Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Monday December 30 2019, @12:23PM   Printer-friendly
from the not-all-systemd-really dept.

Earlier this month we covered a story where we quoted the following:

Due to Debian developers having differing opinions on handling non-systemd bugs in 2019 and the interest/commitment to supporting systemd alternatives in the scope of Debian packaging and various related friction points, they've taken to a new general resolution over weighing init system diversity.

The results of the ballot to discover how the Debian devs feel about their earlier decision with the benefit of hindsight is now in:

Using its power under Constitution section 4.1 (5), the project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus.

The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.

Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.

Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.


Original Submission

Related Stories

Debian Developers Take to Voting Over Init System Diversity 143 comments

Debian Developers Take To Voting Over Init System Diversity

It's been five years already since the vote to transition to systemd in Debian over Upstart while now there is the new vote that has just commenced for judging the interest in "init system diversity" and just how much Debian developers care (or not) in supporting alternatives to systemd.

Due to Debian developers having differing opinions on handling non-systemd bugs in 2019 and the interest/commitment to supporting systemd alternatives in the scope of Debian packaging and various related friction points, they've taken to a new general resolution over weighing init system diversity.

The ballot is available on-line. The choices are:

Choice 1: F: Focus on systemd
Choice 2: B: Systemd but we support exploring alternatives
Choice 3: A: Support for multiple init systems is Important
Choice 4: D: Support non-systemd systems, without blocking progress
Choice 5: H: Support portability, without blocking progress
Choice 6: E: Support for multiple init systems is Required
Choice 7: G: Support portability and multiple implementations
Choice 8: Further Discussion

