What will systemd be doing to Linux?

M

MacLindroid

Well-Known Member
Joined
Apr 25, 2014
Messages
179
Reaction score
0
Location
celebricity
Pardon my sheer ignorance but this is a cut or six above my pay grade. I am a layman, after all!

My understanding is that Linux used to follow a Unix-like approach towards the init process, using separate shell scripts for every process in the startup phase. My understanding is that systemd will combine all of these, plus networking, journalling, etc., in a single "secretly coded" binary process.

Doesn't this go against the fundamentals of the *Nix's?

Also: will this not open the door to (conspiracy theorists will likely feed on this but it is NOT posted as flame bait) all sorts of backoors, allowing paranoid governments to sniff at our tailsides?

How, if at all, will it affect security and also the end user?

Then another question comes to mind: if this systemd goes south, will we see the charshes similar to that of Windows? My Windows 8 did quite well and seldome crashed, recovering well but my Linux always have been crash-free. Will this change with systemd?
 
And may I ask what the real fuss is about? I read about death threats and serious fighting between Upstart and Systemd disciples/zealots?

How many folks REALLY understand this technology well enough to explain to us "lesser beings" what the toxic wars are about?
 
I don't think it goes against the fundamentals for nix. For one, even though it is a binary managing the system startup, the source code is still available, and anyone that want to, can go have a look at what it really is doing. It is not like it is completely a mystery as to what is in the code, as is the case with windows.

The benefits are amazing. To name a few:
- if a process crash, systemd will automatically restart it. In the past you would need a separate daemon to do this, like monit or use supervisor ect.
- no more init scripts that is done is different ways by different authors. everything use a very simple systemd unit file. so consistency.
- systemd startup times are even faster than upstart in my experience
- processes can start up multithreaded instead of 1 by 1 as with most init rc scripts

The only negative you can get from systemd, that it is also doing a lot more than just the init system. Nowadays it is taking over configuring the network, syslogs are gone and moved into the journal, logind ect. However I still see this as a huge benefit, as in consistency over all the linux distributions using systemd, now works the same.

I really believe systemd is moving linux forward into the 20th century. Using only scripts is really too old nowadays, and things need to at least improve, and systemd is doing this for linux.

Systemd won't change how the system manages crashes of the kernel, only of individual services/daemons.

As for the fuss, I will try to sum it up.
1. The original author of systemd and pulseaudio is the same person/developer. Since pulseaudio had a bad rep because of how bad it was initially, people still wants to stay away from his software. However what most don't know, pulseaudio's problems wasn't because of pulseaudio, but mostly due to bad and/or incomplete linux audio drivers

2. Ubuntu created upstart to replace the regular linux init rc scripts and system, and wanted their solution to succeed and take linux forward. Systemd was the only real contender to this ideal/ideology. When Debian who Ubuntu use as their upstream source for each new Ubuntu release decided to go Systemd, this threw a huge spanner in the works and their hand was forced to drop Upstart for future releases and go with Systemd instead. Mostly because it would be way too much work to keep on making everything compatible with Upstart while Debian is working to keep everything working with Systemd. So basically they want to reduce their work and keep on benefiting from Debian's work.

3. Trolls. Yes you get these in the linux world, and there are those who really don't care what happens, they just like to troll and have heated discussions going on forever not leading to an end result. Much like the Nvidia vs ATI and Intel vs AMD debates, which is neverending.
 
Thank you for the nice explanation, Tinuva. All-in-all, a storm in a teacup swamping seven oceans!

At least now I also understand and, should another geek-under-construction venture past here, it will be educational.
 
It is a pleasure. I will admit, I am a huge fan of systemd. I use it myself on Archlinux, as well as CentOS 7. As with most things, it takes some getting used to, but once you have, you will ask yourself, why has it taken this long to get here. If a service fail to start, it is right there with the start command, so easy to find out what happened, as long as the service gives proper output to systemd.

I personally like that I can now use the same commands to manage services on different linux distributions. CentOS and Archlinux used to be worlds apart and different. The latest versions is much closer to being the same than in the past.

As an end user on desktop linux, I believe you will probably not even see a difference, except for maybe 1-5 seconds faster boot times ect.
 
It is not as if Linux need to boot faster; it is really fast at start-up as it is. As Linux also hardly ever requires a restart, getting it to boot faster is not what the average user is crying for. :D

