5 ms·

Am I the only one who likes systemd? No more problems with overflowing logfiles, no more debugging undocumented shell scripts for booting, no more writing init

by creshal 11y ago

Am I the only one who likes systemd? No more problems with overflowing logfiles, no more debugging undocumented shell scripts for booting, no more writing init scripts, no more debugging undocumented 200+ line init scripts, no more minute-long boot delays, no more brittle, half-assed distribution-specific networking solutions (also undocumented shell scripts), ... For me as sysadmin, systemd solved a lot of long-standing problems, while so far introducing no new ones.

vezzy-fnord 11y ago
No more problems with overflowing logfiles Not quite. The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can. no more debugging undocumented shell scripts for booting no more writing init scripts no more debugging undocumented 200+ line init scripts Redundant complaints, and irrelevant. Not all script-based init systems are created equal, and many init systems throughout history have eschewed shell scripts [1]. no more minute-long boot delays Incorrect. Boots can still stall from dependency loops, cyclical transactions, stuck start/stop jobs, an improperly calculated service ordering in the parallel dependency graph, etc. no more brittle, half-assed distribution-specific networking solutions (also undocumented shell scripts) Incorrect. networkd is tailored to specific purposes (largely containers) and not a general-purpose NetworkManager replacement, nor does it necessarily deprecate any ad-hoc network configuration scripts (which aren't even intrinsically bad). [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/
- creshal 11y ago
  Why, yes, I could clobber together my own server distribution with multilog and obscure init systems and whatnot, or… I could just use the distribution default, which massively improved over the old status quo with the introduction of systemd. > The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can. So my choices are a) systemd + journald, which Just Works™ by always feeding units' stdout to it without any further configuration, b) syslog and logrotate and oh I have to patch software to use syslog in the first place and make sure logrotate rotates the files correctly if a daemon still its logfile open and… yeah, screw that, I've wasted enough of my life with that, c) something where I manually set up everything to use multilog. > Redundant complaints, and irrelevant From your ivory tower, maybe. Meanwhile I'm sitting in the trenches and banging my head against the wall because someone again managed to break their 300+ line init script (hi, MySQL!). > Incorrect. I did not mean failure cases. The average case, where every service starts up in a correct order on sysvinit/systemd, went from ~60 seconds to <20. Now, a reboot is usually faster than the failover timeout. And unlike with Debian's "dependency-based sysvinit", systemd works. I've yet to see a failure case that wasn't caused by either hardware failure or gross operator error (e.g. referencing /var wrong in the fstab). > Incorrect. Well, it looks I have to throw away my perfectly working networkd setups then, if you say so. > NetworkManager I wasn't even talking about that. I was mainly referring to Debian's networking scripts (which have been broken and unfixed for half a decade now) and Arch's netcfg/netctl which all three never worked as advertised. If NetworkManager was actually usable on headless devices, I might prefer it over networkd, too (assuming I find a use case where either it or connman are insufficient).
chimeracoder 11y ago
> Am I the only one who likes systemd? No, but those of us who do generally get downvoted for mentioning it in these comment threads, so many just stay away. Paradoxically, due to the positive feedback loop of people downvoting comments that they disagree with and thereby driving away dissenting voices, comment threads on polarizing topics like these tend to be a pretty poor representation of actual popular opinion, as opposed to the opinion of the loudest people in the room.
- vezzy-fnord 11y ago
  I mean, it's not that I'm going to rain on your parade if you want to use systemd. But by and large most systemd proponents seem to scantly have any idea why they like it beyond parroting misconceptions and half-truths, much as many critics aren't sure why they hate it.
  - deleted 11y ago
    [deleted]
    - vezzy-fnord 11y ago
      I'd take it you've actually studied the Unit object, the internal graph engine, the transaction manager, the seven different job queuing modes, the contextual relationships between services, jobs and units, the semantics of the dependency and relationship model, how execution state is composed, etc.? Those are seldom talked about, but are some of the primary reasons I object to systemd. Are you neutral on those aspects, or do you see them as definitively positive?
      - deleted 11y ago
        [deleted]
      - mercurial 11y ago
        Not having looked at the internals of systemd, I'll take your word for it. The question is, is it possible to offer a similar feature set with a simpler model?