[Ed. note: I'm not sure what the letters after the choice numbers indicate, nor do I know where "C" disappeared to.]


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.
(1)
  • (Score: 5, Insightful) by Anonymous Coward on Monday December 30 2019, @12:37PM (10 children)

    by Anonymous Coward on Monday December 30 2019, @12:37PM (#937439)

    Translation: nothing changed.

    • (Score: 0, Insightful) by Anonymous Coward on Monday December 30 2019, @12:47PM (1 child)

      by Anonymous Coward on Monday December 30 2019, @12:47PM (#937440)

      Yup. Debian is open.... but allowed to descrimates in case by case based. I also read “give us money to support your changes”. A open closed system

      • (Score: 3, Disagree) by janrinok on Monday December 30 2019, @07:47PM

        by janrinok (52) Subscriber Badge on Monday December 30 2019, @07:47PM (#937582) Journal

        They can do as they choose. They benefit from systemd - the fact that you or I might not isn't the issue. There is nothing to prevent you from starting your own distro, is there?

    • (Score: 2, Insightful) by Anonymous Coward on Monday December 30 2019, @12:58PM (2 children)

      by Anonymous Coward on Monday December 30 2019, @12:58PM (#937443)

      It's a volunteer organization. We have no right to demand they support anything. I am all for init system diversity - I have GNU Guix (running GNU Shepherd init) and Void Linux (running runit) in VMs right now. But I'm not donating enough to the Debian project to ask them to support either and I don't have the time to - try to - flesh out support for them in Debian myself.

      When somebody dumps a fifty million dollar grant on the Debian foundation, then we can start screaming for alternate init support.

      • (Score: 5, Insightful) by Arik on Monday December 30 2019, @01:53PM (1 child)

        by Arik (4543) on Monday December 30 2019, @01:53PM (#937464) Journal
        When Poettering dumps a fifty million dollar grant on the Debian foundation, then it would make some sense for them to assault their users with systemd.
        --
        If laughter is the best medicine, who are the best doctors?
        • (Score: 1, Funny) by Anonymous Coward on Monday December 30 2019, @02:43PM

          by Anonymous Coward on Monday December 30 2019, @02:43PM (#937477)

          If this is true, did they check the bills? I mean it wasn't Gates face printed on them was it?

    • (Score: 5, Interesting) by Bot on Monday December 30 2019, @01:31PM (1 child)

      by Bot (3902) on Monday December 30 2019, @01:31PM (#937451) Journal

      I think they have a cunning plan:

      -devuan
      -wat
      -we support systemd alternatives nao
      -orly
      -yarly, come back to mommy and help us
      -wait a sec... aaaagh *splits*... ok
      -fine so, can i haz debs
      -here, these are working debs
      -sure but we have to QA them
      *time passes*
      -debian
      -wat
      -what about our debs
      -they are ready, we merge them tomorrow
      -great
      -the day after tomorrow a new debian version is out tho, looks like you gotta port them all har har har
      -oh i recognize this feeling of helpnesses, it's like...
      -we call it systemdinitis. a variant of windowsitis. Always reinventing stuff so we can get jobs adminning and certificating. It gets to the soul, after a while, you see, and you feel nothing.

      --
      Account abandoned.
    • (Score: -1, Troll) by Anonymous Coward on Monday December 30 2019, @02:39PM (2 children)

      by Anonymous Coward on Monday December 30 2019, @02:39PM (#937475)

      Actually quite a lot has changed, but more so everywhere other than Debian.

      It would be nice if distro watch kept a metric on lib the number of lib versions that are most current. As in which distros are most up to date. If your interested in security, this is important. As I recall Debian would not very often be the leader in that particular metric.

      • (Score: 5, Insightful) by Arik on Monday December 30 2019, @02:57PM (1 child)

        by Arik (4543) on Monday December 30 2019, @02:57PM (#937482) Journal
        "It would be nice if distro watch kept a metric on lib the number of lib versions that are most current. As in which distros are most up to date. If your interested in security, this is important. As I recall Debian would not very often be the leader in that particular metric. "

        That's been a very unfair metric to judge Debian by historically.

        Back in the days when I last used it, they would maintain a stable branch which was an excellent way to do it. Security fixes were backported, but new features aka bug nests were not. That would flunk your silly test every time, but that's ok - because your test IS silly.
        --
        If laughter is the best medicine, who are the best doctors?
        • (Score: 0) by Anonymous Coward on Tuesday December 31 2019, @02:50AM

          by Anonymous Coward on Tuesday December 31 2019, @02:50AM (#937706)

          If you want a more accurate picture of Debian's security status: https://security-tracker.debian.org/tracker/ [debian.org] (and many other distros have similar security trackers). That allows you to search by package or release. The frustrating thing about it is that you can sometimes run into exploits that are patched on an earlier release but vulnerable on a later one because of the backport system for security patches.

  • (Score: 5, Insightful) by aim on Monday December 30 2019, @01:27PM (2 children)

    by aim (6322) on Monday December 30 2019, @01:27PM (#937449)

    The result isn't exactly suprising, considering those insisting on other init systems already left Debian. Witness Devuan.

    • (Score: 2) by Pav on Monday December 30 2019, @05:09PM

      by Pav (114) on Monday December 30 2019, @05:09PM (#937528)

      Doesn't MX Linux (supposedly the most popular Linux out there right now) also support freedom from systemd? They default to using the shim though, and haven't removed it completely.

    • (Score: 3, Informative) by VLM on Tuesday December 31 2019, @01:53PM

      by VLM (445) Subscriber Badge on Tuesday December 31 2019, @01:53PM (#937824)

      True although I'd "embrace and extend" your remarks with a side dish of FreeBSD.

      Which also comes with delicious native ZFS support. IPFW seems to "feel" better in my head after getting use to it. I've not used GEOM because I mirror at the ZFS level, but I'm told its better than linux SW raid.

  • (Score: 0) by Anonymous Coward on Monday December 30 2019, @01:36PM (41 children)

    by Anonymous Coward on Monday December 30 2019, @01:36PM (#937454)

    So, where can I read a good "systemd for dummies" getting started guide?

    • (Score: 5, Funny) by Anonymous Coward on Monday December 30 2019, @01:44PM (2 children)

      by Anonymous Coward on Monday December 30 2019, @01:44PM (#937459)

      Try "How I Fucked up Linux" by Lennart Poettering.

      • (Score: 0) by Anonymous Coward on Monday December 30 2019, @09:53PM

        by Anonymous Coward on Monday December 30 2019, @09:53PM (#937615)

        Lennart Poettering is the Donald J Trump of Linux.

      • (Score: -1, Flamebait) by Ethanol-fueled on Tuesday December 31 2019, @12:55AM

        by Ethanol-fueled (2792) on Tuesday December 31 2019, @12:55AM (#937670) Homepage

        Shuttleworth arguably did more to fuck Linux than even Poettering, but one thing that we can all agree on was that too much security and functionality while being free wasn't in-line with the Jewish business model, so now Linux is shit and even modern distros have all the suck of Windows -- except that Windows can actually install without kernel hacking and the risk of nuking all your drives.

    • (Score: 5, Insightful) by barbara hudson on Monday December 30 2019, @01:58PM (35 children)

      by barbara hudson (6443) <barbara.Jane.hudson@icloud.com> on Monday December 30 2019, @01:58PM (#937465) Journal

      You can't. And that, in their minds, is a feature , not a bug.

      This was predicted by the more cynical; that you have to be a hardened cynic to understand what's going on behind the scenes is an indicator of just how corporate it's all become.

      2020 - where Linux isn't Unix, it isn't even Linux any more.

      --
      SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
      • (Score: 5, Insightful) by epitaxial on Monday December 30 2019, @03:18PM (9 children)

        by epitaxial (3165) on Monday December 30 2019, @03:18PM (#937486)

        I've used *BSD and Linux since 1996 or so and SunOS before that. I got away from Linux in the early 2000s and kept my server running BSD in one form or another. Not having touched Linux in a decade and trying to use it was incredibly frustrating. All of /etc has changed several times over and documentation is a mess. Trying to get a simple script to run at startup with systemd wasted hours of time. I decided to get back into Linux because of Windows 7 support ending. My existing Windows install will be moved to a VM to be run inside Linux. I wouldn't mine using OSX but building a hackintosh is exactly that, a hack. There is no guarantee Apple won't flip the switch one day and OSX will need a T2 chip to boot.

        Modern day Linux bears little resemblance to its ancestor and I really don't like the direction of abstraction layers upon abstraction layers. Meanwhile *BSD is still chugging along stable as ever and with good documentation.

        • (Score: 2) by isostatic on Monday December 30 2019, @03:29PM (4 children)

          by isostatic (365) on Monday December 30 2019, @03:29PM (#937489) Journal

          /etc/rc.local still seem to work for me

          /etc/init.d and update-rc.d still seem to work for me

          • (Score: 2) by epitaxial on Monday December 30 2019, @04:28PM

            by epitaxial (3165) on Monday December 30 2019, @04:28PM (#937508)

            No such luck on Ubuntu. I have to use it for my job.

          • (Score: 3, Informative) by mmlj4 on Monday December 30 2019, @05:36PM

            by mmlj4 (5451) on Monday December 30 2019, @05:36PM (#937533) Homepage

            You sometimes (depending on distro, the phase of the moon, etc.) have to tell systemfaild to actually run /etc/rc.local, else it just mocks you.

            --
            Need a Linux consultant [joeykelly.net] in New Orleans?
          • (Score: 2, Informative) by Anonymous Coward on Monday December 30 2019, @06:16PM

            by Anonymous Coward on Monday December 30 2019, @06:16PM (#937548)

            Depending on the distro there may or may not be a shim for rc.local and it may or may not be enabled by default, but there is a major semantic change in the meaning of rc.local from previous linux norms. Previously, most linux distros ran rc.local after the "normal" startup scripts and before starting the login gettys, but systemd runs rc.local at a random point interleaved with the "normal" startups. Anyone foolish enough to request an option to run a startup in serial instead of in parallel will be eviscerated by the high priests of poettering.

            (There is an ugly hack to simulate the old behavior; essentially by manually creating a new "run-level" with just rc.local and a dependency on the old default target.)

          • (Score: 2) by DeVilla on Wednesday January 01 2020, @03:39PM

            by DeVilla (5354) on Wednesday January 01 2020, @03:39PM (#938228)

            /etc/init.d keeps getting less and less reliable in RHEL. (Even prior to them shipping systemd.) We ship a product with an init script that worked on multiple distros. Every few point releases something would change in RHEL to break it. In the pre-RHEL7 releases they would say they had a bug in their LSB support that seemed to never get fixed. In RHEL7 and on, Redhat would tell us that what ever it was we were doing "never worked" and we need to fix it. A few point releases into RHEL7.x we gave up and create a unit file for RHEL7+ and used the init script everywhere else.

        • (Score: 5, Informative) by Anonymous Coward on Monday December 30 2019, @06:20PM (1 child)

          by Anonymous Coward on Monday December 30 2019, @06:20PM (#937551)

          Debian, OpenSuSE, Redhat/RHEL/CentOS/Fedora are all burned. Hell, most don't even support x86 anymore.

          Linux itself has deprecated floppy support, which most might scoff at, but if you have a Pentium Pro or earlier system may be mandatory to install, even if transferring files can be done over ethernet/cdrom/usb later.

          A more important aspect of this is Linux is giving up its roots, which were supporting every peice of hardware they could. And that drop in support is mainly due to shoddy software engineering principles. ABIs for most of the legacy hardware should be stabilitized by now. There should be *NO* maintenance or testing burden to keep them supported because NONE OF IT SHOULD CHANGE. The only reason most of it is breaking now is the NOHZ crap and the push for containerization, both of which are makign architectural changes inside the kernel that are likely going to prove security exploit central for the next two decades.

          In the meantime it may be necessary to fork linux, stabilize the ABIs for legacy busses and system architectures, then have an API compatible kernel in place for newer hardware which can eschew legacy hardware that doesn't exist for it while allowing reuse of the subset of drivers which would be compatible with both platforms. There may be stub/noops of some features, but if it''s properly implemented testing for both legacy and modern playforms shouldn't require more than a half dozen systems, with maybe the odd system here and there for complicated errata (say the old faulty integrated IDE controllers, or some of the more fucked up modern Intel CPUs on boards with efused bios rollback 'protection'.)

          • (Score: 4, Interesting) by Grishnakh on Tuesday December 31 2019, @03:32AM

            by Grishnakh (2831) on Tuesday December 31 2019, @03:32AM (#937727)

            >In the meantime it may be necessary to fork linux, stabilize the ABIs for legacy busses and system architectures

            Forking an OS kernel as large and complex as Linux is a huge task. Who exactly is going to either pay for this, or volunteer their time, just to maintain a fork for obsolete hardware that almost no one uses any more? What's the point?

            If you really want to keep running Linux on your Pentium Pro with a floppy drive, nothing is stopping you from using some circa-2002 Linux distro.

            Just look at the Devuan distro for an example of this. They're not forking Linux, they're just trying to maintain a parallel fork of Debian that doesn't have systemd. And they can't find enough help to do it.

        • (Score: 1) by zion-fueled on Tuesday December 31 2019, @02:21AM (1 child)

          by zion-fueled (8646) on Tuesday December 31 2019, @02:21AM (#937699)

          I'm not a fan of systemd but setting it up wasn't hard. I easily found a solution to run a script at startup, 5 minutes. The other shit like dbus security profiles was what took hours because it's not documented. You can spin up a crappleOS instance as much as linux or anything else. They all have spyware now and are vulnerable to going out of support or doing something shitty.

          If you like BSD, why not just use it. They have window managers, wine, packages, etc.It all should theoretically work. Maybe you'll have to build a few more things from source but so what.

          • (Score: 0) by Anonymous Coward on Tuesday December 31 2019, @07:59AM

            by Anonymous Coward on Tuesday December 31 2019, @07:59AM (#937792)

            Let's see how you go when something breaks.
            Good luck.
            Keep that install usb handy.

      • (Score: 5, Informative) by digitalaudiorock on Monday December 30 2019, @05:02PM

        by digitalaudiorock (688) on Monday December 30 2019, @05:02PM (#937522) Journal

        I wish I could mod this +6. I can't imagine the sysadmins out there that have had to relearn shit that's worked in unix/Linux forever because of this RH/LP pollution...and yes, that IS their plan...to make Linux RH's Windows. The fact that systemd is "open source" is also totally irrelevant, and doesn't help anything or anyone. I've seen other refer to it as "proprietary open source" which pretty much nails it.

        I'm glad that I've been able to avoid it all. I use all Gentoo for my own machines and my company moved from CentOS 6 to Devuan...not a trace of that bullshit in my life and no plans of ever allowing it. The idea of systemd especially on an (otherwise lean) headless server is unimaginable to me. Hell...we don't even have or need fucking dbus on any of ours, let alone that cluster fuck of an attack surface. The maintainers at Devuan really are fighting the good fight for sure. I'm not sure this vote changes the nature of their battle at all.

      • (Score: 5, Interesting) by bzipitidoo on Monday December 30 2019, @06:24PM (14 children)

        by bzipitidoo (4388) on Monday December 30 2019, @06:24PM (#937555) Journal

        Shit documentation, that's for sure!

        I was using Arch Linux when they switched to systemd. What a mess! Months of changes that their update system could not handle. Instead, the system admins were expected to enter long, complicated commands into the terminal, by hand. It went okay for a while, but I grew worried that if they didn't let up with the manual updates, eventually, I'd get something wrong, with catastrophic consequences. And sure enough, that's what happened, leaving me with an unbootable system. I worked around that by reinstalling Arch from the latest installation media.

        When I took a look at /var/log/syslog I found it was gone! What the Hell? Had something deleted it? Was some bug responsible? After considerable hunting for an explanation, and wondering if I ought to submit a bug report, I learned it was no accident. No, in switching to systemd, Arch had changed the whole logging system. System messages were now being logged by a piece of systemd, and being stored in a binary format in a slightly different place, a subdirectory of /var/log/. Bastards didn't have the courtesy to at the very least leave an explanation in /var/log/syslog. To access the messages, had to use journalctl. Couldn't use tail any more. Another very bad effect was that what formerly was near instantaneous, reading the last few entries in syslog, now took a full 30 seconds. My guess is that the binary format had to be decoded from start to end each time an admin wanted a peek at the latest messages. Even so, 30 seconds was an extraordinary long time. gzip sure as heck doesn't need that much time to decompress even a 100M log file, and I wondered what on Earth systemd could possibly be doing to make fetching the logs so incredibly slow. It pointed to grossly inefficient code and a bad design. I have also heard that systemd's logging is unreliable, and may drop messages, or even corrupt the log file.

        The attitude of the Arch Linux maintainers was supercilious. "We know what's best and you don't, we've already discussed systemd and decided to switch, we're not interested in further discussion and might even ban you from the forums for being critical, and if you don't like it, tough." So I ditched Arch.

        To be fair, the mess they made of the system logging was not entirely any one group's fault. I suspect systemd developers recommended that change to message logging, and Arch was overly trusting. Now what you find in most systemd installations is that /var/log/syslog is back as if it never went missing in the first place. Binary logging is still an option, but it's not the default any more.

        Still, the botching of logging is no fluke, it's representative. Systemd was rushed out the door. Its design was not reviewed adequately. It violates a core tenet of UNIX, that of modularity, of having many simple tools instead of a few complicated tools.

        I have continued to use systemd not out of choice, but because it's all over the place and difficult to avoid. The main issue I've run into with Void Linux is that it's not turnkey enough. When you have limited time to get a laptop up and running, you don't want to have to fool around with setting up a WiFi system. So far, systemd in Ubuntu Linux and derivatives has not given me any trouble. But neither have I ever stressed it. Work the system hard, and who knows what will happen?

        Documentation continues to be poor. What does systemd do for you that sysv did not? Because it's much more parallel, it boots faster, that's about it? Nice for portable computers, but how very useless in the server room. And for that, I have to learn new, systemd specific ways of doing everything? To set up a computer with a static IP address is different in systemd, why? Not worth it!

        • (Score: 5, Interesting) by digitalaudiorock on Monday December 30 2019, @06:47PM (10 children)

          by digitalaudiorock (688) on Monday December 30 2019, @06:47PM (#937562) Journal

          Documentation continues to be poor. What does systemd do for you that sysv did not? Because it's much more parallel, it boots faster, that's about it?

          I'd argue that even that parallel boot nonsense is BS that's mostly been debunked. I have an archaic x86 system running Gentoo with openrc that can boot to a working desktop in about 40 seconds including everything needed to to LAMP development. What's to fix there, and how fast would that be on any remotely modern hardware?

          I'd argue that there simply was never any design plan for systemd to begin with...just a "how tough could it be?" attitude. That is, no real plan as to how it was even supposed to work. I've posted links to this before, and it's quite an eye opener. It's a very non-political assessment of systemd architecture:

          https://blog.darknedgy.net/technology/2015/10/11/0/ [darknedgy.net]

          Speaking of parallel startup, just as I was saying about having no real design...read the section there titled "Imbalance between promoting laziness or eagerness".

          • (Score: 2) by janrinok on Monday December 30 2019, @07:56PM (8 children)

            by janrinok (52) Subscriber Badge on Monday December 30 2019, @07:56PM (#937585) Journal

            Because it's much more parallel, it boots faster, that's about it?

            That is exactly it - it is essential for spinning up multiple copies in the cloud on demand. It isn't designed for the home user , although it works as well as any other init system in my opinion, but for use in the cloud it is very useful indeed.

            • (Score: 0) by Anonymous Coward on Monday December 30 2019, @09:32PM (3 children)

              by Anonymous Coward on Monday December 30 2019, @09:32PM (#937604)

              Cause it's vitally important that I can spin up multiple copies in the cloud on demand every minute and ... how does SystemD even help here?

              • (Score: 3, Informative) by janrinok on Tuesday December 31 2019, @08:08AM (2 children)

                by janrinok (52) Subscriber Badge on Tuesday December 31 2019, @08:08AM (#937794) Journal

                Systemd helps in many different ways for cloud software.

                Firstly, it 'knows' which services each program relies upon. If a service fails temporarily - e.g. networking - it can automatically restart all the programs that crashed when the failure occurred without any intervention from a human. It also knows which services depend upon others so it can start them in an effective manner, either in parallel if they have no interdependencies, or sequentially in the correct order. In the cloud it also means that an instance can be stopped, moved elsewhere, and restarted if hardware fails on one server.

                You might only want one a single instance of software starting on a server, but many cloud systems (AWS etc) are starting and stopping instances counted in their thousands or more all the time. They have to do this efficiently, meet a changing customer demand, and ensure that costs are kept to a minimum. The customer does not want to pay for time that he cannot use.

                None of these issues are of vital importance to the home or small business user. But, for Debian to survive (and for many other distros too) it was important that they remained viable for cloud computing. Very few distros can afford to just appeal to a niche user group if they want to be a major player with sufficient funds to pay for the support that such a distro needs.

                However, systemd does work on home computers. I've been using it on some of the machines that I support, although I also use some non-systemd distros too. For example, I have remote systems based on RaspPi that use an SDR to monitor specific frequencies used by aircraft. They do, occasionally, suffer from a network problem that is caused that is caused by an unidentified short-term (5-10 minutes) burst of local RF interference. systemd notices when this happens, waits for the problem to cease, and then restarts the relevant software (and any other services that have been affected) to continue to do the job it is intended to do. I currently have several such systems situated within a few kilometers from where I live. It would be cumbersome to say the least if I had to visit each one every time the problem occurred.

                Finally - and this is no different from other init systems - systemd provides a logical standard way of setting up new services. The documentation is full of new terminology but, once you grep what it actually means, it all seems (to me at least) quite logical and straightforward. I have read of all the potential problems that systemd presents but, after 5 years of use, I have not experienced a single one of them. I'm sure others have, but the same could be said of almost any piece of software that is in regular use. Find me one that doesn't have a bug and I will find you one that probably hasn't been fully tested either.

                There is nothing to prevent anyone from using a different distro if they do not want to bother to learn systemd. But there are hundreds of thousands of home users who rely upon it everyday without many of them being aware that it is even installed on their computer. It just works. If you want to use your computer to do things rather than learn what is going on under the hood, you can quite happily forget about systemd and carry on doing whatever it is that you want to do.

                • (Score: 0) by Anonymous Coward on Tuesday December 31 2019, @03:19PM (1 child)

                  by Anonymous Coward on Tuesday December 31 2019, @03:19PM (#937840)

                  I find that claim to be utterly hilarious, especially given your choice of example. The single issue I've seen the most with systemd is networking startup issues, where it fucks up starting the network and gives up entirely, freezing the boot until I manually intervene. I have literally never seen it recover gracefully from a network issue greater than a link flap.

                  • (Score: 1, Flamebait) by janrinok on Tuesday December 31 2019, @03:58PM

                    by janrinok (52) Subscriber Badge on Tuesday December 31 2019, @03:58PM (#937863) Journal

                    Dear AC - you seem to have missed the point that I have not experienced any of these problems. I didn't say that nobody had.

                    So you think that the many millions of Ubuntu, Debian, Mint or whatever other systemd distros are using them because they don't work? Perhaps you have a special use case that causes such problems - the vast majority of users do not have the same experience as you it seems.

                    The single issue I've seen the most with systemd is networking startup issues, where it fucks up starting the network and gives up entirely, freezing the boot until I manually intervene.

                    So the single issue that you have seen the most is happening on the machines that you manage, and you have to manually intervene? I can see a common link here..., and it is not systemd.

            • (Score: 0) by Anonymous Coward on Tuesday December 31 2019, @03:04AM (3 children)

              by Anonymous Coward on Tuesday December 31 2019, @03:04AM (#937712)

              Even systemd recommends against using systemd for single-purpose VMs or containers. They use a specially designed stub init for that. Not to mention most orchestration software requires special configuration options for systemd if you were going to use it anyway.

              • (Score: 0) by Anonymous Coward on Tuesday December 31 2019, @08:04AM (2 children)

                by Anonymous Coward on Tuesday December 31 2019, @08:04AM (#937793)

                then why in all heck is it on Ubuntu? A desktop OS??

                • (Score: 2, Informative) by r_a_trip on Tuesday December 31 2019, @03:56PM

                  by r_a_trip (5276) on Tuesday December 31 2019, @03:56PM (#937861)

                  Ubuntu is big in cloud computing. Desktop has long since become a byproduct.

                • (Score: 0) by Anonymous Coward on Wednesday January 01 2020, @01:05AM

                  by Anonymous Coward on Wednesday January 01 2020, @01:05AM (#938092)

                  Maybe because a desktop operating system is designed for a desktop, which definitely isn't a single application VM or in a container. Not to mention, the most common desktop environment has multiple dependencies on the systemd ecosystem.

          • (Score: 2) by Runaway1956 on Thursday January 02 2020, @09:43AM

            by Runaway1956 (2926) Subscriber Badge on Thursday January 02 2020, @09:43AM (#938536) Journal

            I've waded into that link. It gets deep. I'm running out of time, so skipped to the conclusion. That summation pretty clearly states what I've often heard, and in some cases experienced. My long holiday is ending, but I hope to find time to follow links and citations, to understand it better!

            In conclusion

            The typical interpretations of systemd all suffer from incompleteness and conceptual mismatch. The definition of systemd proposed herein is a superior model for examining and drawing remarks from the systemd architecture.

            Despite its overarching abstractions, it is semantically non-uniform and its complicated transaction and job scheduling heuristics ordered around a dependently networked object system create pathological failure cases with little debugging context that would otherwise not necessarily occur on systems with less layers of indirection. The use of bus APIs complicate communication with the service manager and lead to duplication of the object model for little gain.

            Further, the unit file options often carry implicit state or are not sufficiently expressive. There is an imbalance with regards to features of an eager service manager and that of a lazy loading service manager, having rusty edge cases of both with non-generic, manager-specific facilities. The approach to logging and the circularly dependent architecture seem to imply that lots of prior art has been ignored or understudied.

            To sum it up even more succinctly, it's something of a kludge. When SystemD doesn't do what is expected, someone shims it somehow, with little regard to "standards", then generally fails to document it.

        • (Score: 0) by Anonymous Coward on Monday December 30 2019, @10:11PM (1 child)

          by Anonymous Coward on Monday December 30 2019, @10:11PM (#937620)

          The binary logs are still there. Now systems do both by default in most distros because of the fallout. And the design of journalctl/journald originally didn't have an index which was later claimed to be because of its append-only design. Wanted to actually read your logs? Better be prepared to scan the whole thing from disk. They have, over time, made it more performant, resistant to corruption, and added various fallback behaviors when the quick ways fail, but still not bulletproof, despite its append-only design.

          Here is the thing though, there was no need to reinvent the wheel that way. Instead of rolling your own database engine, just use SQLite. Quick and reliable. It also has multiple modes (single exclusive writer process and WAL) to speed up accesses and reducing writes while still having the ACID guarantees. Not to mention the maturity, full indexes, database relations, extensiblity, and all the other features SQLite brings you.

          • (Score: 0) by Anonymous Coward on Tuesday December 31 2019, @05:03PM

            by Anonymous Coward on Tuesday December 31 2019, @05:03PM (#937904)

            But is SQLite webscale? Databases need to be webscale even if just used locally.

        • (Score: 2) by Runaway1956 on Tuesday December 31 2019, @04:31PM

          by Runaway1956 (2926) Subscriber Badge on Tuesday December 31 2019, @04:31PM (#937881) Journal

          I'm a neophyte, TBH, but I've had troubles that you seem to describe here. Do an internet search for help on a problem, and most times you're told to "check the logs". Run the command to read the log (tail, grep, whatever) in question, and it don't work!! It leaves a guy feeling like an idiot, and asking himself why he put any faith in 2, 6, or 12 year old documentation. :^( Of course, searching for recent documentation almost always sends you to systemd-centric sites.

      • (Score: 2) by Bot on Monday December 30 2019, @06:52PM (8 children)

        by Bot (3902) on Monday December 30 2019, @06:52PM (#937566) Journal

        >This was predicted by the more cynical;

        It also was announced by the guy who wrote it. "never finished, never complete, but tracking progress of technology" according to wikipedia. Basically the satanic inversion of "do one thing and do it well".

        --
        Account abandoned.
        • (Score: 4, Insightful) by barbara hudson on Monday December 30 2019, @07:09PM (6 children)

          by barbara hudson (6443) <barbara.Jane.hudson@icloud.com> on Monday December 30 2019, @07:09PM (#937576) Journal

          The vote was rigged - the question was designed to limit the answers to the ones they wanted. This is dishonesty. Debian can no longer claim any sort of ethical high ground when rigging a vote on such an issue.

          Then again, are they even relevant any more? If they disappeared tomorrow, what would change? The distros that base off it would just rebase off another distro, or directly incorporate software updates from sources instead of going through debian.

          Seriously, the can now go DIAF for all the difference it would make.

          --
          SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
          • (Score: 0, Disagree) by Anonymous Coward on Monday December 30 2019, @10:36PM (5 children)

            by Anonymous Coward on Monday December 30 2019, @10:36PM (#937628)

            no it was not rigged. Unfortunate perhaps, but not rigged.

            The options were provided by debian devs for debian devs. There is little you can do to rig things there.

            • (Score: 3, Insightful) by barbara hudson on Monday December 30 2019, @11:44PM (1 child)

              by barbara hudson (6443) <barbara.Jane.hudson@icloud.com> on Monday December 30 2019, @11:44PM (#937651) Journal
              Where's the option to make systems an install-time option? Or the one to drop it entirely?

              The fact that you say it was "made by Debian devs for Debian devs" shows that as the poll was drawn up it was already decided that these weren't going to ever be considered. Rigged poll because they were afraid that dropping systemd might have won.

              --
              SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
              • (Score: 1, Informative) by Anonymous Coward on Tuesday December 31 2019, @03:03AM

                by Anonymous Coward on Tuesday December 31 2019, @03:03AM (#937711)

                And there lies the problem, they don't care much anymore about the community or users mentioned in the Debian Social Contract. It should never be "for Debian devs" if they still followed the Contract.

                It is getting even worse than Enlightened Absolutism and its "everything for the people, nothing by the people". They don't care and they don't change their propaganda.

            • (Score: 4, Insightful) by toddestan on Tuesday December 31 2019, @03:37AM (2 children)

              by toddestan (4982) on Tuesday December 31 2019, @03:37AM (#937729)

              It was a biased pole. Just look at the options:

                      Choice 1: F: Focus on systemd
                      Choice 2: B: Systemd but we support exploring alternatives
                      Choice 3: A: Support for multiple init systems is Important
                      Choice 4: D: Support non-systemd systems, without blocking progress
                      Choice 5: H: Support portability, without blocking progress
                      Choice 6: E: Support for multiple init systems is Required
                      Choice 7: G: Support portability and multiple implementations

              Anyone who likes systemd is going to pick the first choice, or maybe the second. People who don't like systemd are going to split their vote among the latter five. In a simple vote where the most number of votes wins, the choice that doesn't split up the votes is going to be favored. And that's exactly what happened.

        • (Score: 2) by Thexalon on Tuesday December 31 2019, @03:57PM

          by Thexalon (636) on Tuesday December 31 2019, @03:57PM (#937862)

          The best part of "never finished, never complete" is that it means that Lennart is never unemployed. Which I'm convinced was part of the point of the exercise.

          --
          The only thing that stops a bad guy with a compiler is a good guy with a compiler.
    • (Score: 2) by janrinok on Monday December 30 2019, @07:52PM

      by janrinok (52) Subscriber Badge on Monday December 30 2019, @07:52PM (#937584) Journal
    • (Score: 2) by fido_dogstoyevsky on Tuesday December 31 2019, @12:56AM

      by fido_dogstoyevsky (131) <axehandleNO@SPAMgmail.com> on Tuesday December 31 2019, @12:56AM (#937673)

      So, where can I read a good "systemd for dummies" getting started guide?

      Here you go [amazon.com].

      --
      It's NOT a conspiracy... it's a plot.
  • (Score: -1, Redundant) by Anonymous Coward on Monday December 30 2019, @01:49PM (1 child)

    by Anonymous Coward on Monday December 30 2019, @01:49PM (#937461)

    That is all.

    • (Score: 0) by Anonymous Coward on Monday December 30 2019, @09:08PM

      by Anonymous Coward on Monday December 30 2019, @09:08PM (#937597)

      Is that German for "The SystemD The"?

  • (Score: -1, Redundant) by Anonymous Coward on Monday December 30 2019, @02:05PM

    by Anonymous Coward on Monday December 30 2019, @02:05PM (#937466)

    nuff said.

  • (Score: 4, Insightful) by Anonymous Coward on Monday December 30 2019, @02:38PM (5 children)

    by Anonymous Coward on Monday December 30 2019, @02:38PM (#937474)

    ...considering their ballot item list of “choices” was generated by an indecisive Adderall-addled ass-burger who could not possibly conceive of the concept of “choice” itself.

    What they presented all but guaranteed there would be no clear majority, which I suspect was the goal.

    • (Score: 1, Interesting) by Anonymous Coward on Monday December 30 2019, @10:31PM (4 children)

      by Anonymous Coward on Monday December 30 2019, @10:31PM (#937625)

      look, i am not particularly fond of systemd and personally run and like Devuan, but this is just FUD, and should not be modded up.

      Every debian developer could submit an option to the ballot. Many did, and several of the DPL options were replaced. The vote was not "rigged" (the worse I could say is that it was hurried). It was also not a matter of diluting votes as that is not really possible with their voting system.

      I think the reality is that there is a significantly large number of active developers who rabidly like systemd. I suspect it is in part BECAUSE systemd got so much hate in the past, that they now think every argument against systemd is made by trolls. There is still a relatively large group of people thinking alternatives ARE important, and this let to the current unsatisfactory compromise (if it had been a yes/no vote on systemd only, it would probably have gone through, and the large minority would have gone completely unheard).

      I think the tragedy here is that everybody loses. The option gives a lot of room for future conflict on how to deal with patches regarding alternative init support. Users and some devs may go to other distro's, but it will be quite hard for Devuan and MX to survive if Debian drops alternative init systems (they do not have the manpower to fix all the issues). Lock-in into systemd will complicate portability and flexibility for debian itself, but such issues will take time to manifest and then it will be to late to handle it (or even realize what has been done). What SHOULD have happened is the definition of an init API that all software init alternatives must conform to. This would allow alternative options to thrive as long as they provide the same inferfaces. Unfortunately systemd upstream refuses this (but I would have liked debian to at least attempt to throw their weight around here, rather than accepting that).

      • (Score: 0) by Anonymous Coward on Tuesday December 31 2019, @12:54AM

        by Anonymous Coward on Tuesday December 31 2019, @12:54AM (#937669)

        Look, I wasn’t expressing so much that there was actually some dark conspiracy going on so much as that the incompetence of the poll was so breathtakingly evident as to be indistinguishable from malice.

        That you have been so personally *offended* at that suggestion that catering to every tediously nuanced difference of expressing the same goddamned thing is precisely the attitude I was ascribing to being crippled by a toxic intersection of ADHD and amphetamines.

      • (Score: 0) by Anonymous Coward on Tuesday December 31 2019, @03:49AM

        by Anonymous Coward on Tuesday December 31 2019, @03:49AM (#937734)

        Debian uses the Schulze method, which is does not have the later-no-harm or later-no-help criteria. This makes the true preference vulnerable to burying through strategic voting, which happened last time by accident. Literally almost any switch of any two options in the vote by anyone, and systemd would have been eliminated as an option and Debian would have adopted Upstart.

      • (Score: 0) by Anonymous Coward on Tuesday December 31 2019, @08:10AM (1 child)

        by Anonymous Coward on Tuesday December 31 2019, @08:10AM (#937795)

        No, those options are screwy. Someone trying to rig a vote.

        Compare to:

        Option 1: Keep systemd as the init system
        Option 2: Change to multi init system support
        Option 3: Reject systemd and choose another init system as the default

        Very simple. Easy to understand. If Option 3 wins, then systemd gets the boot. Done.

        • (Score: 0) by Anonymous Coward on Tuesday December 31 2019, @07:29PM

          by Anonymous Coward on Tuesday December 31 2019, @07:29PM (#937976)

          ...and that’s the point. Someone can enjoy the smell of their own farts all day long over how they chose a Condorcet-efficient means of tabulating aggregate preferences, but if you offer the group a menu of Spam, Eggs and Spam, Spam Dogshit Rusty Nails and Spam, Ebola Spam Dogshit Spam and Spam... and everyone bloody well hates Spam, but maybe with a slight preference that it be masked with dogshit, eggs and rusty nails in some arbitrary proportion...

          No matter what method of tallying these preferences you use, you’re not really going to tease out that people just hate Spam.

  • (Score: 2, Interesting) by messymerry on Monday December 30 2019, @04:43PM (3 children)

    by messymerry (6369) on Monday December 30 2019, @04:43PM (#937514)

    Aren't there blobs in systemd that can't be read? I was led to understand that systemd is not fully "open source".

    Is this true?

    Thanks bunches and an early Happy New Year!

    --
    Only fools equate a PhD with a Swiss Army Knife...
    • (Score: 2, Funny) by Anonymous Coward on Monday December 30 2019, @06:13PM

      by Anonymous Coward on Monday December 30 2019, @06:13PM (#937545)

      Some of those blobs have been deciphered. It's clear now that playing them backwards at 45 rpm reveals satanic worship chanting. Avoid systemd if you value your soul!

    • (Score: 2) by Bot on Monday December 30 2019, @07:07PM (1 child)

      by Bot (3902) on Monday December 30 2019, @07:07PM (#937574) Journal

      > Aren't there blobs in systemd that can't be read.

      Try the documentation. I mean, you can technically read it

      --system, --user
                            For --system, tell systemd to run a system instance, even if the
                            process ID is not 1, i.e. systemd is not run as init process.
                            --user does the opposite, running a user instance even if the
                            process ID is 1. Normally, it should not be necessary to pass
                            these options, as systemd automatically detects the mode it is
                            started in. These options are hence of little use except for
                            debugging. Note that it is not supported booting and maintaining
                            a full system with systemd running in --system mode, but PID not
                            1. In practice, passing --system explicitly is only useful in
                            conjunction with --test.

      so, why not make them a debug and test suboptions? --test-as-system? we will never know. We also will never know how many sysadmins started crying and hitting the keyboard with their forehead when reading this, at 3am and with an unbootable server to diagnose.

      --
      Account abandoned.
      • (Score: 3, Informative) by barbara hudson on Monday December 30 2019, @07:13PM

        by barbara hudson (6443) <barbara.Jane.hudson@icloud.com> on Monday December 30 2019, @07:13PM (#937579) Journal

        These options are hence of little use except for debugging. Note that it is not supported booting and maintaining a full system with systemd running in --system mode, but PID not 1.

        Translation: It will not crash, and if it does it's not my fault, even if it is. - LP

        Systemd doesn't leave a system unbootable forever. Just install another distro, one that doesn't have it. Problem permanently solved.

        --
        SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
  • (Score: 1, Interesting) by Anonymous Coward on Monday December 30 2019, @07:36PM (7 children)

    by Anonymous Coward on Monday December 30 2019, @07:36PM (#937581)

    Systemd was created by the leading distros *for* the leading distros. With systemd, the distros don't have to create init scripts for each package they include in the distro because the script is exactly the same for each distro and is supposed to now be created by the package maintainers. Nevermind that systemd is crappy for admins, it saves distros from doing some work. That is all.

    • (Score: 2, Insightful) by Anonymous Coward on Monday December 30 2019, @09:41PM (5 children)

      by Anonymous Coward on Monday December 30 2019, @09:41PM (#937606)

      What is simpler than, if startup is more complex than foobard -d, for the developer to provide a wrapper for a regular stop / start / restart init script?

      It's not the script thing that got distros to switch, it's RH's control of Gnome and the engineered dick-to-ass link with SystemD they designed that got distros to bend over. Because Gnome is like sacrosanct or something.

      • (Score: 2, Informative) by Anonymous Coward on Monday December 30 2019, @10:17PM (4 children)

        by Anonymous Coward on Monday December 30 2019, @10:17PM (#937621)

        It's not the script thing that got distros to switch, it's RH's control of Gnome and the engineered dick-to-ass link with SystemD they designed that got distros to bend over. Because Gnome is like sacrosanct or something.

        Exactly.

        That is why Poettering, way back in 2011, made a specific request [gnome.org] for an unnecessary, arbitrary Gnome dependency on systemd.

        Poettering (and RedHat) knew that an artificial Gnome dependency would force many of the big distros to adopt systemd.

        • (Score: 3, Insightful) by barbara hudson on Tuesday December 31 2019, @03:58AM (3 children)

          by barbara hudson (6443) <barbara.Jane.hudson@icloud.com> on Tuesday December 31 2019, @03:58AM (#937736) Journal
          Should have made them abandon the piece of shit known as Gnome.
          --
          SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
          • (Score: 0) by Anonymous Coward on Tuesday December 31 2019, @08:15AM (1 child)

            by Anonymous Coward on Tuesday December 31 2019, @08:15AM (#937796)

            You are welcome to code your own.

          • (Score: 4, Informative) by rleigh on Tuesday December 31 2019, @09:42AM

            by rleigh (4887) on Tuesday December 31 2019, @09:42AM (#937803) Homepage

            I did suggest this during the Debian systemd debate. When it was clear that GNOME was being used as the leverage to force Debian into adopting systemd, I questioned whether a single desktop project should be effectively dictating the direction of the entire Debian project, which is intended to be for universal use, including embedded, server and non-Linux kernels.

            We all know what the outcome was. For reasons I can't entirely fathom, GNOME has a privileged position in Debian, has since its inception, and I don't find it at all healthy. When a third-party project effectively blackmails you into performing an action against your will and better judgement, I'd personally have told them where to stick it and dropped them like a hot potato. It's not like it's the be-all and end-all of the free software world. There were and are plenty of viable alternatives, several of which are technically better.

            The free software ecosystem has historically worked together by collaboration for mutual self-interest, not coercion. I do consider this to be a fairly blatant power grab by corporate interests; we now have a single company dictating the future direction of nearly every major Linux distribution where previously they were independent. Much of Debian's core booting stuff was better done than RedHat's approach, e.g. its initramfs-tools. While many follow along in the same of "consistency", I find this the antithesis of what made Linux popular and successful in the first place, and I think long-term it will damage the viability of Linux as a platform. I, for one, have almost completely abandoned it after being a dedicated developer and user for over two decades. I'm now using FreeBSD and Windows; that would have been unthinkable for me a decade back, but that's where I've ended up.

    • (Score: 1, Insightful) by Anonymous Coward on Tuesday December 31 2019, @01:38AM

      by Anonymous Coward on Tuesday December 31 2019, @01:38AM (#937682)

      systemd was made by redhat for redhat; poisoning debian also helps advance redhat's agenda

  • (Score: 3, Insightful) by Azuma Hazuki on Monday December 30 2019, @11:17PM (3 children)

    by Azuma Hazuki (5086) on Monday December 30 2019, @11:17PM (#937643) Journal

    Could be greed for money, for recognition, for mindshare, whatever--when a system's principles are compromised by greed, the entire thing rots from the inside.

    My long journey with Linux--starting in 2004 back in high school!--began with Gentoo and has ended up back there since recently getting a Thinkpad E495 for a ridiculously good deal. There are some distros that haven't succumbed to systemd-only insanity: Gentoo allows the choice and makes OpenRC the default, Void has runit, Artix can use either, and Slackware is...still Slackware, Madokami's blessing be upon it.

    Linux is splitting, and it's time we accepted this. *Let* the greedheads go their own way. There never was a real possibility of power and ease of use; you either control your own machine, or someone else does. You work for it, or it works for someone else. Just...thank goodness for the sane distros and for the *BSDs.

    Someday, if Linux ever truly loses its soul, I will jump ship to {Free,Open}BSD and never look back. Nothing in this world lasts. Everything that has form is destined to destruction. Find your peace.

    --
    I am "that girl" your mother warned you about...
    • (Score: 2) by jmichaelhudsondotnet on Tuesday December 31 2019, @03:40PM (1 child)

      by jmichaelhudsondotnet (8122) on Tuesday December 31 2019, @03:40PM (#937849) Journal

      at least your nihilism is consistent and well stated, and you trust the right distros

      • (Score: 2) by Azuma Hazuki on Wednesday January 01 2020, @03:45PM

        by Azuma Hazuki (5086) on Wednesday January 01 2020, @03:45PM (#938234) Journal

        "All that has form is void" is *not* nihilism. It's a simple statement of the truth of entropy.

        --
        I am "that girl" your mother warned you about...
    • (Score: 2) by Runaway1956 on Tuesday December 31 2019, @04:58PM

      by Runaway1956 (2926) Subscriber Badge on Tuesday December 31 2019, @04:58PM (#937899) Journal

      Linux is splitting

      Such echoes started sounding when Suse accepted special favors from MS. MS didn't just give millions and millions in cash and IP to Suse out of the goodness of their hearts.

      You work for it, or it works for someone else.

      Had to parse your meaning, but yeah. You don't have to do much of anything to get Windows up and running. And, it's becoming more and more obvious that if you run Windows, your ass belongs to MS.

      I believe that SystemD is moving in that direction. Forget part-time gurus like me - real IT people are bitching about it. SystemD is as opaque as the side of a mountain, in many cases.

      Ehhh, nonconformity is it's own reward, I think.

(1)