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.
Some of us stopped using Red Hat when the NetworkManager mess came out with RHEL 6.
Why would we expect RHEL 7 to be any better?
You RedHat fans have fun with your "RedHat Vista" release. :P
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
My experiences with systemd have been good and I can see how it can eliminate some of the kludges I've relied on in the past. Rather than have an /etc/init.d/myservice restart all related services to ensure a "clean" environment, I can list dependencies and triggers and rely on the system to do what is appropriate.
It doesn't eliminate the ability to create or use System V init scripts, it just provides administrators with an alternative. Given the distribution creators have put a lot of effort into converting their scripts we have a lot of examples to work from. I've been working with UNIX since the 80's and rather than adopt a "get off my lawn" mentality I'm looking forward to embracing solutions to modern problems and see this as a positive step forward.
"[...] the exceedingly loud protests on message boards, forums" - and all other places that don't matter
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.
ecosystem, but for working tools. Democratic messiness is great when it results in working tools. But as an end in itself, in software development? Meh.
STOP . AMERICA . NOW
systemd reminds me of Solaris' svcs, and I DO NOT WANT.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Except we don't see systemd solving any problems. It is a solution searching for a problem.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
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.
"Although there are those who think the systems debate has been decided in favour of systems, the exceedingly loud protests on message boards, forums, and the posts I wrote over the past two weeks would indicate otherwise.
"Although there are those who think bacon is tasty, a loud protests I've posted recently on message boards, forums, and here on /. over the past two weeks would indicate otherwise."
(Yeah, I've been here long enough to know that nobody at /. does any actual editing. Still, can I make fun of the submitter for making it sound like (s)he's the one who is going around and posting all the loud protests, and then trying to make it seem like some sort of movement?)
Yaz
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.
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.
XML is like violence. If it doesn't solve the problem, use more.
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.
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!
Well, are you a nice troll too! Anyways, no monolitic, crappy, uninformed and anti-UNIX monstrosities will ever make it into my PID 1.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Wow, something so awful even some Gnome 3 users can't take it.
brandelf -t FreeBSD
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.
I think it is megalomania. Not a good basis for trusting these people. The only alternative I see is that they know their thing is really a disaster waiting to happen.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
I'll use a "server" distro on my laptop before I'll ever use systemd.
Currently ZFS on FreeBSD is rock solid with high performance, while on linux it's not up to that point as of mid-2014. In the space of file servers that's a good reason to change for now.
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.
-Bake in more advanced log processing to mitigate the need for log analysis tools.
What was wrong with log analysis tools? One can bang them out with perl in a minute or two.
Starting up /bin/sh hundreds of times during boot is wasteful and slows boot.
No, it really isn't. Process creation is cheap on Unix, and the shell will not only be cached during boot, but one or more copies of it will be present in memory at all times. Running the shell hundreds of times today is a triviality compared to running the shell dozens of times on Unix machines from the 1980s, on which that was in fact not a big deal, because process creation is cheap on Unix. This is just not a real consideration for any modern system, especially given the plethora of lightweight shells available for low-memory or otherwise limited systems.
Sequential startup of services is silly when many can be started in parallel.
This is really the argument that something new was needed, but frankly, it would have been simple enough to handle this without a whole new init system. A shell script wrapper would probably have done this job. Some distributions are already recording dependencies in init scripts; sequence information would be simple enough to add. If this is the best argument for systemd, and so far as I can tell it is that, then it's a really crap argument.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The problem with Windows isn't what it is trying to do but how it is trying to do it: the highly interdependent object-oriented libraries, the widespread use of C++ for basic services, bloated functionality in everything from the file system to the mouse. Even if every single daemon and server in Windows were superior to Linux individually, the entire system would still be crap because of that.
The situation is pretty simple.
1) Gnome and then more software depends on systemd
2) Debian doesn't want to fix those problems
ergo: easiest solution is to make systemd the default for Debian.
This would be a fight and Debian decided not worth it.
Init was simple, but it left me pining for proper dependencies among daemons. I mean, more than simply trying to stipulate a runlevel loading order by numbering symlinks.
For example, I don't want samba to start unless iscsi is successfully up, etc, etc, and I don't want to code a bunch of one-off scripting in various daemon script files. There are many more instances just like this, and init doesn't handle the use case.
Services are one thing (dependencies, monitoring service status, etc) thar Windows got right. I didn't like the glue / bootstrap code and installation for services, but it's far closer to what I want than init. Solaris' approach also seemed nice, at least upon cursory examination.
Anyhow, systemd gives me what I have always wanted, at the cost of me having to learn a new approach. That's a fair trade.
I hate Gnome 3, Unity, Metro, the last 3 years of "improvements" to Google services UX, etc. Conversely, systemd honestly feels like an upgrade in practically every way.
Seriously, can someone tell me what horrors caused by systemd that I have overlooked?
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?
This shows how old I am but when I first started in web development I was mortified to find out IE would let me erase the visitor's hard drive with a web page.
That's over half of Microsoft's existence that they spent building the perfect opposite of a server. Linux was built to be like Unix, which was designed and built as a server from day one. Not surprisingly, Linux is good at what it was made for (network computing) and Windows is good at what it was designed to do - user-friendly local desktop work.
Sorry, but this is BS. At best it is true for the Win 9x strain of Windows. Windows NT was a clean implementation of a new operating system with the Win32 API reimplemented to support backwards compatibility with Win9x.
Windows NT was built as a network OS from the start, whereas Unix (and Linux) was built as a multiuser OS. The difference is evident when you look at how e.g. a user account has been represented: In Windows a user (or group) account always includes the authority responsible for the account.
In Unix/Linux there is no such concept: users and groups are identified by integers and are implicitly users of the local machine.
Windows user accounts are global in nature: Every time you has a reference to a user, you have the reference to the authority as well. Unix/Linux user accounts needs to be mapped using all kinds of strange tricks especially on networked resources, because it was never perceived in the original design that you other machines would work with the local machine trough a trust relationship.
This is actually why the biggest reason to go with Windows servers is Active Directory: It was trivial to integrate the established user/account regime with something like AD, since AD simply became an "authority" - for which Windows NT already had support. Unix at the time had to resort to strange quirks such as NIS domains.
In general, it has *always* been a pain to share user accounts across Unix/Linux systems, while on Windows you could set up an AD (or a domain before AD), and software did not have to be rewritten just to pass credentials from machine to machine.
After the nice Windows desktop, Microsoft invested a billion dollars developing and deploying a technology called COM. The basic idea of COM was that you could embed documents from one program inside documents from another program, and that did cool things.
You don't know what COM is. What you are referring to here is called OLE - Object Linking and Embedding. OLE is/was built on top of COM - but COM was *never* about being able to embed objects.
COM is a language-neutral binary object model, which ensures that the system has a common object model where objects can be consumed regardless of what language was used to develop them. It is still very much at the core of Windows, mainly because it is so efficient (being a binary standard it has extremely little overhead - especially for in-proc objects).
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Oh, I doubt openrc will go away completely, as long as somebody cares to maintain it. Gentoo never really turns away oddball configurations entirely. What you might find is more and more packages that lack an openrc script - even before systemd came along you could find the oddball package that lacked a script, and if many devs switch over you might find a lower level of support for openrc.
But, nobody is going to tell you, "you're not allowed to run openrc." Despite all the noise people make publicly, the reality is that within Gentoo the maintainers of systemd, udev, eudev, and openrc work fairly closely together to try to keep things running smoothly. Heck, there was just a discussion about whether systemd should support being able to switch back-and-forth with openrc by default, and the answer was yes, even though it involves installing a few files that are otherwise unneeded by systemd. Current policy is that when it comes to installing stuff like init scripts both systems should be supported by default so that people who want to switch either way don't have to rebuild half the system just to get some scripts. Of course, if you're talking about stuff like gnome3 you're not going to find equal support for both.