SoylentNews is people
SoylentNews
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.]
(Score: 4, Interesting) by Unixnut on Wednesday December 11 2019, @11:29AM (3 children)
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.
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.
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).
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)
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
> 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
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]