Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Back for a limited time - Get 15% off sitewide on Slashdot Deals with coupon code "BLACKFRIDAY" (some exclusions apply)". ×

Comment Re:Duh (Score 1) 737

J - Non process managed systems are simply not going to be supported.
P - Unsupported by who? Who gets to decide what is supported and what is not?

The GUI developers. Developers are who get to decide what OS components are going to be dependencies for their software. Debian changed because there were strong signs that developers were starting to introduce hard dependencies for systemd. While those could be overcome for Jessie, the feeling of the Debian people is that in 2 1/2 years there wouldn't be a choice. And while the switch in 2014/5 introduced some bugs the switch in 2017 would be much worse. The anti-systemd people (who are mainly low end system admins) refused to accept that developers don't want to deal with the ever increasing complexity managing complex process management using init. The issue was upstream from Debian, having the argument with Debian was living in denial.

As hardware gets more complex making a more complex uses possible, the underlying OS needs to become more complex to support it. There was a very disruptive change in PCs when people moved from single tasking to multi-tasking. It destroyed Amiga. It cost Microsoft something like $8b. It essentially destroyed Apple. Lots of people argued that task switching was good enough and much less disruptive. But ultimately everyone (excluding some embedded systems) switched to vastly more complex systems which had kernels with more in common mini computer kernels from a decade earlier than the CP/M, DOS and simple Unix kernels of a decade earlier. Notification is the beginning, but once notification works you are 80% of the way there to really exciting features. 10 years from now the idea of a human trying to manage service dependency will be as quant as writing assembler is today.

Comment Re:Duh (Score 1) 737

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) 737

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) 737

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) 737

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) 737

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) 737

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) 737

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) 737

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) 737

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.

Many people are unenthusiastic about their work.