7 ms·

I don't "hate" systemd either, I just think it's a bad approach. It flies in the face of the "open architecture" concept and stifles innovation. It discourages

I don't "hate" systemd either, I just think it's a bad approach. It flies in the face of the "open architecture" concept and stifles innovation. It discourages users from learning about how their operating system works, and it unnecessarily puts too much control of a fundamental component of the OS in the hands of a too-small number of people. None of these reflect the Linux I grew up with. Thus, I am not a fan of systemd. #notmylinux

ossreality 11y ago
What a completely unsubstantiated load of FUD. >#notmylinux oh, you're just a troll. k..
cubancigar11 11y ago
ossreality you are [dead]
- deleted 11y ago
  [deleted]
- cubancigar11 11y ago
  People downmodding this have really nothing better to do?
olau 11y ago
Interesting way to think about it. IMHO systemd is taking much of the hacks and weird glue that has historically held distributions together and replaced it with an active upstream project. Maybe some of the solutions they've come up with could need some improvements, but I have much higher confidence those improvements would happen now compared to how things used to be. Nowadays you can code something up and come to the systemd mailing list and get feedback and get it integrated. Previously you'd have to convince one or more not-really-connected distro hackers that your new fancy thing is worth rocking the boat for.
- weland 11y ago
  Unfortunately, the systemd development team is not that easy to work with, which is part of why a lot of people distrust systemd the way they do. In theory, yes, it should be the way you mention it. In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. No one who has used more than one Linux distro would disagree that a unified system to control init services is a good idea. It's this particular implementation that's problematic, not the principle.
  - madez 11y ago
    In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. Where is the evidence?
    - weland 11y ago
      All over their bugtracker, but the most famous one is here: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935
      - EmanueleAina 11y ago
        Which was ultimately caused by a bug in the kernel, and the systemd developer ultimately accepted the proposed changes just to avoid any kind of confusion (to me, it looked perfectly acceptable to parse the kernel command-line, multiple applications still do for other purposes). Arguably, the tone of the discussion resembles more the usual LKML tone rather than the one observable on the systemd mailing list.
        yellowapple 11y ago
        I fail to see how systemd hijacking a kernel boot argument for its own purposes is a "bug in the kernel".
        11y ago
johnny22 11y ago
Definitely disagree with that. I've been using some form of a Linux based OS since 1998. Now i'm finally starting to feel like this is #mylinux.
exelius 11y ago
Once upon a time, we were obsessed with efficiency and speed of code. We created powerful, but simple systems like sysvinit, and we designed to optimize speed in 80% of use cases. The Linux you grew up with used to mostly run on x86 machines, except the majority of Linux devices now run on ARM with different power requirements, hardware, drivers, etc. than x86 ever had to deal with. The increasing complexity in the use cases of Linux is driving systemd, not some desire to stifle innovation (which IMO is exactly the opposite of what systemd is doing). Our CPUs got fast enough and our use cases so diverse and network dependent (leading to lots of idle CPU time) that we stopped worrying about raw performance above all else. In nearly every case where you're not doing something glaringly stupid, performance is a function of the complexity of your problem set. Things like power consumption and safe asynchronous communication are more important than raw speed, and these things need to be coordinated through the same interfaces on every Linux machine (though not necessarily through the same methods). Systemd doesn't so much fly in the face of "open architecture" as it does introduce architectural concepts that are sufficiently abstract that much of the community doesn't fully understand them. But this is complexity for the sake of flexibility -- which is far easier to deal with than complexity for the sake of performance. Best practices around specific use cases will eventually become common knowledge.
- vezzy-fnord 11y ago
  Your implication is that sysvinit was designed for speed. I can't seem to find much evidence for that. In fact, sysvinit's purely synchronous nature and its reliance on the patterns of symlink farms to represent system states in the form of "runlevels", along with the tendency to write bloated shell scripts for it because no one ever bothered to write a proper rc/service runtime framework until much later (in contrast to the BSDs), meant it was slow. IIRC, one of the motivations for some distros to symlink /bin/sh to dash was to reduce boot times. Then we got ugly hacks like startpar for asynchronous script executions, insserv for parsing dependency directives inside scripts, and Debian had all the cruft behind sysv-rc just to make managing the runlevels easier. The whole thing descended into an unmaintainable mess that performance improvements in systemd and other alternative systems were unsurprising.
  - 11y ago