I am a fan of anything that works well. I have Linux running on Macs (because ML & Mavs needed too much fiddling to work after updates) and also on a jurassic old AMD Athlon TF-20 system. Linux is just so much faster as far as general computing is concerned; its advantage over OS X shrinks to a marginal lead when processing graphics.

Well, if the desktop user is not going to notice anything, let us just enjoy the journey :)
 
Interesting you mention that services don't restart themselves with init because I'm pretty sure they do with Upstart.

I only got deeply involved with Linux since Upstart and mostly on Ubuntu only so maybe I misunderstood.

Respawn is then a function of Upstart?
 
SauRoNZA said:
Interesting you mention that services don't restart themselves with init because I'm pretty sure they do with Upstart.

I only got deeply involved with Linux since Upstart and mostly on Ubuntu only so maybe I misunderstood.

Respawn is then a function of Upstart?
Click to expand...
It is possible. Ubuntu is not my most used distribution. I would put Arch, CentOS and Debian on the top of my list.
 
The linux community hates change, every time there is something new and different there's wailing and gnashing of teeth and one would swear the world's gonna end the way they carry on.

I like systemd, has not had any negative influence on my life and I've been using it since arch adopted it. I don't care much for ubuntu, debian went with systemd so ubuntu will fall in line and drop upstart.

The next big moan is gonna be the depreciation of X11, I can't wait for wayland to become mainstream. Mark my words ubuntu will conform and drop MIR in future.
 
Lennart Pöttering is not a complete weirdo (in spite of the David Bowie-esque lighting) :)

[video=youtube_share;Rm68XYskgH8]http://youtu.be/Rm68XYskgH8?t=34m58s[/video]

This was a nice interview, imho.
 
adrianx said:
Lennart Pöttering is not a complete weirdo (in spite of the David Bowie-esque lighting) :)

This was a nice interview, imho.
Click to expand...

Interview starts at 35:00 for those that don't want to sit through all the crap.
 
Maybe I should step in with a word from the other side in order to keep the discussion balanced (devil's advocate?). Right off the bat I'll admit that I have read up only superficially about this debate, so I'm not overly informed on all the issues.

The "systemd is not Unixy" argument is not only about systemd being binary, but that it violates the Unix principle of "do one thing, and do it well". This relates to systemd doing (quite a lot) more than just focusing on being a kick-ass init system. I think this principle has served all Unixy systems very well so far, and makes systemd's approach a little concerning. The effect of this has already been seen in some old vulnerabilities that has resurfaced in systemd. I think it was this one and/or this one.

The systemd programs being binary is not really a problem, but the binary system logs (journal) kind of goes against the the "everything is a file" Unix philosophy. I know it is still stored in a file, but you can no longer use all the wonderful text processing utilities (perl, sed, awk, ...) to process it without being dependent on the systemd binaries that can read the journal. This will probably turn out not to be a big problem (once the journal becomes less buggy), but seems like systemd going too far "out of scope". A side effect of this is that all the old (ancient) but still used monitoring tools will be immediately obsoleted. Yes, we can (and should) write new ones, but it will take a long time.

Now, I'm all for updating/replacing these very old sub-systems, but I cannot say that I agree with a monolithing approach. The better approach (IMHO) has been to create some standardised interfaces/protocols with discreet components implementing the standard(s), that can be swapped out for an alternative. Even systemd as an init system should be optional. This is (AFAIK) not something that systemd has done.

As far as consistency across distro's go, that is quite the invalid argument: We have different distro's exactly because they want to do things differently. It is the differences that have given us this vibrant Linux ecosystem, and is part of the freedom it offers. The freedom of choice. If you want consistent systems, use the same distro. (What would Linux be without flame wars? :P)

With all that said, people much more knowlegable has decided on the issue, and I am not in a position to do anything about it. So I'll just go on and hope that systemd turns out to be what they want it to be, without too much fallout. I certainly won't be switching to a different OS because of it.
 
The other problem with systemd has been the attitude of the core developers toward bugs. Instead of fixing these, revising their approach, etc., they find it easier to rather blame the `incompatible' piece of software, when the real problem is in systemd itself. This has even gone so far as to have them blaming the kernel itself, which of course was met with well-deserved opposition from Torvalds himself.

That said, at least one of Torvald's machines does use systemd :)
 
Give it 5 to 10 years, everyone gets nice an comfy with systemd, and then some bright spark
will reinvent the wheel again with init scripts.

Thin client in, fat client out.
Functions out, objects in.
OOPs in, OOPs out , Lambda in.
And the spinning wheel goes roun.d and roun.d
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X