wyldfire 11y ago
I like it too. I think systemd has the misfortune/honor of touching decades-old subsystem interfaces. Any time anyone ever makes a change to something that's worked the same forever faces criticism. systemd's feature set is so attractive that it's getting/gotten adopted by the vast majority share of linux distros. The folks who didn't prefer it but thought that they could ignore it may have been surprised and vocal when it showed up in their favorite distro. >undocumented 200+ line init scripts ... undocumented shell scripts Maybe we've just traded those for undocumented C init programs?
- mateuszf 11y ago
  Even if it's undocumented (as far as I know it is well documented), at least this code is in one place.
  - simoncion 11y ago
    A few people have attempted to use the systemd documentation to create a reimplementation. Bearing in mind that the task is complex and largely thankless, all the folks making attempts that I've heard about have reported that the available documentation does not provide enough information to complete such a task. Note: I KNOW that documentation is seriously hard. But, one of the rebuttals of the "Systemd is complex and monolithic" assertion is "Systemd is fully documented, so you can replace any part of it with one that you've authored.". You can't honestly make that rebuttal if the state of your documentation doesn't support your claim.
    - mateuszf 11y ago
      That's because if the code is over some quality level (which can be measured with bugs count) then the source itself is implementation documentation. And systemd contains the more classic documentation of its behaviour for its end users.
      - simoncion 11y ago
        > ...if the code is over some quality level (which can be measured with bugs count) then the source itself is implementation documentation. Oh, you summer child. In any complex software project, there's always a difference between the contract described by the system's specification and the contract described by the software as implemented. The big difference between the explicit contract of the documentation and implicit contract of the code is that -in areas on which the documentation is silent- the contract described by the code is subject to change at any time, without warning. Raymond Chen [0] has spilled much ink over customers who have gotten badly burned by changes in the implicit contract some time after they made use of something that the code permitted, but the documentation did not describe as possible and/or supported. [0] Microsoft most notable backwards-compatibility guru
arbitrage 11y ago
Personally, I hate not being able to dig into it when something goes wrong. But that familiarity will come with time. What I absolutely LOVE is a much more robust ordering of system service turn ons. Start network BEFORE ntpd. Start rpcbind BEFORE nfs-server. A lot of hack solutions for this chicken & egg problem in the past were always very fragile.
- vezzy-fnord 11y ago
  FYI, all ordering options in systemd are relative and not absolute. You cannot guarantee in systemd that X will be started before Y, because that's not how it works. You declare an approximate dependency and ordering scheme, which is then fed into a graph, optimized and recalculated in memory on every bootup and state-modifying operation. There is no determinism in the boot order due to parallelism and some other constraints, so you can potentially have services be malignantly reordered or fail because of cyclical transactions, loops and stuck jobs. The point is that, if you're thinking of it as a linear ordered sequence, you have the wrong mental model. On the other hand, systems like OpenRC do work that way.
  - deleted 11y ago
    [deleted]
  - simoncion 11y ago
    > if you're thinking of it as a linear ordered sequence, you have the wrong mental model. On the other hand, systems like OpenRC do work that way. Are you sure that OpenRC works in this way? There may be some subtlety that I'm missing, but the documentation for systemd unit files [0] seems to describe a service dependency and ordering specification system that looks equivalent to what OpenRC provides with "need", "use", "before", and "after". (Search for "[Unit] Section Options" and read on from there.) [0] http://www.freedesktop.org/software/systemd/man/systemd.unit.html http://www.freedesktop.org/software/systemd/man/systemd.unit...
    - vezzy-fnord 11y ago
      Again, don't be deceived into judging an architecture by its public interface. It certainly appears similarly, but the dependency and ordering primitives are interpreted much more loosely like tags than they are like absolute requirements. Simplifying things, your unit file actually becomes a Unit object which queues a job (which is itself a Unit) which is scheduled and checked for consistency in a transaction, which encapsulates a service (itself a Unit and one that controls jobs). The final graph of dependency information largely does not reflect what you configured.
