10 ms·

The 'haters' are the vocal minority. Lots of people I know, (myself included), actually prefer systemd as it greatly simplifies system management and writing of

The 'haters' are the vocal minority. Lots of people I know, (myself included), actually prefer systemd as it greatly simplifies system management and writing of service files and is a lot more dynamic than upstart was. Maybe it's just my bubble, but systemd tends to be accepted as the right move now. I am sure the people who hate it have good reasons, but all I've heard is 'doesn't follow UNIX philoshophy', (guess what, the whole Linux ecosystem doesn't really, even Stallamn isn't a fan), 'centralized', (somewhat valid, but there's still Gentoo and Void Linux), binary text files, (installing a 'text logger' over journalctl takes 5s and the filtering capabilities of journalctl are awesome). Also, the hate for PulseAudio largely died years ago. I for one am glad for people like Pottering, who are willing to think longer term and produce great* software. Yes, maybe more buggy at the start, (but not really the case with systemd), but great eventually. Also, let's be honest, the reason you see more bugs in i.e. PulseAudio is because it is being developed in the open from its inception.

lettergram 10y ago
Personally, I wish the Linux community went with ZFS. IMO it's still better than systemD as systemD still doesn't have a solid disk backup system... https://wiki.archlinux.org/index.php/ZFS https://wiki.archlinux.org/index.php/ZFS
- walterbell 10y ago
  How is ZFS related to system initialization?
  - AsyncAwait 10y ago
    It's a shot at how systemd supposedly includes everything, I believe...
- Twirrim 10y ago
  It can't, due to licensing incompatibility. ZFS is not compatible with the GPL. Canonical is treading a risky path with what they're doing. I would love ZFS to be native on Linux, BTFS has had too many scary data loss bugs to be able to trust it.
yarrel 10y ago
If it takes "five seconds" to fix the presentation (but not the implementation) of SystemD's log files then there's no reason why people who do not understand SystemD's deficiencies shouldn't be able to spend the same amount of time Googling for one of the many clearly written accounts of them. And I know a lot of musicians who still find PulseAudio not fit for purpose. There's no hate, just frustration at the adoption of a bad solution crowding out ones that work better for their given use case.
- AsyncAwait 10y ago
  > there's no reason why people who do not understand SystemD's deficiencies shouldn't be able to spend the same amount of time Googling for one of the many clearly written accounts of them. I listed the ones I could find and stated why I disagree with them, you could've made this a useful post by listing some additional ones, but instead you choose to just spell, (miscase?), systemd wrong.
- stinkytaco 10y ago
  Why should I spend 5 minutes googling for negative accounts of something I like? I honestly find systemd quite easy to work with. Untangling a maze of init scripts when a package maintainer wasn't being careful or someone made a mistake was miserable. Now startup is more more standardized, in my opinion. I don't like it as well as upstart, but I see no reason to go digging for problems. When I encounter one, I'll do it then.
  - supergreg 10y ago
    > I see no reason to go digging for problems. When I encounter one, I'll do it then. It was the same with init, but instead of digging into greppable script files, you need to dig into Google and systemd manpages first, then dig into the actual issues second.
- cookiecaper 10y ago
  PulseAudio may not serve every use case (and what does?), but it's been an absolute godsend for anyone who remembers the bad old days of Linux sound. Musicians, a small minority of users, can still install JACK to accommodate their needs.
tie_ 10y ago
I don't like systemd for a bit more practical reasons. For example, how do you like the fact that init now comes with "hidden" timers ? After you've scoured every place that a "traditional" Linux might put scheduled tasks, you've come to the realization "Ooooh, now my init has its own cron!". Because obviously an init system needs its own cron! Or the subtle way it breaks existing SysV compatibility. An RPM/Deb package drops its SysV init file at /etc/init.d, and the next thing your ConfigManagement system does is try to start the service - quite standard. Bang - "Unit not found"! Why? Now on systemd-enabled flavors, you need to reload the mofo after dropping in your files. Of course Systemd could hook into dbus and run crons, but it can't be bothered to inotify or even jit-check-upon-request /etc/init.d. Because subtle breakages are cool! How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? And why should it care about the "chasis type" of the machine? These are just some of my own WTFs encountered during my admittedly short but language-colorful interaction with systemd. I have nothing against the Systemd unit files, but the functionality/bug scope of the whole thing is way bigger than I'd feel comfortable with! P.S. Poettering is reportedly a townie, so I'd love to buy him a beer someday and berate him over it.
- AsyncAwait 10y ago
  > For example, how do you like the fact that init now comes with "hidden" timers ? After you've scoured every place that a "traditional" Linux might put scheduled tasks, you've come to the realization "Ooooh, now my init has its own cron!" They're not "hidden", just managed with systemctl like other services, you can still use regular cron if you'd like. As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc, at boot, which I personally would include under the responsibilites of a modern init system and 'system manager' in general, same with taking care of TRIM every so often etc., but I appreciate that it isn't for everyone. > Or the subtle way it breaks existing SysV compatibility. The SysV init scripts would regurarly break in subtle ways by themselves to be honest, I find systemd a much saner option. > How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? And why should it care about the "chasis type" of the machine? The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager, just because it's there, doesn't mean you have to use it. > P.S. berate him over it. Plenty of people already did so, over and over, but have fun, considering you'd be buying him a beer...
