Yeah, yeah I know the history of its development and how log files are binary and the whole debug kernel flag fiasco. And I don't care. By the time I used systemd, that had already long passed.
I switched from Squeeze to Jessie a couple years ago, had some growing pains as I learned how to use systemd... but that was it. No stability issues, no bugs. Can't say whether things run better, but they definitely don't run worse.
I had only really been using Linux for a few years before the onset of systemd, and honestly I think that's part of the problem. People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change". Whether its nostalgia or sunk-cost fallacy, I can't say, but beyond that it seems much more like a philosophical difference than a practical one. It just reminds me of people's refusal to use the metric system, for no better reason than they are unfamiliar with it.
If systemd is so terrible, then why did a lot of the major distros switch over? If they didn't, it would just be a footnote in the history of open source: "Hey remember when they tried to replace sysV and init with that stupid thing with the binary log files? What was it called? SystemP?" The fact that Devaun has not overtaken Debian in any real way (at least from what I've seen, feel free to correct me if I'm wrong) indicates that my experience with systemd is the norm, not the exception. The market has spoken.
I read TFA, there is not one single specific bug or instability mentioned about systemd. What is the "tiny detail" that split the community? I have no idea, because TFA doesn't say what it is. I know that part of the philosophy behind Linux is "figuring it out yourself", but if you don't explain to me these low level kernel details (if that's even what they are; again, I have no idea), then don't expect people like me to be on your side. Linux is just a tool to me, I don't have any emotional attachment to it, so if things are working OK I am not going to start poking around under the hood just because someone posts an article claiming there are problems, but never specifying what those problems are and how they affect me as a user.
Honestly TFA reads like "We are having development problems, therefore systemd sucks." I get that when major changes to the platform happens there are going to be issues and annoyances, but that's the way software development has always been and will always be. Even if systemd was perfect there would still be all kinds of compatibility issues and new conventions that developers would have to adapt to. That's what I would expect to happen whenever any major change is made to a widely used and versatile platform like Linux.
"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."
I'm not saying systemd is "better" or "the right answer". If you want to stick to distros that don't use it, that's up to you. But what I am saying is, get over it.
Perhaps you have had no problems with systemd because you aren't trying to use it to do much.
Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues. If someone asked me for examples, I'd have a hard time deciding where to start because so many things have been gratuitously changed. If you really think there aren't examples, just read this thread.
On the other hand, I have yet to see real technical discussion about problems that systemd apparently is fixing. I honestly and openmindedly am curious about what makes systemd good, so I've tried on several occasions to find these discussions where good technical reasoning is used to explain the motivations behind systemd. If they exist, I haven't found any yet. I'm hoping some will appear as a result of this thread.
But you bring up the idea that the "market has spoken"? You do realize that a majority of users use Windows, right? And people in the United States are constantly electing politicians who directly hurt the people who vote for them more than anyone else. It's called marketing. Just because something has effective marketing doesn't mean it doesn't suck.
Don't let the perfect be the enemy of the good. If you have so many examples that you "don't know where to start", then start anywhere. You don't have to come at me with the best, most perfect example. Any example will do! I'm actually very interested. And I have, out of curiosity, looked a bit. But like you looking for why systemd is better, I came across a similar problem.
Your reply just continues the cycle I spoke of, where people who potentially know better than me, like you, claim there are problems bu
systemd fails silently if something is wrong in/etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged/etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying. Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
The problem is that one camp won't admit that old init is a pile of shit from the 80's whose only virtue is that the stench has faded over time, and the other camp won't admit that their new shiny toy needs to be understandable and debuggable.
A proper init system needs dependencies and service monitoring. init + monit does not cut it today. Systemd does that bit rather impressively well. It's just terrible at actually booting the system, all the early boot stuff that you could depend on old init to get right every time, or at least spit out aggressive messages about why it failed.
Meanwhile here I am, running Gentoo, with init scripts that have had real dependencies for over 15 years (as well as a bash-based but much nicer scaffolding to write them), with simple to use admin tools and fully based on text files, with cgroup-based process monitoring (these days), and I'm wondering why everyone else didn't get the memo and suddenly decided to switch to systemd instead and bring along all the other baggage it comes with. Debian and Ubuntu had garbage init systems, and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half. You can also use systemd with Gentoo if you want, because user choice is a good thing.
and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half.
Gentoo does everything right except exist. On alternate days you can follow the install instructions identically and get totally different results. Gentoo is its own worst enemy.
With that said, lots of people have screamed often and loudly in many locations that Gentoo proves that this stuff is possible without systemd, and that there are at least two init systems which were already in relatively common use when systemd was shat out which support parallel init. This has simply been resoundingly ignored by t
I ran Linux on the desktop (and LOTS of servers) for 19 years, but finally got Mac religion about 4 years ago. As I had used Gentoo for about 5 years over this time, I was wondering how they had handled this. Found this: https://wiki.gentoo.org/wiki/G... [gentoo.org]. Looks like it's just as straightforward as I would have hoped, and the documentation was just a clear as usual for the project. It actually makes me want to emerge a new desktop system, just for old time's sake.
At one point I did have exactly the problem addressed in the article; I followed the steps therein, and the problem went away, and hasn't recurred since. I won't pretend I've never had issues with Gentoo; I have, although probably 80% turned out to have been self-inflicted. Nonetheless I find that it has bought me valuable time to not have to deal with all the systemd nonsense so long as I don't try to run Gnome, which I wouldn't anyway (I prefer XFCE). I've no doubt that sooner or later I will be forced
systemd fails silently if something is wrong in/etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged/etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
It retries for a bit, but it DOES eventually fail and kick you out to a recovery shell. It just doesn't do it immediately because it assumes that the device may just need some time to come up.
Thanks to the binary log files you cannot even boot something random and read the logs,
What do you mean "boot something random"? I don't see why a generic recovery disk can't have journalctl installed. How about a Debian install disk?
but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
Not true at all. If you don't know how to use journalctl, that's on you.
Nothing pertinent to the error was logged. Feel free to not believe it.
I don't believe it. Feel free to provide details on how you were looking through the logs.
It did not fail to a recovery shell after being left overnight.
There is a way to boot into an emergency shell when this happens.
Your attitude is part of why systemd is so reviled.
I could say the same about yours. I mean, the parsing of fstab by the local-fs.target is VERY well documented. And so are the early boot debugging features. Why would you upgrade a system before at least taking a cursory look at the documentation? I successfully migrated a moderately complex system dependent on an external ZFS disk array, several NFS expo
There is a way to boot into an emergency shell when this happens.
Yet you don't seem to be willing to share that information. That's probably the attitude he's talking about, if I had to guess. I remember a time when a member of the Linux community would have responded with something helpful along the lines of:
You can add break to your kernel line to get a shell on your initram, you can even decide to get it before or after mounting...
Possibly even elaborating on just how to go about doing that but, at the very least, pointing the user in the right direction.
There was a time when ignorance was met with information, rather than ridicule. If you want people to embrace your beloved systemd, perhap
Which is moderately annoying if you have access to the system console and you can guess that an unchanged/etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
As far as I know, this (correct according to documentation/intent) behaviour has been the same since any stable distribution shipped systemd as the default init.
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying.
And should teach you to always 'mount -a' when you have made a change to your/etc/fstab.
Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
In most of the cases I have seen this, it is when someone wrote a service unit file without even bothering to read systemd.service(5) and didn't put a Ty
Here we go again with all the insinuations and accusations. The/etc/fstab was correct with the old init. It was incorrect with systemd. Therefore no amount of mount -a would have helped.
"So, you were relying on bugs to boot your systems?"
Have you stopped beating your mother when she tells you to come out of your basement?
Well, I have never seen this myself, or seen valid bug report about. Yes, if your fstab entry was correct and that caused systemd to not boot, you should file a bug report.
However, I have also seen soooo many invalid complaints about systemd where the systemd beaviour was correct but other implementations were wrong (conflicted with the sgstem documentation).
systemd's approach is to boot correctly, or if a required resource is not available to not boot into a partial state.
Here's a few. It has no concept of imperative (Just do what I said), or best effort (everything must be perfect or it won't even try to continue). It hard codes things that should be configurable or external. For example, it has it's own idea of what makes a device ready for a filesystem to mount and it can't be told otherwise.
All of that is why soft RAID must be assembled in the initrd before systemd has a chance to screw it up. Otherwise, there is simply no way to tell systemd to complete the boot process
And once again a systemd opponent proves to be an idiot or a liar. Handling a degraded array and making it bootable has always been the job of the initramfs. See this Debian bug dealing with this issue [debian.org], for example, where the maintainer himself admits so.
Funny thing is, you were so desperate to deny the systemd bug that you pulled up the wrong issue entirely.
The initramfs HAS to handle the RAID for the root filesystem, naturally. Non-root RAID is supposed to be handled after transferring control to the actual init.
Same for non-root btrfs.
If there's an idiot or liar in this thread, it isn't me.
The initramfs has to handle all degraded arrays, otherwise they will be marked inactive, and not mounted. The right place to fix issues with degraded arrays being marked inactive (and thus umountable) is in the initramfs.
Which the Debian maintainer admitted; it was his change in the initramfs scripts that marked the arrays inactive and made them fail to mount.
Again, you are so bound up in your systemd hate that you fail to read.
I read just fine. The workaround is in initramfs, but that's just because systemd is incapable of handling it. Prior to that, the old sysV init handled it just fine.
Not that when I first tested systemd, it was on a working test dummy with a btrfs. It worked just fine before, including when I degraded btrfs. Then I 'upgraded' to systemd and it wouldn't boot. It wouldn't just fail to mount the btrfs (non-root), it just dropped to an emergency shell with no remote services running.
While I do have concerns about systemd, most dependency schemes have a way for a component to declare itself a prereq to an unwitting third party component. It's a valuable cabability in general when trying to enhance behaviors of existing systems without modifying components needlessly.
I'll grant the similarity, but at least the Debian scripts don't create hard dependencies. The boot won't stop as a result. That system might refuse to implement a new configuration if it detects that the advisory dependency cannot be met, but end of the day, the links in/etc/rcN.d will be control the boot and if one fails, it will move on.
The X- prefix provides some indication of knowledge that it's a dirty hack, but it is somewhat less problematic given the small number of init.d scripts all kept in one
There's many hours of reading the Debian CTTE and bug archives about the system init discussion if you have a bit of time and are that interested.
A short version, which is mostly still applicable and accurate for the large part from the past 2 years, is the Debian debate wiki pages with the arguments for and against various init systems to switch to. It's notable that *no-one* wanted to use sysvinit moving into Jessie, and the votes for upstart were heavily partisan being current and ex-canonical employee
Systemd has three fundamental issues: -It's not systemd versus sysv, it's systemd vs. sysv/syslog/cron/at/user session management. That's a whole lot of potential controversy to take on for a project that you either adopt as a distro or you don't, and giving the users choice in a matter like this is an impractical thing for most distributions. It also creates challenges for security, because something you do to provide user-level access to some capabilities becomes a potential path for a vulnerability (of
The simple fact of the matter is both *for* and *against* are necessarily going to be a matter of opinion. Poeple *like* or *don't like* certain things. There are sometimes objective pieces of data (time for computer to do X, amount of memory consumed to do y), but other than boot performance, there isn't an objective good or bad to argue here, it's a matter of consensus and pissing off the fewest people and accommodating the tastes of the most people possible. The logistics of managing processes and sta
But 'who to piss off least' is a factual assertion masquerading as an opinion. There is simply no proof that systemd pisses off more people than SysV. Given that we don't see a massive rise in BSD usage, that Red Hat senior officers say they see no impact on RHEL7 deployments and that Devuan is not advancing in any meaningful way, there is in fact a strong possibility that systemd pisses of a majority of loud whiners, but that is not the same.
One, it would be nice to have more than the opinion of officials who stand to look the worst if there were a problem. Even if there were a problem, people in that position stand to benefit by making that problem invisible.
Two, as time passes, it becomes increasingly difficult to justify staying with RHEL6 era software all *just* to avoid systemd. That doesn't mean customers *happily* go to systemd, but that they have to.
Three, even should systemd be a make or break vendors
It is really strange how for some reason disregarding well-founded statements and just saying that there is a hidden reason why they don't fit seem to be common among systemd opponents and crazy right-wingers.
Given the amount of invective coming out of the anti-systemd camp, complaining about mild epithets like 'whiners' also sounds a lot like the standard alt-right tactic "Yes, but you're the real racists|sexists|whatever".
In other words, snowflake, shut up and come back when you have actual hard facts to
Standard facilities to 'daemonize' software without the software having to do the right double fork and exit dance. It would have been one thing if libc had provided a function, but it hasn't so every daemon has had to do that weird dance itself, and many of them get it wrong, particularly home-grown software
Systemd has three fundamental issues: -Piss poor community engagement. Their reaction to any request or security report is to first say the requester or reporter is an idiot. For example: https://github.com/systemd/sys... [github.com] where he claims that it's perfectly valid for a confused systemd to just run user as root instead of error out.
If I read *just* that bug report, the part of the community engagement that is not working well is from the community of incensed (seemingly Debian) users who insult people in bug reports.
Pottering explained the general approach they took which was:
In systemd we generally follow the rule that when we encounter a unit setting that does not validate syntax-wise we'll log about it and ignore it, for compat reasons. We do the same for User= here as for all other options.
However, he was open to taking a different approach for most security-related settings, and as such the issue is fixed [github.com]
Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues
Many, many examples which are never described in detail, or when enough detail is given to reproduce them turn out to not exist or have already been fixed.
Working with a friend on something and we need decent professional confidentiality. He was using Win10 and with all the telemetry and "sharing" basically what we do is an open secret, so, I wanted him to migrate to Linux. He managed to install Mint and was reasonably happy (he is not a techie, sales), comes to me and says, computer is not booting anymore. System boot stops at "Welcome to emergency...." I asked what he did and he doesn' t know (normal, I may say) so, I try to find out why it stops the
What exactly am I supposed to understand from your story? That people sometimes have technical issues? Great, thanks for that revelation.
Oh, and you, parent poster, are so out of touch [...]
Lol, pretty sure I said as much in my post. I am out of touch. I am not involved in the Linux development process in any way. As I said in my post, it's just a tool.
That's like saying I'm out of touch because I use a Dewalt drill but wasn't involved with designing the motor that went inside it. Well no fucking shit. Meanwhile you're bitching that older Dewalt drills had be
It's always amusing reading comments like this. I remember hearing this kind of thing when it came to software distribution.
"Installing Microsoft Office is so easy. I install it all the time with no issues. People are just so whiny. Why don't they just grow up and get used to it?"
Now try installing it across a few thousand, or maybe 50,000, PCs on a staggered schedule across a business where the OS installation is supposedly standardized. There's a world out there that you don't understand, and it has issue
But the "REEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" has been deafening from sysadmins, because they're not used to doing things this way.
Maybe because it's a horrible way to do software management? Hint: software management should not be done by or be the choice of the end-user. It should happen without them needing to do a damned thing. If this is the case, then we're cool.
I've been using Debian since before Sarge was released in 2005... and tons of distros since -- latest being Ubuntu 17.10 (and a VM dev box for 18.04). I can honestly say as an end user using mostly desktop software, the switch to systemd has been uneventful. I haven't experience any issues -- even when running VMs or running Apache to serve pages from them.
But, I'm not a sysadmin. I've supported Windows, Linux, and IBM AS/400 equipment... including servers... and, I guess our configuration changes so li
People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change".
no, that's not it. people who have been using linux for a long time usually *know the corner-cases better*. in other words, they know *exactly* why it doesn't work and won't work, they know *exactly* the hell that it can and will create, under what circumstances, and they know *precisely* how they've been betrayed by the rail-roaded decisions made by distros without consulting them as to the complexities of the scenario to which they have been (successfully up until that point) deploying a GNU/Linux system.
also they've done the research - looked up systemd vs other init systems on the CVE mitre databases and gone "holy fuck".
also they've seen - perhaps even reported bugs themselves over the years - how well bugs are handled, and how reasonable and welcoming (or in some sad cases not, but generally it's ok) the developers are... then they've looked up the systemd bug database and how pottering abruptly CLOSES LEGITIMATE BUGREPORTS and they've gone "WHAT the fuck??"
also, they've been through the hell that was the "proprietary world", if they're REALLY old they've witnessed first-hand the "Unix Wars" and if they're not that old they experienced the domination of Windows through the 1990s. they know what a monoculture looks like and how dangerous that is for a computing eco-system.
in short, i have to apologise for pointing this out: they can read the danger signs far better than you can. sorry!:)
And, hey, systemd while implementing everything (according to critics) still has less bugs than sysvinit alone. systemd: 272 bugs; sysvinit: 383 bugs.
While poorly implementing things it has no business implementing, and while poettering closes completely valid bug reports as if they were nonsense which also has a chilling effect on people filing more bug reports, systemd still has more bugs than sysvinit? That's your argument in favor?
Except that the people who know the most are unarguably the distro maintainers
[citation needed]
We know they know more about rolling distributions than most of us do. That's all we can tell without further scrutiny. Since the Debian community's leaders were pretty well split on whether they should adopt systemd, your attempt to paint it as a simple decision is extremely disingenuous. That's always a sign of a weak argument.
and they've chosen to adopt and develop systemd.
Most haven't chosen, most are based on redhate or debian and had no choice at all. Isn't Linux about choice? It's been conclusively proven that it's possible to mak
Since the Debian community's leaders were pretty well split on whether they should adopt systemd,
Not really "pretty well split":
The Technical committee had 8 members.
Just taking the first preferences of the members four wanted systemd, two wanted upstart and two wanted further discussion.
Debian's voting system being somewhat more complicated than almost any other on earth it ended up as a tie between systemd and upstart (only one person didn't put sysvinit as the last or next to last choice). The chair of the committee cast his tie breaker for systemd.
The gory details are publicly available here: http [debian.org]
Every time SystemD is brought up we have these religious debates. I have yet to see anything with real substance on the merits of one Init system versus another. It always devolves into complaining about who the developer is, or how some change makes an admin feel about something. I run a box with systemD on it at work every day and haven't had any issues that weren't self inflicted. Of course, I do higher level development in Java/C/C++ and don't really need to tie into Init for any reason.
People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change".
no, that's not it. people who have been using linux for a long time usually *know the corner-cases better*...
Everyone* switched to systemd because everyone* was using something that was much, much worse. Traditional sysvinit is a joke for service startup, it can't even handle dependencies in a way that actually works reliably (sure, it works until a process fails to start or hangs, then all bets are off, and good luck keeping dependencies starting in the right order as the system changes). Upstart is a mess (with plenty of corner case bugs) and much harder to make sense of and use than systemd. I'm a much happier person writing systemd units than Upstart whatever-you-call-thems on the Ubuntu systems I have to maintain.
The problem with systemd is that although it does init systems *better* than everything else*, it's also trying to take over half a dozen more responsibilities that are none of its damn business. It's a monolithic repo, and it's trying as hard as it can to position itself as a hard dependency for every Linux system on the face of the planet. Distros needed* a new init system, and they got an attempt to take over the Linux ecosystem along with it.
* The exception is Gentoo, which for over 15 years has had an rc-script system (later rewritten as OpenRC) based on sysvinit as PID 1 but with real dependencies, easy to write initscripts, and all the features you might need in a server environment (works great for desktops too). It's the only distro that has had a truly server-worthy init system, with the right balance of features and understandability and ease of maintenance. Gentoo is the only major distro that hasn't switched to systemd, though it does offer systemd as an option for those who want it. OpenRC was proposed as a systemd alternative in the Debian talks, but Gentoo didn't advertise it, and nobody on the Debian side cared to give it a try. Interestingly Poettering seems to be *very* careful to *never, ever* mention OpenRC when he talks about how systemd is better than everything else. I wonder why. Gentoo developers have had to fork multiple things assimilated by systemd (like udev) in order to keep offering OpenRC as an option.
The problem with systemd is that although it does init systems *better* than everything else*, it's also trying to take over half a dozen more responsibilities that are none of its damn business.
The only thing it "takes over" that some people seem to take exception to is the system log, and it does it for its own purposes. Yes, it can be argued that it would have been better to work with the generic syslog interface, but that just wasn't going to work. They would have had to rewrite large portions of it anyway that would have broken backwards-compatibility, so they just went with their own logging daemon instead, and they did their best to maintain backwards-compatibility by forwarding the log mess
Kudos for getting Gentoo mentioned for good reasons. I used Gentoo on my old netbook and media server, both of which were 32bit and slow. Except Gentoo made them work great.
Today I simply continued to use Gentoo on my desktop, newish laptop and new media server, all 64bit and running great. Even the dreaded Gentoo Updates are no problem today. I use alternate boot environments to overcome the weird problems. (Orginially my ABEs used BTRFS snapshots, now I use the mu
Excuse me, but the "nobody on the Debian side cared to give it a try" is just plain wrong. First, I was the person that ported OpenRC to Debian, and made it work on kFreeBSD and Hurd. So I did spend a large amount of time on it. Then, the tech committee members, who made the actual decision of making systemd the default, did actually try. It's written in clear text, available for anyone, in the tech committee bug (do your research yourself if you want to check).
If systemd is so terrible, then why did a lot of the major distros switch over?
There's one use case that systemd is really good at, and that is making things easier for distro maintainers. The creators of systemd spent effort discussing it with distro maintainers, and figuring out what features they wanted. That is why they switched over.
Systemd isn't easier for any other demographic, though.
I was going to google and provide you with examples, but really all you need to do is look at the google results: https://www.google.com/search?... [google.com]
Just that "user starting with a digit" bug alone....
I had only really been using Linux for a few years before the onset of systemd, and honestly I think that's part of the problem. People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change".
This is a common misunderstanding. No one is saying "don't replace the init system" they're saying "replace it with one that doesn't try to do everything". There are lots of other good options, I'm particularly partial to runit [smarden.org]. The init system should be pluggable, I should get a choice of which init system I want to use, just like almost every piece of software on my system.
The road to ruin is always in good repair, and the travellers pay the
expense of it.
-- Josh Billings
I have no problem with systemd (Score:4, Interesting)
Yeah, yeah I know the history of its development and how log files are binary and the whole debug kernel flag fiasco. And I don't care. By the time I used systemd, that had already long passed.
I switched from Squeeze to Jessie a couple years ago, had some growing pains as I learned how to use systemd... but that was it. No stability issues, no bugs. Can't say whether things run better, but they definitely don't run worse.
I had only really been using Linux for a few years before the onset of systemd, and honestly I think that's part of the problem. People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change". Whether its nostalgia or sunk-cost fallacy, I can't say, but beyond that it seems much more like a philosophical difference than a practical one. It just reminds me of people's refusal to use the metric system, for no better reason than they are unfamiliar with it.
If systemd is so terrible, then why did a lot of the major distros switch over? If they didn't, it would just be a footnote in the history of open source: "Hey remember when they tried to replace sysV and init with that stupid thing with the binary log files? What was it called? SystemP?" The fact that Devaun has not overtaken Debian in any real way (at least from what I've seen, feel free to correct me if I'm wrong) indicates that my experience with systemd is the norm, not the exception. The market has spoken.
I read TFA, there is not one single specific bug or instability mentioned about systemd. What is the "tiny detail" that split the community? I have no idea, because TFA doesn't say what it is. I know that part of the philosophy behind Linux is "figuring it out yourself", but if you don't explain to me these low level kernel details (if that's even what they are; again, I have no idea), then don't expect people like me to be on your side. Linux is just a tool to me, I don't have any emotional attachment to it, so if things are working OK I am not going to start poking around under the hood just because someone posts an article claiming there are problems, but never specifying what those problems are and how they affect me as a user.
Honestly TFA reads like "We are having development problems, therefore systemd sucks." I get that when major changes to the platform happens there are going to be issues and annoyances, but that's the way software development has always been and will always be. Even if systemd was perfect there would still be all kinds of compatibility issues and new conventions that developers would have to adapt to. That's what I would expect to happen whenever any major change is made to a widely used and versatile platform like Linux.
Even Linus doesn't really care [zdnet.com]:
"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."
I'm not saying systemd is "better" or "the right answer". If you want to stick to distros that don't use it, that's up to you. But what I am saying is, get over it.
Re: (Score:2)
you do realize that they have to support it, right?
You realize that this is their business model, right?
if systemd caused an increase in support instances, they'd do something about it.
Yeah. They'd sure hate an increased demand in their product (support!) and do what they can to avoid that. /s
Re:I have no problem with systemd (Score:5, Insightful)
Perhaps you have had no problems with systemd because you aren't trying to use it to do much.
Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues. If someone asked me for examples, I'd have a hard time deciding where to start because so many things have been gratuitously changed. If you really think there aren't examples, just read this thread.
On the other hand, I have yet to see real technical discussion about problems that systemd apparently is fixing. I honestly and openmindedly am curious about what makes systemd good, so I've tried on several occasions to find these discussions where good technical reasoning is used to explain the motivations behind systemd. If they exist, I haven't found any yet. I'm hoping some will appear as a result of this thread.
But you bring up the idea that the "market has spoken"? You do realize that a majority of users use Windows, right? And people in the United States are constantly electing politicians who directly hurt the people who vote for them more than anyone else. It's called marketing. Just because something has effective marketing doesn't mean it doesn't suck.
Re: (Score:3)
Don't let the perfect be the enemy of the good. If you have so many examples that you "don't know where to start", then start anywhere. You don't have to come at me with the best, most perfect example. Any example will do! I'm actually very interested. And I have, out of curiosity, looked a bit. But like you looking for why systemd is better, I came across a similar problem.
Your reply just continues the cycle I spoke of, where people who potentially know better than me, like you, claim there are problems bu
Re:I have no problem with systemd (Score:5, Insightful)
systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying. Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
The problem is that one camp won't admit that old init is a pile of shit from the 80's whose only virtue is that the stench has faded over time, and the other camp won't admit that their new shiny toy needs to be understandable and debuggable.
A proper init system needs dependencies and service monitoring. init + monit does not cut it today. Systemd does that bit rather impressively well. It's just terrible at actually booting the system, all the early boot stuff that you could depend on old init to get right every time, or at least spit out aggressive messages about why it failed.
Re:I have no problem with systemd (Score:4, Interesting)
Meanwhile here I am, running Gentoo, with init scripts that have had real dependencies for over 15 years (as well as a bash-based but much nicer scaffolding to write them), with simple to use admin tools and fully based on text files, with cgroup-based process monitoring (these days), and I'm wondering why everyone else didn't get the memo and suddenly decided to switch to systemd instead and bring along all the other baggage it comes with. Debian and Ubuntu had garbage init systems, and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half. You can also use systemd with Gentoo if you want, because user choice is a good thing.
Re: (Score:2)
and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half.
Gentoo does everything right except exist. On alternate days you can follow the install instructions identically and get totally different results. Gentoo is its own worst enemy.
With that said, lots of people have screamed often and loudly in many locations that Gentoo proves that this stuff is possible without systemd, and that there are at least two init systems which were already in relatively common use when systemd was shat out which support parallel init. This has simply been resoundingly ignored by t
Re: (Score:2)
I ran Linux on the desktop (and LOTS of servers) for 19 years, but finally got Mac religion about 4 years ago. As I had used Gentoo for about 5 years over this time, I was wondering how they had handled this. Found this: https://wiki.gentoo.org/wiki/G... [gentoo.org]. Looks like it's just as straightforward as I would have hoped, and the documentation was just a clear as usual for the project. It actually makes me want to emerge a new desktop system, just for old time's sake.
Re: (Score:2)
Re: (Score:2)
I must admit that I did not know about Gentoos init system. It seems very sensible.
Re: (Score:2)
systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
It retries for a bit, but it DOES eventually fail and kick you out to a recovery shell. It just doesn't do it immediately because it assumes that the device may just need some time to come up.
Thanks to the binary log files you cannot even boot something random and read the logs,
What do you mean "boot something random"? I don't see why a generic recovery disk can't have journalctl installed. How about a Debian install disk?
but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
Not true at all. If you don't know how to use journalctl, that's on you.
Re: (Score:2)
It did not fail to a recovery shell after being left overnight.
And a generic recovery disk can obviously have journalctl installed. It just didn't. Which meant I had to mess with PXE and all that again.
Nothing pertinent to the error was logged. Feel free to not believe it.
Your attitude is part of why systemd is so reviled.
Re: (Score:2)
Nothing pertinent to the error was logged. Feel free to not believe it.
I don't believe it. Feel free to provide details on how you were looking through the logs.
It did not fail to a recovery shell after being left overnight.
There is a way to boot into an emergency shell when this happens.
Your attitude is part of why systemd is so reviled.
I could say the same about yours. I mean, the parsing of fstab by the local-fs.target is VERY well documented. And so are the early boot debugging features. Why would you upgrade a system before at least taking a cursory look at the documentation? I successfully migrated a moderately complex system dependent on an external ZFS disk array, several NFS expo
Re: (Score:3)
There is a way to boot into an emergency shell when this happens.
Yet you don't seem to be willing to share that information. That's probably the attitude he's talking about, if I had to guess. I remember a time when a member of the Linux community would have responded with something helpful along the lines of:
You can add break to your kernel line to get a shell on your initram, you can even decide to get it before or after mounting...
Possibly even elaborating on just how to go about doing that but, at the very least, pointing the user in the right direction.
There was a time when ignorance was met with information, rather than ridicule. If you want people to embrace your beloved systemd, perhap
Re: (Score:2)
systemd fails silently if something is wrong in /etc/fstab. It just doesn't finish booting.
So, it behaves correctly according to the fstab(5)man page from the release before they switched to systemd? [debian.org]
Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic
As far as I know, this (correct according to documentation/intent) behaviour has been the same since any stable distribution shipped systemd as the default init.
If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying.
And should teach you to always 'mount -a' when you have made a change to your /etc/fstab.
Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
In most of the cases I have seen this, it is when someone wrote a service unit file without even bothering to read systemd.service(5) and didn't put a Ty
Re: (Score:2)
Here we go again with all the insinuations and accusations. The /etc/fstab was correct with the old init. It was incorrect with systemd. Therefore no amount of mount -a would have helped.
"So, you were relying on bugs to boot your systems?"
Have you stopped beating your mother when she tells you to come out of your basement?
Re: I have no problem with systemd (Score:2)
Well, I have never seen this myself, or seen valid bug report about. Yes, if your fstab entry was correct and that caused systemd to not boot, you should file a bug report.
However, I have also seen soooo many invalid complaints about systemd where the systemd beaviour was correct but other implementations were wrong (conflicted with the sgstem documentation).
systemd's approach is to boot correctly, or if a required resource is not available to not boot into a partial state.
I have seen enough failure modes
Re: (Score:2)
If you think your feedback was constructive, I suggest you re-read it.
Re: (Score:2)
Did you upgrade Ubuntu and find out that /var/spool/mail is a symlink to /var/mail and you can't mount to a symlink in fstab?
Re: (Score:3)
Here's a few. It has no concept of imperative (Just do what I said), or best effort (everything must be perfect or it won't even try to continue). It hard codes things that should be configurable or external. For example, it has it's own idea of what makes a device ready for a filesystem to mount and it can't be told otherwise.
All of that is why soft RAID must be assembled in the initrd before systemd has a chance to screw it up. Otherwise, there is simply no way to tell systemd to complete the boot process
Re: (Score:2)
And once again a systemd opponent proves to be an idiot or a liar. Handling a degraded array and making it bootable has always been the job of the initramfs. See this Debian bug dealing with this issue [debian.org], for example, where the maintainer himself admits so.
Re: (Score:2)
Funny thing is, you were so desperate to deny the systemd bug that you pulled up the wrong issue entirely.
The initramfs HAS to handle the RAID for the root filesystem, naturally. Non-root RAID is supposed to be handled after transferring control to the actual init.
Same for non-root btrfs.
If there's an idiot or liar in this thread, it isn't me.
Re: (Score:2)
The initramfs has to handle all degraded arrays, otherwise they will be marked inactive, and not mounted. The right place to fix issues with degraded arrays being marked inactive (and thus umountable) is in the initramfs.
Which the Debian maintainer admitted; it was his change in the initramfs scripts that marked the arrays inactive and made them fail to mount.
Again, you are so bound up in your systemd hate that you fail to read.
Re: (Score:3)
I read just fine. The workaround is in initramfs, but that's just because systemd is incapable of handling it. Prior to that, the old sysV init handled it just fine.
Not that when I first tested systemd, it was on a working test dummy with a btrfs. It worked just fine before, including when I degraded btrfs. Then I 'upgraded' to systemd and it wouldn't boot. It wouldn't just fail to mount the btrfs (non-root), it just dropped to an emergency shell with no remote services running.
Note that at one time, system
Re: (Score:2)
While I do have concerns about systemd, most dependency schemes have a way for a component to declare itself a prereq to an unwitting third party component. It's a valuable cabability in general when trying to enhance behaviors of existing systems without modifying components needlessly.
Re: (Score:2)
I would be interested in knowing what one or more of those are.
Re: (Score:2)
For example, Debian's SysV init scripts:
https://wiki.debian.org/LSBIni... [debian.org]
X-Start-Before: boot_facility_1 [boot_facility_2...]
X-Stop-After: boot_facility_1 [boot_facility_2...]
provide reverse dependencies, that appear as if the listed facilities had should-start and should-stop on the package with these headers.
Re: (Score:2)
I'll grant the similarity, but at least the Debian scripts don't create hard dependencies. The boot won't stop as a result. That system might refuse to implement a new configuration if it detects that the advisory dependency cannot be met, but end of the day, the links in /etc/rcN.d will be control the boot and if one fails, it will move on.
The X- prefix provides some indication of knowledge that it's a dirty hack, but it is somewhat less problematic given the small number of init.d scripts all kept in one
Re: (Score:2)
There's many hours of reading the Debian CTTE and bug archives about the system init discussion if you have a bit of time and are that interested.
A short version, which is mostly still applicable and accurate for the large part from the past 2 years, is the Debian debate wiki pages with the arguments for and against various init systems to switch to. It's notable that *no-one* wanted to use sysvinit moving into Jessie, and the votes for upstart were heavily partisan being current and ex-canonical employee
Re: (Score:1)
In other words, just like all other anti-systemd idiots you have nothing concrete and you are just parotting your echo chamber.
Re: (Score:3)
Systemd has three fundamental issues:
-It's not systemd versus sysv, it's systemd vs. sysv/syslog/cron/at/user session management. That's a whole lot of potential controversy to take on for a project that you either adopt as a distro or you don't, and giving the users choice in a matter like this is an impractical thing for most distributions. It also creates challenges for security, because something you do to provide user-level access to some capabilities becomes a potential path for a vulnerability (of
Re: (Score:2)
The simple fact of the matter is both *for* and *against* are necessarily going to be a matter of opinion. Poeple *like* or *don't like* certain things. There are sometimes objective pieces of data (time for computer to do X, amount of memory consumed to do y), but other than boot performance, there isn't an objective good or bad to argue here, it's a matter of consensus and pissing off the fewest people and accommodating the tastes of the most people possible. The logistics of managing processes and sta
Re: (Score:2)
But 'who to piss off least' is a factual assertion masquerading as an opinion. There is simply no proof that systemd pisses off more people than SysV. Given that we don't see a massive rise in BSD usage, that Red Hat senior officers say they see no impact on RHEL7 deployments and that Devuan is not advancing in any meaningful way, there is in fact a strong possibility that systemd pisses of a majority of loud whiners, but that is not the same.
Re: (Score:2)
The goalpost keeps moving here...
One, it would be nice to have more than the opinion of officials who stand to look the worst if there were a problem. Even if there were a problem, people in that position stand to benefit by making that problem invisible.
Two, as time passes, it becomes increasingly difficult to justify staying with RHEL6 era software all *just* to avoid systemd. That doesn't mean customers *happily* go to systemd, but that they have to.
Three, even should systemd be a make or break vendors
Re: (Score:2)
It is really strange how for some reason disregarding well-founded statements and just saying that there is a hidden reason why they don't fit seem to be common among systemd opponents and crazy right-wingers.
Given the amount of invective coming out of the anti-systemd camp, complaining about mild epithets like 'whiners' also sounds a lot like the standard alt-right tactic "Yes, but you're the real racists|sexists|whatever".
In other words, snowflake, shut up and come back when you have actual hard facts to
Re: (Score:2)
Re: (Score:2)
Standard facilities to 'daemonize' software without the software having to do the right double fork and exit dance. It would have been one thing if libc had provided a function, but it hasn't so every daemon has had to do that weird dance itself, and many of them get it wrong, particularly home-grown software
This should have been added long ago.
Re: (Score:2)
Systemd has three fundamental issues:
-Piss poor community engagement. Their reaction to any request or security report is to first say the requester or reporter is an idiot. For example: https://github.com/systemd/sys... [github.com] where he claims that it's perfectly valid for a confused systemd to just run user as root instead of error out.
If I read *just* that bug report, the part of the community engagement that is not working well is from the community of incensed (seemingly Debian) users who insult people in bug reports.
Pottering explained the general approach they took which was:
In systemd we generally follow the rule that when we encounter a unit setting that does not validate syntax-wise we'll log about it and ignore it, for compat reasons. We do the same for User= here as for all other options.
However, he was open to taking a different approach for most security-related settings, and as such the issue is fixed [github.com]
Re: (Score:1)
Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues
Many, many examples which are never described in detail, or when enough detail is given to reproduce them turn out to not exist or have already been fixed.
Re: (Score:1)
Real story
Working with a friend on something and we need decent professional confidentiality. ...."
He was using Win10 and with all the telemetry and "sharing" basically what we do is an open secret, so, I wanted him to migrate to Linux.
He managed to install Mint and was reasonably happy (he is not a techie, sales), comes to me and says, computer is not booting anymore.
System boot stops at "Welcome to emergency
I asked what he did and he doesn' t know (normal, I may say) so, I try to find out why it stops the
Re: (Score:1)
What exactly am I supposed to understand from your story? That people sometimes have technical issues? Great, thanks for that revelation.
Oh, and you, parent poster, are so out of touch [...]
Lol, pretty sure I said as much in my post. I am out of touch. I am not involved in the Linux development process in any way. As I said in my post, it's just a tool.
That's like saying I'm out of touch because I use a Dewalt drill but wasn't involved with designing the motor that went inside it. Well no fucking shit. Meanwhile you're bitching that older Dewalt drills had be
Linux is is now "mature" (Score:3)
It's always amusing reading comments like this. I remember hearing this kind of thing when it came to software distribution.
"Installing Microsoft Office is so easy. I install it all the time with no issues. People are just so whiny. Why don't they just grow up and get used to it?"
Now try installing it across a few thousand, or maybe 50,000, PCs on a staggered schedule across a business where the OS installation is supposedly standardized. There's a world out there that you don't understand, and it has issue
Re: (Score:2)
But the "REEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE" has been deafening from sysadmins, because they're not used to doing things this way.
Maybe because it's a horrible way to do software management? Hint: software management should not be done by or be the choice of the end-user. It should happen without them needing to do a damned thing. If this is the case, then we're cool.
Re: (Score:2)
I've been using Debian since before Sarge was released in 2005... and tons of distros since -- latest being Ubuntu 17.10 (and a VM dev box for 18.04). I can honestly say as an end user using mostly desktop software, the switch to systemd has been uneventful. I haven't experience any issues -- even when running VMs or running Apache to serve pages from them.
But, I'm not a sysadmin. I've supported Windows, Linux, and IBM AS/400 equipment... including servers... and, I guess our configuration changes so li
Re:I have no problem with systemd (Score:5, Informative)
People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change".
no, that's not it. people who have been using linux for a long time usually *know the corner-cases better*. in other words, they know *exactly* why it doesn't work and won't work, they know *exactly* the hell that it can and will create, under what circumstances, and they know *precisely* how they've been betrayed by the rail-roaded decisions made by distros without consulting them as to the complexities of the scenario to which they have been (successfully up until that point) deploying a GNU/Linux system.
also they've done the research - looked up systemd vs other init systems on the CVE mitre databases and gone "holy fuck".
also they've seen - perhaps even reported bugs themselves over the years - how well bugs are handled, and how reasonable and welcoming (or in some sad cases not, but generally it's ok) the developers are... then they've looked up the systemd bug database and how pottering abruptly CLOSES LEGITIMATE BUGREPORTS and they've gone "WHAT the fuck??"
also, they've been through the hell that was the "proprietary world", if they're REALLY old they've witnessed first-hand the "Unix Wars" and if they're not that old they experienced the domination of Windows through the 1990s. they know what a monoculture looks like and how dangerous that is for a computing eco-system.
in short, i have to apologise for pointing this out: they can read the danger signs far better than you can. sorry! :)
Re: (Score:2)
And, hey, systemd while implementing everything (according to critics) still has less bugs than sysvinit alone. systemd: 272 bugs; sysvinit: 383 bugs.
While poorly implementing things it has no business implementing, and while poettering closes completely valid bug reports as if they were nonsense which also has a chilling effect on people filing more bug reports, systemd still has more bugs than sysvinit? That's your argument in favor?
Re: (Score:1)
systemd still has more bugs than sysvinit?
Uh, in my world 272 is a smaller number than 383. It isn't the same where you come from?
By the way, you may think Lennart Poettering is the Devil himself, but he isn't a Debian developer, so can't close bugs at bugs.debian.org.
Re: (Score:1)
An appeal to authority is only a logical fallacy if the authority is not really an authority.
Re: (Score:1)
*know the corner-cases better*. in other words, they know *exactly* why it doesn't work and won't work
Except that the people who know the most are unarguably the distro maintainers and they've chosen to adopt and develop systemd.
Re: (Score:2)
Except that the people who know the most are unarguably the distro maintainers
[citation needed]
We know they know more about rolling distributions than most of us do. That's all we can tell without further scrutiny. Since the Debian community's leaders were pretty well split on whether they should adopt systemd, your attempt to paint it as a simple decision is extremely disingenuous. That's always a sign of a weak argument.
and they've chosen to adopt and develop systemd.
Most haven't chosen, most are based on redhate or debian and had no choice at all. Isn't Linux about choice? It's been conclusively proven that it's possible to mak
Re: (Score:2)
Since the Debian community's leaders were pretty well split on whether they should adopt systemd,
Not really "pretty well split":
The Technical committee had 8 members.
Just taking the first preferences of the members four wanted systemd, two wanted upstart and two wanted further discussion.
Debian's voting system being somewhat more complicated than almost any other on earth it ended up as a tie between systemd and upstart (only one person didn't put sysvinit as the last or next to last choice). The chair of the committee cast his tie breaker for systemd.
The gory details are publicly available here: http [debian.org]
Re: (Score:2)
Every time SystemD is brought up we have these religious debates. I have yet to see anything with real substance on the merits of one Init system versus another. It always devolves into complaining about who the developer is, or how some change makes an admin feel about something. I run a box with systemD on it at work every day and haven't had any issues that weren't self inflicted. Of course, I do higher level development in Java/C/C++ and don't really need to tie into Init for any reason.
People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change".
no, that's not it. people who have been using linux for a long time usually *know the corner-cases better*...
One could also s
Re:I have no problem with systemd (Score:4, Informative)
Everyone* switched to systemd because everyone* was using something that was much, much worse. Traditional sysvinit is a joke for service startup, it can't even handle dependencies in a way that actually works reliably (sure, it works until a process fails to start or hangs, then all bets are off, and good luck keeping dependencies starting in the right order as the system changes). Upstart is a mess (with plenty of corner case bugs) and much harder to make sense of and use than systemd. I'm a much happier person writing systemd units than Upstart whatever-you-call-thems on the Ubuntu systems I have to maintain.
The problem with systemd is that although it does init systems *better* than everything else*, it's also trying to take over half a dozen more responsibilities that are none of its damn business. It's a monolithic repo, and it's trying as hard as it can to position itself as a hard dependency for every Linux system on the face of the planet. Distros needed* a new init system, and they got an attempt to take over the Linux ecosystem along with it.
* The exception is Gentoo, which for over 15 years has had an rc-script system (later rewritten as OpenRC) based on sysvinit as PID 1 but with real dependencies, easy to write initscripts, and all the features you might need in a server environment (works great for desktops too). It's the only distro that has had a truly server-worthy init system, with the right balance of features and understandability and ease of maintenance. Gentoo is the only major distro that hasn't switched to systemd, though it does offer systemd as an option for those who want it. OpenRC was proposed as a systemd alternative in the Debian talks, but Gentoo didn't advertise it, and nobody on the Debian side cared to give it a try. Interestingly Poettering seems to be *very* careful to *never, ever* mention OpenRC when he talks about how systemd is better than everything else. I wonder why. Gentoo developers have had to fork multiple things assimilated by systemd (like udev) in order to keep offering OpenRC as an option.
Re: (Score:3)
Thanks, interesting, and thanks for the Gentoo recommendation.
Re: (Score:2, Informative)
The problem with systemd is that although it does init systems *better* than everything else*, it's also trying to take over half a dozen more responsibilities that are none of its damn business.
The only thing it "takes over" that some people seem to take exception to is the system log, and it does it for its own purposes. Yes, it can be argued that it would have been better to work with the generic syslog interface, but that just wasn't going to work. They would have had to rewrite large portions of it anyway that would have broken backwards-compatibility, so they just went with their own logging daemon instead, and they did their best to maintain backwards-compatibility by forwarding the log mess
Re: (Score:1)
Kudos for getting Gentoo mentioned for good reasons. I used Gentoo on my old netbook and media server, both of which were 32bit and slow. Except Gentoo made them work great.
Today I simply continued to use Gentoo on my desktop, newish laptop and new media server, all 64bit and running great. Even the dreaded Gentoo Updates are no problem today. I use alternate boot environments to overcome the weird problems. (Orginially my ABEs used BTRFS snapshots, now I use the mu
Re: (Score:2)
The reason why OpenRC hasn't been chosen, is
Re:I have no problem with systemd (Score:4, Insightful)
If systemd is so terrible, then why did a lot of the major distros switch over?
There's one use case that systemd is really good at, and that is making things easier for distro maintainers. The creators of systemd spent effort discussing it with distro maintainers, and figuring out what features they wanted. That is why they switched over.
Systemd isn't easier for any other demographic, though.
Re: (Score:3)
I was going to google and provide you with examples, but really all you need to do is look at the google results: https://www.google.com/search?... [google.com]
Just that "user starting with a digit" bug alone....
Re: (Score:3)
Aka people with lots of experience. 24 years Linux experience here, for example.
Happy with change. Unhappy with systemd. It's a terrible idea and a badly run project as well.
Re: (Score:2)
I had only really been using Linux for a few years before the onset of systemd, and honestly I think that's part of the problem. People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change".
This is a common misunderstanding. No one is saying "don't replace the init system" they're saying "replace it with one that doesn't try to do everything". There are lots of other good options, I'm particularly partial to runit [smarden.org]. The init system should be pluggable, I should get a choice of which init system I want to use, just like almost every piece of software on my system.