vacri 11y ago
Upstart did all those things without needing to worm it's way through the whole system like systemd does. You're mistaking people's dislike for systemd with a love of sysv init - no-one liked sysv init and everyone wanted a change. It's just that systemd has taken a very broad remit, plus the maintainers have a 'fuck your use-case' attitude.
simoncion 11y ago
> No more problems with overflowing logfiles... Logrotate solves this for me, for every logging method. How did it fail for you? > ...no more minute-long boot delays... I don't have this issue with OpenRC on Gentoo. shrug I do know that Kubuntu 15.04's boot time is irregularly slow, and that its shutdown process -every once in a while- hangs forever, requiring the use of SysRq keys. This didn't happen with the previous, Upstart-based version of Kubuntu. (Then again, there are many things wrong with Kubuntu 15.04, so this might not be entirely systemd's fault. ;) ) > ...no more debugging undocumented shell scripts for booting... Scripts written for OpenRC are typically easy to read. Complex tasks -necessarily- require complex scripts, but you'd have to write and call out to those scripts with systemd, too! > ...no more writing init scripts... For services whose startup is as simple as what systemd handles out of the box, I can write a one-to-seven-line startup script for OpenRC and call it a day. Additionally every service packaged in my package manager has come with a init script. [0] > ...no more brittle, half-assed distribution-specific networking solutions... shrug Gentoo uses netifrc. It does appear that this is a distro-specific way to bring up the network, [1] but I assure you that it's full-assed, has a well documented and flexible config file, and is not brittle. [0] Some of them -like the network startup scripts, and the OpenVPN startup scripts- let you make a symlink to the original script, which changes the behavior of the script. In the case of the network startup scripts, this makes that script change the state of a particular network interface, virtual or otherwise. In the case of OpenVPN's script, this causes the startup script to look for config files with a different name. In the OpenVPN case, you symlink /etc/init.d/openvpn to /etc/init.d/openvpn.newconfig . The symlinked openvpn startup script then uses the OpenVPN config file /etc/openvpn/newconfig.config to start the "openvpn.newconfig" service. It's really handy! How would you do this in systemd? Make a new unit file? [1] Only because -like all distro-specific things-, noone else has bothered to adopt it. ;)
- Mic92 11y ago
  How would you do this in systemd? Make a new unit file? systemd start openvpn@<config_name>
  - simoncion 11y ago
    So, the openvpn unit file would make use of the %i or %I specifier described here? [0] [0] http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Specifiers http://www.freedesktop.org/software/systemd/man/systemd.unit...
pmarin 11y ago
What kind of unix sysadmin can't understand 200 línes of shell code which most of it is just boilerplate code?
- mateuszf 11y ago
  Who needs calculators? The same can be done "by hands". But the problem with that is that doing it many times is error prone. Why not let it be solved once for good?
- vacri 11y ago
  What kind of unix sysadmin doesn't like turning 200 lines of code into 10 lines of code :)
  - reactor4 11y ago
    200 lines of code into 10 lines of configs
pmarin 11y ago
what kind of unix sysadmin can't understand 200 línes of shell code which most of it its just boilerplate code?
Sanddancer 11y ago
Have you ever used the BSD's rc? How about launchd? SMF? The biggest problem with systemd is that it goes about trying to fix the problems with traditional sysv init in a rather inelegant, inconsistent way. In your sysadmin roles, how do you now aggregate your logs for later auditing? How often do you really reboot where you'll experience that minute long delay? There are definite problems with sysv init, and systemd is a bit better, but there are a lot of other systems that have solved those problems too, often in a lot cleaner fashion.
JeremyNT 11y ago
I like it, as well. It simplifies many things and no practical functionality is sacrificed. Most arguments against sysyemd appear to be appeals to tradition, not based on any technical deficiency. In actual use I have found no fault with it and it does make some things easier. The only argument against sysyemd that I find somewhat sympathetic is the fact that there is always a cost to pay when migrating to and learning about something new. This is certainly true. However, I find the user experience of systemd to be superior, and this small upfront price seems worth paying.
chronid 11y ago
I actually like some things of the init daemon part of systemd. But systemd is not only an init daemon anymore and the systemd developers work actively to cut off everything that is not systemd (see the udev saga as an example) or make idiotic decisions (NTP server defaults?). And that, in addition to some other things (why should udev be part of systemd? Why should be there an arbitrary limitation in core files size? See also [1] for more) left me very worried. And I don't like journald at all, rsyslog does almost everything already. And the way Fedora integrated kdbus before it was put into the mainline kernel? That's ridiculous, sorry. The need to make another 'su' because the older one was not good enough in the mind of the developers? And now 'systemctl is-system-running'? Wat? 1. http://suckless.org/sucks/systemd http://suckless.org/sucks/systemd
- digi_owl 11y ago
  > But systemd is not only an init daemon anymore and the systemd developers work actively to cut off everything that is not systemd (see the udev saga as an example) http://www.landley.net/notes-2015.html#05-07-2015 http://www.landley.net/notes-2015.html#05-07-2015 is a lovely entry from Rob Landley about trying to maintain an alternative to udev, and getting the runaround by GregKH and Kay Sievers. > or make idiotic decisions (NTP server defaults?). Love the excuse for that. "Systemd is not meant for end users, and distros should set their own servers anyways". Its like anyone thats not a developers working for/on the large name distros are users (aka consumers, aka mooo) and should shut up and accept what the distros ship.

