Slashdot Mirror
You Got Your Windows In My Linux
snydeq writes: Ultimately, the schism over systemd could lead to a separation of desktop and server distros, or Linux server admins moving to FreeBSD, writes Deep End's Paul Venezia. "Although there are those who think the systemd debate has been decided in favor of systemd, the exceedingly loud protests on message boards, forums, and the posts I wrote over the past two weeks would indicate otherwise. I've seen many declarations of victory for systemd, now that Red Hat has forced it into the enterprise with the release of RHEL 7. I don't think it's that easy. ... Go ahead, kids, spackle over all of that unsightly runlevel stuff. Paint over init and cron, pam and login. Put all of that into PID1 along with dbus. Make it all pretty and whisper sweet nothings about how it's all taken care of and you won't have to read a manual or learn any silly command-line stuff. Tune your distribution for desktop workloads. Go reinvent Windows."
What's wrong with services.msc on a Windows Server machine? Any serious answers from people who actually used it?
This space for rent.
Oh day of days! Now it needs to statically link in gconf and we'll all have a registry too!
Is anyone really concerned about this? Let me put on my prophetic wizard hat and predict how this is going to go from here:
I'm really not trying to be flip but this is just the FOSS process at work here. It's messy sometimes but so is anything that involves people. Embrace the ecosystem that makes this whole argument possible! If Apple or Microsoft decided they want some polorizing system like Systemd to be the new hotness in their OS offerings there's literally fuck all we could do about it. At least with the FOSS environment we have the freedom to make our own decisions
"[...] the exceedingly loud protests on message boards, forums" - and all other places that don't matter
This is *the* stupidest thing I've ever read on Slashdot. Holy crap. Can we mark this as spam and delete it?
I have some apprehensions about systemd and the direction it is pushing Linux, but the bug-eyed histrionics from the systemd haters is so comically absurd that it doesn't exactly make me want to join their cause.
What I don't understand is why systemd advocates continue to not understand the perspective of those against it. Critics tend to recognize what systemd brings to the table and debate from that point. Advocates just call those people idiots, curmudgeons, and so on rather than understanding the perspective of the opposing viewpoint. It's quite maddening.
Init runs as PID 1. Systemd runs as PID 1.
Most init systems have a negligible amount of code running as pid 1, meaning init itself is unlikely to ever cause a blip at runtime. The complaint is what the implication for the complexity and volume of code in systemd approach. A better counter argument would be that the kernel itself has even more complex needs and runs in an equally critical context. That's a bit more defensible, though adding more complexity under that excuse is still a weak one.
Claiming that "lots of people don't like systemd equates to anything other than lots of people don't understand systemd, but will complain anyway is just stupid
No, lot's of people who know well enough how systemd works and still don't like it for valid reasons. No one claims it is not capable of things that classic init could not really do, but the question is the relative value of those features and what is given up in the pursuit of those capabilities. systemd is more monolithic in design, involves more compiled code beyond the reach of the typical shell capabilities of a sysadmin, and is more complex in its underpinnings in general. If your boot went off the rails in a classic init system, you can work through it using shell debug because it is comprised of a tiny bit of c code that hasn't changed in an eternity jumping into a sea of plain old shell scripts.. You can chroot and play around a non-booting image if needed. If systemd goes off the rails, it requires a much more complicated debug effort. You pretty much have to start up a container rather than just chroot (admittedly systemd provides a facility to mitigate the complexity of that task, but it is more complex than just chroot). It has a high likelihood of landing in some code a sysadmin is helpless in the face of compared to the same task in classic init scripts. A local mistake can escalate to systemd debug assistance more quickly. This is very much like Windows (which has it's qualities as well) where if things go off the rails very far, it's nearly a lost cause to sort out what happened and how to come back from it unless you have Microsoft developers ready to answer the call to debug it (and they almost never are).
Some people don't like them new fangled fuel injectors and still think a carburetor is the way to go as well.
And there are tons of carburetor platforms in the wild for brand new products. Try finding a leaf blower with fuel injection. The cost and complexity of a fuel injection system is too high in many applications. If cost and complexity were equal, then *everything* would be fuel injected, but cost and complexity are not equal. This is actually a very good analogy for systemd, capable of inarguably fancier tricks but the universe of mechanics who can repair it when broken versus throwing the whole thing out is much different. The relative merit though is more questionable (everyone benefits from lower fuel consumption and reduced uncombusted gasoline in the atmosphere, not everyone really benefits meaningfully from the advances in systemd).
What systemd advocates fail to recognize is that not everyone should have to be an application developer to administer systems. They assume minor configuration mistakes are all sysadmins have to contend with and thus they don't understand why a sysadmin might need to follow the flow of the init system in more detail and yet not have the ability to easily cope with systemd code. The 'DevOps' buzzword may embolden assumptions in some circles, but it does not mean that good sys admins have magically changed, just th
XML is like violence. If it doesn't solve the problem, use more.
It means no such thing. You need to learn about spwan and fork, then get back to us.
That scenario doesn't involve the special nature of pid 1 at all. Any pid can screw up a system. Traditional init is a handful of lines of compiled code and systemd is significantly more to assure services cannot escape their cgroup and other such tricks.
. The kernel does not run " in an equally critical context" at all
If pid 1 crashes, the only thing I can really do is sysrq. The division between kernel space and user space pid 1 is largely academic for a sysadmin afflicted by a crashing bug in either one of them. Yes there are thnigs kernel c code can do beyond the reach of user space code, but that was really not the point of the discussion.
There is nothing more inherently complex about systemd than any other init system
If that were the case, why would systemd exist at all? Systemd exists because they wanted to pull off some tricks they couldn't do in an init system that could be followed by a simple 'set -x' in key locations. Like Windows, when things work, they appear simple enough on the surface. Like Windows when things go wrong, you are pretty well in a weird world.
XML is like violence. If it doesn't solve the problem, use more.
Did that. Not regretting it.
CLI paste? paste.pr0.tips!
I must fess up. I've used Unix since 1978. I cut my teeth on System V and I just fell in love with it's init.d system, where I could control an entire 80 port modem bank enable/disable with a simple change of the init state. telinit 5 - multiuser, telinit 6 - multiuser and modem banks. Heck you could even put that in a cron job. The init system of SYSV was simple, easy, powerful and logical. It is the UNIX WAY.
Fast forward to this labor day weekend, and I had to go into work for a 'Webserver Down' call. Sure enough a hardware failure, so I rebuilt a new system using the *Latest and Greatest* linux distro that was systemD. I needed Apache to fire up with an init.d script, when run-level 5 was hit. Oh wait, how do you do that? Well this is clearly explained so clearly and idiot could do it. It's in /etc/systemd in systemd.conf? Nope! Is it in /etc/systemd/system? Nope! Which one is it? I find a softline from system.default to /lib/systemd/system/runlevel5.target. I 'cat' and it says:
---
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
After=multi-user.target
Conflicts=rescue.target
Wants=display-manager.service
AllowIsolate=yes
---- /etc/rc initialization method. At least it's readable and understandable. All I want is add is Apache_special_ctl start in the initialization to multiuser mode. Were are the readable BASH scripts at? I'll try to emulate IRQBalance, When I drill down soft-link after soft-link I finally find this;
In other words this is a damn maze of BS! Some windows wanker wrote this puzzle to destroy Linux I'm convinced. I'm tempted to switch to BSD just to enjoy the
-----
[Unit]
Description=irqbalance daemon
After=syslog.target
[Service]
EnvironmentFile=/etc/sysconfig/irqbalance
ExecStart=/usr/sbin/irqbalance --foreground $IRQBALANCE_ARGS
[Install]
WantedBy=multi-user.target
----
Hang on, where did the variable $IRQBALANCE_ARGS come from? Grep? nope, more grep? nope! More google searches? Nope.
This is BS. I don't care if you can do a parallel start up (fundamentally you can't anyway, but in init you could use '&' idiots). The complexity added to the system start up and the 'telinit' process is inexcusable and is the worst computer science or computer engineering I have ever seen! It should be tossed into a dumpster! Seriously! Even young programmers will never figure systemd out. It's an undocumented programming maze of gotcha's.
Needless to say my efforts failed and I tossed the machine across the room for the fun of it.
Systemd developers deserves the finger for such an programmer unfriendly pile of trash that replaced elegance and simplicity.
I would be interested in the anyone's response to Lennart Poetterings rebuttal to the common complaints about systemd.
I'm too n00b to know who's right.
Full disclosure: I do not like systemd, although that judgment is based on its merits as I see them relative to my needs.
There seemed to be a pretty concerted determination not to get the point in Lennart's long spiel defending the system. As someone who has been using Unices in anger since the early '90s, I've pretty much seen Linux grow from its infancy. I've seen this kind of attitude before in technology — in Windows, Linux and elsewhere. The article is clearly written (and written clearly) by someone who's clever, articulate and... far too concerned with being right. It's not a healthy perspective.
Being technically correct is not generally optional. It's just not ever nearly as conclusive as some people think it is.
Having the humility to accept an imperfect universe — and to admit that it's imperfect in a particular way for a large number of particular reasons — is a virtue that fewer and fewer people seem to possess these days.
(It's the lack of this virtue that makes people say, for example, 'less and less' where I used 'fewer and fewer' and when someone corrects them, they trot out the grammar nazi epithet and say, 'Everybody knows what I mean. Deal with it.' And the lack of this virtue as well that will make people pick on the triviality of this example to discard my entire post. The temerity of such an approach cannot be explained to those who suffer from it.)
Systemd is clearly not change for change's sake. Lennart and the dozen and a half others who have commit rights are clearly scratching an itch. But regardless of the technical merits of the system, it is horribly, horribly wrong to impose this new system —any new system— on Linux wholesale without a significant maturing process. And by significant, I mean years.
And this is where Lennart's most completely mistaken. He thinks that the technical arguments are the decisive ones, in spite of the fact that technical merit is not why systemd is going to become prevalent. He therefore tries to write a technical opus in defence of the indefensible, which requires more than a few straw men (binary config files? shyeah....), several big ommissions (binary log files) and a clearly unwilled but nonetheless unforgivable ignorance of the fact that he's winning because he's RedHat, not because he's better. (Yeah yeah yeah, it's not all RH; it's others too, you're technically awesome - I read that part and remain utterly unconvinced by the argument.)
Paul Venezia's screed, on the other hand, is just plain substance-free. He's not arguing either technical merit or political power. He's simply looking at a looming mess and saying, well, that it's going to be messy. And to that extent, he's right. Systemd is going to make a mess, and that's precisely because its proponents think that they're perfectly within their rights to claim, 'Well, nobody's forcing anything on anyone.'
What they don't realise is that that is not how cooperation works. And believing you're better or righter than others is an absolutely shit way of improving your own software.
Crumb's Corollary: Never bring a knife to a bun fight.
Here we go:
1: If it *ISN'T* monolithic, why won't Gnome work wiothout it and why aren't the pieces available seperately?
2: If it isn't about speed, why is that all people talk about? What is so 'right' about the way systemd does things?
3: Servers start fast enough without systemd. In the cases where they need to start faster than is typical, they also tend to run ONLY the critical sevrice (ans so already start fast) OR they start the critical service first (and so it's also not a problem). The argument about VMs is entirely specious. The same services must be started either way, so the same I/O and CPU load has to happen one way or another.
And as for 'socket activated containers', it's called (x)inetd and we've had it for decades now.
4: The problem is that often server admins just need to make a small change to the standard shell script that starts a daemon in init.d. Except with systemd, there may not be one unless the distro was smart enough to effectively sidestep systemd by making it start rcS only and sticks with the scripts.
5: Are you freaking kidding me? Where's the howto? Where's the overview? Where's the freaking manual? Most of it is of the nature of 'absolutely true thing isn't REALLY true because OHH look, a bunny! (run away)".
6: I'd rather not recompile every time I want to re-configure my system, thank you very much. The modularity we're after happens at runtime, not compile time. Kinda like in the kernel, I don't have to load the modules I don't want.
7: It all kinda falls apart once 1-6 are dispelled. It adds unwanted complexity and dependencies to the server. A perfect recipe for disaster when things are going badly and the server is hours away by car.
8: Nothing systemd does couldn't have been done using a few helper apps. Had it been done that way, nobody would have a single objection to it. So why wasn't it done that way? That's right, NIH.
9:Well, let's see. It's hosted there, it's developers talk the same talk, and it's all been snarled together into a single dependency ball......
10: Only someone who never grasped that Unix is about small parts that do one thing well tied together through scripts and file-like objects could have written that.
11: A few big honking packages is certainly not simpler than a series of small and largely independent packages. It's a question of how much you have to know in order to do a simple thing. Small packages always win that question.
12: How big is init? Because in Unix, that's the part that has to be loaded. All the rc scripts do their thing they go away. They don't stick around after they do their job. In systemd, most of it insists on staying for some reason.
13: The problem is that it creates a moral hazard. It invites other unrelated things to become dependent on it (like gnome of all things) and so, not compatible with BSD. And BTW, a lot of us Linux folks don't want it either and don't appreciate the dependency trap being used in an attempt to cram it down our throats.
14: You're ACTUALLY arguing that since they worked so hard, what's a bit more? REALLY?!?
15: So there's so many dependencies it's even trapped itself? That doesn't sound like a feature to me... I thought you said it was modular, not complex and not difficult!And didn't you claim it was Unix? BSD is Unix and you're telling me it is intrinsically incompatible? You say there are far too many dependencies and it is all too complex to port? Do YOU even believe what you write?
16-17, no comment
18: So in other words, it IS feature creep!
19:Heh Heh. It's not like you HAVE to breath or anything. You could always hold your breath forever if you don't like my farts. I'm sure it is pure coincidence that other freedesktop projects have developed a hard dependency on systemd when they clearly never needed it befiore.
21: Yeah, it's all perfectly compatible as long as you do it our way rather than the way you did it before.
24: Compared to init, that IS buggy and unstable
You do have to put a fraction of the time you did in 30+ years of learning your way around SYSV systems into actually learning systemd in order to expect the same level of proficiency.
This is BS. "Learning" SYSV configuration takes 15 minutes to explain run levels and that everything is scripts and (usually) symlinks. You could even learn what you need by recursively grepping /etc for a process name and the script it's in is readable to anyone with programming experience. GP pointed out that a config file for systemd is sitting in /lib. WTF?