Does Systemd Make Linux Complex, Error-Prone, and Unstable? (ungleich.ch) 751
"Systemd developers split the community over a tiny detail that decreases stability significantly and increases complexity for not much real value." So argues Nico Schottelius, talking about his experiences as the CEO of a Swiss company providing VM hosting, datacenters, and high-speed fiber internet. Long-time Slashdot reader walterbyrd quotes Nico's essay:
While I am writing here in flowery words, the reason to use Devuan is hard calculated costs. We are a small team at ungleich and we simply don't have the time to fix problems caused by systemd on a daily basis. This is even without calculating the security risks that come with systemd. Our objective is to create a great, easy-to-use platform for VM hosting, not to walk a tightrope...
[W]hat the Devuan developers are doing is creating stability. Think about it not in a few repeating systemd bugs or about the insecurity caused by a huge, monolithic piece of software running with root privileges. Why do people favor Linux on servers over Windows? It is very easy: people don't use Windows, because it is too complex, too error prone and not suitable as a stable basis. Read it again. This is exactly what systemd introduces into Linux: error prone complexity and instability. With systemd the main advantage to using Linux is obsolete.
The essay argues that while Devuan foisted another choice into the community, "it is not their fault. Creating Devuan is simply a counteraction to ensure Linux stays stable. which is of high importance for a lot of people."
[W]hat the Devuan developers are doing is creating stability. Think about it not in a few repeating systemd bugs or about the insecurity caused by a huge, monolithic piece of software running with root privileges. Why do people favor Linux on servers over Windows? It is very easy: people don't use Windows, because it is too complex, too error prone and not suitable as a stable basis. Read it again. This is exactly what systemd introduces into Linux: error prone complexity and instability. With systemd the main advantage to using Linux is obsolete.
The essay argues that while Devuan foisted another choice into the community, "it is not their fault. Creating Devuan is simply a counteraction to ensure Linux stays stable. which is of high importance for a lot of people."
INCOMMING! (Score:5, Funny)
Oh my! I'm going to hang back, make some popcorn, step into some Tyvek coveralls, grab a hard-hat and safety goggles and enjoy the show!
Re: INCOMMING! (Score:2, Funny)
Does systemd make writing headlines complex, error-prone, and unstable?
Does systemd make ... (Score:4, Funny)
This is Slashdot, any ill you can imagine can be traced back to systemd.
Re: (Score:2)
Re:Does systemd make ... (Score:5, Funny)
systemd turned me into a newt!
Re:Does systemd make ... (Score:5, Funny)
A newt that can type on a KEYBOARD??
"He got better! [youtube.com]
Re: Does systemd make ... (Score:5, Funny)
Systemd is nothing but a thinly-veiled plot by Vladimir Putin and Beyonce to import illegal German Nazi immigrants over the border from Mexico who will then corner the market in kimchi and implement Sharia law!!!
And as always, its supporters are so intelligent . (Score:5, Interesting)
... their only arguments are hyperbolic personal attacks. (Look, I can do that too!)
Hint: Your side is just as stupid as your opposing site. There is no sane or reasonable, let alone sensible side. Because that is how Americans are. At least it is beyond their *tiny* mental box.
Regarding systemd, I state *both* A and B:
A) Monolithic "frameworks" have always been a stupid idea. Because they disable you from plugging them into *your* system, and force you to plug into *theirs*. Because they want to dominate you! And they are mutually exclusive as a result of that.
B) Traditional init systems are very limited and badly limiting nowadays. Like still using DOS as the underpinnings of your actual system. A more generic event/trigger system is much more sensible.
THE PROBLEM IS: That systemd throws away what's good about traditional init systems (like "everything is a file"; modularity; being able to do things with a simple file manager, text editor and maybe a script.).
It could have done the event/trigger thing *without* sacrificing modularity (tools that do *one* thing, and do it right!).
It could have acted less like a dominatrix on a power trip, swallowing everything.
The base ideas were good. The personality of the way it was implemented, was that of a complete egocentric psychopathic asshole with a god complex.
Give me a sane eventd, and I will ditch the old init system before you can blink.
Re: (Score:3)
This is Slashdot, any ill you can imagine can be traced back to systemd.
This is simply not true!
A small percentage of troubles are related to the GRUB -> GRUB2 switch.
Re:INCOMMING! (Score:5, Funny)
Oh my! I'm going to hang back, make some popcorn, step into some Tyvek coveralls, grab a hard-hat and safety goggles and enjoy the show!
LOL, I was going to say almost the exact same thing. Save me a seat if you would, I'll be along in a minute with some extra beers and a splatter-shield.
Re:INCOMMING! (Score:4, Insightful)
Slackware or BSD. Everything else is not worth it.
Red Hat has managed to do what everybody compains about Windows. Embrace Extend & Extinguish. Open source means jack squat when 1 or 2 corporte entities control the whole infrastructure stack.
Re:INCOMMING! (Score:5, Informative)
Technology doesn't hold still.
Doesn't mean that just because a technology is new it's automatically a good idea, great-grandpa.
Love, a NetBSD-on-everything millenial who'd pick Slackware if forced to use Linux
Re:INCOMMING! (Score:4)
This is going to be epic....
Well you know lucky for you there is... (Score:5, Insightful)
Re:Well you know lucky for you there is... (Score:5, Informative)
moving to BSD is done like this:
Estimated total time 90 minutes (OpenBSD), unless you are still using a 32 bit machine on 811g*. Do not restore /etc and /var in place, but somewhere else (like /home/restore) and migrate the settings as you find you need them.
Once its working, delete the /home/restore subtree.
There should not be anything that is file system dependent anyway unless you are deeply into file system development.
+ Install from floppies is no longer recommended, and installing over the net will take a while if you have not done it before
* A 32 bit machine on 811g will probably still perform adequately for some purposes - such as a trial run to see if its as easy as I say.
Comment removed (Score:5, Insightful)
Re:Problems with Linux that should have been solve (Score:4, Interesting)
- Drop this selinux shit. It's too complicated and causes more problems than it solves. Vulnerabilities come from bad code, not a lack of complex call ACLs. Security is a process, not a feature.
If you want to disable SELinux then disable SELinux, but not writing "bad code" isn't an option when even OpenSSL get major holes.
As long as people want new features there will either be new security vulnerabilities or software you can't afford and never gets completed. If SELinux adds enough security to be worth your bother then go for it, if not then disable it.
Re: (Score:3)
Drop this selinux shit. It's too complicated and causes more problems than it solves.
I think the utility called audit2allow summarizes well the immense "value" of selinux.
generate SELinux policy allow/dontaudit rules from logs of denied operations
https://manpages.debian.org/un... [debian.org]
The first time I heard about it I thought it was a prank.
Re:Problems with Linux that should have been solve (Score:5, Insightful)
I disagree on SELinux, not because its interface is well-designed (it is not), but because it is needed for some things.
On the rest, I fully agree. And instead, systemd solves things that were already solved and does it badly. The amount of stupidity in that decision is staggering.
Re:Problems with Linux that should have been solve (Score:5, Informative)
I really struggle to reconcile the Slashdot view that systemd is total crap and the fact that every major Linux distro has switched to it.
The Linux ecosystem is not sane. Redhat wanted more control of Linux so they pushed systemd. GNOME developers are easily distracted by shiny things (as proof I submit GNOME 3) so they went ahead and made GNOME dependent on it. And then Debian (which most Linux distributions are based upon) adopted systemd because GNOME depended on it. There were some other excuses, but that's the biggest reason. You can blame Redhat and Debian for this clusterfuck, and really, only a small handful of people in the Debian community are actually responsible for Debian's involvement. Debian's leaders were split almost down the middle on whether they should go to systemd. This is why major changes should require a 2/3 vote (or more!)
Re: (Score:3)
Yes, when you focus on what you intend to happen, issues seem so clear, don't they? But all this lack of responsiveness to your demands arises from attempts to contain potential unintended consequences.
I have a pet peeve, which is people who rank "crash" or "hang" bugs at the apex of the failure scale, above data corruption and faulty outputs. Think of an automated trading system that enters an abnormal state and starts generating random buy and sell orders for example. Or a system which is supposed to aut
Re:Problems with Linux that should have been solve (Score:4, Funny)
code contribution: /code/systemd
rm -rf
Re: (Score:3, Funny)
I tried your patch and it's amazing. Please submit a pull request upstream as soon a possible.
Re:Problems with Linux that should have been solve (Score:5, Informative)
Can I ask, why don't you and other admins/devs like you start to contribute to systemd?
Lennart Poettering has specifically said that he will not accept many important kinds of patches, for example he refuses to merge any patch that improves cross-platform compatibility.
And what's the reason, because people on forums are complaining? Because binary log files break the UNIX philosophy?
Here is my analysis of systemd, spread across multiple posts (links towards the bottom) [slashdot.org]. It's poorly written software (the interfaces are bad, you can read through my links for more explanation), and that will only get worse over time if an effort isn't made to isolate it over time. This is basic system architecture.
Re: (Score:3)
In the UNIX server world, hardware usually doesn't change during runtime (init 3 or init 5). Thus a boot process that starts new processes in a pre-determined, finely tuned sequence until all services are running, makes sense. All dependencies are already solved before the system boots up (and if not, you change your boot sequence until they are). And in this case, shell scripts as glue between the processes make thoroughly sense, as they prov
Re:Problems with Linux that should have been solve (Score:5, Insightful)
>To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better
"Better" is a subjective term. Software (and any product really) does not have some absolute measurable utility. It's utility is specific to an audience. The fact that the major distros switch is probably strong evidence that systemd is "better" for distro developers. But the utility it brings them may not apply to all users, or even any particular user.
A big part of the reason people were upset was exactly that - the key reasons distros had for switching was benefits to people building distros which subsequent users would never experience. These should not have trumped the user experience.
All that would still have been fine - we could easily have ended up with a world that had systemd for those who wanted it, and didn't have it for those who didn't want it. Linux systems are supposed to be flexible enough that you can set them up to whatever purpose you desire.
So where the real anger came in was the systemd's obsessive feature-creep made it go into a lots and lots of areas that have nothing to do with it's supposed purpose (boot process management), in that area it's biggest advantages are only useful to people building distributions (who have to maintain thousands of packages and ensure they reliable handle their bootup requirements regardless of what combination of them is actually installed- systemd genuinely did make that easier on them - but no user or admin ever experiences that scenario). But that feature creep itself wasn't even the issue, the issue was that - as it entered into all these unrelated areas (login was the first of many) - it broke compatibility with the existing software to do those jobs. This meant that, if you built a system to support systemd, that same system could not use any alternatives. So now, you had to create hard dependencies on systemd to support it at all - for distros to gain those benefits, they had to remove the capacity for anybody to forgo them, or alternatively provide two versions of every package - even ones that never touch the boot process and get no benefit from systemd's changes there.
And the trouble is - in none of those other areas has it offered anything of significant value to anybody. Logind doesn't actually do anything that good old login didn't do anyway, but it's incompatible so a distro that compiles it's packages around logind can't work with anything else. Replacing the process handler... and not only did it not add any new functionality it broke some existing functionality (granted, in rarer edge cases -but there was no reason for any breakage at all because these were long-solved problems).
Many years ago, I worked as a unix admin for a company that developed for lots of different target unix systems. As such I had to maintain test environments running all the targets. I had several linux systems running about 5 different distros, I had solaris boxes with every version from 8 onwards (yep, actual Sparcs), I had IBM's running AIX, I even had two original (by then 30 year old) DEC Alphas running Tru64... and I had several HPUX boxes.
At the time, while adminning all these disparate unix environments on a day-to-day basis and learning all their various issues and problems - I came to announce routinely that Solaris pre-Version-10 had the worst init system in the word to admin, but the worst Unix in the world was definitely HPUX because HPUX was the only Unix where I could not, with absolute certainty, know that if I kill -9 a process - that process would definitely be gone. WIped out of memory and the process table with absolutely no regard for anything else - it's a nuclear option, and it's supposed to work that way - because sometimes that what you need to keep things running.
SystemD brought to Linux an init system that replicated everything I used to hate about the Solaris 8/9 init system - but what's worse than that, it brought the one breakage that got me to declare HPUX the absolute worst unix system
Re: Problems with Linux that should have been solv (Score:4, Insightful)
Tough question. Depends what that functionality is. Compatibility is valuable but sometimes it must be sacrificed to deal with technical debt or make genuine progress. Even Microsoft had a huge compatibility break with Vista which was needed at the time (even if Vista itself was atrocious). /etc is a major deal - it utterly breaks with a standard around which disk space allocation is done professionally. /use ought to not even need backups because everything there is supposed to be installed and never hand edited. It means modifying backup strategy which is a big, very risky, cange. Logs aren't where I expect them. Boot errors flash on screen and disappear before you can read them so you have to remember to go look in the binary log to figure out if it was something serious.
It would depend what those features were, what benefits it gave me. It would be a trade off and should be evaluated as such. A major sacrifice requires an even more major advantage to be worthwhile. I've yet to see any such advantage from anything systemd has added. I'm not saying advantages don't exist, I'm saying whatever they may be they do not benefit me, personally, in any measurable way. The disadvantages however do, and compatibility is the least of them.
Config outside
I was never a fan of system V. It was a complicated, slow, mess if code duplication. It needed a replacement. I was championing Richard Gooch's make-init circa 2001 (and his devfs, the forerunner to udev, was in my kernels - I built a powerful hardware autoconfig system on it in 2005 when I built the first installable live CD distribution, the way they all work now: I invented it [I later discovered that pclinuxos had invented the same thing independently at the same time but Ubuntu for example still came on two disks, a live CD and separate text based installation disk and more than once I had machines where the live cd ran great but the installed system broke due to disparate hardware setup systems]). Later I praised upstart - it was a fantastic unit system that solved the issues with system V, retained compatibility but was easy to admin, standards and philosophy compliant and fast. It was even parallel.
That is the system that should have won the unit wars. I'm not a huge fan of Ubuntu's eclectic side, unity has always been a fugly unusable mess of a desktop to me - but upstart was great, that and PPAs are Ubuntu two most amazing accomplishments. Sadly one got lost instead of being the world changing tech it deserved to be and it lost to a wholly inferior technology for no sane reason.
It's the Amiga of the Linux world.
Re: (Score:3)
To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better.
Raises the question, better for whom? Systemd seems to make some things easier for distro maintainers, at the cost of fucking shit up for users and admins.
That said, Debian's vote on the matter was essentially 50:50, and they're going to keep supporting SysV init. Most distros are descendants of Debian, so there's that. Redhat switched for obvious reasons (having the main systemd developer on their payroll and massively profiting from increased support demands).
With Debian and Redhat removed, what remain
Re: (Score:3)
There is a long history of Poettering and Sivers marking even clear security problems as "will not fix". Look for them yourself, they are not hard to find.
However your stance implies that you are just trying to sabotage the discussion. Your blue-eyed innocence is an obvious lie. Despicable.
Security services (Score:5, Interesting)
faster boot time as well (Score:5, Interesting)
it turns out that, on arm embedded systems at the very least, where context-switching is a little slower and booting off of microsd cards results in amplification of any performance-related issues associated with drive reads/writes when compared to an SSD or HDD, sysvinit easily outperforms systemd for boot times.
It violates fundamental Unix principles (Score:5, Insightful)
Do one thing, and do it well. Systemd has eaten init, udev, inetd, syslog and soon dhcpd. Yes, that is getting ridiculous.
Re:It violates fundamental Unix principles (Score:4, Funny)
The Emacs of the 2010s.
Re:It violates fundamental Unix principles (Score:5, Funny)
We are systemd. Lower your memory locks and surrender your processes. We will add your calls and code distinctiveness to our own. Your functions will adapt to service us. Resistance is futile.
Re:It violates fundamental Unix principles (Score:4, Insightful)
I think we sould call systemd the Master Control Program since it seems to like making oter programs functions its own.
Re: (Score:3)
Yeah, but Linux Is Not UniX, remember?
It's the implementation. (Score:5, Insightful)
I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example. I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).
In short, systemd has too many things stuffed into its kitchen sink -- if you want that, use Emacs :-)
[ Note, I'm a fan and long-time user of Emacs, so the joke's in good fun. ]
Re:It's the implementation. (Score:5, Interesting)
I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example.
the difference is that solaris is - was - written and maintained by a single vendor. they have - had - the resources to keep it running, and you "bought in" to the sun microsystems (now oracle) way, and that was that. problems? pay oracle some money, get support... fixed.
free software is not *just* about a single way of doing things... because the single way doesn't fit absolutely *all* cases. take angstrom linux for example: an embedded version of GNU/Linux that doesn't even *have* an init system! you're expected to write your own initialisation system with hard-coded entries in /dev. why? because on an embedded system with only 32mb of RAM there *wasn't room* to run an init service.
then also we have freebsd and netbsd to consider, where security is much tighter and the team is smaller. in short: in the free software world unlike solaris there *is* no "single way" and any "single way" is guaranteed to be a nightmare pain-in-the-ass for at least somebody, somewhere.
this is what the "majority voting" that primarily debian - other distros less so because to some extent they have a narrower focus than debian - completely failed to appreciate. the "majority rule" decision-making, for all that it is blindly accepted to be "How Democracy Works" basically pissed in the faces of every debian sysadmin who has a setup that the "one true systemd way" does not suit - for whatever reason, where that reason ultimately DOES NOT MATTER, betraying an IMPLICIT trust placed by those extremely experienced users in the debian developers that you DO NOT fuck about with the underlying infrastructure without making it entirely optional.
now, it has to be said that the loss of several key debian developers, despite the incredible reasonable-ness of the way that they went about making their decision, made it clear to the whole debian team quite how badly they misjudged things: joey hess leaving with the declaration that debian's charter is a "toxic document" for example, and on that basis they have actually tried very hard to undo some of that damage.
the problem is that their efforts simply don't go far enough. udisk2, policykit, and several absolutely CRITICAL programs without which it is near flat-out impossible to run a desktop system - all gone. the only way to get those back is to add http://angband.pl/debian/ [angband.pl] to /etc/apt/sources.list and use the (often out-of-date) nosystemd recompiled versions of packages that SHOULD BE A PERMANENT PART OF DEBIAN.
in essence: whilst debian developers are getting absolutely fed up of hearing about systemd, they need to accept that the voices that tell them that there is a problem - even though those voices cannot often actually quite say precisely what is wrong - are never, ever, going to stop, UNTIL the day that the role played by http://angband.pl/debian/ [angband.pl] is absorbed into the main debian packaging, providing "Replaces / Provides / Conflicts" alternatives of pulseaudio, libcups, bsdutils, udev, util-linux, uuid-runtime, xserver-xorg and many more - all with a -nosystemd extension on the package name.
ONLY WHEN it is possible for debian users to run a debian system COMPLETELY free of everything associated with systemd - including libsystemd - will the utterly relentless voices and complaints stop, because only then, FINALLY, will people feel safer about running a debian system where there is absolutely NO possibility of harm, cost or inconvenience caused by the poisonous and utterly irresponsible attitude shown by pottering, with his blatant disregard for security, good design practices, and complete lack of respect for other peoples' valuable input by abruptly and irra
If you put it that way... (Score:4, Insightful)
Betteridge's Law says no.
Don't go hating on systemd (Score:5, Funny)
it's a fine OS, the only thing it's missing is a really good init system.
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: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: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: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: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: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
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: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: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: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.
Good Lord, just run Slackware. (Score:4)
"but servers that don't boot, that don't reboot or systemd-resolved that constantly interferes with our core network configuration made it too expensive to run Debian or Ubuntu."
PRO TIP: Run Slackware. Slackware is cleaner and does everything Debian does and has never been tainted with systemd.
Re: (Score:3)
Slackware has several OFFICIAL package managers and about half-dozen 3rd party. Slackware's PMs are BETTER than Debian's or RH's..
Do the OFFICIAL PMs auto dependency resolve?
No. but- 1) The 3rd party PMs do. and 2) I've never had a Slackbox hosed-up by a package upgrade because the auto-dependancy upgraded something that didn't work with something else.
Do the Official Slackware PMs allow repositories?
Yes. (slackpkg+)
Do the Slackware PMs have a cool GUI that I can just click?
yes/no... The official PMs ha
The new print daemon (Score:3)
Linux (and before that: UNIX) has always had a "look how clever I am, writing all this obscure code" mentality. Since not too long after its inception, complexity - as a way of displaying the developers' prowess - has always been favoured over simplicity and elegance.
Whether you look at systemd, or the print subsystem or emacs or sendmail. They are all over-complex and if not intended to freeze-out users without the time, inclination or ability to grok them, then to achieve this through bad design which leads to complicated implementations.
Good design is difficult. Too hard for most coders. And it does seem that with kernel development and the systems that surround it, most of the design decisions are simply left up to the people writing the code to make, themselves. While this is standard procedure for a teenager sitting in a darkened bedroom, knocking out .... code, it is strictly amateur-hour stuff. You would have hoped that the linux community would have moved past that in these last 30 years.
Comment removed (Score:4, Insightful)
Betteridge's law of headlines meets... (Score:3)
Systemd moved Linux closer to Windows (Score:5, Interesting)
Windows is a very complex system. Not necessarily because it needs to be complex, but rather because of "wouldn't it be great if we could also..." thinking. Take the registry. Good idea in its core, a centralized repository for all configuration files. Great. But wouldn't it be nice if we could also store some states in there? And we could put the device database in there, too. And how about the security settings? And ...
And eventually you had the mess you have now, where we're again putting configuration files into the %appdata% directory. But when we have configuration in there already anyway, couldn't we... and we could sync this for roaming, ya know...
Which is the second MS disease. How many users actually need roaming? 2, maybe 3 out of 10? The rest is working on a stationary desktop, never moving, never roaming. But they have to have this feature, needed or not. And if you take a look through the services, you'll notice that a lot of services that you simply know you don't need MUST run because the OS needs them for some freakish reason. Because of "wouldn't it be great if this service did also...".
systemd now brought this to the Linux world. Yes, it can do a lot. But unfortunately it does so, whether you need it or not. And it requires you to take these "features" into account when configuring it, even if you have exactly zero use for them and wouldn't potentially not even know just wtf they're supposed to do.
systemd is as overengineered as many Windows components. And thus of course as error prone. And while it can make things more manageable for huge systems, everything becomes more convoluted and complicated for anyone that has no use for these "wouldn't it be great if it also..." features.
binary logging is just so awful because... (Score:4, Insightful)
if I have a problem with e.g. my dovecot instance on a server, with rsyslogd (as default installed on Debian) I get the fun of guessing which of mail.log, mail.info, or mail.err contains the messages I might like to see (with the mild suspicion that I ought to also glance at debug.log as well, just in case), then if I like to see things in chronological order I have the added amusment of running a command line like this:
zcat $(ls -tr /var/log/mail.log.*.gz) | cat /var/log/mail.log - | grep dovecot | grep $whatever_I_really_wanted_to_see
and I'll get most of what I'm looking for, along with anything else that contains the word dovecot.
[BTW hands up anyone that thinks a gzip file is a text file]
whereas with systemd it's just so bloody tedious:
journalctl -u dovecot | grep $whatever_I_really_wanted_to_see
Where's the fun in that?
Re: (Score:3)
This is one of those false arguments, though.
Nobody really cares about the logging, so long as there's an option to have "normal" logging if that's what you want.
But the logging has almost nothing to do with NOT NEEDING to use the logs. The problems mentioned with systemd are not "I couldn't find a line that dovecot was saying" but services literally not starting up, boots not completing, and even things like random variations on that (which is worse than not booting at all).
I've seen such things in the wi
Re: (Score:3)
If finding and reading the logs requires that a manual be read, then you've done something wrong.
That said...
One of the problems systemd faces is that it took thirty plus years of "how things are done" and tossed it in the trash -- without warning, and without a good sales pitch. We sysadmins woke up one day, and suddenly the next version of redhat changed everything out from under us. There was no transitional period, no slow migration a piece at a time. A dozen and a half things were suddenly completel
yeah, no. (Score:4, Informative)
Your example is off base.
1. I seldom search my gzipped backlogs, because if something went wrong, it was recent. That is why they are gzipped.
2. If I am searching for a specific error message, like "$whatever_I_really_wanted_to_see", then generally no other program will spew that and the extra "grep dovecot" is unnecessary.
Generally this is all you need:
grep $whatever_I_really_wanted_to_see mail*
Which is even simpler than the journalctl bullshit.
Second, the example that you give above is not that difficult for an admin because zcat, cat, grep ARE ALL STANDARD TOOLS that I use for the output of virtually every program and service that I use. I do not want to have to use a different command (journalctl) to look at the output of every different program (systemd) that I run.
Systemd is a bitch (Score:3)
I am an old fart. My first Unix machine was a VME 68xx running Unix Version 7 around 1986. I am mostly a developper, but I've been doing sysadmin work as an aside (unavoidable in small companies) more or less continuously for the last 30 years.
Recently, on upgrading my Debian home server (can't remember if it was Wheezy->Jessie or Jessie->Stretch), the server did not come back on the network after the upgrade. Go down to the garage where it lives: single user mode. No explanation nothing. After wasting 2 hours trying to guess what was happening, the explanation was that there was a stray entry in fstab. Nothing related to the real important stuff (/ or /usr), something like /proc/bus/usb or such. Systemd just decided that single user was the right thing to do. No ssh, no nothing. If the server had been remote, this would have been a major issue, instead of a couple of uncomfortable hours (restarting from backups would have been possible but would have changed a quasi-routine thing into one or more days of work).
I can't remember a machine being so nasty to me since the 90s (Unixware maybe :) )
Re: (Score:3)
I have to wonder what in my message made you think that I would have done the same thing if the machine had not been in my garage? Or are you just being hostile for the fun of it ?
Enterprise Headache (Score:4, Informative)
I'm curious if Redhat are regretting their decision on the early hard switch to systemd in RHEL7. I know for a fact their support system was flooded with issues from early adopters. I have friends in the industry still on RHEL6 as the upgrade to version 7 is a logistical nightmare and one who works at a reasonably large enterprise considering ditching Redhat entirely to go to a systemd-less alternative.
That faster boot time sure helps with servers that are only restarted once a year ...
Re:Enterprise Headache (Score:4, Informative)
Question is too large... (Score:3)
.
I am now actively looking for a distribution that does not use systemd.
Sometimes I have to wonder if the wrong feature goal (faster start-up times) was over-emphasized in the whiplash switch to systemd by the distributions. For me, the faster start up is just not that big of a deal anymore, now that I've moved to SSD.
Why no non-systemd competitor to Redhat? (Score:3)
I mean a sizeable company that has it's own Linux distro, and makes money supporting that distro.
Red Hat seems to be the enterprise Linux company.
I suppose IBM, and Oracle, somewhat support Linux. But for those companies, Linux is just a sideline.
I bet if there were a company like Red Hat, that had a non-systemd alternative, the Red Hat competitor would win.
Re: Ah yes the secret to simplicity (Score:5, Insightful)
A big ol ball? My init.d was about 13 scripts big which were readable and editable. Ever tried to edit systemd files? Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Systemd makes every system into a dependency mess.
Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.
Re: Ah yes the secret to simplicity (Score:5, Insightful)
So the short answer is: Yes, systemd makes things unnecessarily complex with little benefit.
That matches my experience - losing a lot of time trying to figure out why things don't work. The improved boot time is lost several times over.
Re: Ah yes the secret to simplicity (Score:5, Informative)
So the short answer is: Yes, systemd makes things unnecessarily complex with little benefit.
That matches my experience - losing a lot of time trying to figure out why things don't work. The improved boot time is lost several times over.
I completely agree. Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time. And getting anything of value out of the log is a pain in the ass.
Quite often I end up writing control shell scripts specifically to be called by systemd, because this junkware is too fragile and capricious to work with actual daemons. That says a lot about the overal usefulness of systemd.
Nothing has been gained with systemd, at least not on servers.
Re: Ah yes the secret to simplicity (Score:5, Informative)
Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
Not to mention that the damn logs are not plain text, which in itself complicates things before you even have the chance to start troubleshooting.
Re: Ah yes the secret to simplicity (Score:5, Insightful)
Granted, I have never needed any kind of tampering or corruption mitigation in my log files over the last 20 years of Linux administration. So the value for at least my usage of journalctl has been sum negative because I don't see the value in a command that by default truncates log output.
So the answer for systemd is to workaround it by using a "legacy" service to restore decades of functionality.
SMF was the death knell for Solaris (along with the Oracle purchase), and it feels like systemd is going to be the anchor which drags Linux into the abyss.
Re: (Score:3)
I'd say it is worse having to type something different for one log on the system, when the other 100+ are plain text and so accessible with the old tools we've all learned backwards. It means you don't have the necessary switches or key presses to hand because you don't do it often enough.
"journalctl" might be the best thing since sliced bread, but making it a hard requirement of systemd makes adoption of systemd that much harder. IMHO, systemd should "pick it's battles" and concentrate on managing system p
Re: (Score:3)
The point being that text format is more universally readable, and also should it get corrupted, it has a better shot of still being readable.
On the other hand, pure binary logging was not necessary to achieve what they wanted. In fact, strictly speaking a split format of fixed-size, well aligned binary metadata alongside a text record of the variable length data would have been even *better* performance and still be readable.
Re: Ah yes the secret to simplicity (Score:5, Insightful)
Using text processing skills to process a generic text file isn't any harder than using journalctl. The difference is that the former is generically applicable to just about any other software on the planet, and the latter is for journald. It's not that complex to confer the journalctl benefits without ditching *native* text log capability, but they refuse to do so.
Using ForwardToSyslog just means there's an unnecessary middle-man, meaning both services must be functional to complete logging. The problem is the time when you actually want logs is the time when there's something going wrong. A few weeks ago was trying to support someone who did something pretty catastrophic to his system. One of the side effects was that it broke the syslog forwarding (syslog would still work, but nothing from journald would get to it). The other thing that happened would be for the system to lock out all access. I thought 'ok, I'll reboot and use jornalctl', but wait, on CentOS 7, journald defaults to not persisting journald across boot, because you have syslog to do that.
Of course the other problem (not entirely systemd project fault) was the quest to 'simplify' console output so he just saw 'fail' instead of the much more useful error messages that would formerly spam the console on experiencing the sort of problem he hit (because it would be terrible to have an 'ugly' console...). This hints about another source of the systemd controversy, that it's also symbolic of a lot of other design choices that have come out of the distros.
Re: (Score:3)
I'm inclined to agree, BUT... I actually quite like system unit (files). It's a great way to daemonise a very simple program (perhaps one you got handed by your devs who know nothing about sysadmin, or perhaps some crap downloaded from the Internet because someone thought it would be useful). Getting simple stuff to work with systemd is actually super-easy. All those symlinks are really just enable/disable, although I'd love to see the actual files in some obvious directory - I'm not sure how much of that i
and AWS / other lack consald (Score:2)
and AWS / other lack 2 way console.
But., but... (Score:3)
Re: (Score:3)
In my experience managing systemd unit files is GREAT!
What are you using them for? Are you a sysadmin? A debian init script writer? An embedded systems builder?
I wish half the effort that went into b!tching and moaning would go into a decent alternative but compatible alternative/fork to systemd (ie. works with same unit files etc).
The reason there isn't a compatible alternative is because the code is too complex.
Re:Ah yes the secret to simplicity (Score:5, Informative)
1. You've moved having a basic understanding of the boot process, and the ability to fix things, from having a decent knowledge of bash to being a C wizard.
2. You've broken decades of understanding the boot process.
3. It breaks KISS, as it doesn't simply do startup. Hell, it does ntpd.
It breaks a lot of the *concept* of unix. Maybe to something preferred by a lot of people - but it also turns it into an alien mess to a lot of other people.
Re: Ah yes the secret to simplicity (Score:4, Insightful)
Re: (Score:3)
The problem is that systemd is full of bugs. When the boot process hangs, automounts fail, or shutdown gets stuck waiting on nfs (saying it will time out but the time out target keeps moving), troubleshooting requires knowing C. Those problems can't be fixed by config files and documentation. They are bugs in the C code which is far more complex than a boot system should be.
Exactly! This is the MASSIVE point that pro-systemd-ers completely fail to address.
If any portion of my sysvinit system fails to process... at the console I can ctrl-c, carry on, and figure the issue out normally.
Perfect example, case in point: I recently upgraded a box to Debian Jessie and forgot to remove systemd before rebooting. I lost remote access to the box because for whatever reason, systemd was waiting for dhcp on an interface that was supposed to be set up as static, and was frozen in the proce
Re: (Score:3)
It breaks a lot of the *concept* of unix.
And therein lies the problem. After all, Linux is based on Minix [wikipedia.org] and Minix is "a POSIX-compliant (since version 2.0), Unix-like computer operating system" [wikipedia.org].
POSIX [wikipedia.org], of course, is a standard derived from the various versions of Unix that existed when the standard was first thought of; and Unix systems are characterized by a modular design [wikipedia.org] that is sometimes called the "Unix philosophy" [wikipedia.org].
The original draft of the Unix philosophy stated:
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
It was later revised to:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
And, of course, systemd isn't compatible with eithe
Pottering's problem... (Score:3)
... is he's an arrogant fool with an overrated sense of his own abilities who will not listen to advice from people who know a lot more and have a lot more experience of using linux/unix in a critical enviroment than he does.
Why red hat and other distros are in thrall to his buffoon and his 2nd rate software is a mystery that I suspect even Mulder and Scully would find a challenge to solve.
Re: Ah yes the secret to simplicity (Score:5, Insightful)
Systemd creates a dependency mess which means it cannot be replaced by simpler things, which wasn't the case before systemd.
Re: Ah yes the secret to simplicity (Score:5, Interesting)
I started out using Slackware over twenty years ago. Biggest reason I left it was the libc5/glibc2 debacle. It became nonviable for me to remain on Slackware at that time. Bounced around through several package-managed distros and eventually ended up on Debian. I've now watched Debian become increasingly complex, sometimes needlessly, and sometimes because different major components have features that other major components lack. This means even if one is running something like xfce for the windowmanager one has to have a lot of Gnome or KDE stuff installed for basic stuff to work.
It's gotten worse since Systemd entered the picture. Honestly pulseaudio is still not mature, not sure how the person who didn't get that working right was entrusted to replace init.
Re: (Score:3)
Re: (Score:2, Insightful)
I'm still yet to have someone give me a legitimately non hysterical reason why "systemd bad" other than "its different"
This indicates a problem with understanding technology and technological explanations on your side, nothing else. "Safety in numbers" does not work for software.
Re: (Score:3)
>do not tinker under the hood, don't use Linux professionally, and don't run servers.
I do all of these things, I still don't whine hysterically about systemd.
Re:Ah yes the secret to simplicity (Score:5, Informative)
Journald makes logging simple and convenient, right?
journald has been known to run out of memory and stop responding.
Due to the design of "oh just connect stdout of the process to journald" if you restart journald it closes all of those file descriptors and you silently lose all further logging from already running processes.
Journald, by design, will only log so much per process, meaning that if it's logged too much since startup/an error you're interested in, you've now lost it.
Why 'they' had to go for demonstrably broken binary logging using a new interface I don't know. They could have just extended the syslog format to make it mandatory to pass along program name and process ID in the message. Then they could have made it "easier" to find the logs by having a per program/facility directory under /var/log and then stuck to simple, plain text logging that the existing *nix tools can search with ease. But, nope, they had to go with this shitfest instead.
And that's only one component of the whole systemd shitfest. On a very simple Debian install I've had it exhibit issues with shutdown, hanging on something that is simple or ignorable.
Sadly I had to abandon using Devuan after a while. The only really supported version is the jessie (Debian old-stable) version, and I'm not sure even that gets timely security updates. Their equivalent of Debian stable (Stretch) is 'ascii' and got next to no updates during the few months I used it. Boot up was both nice and fast (a major systemd selling point) and reliable (unlike systemd). I guess they just need more in the way of human resources so that they can nail down which Debian packages have problematic systemd tentacles involved, then they could pass through other Debian updates as soon as they're available.
Re: (Score:3)
Or in other words, a simple, reliable and clear solution was replaced with a gigantic KISS violation. No engineer worth the name will ever do that. And if it needs doing, any good engineer will make damned sure there is an easy and clean way back. The systemd people seem to be hell-bent on making it as hard as possible to not use their monster. That alone is a good reason to stay away from it.
Re: (Score:3)
Indeed. And on top of that they try to make it as hard as possible to do without systemd. This really seems to be a case of "if you cannot compete on merit, force users into it", which is completely unacceptable.
Re:What a load of twaddle.... (Score:5, Funny)
yet another rant with zero details.... "all the problems caused by systemd" and yet not a single one listed.
Use "journalctl" to see the details log.
Re: (Score:3)
apt purge systemd
add http://angband.pl/debian/ [angband.pl] to /etc/apt/sources.list before doing that and it will actually succeed. okok it's a bit more complex than that, but you can read the instructions online which are neeearly as simple :)
Re:Oh stop complaining FFS (Score:5, Interesting)