by creshal 11y ago

vezzy-fnord 11y ago

No more problems with overflowing logfiles Not quite. The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can. no more debugging undocumented shell scripts for booting no more writing init scripts no more debugging undocumented 200+ line init scripts Redundant complaints, and irrelevant. Not all script-based init systems are created equal, and many init systems throughout history have eschewed shell scripts [1]. no more minute-long boot delays Incorrect. Boots can still stall from dependency loops, cyclical transactions, stuck start/stop jobs, an improperly calculated service ordering in the parallel dependency graph, etc. no more brittle, half-assed distribution-specific networking solutions (also undocumented shell scripts) Incorrect. networkd is tailored to specific purposes (largely containers) and not a general-purpose NetworkManager replacement, nor does it necessarily deprecate any ad-hoc network configuration scripts (which aren't even intrinsically bad). [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/

creshal 11y ago
Why, yes, I could clobber together my own server distribution with multilog and obscure init systems and whatnot, or… I could just use the distribution default, which massively improved over the old status quo with the introduction of systemd. > The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can. So my choices are a) systemd + journald, which Just Works™ by always feeding units' stdout to it without any further configuration, b) syslog and logrotate and oh I have to patch software to use syslog in the first place and make sure logrotate rotates the files correctly if a daemon still its logfile open and… yeah, screw that, I've wasted enough of my life with that, c) something where I manually set up everything to use multilog. > Redundant complaints, and irrelevant From your ivory tower, maybe. Meanwhile I'm sitting in the trenches and banging my head against the wall because someone again managed to break their 300+ line init script (hi, MySQL!). > Incorrect. I did not mean failure cases. The average case, where every service starts up in a correct order on sysvinit/systemd, went from ~60 seconds to <20. Now, a reboot is usually faster than the failover timeout. And unlike with Debian's "dependency-based sysvinit", systemd works. I've yet to see a failure case that wasn't caused by either hardware failure or gross operator error (e.g. referencing /var wrong in the fstab). > Incorrect. Well, it looks I have to throw away my perfectly working networkd setups then, if you say so. > NetworkManager I wasn't even talking about that. I was mainly referring to Debian's networking scripts (which have been broken and unfixed for half a decade now) and Arch's netcfg/netctl which all three never worked as advertised. If NetworkManager was actually usable on headless devices, I might prefer it over networkd, too (assuming I find a use case where either it or connman are insufficient).

chimeracoder 11y ago

> Am I the only one who likes systemd? No, but those of us who do generally get downvoted for mentioning it in these comment threads, so many just stay away. Paradoxically, due to the positive feedback loop of people downvoting comments that they disagree with and thereby driving away dissenting voices, comment threads on polarizing topics like these tend to be a pretty poor representation of actual popular opinion, as opposed to the opinion of the loudest people in the room.

vezzy-fnord 11y ago
I mean, it's not that I'm going to rain on your parade if you want to use systemd. But by and large most systemd proponents seem to scantly have any idea why they like it beyond parroting misconceptions and half-truths, much as many critics aren't sure why they hate it.
- deleted 11y ago
  [deleted]
  - vezzy-fnord 11y ago
    I'd take it you've actually studied the Unit object, the internal graph engine, the transaction manager, the seven different job queuing modes, the contextual relationships between services, jobs and units, the semantics of the dependency and relationship model, how execution state is composed, etc.? Those are seldom talked about, but are some of the primary reasons I object to systemd. Are you neutral on those aspects, or do you see them as definitively positive?
    - deleted 11y ago
      [deleted]
    - mercurial 11y ago
      Not having looked at the internals of systemd, I'll take your word for it. The question is, is it possible to offer a similar feature set with a simpler model?

wyldfire 11y ago

I like it too. I think systemd has the misfortune/honor of touching decades-old subsystem interfaces. Any time anyone ever makes a change to something that's worked the same forever faces criticism. systemd's feature set is so attractive that it's getting/gotten adopted by the vast majority share of linux distros. The folks who didn't prefer it but thought that they could ignore it may have been surprised and vocal when it showed up in their favorite distro. >undocumented 200+ line init scripts ... undocumented shell scripts Maybe we've just traded those for undocumented C init programs?

