Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The vast majority of distros seem to agree that standardization is a good thing in the switch to systemd. If you don't want to be standardized maintain it yourself, see: GoboLinux.

But modularity of Linux doesn't seem to be going anywhere. Contrary to what the author says, systemd is not monolithic but rather consists of protocols and multiple daemons outside of PID1.

There doesn't seem to be any plans to stop one from using anything other than systemd on say Debian either. As far as I know the only hard requirement for systemd (really logind) is with Gnome on Wayland for user seats, because Consolekit is dead. Gnome seems to be willing to work with the *BSDs et al who have no plans to switch to systemd.

https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...



It consists of multiple daemons which are relied on by userland applications, are so strongly interdependent that the systemd developers don't support running them independently, and which have no stable or documented APIs between the different components. Oh, and many of them are infeasable to re-implement according to said developers.

Now, the Gnome developers may argue that technically Gnome doesn't require logind, and technically they're right. You lose the ability to shutdown, restart, sleep or hibernate your PC from the Gnome user interface - all things that worked before and that normal users expect to be able to do - but you can technically run without it. The API for those things isn't itself terribly complicated, but because the systemd and Gnome developers don't give a fuck about anything other than systemd they've bundled it together with a whole bunch of complicated, poorly-documented multiseat stuff that can only be implemented as one single, monolithic all-or-nothing API.

Which is, I think, part of the reason why Ubuntu gave up and is switching to systemd; they can hardly ship something that requires users to use the command line to shutdown or suspend their PC.

Edit: Also, the bit about how "we specifically approved some patches to allow Canonical to run logind without systemd" is... well, outdated is probably the politest way to put it. Since then the systemd developers have announced that they're breaking the ability to run logind seperately in future, they never supported it in the first place, and Ubuntu should never have done it.


The problem is that while systemd is superficially a bunch of different commands, they are a clinking, clanking mess of poorly documented programs that do their job worse than the programs they replace.

For a moment, let's look at one of these components, systemd-backlight, and it's terribly written manual page, http://www.freedesktop.org/software/systemd/man/systemd-back... . Okay, so what return values can you expect? Where on the filesystem does it store the saved values so you can debug if things do go cactus? Why does it always overwrite the value at shutdown? These are all things that a reasonable program either should not do, or should document why and where they put things. Systemd just is not a responsible, well-engineered project.

Furtnermore, the only real reason consolekit is dead is because Lennart again shows a complete lack of responsibility as a developer with that project. He'd rather shove everyone towards his new baby of systemd than to do a responsible hand-off. This is furthered in his inability to document the interfaces used so that people can write compatible software, so that people can debug software, and so that people can maintain things if he ever gets hit by the number eight bus going downtown. It's just not a good way to run things, period.


> Where on the filesystem does it store the saved values so you can debug if things do go cactus?

Quoting the page you linked to: "On disk, the backlight brightness is stored in /var/lib/systemd/backlight/."


I missed it. I guess I've gotten spoiled by BSD manual pages that have file locations in a subsection labelled Files instead of stuck in the description. At the same time, it gives a directory location, instead of an actual filename, which lends one to believe that the actual name and location will be subject to change without notice, as well as the contents of the file, format, etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: