On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
On 9/10/2014 1:44 PM, Russell Coker wrote:
systemd is a debacle, good luck making it workable for yourself and others whom believe it is the /right/ way forward irregardless to popular opinion of most users -- including the silenced [moderated posts? thread] majority whom care like myself.
Install it and it just works.
For some, not for everyone -- that's why you are still trying to make it work by your own admission???
Not sure what you mean by this. If you are referring to BTRFS optimisation, the alternative is poor performance when such files are accessed sequantially. But that's usually only done for backups and an alternative option is to exclude them from backups. If you are referring to other general development work the thing you need to know is that any software that works well does so because lots of programmers work on it. Software doesn't magically work by itself.
The only problem I've seen with systemd is the journal file being excessively fragmented on BTRFS. As you don't use BTRFS that won't be an issue for you, but if you did then you could just configure systemd to limit the size of it's journal (which is a good idea anyway).
I've heard of one case where an auto-mount USB device that wasn't connected at boot time caused systemd to fail to boot the OS, even though the file system on the USB device wasn't significant for the boot process at all.
Did you file a bug report?
There are more systemd issues, but most of all, the so called ills of sysvinit are due to poor [errors] configuration and not a failing of sysvinit itself.
Using cgroups to track daemons to allow reliable shutdown is one feature that solves significant problems with SysVInit.
People often mocked Debian for being stale for the stable installations ... give me stale with sysvinit any day, it works very well -- don't force packages to depend on systemd, it is not wanted, nor warranted; fix any apparent configuration issues [that's all
When a package depends on systemd it does so for a technical reason. No-one is putting in gratuitous dependencies.
they of the issues that exist] with sysvinit and you don't have any need for systemd. Upstream, for gnome and network-manager, well they need to remove reliance on systemd and fix their own issues relating to configuration with sysvinit.
I don't use NetworkManager. The Gnome developers have reasons for using systemd, feel free to read debian-devel or any other mailing list where such things are discussed. On Thu, 9 Oct 2014, "Peter Ross" <Petros.Listig@fdrive.com.au> wrote:
From: "Russell Coker" <russell@coker.com.au>
Technical analysis of the features and relative merits of different software has some value.
For a FreeBSD user it is annoying if a well-known Unix/Linux desktop environment gets "Linuxalized" via systemd etc. It is obviously harder to port it to other than Linux if you think of systemd during development in the first place.
What does Gnome do that is so hard to port to non-systemd? Also there's nothing stopping you from just porting systemd to BSD. I think that upstream don't want to take the patches, but that's the same situation as OpenSSH...
The init scripts are grown in nearly half a century and are well-thought through.
Apart from the majority of scripts that have grown without being well thought through. Consider the startup process for MySQL as one of many horrible examples.
In substance, a daemon start/stop script looks the same under all kinds of Unix. A postfix start/stop scripts runs under any kind of Unix/Linux so - minimizing the work to integrate it in any kind of distribution.
The actual start/stop of the Postfix "master" process is the smallest part of it (in Debian at least). Most of it is about maintaining the chroot environment. Admittedly that chroot stuff would also apply to systemd, but your claims of Postfix scripts being the same on all kinds of Unix are obviously wrong.
For a physical server I wait for the hardware when booting, the OS initialisation only take seconds.
A jail is running more or less immediately. The gain will be in millisecond range.
Other people get different results.
[This is opinion] The history of Linux daemons close to the hardware (udev, hald, policy-kit, dbus, kdbus) as well as filesystem layout (procfs,sysfs) does not convince me.
The history of all the alternatives shows the benefit of udev.
It all feels half-baked (sometimes even a bit narrow-minded, "I need this for me here now", and there are huge egos involved it seems) and I am not confident about quality and security of the code which is redone every few years and with competition between different approaches (and with this, splits in attention and effort).
Except that it's not being done every few years. We're talking about a change in default that's once only in the history of distributions such as Debian. On Thu, 9 Oct 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
It certainly looks like systemd is dividing many more people, it most certainly is not worth the trouble it is causing even at this stage.
This is the type of arguments that supporters of Dubya used to use. Anyone who disagrees is "divisive". -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/