mateuszf 11y ago
Even if it's undocumented (as far as I know it is well documented), at least this code is in one place.
- simoncion 11y ago
  A few people have attempted to use the systemd documentation to create a reimplementation. Bearing in mind that the task is complex and largely thankless, all the folks making attempts that I've heard about have reported that the available documentation does not provide enough information to complete such a task. Note: I KNOW that documentation is seriously hard. But, one of the rebuttals of the "Systemd is complex and monolithic" assertion is "Systemd is fully documented, so you can replace any part of it with one that you've authored.". You can't honestly make that rebuttal if the state of your documentation doesn't support your claim.
  - mateuszf 11y ago
    That's because if the code is over some quality level (which can be measured with bugs count) then the source itself is implementation documentation. And systemd contains the more classic documentation of its behaviour for its end users.
    - simoncion 11y ago
      > ...if the code is over some quality level (which can be measured with bugs count) then the source itself is implementation documentation. Oh, you summer child. In any complex software project, there's always a difference between the contract described by the system's specification and the contract described by the software as implemented. The big difference between the explicit contract of the documentation and implicit contract of the code is that -in areas on which the documentation is silent- the contract described by the code is subject to change at any time, without warning. Raymond Chen [0] has spilled much ink over customers who have gotten badly burned by changes in the implicit contract some time after they made use of something that the code permitted, but the documentation did not describe as possible and/or supported. [0] Microsoft most notable backwards-compatibility guru

arbitrage 11y ago

Personally, I hate not being able to dig into it when something goes wrong. But that familiarity will come with time. What I absolutely LOVE is a much more robust ordering of system service turn ons. Start network BEFORE ntpd. Start rpcbind BEFORE nfs-server. A lot of hack solutions for this chicken & egg problem in the past were always very fragile.

vezzy-fnord 11y ago
FYI, all ordering options in systemd are relative and not absolute. You cannot guarantee in systemd that X will be started before Y, because that's not how it works. You declare an approximate dependency and ordering scheme, which is then fed into a graph, optimized and recalculated in memory on every bootup and state-modifying operation. There is no determinism in the boot order due to parallelism and some other constraints, so you can potentially have services be malignantly reordered or fail because of cyclical transactions, loops and stuck jobs. The point is that, if you're thinking of it as a linear ordered sequence, you have the wrong mental model. On the other hand, systems like OpenRC do work that way.
- deleted 11y ago
  [deleted]
- simoncion 11y ago
  > if you're thinking of it as a linear ordered sequence, you have the wrong mental model. On the other hand, systems like OpenRC do work that way. Are you sure that OpenRC works in this way? There may be some subtlety that I'm missing, but the documentation for systemd unit files [0] seems to describe a service dependency and ordering specification system that looks equivalent to what OpenRC provides with "need", "use", "before", and "after". (Search for "[Unit] Section Options" and read on from there.) [0] http://www.freedesktop.org/software/systemd/man/systemd.unit.html http://www.freedesktop.org/software/systemd/man/systemd.unit...
  - vezzy-fnord 11y ago
    Again, don't be deceived into judging an architecture by its public interface. It certainly appears similarly, but the dependency and ordering primitives are interpreted much more loosely like tags than they are like absolute requirements. Simplifying things, your unit file actually becomes a Unit object which queues a job (which is itself a Unit) which is scheduled and checked for consistency in a transaction, which encapsulates a service (itself a Unit and one that controls jobs). The final graph of dependency information largely does not reflect what you configured.

vacri 11y ago

Upstart did all those things without needing to worm it's way through the whole system like systemd does. You're mistaking people's dislike for systemd with a love of sysv init - no-one liked sysv init and everyone wanted a change. It's just that systemd has taken a very broad remit, plus the maintainers have a 'fuck your use-case' attitude.

simoncion 11y ago

