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


Forgot your password?
Slashdot Deals: Deal of the Day - Pay What You Want for the Learn to Code Bundle, includes AngularJS, Python, HTML5, Ruby, and more. ×

Comment Re:Duh (Score 1) 673

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.

It at the very least reduces the chances of a 3A.M. server down emergency to a very small figure if it's in a decent datacenter with proper electrical backup. I have seen a fair number of power supply failures and a LOT of HD failures, but few machines go down for other failures.

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

I know you desperately want to minimize one of systemd's most embarrassing failures, but it just doesn't ring true. I have servers with dual power supplies and RAID (I'm testing brtfs w/ raid1) and I want them to boot in degraded mode if that's what it takes. Systemd is absolutely contraindicated for that application.

Comment Re:Duh (Score 1) 673

First, Linux isn't restricted to x86 hardware (you knew that right?). Second, HA isn't all or nothing. 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).

Honestly, the RAID thing is a brown paper bug for systemd that should never have made it into a distro and should have resulted in a crash program to fix that in days. It should not have resulted in claims of "not a bug".

Comment Re:Duh (Score 1) 673

And let's not forget that systemd destroys high availability by refusing to mount btrfs degraded if one of the drives fails even if it's set up as RAID1. It refuses to even try the mount commend and drops to the shell (eventually). If you issue the mount manually from there, it mounts right up. They apparently don't know what high availability is all about.

Comment Re:Duh (Score 1) 673

If systemd didn't use butt-ugly APIs, it would be a lot easier to mix and match. For exampl, you want to suspend? Call /sbin/suspend which might be an suid binary, or might use a private interface to a daemon running as root (depending on need). That constitutes a nice standard interface. Want to manage a daemon? Run a manager and pass it the path to the daemon it should manage. Again, a standard interface that can be used by any init system to provide more advanced functionality.

It seems that everywhere there is a choice between a goofball tangled mess and a simple and easy to use interface, systemd is all over the former.

Comment Re:Wrong way around (Score 1) 673

It's much faster and easier to cover everything in shit than it is to scrub it all away again.

The projects are out there, it just takes a little while to bootstrap. Meanwhile, I am working with Jessie and fvwm using sysv to avoid systemd to the extent possible. That is, where I haven't just stayed at wheezy for now.

For example, have a look at Devuan.org.

The two most common things in the Universe are hydrogen and stupidity. -- Harlan Ellison