Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Tuesday December 10 2019, @02:06PM   Printer-friendly

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.
  • (Score: 5, Interesting) by Unixnut on Tuesday December 10 2019, @03:59PM (14 children)

    by Unixnut (5779) on Tuesday December 10 2019, @03:59PM (#930614)

    > I don't remember ever having a problem with a non-systemd init system issue.

    Likewise, but I have had no end of problems with systemd, many of them so obscure and fiddly to debug and fix that most of the time its easier to treat it like windows (hard reset and hope it fixes itself, otherwise reinstall).

    And it isn't just me, stability and bugs in systemd have been growing concern for the companies I work for. As most companies I've worked for use RHEL, we have been dealing with systemd since around 2014.

    The hope was, that the buggy, obtuse, horribly interconnected pile that is systemd would with time be smoothed around the edges, it would start integrating better, things would "just work", and the bugs would get ironed out. Yet here we are, on the cusp of 2020, and its still a bug riddled PITA to administer, except now they have absorbed even more of the Linux subsystem into it.

    The sad thing is, systemd has done more to squander the Linux image of "fast, secure, dependable and reliable" that had been built since the late 90s to the start of the 10's than anything else.

    When systemd has a security hole that opens you up to root infection, or hangs on boot, or hangs on shutdown with some cryptic message, or we get random services not started, or crashing, or odd issues like systemd overriding settings set in standard OS places, causing much headache and admin time spent debugging, the business weighs in on the cost of maintaining Linux infra, and sees it going up.

    Linux used to be able to claim a lower TCO. Yes, Linux admins were more expensive than MCSEs, but you needed less of them for the same number of systems (as they spent less time babysitting the machines).
    As that is now no longer the case, and we have to spend almost as much time as the Windows admins babysitting systemd, the costs are swinging away from us.

    Recently I have started seeing something which I have not seen before, which is wholesale virtualisation of Linux infrastructure onto windows hypervisors, as windows is now seen as more reliable and easier to administer.

    It makes sense, because when systemd shits the bed, you just roll back to the last snapshot and carry on, meaning you don't need that many Linux admins anymore to do actual debugging and fixing of the machines. However it is a sad state of affairs to have reached this point. Thanks to systemd, Windows is now considered a solid server-based competitor to Linux again.

    Thank god for Devuan at home, and FreeBSD for my servers, however I understand that very few companies will not go with what technology the Linux "market leader" uses, just because its extra cost and hassle to go your own way (and they don't really care about the tech). So I resigned myself to systemd until I could move away from Linux administration, and it became someone else's problem.

    Starting Score:    1  point
    Moderation   +3  
       Interesting=3, Total=3
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 5, Insightful) by FatPhil on Tuesday December 10 2019, @04:44PM

    by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Tuesday December 10 2019, @04:44PM (#930639) Homepage
    > systemd has done more to squander the Linux image of "fast, secure, dependable and reliable"

    By first shitting on the unix principle of doing one job, and doing it well (but having sensible enough interfaces that bigger systems can easily be built from it).
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
  • (Score: 2) by RS3 on Tuesday December 10 2019, @04:54PM (6 children)

    by RS3 (6367) on Tuesday December 10 2019, @04:54PM (#930642)

    Thanks, I'm a bit worried. I'm in the market for full-time work and mainly looking into Linux admin. If I can convince management to use a systemd-less distro, then coolness. Otherwise I'm worried. There are many systemd-less distros- any thoughts or experience? I've been running Alpine on a couple of machines for years and it's rock-solid, including xen hypervisor / qemu. I'm also a slackware guy from the beginning. I worry about building systems that the next admin might struggle with, or hate. My biggest issue with Linux is package management. I have yet to meet a package manager I really like.

    • (Score: 5, Insightful) by barbara hudson on Tuesday December 10 2019, @07:43PM

      by barbara hudson (6443) <barbara.Jane.hudson@icloud.com> on Tuesday December 10 2019, @07:43PM (#930729) Journal

      You want option zero - find another career. Tech is no longer about either innovation or empowering users, hasn't been since unicorn money infested it.

      --
      SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
    • (Score: 0) by Anonymous Coward on Wednesday December 11 2019, @06:32AM

      by Anonymous Coward on Wednesday December 11 2019, @06:32AM (#930981)

      Gentoo. It has a lot of the same attributes that used to make Slackware good 20 years ago, including extreme flexibility and customizability. Although of course, it depends on what exactly you want from your package manager. But then, Slackware barely has a package manager at all.

    • (Score: 4, Interesting) by Unixnut on Wednesday December 11 2019, @11:29AM (3 children)

      by Unixnut (5779) on Wednesday December 11 2019, @11:29AM (#931014)

      Thanks, I'm a bit worried. I'm in the market for full-time work and mainly looking into Linux admin.

      Well, it depends on where you are based and what your career goals are, but since maybe 2010, I have recommended people don't go into Linux Admin. The rise of cloud technologies/IAAS, and "DevOps"/Automation using tools like Ansible, means the days of crafting, administering and maintaining servers is coming to an end.

      As I mentioned above, nowadays, if a Linux VM malfunctions, we roll back to another snapshot, if that doesn't fix it, we delete the machine and rebuild it from Ansible. The entire rebuild, from kickstart to running business services, can take 15 to 20 mins. That is often a lot faster than trying to even work out what stupid thing systemD did this time to brick the system, let alone fix it.

      Even if you do have physical Linux machines, if they do break, the "re-kickstart and run Ansible" is still faster than debugging systemD. So we don't really do administration anymore. It is more "infrastructure as code", where you program in Ansible (or other config management tool), and then run that to build your machines. We don't even do interactive logins to machines anymore.

      And now they are looking to the next phase, which is "SAAS/Serverless". You don't even run the software yourself anymore, it runs somewhere else, you pay them, and you just connect to it via APIs, or like Amazon lambda, you just upload your code, they execute it, and you get your results.

      That is further reducing the demand for on-premises infra/admin people. As economies of scale take effect, the pool of admin jobs is shrinking. The best place, if you want to do Linux Admin, is try to find companies who can't make use of public clouds (usually due to secrecy, or regulation/compliance issues), or are large enough to run their own clouds. So The big tech companies (Google/FB/Amazon), or Financial/Defence companies.

      If I can convince management to use a systemd-less distro, then coolness. Otherwise I'm worried.

      It is unlikely you can convince management of most companies to use something other than RHEL. I know, I tried, but then I realised that the OS/systemd, while a horrible PITA (and they agree with me on that), is the way the market is going. They know the technology is a pile of crap, but the technology is not their largest concern.

      Fundamentally, for them the OS is a tool, something that is needed to run their applications. Their applications are all certified to work with RHEL (and if you happen to find some really progressive companies, they may certify a LTS Ubuntu release), both of these are systemD distros.

      If you don't use a certified OS/stack, then that will jeopardise support contracts. Any support tickets you raise, when you specify the OS/stack you run, will be returned with "You are not running a supported stack, please try again with a supported stack and re-raise ticket if problem persists", or words to that effect. In the open source world, companies don't buy software, they buy support contracts, because if something goes wrong and you can't conduct business, you are losing money, and you want to to get back on track ASAP.

      Running non standard stacks, or OSes, means that (a) the above support contracts become useless, (b) a lot of the results on the internet about fixing the problem will be RHEL/systemD specific, making it harder for you to adapt to your distro of choice, and (c) you can't be sure whether the problem is with the application, or with interacting with a non systemD OS, increasing the "problem surface" you have to investigate for problems, and increasing time to debug/fix immensely.

      Not to mention you would have to write your own upstart/sysVinit/supervisord scripts to manage the services, as they tend to come with only systemD configuration.

      All of this costs money, and the business wants to keep their IT costs down. If their competitors just use the RHEL stack and end up with cheaper IT costs, then they have to do the same. The counter argument we provide is a technical one (systemD is technically bad), and they may well agree, but money arguments beat technical arguments in business.

      Indeed support contracts are Red Hats bread and butter, and the problem with support contracts is they require problems to solve. Like a bug hunt where you pay developers to find bugs, you will have people game the system by introducing bugs and then "finding" them, to get the money.
      Same thing can happen in supporting software. The buggier a piece of software is, the more quirks it has, and the harder and more obscure it was to debug/fix, the more money they can get paid for support, as companies found it easier just to pay for support than to admin/fix the machines themselves.

      There are many systemd-less distros- any thoughts or experience?

      I personally switched from Debian to Devuan, primarily because I already ran Debian everywhere, and switching was just a matter of re-pointing the apt repositories and running an upgrade, it was seamless. In fact the conversion was no more difficult than the usual system upgrade, and all production servers did not need to be rebuilt.

      It also meant all the old scripts and configs just worked. In fact as I did not have to adapt them to systemD it was easier to convert to Devuan then it would have been to update Debian to the first systemD version (especially after I heard of all the problems people had, I really dodged a bullet with that one).

      My biggest issue with Linux is package management. I have yet to meet a package manager I really like.

      Can't help you there. I have settled on APT, and it has served me well for decades now (and I've used all the big ones, from pacman/yum/ports/emerge/zipper onwards). The second fave I have (on Linux) is Gentoo emerge, but I have not used it in years. The day machines got powerful enough that it was not worth the time to compile everything from source (as I could not see a noticeable speed increase from doing so), is the day I stopped using Gentoo day to day. Just keep trying to find one you are comfortable with.

      • (Score: 2) by RS3 on Wednesday December 11 2019, @03:43PM (1 child)

        by RS3 (6367) on Wednesday December 11 2019, @03:43PM (#931077)

        I can't thank you enough, all really good points and very helpful.

        There are a few cases where mgt. have realized that clouds are kewl and all, but when they break, you wish for your own servers or some other contingency. Fortunately in my geographic area are some pretty major corporations that need their own clouds, including (financial) transaction processing, military contractors, healthcare and pharmaceuticals, transportation / logistics, and generally companies that can't afford chaos and downtime.

        I really appreciate your support for Devuan. I hadn't looked into it yet. I guess I thought of it as experimental or some such, but I might deploy it soon. Again, I'm loving Alpine, but not apk, their package manager. Again, I don't like anyone's package management, but I haven't run apt in years. Thank you again!

        • (Score: 2) by Unixnut on Wednesday December 11 2019, @04:33PM

          by Unixnut (5779) on Wednesday December 11 2019, @04:33PM (#931115)

          > I can't thank you enough, all really good points and very helpful.

          Glad to have been of help!

          > There are a few cases where mgt. have realized that clouds are kewl and all, but when they break, you wish for your own servers or some other contingency.

          It is always a case of Cost vs Risk. A business must look at how much it would cost to keep in house vs public cloud, then decide what are the risks of each. Sometimes they decide the risks of public cloud outweigh the benefits and they keep it all in house, sometimes not.

          Rarely does management make a stupid decision deliberately (I know its hard to believe sometimes). Decisions are based on what information they have been given, and usually judged based on business needs, cost and risk.

          Still, even if they do decide to keep everything in house, they will probably still stick with the RHEL Stack (or RHEL compatible, like CentOS), just because of the increased IT costs of "doing your own thing", which fundamentally will not increase their income (if running an application makes them money, the underlying OS is irrelevant except as a cost centre).

          >Fortunately in my geographic area are some pretty major corporations that need their own clouds, including (financial) transaction processing, military contractors, healthcare and pharmaceuticals, transportation / logistics, and generally companies that can't afford chaos and downtime.

          That is indeed fortunate. Many of those would have stuff in house, even if it is an internal "private cloud" setup using things like Openstack and Kubernetes. You would have better success if, in addition to Linux Admin, you show proficiency with automation tools like Ansible, as it shows you have the capability to automate systems as well. I find there is a lot of work going to companies and converting the old legacy configured machines (running critical software) into Ansible. Primarily for disaster recovery (so they can recreate their entire infra from the code sitting in a git repo in a worst case scenario).
           

      • (Score: 2) by bart on Thursday December 12 2019, @03:21PM

        by bart (2844) on Thursday December 12 2019, @03:21PM (#931410)

        My biggest issue with Linux is package management. I have yet to meet a package manager I really like.

        I've seen them all, and `xbps` from Void Linux is by far the fastest and most robust rolling release package manager I've seen so far. I recommend everyone to take a look at Void Linux. Have a look at this comment to get a feel for the Void
        https://www.reddit.com/r/voidlinux/comments/e7jpb2/1_year_into_the_void/ [reddit.com]

  • (Score: 3, Informative) by Bot on Tuesday December 10 2019, @07:39PM (5 children)

    by Bot (3902) on Tuesday December 10 2019, @07:39PM (#930725) Journal

    Did your people really think that redhat would have gone all the way pushing for a new incompatible init system/system middleman, if its aim was ultimately to return to transparent and easy to admin linux boxii?
    Systemd is working as expected.

    --
    Account abandoned.
    • (Score: 2) by RS3 on Wednesday December 11 2019, @03:46PM (4 children)

      by RS3 (6367) on Wednesday December 11 2019, @03:46PM (#931080)

      Yes, again, "business decisions" get priority over tech.

      • (Score: 2) by Unixnut on Wednesday December 11 2019, @04:22PM (3 children)

        by Unixnut (5779) on Wednesday December 11 2019, @04:22PM (#931106)

        > Yes, again, "business decisions" get priority over tech.

        And in business, they always will. Unfortunately the only place where you can make technical arguments about things like OS subsystems, is on sites like this, or the CS departments in Academic institutions.

        • (Score: 2) by RS3 on Wednesday December 11 2019, @08:30PM (2 children)

          by RS3 (6367) on Wednesday December 11 2019, @08:30PM (#931218)

          Frequently I forget and neglect to mention the big giant obvious-to-me thing: shortsightedness. In most of my job/corporate/business experience, when mgt. types start getting defensive and feel they have to justify things, they use phrases like "it's a business decision", and "we feel this is the right course of action", etc. It always means "shortsightedness", immediate profits. I don't think they think about long-term company survival. I think their instinct is conquer, rape and pillage, and move on to the next town to sack. But that's my somewhat cynical view of many in management.

          • (Score: 3, Insightful) by fido_dogstoyevsky on Wednesday December 11 2019, @09:12PM (1 child)

            by fido_dogstoyevsky (131) <axehandleNO@SPAMgmail.com> on Wednesday December 11 2019, @09:12PM (#931227)

            ...I think their instinct is conquer, rape and pillage, and move on to the next town to sack. But that's my somewhat cynical view of many in management.

            You're confusing cynicism for realism.

            --
            It's NOT a conspiracy... it's a plot.
            • (Score: 2) by RS3 on Wednesday December 11 2019, @11:13PM

              by RS3 (6367) on Wednesday December 11 2019, @11:13PM (#931255)

              Yeah, I was hedging a bit. That much realism hurts some people.

              And I was thinking of the children. And myself a bit- hoping to find good job, good management. If I do, I'll keep it secret of course. :)