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."

Comments

Re:What's wrong with Windows Server?

[Anonymous Coward]

Not having to manage licensing... is a gift all its own. I'm not talking about not buying licenses, I mean not having to deal with ANY of that shit for servers... a blessing.

THIS is the reason I build so many linux servers. When you compare costs of a typical Windows based small business server vs a linux server, linux wins hands down. Unless there is a very specific reason to run a windows based server, I always run linux servers. No licenses to keep track of, no extra up front software expenses.

Re:Troll much?

[X0563511]

systemd reminds me of Solaris' svcs, and I DO NOT WANT.

Re:What's wrong with Windows Server?

[PRMan]

I've never used the "Support" on any Linux box yet. And almost never on Windows either. It's quicker to look it up yourself. In fact, out of the 3 times I called Microsoft Support, twice I got refunded for figuring it out while on the phone with the "experts".

Re:Troll much?

[armanox]

Except we don't see systemd solving any problems. It is a solution searching for a problem.

What do we need systemd for?

[Anonymous Coward]

My main problem is that the old init system was dead simple to administer. You only needed to know basic shell scripting as well as grep and you could figure out most things you ever encountered. Systemd again is a horribly complicated program that probably no one except the developers understand inside out.

It seems to me like this whole systemd/upstart etc. nonsense started when someone wanted to make machines boot up faster. The problem is that in today's world how fast a machine boots is completely irrelevant. On VM's you can clone a running machine, so how the OS starts is unimportant. A classic server is always on and rarely gets booted. Laptops, which seemed like the obvious target, are typically just suspended to disk, so they rarely run through the whole boot process. Desktops are typically sleeping too when not in use.

In other words, I still haven't figured out why anyone would need systemd. I've never had a reason to need it. I've only had reasons to hate it when something that used to be very simple is now hidden behind some complicated shell commands.

Re:What do we need systemd for?

[Endymion]

While the obvious answer is that Poetternig/RedHat wants a windows alternative they can sell to "big" software developers, a more cynical (and mildly speculative) answer is that systemd is an outstanding way to shoehord into linux all the things that linux users would never normally allow. PID 0 is an important spot to control; if it wants to, it can control what programs are started and under what permissions. There are a few groups that really want this capability, or at least the capability to add something optional that can later be a forced dependency in GNOME or some other popular package.

The first group that comes to mind are the people who want DRM and a protected media path. A monoculture that forces features on users whever it wants to change things is the only way you'd get around the problem of having distributions simply compiling out or otherwise ignoring your DRM. Systemd has effectively raised the costs of not using whatever future "upgrade" is mandated, because the tight integration means you have to replace all the other software you now use as well.

Another group that would really like it if a buggy, alpha-quality, horribly overcomplicated, uncommented, unproven, monolithic black-box of software was a required to use Linux is... the NSA. Simplicity is important when it comes to key services like PID 0. I'm sure it's just a coincidence that the NSA is one of RedHat's larger customers, and that the NSA - while suberting NIST, Cisco, etc - submitted various pateches through redhat. I have no proof, of course, but you don't get security by assuming eveybody is being "nice". I strongly suggest listening to PHK's talk on this subject.

Finally, I'll link a post I just made over at HN. The reason systemd is causing emotions to run high is because it is trying to do to linux what has been done to many other tools: dumb it down and hide how it works. There are a lot of people trying to do that right now, because the idea of open computing that *cannot be limited* (see: "turing complete"). Welcome to the Civil-War On General Purpose Computing.

Re:What's wrong with Windows Server?

[rahvin112]

Almost everyone I've asked that has expressed hatred of SystemD hasn't actually used it. The vast majority either hate the creator or read some blog post, all but one had never used it or tried to understand it. I attribute much of the hatred to a "I hate change" attitude that is unfortunately common in the *Nix sphere.

Re:What's wrong with Windows Server?

[NemoinSpace]

