Slashdot Mirror
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...")
The old pile of shit was willing to keep its fingers out of other people's pies if you wanted to try something else along side it.
It also understood imperatives. If you tell it run something NOW, it does just that, every time.
We never had that much modularity in the first place. Most distros all used the same core components anyway. But if you want to you can still disable pretty much any systemd component and replace it with whatever you want. I do that in Docker, I have lots of containers that use only systemd as init and journald, and my app. Nothing else is running in the container, and if I wanted something more I could easily have systemd start it for me.
Actually, I want to to use other tools to help boot the system. With sysvinit, I can easily plug modules at will.
because something was done in the wrong order.
I know it sounds like a really radical idea, but howsabout just specifying the right order?
But here's an example: I was testing a system with BTRFS doing mirroring. As part of the test, I dropped one of the disks to simulate a failure. Systemd flatly refused to start in degraded mode. It dropped to the shell every time. There was no way to tell it "Just mount the damned thing and let me worry about it". So much for high availability. Under sysV, I just added the degraded option and it worked every time. If I want to wait an arbitrary amount of time for all the drives to spin up, I can do that in the mount script with no difficulty.
Literally anything systemd can do could already be done using simple helpers called by sysV. You even provided an example yourself.
Have just reinstalled Debian after 17 years away from Linux on my home machines. I have to say I'm impressed. It worked on a 2007 MacBook without any messing around. Graphics, sound, fan speed, touchpad, brightness and volume buttons, sleep etc. all worked out of the box. The default desktop looks good. The fact that it's a root distribution and not derived from something else makes it feel solid. I'm liking it. I'm liking it a lot :-)
We previously had these components:
Not only is it modular, the system is fully composable, allowing the admin to build each layer upon each layer to their own liking. The layers are not tightly-coupled, and it's entirely possible to replace any or all of the layers:
When people complain about sysvinit being old and outdated, these claims are usually considering the sysvinit+sysv-rc+initscript triad as a single entity. sysvinit is old, but it's a tool with just two purposes: running specified programs and runlevel switching. You can build anything you want on top of that. It does exactly what it was designed to do, and *only* what it was designed to do. It's not broken, and never was. If you want more functionality, you build that on top of it.
Some parts of the old system were crusty, for example dynamic networking configuration. But the vast majority worked pretty well, and pretty efficiently. And it would have been perfectly possible to fix those issues, with vastly less effort and disruption than throwing it all away and breaking much backward compatibility in the name of inter-distribution uniformity (and consequent stagnation).
Note that while common distributions came with their default, it was absolutely possible to run with all sorts of different combinations of components; Debian supported several. file-rc was a supported alternative to sysv-rc, and daemontools and other alternatives were also available. It's this very flexibility which allowed systemd to be swapped in relatively easily. But consider that once systemd was adopted, the vast majority of this flexibility was lost. The low-level init, the rc runner and the initscripts are all in one place, and it's no longer possible to swap one part for another or tweak one little bit. It's all or nothing, and that will effectively entrench it. As an ex-Debian sysvinit/sysv-rc/initscripts maintainer, I wasn't dictating that you use them all together. You want to use openrc, or daemontools or s6? Go for it, you don't need me to approve it, you do what you like. Want to change the initscripts around to do something different, be my guest. We took care not to break any custom setups on upgrade as well, e.g. preserving file-rc configuration when adding/removing/upgrading packages, as well as helper script API stability. Contrast that with the top-down dictatorial approach which comes from the systemd people: you'll use the system the way we tell you to, and no, we don't approve of you doing anything non-standard unless we like it (and good ideas only come from us, so forget it). And if you do change stuff and it breaks, that's 100% your fault since we don't care to consider this. That's the real difference, the attitude and thought behind the design, and how that affects your freedom to use your system as you see fit. And that's one major reason why my servers now run FreeBSD.
With sysvinit, I can easily plug modules at will.
I'm going to assume you didn't RTFM if you're having problems with modules and when they get plugged.
I know it sounds like a really radical idea, but howsabout just specifying the right order?
The right order is stable during one scenario only, a controlled boot. It was a good idea in the 70s, but it's a truly horrible way to run a system of interdependent daemons, especially when boot time is such a rare state to be in for a server.
I was testing a system with BTRFS doing mirroring. As part of the test, I dropped one of the disks to simulate a failure.
So you were using an experimental filesystem and complaining that your system didn't boot in degraded mode? It's quite telling that when you search online for the issue it is noted that this ONLY happens with BTRFS and not ZFS or mdadm. BTRFS's design is to not mount in degraded mode by default, and the fact that when you force the mount it doesn't act like every other file system, or indeed itself in a healthy state (which leads to udev not getting the device UUID) is a BTRFS bug / "feature". Maybe don't use an experimental filesystem if you're worried about your system.
Literally anything systemd can do could already be done using simple helpers called by sysV. You even provided an example yourself.
So literally anything systemd can do could already be done using sysV-init, a whole host of other programs, a shitload of scripts re-written and customised for each and every daemon .... except for the myriad of things you can't do with sysV-init. The fact that you think it can just shows how little you know of the topic. My guess is you don't even realise that systemd isn't the first attempt to work around the many shortcomings of sysv-init and the things it *can't* do, it's not the 2nd, 3rd, 4th or 5th either. It's somewhere in the double digits, and based around a combination of the way 2 different UNIX systems manage processes.
Those last two words are key, since it's something that sysV-init can't do.
I'm going to assume you didn't RTFM if you're having problems with modules and when they get plugged.
Not KERNEL modules, init system modules.
The right order is stable during one scenario only, a controlled boot.
You prefer an out of control boot? Not sure what you mean there.
BTRFS hasn't been listed as experimental for some time now. It is considered usable in production now. The problem wasn't BTRFS, the problem was systemd trying to be clever when it really isn't. It would refuse to even attempt to mount btrfs until all disks showed present. It offered no timeout. I did have the degraded option set, such that when systemd inevitably dropped me to a shell, I could just type mount /home and POOF, there it was.
systemd never did solve the problem for MD RAID devices, it's just that the initrd now assembles the RAID before systemd gets a chance to screw it up.
The Unix philosophy has always been small tools that do one job well combined to do nearly anything. That's how it's SUPPOSED to be.
Systemd COULD have been designed to play well with others. It's whole process management thing could have been called by /sbin/init to take care of whatever was configured under it and leave everything else to the rc scripts (or whatever other modules might be called by init). Instead, it's a hairball. It reminds me of Robin Williams joke about God getting stoned and creating the Platypus just to fuck with us.
Since I actually wrote an init system for bproc nodes, I probably know a hell of a lot more about it than you do.
You know what it usually means when dozens of "new and improved" replacements fail to replace the original? It means the original is actually a lot better than you think it is.
That's funny given that it was primarily designed with servers in mind.
Not sure that's true. It was inspired by launchd from Apple (specifically this video). Personally I think launchd is cleaner, but that's partly because Apple has full control of the ecosystem.
"First they came for the slanderers and i said nothing."
You prefer an out of control boot? Not sure what you mean there.
I can tell. There's one scenario where a specific order applies, boot time. It's also a time you don't normally find yourself. So having an entire process manager with hard coded order is asinine and is the number 1 "feature" that every single other init system has removed.
BTRFS hasn't been listed as experimental for some time now. It is considered usable in production
By who? Certainly not the project team who say that only the physical disk format is stable, and the rest of the project is still under heavy development including the caveat that bugs may creep in.
The problem wasn't BTRFS, the problem was systemd trying to be clever when it really isn't.
Nope the problem was udev (nothing to do with systemd itself) and the fact that even when the options are passed in fstab to mount degraded that it doesn't report back to udev that a valid UUID is present. Systemd then tries to boot a system with a filesystem that has a valid UUID and does what every good system should do when fundamental hardware is missing in the boot process: fails to console.
systemd never did solve the problem for MD RAID devices, it's just that the initrd now assembles the RAID before systemd gets a chance to screw it up.
Initrd? You mean the thing that is supposed to assemble rootfs devices before a system tries to boot from them? Colour me surprised. Amazed. Gobsmacked! What a revelation!
The Unix philosophy
Don't care.
Since I actually wrote an init system for bproc nodes, I probably know a hell of a lot more about it than you do.
Now there's an appeal to authority no one gives a shit about. Sorry but you're still just a name on the internet.
You know what it usually means when dozens of "new and improved" replacements fail to replace the original? It means the original is actually a lot better than you think it is.
Actually it means that no one was happy with the original. The only problem was that up until this point people couldn't agree on what the replacement was supposed to look like. Hence we ended up with 5 different distros with 5 different init systems all under parallel development all of them got traction in their own way. Fortunately one project came along that actually offered the benefits of most of them and appeased them enough to all focus the efforts on a single replacement.