Slashdot Mirror
Does Systemd Make Linux Complex, Error-Prone, and Unstable? (ungleich.ch)
"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."
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!
If you want news from today, you have to come back tomorrow.
Of course it does!
Not! Not!
Ah yes, a big ol' ball of gaffer tape and bash scripts. The cure to complexity.
I'm still yet to have someone give me a legitimately non hysterical reason why "systemd bad" other than "its different"
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
The BSDâ(TM)s and Illumos. There is no reason to use the tire fire that is Linux. You have options!
Here's a list of actual problems that should have been solved instead of introducing the nightmare of systemd upon the Linux (Debian specifically) world:
- Forceful, unconditional kernel operations. When I say "unmount this filesystem," I'm not asking a question. When I say "terminate this process," I expect the process to be removed from memory and the runqueue, regardless of consequences.
- When I say "reboot" I mean "reboot." Hangs are not okay, ever.
- Actual, real soft NFS failures. Do not hang during boot for any reason unless that share is marked hard,nointr. Do not hang during shutdown/reboot, either.
- Enforce GPL-standard syntax on new incoming utilities. If you want into the package tree, use a GNU parsing library and use it correctly. Perhaps a standardized syntax wrapper available for package maintainers.
- Bolt simple parallelization, triggers and flow control onto init/rc.
- 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.
- Standardize and fix bluetooth support ffs.
My $0.02, as a 25-year Linux admin.
A government is a body of people notably ungoverned - AC
yet another rant with zero details.... "all the problems caused by systemd" and yet not a single one listed.
How are they going to get in and stay in if admins have real logs and can detect persistence?
Domestic spying is now "Benign Information Gathering"
and AWS / other lack 2 way console.
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.
Do one thing, and do it well. Systemd has eaten init, udev, inetd, syslog and soon dhcpd. Yes, that is getting ridiculous.
At least it's not as bad as selinux.
And nobody cares. Such things are unimportant when it comes to making this the year of the Linux desktop.
“Common sense is not so common.” — Voltaire
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. ]
It must have been something you assimilated. . . .
This is Slashdot, any ill you can imagine can be traced back to systemd.
“Common sense is not so common.” — Voltaire
SYSTEMD is WORST
Linux is that way to begin with.
Betteridge's Law says no.
- 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.
I stole this Sig
code contribution: /code/systemd
rm -rf
Yes this is a list of some of those niche edge cases that most Linux users just put up with but that turn off potential Linux users. Instead of bowing to NIH syndrome and coming up with yet another init system or gui or audio subsystem or window toolkit or graphical server these are the sort of problems that should be fixed. There are dozens of things like this that need fixing and the Linux community has become so enshrined in just working around these bugs that they never get addressed.
Now that you converted all your start scripts etc... to systemd, to you really want to go back to init?
Slashdot, fix the reply notifications... You won't get away with it...
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...
The first time I heard about it I thought it was a prank.
lucm, indeed.
I tried your patch and it's amazing. Please submit a pull request upstream as soon a possible.
it's a fine OS, the only thing it's missing is a really good init system.
Theres a consistent and simple way to lauch a daemon or script on noot witbout having a lot of redundent code in the init scripts.
Does matter if you love or hate systemd the systemd file is much simpler thanthe init files. One annoying thing i found with init files is they all had the same script and most targets didnt populate the standard arguments
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
And thats why I switched to Windows.
Oh right, crap code from the audiophile that couldn't code straight.
Never used any of his work. Linux has been seriously stable in my system ever since I started blocking that audio whatever it was called.
systemd is complex because non-server service management is complicated.
See the archlinux maintainer reasoning why they migrated here: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/
I think braeckmansj@outlook.com just asked our help to get subscriptions to penis enlargement mailing lists!
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.
It would be really nice to be able to run software without worrying about the amount of damage it could do. Android apps are fairly limited in what they can do, and in the absence of a root exploit, they can't go beyond their stated permissions, and can do nothing whatsoever after they've been uninstalled. I assume we're a long way off from having the right permission granularity and the good UIs for managing them, but this is a model we should at least explore further.
A cat can't teach a dog to bark.
SELinux wouldn't be needed if people knew how to write proper code instead of yanking library of the week down into their project.
I've been Unix admin in various environments for 20+ years. My first Linux install was in the early 90's with a pile of 3 1/2" floppy disks that I downloaded from Usenet. I think the first kernel I ever got compiled and working from scratch was 0.87. I've learned, and forgotten, more than I care to remember about Solaris, AIX, HPUX, IRUX & Linux.
I no longer care to admin anything but my own few systems as I've developed other interests and career paths.
I just got done, this very evening, installing Devuan on the laptop I'm using to make this post. The installation process was trivial. I've had Devuan running on other laptops and virtual machines for about a year now. I couldn't be happier, and I'll never go back to a systemd corrupted distro. I just want my stuff to work, and keep working, and not require hours to fix when something does go wrong.
systemd: may you rot in hell.
"Every time I see an adult on a bicycle, I no longer despair for the future of the human race." - H. G. Wells
Who pays the systemd developers? I'm not convinced that they are paying because they want Linux to be successful.
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:
"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.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
Stop using Nitwit File System. It was borken in the 90s, still borken now
Short answer: YES!
No further explanation needed.
The sooner the abomination called systemd is given a one-way ticket to /dev/null, the better. You know what? Even /dev/null deserves better than that.
And on the Eighth Day, Man created God.
- Fix the logging.
Seriously. It's nearly impossible to troubleshoot issues if messages are just swallowed and not either output to the screen (which systemd has broken completely) or to the journal.
hates it!
Yes, Yes, And Yes...
Rather than keep having holy wars over it, foster both systemd and non-systemd distros, and let time decide which is better.
Table-ized A.I.
"A stop job is running" Oh really? How does a stop job get started? Maybe you could use that instead of a stop job.
"A start job is running" Jesus fuck. If it hasn't started yet it's fucking STOPPED! Just say so and boot the goddamn machine already.
Fuckfuckfuck
As a longterm openSUSE user (since 1996) I very much appreciate the switch to systemd. TUMBLEWEED got really stable since then. Being no nerd but always trying to get a job done in a very short time with minimal effort I appreciate the clear cut interface and structure of systemd. It has some learning curve but in the end is much more efficient than tinkering with init scripts.
Thank you! Finally someone actually outlines specific issues instead of just complaining.
But I have to say, I'm using Jessie and I have not experienced any of the problems you have cited... When I kill a process, it gets killed. When I reboot or shutdown, it reboots or shuts down. When I mount/unmount something, it gets mounted/unmounted. The other stuff I can't speak to.
Just my $0.02 as well. Not a 25-year Linux admin, I've run my own server for ~5 years, so I didn't have that much experience before the changeover happened.
Can I ask, why don't you and other admins/devs like you start to contribute to systemd? Obviously there are huge philosophical differences between the systemd devs and parts of the Linux community, but if people like you never get involved in systemd development because of those issues, can you really expect them to change? It's like people who don't vote because they think their vote doesn't matter... it's a self fulfilling prophecy.
I mean, part of the process of development in general is that different people working on the project have different philosophies, but that tension between them (should) ultimately produce a better result than each individually would. It seems like, from my perspective as a semi-outside observer, that neither side is willing to compromise at all. That just drives the two even further apart as the dev teams become more monolithic in their philosophy... And I'm just left in the middle like, WTF?
I didn't even know systemd existed until I updated from Squeeze to Jessie and found that "service apache2 restart" didn't work. Once I got around the growing pains of learning a few new commands, that was it. It's not like I was like "ZOMG gotta get me some systemd!"
I'm not having any problems with systemd, so why would I switch to a smaller, less supported distro to avoid it? That just opens me up to a huge swath of potential issues that I don't even want to think about. And what's the reason, because people on forums are complaining? Because binary log files break the UNIX philosophy? I don't think you should be that surprised when I say that I really don't care.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
I’m surprise more people don’t use BSD. TrueOS is pretty decent as a desktop OS.
So much for Betteridge's law. Or is it?
All i see here is fud, not facts.
Yes.
Thank you! Finally someone actually outlines specific issues instead of just complaining.
Well most of the issues he complained about weren't actually related to Systemd.
But I have to say, I'm using Jessie and I have not experienced any of the problems you have cited... When I kill a process, it gets killed. When I reboot or shutdown, it reboots or shuts down. When I mount/unmount something, it gets mounted/unmounted. The other stuff I can't speak to.
Usually no, but it happens
Can I ask, why don't you and other admins/devs like you start to contribute to systemd? Obviously there are huge philosophical differences between the systemd devs and parts of the Linux community, but if people like you never get involved in systemd development because of those issues, can you really expect them to change?
For one thing contributing to a project like that is a massive commitment, but more to the point the poster is fundamentally opposed to the underlying philosophy of Systemd. They can get what they want by simply using init.
I didn't even know systemd existed until I updated from Squeeze to Jessie and found that "service apache2 restart" didn't work. Once I got around the growing pains of learning a few new commands, that was it. It's not like I was like "ZOMG gotta get me some systemd!"
I'm not having any problems with systemd, so why would I switch to a smaller, less supported distro to avoid it? That just opens me up to a huge swath of potential issues that I don't even want to think about. And what's the reason, because people on forums are complaining? Because binary log files break the UNIX philosophy? I don't think you should be that surprised when I say that I really don't care.
For the average user, or person running their own server, it doesn't really change anything. The people affected by Systemd are the hardcore sysadmins running huge networks or mission critical servers.
If you're to believe the people running the major distros the hardcore sysadmins love Systemd since it's given them a bunch of new capabilities and fixed a lot of issues. But there's a lot of people, at least on message boards, who are extremely skeptical of the change.
I stole this Sig
"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.
Your thin skin doesn't make me a troll
This is exactly what systemd introduces into Linux: error prone complexity and instability. With systemd the main advantage to using Linux is obsolete.
I keep saying it: Poettering is being paid by Microsoft. The best way to destroy an enemy is from within.
On the other hand I suspect it works the other way round for headlines where the author implies the opposite of the question.
I've never had to use sysrq+b this much since Ubuntu switched to systemd. Every other reboot systemd just hangs in a totally unexplainable way with no logs left behind (oh why thank you binary logs!). Nice to have an init system that can't shut down the system in what used to take about 1.5 second with sysvinit on SSD...
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
I have a PC with a Bios that tries to do everything, launching a bootloader that tries to do everything, to start a DesktopManager that treis to do everything, so I can run a browser that tries to do everything to see a website that tries to do everything.
And to think I started with Linux, because each thing had its own program and I could select what program did it.
Don't fight for your country, if your country does not fight for you.
For one thing contributing to a project like that is a massive commitment
Sure, that's totally understandable. But there are people who have enough time to fork entire distros, like Devaun... So while you could make that argument on an individual basis, you can't honestly say that "only the people who like systemd's philosophy have time to contribute to systemd".
but more to the point the poster is fundamentally opposed to the underlying philosophy of Systemd.
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to. As long as that's the position someone is going to take, they shouldn't really expect things to change. Again, self-fulfilling prophecy.
But there's a lot of people, at least on message boards, who are extremely skeptical of the change.
Great. But how is someone like me supposed to weigh these posts on message boards against the fact that the major distro I use switched? Skeptics demand to see the evidence. To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better. Is it definitive? Of course not, but when compared to "posts on message boards"... I mean, seriously? There are message boards where people think the world is flat, I'm not throwing out my globe any time soon.
I know it's "argument from authority", but I don't have anything else to work with except my own experience which supports the same conclusion.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
apt purge systemd
Slashdot, fix the reply notifications... You won't get away with it...
Which will never happen thus, those of us who live in the real world, need real solutions.
... assume we're a long way off from having the right permission granularity and the good UIs
The problem is much deeper than that, unfortunately. Android apps are nothing at all like whatever passes for 'apps' in the general world of Linux. Running apt-get can play total havok with your system, due to Linux's obsession with complex dependencies and shared libraries. Android apps, iOS app and Mac OSX apps dispense with this nonsense completely, and imagine apps instead as completely self-contained repositories of code. Apt-get can modify your system's startup process in a way that you can't just "undo". Android app installs cannot.
Betteridge's law of headlines meets slashdot's anti-systemd bias. Could be interesting
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 issues that you can't even comprehend. Their concerns are not your concerns.
If anything, it shows that the linux base is so big that major distros are now unable or unwilling to cater to the needs of professional system administrators.
Most consumers couldn't care less how stuff works under the hood. It's bizarre that that may be a reality in the Linux world, but here we are.
We can talk, discuss, compare notes, analyze and exchange war stories about the insanity that systemd has brought us, does Poettering even give a damn?
***HELL NO*** !!
The more we suffer, the more happy Poettering becomes as if it lives on our miseries
to place said configuration files in /usr/lib/systemd, rather than /etc where configuration files are supposed to belong, or at least in /var where every other dumb program chose to put configuration files that don't go in /etc.
Instead they chose to go with the method only used by scripting interpreters and usually only for files used statically as resources, not for configuration files that might need to be modified by the administrator.
I believe, Slackware has not jumped on the systemd wagon? Stable distro, too!
A fucking stupid German cunt who isnâ(TM)t anything designed it.
Itâ(TM)s a fuck off piece of shit for laptops.
My Fedora workstation is a fucking piece of shit. There is no /var/log/messages.
Why? Cos Lennart is a fucking piece of shit with no fucking idea.
The Dozens of CentOS 7 vm I run all seem fine with systemd.
Still, eat a dick you fucking faggot lennart.
???? Can you give specific example?
I've written daemons for linux before and it's had it's fair share of problems but logging was almost never one of those. Either your initialization script run by root created a place to write into /var/log// to log, or you configured your daemon to use the syslog mechanism which just pushes to journald (or /var/log/messages if you prefer that). I've not had an instance of a daemon loosing logs in journal that was due to a programming error, and that would've affected the older syslog mechanism as well.
Selinux sucks. It's either all in or turn it off... /etc/selinux/rules file, not some crappy command that adds them to a binary database...
A complex system will have some tools that are selinux ready and others that are not. How about having enforcing levels? Like this user is enforcing free and this one is not? In a simple
Turning off a bad program is not the solution in Linux has it often becomes so big that ppl will not develop alternatives.
If the kernel starts being buggy and crappy, is the alternative to uninstall it?
That stuff is all interface, not core to the execution of a Linux application. Dependencies aren't an issue because permissions are based on the process or user, not the file. (This is still an issue when a daemon is a dependency, or when a file has effective permissions of another user/group, but those are separate cases.) I don't have a complete solution, but modifying /etc (aside from /etc/$APP_NAME) could be considered a master-level permission, and the package manager would run with rights that don't allow that change unless the user approved the master-level permission for the application being installed. (Note that installation permissions wouldn't be the same as runtime permissions. Neither permission set should allow excessive read/write access.)
Compilers and interpreters aren't hard, either. They're just normal executables. If a rogue application launches "bash -c 'rm -rf /'", it should fail if the parent application doesn't have permission to touch files in /.
Do you have any other examples of why this isn't possible in principle?
A cat can't teach a dog to bark.
is all the complaints about how alsa doesn't work for multiple audio streams....
But that hasn't really been a problem with blocking in years, and generally when it *IS* a problem with blocking because something else has exclusive access to the audio device, then running pulseaudio atop it will cause cracking, popping, or just not work at all.
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Seriously, nobody's FORCING any of you to use SystemD - If you hate it so much, use something else!
There are LOADs of init systems out there!
I don't know why SystemD has become a thing - Pottering is just one guy; Why are you letting him have so much influence?
Because of you morons, things in userland are now depending on systemd because you are accepting it! But it does't have to be that way; Heck, in Gentoo there are people and teams patching systemd out of things like gnome3!
you're right, the systemd file is much simpler then a oldschool init script
on the other hand systemd makes pretty much everything else much much more complicated
that's not good a tradeof IME
In over 15 years of using Debian unstable I had only twice had problem, both of which where fixed in under an hour after checking the mailing list to see what was going on.
Then systemd came along and in 3 or so months my system broke 5 times, each time the brokenness turned out to be related to systemd components. Each time the brokenness had nothing to do with the init process itself but with the hooks systemd requires and introduced fucking everywhere. Each time the brokenness was something that should be completely unrelated to the init system.
SELinux doesn't give you any real extra security, that's the problem. Once people have the ability to run code on your OS, they can also find a privilege escalation exploit (this is true on all OSes, even OpenBSD).
In modern use cases, it's better and simpler to partition with containers instead of SELinux, but even then, once you give them the ability to run code, they can escape from the jail.
"First they came for the slanderers and i said nothing."
Actually, 100% of the issues he complained about weren't actually related to systemd. That's the point. There's a ton of issues that need fixed. systemd is more a solution looking for a problem. Having said that, the issue is then that most the issues he speaks of are of the sort that are very hard to debug. Which is another way of saying, what we really need is a much better debugging system for the kernel and really computers in general.
Having said that, I'm pretty sure 90% of the issues the OP was stating have more to do with Linux allowing D state processes and not dealing well with working dirs in to-be-unmounted dirs. Fixing those things really should be a high priority. Sort of funny, actually, that we're still not at the point where we can deal with these things. And by funny, I mean sad. Like OOM killer sad.
Now that runit is being actively maintained, I would definitely choose that.
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). 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.
"First they came for the slanderers and i said nothing."
For one thing contributing to a project like that is a massive commitment
Sure, that's totally understandable. But there are people who have enough time to fork entire distros, like Devaun... So while you could make that argument on an individual basis, you can't honestly say that "only the people who like systemd's philosophy have time to contribute to systemd".
Just because you can submit a patch to something doesn't mean it will be accepted. If it won't be accepted you're pretty much wasting your time making a patch. Yes, you can make a fork, but I'd argue that the very fact they chose to fork a entire distribution rather than systemd says a lot (systemd is tightly coupled by design for example; tight coupling in itself isn't bad as the Linux kernel does it, but the stuff systemd replaces never needed it). Like why would you fork something where you disagree with many of the design principles it's based on? It'd be far easier to just make your own from scratch at that point.
There is more complexity to Linux than that monolythic piece of software. Starting from the kernel itself.
SysV? Doesn't really do much, you need to implement your scripts well or else...
Can I ask, why don't you and other admins/devs like you start to contribute to systemd?
Adding more code to something already hugely overweight isn't going to make things better.
I can only think of one kind of contribution that'd be worthwhile: rip out a lot of code. I'm not convinced this sort of contribution would be accepted.
And generally I've much better plans to do with my time instead of joining a project I hate. For instance, my ceiling has this funny dot pattern and I still haven't gotten around to counting all the dots.
CLI paste? paste.pr0.tips!
>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
Unicode killed the ASCII-art *
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 remains on the list of major distros?
Yeah.. strong evidence...
CLI paste? paste.pr0.tips!
There is a reason we do not have have packaged it in #t2sde: https://t2sde.org/, our various init script and systems work since 1998 or so. No need to hijack the boot process with another emacs like complex operating system that is systemd. One days it replaces the whole Linux kernel ;-)
This overcomplicated hidden layer of bullshit is exactly what we did not want to maintain and analyse in Windows systems, and there is no good reason why one would such crap on Linux.
Using an unknown exploit is an economic risk for the attacker, unless your data is very valuable simply staying up to date with advisories will make containers relatively secure.
No it doesn't. As evidenced by the all distributions successfully using it and conspicuously not dropping like flies.
next
As someone who thinks Linux is pretty much void of the average air head PC user and resides mostly in the hands of people who should know what their doing. I am not sure that if systemd is a problem that it doesn’t involve people who simply don’t know what they are doing, and probably shouldn’t be attempting it.
As usual, any systemd-related thread brings out losers whose arguments are "but my pile of shell scripts is so much better because that's what I've been doing for 15 years!111!!!".
Let's deconstruct this article - it's ALL whining. There are no examples of actual bugs (sorry, "servers don't boot" is just BS). Other examples are equally pathetic: "systemd-resolved that constantly interferes with our core network" - I guess they stopped reading manual before getting to "systemctl disable" part?
After this article I'm pretty sure that this "CEO"'s company will fail pretty spectacularly.
not writing "bad code" isn't an option when even OpenSSL get major holes.
... and that's the reason why you shouldn't replace a bunch of editable and working scripts with some new, large and overly complex program written in C!
So some old people whine that things are changing with remarks that show that they are largely clueless. How is that newsworthy?
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 provide a deterministic, linear approach. For the few cases when hardware changes during runtime (USB drives etc.pp.), you have a wrapper that handles it, but it's not something init is concerned with.
But if you have a system where the hardware changes all the time during runtime, because mice get plugged in and graphic tablets removed, monitors are sometimes on, sometimes not, you have to support projectors for some time, you have to support several different "power down" states (S1, S2, S3...), computers get put into docking stations and removed etc.pp., init is just clumsy. There are so many drivers to be loaded and unloaded, services to be started, to be stopped, to be removed from memory, you have so many dependencies to be solved on the fly, that your shell scripts take ages to tune, and the boot sequence is depending on the hardware currently plugged in. You would need dozens of init states to make sense of it all, each one with the correct set of started and stopped services, and the changes between states happen often.
This is not the usual server environment (yet), but it is the daily life of Linux running on other devices.
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?
Debian: GNU/Linux done the Linux way
It's similar to UEFI. First the BIOS was that simple booting and basic service platform, now there is network stacks and graphical stuff. A lot of the traditional "user mode" stuff already runs as systemd related services. Soon systemd will include some graphical operating system or maybe a browser, just wait for it...
I didn't even know systemd existed until I updated from Squeeze to Jessie and found that "service apache2 restart" didn't work.
Huh? "service apache2 restart" works just fine with systemd. Hell, on Debian you can even do "invoke-rc.d apache2 restart" and it'll notice you're using systemd and do a "systemctl restart apache2" for you.
Watch this Heartland Institute video
I'm not having any problems with systemd, so why would I switch to a smaller, less supported distro to avoid it?
The whole joke about Devuan is that you don't have to switch to Devuan to get rid of systemd -- Debian, unlike Devuan, lets you choose the init system you want. Don't like systemd? Just apt-get install sysvinit.
Watch this Heartland Institute video
Just because you can submit a patch to something doesn't mean it will be accepted.
True.
What patches to systemd have been rejected? For what reasons?
Watch this Heartland Institute video
... 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.
Been using systemd with Lunar Linux for a very long time now and cannot say the box has been any less stable, or any of the other things you claim. Sure, early in its adoption systemd was a little hard to get a handle on but so is most things of that scale and over time those issues go away. I understand some objections to systemd by the unix purists, I get that and there is one thing I am not real pleased about with systemd. It seems like it wants to glob onto everything in a system including the kitchen sink. Aside from that I have found it to be no worse than init.d.
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.
It seems like Lennart is an asshole with no clue about security, but despite that it does seem to offer enough for people who sell Linux, people who offer commercial support for it, seem to think it's better.
Red Hat said it hadn't affected sales when they did an interview here.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
So would you be okay with it if it still broke compatibility but that was necessary to add some really important/useful features?
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
And while in Linux land we are discussing if systemd is bloated or not, in unix land they throw a fit over 'cat' getting to bloated.
http://harmful.cat-v.org/cat-v...
On a long enough timeline, the survival rate for everyone drops to zero.
That actually doesn't make sense. Most of the hotplugging support resides in a combination of udev rules and the kernel. Further, most the glue of supporting drivers comes in precisely those things. Where it doesn't come in play has to be supported by the X server or Wayland. Very little in the way of "services" are invoked or not based upon hotplugging. Even if they were, then that's a sign of better integrating service invocation and revoking under udev rules. If anything a move towards that would make init's job even easier as a lot more work, hypothetically, would be under udev and done automatically.
Having said all that, have you actually looked at systemd? In practical application, it has virtually nothing to do with hotplugging of hardware. It's still fundamentally tied to a system of dependencies which have to be heavily tuned to get decent functionality out of. All that and we still see horrible startup times for the desktop, in relative terms. Perhaps it's because the fundamental issue is how X server or Wayland interact with the kernel and have certain demands on the system? Or that programs on top of that have certain demands of the system? Simply put, most the system should be built upon a lot of dependencies that should be accepted asynchronously (ie the "hotplugging" that you speak of) without a minimal usage of timeouts or pre-allocation (we don't need 256 ttys by default). Systemd doesn't really fix any of that because it's trying to be a compatible init replacement.
Come back to me when you've radically improved the design of the Linux system and bootcharts aren't a joke.
...Do people have a problem with systemd or something?
[ducks]
Strat
Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
... 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.
PROTIP: Stating others misinform and lie, while using zero arguments to back that up, only makes you look like somebody who misinforms and lies (or is a religious fanatic), and therefore assumes, others do too.
Ah yes, a big ol' ball of gaffer tape and bash scripts. The cure to complexity.
I'm still yet to have someone give me a legitimately non hysterical reason why "systemd bad" other than "its different"
That has to be the most asinine pro-systemd strawman I've ever seen posted.
First, if the "big ol' ball of gaffer tape and bash scripts" of Sys V-style init is too hard for you to comprehend, you probably should stay far away from the inner workings of any computer. By your own admission, it's above your capability to understand.
Second, if you think running easily-understood scripts in a well-defined, obvious order that is "a big ol' ball of gaffer tape and bash scripts", why the hell do you think a mass of unreadable binaries that does things in no easily-determined order is better? Sys V init does have its shortcomings, but damn you're denser than a neutron star if you think it's complex and hard to understand.
Finally, if a system that does nothing more than run those easily understood scripts in a well-defined order is "a big ol' ball of gaffer tape and bash scripts", what the hell do you call rolling extraneous crap such as NTP and kernel modules into that?
Because if Sys V init is "a big ol' ball of gaffer tape and bash scripts", systemd is a tire fire of impenetrable dependencies covered with an entire elephant herd of shit's worth of extraneous bloat.
NTP?!?!?! In the init system? Seriously?
systemd is probably the best example of the law of the hammer I have ever seen. All Poettering knows how to do is write code - so every damn problem he imagines has to be solved with shitload of his own "brilliant" code - and forget design. It just grows of its own accord, and you can see that in systemd's development - "Hey, we seem to have a problem! Let's add 10,000 lines of code and a kernel module or two to systemd to solve that!!!"
What a dumbass.
He's too wrapped up in himself to realize that truly brilliant code is simple and generates "Damn, why didn't I think of that!" as a response. Spewing code in search of problems out of both ends like some fat, drunk frat boy with food poisoning who just lost it after downing two pizzas and six vodka-laced beer bongs isn't brilliant - it is systemd, though.
YES!
Yes it does!
Chas - The one, the only.
THANK GOD!!!
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 :) )
> So while you could make that argument on an individual basis, you can't honestly say that "only the people who like systemd's philosophy have time to contribute to systemd".
That just doesn't make sense, why would someone who thinks the whole design of systemd is a complete idiocy contribute to it? It doesn't even matter if they have time or not.
If someone decided to build a house out of cardboard, you wouldn't tell someone who says that it's not usable as a proper house to invest time into designing a better cardboard house! Because no matter what amount of time they invest, it will never become something useful to them (except by e.g. building it out of brick, but if you want a brick house, why would you contribute to the cardboard house project?!? And why would anyone expect you to?! And why would you expect the cardboard house project to even want you to?).
And sorry for anyone insulted by the analogy, but I think it is a quite suitable one in many aspects (but not meant to represent the truth of course). As simply for many people against it the concept of systemd itself makes as much sense as building a house from cardboard. And why "then help fix it" just isn't considered viable. If you consider systemd a sensible approach, you will have a quite hard time understanding these people.
Most of these I agree with, but I fail to see why you'd want to fix this, but not fix sysvinit, which has always been a horrible kludge and has been "obsolete" (unable to deal with a world where networking, hot pluggable hardware, CPUs requiring complex thermal management, etc, are ubiquitous.)
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap would be in the kernel itself.
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
The worst I can say about systemd is that it's the best init replacement ever created. That's not a complement, it's just a very low bar. The lack of recognition that it's a low bar is why we have these stupid "systemd is why we have Trump" discussions here.
You are not alone. This is not normal. None of this is normal.
Just move to FreeBSD, or any other BSD.
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 ...
I had not had a SystemD for an Year now. Not a single one.
I wonder if there's something to do about not using nothing with it since in the last 12 months?
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
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.
Unicode killed the ASCII-art *
I should not comment from my phone. Man autocorrect rapes my text...
Unicode killed the ASCII-art *
That is not true, unfortunately. In some environments you need two effective lines of defense and sometimes SELinux is the only thing that can provide the second one.
Also, any proper engineer knows that mistakes do happen and that the proper way to deal with that is redundancy, in software usually called "dense in depth".
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
And then you could look at why people use Linux and not Windows. And you would not be surprised at the masses willing to run trash and the smaller group that finds it unacceptable.
Seriously, have you thought even one minute about what you just posted?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
That does work. For now. And it comes with some problems, but nothing large at this time. The problem is that this is not fully supported anymore, otherwise I would not care about systemd at all and simply ignore it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You answer a question I didn't ask. Who is trying to sabotage what discussion?
Twat.
Watch this Heartland Institute video
"This XAML and WPF bollocks is unnecessarily complex" says last remaining WinForm dev.
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!)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
Huh? The big win of systemd over sysvinit is that it returns to "everything is a file". systemd units are simple declarative configuration files, not programs written in a turing-equivalent language.
I mean, Jesus Christ, what the fuck, introducing the halting problem into the configuration files you use to start your system, How the hell could anyone think that was a good idea.
Watch this Heartland Institute video
Its not the Slashdot point of view, its a vocal minority. Personally I trust the developers at Red Hat more than random posters.
Yes, yes and yes.
SELinux doesn't give you any real extra security, that's the problem. Once people have the ability to run code on your OS, they can also find a privilege escalation exploit (this is true on all OSes, even OpenBSD).
Wait, what? The specific thing that capabilities-based security does for you is mitigate privilege escalation exploits! If you use capabilities correctly, then even if someone can execute code, that code can't do bad things because it doesn't have the rights to do so.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap would be in the kernel itself.
That is not the argument, and if that's all you've taken away from it, then you are a disingenuous douchebag who refuses to listen to other people's arguments at best. The argument is that it's a large collection of tools which are designed to replace existing tools without actually being compatible with them, and built in such a way that you have to take many of them on. Its modularity is mythical at best.
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
That is a lie, and you are a liar. sysvinit still works fine, and there were several drop-in replacements which retained sysvinit compatibility while adding things that people claim you need systemd for, like parallel init.
The worst I can say about systemd is that it's the best init replacement ever created.
It's a security nightmare, it's very low-quality code put in a position of managing the entire system, and it was rammed up our asses without any notion of the existence of politics. Lots of other init systems don't have those problems.
That's not a complement, it's just a very low bar.
It is a "complement". It's a side of shit tacked on to a main course of shit. The init system is meant to be simple and reliable, two things which do not describe systemd. It should never have even been considered for inclusion in anything on that basis.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I'm one of systemd's early adopters, both on PC and on mobiles (had it on my phone in 2008 already). I'm still using it. I was completely on board with idea and even liked the implementation at the beginning.
The truth is, though, that it really got overly complex. It works great when it works, is somewhat manageable when you want to configure it, but when something unexpectedly breaks, it's really hard to debug. A few years ago I would use my last sentence only in regards to Microsoft Windows, but sadly, now it related to systemd as well.
Um, you know, this sounds an awful lot like OpenBSD...
Coming from someone who uses several flavors of Linux, OpenBSD, and FreeBSD on a regular basis.
Both of the original authors of SystemD are German, Germany is pushing for a law to backdoor all internet enabled hardware. Coincidence?
- Forceful, unconditional kernel operations. When I say "unmount this filesystem," I'm not asking a question. When I say "terminate this process," I expect the process to be removed from memory and the runqueue, regardless of consequences.
- When I say "reboot" I mean "reboot." Hangs are not okay, ever.
What about the Magic SysRq key?
- Actual, real soft NFS failures. Do not hang during boot for any reason unless that share is marked hard,nointr. Do not hang during shutdown/reboot, either.
Yep, that's annoying, but I don't know enough to say more.
- Enforce GPL-standard syntax on new incoming utilities. If you want into the package tree, use a GNU parsing library and use it correctly.
Perhaps a standardized syntax wrapper available for package maintainers.
That's a downside of decentralized development. The issue here is that different platforms have different standards, and a lot of linux tools are multiplatform. So you have the choice of making the syntax different for each platform or being consistent between platforms. Furthermore, for licensing reasons, using a GNU parsing library may not be an option. Keep in mind that developers may not want to go out of their ways just to be included in the package tree of a certain distro.
- Bolt simple parallelization, triggers and flow control onto init/rc.
You mean, without breaking anyone's workflow? Impossible. After many unsatisfactory attempts and discussions, it turned out that that systemd was deemed the least unsatisfactory.
- 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.
Feel free not to use it, we don't. Yes, it is compllcated, but when you want NSA-level security (at the time it was a thing), you can't rely on every developer and every administrator to be flawless. It's called defense in depth. Yes security is a process, and SELinux is one way of enforcing processes. And BTW, vulnerabilities tend to come from users (including admins) more than bad code.
- Standardize and fix bluetooth support ffs.
Not a linux-specific issue but please, yes. To be fair, Bluetooth is an extremely complex spec and it is at least partly justified. The issue is that no one seem to implement it correctly.
no, not "everything is a file" but systemd considers everything to be "configured in a file", the thing that does stuff is still systemd and you can't plug in a binary or a network stream or something and have it work. That's the big difference here.
So you're saying Windows 8 (and Windows 10) are better than Windows 7? The distribution didn't fail so it must be better, right?
The problem is people have a tremendous investment in these operating systems and it's extremely difficult to migrate, so they just suck it up and deal with systemd.
"We tried to build Data Center Light on Debian and Ubuntu, 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."
The author states that this is a Linux problem, but only reports using systemd on Debian and Ubuntu, and complains about optional features that are not enabled on "Enterprise" or stable distros.
I have used systemd on a number of distros on a variety of hardware (production bare-metal servers, production VMs, desktops, laptops) and have never experienced the problems the Debian and Ubuntu users complain about here.
All of the "examples" I have seen were obviously due to the user having spent mote time trying to manufacture a bug than reading the very good documentation.
.
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.
Plug a network stream into init(1)? What?
Watch this Heartland Institute video
people who offer commercial support for it, seem to think it's better.
There's your reason.
"Freedom in the USA is not the ability to do what you want. It is the ability to stop others from doing what THEY want"
Second, if you think running easily-understood scripts in a well-defined, obvious order
Bwhahahahahaha!
There are 9492 lines of scripts in /etc/init.d on one very simple system I sysadmin. Those scripts source an extra 920 lines of library scripts. The "obvious order" comes from the LSB headers at the top of the scripts (Hey, boogie on like it's 2005, fixed order boot is so dead).
Even that is ignoring the fact that the scripts are full of calls to such clear and simple things as "start-stop-daemon".
Watch this Heartland Institute video
for example he refuses to merge any patch that improves cross-platform compatibility.
As a BSD user, I'm incredibly happy about this decision.
CLI paste? paste.pr0.tips!
Config outside /etc is a major deal
It's also a major misunderstanding of systemd.
systemd has no site dependent configuration outside of /etc.
The files installed in /usr/lib/systemd by packages are not supposed to be modified by the sysadmin -- that's what /etc/systemd is for, putting things that override the distro defaults.
Watch this Heartland Institute video
I've had numerous instance of "service xyz restart" not restarting the service yet not producing an error message AND giving exit code 0. It might be due to debian's unit files being a mess, but that doesn't really change anything.
Disclaimer before someone calls me out on the BSD message above: I have to fiddle with Linux at work.
CLI paste? paste.pr0.tips!
If someone decided to build a house out of cardboard
...
https://www.sciencealert.com/t...
Watch this Heartland Institute video
Debian isn't at the mercy of systemd.
systemd is at the mercy of Devuan.
Know that Devuan has no mercy for terrible code like systemd.
LOL, extremely difficult to migrate. If that's your big concern then don't migrate. Stay put. Use RHEL 6 or whatnot and stay there for as long as you like. And if you do migrate then tweaking a script to be launched by systemd instead of upstart or sysvinit is most likely the least of your concerns. In the real world, it is far more likely you're worried about preserving your database, your users, your network mount points and so on.
Right... /etc/default is good enough for every other package but not for systemd.
And
You know, if you don't follow the standards and "misconceptions" arise - it's the fault of bad development.
Unicode killed the ASCII-art *
"A complex system"
Here is your problem, if you want a system to be secure then keep it simple...
And as for the kernel being big and buggy, the vast majority of kernel features are optional - you can compile a minimal kernel to suit your needs and get a more stable, more secure and better performing system.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Keep it simple: compile a custom kernel!
If "service xyzzy restart" doesn't work then "systemctl restart xyzzy" wouldn't work either -- they're literally the same thing.
(/usr/sbin/service is, on Debian, a big shell script that ends up calling systemctl if pid 1 is systemd).
Watch this Heartland Institute video
I'd move there if I could get my preferred desktop.
Great groaning sound as the goalposts are shifted.
You're changing "Config outside /etc is a major deal" to "Config outside /etc/default is a major deal" now?
Are you unable to admit that one of your complaints about systemd, which you described as "a major deal" was simply wrong?
Watch this Heartland Institute video
Clearly you have spent time thinking about systemd, and so some questions:
1) Any chance systemd will improve? I think about how gnome3 seems to be slowly gaining more acceptance, perhaps this will be similar?
2) One of the challenges, even for a general-purpose computer distro, is to run on a wide variety of hardware with different needs. Example: Portable computer needs to be able to sleep, use graphics switching (start quicker??) while on a server these might be less important. It seems that systemd is screwing up more on the server side, which is a bit surprising. Any ideas on why? Theoretically these systems would be admined by more seasoned humans, but they seem to be having the biggest issues.
Anyway, just some thoughts. In my personal experience running a single server running Debian Jesse all seems OK with systemd, but I am not doing anything too fancy there. I also run mint on some desktop systems, and systemd seems OK there too..
No. I didn't change anything. No configs, editable or otherwise, should exist outside /etc. Configs installed by packages which should be overridden rather than edited (what you described the ones under /usr as being) belong under /etc/default. They no more belong under /usr than the similar files installed by a thousand other packages do.
Unicode killed the ASCII-art *
I'm happily running rsyslog on my systemd-containing distribution.
For debugging, though, the journal actually contains far more verbose logging than syslog ever did. And redirecting both standard error and standard out is a good thing, as before systemd a messages that you talk about being swallowed just scrolled off the console, eventually to disappear forever if you didn't happen to catch them at the time.
I'm amused that people would actually prefer the thousands and thousands of lines of buggy bash script code of the init system, where many init scripts were ad-hoc, duplicated functionality (often poorly) of tracking instances, recording PIDs, etc. To say nothing of buggy daemonizing code in the deaemons themselves. Systemd is very modular, and auditable. If you can make the systemd daemonizing code correct, and fix bugs there, you've now fixed bugs for all daemons.
There are occasional bugs that crop up that get people worked up (and justifiably so perhaps). But "daily problems," as some suggest, with systemd doesn't seem to be true. In fact, systemd seems to be working rather well for a major commercial distribution like RHEL 7. I've run systemd on my desktop distribution for quite a few years now and I have had no problems and don't even know it's there, except that when I need to make a custom daemon, it's a heck of lot easier to make a short ini file than it ever was using init scripts, or even the XML-based services I used on OS X or Solaris.
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
That is a lie, and you are a liar. sysvinit still works fine,
What is a lie? That RedHat and Ubuntu had already moved away from sysvinit? That Arch Linux moved to systemd in 2012? That Debian was weighing up the possible alternatives with their usual glacial pace?
As for "sysvinit still works fine" -- sysvinit has been a piece of shit since the first time I saw it, back in 1990.
Watch this Heartland Institute video
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.
No. I didn't change anything.
Oh yes you did. You said:
/use ought to not even need backups because everything there is supposed to be installed and never hand edited
I pointed out that that was exactly the case with systemd and now you've changed the claim to:
No configs, editable or otherwise, should exist outside /etc.
with exactly zero justification.
Watch this Heartland Institute video
As for "sysvinit still works fine" -- sysvinit has been a piece of shit since the first time I saw it, back in 1990.
How many times have you actually had a problem due to sysvinit itself failing?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I'm sorry but you don't understand what went wrong in OpenSSL. OpenSSL just makes the parent poster's point. HeartBleed was due to OpenSSL trying to reinvent memory management because some OS's could not be trusted to do so efficiently. This was bad code and is in retrospect obviously bad code that is a perfect example of added complexity implemented as a workaround for the poor performance of a platform due to its overly complex implementation that broke security for everyone. LibreSSL http://www.libressl.org/ essentially removed the complexity and workaround from OpenSSL to improve security.
Two things can be equally true. Systemd rocks and sucks major balls at the same time. Systemd is a great init system when it comes to laptops and desktops that need to dynamically change based upon external events. Like closing the the lid on a laptop or plugging a device into a USB port. In that regards, it's a lot like launchd on a MacOS. Where systemd sucks is in server applications where you want simplified, stable, secure, maintainable specialized use systems that should change and reboot infrequently. It is for this reason, I have stayed with older Linux Distros and returned to *BSD for many of my server installations. All the while, I hope the distros learn the philosophy of UNIX and come to their senses.
Agreed on all except, I'll take another's comment on seLinux as something to consider. It may have it's uses.
:-)
Additionally, I'd add this;
- Reduce the number of security holes, bugs, quirks and whatnot, (but not at loss of reliability), over new features.
We don't need stinking new features! (I am looking squarely at you, Gnome 3! It should have been Gnome-NG, or something else, not 3.x.)
Everytime a new feature is added, it's possible that it added new security holes, bugs, quirks and reduced reliability. Let's end the madness
and decline new features until the software is secure, stable and suitable for it's intended task. (Copyright pending for SSS=Secure, Stable
and Suitable
Lady Galadriel
The real problem is the combination of both hotplug hardware and dynamic responses. For example, when I plug in a USB network or sound interface, I probably want to configure it once and have the same event trigger the same action every time. In contrast, when I plug in a USB mass storage device or insert a DVD into an optical device then the action that I want to run depends on the user that's logged in and the software that's currently running. FreeBSD's devd is not a great fit for that, because it doesn't provide a convenient mechanism for registering events dynamically. Well, it kind-of does: it forwards all of the events to a socket so that another process can add the missing functionality, and this is typically something that then forwards the events to DBUS and let's the running DE handle them. That's generally a better solution, because the events with statically configured actions tend to be ones that want to run with high privilege and the rest do not, so it's fine to have something as untrustworthy as DBUS[1] in the path for delivery (though it would be nice for devd to have some integrated support for adding and removing events beyond adding a file in devd.d and sending SIGHUP to the process).
[1] DBUS uses XML and so inherits vulnerabilities from expat (the XML library that they use) as well as providing its own in addition.
I am TheRaven on Soylent News
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.
Anecdote, not data. I'm a relative Linux noob, been using since 2011 etc just to get stuff done, nothing fancy. On Ubuntu Trusty based distro, that thing is rock solid, in short the damn thing just works for years with no major probs.
Installed the latest LTS with sysD. Something (not saying necessarily SysD... Likely pulse audio and network manager etc) fails almost as often as win 95 bluescreened. It will fail to have audio on boot, requiring a power off and boot. It will drop a WiFi connection after +-half an hour (religiously). Linux has gone from being far more Trusty then windows, to far less from a reliability perspective (based on very limited noob perspective)
So your solution is that rather than using libraries in a project, that each project should rewrite support for that feature from scratch? And you think this is going to increase security? Dozens of implementations of feature X that are only tested as much as the single project that uses that code. Reimplementation after reimplementation, no one in one project looking at the code in a different project because they don't share any - it's all uniquely written.
Great idea. Dist that out now!
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap would be in the kernel itself.
That is not the argument, and if that's all you've taken away from it, then you are a disingenuous douchebag who refuses to listen to other people's arguments at best. The argument is that it's a large collection of tools which are designed to replace existing tools without actually being compatible with them, and built in such a way that you have to take many of them on. Its modularity is mythical at best.
It's also worth noting that a large collection of integrated tools is totally unlike UNIX. The UNIX philosophy is about providing a large set of loosely-coupled tools. The UNIX tools are not designed to be tightly coupled (which shows at times, for example try doing ls -h and then use other tools to sort the result by size), they are designed to be composeable in ways that the authors didn't anticipate and to be replaceable by others. This is very different from systemd, which has a bunch of tightly coupled components that happen to be in different processes. This may be good for fault isolation (though most of them run as root, and I don't know to the degree that they each gracefully handle failure of the others), but it's not great software engineering.
Note: I have some issues with this aspect of the UNIX philosophy, which is largely a work around for the fact that UNIX didn't support dynamic shared libraries and so the only options for code reuse were statically linking all of the useful things (infeasible for space reasons) or have a bunch of utilities that you chained together. Lisp machines and the Alto running Smalltalk had much more elegant ways of composing useful bits of functionality.
I am TheRaven on Soylent News
I'm charmed to read such vitriol against systemd. I thought people were losing it. My pet hates in Linux atm are: Systemd; Grub2; PulseAudio; RHEL NetworkManager (More properly named GuessworkManager); Bloatware Window Managers KDE & Gnome.
Yeah, Sysvinit is slow, Yeah, Systemd is a POS. Init has stood the test of time, is no slower than windows, and surely can be paralleled more than it is. Systemd has FAILED the test of time. Slackware also offers init and systemd - you don't need Devuan. I have yet to be convinced Devuan is not going to go the way of so many other forks for lack of developers.
I parsed what he said, possibly incorrectly, as the stuff in /usr after installation should never need to be backed-up because it shouldn't change from the installation defaults. But everything I think can be discounted since I've been a Gentoo "Ricer" since '04. Though, how many others can truthfully state that they are still using the original base installation on what is effectively a completely different computer (Only thing original is the case and the hard-drive, the rest has been upgraded piece-meal) almost 14 years later.
How many times have you actually had a problem due to sysvinit itself failing?
What do you mean by "sysvinit itself"? If you mean init(1) and the core scripts (/etc/rc1 and so on), never. init scripts from packages, quite a few times, sometimes leading to unbootable systems, sometimes to booted but useless systems (no network, missing services).
The most recent sysvinit problem was poor dependency handling, leading to failure to mount NFS volumes on boot. That was a pain to fix.
Watch this Heartland Institute video
This!
+5 insightful
The real question is this: Does systemd make fitting the tool to the purpose at hand imposing, error-prone, frustrating, and counterproductive?
I've always regarded systemd "making Linux complex, error-prone, and unstable" as a short-term complaint, which was mainly advanced to argue that systemd's misguided mission was fueled by arrogant, deaf, sociopathic egocentrism.
Of course, those ad hominem characteristics are not a fatal flaw. For OpenBSD, that personality cluster is a match made in heaven.
Do biker bars hire bouncers on charisma and charm?
On the other hand, this is perhaps not the ideal personality cluster to introduce (almost by fiat) a highly integrated, monolithic subsystem that helps the user erect and automate their custom xmas light display.
Let's not become distracted by the reality that even a design turd, sufficiently polished, eventually achieves design maturity.
does systemd make...
or systemd makes.
not does systemd makes.
headline talks about errors, makes one itself.
Second, if you think running easily-understood scripts in a well-defined, obvious order
Bwhahahahahaha!
There are 9492 lines of scripts in /etc/init.d on one very simple system I sysadmin. Those scripts source an extra 920 lines of library scripts. The "obvious order" comes from the LSB headers at the top of the scripts (Hey, boogie on like it's 2005, fixed order boot is so dead).
Even that is ignoring the fact that the scripts are full of calls to such clear and simple things as "start-stop-daemon".
Hint: look in all the "/etc/rc?.d/" directories, and not in "/etc/init.d".
Why don't you just demonstrate your misunderstanding of how init works?
Oh, wait. You just did.
Sure, just like the tiny group of Slackware users who always argued that it was better because of its "more pure UNIX approach", talking about how package managers are essentially garbage (Slackware's package manager essentially unpacks a tarball and says good luck; removal wasn't a feature last time I saw this argument surface).
Support my political activism on Patreon.
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 authorize access sensitive data. This is why operating systems are designed to crash when unexpected states are encountered. It's also why they're designed to restrict or alter powerful operations like unmounting a drive.
Now I'm with you -- a system should be responsive to what the operator demands, even if it is a potentially bad idea. I think computers (smartphones especially) should have genuine power buttons that cut off the power supply from the system. But just because getting the computer to do what I *intend* is simpler doesn't mean that the operation itself is simple; the operator has to be prepared for the complex consequences of his action.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
There are good options, even within debian based distros.
The dynamic duo of MX linux and antix are both systemd free.
https://antixlinux.com/blog/
https://mxlinux.org/mx-17-release-candidate-1-now-available
The load systemd to get some dependencies met, but it uses svinit.
A nice fast distro based on debian stable, with lots of polish and a great helpful user community.
They both have a test repo with the latest packages, and a team that will generally package up programs you want if available.
https://forum.mxlinux.org/search.php?search_id=active_topics
Apple gave launchd to the world as Open Source, and has been using it in macOS pretty much flawlessly since OS X 10.4 (Tiger) (and more recently, probably iOS, WatchOS and TVOS, too).
If that STUPID FUCK, Pottering, and his ilk had simply taken the ALREADY-DEVELOPED-AND-TESTED GIFT that was offered by Apple, instead of going "Apple is teh Evilz!"; we'll show THEM we don't need no Steenking gift Daemons!" Most of this hand-wringing could have been avoided.
I have several machines which run Ubuntu 14.04LTS. They work 100% perfectly under Ubuntu 14.04LTS, and shuts down IMMEDIATELY when I tell it to. Since I'm curious and have time on my hands, being retired and all, I decided I'd give a try to Ubuntu 16.04LTS. I slapped a fresh drive into my laptop and proceeded to install 16.04.. The install went fine, as Ubuntu installs always have for me since I started using it, around 8.04LTS. After the install completed, the reboot after removal of the USB install media took forever. My use of the system with 16.04LTS for nearly a week showed me that EVERY time I told the system to SHUTDOWN, it took minutes to do so, and pressing ESC to watch the system shutting down showed me a bunch of VERY suspicious systemd-related items that were NOT shutting down in a timely manner. After a week of use of this, I removed the 16.04LTS drive and replaced it with the original 14.04 drive and magically, I was back to shutting down IMMEDIATELY when I told the system to... My only conclusion is this is caused by systemd, so I'm planning on staying with 14.04 till near its EOL, and then evaluating other distros that have NOT drank the "systemd-koolaide", such as Slackware/Devuan... FUCK SYSTEMD
THANK YOU, Edward Snowden!! Americans owe you a debt of gratitude (whether they know it or not..)
Technical answer: Yes, systemd adds more complexity mainly because it tries to do too many things, it's base code is very big making code revision and quality assurance really challenging.
Systemd is a RedHat project designed to solve their very own specific requirements, is not really meant to be used outside of RedHat, the other distributions have been forced to use it because it took over other basic shared projects like udev.
In the years that systemd have been developed I have read several problems from kernel hanging to arbitrary code execution and 90% of those problems were because bad design or poor judgement and 10% because it was bad implemented; Sometimes I wonder if systemd is designed on the go (and making a block diagram with names on it is not a project design).
Also Systemd's manager is a well known character that seems to lack the leadership and insights required to deal with complex projects (some people thinks he's the worst stereotype kind of bad hipster and most of his own comments do not help him at all).
And let's not forget that M$ bought 20% of RedHat about the time that Putteringaround was implementing systemd.
Why hide the configuration files for services? Why nest them?
And who *cares* about how fast it boots, if you're not running a laptop, or a ton of VMs? I have servers that take *minutes* before they finish posting. Hell, I've got an older HP DL580 G5 that takes seventy seconds before it even lights the screen and shows a logo, to let you know it' started posting.
And it's linux. Most folks just leave them running... so, again, who cares how fast? And, with the emphasis on parallel booting, when there's a problem, it's just made debugging that a *lot* harder. And come *on*, give me one justification for a binary journal file. And that's not even that great, given that not long ago, I was unable to boot a system, except to an older kernel, until I found, by chance, an error in /etc/fstab. For all the attempted boots, there was NOTHING in journald.
I do not see benefits.
List of problems I have personally encountered with systemd.
Upgrade never completing due to infinite loop bugs in systemd log maintenance.
Inability to read out log files without using slow as shit systemd commands.
Every time I run top there is ALWAYS systemd shit at the top of the list doing god knows what consuming resources for god knows why. The logging overhead of background noise from Internet SSH probes uses more CPU time than any other process in the entire system. It's almost as if systemd was designed to be a DOS attack helper service.
Kernel message ring buffer full of nothing but systemd related log bullshit.. because that's really what I wanted to see.
Here are a list of benefits I have personally encountered with systemd:
Intentionally left blank. I have no idea.. honestly I just don't know what systemd does that is at all helpful to me.
eom
audit2allow is an automated rule writer to make usage easier. You're still supposed to use your brain and look at the policy it generates and make sure it's actually sane.
And as a Linux user, I'm very happy about that too.
systemd is completely unapologetically Linux targeted, and made to expose all the cool stuff Linux has but that was getting little use. If it was written in a cross-platform compatible way, there would be no way to guarantee all the functionality would be there always.
Yes, systemd is/was new, and different from the classical /etc/inittab and /etc/inetd.conf. These features justify the changes:
Systemd acceptance will increase when they push some of this into the POSIX standards. The first three above should not be difficult.
It's init, not system. Events and triggers have and will continue to be the domain of the kernel. You still have everything you need for a async, multi-user OS and is nothing like running DOS. I award you no points, and may God have mercy on your soul.
Also if your projects require OS level, dependency based service initialization, your projects suck.
Generally, the improvement is in if it lowers labor required downstream. That's the absolute measure of "better".
Support my political activism on Patreon.
I think about how gnome3 seems to be slowly gaining more acceptance
Gnome 3 has always had a superior workflow, aside from its alt-tab behavior (which can take you to a different desktop, then back to a different window from the same application, then tab you between those two--no rapid swapping between the last 2 windows you touched). With the Activities view, it became possible to just press Meta and swap up/down through desktops, or press Meta and type an application name or keyword ("DVD burner" etc.), and press enter to take the first result. You can tap the corner and move windows to any desktop, or create new desktops between desktops, and so forth.
The desktop environment's job is to get out of your way and let you use applications. When you have to go searching around for windows, or use a lot of manipulation to reorganize your windows across desktops, or go hunting through menus, it's broken. I eventually did look at the menus in Gnome 3--kind of annoying to traverse--only by curiosity; I've never actually used them to find or launch an application. It hadn't occurred to me until someone complained about it.
People dislike change. Learning a new system takes some effort. I happen to identify new interfaces as new systems and not reach for old muscle memory, so switching to a different DE doesn't bother me unless that DE is objectively-worse. That gains me exemption from that particular growing pain.
Support my political activism on Patreon.
I'll leave the unjustified and arrogant name-calling aside. There are lots of Americans on both sides of this fight, yes, but recall that the author of systemd is a German and the rest of the world is well-represented in both camps.
Both of your points A and B are quite true. The thing is that you forget that there other init systems out there that are neither monolithic nor traditional. I think that most systemd opponents would agree that Lennart Poettering's initial observations were good. If he had not been intent on world domination it would have come out much better for everybody.
There is a list of these candidates in init article in Wikipedia. At least a dozen of these are candidates worth investigating.
SELinux is focused on preventing privilege escalation between users. However, most modern systems are all run as single-user (to the point that most AWS instances have no root password). SELinux does nothing to prevent privilege escalation when the flaw is in the kernel (so, gaining kernel-level access). Unfortunately almost all privilege escalation exploits you see these days are kernel level exploits, so SELinux does not do anything to stop the (by far) most common use case. Access controls on a file level are almost useless these days, but the container aspects of SELinux (chroot jails, etc) can still be useful. But then you might as well use containers and get more useful capabilities. To say it again differently, I'll quote Wikipedia:
the security of a "modified" system (based on an SELinux kernel) depends primarily on the correctness of the kernel and its security-policy configuration.
The weakest link by far is not the security-policy configuration.
"First they came for the slanderers and i said nothing."
R! /dir/.* destroys root. /foo/.*" will work the exact same way, no?"
Poettering: "I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf
Processes owned by a user with a leading zero in the name are started with root privilege..
Pottering: "I don't think there's anything to fix in systemd here"
Systemd kill background processes after user logs out.
Poettering: "In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout."
'I have an issue with journal corruptions and need to know what is the accepted way to deal with them.'
Poettering: "Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence."
'Poettering locked and limited conversation to collaborators on 17 Apr'
There is a good reason he got the pwnie award:
https://www.csoonline.com/arti...
Now if this isn't a textbook win-win situation I'm not sure what is. :)
CLI paste? paste.pr0.tips!
Does the pope shit in the woods?
They can take my LifeAlert pendant when they pry it from my cold dead fingers.
FYI, Gentoo and (I think) Slackware are among the distros that have not adopted systemd. I use Gentoo.
Nonaggression works!
Whos the butthurt downvoter? That was one of the most cogent posts in this entire shit thead. Fuck you downer.
Its not the Slashdot point of view, its a vocal minority. Personally I trust the developers at Red Hat more than random posters.
I trust the will of our southern leaders more than I trust random black protesters on the issue of slavery. Go fuck yourself. You're nothing more than the Linux equivalent of a statist.
Regardless of folks opinions, I like it a lot. Especially where it incorporates cgroups which can be handy when dealing with an unruly multiuser environment. It is more complex, but solves a lot of problems for folks who make a living on top of it.
Having said that, I'm pretty sure 90% of the issues the OP was stating have more to do with Linux allowing D state processes and not dealing well with working dirs in to-be-unmounted dirs.
Which is hilarious, because it was SystemD that decided /usr had to be mounted for a sane system boot and screwed up THAT long-standing Linux FS std of having everything necessary for boot post pivotroot in the root filesystem.
If you want to disable SELinux then disable SELinux, but not writing "bad code" isn't an option when even OpenSSL get major holes.
This reminds me of a New Yorker cartoon where the picture was of two winos laying in a garbage-strewn alley and one turns to the other and slurs "...and that's when I realized failure is an option."
In true New Yorker fashion, it's "funny" because it's true.
Android apps are fairly limited in what they can do, and in the absence of a root exploit, they can't go beyond their stated permissions
You're talking about an entirely different security model. Android apps are isolated from each other, and they generally cannot manage the operating system.
In a desktop environment, you typically cannot isolate applications in the same way. Maybe if everyone rewrote their applications to place nice that way---but that's a lot of work and a long time away.
In a server environment, you have applications which monitor/manage other applications, and often applications which monitor/manage the operating system itself. If it is difficult to bring the Android security model to the desktop, it is virtually impossible to do so for servers.
Overall, the idea would be great if it weren't completely unworkable.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
systemd is the Linux version of one of the main problems with windows. It could have been written to be a drop in replacement for _your_init_system_here__ and play nice with existing Unix ecosystems but it wasn't. It's designed to be a "F-U, we're making it solely to benefit us (RedHat) and the way we want to do stuff".
I'm tired of hearing how the old init system "needs improvement" or "just can't hack it in the modern world"... I use Slackware so BSD RC init is how we do things... BIG CLUE HERE: THEY'RE ALL BASH SCRIPTS, YOU CAN EDIT THEM TO ACT HOWEVER YOU LIKE!!!!!
Don't like that things don't start in parallel? Change your init script to bring up the absolute necessities first and then ADD A BUNCH OF "&" to the rest of your script tasks!!!!
Don't like how NFS 'locks up the machine when not available during boot? Change your init script to NOT MOUNT NFS at boot and add lines to your RC.LOCAL to add the mounts later.
The old system is plain old text human readable BASH SCRIPTS! Change what you don't like! Don't use this binary POS systemd!
Your thin skin doesn't make me a troll
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to.
True, but only an idiot would contribute to them. It's like handing the guy with a gun to your head the bullet he's going to use to shoot you. Much better to disarm him while the gun's not loaded.
That's not to say I believe that systemd contributors are idiots because I disagree with it's philosophy, just so they're no confusion; if they agree with it. But to contribute to something with which you don't agree is just plain idiotic.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Patches for those security issues would be prime examples, dunce.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Two separate points, you're conflating them when you should not be.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
"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."
Modding up overt hateful generalizations of ~300M individuals today? TFS doesn't even have anything to do with Americans.
Witness BitZtream getting pwned!... twice.....three times..... four times!
Linux was complex, error prone, and unstable well before Systemd, and will remain so well after Systemd is gone.
But no time to fix Systemd. Well done.
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.
That might be because "systemd is total crap" is not the the Slashdot view.
There are some outspoken detractors, some of whom may have legitimate beefs.
There are the usual trolls who spout nonsense on every thread--for some reason, systemd seems to be a favorite.
There are probably also a lot of people who updated their Ubuntu/Debian/Red Hat from a version without systemd to a version with systemd, and never noticed.
Thank goodness there's still at least one person on Slashdot who knows what they're talking about with respect to systemd.
Wow! You've been on the same hard drive for 13 years! I've been on Gentoo for 11 years, but I'm not on any of the same hardware. Did you go through an x86-to-amd64 transition with the same setup as well? I went with a fresh amd64 stage-3 tarball on the new machine when I went 64-bit.
OTOH, I've pretty much copied my home directory from machine to machine. I've taken to using a build host so that I do things once and install multiple places.
I think I want to buy some stuff from this company now. They sound like a nice company.
I asked which patches have been rejected, not what those (so far not revealed) patches were supposed to be for. The claim was that the systemd team have rejected patches, but so far nobody has given any link or reference to any such patch.
Twat.
Watch this Heartland Institute video
Here's one example.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
I take it you've never looked at /etc/systemd/system then? Because that's exactly what you'll find there. Files. Plain text files. That control systemd's init behaviors and dependencies.
A) Except, randomly firing off process threads asynchronously, and the dephell doing that causes, is the exact reason why systemd was made in the first place. You need some level of process management to do any form of dependency resolution for services. Which was the main issue.
Users have their own services, such as VPN connection daemons, input method editors, midi synths, ID management daemons, SSO, xeyes, etc. that need to run as well, and they have their own dependencies. Some even depend on system services. (For example, Timidity requires the sound system to be running before it starts or say good bye to anything requiring PCM support. Another would be my workplace's proxy daemon which informs the corporate proxy of the user's login.) So systemd needed to be able to reliably tell when a user logged in and logged out to be able to perform dependency resolution for those services as well. Hence the seat management.
B) You are right about some portions of systemd. For example it's DNS resolver. We always have to disable that on new installs due to it breaking DNS resolution of our domain controllers, forcing sssd to fail to log in network users. Why? Because it has "memory" that if the DC doesn't respond immediately when it asks it something, it will never query the thing again. Worse, it breaks TSIG updates because it makes itself the host's only DNS server.
That's the first real gripe I've ever had about systemd. Most of the time it's always been "My ancient initscript that has improper dependencies is broken by systemd, wahhh! Why couldn't they just leave well enough alone???" To which my response was: Maybe because it's those quirks that cause endless amounts of head scratching and claims of "works for me, not for you", due to obscure errors that keep linux from becoming the desktop OS it desperately wanted to be. Now it seems a bit more justified, though nowhere near as much as people would have you believe.
The real issue with linux has been it's lack of standards. Doing something as simple as changing the desktop wallpaper to be something specific, or as complicated as deploying certs to a system's various browsers and hitting all of them with any level of guarantee isn't, and never has been, easy with linux. Every single program has it's own config hidden away in multiple places. (Is it /etc, ~/.config, ~/.local, gconf, or DBUS that I need to change? Are we sure it's not baked into some shared library?) Some even have different config locations and methods depending on the distro. (libreswan Ubuntu: config in /etc plain text files, libreswan Fedora: config is in some nss database stored in /etc.) Others have overriding configs in different places. (Is the order of preference ~/.local => ~/.config => /etc , ~/.config => ~/.local => /etc, or ~/.bad_program_specific_dir => ~/.config => ~/.local => /etc?) Finally some issues are just plain weird and are causing others. Need to add a network user to plugdev? Fat chance of that happening anytime soon. Apparently that's been resolved as WONTFIX because of API issues involving libc. (Yeah, the cause of that issue is apparently the one standard th
The problem is there are a lot of old init scripts that have to be properly migrated
Why? They were not broken. They worked perfectly well since before the idiot who created systemd was born.
lucm, indeed.
Get it the fuck out. I had a VM up in a library and it totally crashed my shit.
Garbage. It is backwards thinking, return-to-monolith-WIndows. One emperor process over all.
Get fukt.
gtfo
Slashdot bitching is not really a good indication of the Linux community in general.
It's certainly not an indication of what people who know what they're doing (like distro maintainers) feel.
"Redhat wanted more control of Linux so they pushed systemd" is "insightful?"
microsoft is the main beneficiary of course, not only they can keep pushing their crappy server OS but now they are able to run almost natively docker images
And /etc/default is good enough for every other package but not for systemd.
Eh? There are plenty of packages that pull default configs out of some location in /usr, with /etc/ being an override. /etc has long (apart from systemd even) been considered the user-editable configuration, and /usr/share the non-user-editable configuration area (among other things).
systemd overtly funded by redhat in order to gain absolute control and veto power over the low-level linux ecosystem.
It's not completely unworkable, it's just in very early stages. And most desktop application don't need to be rewritten. Web browser: needs a rewrite so its permissions are integrated with file pickers (giving an implicitly granted permission) and prompted permissions. File explorer: needs a minor change to de-escalate permission of launched apps. Terminal: no change (running with permissive permissions, like before selinux). Chat applications: optional change (running with permission to write only to their config/data directories and read /etc and the camera/mic and their install path, but file attachments won't work until it adds implicit permission-granting via the file picker widget). Bittorrent app can run with legacy permissions until it's rewritten to use implicit permissions granted by file-picker. Git tools need to run in legacy mode. Game engines and 3D games could have restrictive permissions with no rewrite, or they could run in legacy mode for highest performance.
You're being pessimistic. Most applications could run in legacy mode until they support finer grained permissions, and many other apps could run with restricted permissions and not even know they're being restricted.
A cat can't teach a dog to bark.
Nobody uses Windows? Too complex? Unstable? What the fuck is he doing that fucks up Windows so bad? Fuck off, nobody cares for his opinion.
I don't know what the fuck you're talking about, but I like not having to google what OS uses for starting apps on boot and can use two simple systemctl commands to enable and start them regardless of OS.
It helps to to tell us we can ignore this idiot.
And servers are another case. Server applications would definitely need to be rewritten, but until then they can continue running with legacy (user-based) permissions. User-based permissions work better on a server than on a desktop. (On desktop, the user-based permission model is destined to fail, since every application is launched by one user.)
A cat can't teach a dog to bark.
Great, thanks.
A minor change (+5,-6) to Makefile.am, cool.
Watch this Heartland Institute video
Debian's leaders were split almost down the middle on whether they should go to systemd.
And this brings us to Devuan,
1) It's possible - a big part of Gnome3's growth however was weakening the "we know what's good for you" arrogance of the developers (partly due to the huge user-losses they suffered on release) and actually listening to their users. Thus far, systemd seems quite uninterested in that.
2) This leads into the other problem with systemd - which may make the odds of improvement lower. It is more on the fundamental design level. There is a reason the unix philosophy is what it is. "Small programs that do one thing and do it well", "Simple pipes and text-based configs and communications. It's because this has been the single most succesfull development philosophy is the history of computer science. Unix is now almost 50 years old - no other OS that old is still in active use. It runs on everything from massive server-farms and mainframes to cellphones. Doing widely disparate jobs and it adapts to all these completely different usage scenarios. Just within Linux you have GNU stacks, you have the JAVA based android stack, you have busybox - if you feel like it you can build a system by compiling BSD utilities from source on a Linux kernel and build BSD/Linux - nothing stops you (the only reason you can't go download that is because nobody has wanted it badly enough to maintain such a system - but there's nothing stopping you from making one).
The reason it can adapt is that philosophy - because it's made up of simple drop-in-and-replace programs you CAN adapt it for any use-case. The unix philosophy is very much the software equivalent of an old-style giant bucket of legos. You can drop and in and replace any brick with any other, the pieces are all ridiculously simple but they can connect to each other in well-understood ways and you can build truly magnificent structures by coupling all these simple pieces together in arbitrary ways.
SystemD violates that approach entirely. And so you get the very issue you describe - in one of the most common use-cases it works quite well, in the other most common use-case it works a lot less well - and in the millions of niche use-cases... it fails entirely, because I can't no longer take individual components and arbitrarily swap them out, or put them together in arbitrarily different ways.
The Unix philosophy is to give you a bucket of lego bricks so you can build whatever you need.
SystemD is more like the modern lego-kits, sure it may give you a prettier model of the death-star, but you can't build a model Boeing 747 from the same kit. The lego company apparently decided they'll make more money selliing people single-purpose kits than buckets they can play with for decades and build anything with - it doesn't mean the buckets weren't a far superior product.
And that's a real issue- because even the one use-case it's great at isn't static (not to mention it's a shrinking part of the market - I suspect it's only a matter of time before only programmers, gamers and engineers have desktops at all anyway) - the needs there will change in time, it may change very radically, and it's impossible to predict how it will change. For Microsoft it meant having to rewrite their entire API from scratch in the mid-2000s because it simply could no longer do what their market required, systemD is now creating the groundwork for the same thing happening to Linux in the end - because it's not small, generic blocks you can put together differently to meet new needs when they arrive, you either have to extend systemD to support those needs - or if it cannot be logically be extended that way, you'll have to abandon it entirely and write an all new system !
That's a very real issue - and one there is no good answer for.
So, unfortunately, that leads me to predict that systemD is more likely to get worse than better - the more our needs evolve, the harder it will be for such a large all-encompassing and interconnected project to evolve along.
Unicode killed the ASCII-art *
But downstream isn't one place, there are multiple stops along the way. The assessment of "Better" was made on stop down (the distro packagers) but nobody every really considered the question of whether it would be "better" (by your own measure) for the those even further downstream - the users, the sysadmins, the devops engineers.
I think, objectively, that it wasn't - at least for a large subset of those further downstream (notably experts and sysadmins).
Unicode killed the ASCII-art *
SELinux was just the precursor to SystemD: a complicated and clever system instead of a simple and robust system.
You need a dedicated SELinux resource in order to run SELinux in a production environment in any mode other than "learn what's normal and then allow that".
What SELinux NEEDED was a kick-ass GUI visualization and management application, from the very start, with a static analyzer and a honey-pot option (if an application does a bad thing, don't fail, don't watch-and-allow, but give it a predefined response as if it had succeeded).
Mostly these are packages that predate the establishment of the /etc/default standard, or packages that are small third-party things that aren't shipped by distros, or are so badly coded that you can't actually change installation paths during the build process.
Because even if packages typically don't do it, distros would usually change that- even when it means applying patches to the code while building packages (official debian packages almost always have patches included to modify the package to debian standards - other distros are a bit more lax about it).
But SystemD is not archaic, and it's not a small third-party package whose developers are few in number and perhaps just don't care or know about the standard. It's a major system component, which has pushed itself as an irreplaceable part of every major distro now. Surely such a component of all things should try to comply with good practise and standards ?
Surely the the bar should be higher for a component that aims to replace most of the other components in a linux system ?
But SystemD has never cared about best practise or standards or legacy of any kind. They do whatever the hell they want and everybody else has to either adapt to whatever THEY decided is how we WILL work - or we have to go to the extreme effort now required to avoid them.
That's the opposite of how it's supposed to work. You want your code in a distro ? On my PC ? You should be adapting to the distro's standards, and to MY needs and desires - if you can't do either, then you belong on neither. Upstream should not get to dictate to downstream, that's the way of closed-source software.
The entire point and purpose of free and open source software is the opposite: that downstream should be in control of itself, which requires that the only possible path to acceptance for upstream must be to comply with the wishes and standards that downstream establishes.
Unicode killed the ASCII-art *
I find that logs still get pumped out to /var/log on Ubuntu, yet journalctl captures information that never went to those logs, so it has been an absolute boon in troubleshooting things I'd never understood before. There was a time when I'd occasionally try to run the application myself, or modify the init script; frequently I found this nigh-on-impossible with the ultra-complex, 700-line bash scripts Redhat and Debian like to shove into init.d.
Docker has also been a godsend.
The one time shit pissed me off was when I had /var/spool/mail in fstab, as it's a symlink to /var/mail, and systemd decided one day it didn't like that and forever refused to boot. Took me 3 hours to figure out that wasn't allowed, fix fstab (from the systemd recovery shell it happily offered!), and reboot. That was during an Ubuntu major upgrade.
It's never given me trouble, and has cut out the amount of time spent looking under the hood and trying to muck about with machines nobody honestly understands.
Support my political activism on Patreon.
That's the first one I could find; it's not like rejected patches are published -- after all, they were rejected. You're asking for evidence that only the person who submitted the patch and the person who rejected it would have, and you're asking in a place where you know you won't find either of those people. That I was able to find one example of something that it not typically published tells me there are likely more; if you were thinking objectively, you'd see this truth.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
I started the drive as an x86_64 install. Since then, I've replaced the MOBO twice, the RAM twice, the CPU 3 times, added 2 SATA-2 cards and 7 drives set-up with ZFS RAIDZ2 (Started as 2TB, now up to 7TB of striped and redundant data). It started with kernel 2.6.0-r1 (or so) and I'm now settled on 4.9.6-r1. The system is only turned off or restarted when I lose power that lasts longer then the UPS, or when a serious kernel update requires a reboot, so usually once a year.
I also have a second HD(same make and model as the original) that I use to dupe the system drive with on a semi-regular basis. I love rolling updates. No having to reinstall everything every six months or two years to keep all patches and current kernels.
I've never found journalctl to contain anything that wasn't in /var/log - but if you only checked one file in a folder full of logs you'd likely have missed things.
And if you recall, I said in my original post that System-V had issues - you mention one of the worst, I just don't think SystemD was the best answer available - it wasn't even in the top-5 best alternatives that were available at the time. Personally I think upstart was but there were several other very good ones, and none of them should have been in EVERY distro - each distro should have been using the one best suited to the use-cases and target markets that distro was aimed at.
Unicode killed the ASCII-art *
inetd is far more of cluster-fuck of security problems than systemd. I'm guessing people saying this have only limited Unix/Linux historical experience. They didn't live through inetd.
Hint: look in all the "/etc/rc?.d/" directories, and not in "/etc/init.d".
Of course the /etc/rc?.d directories consist entirely of links to the files in /etc/init.d, all 9000 odd lines of them.
Tell a lie, there are two files in /etc/init.d that are not linked to by /etc/rc?.d -- /etc/init.d/README and /etc/init.d/skeleton.
So, tell me, when did you learn how sysvinit works? Been using it since 1994 like me?
Watch this Heartland Institute video
it's not like rejected patches are published -- after all, they were rejected.
Huh? You think systemd development is done in secret? On what basis?
It's been claimed that the systemd team are rejecting patches en-mass. So far the only example seems to be a trivial change to an automake file, which doesn't seem to have been proposed with any real justification.
But never mind, you've decided that because you can't find anything it must exist and be hidden.
Watch this Heartland Institute video
I can guarantee they've rejected more than one single patch. Where do they publish the list of rejected patches, then? I never claimed development was done in secret, only that no list of rejected patches is kept; and if such a list does exist, surely it lists the rejected patch I've provided, right? So where is it?
As I said, such a list does not exist; but that is not evidence that no patches are rejected; if it were, I would not have been able to provide a single rejected patch.
Dude, get a clue.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
It is a fact that GNU+Linux has got thousands of programs everything doing its task. Systemd has to specify its goals else it is doomed. First of all most programs are never used. At least on my system I mainly use emacs, gcc and make as well some libraries. Minimal operating systems are a big deal. Systemd is overloaded and doesn't really do anything the user benefits of directly. You should ask yourself if you put in a room so much theory, does it become thinking once.
Absolutely. There are some things that are definitely GOOD about systemd. The extensibility/overloading of the service/unit files is a good example of something that works well and is implemented in a way that makes a lot of sense. For example, you can have a service file at /usr/lib/systemd/system/somesystem.service /etc/systemd/system/somesystem.service.d/*.conf
And then modify functionality with units under
It's easy to do, and works nicely with packaging systems so that you can create an addon package to modify or add behavior without editing the file(s) supplied by the original package. The way you can build dependency chains is also quite useful.
There's also some stuff that is lame, like the binary logs and the needed to run journalctl or systemctl to figure out WTF your daemon is doing when it fails, or how the binary log can be corrupted so that you can *never* figure out what happened in some situations.
The biggest problem is the lack of compromise. A lot of people in SystemD-land have a "my way or the highway" attitude, whereas a lot of people in init-land have a "change is bad" mentality.
" Forceful, unconditional kernel operations. When I say "unmount this filesystem," I'm not asking a question. When I say "terminate this process," I expect the process to be removed from memory and the runqueue, regardless of consequences."
Thank you. Nothing is more maddening than doing a "-f" type of operation, particularly an unmount, and having the system bitch at you because "I think something is still using this". I've had major issues not being about to release USB devices that have glitched up because "umount -f" still refuses to actually unmount.
Why even have a fucking force option if it doesn't actually work?
I run Devuan on my home computer and seems to run OK, no big issues. I don't do much either except LibreOffice and a Browser, maybe the occasional scan and GIMP.
One thing about the Devuan community, they were strangely silent when I first tried to contact them after my first install, so I gave up. Many of their web pages also told me 404 on their links.
I update with Synaptic. Funny thing about Synaptic on Devuan. You only get the Title line of a program in the description window. There are no descriptions. If you want to find out what a program does, you have to google it up and hopefully the program name you're looking for isn't some common word.
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
Bjarne closes with the assertion that clean code does one thing well. It is no accident that there are so many principles of software design that can be boiled down to this simple admonition. Writer after writer has tried to communicate this thought. Bad code tries to do too much, it has muddled intent and ambiguity of purpose. Clean code is focused. Each function, each class, each module exposes a single-minded attitude that remains entirely undistracted, and unpolluted, by the surrounding details.
PS: Emphasis mine
Slashdot ya no es que lo era!
Mostly these are packages that predate the establishment of the /etc/default standard,
Given all the packages I've had to mess around with over the years and seeing how they like to do things, I think /etc/default was a very short-lived standard that most just didn't pick up. I'm looking backwards at some of the distros I've used over the years, and I just don't see that it got a lot of traction.
Lots of daemons don't capture stdout. On some systems, you can see logs spew to the console, making tty1 unusable.
Upstart was another SystemV-like, but better. I generally think of Upstart and whatever Gentoo uses as "SystemV" because they attempt to be that with new capabilities.
Just imagine if they all integrated Supervisord instead.
Support my political activism on Patreon.
Systemd straight up ruined linux.
Never until systemd have I considered 'going back to windows' (I've been a linux user since kernel 0.98, most of that time as my desktop environment). Indeed, right now I am using windows to try to find information in support of repairing a failed Arch linux upgrade, which would very likely go a lot smoother if I could use the not inconsiderable experience I have with the classical toolchain.
Whoever made systemd and whoever forced it on linux users can go fuck themselves straight to hell as far as I am concerned.
Upstart was in no way system V like, it had a backwards compatibility feature that led system V scripts work but that was only for non-updated third party software. Upstart's own system used config files, not scripts. Its wrapper utility commands were compatible with older ones created for system V but were drop in replacement code. Upstart was parallel capable, sensibly structured (dependency model) and fast. It was the right way to improve init. And it was just init. Upstart didn't mess with anything else.
Capturing stdout was never actually a good thing. It's not supposed to be logged. It's supposed to be read live if you manually start a command and contain information only useful in that scenario. A well written daemon will not write anything to stdout at all unless you specify foreground running in which case it should give debug level info.
I didn't work with gentoo's init enough to comment on it.
Supervisord is a prime example of why systemD is a bad design. It's a terrible init approach... For almost but not quite every use case. But for what it is designed for its absolutely brilliant, indeed better than anything else I have seen.
Thats exactly where systemD annoys me, no single program can ever be the best for every use case, so having a program that is so tightly coupled to so much of the system that it's hardly possible to replace it (and trying means weird breakages in utterly unrelated software) is terrible because it inevitably forces a bunch of use case to use inferior software.
We have apache and nginx and haproxy and there is great overlap in what they do but none can fully replace the others. Haproxy is simply a better load balancer than the others if your use case is complex because it's specialized and thus has far more powerful features. Apache is still better at doing things like tomcat hosting and nginx is deservedly popular because it's great.
But nothing in nginx says if I use it for web hosting I cannot use haproxy for load balancing despite nginx also having loads balancing features. If I need the extra power of the specialized tool nothing in either stops me combining them.
That's how it should be. The job should dictate the tool, nothing else. There must be standards about how tools talk to each other, how they respond to signals etc. But never standard tools. The task should determine the tool and no tool should make it difficult to swap out a component when a task would be better served by a different one.
There is no such thing as a best program. There is only the best program for what I am doing right now.
Unicode killed the ASCII-art *
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.
Yes, the traditional init systems are so limited that I've never ever had a problem with them in the 25+ years that I've been a *NIX user and admin. The fact is they work great for the vast majority of users.
I'm so happy that my environment was migrated from RHEL to Amazon Linux where I don't have to deal with the systemd nonsense.
Re: kill -9
It's not as good as you make it out... Any single hanging I/O can reempt a kill -9, or any process that is hung inside of a systemcall for whatever reason... I understand what you're saying, but SIGKILL is not an all encompassing magic bullet.
So much for being a "silent" coder...
Trust Red Hat? Ha hahahaha ... Trust, after they screwed users of RedHat-6 by charging for, then withdrawing support. I know ... cause I bought into it ! Krooked as ol' Opera! Prudent Welshmen would not trust RedHat to blojob RMS at a Billary Fire Island fundraising group-grope.
This.
In a nut shell.
Even if you are right it doesn't follow that text config files belong in /usr/lib does it? That's where libraries go. At the very least if it had to be under /usr it ought to have been in /usr/share/SystemD
Unicode killed the ASCII-art *
If "service xyzzy restart" doesn't work then "systemctl restart xyzzy" wouldn't work either
Yes. So?
CLI paste? paste.pr0.tips!
At my office we don't talk about problems with systemd, we just call it a Poettering Error.
But cheer up, it only took about 10 years to get the worst problems out of Pulse Audio. I'm sure systemd will stabilze in a few years time, to the level that you seldom have to much around with it.
Sorry, It's just that your original message wasn't clear -- I thought you were complaining that the "service" command wasn't working properly, not that systemctl restart wasn't working for you.
So did you manage to find out why "systemctl restart" wasn't restarting the service? What service was it?
Watch this Heartland Institute video
HEY I MISS a REGISTRY in a systemd distro ;-)
All the rest other distros already managed to crap
SLACK and BSD are still sane
All the configuration was done by text files with different formats, all easily explained in the file itself, usually, to any human reader. However, it wasn't XML and that WAS BAD. And not being able to force anyone in BIND or telnet to use XML of the blessed format, with a document description that meant that there was no need for HUMANS to understand the format, the XML knew what it all was, for all configurable sources, therefore you could have one "control panel" to configure EVERYTHING without wanting to see text EVER again. And it was XML. And XML is why systemD. If it were just to take over everything, it wouldn't do it this way, it is being done to force XML to be used to configure EVERYTHING. Because it's XML. And that's a good thing. If only because it is not text...
You now see the problem of your use of that "law".
but not writing "bad code" isn't an option when even OpenSSL get major holes.
That's a bad example, the openssl people didn't even try.
"First they came for the slanderers and i said nothing."
You are given this rich open source ecosystem on a platter and you let greedy corporate interests hijack it.
No normal 1-3 person open source project will be able to replace Systemd because of its scope and complexity, only another corporate backed project.
So you have given up control of another important piece of Linux when it was not needed. That is the price of gratuitous complexity and naively failing to understand how corporate interests work.
SELinux is not hard to deal with, especially in targetted mode. Otherwise I agree.
- Michael T. Babcock (Yes, I blog)
Why would we contribute to an obviously broken concept? Most of those complaining feel systemd falls into the "shred it and start over" category, not the "needs a few patches" one.
- Michael T. Babcock (Yes, I blog)
That is to say, systemd fixes udevd not init.
- Michael T. Babcock (Yes, I blog)
Systemd is an unstable, buggy, and a giant pain in the ass piece of shit.
It boggles my mind why the big distros ever jumped on it, but I can't wait for the day when they eventually get over the whole fad and move back to simple startup scripts.
Today I learned that "conversations of slashdot" are consider "coding" by some people...
Unicode killed the ASCII-art *
You don't appear to know anything about how systemd works.
Before systemd it was consistently:
update-rc.d defaults ...
invoke-rc.d
And if your OS was particularly old, call thr /etc/init.d/ script directly.
Just as arcane as systemd semantics. At least I could read the service scripting and see what's happening easily. Not the case with systemd.
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.
When it comes to the Linux ecosystem there seem to be two truly major players/gatekeepers, those being Red Hat and Debian. If they decide something must be installed in the base system, chances are that's what's going to happen, and it's going to propagate downstream. Debian in particular is not used all that much by itself, but it forms the bedrock of some of the largest distros out there.
Red Hat said it hadn't affected sales when they did an interview here.
A company is not likely to change its basic platform because of a few bad decisions, and "keep your old software" seems to be a foreign concept to many IT departments these days. Red Hat caters mostly to enterprise users, so shifting away from Linux, or to a significantly different distro, could easily cost a company tens of millions. This is especially so for high-security government customers such as the military who may have to go through an extensive certification process. I think Red Hat's offerings may be the only ones that they can use short of building their own distro, which would also be very costly and would mean their systems would be incompatible with any standard Linux install, resulting in even more software costs in the future, resulting in a lovely snowball that is probably in the end even more insecure and inefficient thanks to the magic of government. Plus, for many, Linux is still better than Windows, even if systemd is a major negative.
These bad decisions can accumulate over time, resulting in a much worse situation overall, e.g. systemd-based distros that are worse than Windows. But that hasn't happened yet, at least so far as I know of, and moreover, most companies are probably not going to make decisions based on what might be the case if several large organizations make specific decisions and/or mistakes in a particular way many years from now. Most companies seem to be hard pressed to look much past the present fiscal year (or even quarter), particularly if the executives are more interested in their bonuses than company solvency. As such, for the vast majority of cases, deciding to switch away from Linux because of systemd is not cost-effective in the foreseeable future, even if it is an overall major detriment to Linux. The quality and popularity of systemd is highly unlikely to be captured in the sales figures for Red Hat.
as a test for the next packaging system. If systemd removal is any more than apt-get remove --purge the packaging system is broken. Hard depends on libraries that might be used in the future ditto.
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.
they've claimed that they're supporting sysvinit... but in reality, as one of the posts further up points out, they had to REMOVE absolutely critical packages such as udisks2, policykit, and a fxxx load of other absolutely critical packages which should in absolutely NO WAY have anything to do with BOOTING.
even xorg now critically depends on libsystemd, i mean what the fxxx, man??
the only way to get rid of the dependencies cleanly and with full confidence that they're truly gone... and yet at the same time maintain a debian system... is to install angband.pl's alternative replacements.
systemctl works on BSD and Windows now?
Fuckstain
While not trivial it is hardly a complex task.
fuckstain
No one wants to join a project run by a narcissistic asshat dipshit who can not listen to others.
fuckstain