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'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: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