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.]
Related Stories
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.
(Score: 5, Insightful) by barbara hudson on Tuesday December 10 2019, @02:10PM (8 children)
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 4, Touché) by acid andy on Tuesday December 10 2019, @02:15PM (6 children)
People like you, I'm sure, would be directed to Choice 8, or failing that, the nearest exit. ;)
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 1, Touché) by Anonymous Coward on Tuesday December 10 2019, @02:16PM (2 children)
You mean Choice 9: Choose another OS
(Score: 2) by barbara hudson on Tuesday December 10 2019, @06:06PM
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, @12:46AM
> You mean Choice 9
I think you meant Plan 9 https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs [wikipedia.org]
ftfy...
(Score: 2) by DeVilla on Tuesday December 10 2019, @03:55PM
C, There you go again.
(Score: 4, Interesting) by barbara hudson on Tuesday December 10 2019, @05:59PM (1 child)
There's a lot of that going around among the more closed-minded. Rigging the poll so that abandoning sysyemd isn't even an option tells you that it's dishonest and they have already decided what will happen no matter what the outcome.
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: -1, Flamebait) by Anonymous Coward on Tuesday December 10 2019, @09:57PM
No, you're just being rude at that point. Supporting multiple init systems is what you want, totally blocking systemd is just as bad as forcing it on everyone. As long as you can choose a different init and have everything work I see no problem.
Hmm, maybe you were half right cause "support" could mean keeping a lot of systemd changes while allowing a different init. Systemd is way beyond just init at this point...
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @04:05PM
That option is C++
(Score: 4, Funny) by acid andy on Tuesday December 10 2019, @02:20PM (1 child)
It's a subliminal message:
So, "Focus on systemd" is BAD. Yeah, that makes sense.
He wants to gee up support for "portability and multiple implementations"? Wow this Debian lot are totally ahead of the curve. I'm switching distro immediately!
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 5, Funny) by FatPhil on Tuesday December 10 2019, @04:39PM
The conclusion can only be - dum dum dahhh - to migrate to Steam-OS.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 4, Interesting) by DannyB on Tuesday December 10 2019, @02:20PM (7 children)
Choice 9: WWMD: What Would Microsoft Do
Seems like this should be an SN poll. We need new SN polls. And a mechanism to submit poll ideas.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 3, Interesting) by The Mighty Buzzard on Tuesday December 10 2019, @04:29PM (4 children)
Doesn't suck as an idea but for the moment you can sub them as a story. Most of our eds are capable of figuring out something with "POLL" in the title and a list of choices is supposed to be a poll. When they're sober and have had their coffee anyway.
My rights don't end where your fear begins.
(Score: 2) by FatPhil on Tuesday December 10 2019, @04:32PM (3 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by The Mighty Buzzard on Tuesday December 10 2019, @05:41PM (1 child)
Don't worry, as long as you can keep making at least half as many typos as cmn32480, we'll keep you around.
My rights don't end where your fear begins.
(Score: 2) by DannyB on Tuesday December 10 2019, @05:57PM
Speed is substitute fo accurancy
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by Mykl on Wednesday December 11 2019, @04:07AM
Or those of us who are Australian [youtube.com]?
(Score: 3, Funny) by stretch611 on Tuesday December 10 2019, @07:05PM
How appropriate that your Microsoft option contains a WMD (Weapon of Mass Destruction)
Now with 5 covid vaccine shots/boosters altering my DNA :P
(Score: 2) by PartTimeZombie on Tuesday December 10 2019, @08:14PM
Some sort of systemd module, presumably.
(Score: 2) by Mojibake Tengu on Tuesday December 10 2019, @02:35PM (30 children)
It is all just politically correct collectivism with only residual traces of rationality.
Best rational option is: split Debian to multiple projects, by what people truly need of it and what they really do for their needs.
Devuan separatists got it right.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 2, Interesting) by shrewdsheep on Tuesday December 10 2019, @02:46PM (12 children)
To the contrary. There is a lot of duplication of efforts going on in the larger Linux/BSD community. Start with hosting, bug tracking, packaging systems, packaging itself and there is no end in sight. Freedom it is and it is everybody's choice, I do cherish that for sure. In terms of market penetration, Linux would be much more effective if efforts would concentrate on fewer distributions.
It is a double edged sword: the zeal and idealism of developers/contributors drives these projects, the very same zeal and idealism leads to deep emotional conflict, flame wars, and forks.
(Score: 5, Insightful) by Arik on Tuesday December 10 2019, @03:01PM (4 children)
That's not a bad thing.
"In terms of market penetration, Linux would be much more effective if efforts would concentrate on fewer distributions."
I doubt that very much, in fact I'll go so far as to say the opposite is far more likely to be true.
Different distros exist to meet the needs of different people. You start eliminating them, you lose the people they served, you lose the people that were motivated to develop and maintain them, it's all very counterproductive.
Instead, you might focus on shaming application developers to produce proper software again - well written applications are portable, crappy ones expect you to use the same distro as the developer and that's really not acceptable.
If laughter is the best medicine, who are the best doctors?
(Score: 1, Offtopic) by epitaxial on Tuesday December 10 2019, @07:45PM (3 children)
Take iMessage for example. It works over wifi unlike normal SMS messages. On wifi I can text any other iPhone user because its the only messaging app. Now take Android. It has that capability but via third party apps, of which there are dozens. Which one can I install that will work with EVERY Android. There isn't one. Simple shit like this is the problem.
(Score: 3, Insightful) by Arik on Tuesday December 10 2019, @07:58PM (2 children)
And Android is an excellent example of what should never be done. On just about every level. So I'm not even sure if you replied to the right message.
It's a bit mystifying.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by epitaxial on Tuesday December 10 2019, @09:10PM (1 child)
It perfectly describes your problem of packaging. There are competing formats that all do the same thing and now that systemd is involved it makes things much worse.
(Score: 1) by Arik on Wednesday December 11 2019, @05:08AM
Not my problem. Again, I suspect you are replying to the wrong messages for some reason.
If laughter is the best medicine, who are the best doctors?
(Score: 4, Insightful) by Mojibake Tengu on Tuesday December 10 2019, @03:40PM (3 children)
If the true needs are divergent, any effort to converge them by just exercising power is harmful. This is what evil corporations do, like RedHat or Microsoft.
You want cathedral, instead of bazaar. Centralism does not fit to the concept of FOSS.
Duplication of efforts is critical factor to prevent single points of failure by concentration of errors. Linux needs more different distros, not fewer almost identical.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 2) by Dr Spin on Tuesday December 10 2019, @05:23PM (2 children)
You want cathedral, instead of bazaar. Centralism does not fit to the concept of FOSS.
Actually, the BSDs are cathedral like, and are a good answer if what you want is *BSD!
OTOH closed sores is the answer if you want a pile of shite.
Warning: Opening your mouth may invalidate your brain!
(Score: 2) by Bot on Tuesday December 10 2019, @07:48PM
In the meantime, project trident, aiming to improve freebsd, transitioned to systemd-free void linux, they also stated their reasons.
https://project-trident.org/post/os_migration/ [project-trident.org]
So, just use freebsd is not a catch-all solution, even without considering licensing philosophies.
Account abandoned.
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @08:22PM
The BSDs are a bazaar of cathedrals; each one may be a cohesive whole, but there are many to choose from.
And, I would put forth that the cross-pollination between the BSDs are a great source of their strengths.
(Score: 2) by DannyB on Tuesday December 10 2019, @05:59PM
We now have fewer Linux distributions than there are Linux users. At one time in the past the opposite was true.
So progress has already been made.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @06:21PM
>> There is a lot of duplication of efforts
That is exactly why Poettering is doing the community a huge favor by incorporating new functionality into systemd... he accepts your suggestion to add hosting, bug tracking, packaging systems, packaging itself and there is no end in sight.
(Score: 2) by Bot on Tuesday December 10 2019, @07:43PM
But this happened with systemd. Distros are becoming mere branding thanks to systemd propension to submit other services. Linux did not advance much as a result did it?
Account abandoned.
(Score: 3, Touché) by RS3 on Tuesday December 10 2019, @02:48PM (13 children)
"collectivism"- I like that. I lump that in with "popular misconception".
Yes, agreed on all points.
The flaw I see is a lack of choice, including the survey: how about giving us a choice of init system?
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @05:41PM (8 children)
Never gonna happen. It's not like this is part of the discussion, right:
(Score: 2) by RS3 on Tuesday December 10 2019, @06:47PM (7 children)
I find that wording awkward. I don't want multiple init systems. I want 1, that I choose from a list of options.
And, I was referring to ALL Linux distros, and software in general. Seems it (providing options) would solve the debate.
(Score: 4, Informative) by Bot on Tuesday December 10 2019, @07:55PM (3 children)
You are the user, there is written "support". So your objection as a dev might be I don't want to support many init systems.
Debian, before systemd and COCs, was adding support for different KERNELS. Why? because it is called the universal operating system. So multiple init support, especially in terms of removing BAKED IN dependence on systemd, should be one of the main goals of debian. That they have trouble achieving it for lack of dev power (everybody occupied with making their systemd work I guess?) is another matter.
Account abandoned.
(Score: 2) by RS3 on Tuesday December 10 2019, @10:08PM (2 children)
It's amazing how confusing language can be. Let me try this: to me, the wording "support for multiple init systems" means "one installed OS can have multiple init systems installed at once." Does that make more sense? And maybe that could exist, and a boot menu would allow choosing which init system to use for that boot.
I'd rather the wording be: at installation, choose one init system from many available.
(Score: 3, Informative) by Bot on Tuesday December 10 2019, @11:03PM (1 child)
Mxlinux in fact has sysvinit and systemd as boot options.
Account abandoned.
(Score: 2) by RS3 on Wednesday December 11 2019, @03:52PM
Thank you so much, I'll try it. I had tried "mepis" 8 or so years ago, before systemd became malignant. Recently when I saw systemd listed as part of Mxlinux I moved on, not knowing it was optional. Generally when a distro starts including systemd, my inclination is to steer clear because they're wasting valuable time and resources on a tumor. My fear with Mxlinux is that systemd will become defacto, but I'll try it...
(Score: 0, Troll) by Anonymous Coward on Tuesday December 10 2019, @08:37PM (2 children)
If you want such a an option list when installing a distro, from where do those options come?
Perhaps you could write several of them each time you install a new system? What's that? You just want a bunch of different options presented to you and don't care about how they get there? If that's the case, then the discussion/vote in TFA isn't aimed at you.
I'm not *at all* suggesting that you don't participate. By all means, say whatever you want.
However, the issue isn't awkward wording, it's your complete misunderstanding of the discussion WRT init systems in TFS/TFA is all about.
It's not like multiple init systems run at the same time (okay, I guess they *could*, but hilarity, then tragedy, would ensue -- possibly without the hilarity). As such, what do you think
means?
It means exactly what you're asking for. I'm not sure how you could be confused so badly. Lack of sleep?
(Score: 2) by RS3 on Tuesday December 10 2019, @10:10PM (1 child)
Whenever you misunderstand someone, it's always the best thing for all of society to insult the person, rather than realize that language is not exact, and sometimes some readers may misinterpret what they've read. /s
(Score: -1, Troll) by Anonymous Coward on Tuesday December 10 2019, @10:32PM
That, to you, is an insult?
Remind me not to hope you have a good day -- you might beat me up.
(Score: 2) by DannyB on Tuesday December 10 2019, @06:04PM (3 children)
A choice can be a set of radio buttons with only one option. Or make that single item a checkbox if that helps you to perceive it as a choice.
(radio buttons...)
Which init system would you like to install:
(*) systemd
(checkbox...)
Would you like to have systemd installed as your choice of init system?
[x] Yes!
(unchecking the [x] Yes, will disable the Continue button to proceed with system installation.)
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @06:23PM (1 child)
Sorry, Microsoft has patented that trick already with Window 10 upgrade.
(Score: 2) by Osamabobama on Tuesday December 10 2019, @09:55PM
Microsoft used the opposite trick; the Continue button was never disabled, even when not clicked.
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by RS3 on Tuesday December 10 2019, @06:49PM
> A choice can be a set of radio buttons with only one option.
Like everything but systemd is grayed out.
(Score: 2) by DeVilla on Tuesday December 10 2019, @04:07PM (1 child)
On idealistic grounds I would disagree. I've always liked Debian as a "universal operating system" that offered choices and that was never the "wrong" platform for anything except maybe riding the bleeding edge. And even then there was sid and later testing.
I think the problem may be that the universe has gotten too big and there aren't enough people who value that ideal who can volunteer to help.
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @04:27PM
On the contrary, I think there are still lots of volunteers to help, but project leaderships get lost in the political, while steering the boat away from professionals and their needs, to amateur users and their whims.
(Score: 2) by krishnoid on Tuesday December 10 2019, @10:07PM
Do isotopes count? [distrowatch.com]
(Score: 5, Informative) by Anonymous Coward on Tuesday December 10 2019, @02:38PM (26 children)
The first vote was gamed. I expect this one to be more of the same. Even if "dump systemd" or "allow multiple inits" succeeds, the entrenched proSystemD-ers will just drown it all in red(hat) tape, "minutes meetings", and rules-lawyering, and substandrd package/patch compliance until they get their de facto corporate approved way. It also doesn't hurt their cause that the spooky three letter power rangers also want this but as a unified attack surface to go after and SystemD fits the bill. They'll be sure to put their thumb on the scale where needed, when needed as well. Compare the proSystemD-ers previous actions inside Debian with the co intel pro recommended actions for disrupting/taking-over a group from the inside. The similarities are striking.
(Score: 3, Informative) by RS3 on Tuesday December 10 2019, @03:00PM (16 children)
You make good points, but I think a big problem is when a company makes "business decisions" (technical decisions made by non-technical idiots), such as going all MS, or all RedHat, the employees either adapt and learn, or look for another job. And the ones who adapt and learn are sometimes poison kool-aide drinkers, and that's just a fact of life.
Changing jobs isn't all that easy, and sometimes it's easier to just suck it up, do the job, deal with systemd, and worry about other things. It's no secret that the world is constantly moving toward "automation", and if systemd lessens the labor cost, then that's the way "business decisions" will be made. Of course, the obvious problem is the big spike in labor cost when something goes wrong. In 25 years of Linux, including 10+ of professional / live servers, I don't remember ever having a problem with a non-systemd init system issue.
(Score: 5, Interesting) by Unixnut on Tuesday December 10 2019, @03:59PM (14 children)
> 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.
(Score: 5, Insightful) by FatPhil on Tuesday December 10 2019, @04:44PM
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)
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
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
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)
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]
(Score: 3, Informative) by Bot on Tuesday December 10 2019, @07:39PM (5 children)
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)
Yes, again, "business decisions" get priority over tech.
(Score: 2) by Unixnut on Wednesday December 11 2019, @04:22PM (3 children)
> 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)
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)
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
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. :)
(Score: 1, Insightful) by Anonymous Coward on Tuesday December 10 2019, @09:50PM
Nothing new, more like over two decades old and documented multiple times since (source of quote below [archive.org], same author, similar text in page 14 of PDF from 2005 [researchgate.net], Bruce Perens version mentioning Donnie Barnes, instead of Bob Young [archive.org]). It is for the money and the control first, technical later or never:
If Debian does not want to follow the tracks laid from the begining, fine, but should stop calling themselves "The universal operating
system" (front page header image [debian.org]). It's incompatible with focusing in a framework (it is not just an init system, probably never was) that does not care about other kernels and even C libraries (leading to vendor lock-in, very anti Free Software), when one of the points of Debian was keeping alternatives, and not a Cathedral approach dictated by others. Remember that now Red Hat is part of IBM, don't expect anything but pushing their weight around even more.
Of course also change the Social Contract [debian.org] to stop saying "users" so many times, as that does not apply anymore with this kind of decisions:
Replace it with "developers" or "maintainers" or "corporate interests" for example. Eliminate "free software community" and "high-quality". The "allow others to create distributions" phrase also needs changes or deletion, to match the new behaviour of being obedient to external interests instead of a guiding light. Bare mininum to not fall into hypocrisy.
Maybe this is the Nth (4?) Ethical Moment in Debian, in which the project publicly drops the original ethics and purpose.
(Score: 1, Troll) by jmichaelhudsondotnet on Tuesday December 10 2019, @03:25PM (5 children)
well said
I do not see why there cannot be a selection of init system like you can select a boot system or a desktop environment. Anyone who is deadset against that, like this one tool of theirs is essential to the whole thing, just lost their ability to convince me they are not police or worse.
Open source can be destroyed with Open Obfuscated Source, death by a million riddles, which is what intentionally planted exploitable bugs are and NSO has shown us that they are doing that exactly with google.
(infiltrated entity produces thing) (hand off bug to private spies) (sold to law enforcement and military by consultants)(people get murdered by paramilitary police)(freedom justice and the american way) /s
I made some memes to talk about this, in the interest of not just a thriving public interest, but we are struggling to have a public sector even at all.
This is what decultification.org is about. You might also like these hot off the presses:
https://archive.is/5II5U [archive.is]
https://archive.is/bRCdQ [archive.is]
https://archive.is/ZK7up [archive.is]
https://archive.is/eSLh7 [archive.is]
https://archive.is/xXs6r [archive.is]
https://archive.is/YkJr8 [archive.is] ***
https://archive.is/EoIML [archive.is]
https://archive.is/QBVQJ [archive.is]
https://archive.is/x5dMp [archive.is]
(Score: 3, Informative) by HiThere on Tuesday December 10 2019, @05:07PM (3 children)
The problem is that systemd doesn't want to be just an init system.
E.g., it want's to run the error logging system and not export it. Yes, it claims to export it, but there were a lot of "won't fix" responses to comments about problems.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 4, Informative) by VLM on Tuesday December 10 2019, @08:26PM
There's also some impenetrable and apparently pointless DNS server on 127.0.0.53, seemingly solely existing because DNS resolution on linux used to work and make sense and be predictable, so that must be changed so as to boost billable admin hours per server.
Also there were too many eyes on security bugs in the existing NTP clients (and servers) so as to increase the attack surface even more, they implemented their own "timesyncd". Its main claim to fame is on a raspberry pi it'll log the current time every time it syncs, so as to avoid lack of RTC on pi by whacking the SD card until the flash fails sooner than with a "legacy ntp"
Its a linux distro tradition to make it ever weirder to set the hostname, so thats getting eaten by systemd as yet another weird way to set the hostname.
Its basically a NIH machine that eats stuff that works and emits a sophomoric similar parody of "legacy" services.
(Score: 4, Informative) by Arik on Wednesday December 11 2019, @05:19AM (1 child)
Another way of saying this is that it simply refuses to behave. They refuse to create a component that will behave properly as part of the system as architectured. They'll break it apart and remake it, in the form of an architecture they like better. Ultimately this will become an entirely different system if they get their way, an entirely different architecture.
This is insidious. They have every right to fork the OS, but they're doing it by the back door, effectively taking over the existing architecture of distribution to force their fork on users, instead of having to make a case to attract users to their fork.
If laughter is the best medicine, who are the best doctors?
(Score: 3, Interesting) by jmichaelhudsondotnet on Wednesday December 11 2019, @11:13AM
So then it is a decultification situation, where the public is defending itself from slimy lateral power grabs of non-public forces, and we hardly, we thet public, have any language or social form to handle this, so they are just analyzing our exisitng networks and spamming them with social engineering attacks.
That is why I try to warn people about things like this with memes and drawings:
https://archive.is/OczM2 [archive.is]
https://archive.is/YkJr8 [archive.is]
https://archive.is/Eu1Z4 [archive.is]
https://archive.is/9Chwi [archive.is]
Something is definitely up with sysd. I gave it some time, but by their packages and change request responses ye shall know them. And they stink.
Whoever is being more manipulative is the one that you should be more concerned about. They must think we are pretty dumb. At least we can see their intents and strategies, and now we can adapt too.
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @07:40PM
Your memes [kym-cdn.com].
(Score: 4, Touché) by tangomargarine on Tuesday December 10 2019, @04:14PM
Notice this is not an option on the ballot.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @05:43PM
I didn't realize that BSA [scouting.org] had skin in this game. Thanks! The more you know... [minutemediacdn.com]
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @11:42PM
That's why I'm voting for "Boaty McBoatface"
If they don't get the result they want, they'll just implement their own John Scott [thehockeynews.com] rule.
(Score: 5, Interesting) by Runaway1956 on Tuesday December 10 2019, @03:03PM (4 children)
Choice 6: E: Support for multiple init systems is Required
The Windows Phan Bois have been telling us for years (is it decades now?) that much of Linux' security is just security through obscurity. And, they make a point. Happy Hackers of Hoboken have worked for months to develop an exploit in Red Hat - but I don't care (much) because I've never ever run a Red Hat. HH of H, a few months later, comes up with another exploit, that relies on Gnome. Again, I don't care (much) because I don't run Gnome.
Unlike Windows, the same exploit is NOT common to all Linux users. Oooohhhhhh, Apache is being exploited all around the world today? Whoop-ti-doo, Apache doesn't run here either.
This is one instance where that silly word, "diversity" might be applied meaningfully. The guy who successfully hacks into my machines looks to TheMightyBuzzard next, and runs face first into a brick wall, because Buzzard's machine has little to no resemblance to mine.
The Debian installer should ASK YOU which init system you want to run. It's alright to put a banner somewhere in the installation, "SystemD is our default init system, but you may choose any of the following init systems. See documentation at www.debian.documentation.com/howweforkyouwithsystemd.html"
They give me choices about formatting my hard disk, right? What's so hard about giving me a choice of init systems?
(Score: 5, Insightful) by bradley13 on Tuesday December 10 2019, @03:36PM (2 children)
Security through obscurity is, indeed, not a bad thing. It's not enough by itself, but it is a tool in the toolbox. Just running a server on an unusual port eliminated virtually all attacks. So why not take advantage of that?
Linux is the same: The mass consumer usage of Windows and Mac markets attracts most of the hacking activity. Linux may be dominant in servers, but servers are also generally pretty well secured. Hence, Linux has attracted (through its obscurity in the consumer market) comparatively little hacking attention.
As far as SystemD is concerned: I'm not any sort of Linux admin, just a technical user. That said, the classic init-systems were a dog's breakfast. The few times I had to work with them, sure, everything is a text file, that's great. But the system just wasn't reliable, or didn't seem so to me. So I absolutely like the original, stated goals of SystemD.
That said, all the different things that it does should be in different modules, that you can pick and choose. It should not be the case that choosing SystemD as your init system also dictates a zillion other aspects of your Linux installation. Separate tools for separate tasks, and user (or at least distro) choice on which combination is used.
Everyone is somebody else's weirdo.
(Score: 2) by chromas on Tuesday December 10 2019, @08:08PM (1 child)
It sort of already is. You don't have to use the timesync daemon, caching dns resolver, or the service that gives you dbus access to /etc/hostname, but they're there for you, whether you want 'em or not.
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @09:10PM
... for now.
Most of systemd started as optional, and then new parts required them, and then Gnome required those parts ...
So they might be "optional" now, but they'll be needed by some core part son enough.
(Score: 0) by Anonymous Coward on Wednesday December 11 2019, @12:43PM
I'd call it security though diversity. Having the bad guys comb through more code.
(Score: 3, Interesting) by jmichaelhudsondotnet on Tuesday December 10 2019, @03:29PM (1 child)
E multiple inits required
No matter what anyone says, the debian community is not satisfied with systemd.
And I want no aspects of linux, ever, anywhere, that are single point of failure blobs.
And I want a version of debian that has no ability whatsoever to integrate with active directory or any corporate cubicle-hierarchy management bullshit.
There should be a server version and a desktop version and no windows 10 clone version.
Also, a human readable timestamp is required for human operated computers unless your intention is to keep humans from reading the logs.
These things are not difficult.
Hmmm I feel a meme coming on, hold my beer.....
(Score: 1, Touché) by Anonymous Coward on Tuesday December 10 2019, @05:46PM
Don't install Samba or LDAP. And you're welcome.
(Score: 4, Insightful) by Anonymous Coward on Tuesday December 10 2019, @03:31PM (18 children)
There is a convincing argument for maintaining alternative init systems on a distro. If shit ever hits the fan or multiple NSA backdoors or showstopper bugs are found or some other worst case scenario? You can switch init systems.
Systemd and the rest of Linux+userspace has become too complex. Did you know systemd now does DNS caching and name lookups? I didn't either until I was on a network and upstream DNS servers were returning some non-compliant query results. I had to disable caching, but first figure out how systemd's boutique config routine worked. (I forgot already!)
Regardless of platform, I think we all need to take a step back and think long and hard about this tower we're building. I don't want FOSS to end up in a spot where Microsoft is: inter-team hostility, the inability to understand the system and requiring the majority of a month to implement a fucking drop-down box in the control panel.
Holy shit, people can't even build machine learning tools anymore, we're back to downloading unsigned binaries from websites at this point!
What the fuck are we doing?!
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @06:03PM (17 children)
Not on my systems.
systemctl disable NetworkManager
systemctl mask NetworkManager
I do it every. single. time. Easy peasy.
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @07:31PM (3 children)
The number of characters typed at the console (or even their repetitiveness) is not a measure of how complex that thing is. No matter how "easy" the the command line, the fact that you have to remember to do this is beyond fucked up.
Systemd is a horriffic cancer, the long term goal is the destruction of the role of sysadmin, and we know now why Poettering has been smirking for a decade.
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @08:00PM (2 children)
Actually, including it in my kickstart postinstall script means I don't have to remember.
I'm no huge fan of systemd either. That said, if there's an issue, it's better to know how to address it, rather than remaining ignorant.
You appear to wear yours as a badge of honor. Good show!
(Score: 1, Touché) by Anonymous Coward on Wednesday December 11 2019, @03:09AM (1 child)
Clearly.
You address the issue by blacklisting faulty software from running on your machines. Expecting a hack not supported by upstream "wontfix" developer to stay viable with updates is ignorance. Funny how you seem proud of it.
(Score: 0) by Anonymous Coward on Wednesday December 11 2019, @07:40PM
>quote>Expecting a hack not supported by upstream "wontfix" developer to stay viable with updates is ignorance./quote.
What, exactly is the "unsupported hack" here? enabling/starting/stopping/disabling/masking services is core functionality in *any* init system.
As such, is there a specific "bug" you're talking about or is it just flatulence?
(Score: 1, Informative) by Anonymous Coward on Tuesday December 10 2019, @07:43PM (12 children)
Too bad that is the wrong service. NetworkManager is a RedHat project under GNOME, that interfaces with systemd-networkd among others. Systemd and FreeDesktop haven't merged completely yet. Now, I don't want you to claim that I got you on a technicality, so I also want to point out that you would have missed systemd-resolved [archlinux.org], which is probably what GP was talking about in the first place.
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @08:11PM (11 children)
systemd-resolved is dependent on NetworkManager on my systems.
Disabling/masking it prevents systemd-resolved from running.
If that's not the case on other distros, I'm sure that generalizing it would work too:
systemctl disable systemd-resolved
systemctl mask systemd-resolved
Or any other unwanted service for that matter.
I trust that GP would be smart enough to figure that out.
My apologies for any confusion, friend.
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @11:26PM (10 children)
If it weren't for the black magic that systemd programmers got from their RedHat overlords, I'd think you are lying. It is literally the opposite on the machine I checked. On the one hand, I wonder what sort of trick was used to reverse dependencies like that. But on the other hand, I'm not sure I do. I bet it has something to do with the unholy merging of FreeDesktop and systemd or maybe wifi-enabled vs ethernet-only machines. Either way, have fun troubleshooting that, especially across distros.
(Score: 0) by Anonymous Coward on Wednesday December 11 2019, @12:09AM (9 children)
WTF are you going on about? There's no magic.* There's just code.
Your inane hyperbole would be amusing, if it wasn't so sad. I feel sorry for you.
I don't need to. My installations disable all that garbage by default. When you bother to get a clue (you might try it sometime), there are all sorts of things you can do. Funny that.
*SCSI is *NOT* magic. There are *fundamental technical reasons* why you have to sacrifice a young goat to your SCSI chain every now and then
(Score: -1, Troll) by Anonymous Coward on Wednesday December 11 2019, @03:00AM
Until new version of systemd adds more garbage, or removes a way for you to disable existing garbage. When you bother to get a clue (you might try it sometime), you can spot a game you cannot win. Funny that.
(Score: 0) by Anonymous Coward on Wednesday December 11 2019, @05:43AM (7 children)
What I was saying is that on one system NetworkManager won't start without systemd-resolved and on the other systemd-resoved apparently won't start without NetworkManager. In order for that to be the case, somewhere along the line NetworkManager and systemd-resolved were changed to make that requirement go the other direction. That is why I said "black magic" as a handwave to both the feature change required for that and the distro differences necessary for that requirement. And the reason why that is "fun" between distros is that there is apparently no clear requirement difference or concept between them, unlike your X client requiring an X server or Apache requiring a network or Plymouth requiring a console. Its just one more gratuitous waste of cognitive effort (usually while under time pressure) to figure out which is which on the systems you are switching between.
Also, as you tell me to "get a clue," if the dependency between the two can apparently switch between distros and versions and all you do is disable NetworkManager, how can you be sure you actually disabled it all? You'd have to check both. That is the point. Even in disabling them, such inconsistent behavior results in unnecessary work or odd problems could arise when trying to run what you do want.
(Score: 0) by Anonymous Coward on Wednesday December 11 2019, @08:28AM (5 children)
That's not "black magic" as you say. The appropriate thing to do, IMHO, is not to use any of that garbage, as it doesn't add anything useful (systemd-resolved is a stub resolver which is completely redundant, and NetworkManager really only provides utility when you have removable network devices -- which can be useful, but is mostly an edge case), as just about all the functionality it provides (except as I noted) is provided by solid tools already installed on your system.
Yes, I did. Firstly, your description ("black magic") made it pretty clear that you don't understand how systemd dependencies work, nor did you provide *any* useful information. That's *two* areas where you aren't displaying "a clue."
If you did understand it, you'd realize that systemctl mask <service> will block any attempt to start that service, even if it's required by a dependency, which will cause that dependent service to fail as well. When it comes to systemd-resolved and/or NetworkManager, that's as it should be IMHO.
If you don't want one or both of those to run, then you absolutely need to check to make sure one or both is not just disabled, but masked as well -- as a disabled service will still start if a service says it's dependent upon it. Which you, apparently, didn't know -- hence my statement.
This isn't rocket surgery. And while I generally prefer init systems other than systemd (I'd note that systemd-resolved and NetworkManager are *not* part of the init system, but separate tools that are poor replacements for existing tools and shouldn't be used, IMHO), systemd does function as an init system *and* provides relatively consistent results.
However, those results are highly dependent on the configuration, order of execution and management of service dependencies. If those settings/configuration aren't configured properly, you will almost certainly get inconsistent results, and often serious problems. What's more, the same is true for sysV, Upstart and every other init system as well.
If you don't understand how such things work in systemd, there's a whole raft of documentation that will explain it to you in long and painful detail.
It's clear that you don't really understand how to use and configure systemd effectively. As such, it would make sense to either learn what you'd need to know to do so, or use a different init system.
Personally, it's not a huge deal to use systemd (specifically the init system -- just about all the rest of the systemd-<whatever> stuff is redundant and inferior to other, existing tools, which is why I ensure they are disabled/masked on all my systems). SysV and other init systems work very well, and I've used most of them over the past 30 years or so.
And so, yes. If you're going to use a distro that features systemd as its init system, then you definitely should get a clue and learn how it works. Otherwise, you're just asking for problems. As you've already discovered.
(Score: -1, Troll) by Anonymous Coward on Wednesday December 11 2019, @12:03PM
So many words to say "I'm confused".
AC wrote "black magic" in regards to changing dependencies between services, not to how disabling or masking works.
Letting you know that NetworkManager depends on systemd-resolved on other systems is very useful information, but you are blinded by hubris.
Looks like you have more learning to do. Otherwise, you will have problems when systemd gets updated.
(Score: 0) by Anonymous Coward on Wednesday December 11 2019, @11:03PM (3 children)
You are saying a lot about things not about my point. My point isn't how to disable anything or how dependencies actually work or anything to do with init systems, even systemd. I understand that using "Wants," "Requisite," "Requires," etc. you can make anything depend on anything else. I also understand hard vs soft dependencies and explicit vs implicit dependencies. But none of that is the issue I was attempting to raise.
What I was pointing out is that usually there is some logic as to why things depend on each other, especially by default, as shown in the examples I provided. In the case of NetworkManager and systemd-resolved, that is broken because you have one system where the relationship goes one way and another where it goes the other. There is, apparently, no logical order to the way those two services are related, which is somewhat fascinating given what they are supposed to do. That is the point, the entire point, I was attempting to make, with everything else being aside or conceptual fallout.
(Score: 0) by Anonymous Coward on Thursday December 12 2019, @01:54AM (2 children)
I'd venture to guess that the publishers of any specific distro have reasons (whether they are good reasons or not) as to why they set the default service dependencies the way they do. That such defaults aren't the same between different distros isn't surprising, or very interesting -- at least not to me.
Given that many distros rely, by default, on NetworkManager to bring up networking and systemd-resolved requires the network to be up in order to function, it's not surprising that there would be some sort of dependency there.
Are you arguing that there should be a "standard" set of dependencies across every distro? That would be a pretty tough row to hoe, IMHO. What's more, I don't think it's a good idea. Distros differ because they have different foci and/or provide different sets of functionality. I like that there are many different distros myself.
If consistent configuration is important to you, perhaps you should just settle on one specific distro and use that -- then you won't have issues with differing default dependencies.
Perhaps I'm missing something important? If so, do tell, as it's not clear to me what makes this important or relevant.
(Score: 0) by Anonymous Coward on Thursday December 12 2019, @04:22AM (1 child)
Exactly, there is an underlying logic available as to why systemd-resolved should depend on NetworkManager (or alternatives like connman, wicd, systemctl-networkd, etc.). But then you have other systems where NetworkManager depends on systemd-resolved, ostensibly because it requires some feature of it like resolving a domain or network name to function. That is what I find interesting. Either the technology behind them changed or the packagers' thinking differs to the point where the services relationship reversed. Its not that there should be a "standard" or that all of them be the same; its that there is usually an underlying logic to any human system. Different strokes for different folks, but I find the underlying idea of such a reversal fascinating, and somewhat "magical" (to harken back to an earlier term). As if next year the packagers made it so that bringing up your network required ssh or nginx running or your X server refusing to start if a client didn't load. Regardless, there would have to be some major differences in either the thought process or the underlying software for such to occur.
(Score: 0) by Anonymous Coward on Thursday December 12 2019, @09:25PM
I have some ideas about that, with the caveat that I don't have any actual information from those who made such choices.
As you're almost certainly aware, even if you disable a service, it can still be started by another service that declares it *either* dependent on that service, or dependent on *another service* that's dependent on the disabled service. That dependency tree can be several levels deep.
Which is why the 'mask' (which keeps a service from starting under *any* circumstances) command is necessary for systemctl/systemd. If any service can start any other service simply by asking for it (or having a dependency or even a dependency of a dependency do so), that's a *huge* security and stability risk.
Interestingly, on both Fedora Core 30 (RH-based) and MXLinux 19(Debian-based), the NetworkManager (/usr/lib/systemd/system/NetworkManager.service) unit file specifies:
[Unit]
Description=Network Manager
Documentation=man:NetworkManager(8)
Wants=network.target
After=network-pre.target dbus.service
Before=network.target network.service
---snip---
[Install]
WantedBy=multi-user.target
Also=NetworkManager-dispatcher.service
# We want to enable NetworkManager-wait-online.service whenever this service
# is enabled. NetworkManager-wait-online.service has
# WantedBy=network-online.target, so enabling it only has an effect if
# network-online.target itself is enabled or pulled in by some other unit.
Also=NetworkManager-wait-online.service
[emphasis added]
And the systemd-resolved (/usr/lib/systemd/system/systemd-resolved.service) unit file specifies:
---snip---
[Unit]
--snip---
DefaultDependencies=no
After=systemd-sysusers.service systemd-networkd.service
Before=network.target nss-lookup.target shutdown.target
Conflicts=shutdown.target
Wants=nss-lookup.target
---snip--
[Install]
WantedBy=multi-user.target
Alias=dbus-org.freedesktop.resolve1.service
[emphasis added]
What's more, neither one starts systemd-resolved by default. Out of curiosity, which distributions did you look at that not only started systemd-resolved by default, but also had the dependencies juxtaposed?
I wonder if the folks who maintain the distros you looked at have some published reasoning behind their choices.
(Score: 0) by Anonymous Coward on Wednesday December 11 2019, @07:37PM
Who says every distros must/should/can apply the same sets of dependencies in their init system? That's not (and never has been) the case for other init systems across distros, so why should it be so for systemd?
By making sure you actually understand how this stuff works/is supposed to work. And different distros do things differently -- if they didn't, they would be the same distro. That's really freaky, right? I'm getting chills just thinking about it.