Haha, that is pretty funny. For the first time in several years, i have bad karma myself. It's quite enjoyable to offer contrary opinions on subjects as varied as global warming to police shootings to lindows. Yup, having good karma kinda started making me feel old. (Which i am). Now i don't consider my way of thinking any more valid than any other lost soul on slashdot. But it seems poking blowhards with sticks is quite enjoyable. The real question now is what are we going to call the linux registery. (I mean the part after the 'K-' or 'G-'. I always thought windows would make a linux version mainly because as we have seen, having the linux folks reinvent windows is taking longer than planned. You should not be surprised what some people at MS can do to a version of windows (Me, Vista) especially when compared to what Iomega has done to debian5. Yeah xml config files! Systemd is going to be great once they are done with it. Which will be never. This might be the break BSD needs to take the desktop from linux. LOL mofos.

Re:Too late, we already bailed.

[Zocalo]

Likewise. In the process of migrating a considerable proportion of a large RHEL estate over to BSD here. A general lack of satisfaction with RHEL6 started our look at alternatives - including other Linux distros - but SystemD was our deciding factor in the making the slightly more drastic leap from Linux to BSD. Despite the dream of Linux on the Desktop, most of us are actually running Linux on servers with (hopefully) competent personnel, so we don't really need some cuddly desktop OS that needs to pander to the lowest level of luser or the additional cruft and abstraction layers that brings, let alone the mess of package dependencies that seems to be afflicting Linux at present. In some cases we're seeing significant perfomance gains for what, in theory, should be the same basic set of code so for us it's more performance for less cost, and possibly an interesting call with our RHEL rep when the first tranche of RHEL licenses come up a renewal we are not going to need...

The King is dead, long live the King!

Re:What's wrong with Windows Server?

[r_naked]

I hate posting a "me too" post, but you nailed it. Who the FUCK thought that having to run a separate command to find out if your service started was a good idea?!?

I work in a shop that has ~2000 Red Hat servers / VMs, and my advice will be to switch to something else unless Red Hat gets their heads out of their asses, and gets rid of systemd. Unfortunately we don't really have the option of moving to FreeBSD (tooooo much code to port), but I am sure their will be a distro that fills the void. At least we have a few years to worry about it since 6.x is supported for a few more years -- hell I might fork the final 6.x release.

Lennart Poetterings rebuttal

[Art3x]

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.

Re:Lennart Poetterings rebuttal

[Anonymous Coward]

Overall a good read for people who are against systemd, in case they are against it for the wrong reasons. However for me it rings hollow:

monolithic:
" we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.". The design of all of them is inexorably linked. The component that lives as pid 1 is more complicated than what formerly lived as pid 1.

speed:
whether intended or side effect is a moot point. This should in no way be held as a point against systemd. I presume he's trying to address how dismissive some people are about systemd. He's right, it isn't about speed, it's about more complex issues.

boot speed is needless for servers:
Yes, there are some use cases where boot speed can be good in a server context. There are many more cases where it does not matter. It's silly to tell someone that boot time isn't a big deal to them that it really is. A sysadmin knows damn well which case his falls under.

systemd and init scripts:
"We just don't use them for the boot process, because we believe they aren't the best tool for that specific purpose" Here he misses the point. The complaint is not that people cannot use their own shell scripts, it's that they are now repsonsible for supporting third-party non-scripts by others more than they already have to.

systemd is difficult:
  This is a point where it's nearly impossible to retain perspective. as the archtect of systemd of *course* it all makes sense to him. The issue is that other people who are not in that position take issue with it. His rebuttal basically boils down to 'nuh uh, I understand it fine!'

systemd is not modular:
" At compile time you .." I think that speaks voulmes right there... Compile time modularity is not the worrisome demonstrative facet, runtime modularity is.

systemd is only desktops:
true, their intent covers servers and in fact some features that only really appeal in a server. Much of the sysadmin base disagrees, but this is a subjective matter.

Myth: systemd was created as result of the NIH syndrome
They tried somehting else first before thoring up their hands and going NIH. Again, a moot point, the results matter more than the beginnings.

systemd is a fdo project:
Who the hell cares whether it is or isn't?

systemd is not unix:
strictly the myth is true, but linux is not unix either. The statement being addressed is that systemd is a departure form the unix-like ways. This is undeniably true, just differnt audiences have different opinions on the value of that.

systemd is complex:
He made it, so he understands it better than the stuff he did not make.

systremd is bloated:
What moist people mean here is feature creep, not resource consumption

not nice to BSDs:
the complaint is really not nice to people who administer both platforms, not that BSDs are themselves maligned,

there are a lot of oversimplifications about porting it to other places, but I think people don't WANT it ported, so that's a lot of evangelizing to a group that does not exist.

not debuggable:
it is debuggable... if you are a developer.. again failure to keep perspective of many sysadmins.

Re:Lennart Poetterings rebuttal

[Anonymous Coward]

It's relatively straightforward point by point.
Just by way of disclaimer, I don't consider myself a systemd hater; but I think that it has massively overreached. At best, it creates a new issue of dependencies (where applications are tightly coupled to systemd versions, and systemd versions are tightly coupled to kernel versions, creating a dependency where none existed before). Most likely, it's just an attempt to re-invent Windows (under the control of Red Hat). At worst, it's ... well, the haters will tell you the "at worst."

Overall I would say that in situations where facts are in dispute, he is generally right; but the conclusions are completely wrong.

Point 1, monolithic. The point is not the number of binaries. The point is the number of things running in PID 1 (too many) and the fact that so many applications must be changed to work with systemd. And, what's worse, that it's increasingly hard to work both with systemd and without it. GNOME 3 is the best example here. If systemd started services and that's all, that would be great.

Point 2, all about speed. I guess I don't really see this as a valid criticism in the first place. Oh no, it's faster! I think speed is actually one of the best things about systemd. It's just that the speed improvements could have been realized without creating so many other problems.

Point 3, boot time is irrelevant for servers. People say that because it's true. Sure, systemd might save ten seconds or even thirty seconds in service boot time, maybe. More likely it is not that fast. But as a server admin, the hour I spent troubleshooting a problem is much more important to the overall downtime than the ten seconds I saved when everything was happy.

Because systemd requires rebooting so much more often, I think the average server admin will probably spend more time booting with systemd than without it.

Point 4, incompatibility with shell scripts. This is a misrepresentation of the actual problem. The actual problem is not that systemd lacks some theoretical capability to run shell scripts, because that is not the case. The problem is that the service configurations actually deployed with systemd are in fact not shell scripts and therefore cannot easily be reconfigured. Effectively, if you need to do something different than what was conceived of by the systemd authors, you don't just have to make a small change to an existing shell script, you have to basically start from scratch. This makes things harder, not easier.

Point 5, difficulty. I guess this is too nebulous to argue with really. I guess I would say that users are typically either professional admins and software developers, who should be expected to know how to write shell scripts, and desktop users who are never going to change their init configuration anyway. The idea of breaking the traditional configurability in the pursuit of some improved approachability benefits no one because there are no real-world users who benefit from that. And as we all know from Microsoft, making things look simple is not the same as making them easy. It is quite the opposite in fact, as the simple UI gets in the way of the more capable users while nevertheless still being impossible for the casual users to get right.

I would draw a parallel with programming. People who don't program usually assume the hard part is learning the syntax, and therefore a language with simpler syntax is an easier language to learn. Sometimes even people who do program make this mistake. But in the end, it turns out that C and Ruby and Scala are better than COBOL and BASIC and Java. Not only more powerful - just plain better, start to finish.

Point 6, modularity. I'm not sure that's a real complaint that I've heard, at least not in the way he takes it. Nobody really cares how many compile-time options systemd has. Only Gentoo and FreeBSD users ever actually recompile their init system, and they, generally speaking, don't use systemd (It's possible with Gen

Re:The Future!

[jbolden]

2 comments.

First almost all distributions already go with systemd. Gentoo is the only major holdout and that's harmless since Gentoo is fairly self supporting. Gentoo also doesn't use init they use a very good upgrade called OpenRC. There is no systemd fork going on. I think there are a small group of people who would like a fork but they aren't going to get it.

Second, for the End Use it is fairly easy to imagine what would happen for distributions without systemd. Right now in init people kludge together systems which restart daemons when they have problems or monitor them. Most likely those kludges don't get written when systemd is ubiquitous on the major distributions. Which means end users on init based systems will have daemons go down and stay down or ask for resources and not get them. They'll experience a much more buggy unreliable system. "You have to reboot Linux every couple days otherwise too much stuff doesn't work".

_____

As for the rest reducing the pool of available developers for most choices. This is where it gets tricky. You can look at the distributions overtime and see big differences. Take for example the original (in the USA) big 3 Linuxes of 20 years ago:

Debian -- heavy focus on open source. Willing to be hard to use. Server focused
RedHat -- moderate focus on open source. Aimed to be easy for hobbyists. Workstation focused
Caldera -- indifferent to open vs. closed source. Aimed for commercial functionality, especially desktop using a Novell LAN.

OK let's go back to that point in time. How do you prevent the original fork? Clearly those distributions served different needs they have different users in mind. Now let's look today

Debian -- meta distribution that is key end users are distributions who distribute free desktop Linuxes or embedded systems. Focused on being the leader in keeping Linux open and free.
RedHat -- Enterprise server and infrastructure. Just starting to refocus on embedded.
SUSE -- Meta distribution designed to allow for containerized custom OSes for VMs.
Android -- Meta distribution for touch enabled ARM hardware

Again very distinct user bases. Arguably on that list SUSE and RedHat could merge. But beyond that, where do you a merge potential?