Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Friday February 08 2019, @05:14AM   Printer-friendly
from the it's-all-geek-to-me dept.

https://lwn.net/Articles/777595/

LWN (Linux Weekly News) provides a written account of Benno Rice's talk. The former FreeBSD core developer gives some context around systemd and what FreeBSD should learn from it. He compares the affair to a Greek tragedy which contains much suffering followed by catharsis. His attitude toward systemd is generally not negative, but I won't cherry-pick any specific sections; you'll have to actually read the article for once.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by canopic jug on Friday February 08 2019, @12:14PM (4 children)

    by canopic jug (3949) Subscriber Badge on Friday February 08 2019, @12:14PM (#798263) Journal

    From a system administration perspective, you have a monolith on your hands with systemd. Try swapping out journald or timesyncd, to pick two out of several dozen services in that systemd tarbaby. As a system administrator or home user, you should be able to swap out timesyncd for OpenNTP or NTPd, but that's not possible.

    So from an end-user or even a system administration perspective, systemd is a monolith. Sure the distro packagers have a little leeway in which to pick and choose but not so much really. Even then how many, even among those of us who can, are willing to roll their own distro just to remove a component from systemd? It's not going to happen.

    Letting them continue to lie about it being an init system doesn't help the debate. It just obfuscates the problem.

    --
    Money is not free speech. Elections should not be auctions.
    Starting Score:    1  point
    Moderation   +2  
       Insightful=2, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 2, Interesting) by pTamok on Friday February 08 2019, @01:27PM (1 child)

    by pTamok (3042) on Friday February 08 2019, @01:27PM (#798278)

    I see and agree with your point.

    However, in saying "systemd is a monolith", it allows those with a differing point of view to yours to point out that (technically) you are wrong and imply that (a) you have not investigated in sufficient depth and (b) that being wrong on such an easy point calls into question your judgement on other items.

    Asking for a stable API between the dozens of binaries that make up the systemd 'ecosystem' would be a reasonable request. Explain why the InterfaceStabilityPromise [freedesktop.org] is either incomplete or not relevant, and the same for the InterfacePortabilityAndStabilityChart [freedesktop.org].

    I know that many people find systemd's position incompatible with their requirements, but rather than just saying "it's monolithic", it really is necessary to expose just why the systemd approach causes the problems complained about. E.g. if you want or need to use a different login manager, why that is so difficult, and the consequences of various desktop environments assuming that you are using systemd.

    Don't get me wrong, I am no systemd fan, but when proponents of systemd can appear to knock down the arguments of detractors so easily, it behoves the critics to make better arguments - or agree that the systemd people are, in fact, correct.

    So systemd is not, in fact, monolithic, and it has a Interface Stability Promise. How and why is that misleading? If you cannot answer that clearly and concisely so that non-experts can understand, then perhaps some research is necessary.

    Note: if you are a software maintainer, and 90% of your users use systemd, and keeping the other 10% of your users happy will require 30% of your effort, what would you do? You can understand why preserving non-systemd choices is difficult. It is easier to just go with the flow (Those numbers are not backed up with data, but given as an example). This is why Debian choosing not to require maintainers to support a choice of inits has been so corrosive. Non-systemd choices have fallen into desuetude, quite understandably, even if regrettably.

    I sometimes wonder if systemd will, eventually, cause a fork of the kernel. Linus won't be around forever.

    • (Score: 2, Informative) by Anonymous Coward on Friday February 08 2019, @07:25PM

      by Anonymous Coward on Friday February 08 2019, @07:25PM (#798491)

      If geeks are supposed to be more meritocratic and fairer minded, the debate, and particularly the tone of it, over systemd calls that notion into question. I have not cared to personally undertake a deep investigation down to the level of reading the source, of systemd vs upstart vs runit vs sysV vs whatever. I have other technical interests I prefer to spend my limited time upon. So I have to rely upon others for analysis. It's irritating to be constantly trolled with what purports to be another somewhat analytic and unbiased piece about init systems and systemd in particular, only to find it's fluff and puff.

      My own bad experience with systemd was when Arch Linux switched to it. The manner in which they did it was terrible. How much of that was the fault of systemd is hard to say. Anyway, to update Arch during that switch, I had to enter many complicated command line instructions one after another, over a period of a few months. I feared if it didn't let up, eventually a mistake, maybe mine, or maybe with the commands, would screw up the system. And that's exactly what happened some 6 weeks into the gradual switchover. Left me with an unbootable system, and the easiest way forward was a reinstall, which I did. Stuck with Arch when I reinstalled.

      The crap Arch did was pretty bad. /var/log/syslog disappeared without notice. What they should have done was at least leave a text file at /var/log/syslog with a short explanation to redirect the administrator to the new journalctl command. Instead, I had to hunt around for an explanation of what had changed and what to do now to read the logs. Then, journalctl turned out to be a lot, lot slower, because they'd defaulted to a compressed binary log. Every time the admin needed to read the last few lines of the log, the setup imposed a long delay (5 seconds at least, even saw delays of 30 seconds) to decompress the whole log file, where before "tail /var/log/syslog" was practically instantaneous. I think Arch Linux has restored /var/log/syslog, but that was enough for me. I didn't stick around for it, I changed distros.

      The Arch Linux people were also high handed and arrogant about the change, another factor in my decision to move on to a different distro. Basically told me to shut up, I didn't know what I was talking about, the decision had been made. Love it, or leave it. So I left. That attitude has infected most of the debates I've seen about systemd.

  • (Score: 2) by The Mighty Buzzard on Friday February 08 2019, @08:09PM

    by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Friday February 08 2019, @08:09PM (#798519) Homepage Journal

    I think I'll just stick with Gentoo or Gentoo-based distros. You don't get a modular pick and choose of components but you do get to decide if you want it or don't want it and you don't have to give up much of anything if you decide you'd rather go OpenRC as they do a pretty good job of unfucking packages that have decided systemd should be a requirement.

    --
    My rights don't end where your fear begins.
  • (Score: 0) by Anonymous Coward on Sunday February 10 2019, @08:23AM

    by Anonymous Coward on Sunday February 10 2019, @08:23AM (#799040)

    > Try swapping out journald or timesyncd, to pick two out of several dozen services in that systemd tarbaby.

    That's trivial:

    systemctl disable systemd-timesyncd; systemctl stop systemd-timesyncd

    Then install ntpd or whatever you want as an alternative.