Debian 8.7 Released (debian.org)
Debian 8.7 has been released. An anonymous reader quotes Debian.org:
This update mainly adds corrections for security problems to the stable release, along with a few adjustments for serious problems. Security advisories were already published separately and are referenced where available.
Please note that this update does not constitute a new version of Debian 8 but only updates some of the packages included.
There is no need to throw away old "jessie" CDs or DVDs but only to update via an up-to-date Debian mirror after an installation, to cause any out of date packages to be updated. Those who frequently install updates from security.debian.org won't have to update many packages and most updates from security.debian.org are included in this update.
86 packages have been updated -- including some fixes for systemd. ("Rework logic to determine when we decide to add automatic deps for mounts; various ordering fixes for ifupdown; systemctl: Fix argument handling when invoked as shutdown...")
There is no need to throw away old "jessie" CDs or DVDs but only to update via an up-to-date Debian mirror after an installation, to cause any out of date packages to be updated. Those who frequently install updates from security.debian.org won't have to update many packages and most updates from security.debian.org are included in this update.
86 packages have been updated -- including some fixes for systemd. ("Rework logic to determine when we decide to add automatic deps for mounts; various ordering fixes for ifupdown; systemctl: Fix argument handling when invoked as shutdown...")
You forgot to add "Run Redhat through a shredder".
I like Red Hat and I appreciate all they've done for open-source in the enterprise, but the desktopification of core Linux aspects is a bad thing. It's fascinating to see how Microsoft took a desktop o/s and shoehorned it into a server product, while Red Hat is taking the perfect server and adding stuff like systemd to make it more convenient for desktop users.
systemd is bad for servers. It adds nothing, just makes everything brittle and clunky. Maybe it's awesome for plug & play devices and soundcards and window managers but none of that is relevant on servers. No wonder even in the CentOS docker images it's not enabled by default - it's USELESS.
lucm, indeed.
Systemd has helped raise awareness of the *BSDs.
Many former Linux desktop users who were driven away by systemd have ended up using FreeBSD. Many who ran Linux servers have started using OpenBSD instead. Those who ran Linux on older or less-powerful hardware have discovered the joys of NetBSD.
Systemd has turned out to be one of the best advertising campaigns for the *BSDs.
This behaviour is where I really dislike the sytemd way. The "it will be done this way, and only this way" attitude. It's my system, why should I not be the one who gets to decide policies such as this? In the initscripts world, this would have been effected through a little configuration file in /etc/default, which would customise the behaviour of the script (or you could edit the script as well if you wanted something truly custom). While systemd does allow some modicum of customisation in the unit files, there's a heck of a lot of policy and behaviour directly encoded in the implementation, which an admin isn't going to be able to touch without rebuilding the thing. While old and crusty, sysv-rc and initscripts left every part out in the open and hence amenable for changing and tweaking. So the "don't boot if a single filesystem in fstab fails to mount" policy would have been a tweak to the mountall script (or better, one of the mount helper shell functions).
Been using systemd for nearly 5 years now and have never had a boot problem from it yet.
Probably because you aren't actually 'doing' anything that presses systemd beyond the most simple use cases.
I bet you don't, for example, use NFS mounts, or NAS, or run applications that fail to release mounts when systemD tells them to shutdown. I bet you've never had to sit on a console watching a server hang on shutdown because systemD has walked its self into an impossible loop waiting for an application to quit, which is waiting for a drive write to finish, which is waiting on a mount that's been disconnected because systemD thought "all systems are a go"
If you haven't had systemD problems it's because you haven't done anything complicated enough to expose them. You might as well just say "the computer worked great in the store demo, I don't see what all the buyers are bitching about"