ossreality 11y ago

What a completely unsubstantiated load of FUD. >#notmylinux oh, you're just a troll. k..

cubancigar11 11y ago

ossreality you are [dead]

deleted 11y ago
[deleted]
cubancigar11 11y ago
People downmodding this have really nothing better to do?

olau 11y ago

Interesting way to think about it. IMHO systemd is taking much of the hacks and weird glue that has historically held distributions together and replaced it with an active upstream project. Maybe some of the solutions they've come up with could need some improvements, but I have much higher confidence those improvements would happen now compared to how things used to be. Nowadays you can code something up and come to the systemd mailing list and get feedback and get it integrated. Previously you'd have to convince one or more not-really-connected distro hackers that your new fancy thing is worth rocking the boat for.

weland 11y ago
Unfortunately, the systemd development team is not that easy to work with, which is part of why a lot of people distrust systemd the way they do. In theory, yes, it should be the way you mention it. In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. No one who has used more than one Linux distro would disagree that a unified system to control init services is a good idea. It's this particular implementation that's problematic, not the principle.
- madez 11y ago
  In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. Where is the evidence?
  - weland 11y ago
    All over their bugtracker, but the most famous one is here: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935
    - EmanueleAina 11y ago
      Which was ultimately caused by a bug in the kernel, and the systemd developer ultimately accepted the proposed changes just to avoid any kind of confusion (to me, it looked perfectly acceptable to parse the kernel command-line, multiple applications still do for other purposes). Arguably, the tone of the discussion resembles more the usual LKML tone rather than the one observable on the systemd mailing list.
      - yellowapple 11y ago
        I fail to see how systemd hijacking a kernel boot argument for its own purposes is a "bug in the kernel".
        11y ago

johnny22 11y ago

Definitely disagree with that. I've been using some form of a Linux based OS since 1998. Now i'm finally starting to feel like this is #mylinux.

exelius 11y ago

Once upon a time, we were obsessed with efficiency and speed of code. We created powerful, but simple systems like sysvinit, and we designed to optimize speed in 80% of use cases. The Linux you grew up with used to mostly run on x86 machines, except the majority of Linux devices now run on ARM with different power requirements, hardware, drivers, etc. than x86 ever had to deal with. The increasing complexity in the use cases of Linux is driving systemd, not some desire to stifle innovation (which IMO is exactly the opposite of what systemd is doing). Our CPUs got fast enough and our use cases so diverse and network dependent (leading to lots of idle CPU time) that we stopped worrying about raw performance above all else. In nearly every case where you're not doing something glaringly stupid, performance is a function of the complexity of your problem set. Things like power consumption and safe asynchronous communication are more important than raw speed, and these things need to be coordinated through the same interfaces on every Linux machine (though not necessarily through the same methods). Systemd doesn't so much fly in the face of "open architecture" as it does introduce architectural concepts that are sufficiently abstract that much of the community doesn't fully understand them. But this is complexity for the sake of flexibility -- which is far easier to deal with than complexity for the sake of performance. Best practices around specific use cases will eventually become common knowledge.

vezzy-fnord 11y ago
Your implication is that sysvinit was designed for speed. I can't seem to find much evidence for that. In fact, sysvinit's purely synchronous nature and its reliance on the patterns of symlink farms to represent system states in the form of "runlevels", along with the tendency to write bloated shell scripts for it because no one ever bothered to write a proper rc/service runtime framework until much later (in contrast to the BSDs), meant it was slow. IIRC, one of the motivations for some distros to symlink /bin/sh to dash was to reduce boot times. Then we got ugly hacks like startpar for asynchronous script executions, insserv for parsing dependency directives inside scripts, and Debian had all the cruft behind sysv-rc just to make managing the runlevels easier. The whole thing descended into an unmaintainable mess that performance improvements in systemd and other alternative systems were unsurprising.
- 11y ago