Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[mdias]

Just because a lot of people rubberstamped a decision doesn't mean it was the right decision. Do you have anything substantial to say in defense of systemd?

I do, but I will not, because:

1. There's plenty of easy to find info on the internet already.
2. It's obvious you will not agree with such info no matter what.

Do note that I will not consider your opinion worthless however. Your opinion is just that - your opinion. And I'm sure your formed your opinion based on your needs and as such, systemd has probably no use in your life.
What I wanted to say in my previous sarcastic comment was that a lot of highly capable people decided that it was important enough to replace the old system, therefore you should probably give a little respect to that decision and think that maybe, for most people, systemd will actually be a better system.
It's ok if you prefer sysvinit, but don't be upset if you get left behind in exchange of making "everyone else" happy. It's how the world works, not just software...

[nictki]

Says the person whose anti-systemd rant was just a string of words without any substance behind them. Hilarious.

I, or anyone else, could write something in defense of systemd. But, two things: a) it has already been said plenty of times, so we'd just waste time repeating it, and b) you'd dismiss it anyway, it's very clear you're not here to have a meaningful discussion.

You might want to look at this this

[prodigy_]

I, or anyone else, could write something in defense of systemd.

Are you sure? Because everyone says they know why systemd is great but seemingly noone can explain it.

Originally the idea behind systemd (as it is with all would-be init replacements) was using synchronous service startup to reduce boot time. A fine goal but how does it justify all the bloat that has been added since? What we have here is a serious case of reinventing the wheel syndrome complicated by some very strange determination to do everything in the most un-UNIX way possible.

[justmy2cents]

In case you didn't notice he is not pissed with systemd. He is pissed with Kay not fixing bugs he introduced.

well, in whole truth he is not pissed off for not fixing bugs, he is pissed on lame excuses why he will not fix the bugs. i think Kay did the same thing few times now, althuogh i only remember the example with cd driver.

same attitude could be attributed to gnome-gtk people on daily basis, not on few examples.

[justmy2cents]

Are you sure? Because everyone says they know why systemd is great but seemingly noone can explain it.

Originally the idea behind systemd (as it is with all would-be init replacements) was using synchronous service startup to reduce boot time. A fine goal but how does it justify all the bloat that has been added since? What we have here is a serious case of reinventing the wheel syndrome complicated by some very strange determination to do everything in the most non-UNIX way possible.

hmmm, let me try this one. for me it is first feature full init that covers all of the bases and most of them in a way that it is right. which means it could be suitable for any distro to pick it up and have all requirements for init met. maybe... just maybe, in perfect world we could someday be able to start services on machines where you don't need to go trough discovery which distro you are running, which init does it use and how the hell some typical data is stored. as simple as that. no claims about rocket science

as for reinventing. if you would read more, you would see they really tried to pick up upstart 1st, even RHEL and Fedora adopted it for some time. CLA was unavoidable bug. but, going with new was simply better. if you would check upstart, you would notice how service dependencies are simply done wrong there

[Gusar]

Are you sure? Because everyone says they know why systemd is great but seemingly noone can explain it.

We can and we have. The point is, why do it again for someone who's not willing to really listen anyway?

Originally the idea behind systemd (as it is with all would-be init replacements) was using synchronous service startup to reduce boot time.[/QUOTE]No, fast boot times are a side-effect of systemd's design, not an explicit goal.

A fine goal but how does it justify all the bloat that has been added since? What we have here is a serious case of reinventing the wheel syndrome complicated by some very strange determination to do everything in the most un-UNIX way possible.

Which parts do you consider bloat? logind doing session tracking better than consolekit did? Other stuffd that DEs want to make use of so they don't need to write support for, say, changing the timezone for each distro separately (ifdef mess anyone)? networkd with it's focus on containers, but nevertheless being usable elsewhere too, like fast reconnection when resuming a suspended laptop?

[prodigy_]

hmmm, let me try this one. for me it is first feature full init that covers all of the bases and most of them in a way that it is right. which means it could be suitable for any distro to pick it up and have all requirements for init met. maybe... just maybe, in perfect world we could someday be able to start services on machines where you don't need to go trough discovery which distro you are running, which init does it use and how the hell some typical data is stored. as simple as that. no claims about rocket science

as for reinventing. if you would read more, you would see they really tried to pick up upstart 1st, even RHEL and Fedora adopted it for some time. CLA was unavoidable bug. but, going with new was simply better. if you would check upstart, you would notice how service dependencies are simply done wrong there

I know why upstart was never adopted beyond Ubuntu and derivatives. Though upstart has the benefit of simplicity, ultimately it's just as broken.

That's not what I was talking about though. Systemd isn't just a PID1 that starts daemons. Sadly, it's much more. As you said, it "covers all of the bases" forcing everything to depend on it (networkd, logind) and making things less transparent than they used to be (journald).

[combuster]

well, in whole truth he is not pissed off for not fixing bugs, he is pissed on lame excuses why he will not fix the bugs. i think Kay did the same thing few times now, althuogh i only remember the example with cd driver.

same attitude could be attributed to gnome-gtk people on daily basis, not on few examples.

I was once being told by a systemd and by a SMACK developer that userspace can't be responsible, EVER, for trashing the kernel So it's always a kernel bug. Same thing Linus admited when he was angry at one of the kernel dev's that blamed systemd dev's for fscking up the kernel (some sound related issue, can't remember).

So, from everything I've read so far, too many debug info that is trashing the kernel is a kernel bug. That could've been induced by a kernel driver that has debug info enabled and is spamming out large. But since this was triggered by systemd - and systemd should not really mirror the kernel behaviour with the same parameters - this was the only right course of action.

This - responsibility shifting thingy - we are not here to say - It wasn't my fault. Instead we should say - Let us work together and see if we can fix this.

And ocassionally - Screw you nV****

/edit: And yes, I'm one of those Arch users that wish they have never "upgraded" their rc.conf for systemctl and greping a number of individual config files for just journald.

[prodigy_]

Which parts do you consider bloat?

This one is easy. Everything that extends beyond service management is bloat (so about 90% of what systemd is today).

[justmy2cents]

I was once being told by a systemd and by a SMACK developer that userspace can't be responsible, EVER, for trashing the kernel So it's always a kernel bug. Same thing Linus admited when he was angry at one of the kernel dev's that blamed systemd dev's for fscking up the kernel (some sound related issue, can't remember).

So, from everything I've read so far, too many debug info that is trashing the kernel is a kernel bug. That could've been induced by a kernel driver that has debug info enabled and is spamming out large. But since this was triggered by systemd - and systemd should not really mirror the kernel behaviour with the same parameters - this was the only right course of action.

This - responsibility shifting thingy - we are not here to say - It wasn't my fault. Instead we should say - Let us work together and see if we can fix this.

And ocassionally - Screw you nV****

/edit: And yes, I'm one of those Arch users that wish they have never "upgraded" their rc.conf for systemctl and greping a number of individual config files for just journald.

yep, as i said. Kay simply lacks tact. if he made well done case point, but his answers sometimes really border on "GTFO and bother kernel people". that is not to say Kay is at fault,

me for example... not being primarily english spoken person i often suffer from being to direct where i realize 3 posts later that i was actually rude and offensive (even though it was the least of my intention). that directness comes when you look at our country language being directly translated into english. but, sooner or later one has to realize that about him self when it communicates in some serious session like kernel development and maybe force him self to at least rethink what he wrote.