wpietri 10y ago
> Yes, maybe more buggy at the start, (but not really the case with systemd), but great eventually. This kind of excuse-making makes me rabid. "We will use our position of power to drag everybody through debugging our poorly made software because we are amazing and one day it will be great" is not a position I will ever have much respect for. If somebody's enough of a genius to see the future of software, they're enough of a genius to make their shit work for the audiences they are currently shipping to.
stevekemp 10y ago
Philosophically I dislike the idea of systemd, primarily because it seems to be growing more and more. (Gaining the ability to launch machines, run DNS, etc) But practically? The service-files are a pleasure to write, the documentation is excellent, and I've not personally had a failure I could attribute to systemd. (Though I did come close, learning that systems with an old version of "snoopy" installed wouldn't boot under systemd.)

lettergram 10y ago

Personally, I wish the Linux community went with ZFS. IMO it's still better than systemD as systemD still doesn't have a solid disk backup system... https://wiki.archlinux.org/index.php/ZFS https://wiki.archlinux.org/index.php/ZFS

walterbell 10y ago
How is ZFS related to system initialization?
- AsyncAwait 10y ago
  It's a shot at how systemd supposedly includes everything, I believe...
Twirrim 10y ago
It can't, due to licensing incompatibility. ZFS is not compatible with the GPL. Canonical is treading a risky path with what they're doing. I would love ZFS to be native on Linux, BTFS has had too many scary data loss bugs to be able to trust it.

yarrel 10y ago

If it takes "five seconds" to fix the presentation (but not the implementation) of SystemD's log files then there's no reason why people who do not understand SystemD's deficiencies shouldn't be able to spend the same amount of time Googling for one of the many clearly written accounts of them. And I know a lot of musicians who still find PulseAudio not fit for purpose. There's no hate, just frustration at the adoption of a bad solution crowding out ones that work better for their given use case.

AsyncAwait 10y ago
> there's no reason why people who do not understand SystemD's deficiencies shouldn't be able to spend the same amount of time Googling for one of the many clearly written accounts of them. I listed the ones I could find and stated why I disagree with them, you could've made this a useful post by listing some additional ones, but instead you choose to just spell, (miscase?), systemd wrong.
stinkytaco 10y ago
Why should I spend 5 minutes googling for negative accounts of something I like? I honestly find systemd quite easy to work with. Untangling a maze of init scripts when a package maintainer wasn't being careful or someone made a mistake was miserable. Now startup is more more standardized, in my opinion. I don't like it as well as upstart, but I see no reason to go digging for problems. When I encounter one, I'll do it then.
- supergreg 10y ago
  > I see no reason to go digging for problems. When I encounter one, I'll do it then. It was the same with init, but instead of digging into greppable script files, you need to dig into Google and systemd manpages first, then dig into the actual issues second.
cookiecaper 10y ago
PulseAudio may not serve every use case (and what does?), but it's been an absolute godsend for anyone who remembers the bad old days of Linux sound. Musicians, a small minority of users, can still install JACK to accommodate their needs.

tie_ 10y ago

I don't like systemd for a bit more practical reasons. For example, how do you like the fact that init now comes with "hidden" timers ? After you've scoured every place that a "traditional" Linux might put scheduled tasks, you've come to the realization "Ooooh, now my init has its own cron!". Because obviously an init system needs its own cron! Or the subtle way it breaks existing SysV compatibility. An RPM/Deb package drops its SysV init file at /etc/init.d, and the next thing your ConfigManagement system does is try to start the service - quite standard. Bang - "Unit not found"! Why? Now on systemd-enabled flavors, you need to reload the mofo after dropping in your files. Of course Systemd could hook into dbus and run crons, but it can't be bothered to inotify or even jit-check-upon-request /etc/init.d. Because subtle breakages are cool! How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? And why should it care about the "chasis type" of the machine? These are just some of my own WTFs encountered during my admittedly short but language-colorful interaction with systemd. I have nothing against the Systemd unit files, but the functionality/bug scope of the whole thing is way bigger than I'd feel comfortable with! P.S. Poettering is reportedly a townie, so I'd love to buy him a beer someday and berate him over it.

AsyncAwait 10y ago
> For example, how do you like the fact that init now comes with "hidden" timers ? After you've scoured every place that a "traditional" Linux might put scheduled tasks, you've come to the realization "Ooooh, now my init has its own cron!" They're not "hidden", just managed with systemctl like other services, you can still use regular cron if you'd like. As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc, at boot, which I personally would include under the responsibilites of a modern init system and 'system manager' in general, same with taking care of TRIM every so often etc., but I appreciate that it isn't for everyone. > Or the subtle way it breaks existing SysV compatibility. The SysV init scripts would regurarly break in subtle ways by themselves to be honest, I find systemd a much saner option. > How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? And why should it care about the "chasis type" of the machine? The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager, just because it's there, doesn't mean you have to use it. > P.S. berate him over it. Plenty of people already did so, over and over, but have fun, considering you'd be buying him a beer...

wpietri 10y ago

> Yes, maybe more buggy at the start, (but not really the case with systemd), but great eventually. This kind of excuse-making makes me rabid. "We will use our position of power to drag everybody through debugging our poorly made software because we are amazing and one day it will be great" is not a position I will ever have much respect for. If somebody's enough of a genius to see the future of software, they're enough of a genius to make their shit work for the audiences they are currently shipping to.

stevekemp 10y ago

Philosophically I dislike the idea of systemd, primarily because it seems to be growing more and more. (Gaining the ability to launch machines, run DNS, etc) But practically? The service-files are a pleasure to write, the documentation is excellent, and I've not personally had a failure I could attribute to systemd. (Though I did come close, learning that systems with an old version of "snoopy" installed wouldn't boot under systemd.)