Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Take advantage of Black Friday with 15% off sitewide with coupon code "BLACKFRIDAY" on Slashdot Deals (some exclusions apply)". ×

Comment Re:Duh (Score 1) 712

A simple window manager wouldn't be dependent on a process manager. A GUI however is going to be dependent on a process manager. Kwin and Mutter don't require systemd, KDE and Gnome do. GUIs need many processes to be running and communicating with each other. Which means when things go wrong they need to resolve it. A GUI needs to provide process management. Modern GUIs in particular, where there is an expectation of dozens of processes running notifying the user require quite sophisticated process management. Arguably the thing that drove the biggest change in Gnome 3 / KDE 4 from Gnome 2 / KDE 3 was introducing a framework dependent on much more sophisticated process management because they wanted notification to work well.

So for Linux either:

a) Each GUI provides process management and most applications can't be cross GUI
b) The GUIs agree to share a process management framework and then there is a hard dependency between the GUI and this process management framework.

In the days of Gnome 1, KDE 1/2 the world looked more like (a) where neither GUI had a desire for the other GUIs apps to run well. Linux was then in the process of forking into two incompatible operating systems. The customer base however objected to this fork and since then the move has been towards (b). There is no reason in 2015 to object to process management while using a modern GUI. FVWM, Fluxbox, Sawfish etc... never claimed to provide this kind of service so of course those window manager are likely to continue to run fine on distributions that don't use systemd. As time goes on the less sophisticated Linux products are going to need to provide viable means of running large numbers of processes that have dependencies on one another and resolving dependency issues in real time. Non process managed systems are simply not going to be supported.

Comment Re:Duh (Score 1) 712

I would say it's a 90% solution if you have RAID and dual power supplies on separate circuits (this is common in x86 servers these days). Add in dual network connections and you're certainly on the threshold of diminishing returns.

And if the network to that location goes down? If the location loses power for an extended period? If there is a fire?

but few machines go down for other failures.

I've seen lots of machines go down from an upstream network problem. 50k+ servers go down because of a configuration error in a in a telco router during a routine upgrade that takes the system down for hours.

Sure, for only 100x more money you could get a non-stop like solution but few applications justify that outlay.

Mainframes aren't 100x more money.

I want them to boot in degraded mode if that's what it takes. Systemd is absolutely contraindicated for that application.

Simply not true. .add rootflags=degraded in GRUB_CMDLINE_LINUX

Comment Re:Duh (Score 1) 712

Very few (very expensive) machines go all in on HA. By far, the most common case is RAID (which is implemented on x86 hardware all the time).

I wouldn't call RAID in and of itself HA. So I'm going to strongly disagree with a characterization of saying this "destroys HA". It does nothing of the kind. If you are using x86 non clustered you aren't HA. So at best it destroys booting by default a non-HA system on a damaged RAID.

In any case systemd is designed to handle error conditions. You tell it what to do on errors. In this case there is a flag to tell systemd to mount a degraded raid that can be added so you change the default behavior. I can see the argument that this is perhaps not the best default to just drop you to emergency shell, but I can also imagine the other side where systemd feels it is too dangerous to allow the system to risk total data loss by continuing to run. Pick the default you like.

Comment Re:Duh (Score 1) 712

He didn't cheerfully refuse to fix it:

Well, cgroups-less kernels are explicitly not supported by systemd. However we added some hacks to allow it to boot to a certain degree even if a lot of things will not work correctly afterwards. In this mode when you boot you will actually get a warning on screen and bootup is delayed by 10s to make sure the user understands this.

Now, this mode recently broke, and it will segfault early on. I am happy to take a patch to 'fix' this again, but I will not work on this as i dont run kernels like this, and as mentioned its not really supported anyway...

Another option is to simply be honest amd stop supporting in entirely, and refuse booting completely. And I figure this is what I will eventually do if nobody cares enough to send me a patch to fix that segfault.

He's happy to accept a fix the segfault. He will take a patch or just have systemd refuse to boot. You were misrepresenting his position by saying he refused to fix the segfault.

Comment Re:Duh (Score 1) 712

Again think of systemd as a process manager. Once you have process management you don't want an init system. Why would you want to distinguish the move from init to everything running from other process management? Whether you want a process manager or just want an init system is a different question than being able to break apart a process manager.

Comment Re:Duh (Score 1) 712

No I'm saying that there is no difference between non sensible error messaging resulting in a crash and and just crashing. Obviously full error handling is better. But no system survives every possible case. Cases get logged they get fixed. That takes time and all software is vulnerable to being tricked into failing to boot properly.

As for the VM. If the VM doesn't have access and systemd is running on the VM then you are missing a hard dependency for your boot system. You wouldn't expect the kernel to boot without ram installed.

Comment Re:Duh (Score 1) 712

Do we actually need two abstraction layers?

We wouldn't if the kernel provided sophisticated process management, logging... But since it doesn't yes you do need that.

So systemd is an operating system in itself, in this view. Why not. Not sure that how it has been sold, though.

It has. Pottering has always said that he wants systemd to be the interface for userspace the way the kernel is for kernel space. Every application that doesn't need low level interfaces with the kernel should would be using systemd to provide services. Effectively Linux kernel + systemd + X11/Wayland... become the OS.

Comment Re:Duh (Score 1) 712

The primary use cases for Linux are embedded systems and very large server farms. Niche system admins running 1-100 boxes are an important constituency but not even 1% of 1% of the Linux out there. Linux as a cloud based OS is more important than Linux as a strictly hardware based OS. I don't agree that systemd creates problems for hardware, as you mention it is popular on desktop. But if ultimately one of the other has to go overboard...

Comment Re:Duh (Score 1) 712

I'll give you something you couldn't do in 2008 but can do today that I've been able to do on mainframes for 2 decades. Start running a process, take the node running that process and yank the plug, keep all session data fully intact as the process moves to another node. What systemd is doing is creating the application hooks so that this becomes possible in most rather than just a few applications.

Comment Re:Duh (Score 1) 712

What you are missing is verb tenses. The decision to move to more modern architectures was being made around 2007. The specifics then got rolled out in 2010. Now the effects are being felt. The choice isn't starting to be taken away, that happened a long time ago.

There is going to be choice among modern configuration but not the choice to use "modern" software in 1990s style configurations. Same thing that happened to CP/M users.

No problem is so formidable that you can't just walk away from it. -- C. Schulz