You Got Your Windows In My Linux 613
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 Windows Server? (Score:5, Informative)
Re:What's wrong with Windows Server? (Score:5, Informative)
Re:What's wrong with Windows Server? (Score:5, Informative)
If it was just replacing the /etc/init.d mess, that'd be fine.
My main problem with SystemD is that it is turning into this massive black hole that's trying to replace many different systems in one. And not very well at that.
Why replace pam.d, crond, init, and add complexities like dbus in a single package that runs at PID1 when it doesn't need to? So now a single flaw in its crond could allow a vector that lets dbus provide a way to trick pam.d into letting users escalate their privileges? Sure, it hasn't happened yet, but when you start intertwining these apps into a single super app....
Worse, the logging it provides is next to useless. If I have a headless server with no GUI, how the hell am I supposed to read binary logs? It doesn't even give me useful information during the boot process. At least my old init scripts could do that much.
It completely goes against the core principles of UNIX in general. Do one thing, and do it damn well. Make it interoperable with other processes. Log to text. Configure with text.
I don't want this massive beast of a process that replaces my options. And I especially don't want one that isn't even very good at performing the original single task its supposed to be replacing, let alone all the franken-tasks its taken on.
If this were just about replacing init, I doubt I'd be anywhere near as bothered. But as an active admin, this bothers me significantly more than just having to redo my startup scripts.
Re: What's wrong with Windows Server? (Score:5, Informative)
I'm not either, but that's hardly the point. Let's say something isn't documented properly and doesn't work the way I expect: just being able to read the source code can be extremely helpful.
But it goes even beyond that, because open source software naturally forms communities around it. Even if I were to never even look at a single line of the source, the fact that it's availble to others adds value for me. I can go download a patch someone else wrote that fixes a bug MS hasn't bothered to fix. I can ask someone who's read the code how it works on Stack Overflow. Or when someone uses that source as a basis for an entirely new and improved version, I can switch to that.
Re:What's wrong with Windows Server? (Score:5, Informative)
But OpenRC (Gentoo) does dependency management without having to replace init.
Now systemd does give you a lot of advantages when it comes to fully managing processes, respawing and dbus/alerting. But that's also part of the problem. It connects to EVERYTHING. And if one of those things breaks or has a security flaw, you could pass messages around and compromise systems.
Not to mention the command line tools SUCK.
Sys V: /etc/init.d/ (stat|stop|restart)
Upstart: (start|stop|restart)
Systemd: systemctl restart .service
And you get ZERO output. You have to run journalctl -n or systemctl status right after it. Who the fuck thought that was a good idea?! A widows developer?
Re:Troll much? (Score:5, Informative)
Well it does solve some problems, just not problems many server administrators largely cared about while creating problems some systems administrators really do care about.
-Services cannot reparent themselves out of the launching context, meaning init system *always* knows how many processes it is and resources it consumes. It's nice and structured, too bad that ps axf and grep largely serve the same purpose when things went south, but the systemd approach is certainly more structured. Of course it means that you can't try out a systemd controlled service start in a chroot, since it can't take pid 1 and how could we have *possibly* ever lived starting services as anything but pid 1.
-Bake in more advanced log processing to mitigate the need for log analysis tools. The problem of course being that those log analysis tools tend to work well enough while leaving the plain text behind in a manner that can be trivially opened and perused in Windows or whatever.
-Starting up /bin/sh hundreds of times during boot is wasteful and slows boot. Systemd mitigates that by enabling more lightweight service start. However you'd have to care something about boot times, which is rarely even in the mobile category (android phones take forever to boot, but people don't seem to mind since they almost never reboot them), and not mind that more opaque binary code is handling stuff that a common sysadmin cannot trace.
-Sequential startup of services is silly when many can be started in parallel. Of course now you have to debug a less deterministic boot process to enable such a thing, with the same inscrutable code paths for the sake of a faster boot very few people needed.
Re: Debian general resolution needed (Score:4, Informative)
There was no general resolution selecting systemd, you smug liar. Someone reported the fact that systemd was not default as a bug and the eight man technical committee (tech-ctte) decided for systemd in a tie broken split decision. An end run was done around the rest of the debian devs. Anyone who opposes systemd is labeled a troll and banned from the mailing lists now.
Re:Troll much? (Score:2, Informative)
Of course it means that you can't try out a systemd controlled service start in a chroot, since it can't take pid 1 and how could we have *possibly* ever lived starting services as anything but pid 1.
Systemd supports both:
1. Running as PID 1 in a container using a separate process namespace (which is at least as good as running in a chroot).
2. Running as non-root - you can use it to manage your own services under your own uid.
However you'd have to care something about boot times, which is rarely even in the mobile category (android phones take forever to boot, but people don't seem to mind since they almost never reboot them), and not mind that more opaque binary code is handling stuff that a common sysadmin cannot trace.
What are you going to be tracing in the init system anyway?
And if you want to stop a container, snapshot it, and restart it, you would definitely prefer that this operation takes place in about 100ms and not in 30 seconds. PID 1 doesn't just run after disks spin up and the POST completes.
You missed a bunch of other features, like native support for namespaces/containers, or not leaving orphans lying around when a service stops, which would certainly be interest to somebody running a server.
Re:What's wrong with Windows Server? (Score:2, Informative)
$ cat /var/log/syslog | ./your_filtering_script.sh
- or -
$ journalctl -f | ./your_filtering_script.sh
Was that so hard?
Re:What's wrong with Windows Server? (Score:5, Informative)
Uhm... cp has the exact same behaviour as systemd. Examples from my system: /bin2
: cp -ar bin bin2
: cp -ar bin
cp: cannot create directory ‘/bin2’: Permission denied
: echo $?
1
: systemctl start dmraid.service
: systemctl start imaginary.service
Failed to issue method call: Unit imaginary.service failed to load: No such file or directory.
: echo $?
6
:
So, systemctl behaves exactly the same as cp - error message and non-zero return on failure. Perhaps you were thinking of the verbose option for cp, which some people alias in permanently but is very non-unixy?
Re: What's wrong with Windows Server? (Score:3, Informative)
Even if I were to never even look at a single line of the source, the fact that it's availble to others adds value for me. I can go download a patch someone else wrote that fixes a bug MS hasn't bothered to fix. [...]
I am also in favour of Open source myself and get your point. However, after the OpenSSL bug, my belief in this "someone else" has significantly lowered. If too many people rely on "someone else" fixing a problem in his/her spare time you are worse off than when people are paid to fix closed source software. If the problem is important ($$$) enough, it wil be fixed.
Heartbleed was a subtle bug that was fixed after 2 years and 1 month of being in the release branch of openssl. Looking at the "critical" and "important" bugs in the latest round of Windows patches, I see one that has been open since IE6 was released (13 years), one for windows 8 (21 months), OneNote 2007 SP3 (35 months), SQL Server 2008 SP3 (35 months), Windows 2003 (11 years) x2, SharePoint Server 2013 (18 months), and .NET Framework 2.0SP2 (5 years).
It looks to me like open source is working just fine here; Hearthbleed appears to have been fixed much faster than an average important security flaw in a closed source package.
Comment removed (Score:4, Informative)