Lennart: The State & Future Of Systemd

[Stellarwind]

If it is sarcasm, does that mean you didn't mean what you said? To phrase it otherwise, you don't actually mean what you say, so you don't mean that systemd developers actually make it their hobby to introduce bugs. But then what did you actually try to say? Please explain what your sarcasm meant, otherwise it just looks like you are using it as excuse to run away from what you said.

Read on wikipedia what sarcasm is, it doesn't have to have an irony, despite often used this way. When I wrote "hobby", I didn't actually meant it is their true hobby, but rather to highlight how often this happen. Rest of the statement stands.

When I say "refuse to fix bugs" means they keep closing bugs saying it is not a bug / not in their crapware or just keep dragging it for ages despite either working patch attached or when they can just revert the change they did that broke stuff. Some people just maintain their own forks like gentoo, in other cases Linus happens to notice and fixes it in kernel or starts calling them names.

Giving back money after an armed robbery doen't make you innocent.

And no, I'm not Fedora user, but since systemd/udev is rh projects it is only natural to link to bugs where actual devs reply.
Also Red Hat seems to like douchebags, like those two or Ulrich Drepper, who did the same shit in glibc:

https://bugzilla.redhat.com/show_bug.cgi?id=638477

https://sourceware.org/bugzilla/show_bug.cgi?id=4980

https://www.sourceware.org/ml/libc-alpha/2000-08/msg00053.html

and tons of other things.

[erendorn]

Comparing software engineering to classical engineering assumes that software
has the ability to wear out. Software typically behaves, or it does not. It
either works, or it does not. Software generally does not degrade, abrade,
stretch, twist, or ablate. To treat it as a physical entity, therefore, is
misapplication of our engineering skills. Classical engineering deals with
the characteristics of hardware; software engineering should deal with the
characteristics of *software*, and not with hardware or management.
-- Dan Klein

While software engineering certainly differs from classical engineering, software definitely wears out. An old piece of software will behave as was first intended, just as a century old stone is still very much a stone. The important part is not the stone, it's the building, and yes, individual pieces of software gradually stop being adequate to their environment.

[ncopa]

I love the fascist view of the systemd proponents. "Conform or be thrown out! It must be our way!"

This attitude is what makes me sceptict. And it does not help that they are changing the goals along the way.

The claim they want unite linux community but it feels like they are splitting it.

[ncopa]

It was pretty clear that systemd developers never had any interest in coexisting with alternative init systems, to put it diplomatically.

And now they want be a "general purpose operating system". Will there be room for any alternative implementations for logging, login management, device management, temporary and volatile file management, binary format registration, backlight save/restore, rfkill save/restore, bootchart, readahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration, container management, hostname management, locale management, time management, random seed management, sysctl variable management, or console managment?

Or are alternative implementations of those parts also "pointless differences" that needs to be unified?

What about web browsers or email clients?

Remember, those guys have changed their goals earlier. Who know what their future goals will be?

[erendorn]

And now they want be a "general purpose operating system". Will there be room for any alternative implementations for logging, login management, device management, temporary and volatile file management, binary format registration, backlight save/restore, rfkill save/restore, bootchart, readahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration, container management, hostname management, locale management, time management, random seed management, sysctl variable management, or console managment?

Or are alternative implementations of those parts also "pointless differences" that needs to be unified?

What about web browsers or email clients?

Remember, those guys have changed their goals earlier. Who know what their future goals will be?

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

There is a column "Reimplementable Independently" that exactly answers your question.

[Chousuke]

Still the systemd opponents on Phoronix continue the tradition of ad hominems and FUD, with nothing that even tries to demonstrate why systemd just isn't better.

Can I for a change get a real, technical argument out of you guys? Preferably one that hasn't been debunked several times over, but I'd be happy to see a clearly articulated one with actual effort put into explaining the what and why of the perceived issues.

[Chousuke]

And now they want be a "general purpose operating system". Will there be room for any alternative implementations for logging, login management, device management, temporary and volatile file management, binary format registration, backlight save/restore, rfkill save/restore, bootchart, readahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration, container management, hostname management, locale management, time management, random seed management, sysctl variable management, or console managment?

Or are alternative implementations of those parts also "pointless differences" that needs to be unified?

What about web browsers or email clients?

Remember, those guys have changed their goals earlier. Who know what their future goals will be?

Would you people please stop crying about alternative implementations? None of you is ever going to write one anyway so it doesn't bloody matter at all!

[ceage]

Can I for a change get a real, technical argument out of you guys? Preferably one that hasn't been debunked several times over, but I'd be happy to see a clearly articulated one with actual effort put into explaining the what and why of the perceived issues.

FWIW, what's been bothering me since I first started using systemd is the naming policy used for those types of unit files which encode paths in their file names. Specifically .mount unit files. Mount points already get stored as key-value pair inside the unit file itself, which is where they belong. The redundancy is just confusing there.

It's also unintuitive and over-engineered in a microsoft-ish kind of way. Configuration file naming is a user facing aspect of the program after all. Hence, it should be as easy to grasp as possible for the user, especially when there's no strict requirement to make it easier for the program to handle it. Escape sequences aren't easy to grasp for a non-technical audience. It's okay to use them in generated unit names. However, I see no reason to enforce them for user created unit files as well, other than to make everything look nice and structured *from the perspective of a software engineer*. This kind of restrictive design reminds me a little of Windows and the Registry. I like to call it software bureaucracy.

It's never bothered me enough to make me write to the mailing list though, and apart from such minor issues I consider systemd the greatest thing since sliced bread.

[Chousuke]

FWIW, what's been bothering me since I first started using systemd is the naming policy used for those types of unit files which encode paths in their file names. Specifically .mount unit files. Mount points already get stored as key-value pair inside the unit file itself, which is where they belong. The redundancy is just confusing there.

It's also unintuitive and over-engineered in a microsoft-ish kind of way. Configuration file naming is a user facing aspect of the program after all. Hence, it should be as easy to grasp as possible for the user, especially when there's no strict requirement to make it easier for the program to handle it. Escape sequences aren't easy to grasp for a non-technical audience. It's okay to use them in generated unit names. However, I see no reason to enforce them for user created unit files as well, other than to make everything look nice and structured *from the perspective of a software engineer*. This kind of restrictive design reminds me a little of Windows and the Registry. I like to call it software bureaucracy.

It's never bothered me enough to make me write to the mailing list though, and apart from such minor issues I consider systemd the greatest thing since sliced bread.

Is that naming convention actually enforced? I don't think it's that bad, though some unit names do look a bit weird. The ini-style configuration file syntax is something I don't particularly like (it gets ugly with conditionals), but since it's still preferable over shell scripts and mostly a bikeshedding problem anyway, I can live with it.

Oh, and regarding machine parseability... It does sort of matter for systemd, since systemd also targets embedded systems; there is value in keeping the syntax simplistic so that a small, lightweight parser is easy to write.

[profoundWHALE]

While software engineering certainly differs from classical engineering, software definitely wears out. An old piece of software will behave as was first intended, just as a century old stone is still very much a stone. The important part is not the stone, it's the building, and yes, individual pieces of software gradually stop being adequate to their environment.

Here's the point with software engineering, 10 years down the road it can be doing the same thing it originally did. Sure it won't take advantage of newer hardware and extensions only make it go so far, but it's not going to randomly break on its own. There might be a compatibility issue, but that is true in the real world too; car parts that aren't interchangeable. The difference is with software you can have all the advantages!