> No more problems with overflowing logfiles... Logrotate solves this for me, for every logging method. How did it fail for you? > ...no more minute-long boot delays... I don't have this issue with OpenRC on Gentoo. shrug I do know that Kubuntu 15.04's boot time is irregularly slow, and that its shutdown process -every once in a while- hangs forever, requiring the use of SysRq keys. This didn't happen with the previous, Upstart-based version of Kubuntu. (Then again, there are many things wrong with Kubuntu 15.04, so this might not be entirely systemd's fault. ;) ) > ...no more debugging undocumented shell scripts for booting... Scripts written for OpenRC are typically easy to read. Complex tasks -necessarily- require complex scripts, but you'd have to write and call out to those scripts with systemd, too! > ...no more writing init scripts... For services whose startup is as simple as what systemd handles out of the box, I can write a one-to-seven-line startup script for OpenRC and call it a day. Additionally every service packaged in my package manager has come with a init script. [0] > ...no more brittle, half-assed distribution-specific networking solutions... shrug Gentoo uses netifrc. It does appear that this is a distro-specific way to bring up the network, [1] but I assure you that it's full-assed, has a well documented and flexible config file, and is not brittle. [0] Some of them -like the network startup scripts, and the OpenVPN startup scripts- let you make a symlink to the original script, which changes the behavior of the script. In the case of the network startup scripts, this makes that script change the state of a particular network interface, virtual or otherwise. In the case of OpenVPN's script, this causes the startup script to look for config files with a different name. In the OpenVPN case, you symlink /etc/init.d/openvpn to /etc/init.d/openvpn.newconfig . The symlinked openvpn startup script then uses the OpenVPN config file /etc/openvpn/newconfig.config to start the "openvpn.newconfig" service. It's really handy! How would you do this in systemd? Make a new unit file? [1] Only because -like all distro-specific things-, noone else has bothered to adopt it. ;)

Mic92 11y ago
How would you do this in systemd? Make a new unit file? systemd start openvpn@<config_name>
- simoncion 11y ago
  So, the openvpn unit file would make use of the %i or %I specifier described here? [0] [0] http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Specifiers http://www.freedesktop.org/software/systemd/man/systemd.unit...

pmarin 11y ago

What kind of unix sysadmin can't understand 200 línes of shell code which most of it is just boilerplate code?

mateuszf 11y ago
Who needs calculators? The same can be done "by hands". But the problem with that is that doing it many times is error prone. Why not let it be solved once for good?
vacri 11y ago
What kind of unix sysadmin doesn't like turning 200 lines of code into 10 lines of code :)
- reactor4 11y ago
  200 lines of code into 10 lines of configs

pmarin 11y ago

what kind of unix sysadmin can't understand 200 línes of shell code which most of it its just boilerplate code?

Sanddancer 11y ago

Have you ever used the BSD's rc? How about launchd? SMF? The biggest problem with systemd is that it goes about trying to fix the problems with traditional sysv init in a rather inelegant, inconsistent way. In your sysadmin roles, how do you now aggregate your logs for later auditing? How often do you really reboot where you'll experience that minute long delay? There are definite problems with sysv init, and systemd is a bit better, but there are a lot of other systems that have solved those problems too, often in a lot cleaner fashion.

JeremyNT 11y ago

I like it, as well. It simplifies many things and no practical functionality is sacrificed. Most arguments against sysyemd appear to be appeals to tradition, not based on any technical deficiency. In actual use I have found no fault with it and it does make some things easier. The only argument against sysyemd that I find somewhat sympathetic is the fact that there is always a cost to pay when migrating to and learning about something new. This is certainly true. However, I find the user experience of systemd to be superior, and this small upfront price seems worth paying.

chronid 11y ago

I actually like some things of the init daemon part of systemd. But systemd is not only an init daemon anymore and the systemd developers work actively to cut off everything that is not systemd (see the udev saga as an example) or make idiotic decisions (NTP server defaults?). And that, in addition to some other things (why should udev be part of systemd? Why should be there an arbitrary limitation in core files size? See also [1] for more) left me very worried. And I don't like journald at all, rsyslog does almost everything already. And the way Fedora integrated kdbus before it was put into the mainline kernel? That's ridiculous, sorry. The need to make another 'su' because the older one was not good enough in the mind of the developers? And now 'systemctl is-system-running'? Wat? 1. http://suckless.org/sucks/systemd http://suckless.org/sucks/systemd

digi_owl 11y ago
> But systemd is not only an init daemon anymore and the systemd developers work actively to cut off everything that is not systemd (see the udev saga as an example) http://www.landley.net/notes-2015.html#05-07-2015 http://www.landley.net/notes-2015.html#05-07-2015 is a lovely entry from Rob Landley about trying to maintain an alternative to udev, and getting the runaround by GregKH and Kay Sievers. > or make idiotic decisions (NTP server defaults?). Love the excuse for that. "Systemd is not meant for end users, and distros should set their own servers anyways". Its like anyone thats not a developers working for/on the large name distros are users (aka consumers, aka mooo) and should shut up and accept what the distros ship.