While the use of systemd by most Linux distros remains a subject of controversy, the recent vote by Debian members to support systemd while exploring other alternatives seems to indicate the init system is gaining acceptance.
The Debian distribution does not speak for the whole of Linux. However, it is the source of many popular distros, including MX Linux, Linux Mint, and Ubuntu. For that reason, there is a sense of finality in the news that Debian has resolved to focus on systemd as an init system — the first process to run on the system, and the manager of all the others – while exploring alternatives. Six years after Debian’s Technical Committee decided to use systemd, in effect the experiment has been declared a success, although a qualified one.
The decision to use systemd was revisited in December 2019 because of the proposal to include elogind, which forks the systemd-logind daemon, but does not require all of systemd. The members of Debian voted on seven proposals, which I paraphrase here as:
- Focus on systemd.
- Support Systemd, but support exploring other alternatives.
- Support portability without blocking progress.
- Support non-systemd without blocking progress.
- Support portability and multiple implementations
- Support for multiple init systems is important.
- Support for multiple init systems is required.
The winning option was to support systemd, but to explore other alternatives. By contrast, officially supporting multiple init systems was the first to be dropped in the multiple rounds of Debian’s complicated Condorcet voting system, no doubt because it would seriously complicate packaging many applications.
Clearly systemd has reached a level of acceptance that would have been unimaginable when it was first introduced eight or nine years ago. In fact, probably no other application had been so reviled since Mono, the Linux version of Microsoft’s .NET Framework. Critics claimed systemd’s centralized controls violate the Unix philosophy of using one small program for a single, limited purpose. Since systemd was developed by Red Hat, others viewed systemd as part of a ploy to dominate the Linux desktop.
On the technical side, many considered systemd as an unnecessary overlay of existing functions. Systemd was also condemned as making the entire system easier to crash, and acting on different assumptions from the rest of the system. Others praised elements of systemd like the systemctl command while objecting to the binary logging system. The wide-ranging debate was often venomous, and the venom often spilled over into personal attacks on Lennart Poettering and Kay Sievers, systemd’s original developers, who sometimes responded in kind.
Today, systemd is regarded differently. Arguments about the true Unix philosophy have proved moot, and the worst case scenarios have not materialized. Probably, too, the fact that most distributions use aliases to integrate systemd keeps non-administers unaware of its omnipresence.
In proposing the winning option, former Debian Project Leader Martin Michlmayr argued foremost that, “Cross-distribution standards and cooperation are important factors in the choice of core Debian technologies. It is important to recognize that the Linux ecosystem has widely adopted systemd and that the level of integration of systemd technologies in Linux systems will increase with time.” For Michlmayr, the technical benefits of supporting multiple init systems do not justify the efforts required.
Michlmayr went on to say, “Debian can continue to provide and explore other init systems, but systemd is the only officially supported init system. Wishlist bug reports with patches can be submitted, which package maintainers should review like other bug reports with patches. As with systemd, work should be done upstream and in cooperation with other Linux and FOSS distributions where possible. The priority is on standardization without the reliance on complicated compatibility layers.” In effect, the vote was a decision to keep the status quo into which Debian had drifted into during the last few years, while leaving room to respond to changes in technology. Since, as Mchlmayr states, other distributions are in a similar position, there are few reasons to think that many of them would decide differently.
The resistance to systemd has not died with this decision, of course. Distrowatch continues to list one hundred distributions that do not use systemd — a minority, but a large and determined one. Those opposed to systemd still have plenty of choice, including Debian derivatives like Devuan and Knoppix. But if cautious, ultra-democratic Debian can opt to retain systemd, then it seems here to stay for the foreseeable future.
Bruce Byfield has been involved in FOSS since 1999. He has published more than 2000 articles, and is the writer of “Designing with LibreOffice,” which is available as a free download here.
Are you serious? It’s back to the Byfield show, what did you pay to take editorial of this site? Where are other writers with more varied views that are more critical of the facts?
Those that care about not using systemd moved away; that left mostly those that were interested in using systemd as a concentrated base.
It’s like having a vote about Jesus in a Christian church; or less politely, voting for the devil you know when only devils continue to exist there.
Debian is loosing more and more reputation. No payed pro-systemd-article can buy that back.
@systemd refugee: FOSS Force does not publish “sponsored” content or accept payment for any articles we publish.
I’m not a big fan of systemd either, but I note that both the people criticizing the article have chosen the ad hominem route, insisting without evidence that Bruce is a paid shill, rather than debate him on the merits of his post.
>Today, systemd is regarded differently.
Depends who you ask. It has been forced on most without any choice by the user. Hardly a ‘free and fair fight’. Hey ho.
> Arguments about the true Unix philosophy have proved moot,
Please… moot is too argue or debate. So your statement reads:
“Arguments about the true Unix philosophy have proved to be argued”
Meaningless mumbo jumbo, like much of the rest of it. Where is the editor round here?
> and the worst case scenarios have not materialized.
Yet.
> Probably, too, the fact that most distributions use aliases to integrate systemd keeps non-administers unaware of its omnipresence.
‘administrators’. Might have been easier for you to use ‘users’.
But yes…. they can’t be open and honest about it can’t they?
And yes, omnipresent is one way to describe the gaping black hole that is systemD. Tentacles everywhere and a fight to get a system doing what I want, rather than what systemD wants.
I personally don’t care what system init. is used, as long as it works. I know it is a very controversial subject, as you can see from people making all kinds of accusation. Operating developers are free to use the system they prefer, and don’t even need to start from scratch, i.e. Devuan. As a user you do have a choice, and that is why I at least you Linux and not Microsoft of Apple. I really don’t see the need to disparage others.
Also thank you Christine for straightening out the paid advertising.
Bruce, that’s a pretty good block diagram of systemd at the top of your article. Could you tell us why you have all the blocks, but not the interaction lines between them? Could you tell us why *nobody* has published a block diagram with interaction lines? Could it be that such interactions are too complicated to document in an understandable way?
Contrast this with the following block diagram, with interactions, of daemontools:
https://tinyurl.com/mm-daemontools
The preceding is pretty much the same as the process supervisor part of systemd competitors runit and s6.
Also, Bruce, your article is slanted. It mentions “Distrowatch continues to list one hundred distributions that do not use systemd”. A hundred sans-systemd distros is hardly a resounding victory for systemd.
You mention “Arguments about the true Unix philosophy have proved moot”. What judge rendered that ruling? This proclamation is just your opinion.
You assert, “But if cautious, ultra-democratic Debian can opt to retain systemd, then it seems here to stay for the foreseeable future.” I see the situation differently: The systemd debacle gravely damaged Debian’s “democratic” reputation. Read the following to see just how undemocratic the decision was, paying particular attention to the summary relegation of discussion of whether Systemd would be the only init to a sidetrack thread:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
Warning: Big doc, slow server
Glaringly missing from Bruce’s article is any mention of systemd modern competitors runit and s6, which continue to make inroads in the Linux marketplace and mindset.
Others may differ, but my view of Bruce’s article is that it’s more innuendo than facts, and insults the intelligence of Linux users.
@systemDisLindows:
> Please… moot is too argue or debate.
Definition 2, guy.
https://www.dictionary.com/browse/moot
And FYI, it’s “to”, not “too”.
It’s funny how people assume that acknowledging what is happening means that you are in favor of it.
Such personal attacks hardly deserve a civil answer. However for the record, I have never seen the need for systemd myself. It seems to complicate things in a way that hardly seems justified.
At the same time, some of the reasons for disliking it strike me as absurd. If you want to see a Red Hat plot to take over the desktop, a far better piece of evidence can be found in gnome-boxes, which, although an excellent virtualization option, emphasizes Fedora and RHEL in its interface in a completely unnecessary way.
As for runit and s6, they are interesting, but they were not even in the running in the Debian general resolution, except in a general way. Mentioning them, though, does suggest a good topic for a future article.
From Christine Hall: “@systemd refugee: FOSS Force does not publish “sponsored” content or accept payment for any articles we publish.”
Nor do I write sponsored articles nor accept payment from anyone except the site or magazine in which content by me appears. The assumption that I would is deeply offensive — all the more so because it has no evidence whatsoever.
The problem is that we have people shouting the same argument at each other for years now. Please just shut up! It should be obvious by now that neither side will convince the other!
Please just go your separate ways and do your thing.
“Arguments about the true Unix philosophy have proved moot,
Please… moot is too argue or debate. So your statement reads:
“Arguments about the true Unix philosophy have proved to be argued”
Please, don’t try to school an English major who publishes regularly. FYI, “moot”‘s meanings include “points that are still unresolved but are beside the point.” If you hadn’t stopped at the first meaning that pleased you, you might have learned that for yourself.
@Bruce: Your article was referenced on the Devuan mailing list (https://lists.dyne.org/lurker/message/20200203.151133.dc71adf3.en.html).
That’s where the wierdos come from all of a sudden.
‘Foobar’, you mean weirdo comments like this one, the immediate response to the one you linked?
https://lists.dyne.org/lurker/message/20200203.163253.5e39e7ff.en.html
I will perhaps find time this evening to try to make some useful comments, but doing so rather than posting insults or dredging up prepared semi-idiotic talking points, takes time.
— Rick Moen
rick@linuxmafia.com
@Rick: No, more like the first two comments here and that one from Steve Litt.
I am looking forward to your well argued postings.
Foobar, I thank you, and hope I do have time. FWIW, Steve Litt is a friend of mine, and I profoundly respect (mostly, most of the time) his comments when he isn’t, himself, shooting from the hip. For the record, he is likewise a Devuan ‘Dng’ mailing list regular.
— Rick Moen
rick@linuxmafia.com
(mathematics major, but like the estimable Mr. Byfield able to read and comprehend multiple entries in a dictionary; mirabile dictu!)
Where to start with this…
The author seems to have taken pro-systemd arguments at face value and applied no critical thinking or analysis.
The first failure is to accept the “it must be good, most distros have adopted it” fallacy. Most distros have taken it on for the simple reason that the systemd folks were quick to get it’s tentacles deeply embedded in certain popular software so it became difficult to rip it out. Add that in the early days it was excused as being “just another init, you can easily replace it” – thus sidelining criticisms until it was entrenched.
As to Debian voting for it (the first vote), if you look at the vote it’s easy to show that really they didn’t. It’s only the way the vote was arranged that made it appear to be a positive vote.
The most recent vote is really “we can’t rip it out now because it’s too entrenched, but we’ll tolerate alternatives if someone else does all the work”. In reality, that means carrying on letting systemd metastasize through more and more software – while it gets harder and harder to remove.
Then lets look at the statement that it’s now accepted more. Amongst people that undetstand, it is even less accepted now – it’s become clearer just how far the systemd people want to embed it in the system, making it ever harder to rip it out.
It wouldn’t have been quite as bad if it was quality code – when Linus bans kernel submissions from their devs, you know there’s something wrong !
Lead devs have a track record in poorly designed & buggy code – not to mention their attitude to labelling bugs as “won’t fix”. They’ve shown no regard for the idea of compatibility – seemingly intent on replacing time tested utilities with something new and incompatible. It appears as though this is part of the plan, making it ever harder to write code that runs in traditional environments as well as under systemd.
And these “new & improved” tools often are far from improved. Take their replacement for ntpd – which breaks real-time stuff like cnc while offering zero benefits to justify it’s existence.
I have systems held at Debian Wheezy while I waited to see how things worked out. I’m in the process of moving them to Devuan because I value reliability and maintainability.
If something goes wrong I want to be able to debug it – not just reinstall the system like many Windows faults. Just because you personally haven’t heard of big problems caused by systemd’s monolithic and undebuggable boot system doesn’t mean othets haven’t. I haven’t crashed a car – but I still wear a seatbelt and have insurance.
@ Karl Napf
“Please just go your separate ways and do your thing.”
Most if us would love to. If systemd folk wete prepared to do thatvthen we’d not be having these discussions. I really don’t give a toss if people actually want to use systemd, and I think you’ll find that most people on this side of the fence would agree.
The problem is that on the systemd side of the fence, there appears to be no attempt whatsoever to co-exist with other inits or tools. Quite the reverse – it appears to be policy to ignore such niceties and just keep forcing software devs to choose between incompatible interfaces, or put a lot of effort into duplicated code.
@Simon: Most developers out there do not care for systemd one way or another. They will use whatever offers to solve their problems and if systemd does and nobody else bothers, then they will go for systemd.
Provide alternatives and developers will support those, too.
But so far no such alternatives are forthcoming. There apparently are 100 non-systemd distributions out there. Surely you can find some developers there that can implement real alternatives to systemd! And I am not talking about re-implementing systemd APIs, but entirely different solutions to the same problem!
The init system itself is pretty irrelevant by the way. Nobody cares whether that is done by systemd, s6, runnit or whatever! Logind, tmpfiles.d, sysusers.d and now homed are all way more important.
“The author seems to have taken pro-systemd arguments at face value and applied no critical thinking or analysis.”
Again, you confuse observation with taking a position.
More importantly, you obviously missed the point. I had no interest in rehashing the arguments of previous years. I only observed that major distributions like Debian seem to have made a decision through their actions.
I would welcome anyone’s reply to the arguments made by Debian in favor of systemd. That would be a useful contribution to the discussion. But please, do not attribute those arguments to me simply because I reported them.
@foobar
Thanks for mentioning my name and my post. As a person who backs up his assertions with facts (disparity of block diagrams, for instance), it’s gratifying for me to be named by those appreciating factual posts.
What I appreciate most about your acknowledgement is the recognition that facts matter: The undocumentable architecture of systemd, the 100 sans-systemd distros (although that was actually reported by Bruce, not me), or the existence of the powerful s6 and runit alternatives, to name a few.
Let’s start with an easy agreement, Bruce: Indeed, (most) major distributions including Debian seem to have made some sort of decision through their actions. Which, it turns out, doesn’t actually mean much, a great deal of inertia being involved.
Back shortly after the Debian 2.0 ‘hamm’ to 2.1 ‘slink’ transition, after it became obvious that promising candidate Stampede Linux would not be a long-term option, I adopted Debian for major system builds; stable for other people’s production boxes, and testing/unstable with apt-pinning for my own. One of the first things I learned about Debian as a project (partly on my own and partly from DD-hat-wearing work colleagues) was that Debian Project would make eccentric policy choices occasionally, but that with only modest sysadmin attention and learning some Debian-specific tools, I could countermand any IMO-wacky Debian Project policies with my own — and I’ve done that ever since.
The systemd init-with-other-things codebase arrived along with an ever-changing marching band of related and frequently orphaned/rewritten Freedesktop.org software and caused a huge fuss primarily within DE-centric desktop computing in minor part through some often hilarious gaffes (like systemd-resolved badly breaking system security) that suggested poor design and inattention to detail, but in greater part through epically excessive and intertangled codebase dependencies. We professional sysadmins, IIRC, barely noticed the squabble, because the obvious solution to (e.g.) excessive GNOME dependencies was to eschew GNOME; problem solved. In this light, Debian Project’s first General Resolution fight on the systemd matter struck me, at least, as to have oddly misdefined the problem: The GR took as unquestioned the need to remain GNOME-centric even though the crisis’s real cause was the entire distro getting dragged along by GNOME’s absurd mandating of deservedly obscure ‘multiseat support’ for all systems, leaving GNOME3 in the lurch when Freedesktop.org’s ConsoleKit became deprecated and was to be dropped. The gdm3 display manager included ‘multiseat’ in its required spec, ConsoleKit had filled that checklist tick, and now it was going away. Loosely speaking, the GR said ‘Should we force-migrate to systemd as our supported init system? Its systemd-logind component ticks that checklist item.’ Nobody ever put it to the assembled Debian developers whether the entire project cared about multiseat, nor the even better question of whether this wouldn’t be an excellent time to dump GNOME as a distro architectural essential. So, the GR wheeled Debian Project in an odd direction for wacky reasons — but my cadre of sysadmins didn’t need to care much because local administration remained more powerful than IMO-wacky distro policy moves, because, well, we have root and know how to use it to countermand that. (I do mostly servers. My ‘desktop’ systems are, typically, deliberately pared down and thereby sidestep DE-based problems.)
And there matters have largely rested. Countermanding intrusions into Debian of systemd, PolicyKit, upower2, and all the rest of the Freedesktop.org marching band of frequently replaced betaware remains a pretty simple task of local administration. My friend Steve Litt and many others argued with me on this matter for years, claiming it was utterly impossible to run Debian 8 ‘jessie’ (in particular) without systemd. I got tired of hearing rhetoric without data, and set up a VM test platform with Debian 8, expunged systemd with OpenRC (other choices, almost all of them available as functional binary packages are equally feasible), and documented on a Web page entitled Debian 8 “Jessie” OpenRC Conversion, explicitly stating the simple steps and the (very few) problems and how to work around them.
The next time I was advised it was impossible to run Debian 8 without systemd, I dropped the URL into the discussion and said ‘Gosh, hard data seem to disagree.’ No need for advocacy rhetoric. I just did the obvious, it works, and I documented the actual reality. This outcome seemed to have flummoxed some devoted arguers on the subject, as I didn’t argue, but rather just showed my work. Steve’s fallback position amounted to ‘Ah, I guess you’re right, but it’ll never work with Debian 9 when that’s released.’ Surprise, same testing, same methods, same results. I believe his fallback-fallback position is currently ‘You’re able to administer Debian systems your way now, but soon nothing you do will suffice, you’ll be sabotaged from deep within the system, and you’ll be unable to apply local policy.’
This wounds me, just a bit: I’ve been applying Rick Moen local policy to Linux machines and overriding where useful distro policy since 1993. And it’s called system administration, guys.
Attentive readers will note that nowhere in the above is any systemd argumentation, familiar or non-. When I ran Slackware and Patrick made a dumb architecture move, I used system administration to adjust it. Later when I mostly used Red Hat Linux and RHAT made a dumb architecture move, I used system administration to override it. If Stampede Linux had lasted longer, probably I’d have needed to do that in places, too. Debian? No different: In all of those cases, I didn’t get angry and flood mailing lists with impassioned pleadings for packagers to do as I wished. That’s neither productive nor even dignified. I always instead just treated the packager as damage and routed around him/her (to paraphrase the late John Perry Barlow).
I really have no use for arguments. I care about running code and doing administration my way following my policies. And where Debian or any other distribution places a default obstacle in the way of those personal objectives, I remove the obstacle and move on.
Getting back to Bruce’s piece, he finds notable that ‘Debian has resolved to focus on systemd as an init system’ (which is a rather sloppy and inaccurate restatement of the recent GR results, but let’s set that aside). I simply do not find it notable. Largely all Debian Project has done in the recent GR is set a small policy bias about what pressure will be brought onto DDs to ensure that lots of init systems remain always guaranteed to be full equal citizens out of the box. Shocker! The DDs opted through a cramped and constrained Condorcet ranked-choice voting process to let DDs float forwards following their own inertial forces. It’s almost as if they maximise personal convenience or something, and gosh, who knew?
Bruce finds it significant that Debian Project is ‘ultra-democratic’, an ideological term that upon examination doesn’t in my experience say much, except that on rare occasional when functioning as a parliamentary body, each DD has one vote and nobody who’s not a DD has one at all. On a functional level, however, Debian Project is actually steered day to day, and in all but extreme cases, by key figures such as members of the ftp masters group, and on a micro scale by individual DDs being variously peculiar and mulish, closing bugs they don’t like for specious reasons, etc.
Last, Bruce is impressed that if ‘ultra-democratic’ Debian Project can retain systemd, then ‘then it seems here to stay for the foreseeable future’ (as if systemd were subject to an eradication effort, but were evading the cans of figurative pesticide). I’m not impressed. I remember when we were all going to be running the Linux Standard Base and would be having no choice about that. Funny world, isn’t it?
Rick Moen
rick@linuxmafia.com
(Not bothering to waste time fisking various reader comments especially the pseudonymous ones, and I don’t accept homework from them about how I’m expected to provide ‘well argued arguments’. If you wish to set my agenda, you’ll need to offer consulting money, two hour minimum, and I would more than likely decline the business.)
It’s been 10 years of this fight and I just don’t understand what it’s even about anymore. I use whatever init system a distribution has and if I need a different one I just switch distributions. Alpine is like the most widely used distro since the dawn of containers and uses open.rc or whatever its called and I don’t see it loosing any steam. I actually started using alpine in most of my containers due to its small size and I love it. Also open.rc init scripts are so easy to write and well documented. Everyone has options so if you don’t like systemd just don’t use it.
But in contrast to my love for alpine and microservices when I’m installing a hypervisor or baremetal server I don’t want 6 separate services to manage something that systemd does in a single monolithic package. If I even see that I’m missing systemd in a distro that is baremetal I just replace it with a systemd alternative.
Its so good It shouldn’t even be open source. I would be willing to pay for such a functionality and just having it for free and people complain? Honestly I hope systemd gets kicked out of distros and goes into a payment model. I sure it would mean more money and more success for the developers.
The diagram of systemd components is missing one significant piece, udev. Which is probably the number one reason for systemd’s wide acceptance. When udev was absorbed into systemd it left developers with few options. You could use an old version of udev or use Busybox’s mdev, or write your own. Because of this Gentoo forked udev, so now at least there’s a viable alternative.
An (IMHO) honest look at systemd.
To be up front, I do not like systemd for a variety of reasons, but I don’t hate it or its developers. I was a longtime user of Debian before the rise of systemd, but prefer non-systemd systems today. I respect Debian’s commitment to software freedom and realize they are trying to strike a balance between ease of use and complexity that is more difficult to maintain than most realize. I don’t think their latest decisions reflect on more than that.
I think a lot of the systemd acrimony is caused by people talking past each other. We all have different goals and desired behavior from our systems. ‘Correct’ is in the eye of the beholder. I was going to list pros and cons of systemd, but really most things can be both depending on expectations, so I’ll just list things I’ve observed and some opinions.
Auto-magical runtime system configuration – For lots of people this is a pro (not everybody though). systemd and its associated spiderweb of dependent code can handle a lot of scenarios transparently such as changing hardware, service states, and network details. This can be accomplished without systemd surely, but that complexity has to live somewhere in any case. This can become a difficult problem when the auto-magical thing doesn’t behave as it should. The problematic behavior may lie deep in systemd’s code and its authors’ assumptions on the ‘correct’ behavior. Not every system needs dynamic management of the kind systemd provides and the added complexity may not be welcome.
Easy configuration without scripts – More people can create/edit systemd’s unit files than are capable of writing management scripts. This is less flexible than scripting naturally, but sometimes the extra flexibility of scripting isn’t needed. Behavior is often reliant on assumptions in systemd’s code which may conflict with the user’s.
Supported by lots of distros and packages. Also, hard to avoid as one single desired package may drag in systemd’s entire spiderweb of dependencies. This is (again IMHO), more than anything else in systemd, a sign of bad design and one of the reasons I don’t like systemd.
Authors? Lots of anger directed here, but I really don’t care who writes the software I use. As a user I do care that authors are open to other points of view and responsive to user concerns. There does seem to be some evidence that systemd authors can handwave user concerns if it doesn’t fit their goals. As a developer I also understand that you cannot accomodate everybody and flexibility breeds complexity. This is a wash for me, but I understand why some people get upset about it.
Faster boot? This was an early claim of systemd that used to be sort of true, but isn’t really anymore and isn’t particularly claimed by its authors either. It still gets repeated in arguments so I included it here.
“If systemd is bad, why are there no alternatives?” There are plenty. The mistake people make is assuming alternatives should do most of what systemd does, which is precisely what some people do not want.
Personally I prefer less complex systems where I can manage the level of automation myself via scripts, but that isn’t everyone’s cup of tea.
I would want to know what’s in that “tiny proprietary unharmful” component that was announced as an essential part of systemd, for I think this is where the “freedom” in many distros, went to the garbage bin.
At the risk of being branded a heathen or a religious fanatic (two sides of the same coin?), I think that the diehards who despise systems should try taking a step back. I am not alone in finding a consistent, broad, and fairly straightforward approach to the underlying daemons of Linux to be a great improvement over the status quo ante. Since Arch went with systemd, I’ve been able to assert control over my system that had not been easily possible before.
I understand that some people hate change or believe that anything except their old ways is blasphemy, but we all have to be able to adjust. Or not. If you don’t like systemd, don’t use it. But leave those of us who love it alone.
Dojero,
> I understand that some people hate change or believe that anything except their old ways is blasphemy, but we all have to be able to adjust. Or not. If you don’t like systemd, don’t use it. But leave those of us who love it alone.
Believe it or not, there are plenty of reasons not to like systemd that are perfectly valid and have nothing to do with ‘hating change’.
> But leave those of us who love it alone.
Do you feel persecuted? Many of the people who never wanted systemd yet saw their distros adopt it en masse felt exactly that way.
Actually, I don’t doubt that many reasons exist for disliking systemd. The point is that both sides have good reasons for their views. There are also many invalid reasons for both sides, like hating change.
No, I don’t feel persecuted. I just feel tired of the strident nature of many who dislike systemd. I really have trouble understanding why those who want systemd can’t use it in peace, and those who don’t, don’t.
Dojero,
> I really have trouble understanding why those who want systemd can’t use it in peace, and those who don’t, don’t.
I think for the most part that’s really what happens, but that doesn’t make for exciting clickbait headlines and troll fodder.
I don’t like systemd, so I simply avoid distros that have it. I know people who like it and it does not bother me that they do. I actually get why some people like it. It’s just not for me and likely never will be.
The one thing I don’t like about systemd is its reliance on non-human-readable data files.
Other than that, it’s an init system that is Free Software, specifically the GNU LGPL. Therefore, other than the binary data file formats, I don’t mind it. It works, and it does the job. I did resist it at first because of the new syntax, and humans do have a natural resistance to change. I felt similarly about iptables when it first came out (I’d used ipfwadm and then ipchains). But as long as it remains Free Software, then like 389 Directory Server, I see no problem with including it in GNU/Linux distributions. It’s just a matter of getting to know the new init system.
So, let’s stop with any further ad-hominem attacks and learn the new system as well. Clearly, it’s here to stay, and most importantly, *it is Free Software*. Should the authors of systemd try to take future versions proprietary like Oracle hinted they would with MySQL years ago, we’d fork it like with MariaDB. So, no worries, folks.
–SYG
The issues relating to binary log files and non-human readable configs is probably not that significant if you have the tools to work with them properly.
But systemd is a one way street, it is not so simple as take it or leave it. More and more non related system components are being drawn in to the systemd bucket over time; Pottering has stated goals to make “his” version of Linux…. it isn’t “our” version of Linux anymore if it contains systemd and the more he does so, the less we’ll be able to remain independent of the systemd problems.
If it was a simple as take it or leave it, then systemd would never have been anywhere near as controversial. The fact is that systemd is a huge departure, in a bad way, from traditional systems that kept Unix and Unix like systems fully functional for many, many years and still does today.
@Sum Yung Gai
> So, let’s stop with any further ad-hominem attacks and learn the new system as well. Clearly, it’s here to stay, and most importantly, *it is Free Software*
No thanks.
It is Free Software, but that doesn’t mean it is good software.
I don‘t get some linux nerds. Sorry my take : You’re supposed software engineering principles are as ancient and outlived as it gets, to say the least. And from pure ethical point of view: this ugly infighting and spreading of hate, which even the great Linus participated, gives me the creeps. The equally greaz Coplien once said : software engineering is a socio – cultural undertaking, the resulting software systems reflects your society. Second that. For me systemd is terrific and actually makes Linux relevant ….. and yep i coded my perl 25 years ago and still do if opportunity , compiled gcc from source etc …. but the world changed since then dramatically and with it software engineering…. if there one constant, is the constant learning… best in active way. That’s also what systemd is about for me. No „tragedy“ about that at all, to anti quote Benno Rice.