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...")

Comments

Drip

[lucm]

worked with my tuner devices (cx88 PCI cards and an xc5000 USB device) together with MythTV

You're like a wet dream for QA people

Re:One can hope

[lucm]

Your post however contributes nothing.

My post doesn't try to take Linux over one feature at a time by replacing things that were not broken with more and more legs of the same octopus. I'm happy if systemd made your own life easier but that doesn't mean everyone should bend over and take it quietly.

Re:One can hope

[lucm]

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.

Re:One can hope

[sjames]

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.

Re:One can hope

[Motherfucking Shit]

More importantly to me, I've used the old pile of shit for 20 years. I know how it works, I know its quirks and shortcomings, and I'm comfortable with all of that.

I have no particular aversion to trying new things. I ran ntpd for years, now I use chrony. I ran exim for years, now I use postfix. I ran apache for years, now I use both apache and nginx. I ran cvs for years, then svn for years, and am now aboard the git train. I was able to gradually step through all of those changes and take time to learn them properly. And when something went wrong along the way, the problem was isolated and I could troubleshoot it in isolation.

systemd on the other hand wants to implant itself underneath every aspect of the OS like a kludgey layer of Elmer's paste, where even such basic functionality as DNS resolution wants to worm its way through an unnecessary and complex intermediary service. Not to mention that when systemd goes tits up, it has a tendency to take the entire machine with it.

No thanks.

Re:One can hope

[Anonymous Coward]

Do tell one reason how Systemd has actually helped something?

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.

Re:One can hope

[nadaou]

What was a better way, the UNIX way, was having multiple interchangeable options for any particular cog in the machine. No reliance on a sole supplier. In Debian even HURD or BSD could be swapped out for the Linux kernel in a semi-official, if experimental, way.

Avoiding a mono-culture has huge industry implications for surviving horrific infrastructure bugs, engaging competition and A/B tests, and filling niches with the best tool for the day's particular job. If systemd was truly optional in official Debian there would be no crisis, no endless talking past each other hate filled forum threads. Instead there was an unfortunate slim-vote by a Debian technical committee and major community damage to the project with a large number of DDs and contributors losing passion for the greater project. Which is the real horror and tragedy of the thing.

Re:One can hope

[Anonymous Coward]

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.

Re:One can hope

[johannesg]

"The UNIX way" was to have multiple, not quite compatible, complete operating systems from multiple vendors such as HPUX, Solaris, IRIX, etc. Porting your software between those was a considerable effort, and in fact a whole standardisation body (posix) has sprung up around efforts to make those systems at least nominally compatible. And in later years, the Linux way was quite similar, with LSB attempting to keep distributions at least nominally compatible with each other, but the effort of porting an application from one distribution to another still going by the name of "porting".

I have no idea in which dimension your UNIX way happened, but it wasn't this one.

Re:One can hope

[sjames]

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.

Re:One can hope

[Anonymous Coward]

Christ Almighty. Overreact much? If you don't like it, either switch to a distro that doesn't use it or move to BSD.

I was expecting systemd to be a steaming turd based on all the hysterical screaming and tears from parts of the Linux community. The reality is I've been using it at home just fine for a while now, and we have production servers at work using it without a hitch.

Thank you Debian maintainers

[cwveg]

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

Re:Thank you Debian maintainers

[Anonymous Coward]

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"

Re:One can hope

[nadaou]

You are twisting the meaning to fit a particular straw man you want to knock down. I obviously wasn't talking about Berkley vs. Bell Labs UNIX as being interchangeable cogs and was talking about the philosophy governing the interaction of the various sub and support systems within a modern Linux deployment.

Re:One can hope

[rl117]

Yes, we did have that modularity.

We previously had these components:

• sysvinit (low-level process spawning and runlevel change triggering; all done from /etc/inittab)
• sysv-rc (intermediate-level script to effect runlevel changes by batch invoking rc.d scripts)
• initscripts (high-level rc.d scripts to do the actual work of bringing the system up or down, with helper scripts to unify logic shared between multiple scripts)
• package-specific scripts whch use the initscripts helpers and to some package-specific action
• insserv and startpar, to use LSB script headers to compute a global dependency graph with make-like syntax and allow sysv-rc to start the scripts up in parallel with proper dependency constraints

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:

• You can swap out sysvinit but retain sysv-rc and all higher-level parts; example: s6
• You can swap out sysv-rc; example: file-rc which gives a bsd-style startup with a single file to configure what starts, or daemontools which runs directly from inittab and does process supervision
• You can replace the initscripts with whatever you like, but retain sysvinit; example: openrc, which replaces sysv-rc and uses its own scripts

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.

Re:One can hope

[rl117]

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

Re:One can hope

[K. S. Kyosuke]

BSD: Because SystemD? ;)

Re:One can hope

[sjames]

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.

Re:One can hope

[phantomfive]

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.

How To disable SystemD on Debian 8

[psergiu]

http://without-systemd.org/wik...
http://jrigg.co.uk/linuxaudio/...
I did it, and it works perfectly if you don't use any Gnome & co. stuff.