Slashdot Mirror
Security Updates Released for Debian 8 and 7 (debian.org)
An anonymous reader writes: The Debian Project just released Debian 8.5, which adds 65 security updates to the stable release. They're also releasing the final update to Debian 7 (codenamed 'wheezy'), which includes "all other security updates released during the lifetime of 'wheezy' that have not previously been part of a point release."
They're emphasizing that each of the new updates "does not constitute a new version...but only updates some of the packages included. There is no need to throw away old...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."
They're emphasizing that each of the new updates "does not constitute a new version...but only updates some of the packages included. There is no need to throw away old...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."
A heart-felt Thank You to all contribuitors of the Debian project - your work is driving many platforms all across the world.
One major bug affecting Debian 8 is how systemd is the default init system,
You might not like it, you might think it's a stupid decision, you might call it a misfeature, but it's not a bug.
and it's not at all easy to switch to another init system (like sysvinit, or OpenRC, or one of the many other alternatives).
Switching to sysvinit is very easy: apt-get install sysvinit-core and reboot. While I personally use systemd and am quite happy with it, I've done this many times to test stuff.
OpenRC was never really supported in Debian (also not previous versions), because nobody did the work to get it there. They can still do so for Stretch btw., if they are really interested. Nobody has stepped up enough yet, though. Only switching to Upstart is non-trivial, but that's mainly the fault of the Upstart maintainers in Debian not caring about it anymore. (And that doesn't surprise me: as much criticism as systemd gets, there are quite a few people that actually like it; and I have yet to meet a single person that likes upstart, save for its developers.)
There have been many serious problems affecting systemd.
Like many other core pieces of software, any problem in there will have serious consequences. I've had far more trouble with the kernel and Xorg than with systemd, and I still use those.
For example, about a week ago we learned how a systemd change broke critical programs like screen and tmux.
Which will never affect Debian stable, because Debian stable will keep the systemd version with which it was first released, with potential bugfixes backported - like any other package in Debian stable.
That said, the example you chose is not really clear-cut: I really want there to be a mechanism to clean up after user sessions (I've had enough software misbehave in stupid ways and leaving processes running around that caused trouble), so the change in systemd there is not a bad thing in and by itself. The problem here is that you should be able to explicitly leave some processes running in the background. But any solution to that (regardless of whether it has to do with systemd or not) would mean that you'd need to modify the legitimate use cases to use some hook to say "yeah, I need to stay around", whereas all the other programs should then be killed. (Alternatively, you can stick your head in the sand and pretend that left-over processes aren't a legitimate problem, which is what I've seen a lot of people do, because they reflexively react to the name "systemd".) Btw. just because systemd upstream changed a default setting, doesn't mean distributions have to follow. (And I'm not saying that systemd upstream is necessarily right here; it might have been better to first get support for this into screen, tmux etc. and then switch the default.) The current systemd package in Debian unstable doesn't change the default, btw.
Clearly a large segment of the Debian community is troubled enough by systemd and its implications, given how the Devuan distribution was forked from Debian.
To me that looks more like a small, but very vocal, minority. I had the impression that most Debian users just don't care that much about the init system. But perceptions can vary, obviously.
If other Linux distros, like Gentoo, can easily support multiple non-systemd init systems, then why doesn't Debian?
You're shifting the goal post: first you complain that systemd is the default, then you complain that Debian doesn't support alternatives? By virtue of definition something that is the defau
The saddest thing about systemd is not systemd itself, but rather how it highlights the big problems of the Linux "community". People, init systems were a solved problem more than a decade ago. Can we spend all this wasted time and effort on something that actually does need major improvement and that a significant amount of users actually care about instead? Pretty please?
People, init systems were a solved problem more than a decade ago.
Really? Best I can tell people have been spending the best part of several decades attempting to fix systemd, from the numerous programs to combat the fact that it was missing functionality, to the many groundup re-writes. It is only 2015 when people finally standardised on one of the very VERY many replacements that have been attempted.
People who say the problem was "solved" long ago, don't understand the problem, don't understand the context of the requirement, or just plain want to stick their fingers in their ears and shout la la la.
systemvinit is far from perfect, especially from the point of view of many maintainers, so it can equally be called a bug plan and simple.
And I've had numerous cases in the past where due to the fact that the bunch of scripts that come with sysvinit don't have any kind of limits behind them (especially time limits), a system (headless, to make it worse) would get stuck during shutdown and never properly reboot.
At least from my experience, booting has been much more consistently reliable with systemd than without. I used to dread having to reboot headless servers before systemd, just because I was never quite sure whether they'd come up again. (And I had numerous cases where they didn't, because of some weird race condition that would be triggered only every now and then in the init scripts.) And if I think about it, I can't remember the last time when I worried that whether a given would boot again.
I get that this isn't the experience everyone has had; but at least from my perspective, if there are problems with systemd, they are far easier to debug (if you know how by reading the appropriate docs) and are far more consistent - so that if something doesn't boot, it will reliably not boot until you fix it, instead of having something that sometimes might boot and sometimes not, and other times get stuck half-way in between.
Is systemd perfect? No. Have there been cases where bugs in systemd or at least the integration of systemd with the rest of the OS have caused serious issues? Sure. Does systemd have bugs? Sure. (As does any piece of software except for the most trivial programs.) But that doesn't mean it makes sense to call the decision to make systemd the default init system a bug. (Which is what I responded to.)
I could agree with this, but my problem is upstream. The systemd folks keep breaking or changing things that were once standard, documented and could be counted on. Most recent on slashdot was breaking the backgrounding of processes. Given the creation of an 'su' function I'm waiting for su, sudo and the like to be declared broken and for the accompanying posix calls to be superseded by function in libsystemd.
My product had our (once) portable init script broken in RHEL7.2 by a systemd change that now declares that the init.d script cannot be a symlink to the product installation area. This worked in RHEL 7.1 with systemd and with prior releases and other (pre-systemd) distributions. Yet another gentle nudge to doing things the systemd way, or else.
If I trusted upstream to maintain a interface that could be made portable I'd be less resistive to systemd. It provides some good features, even if the architecture is awful. A sane, portable re-implementation for be made once the current architecture shows its problems. But a re-implementation won't be possible with an upstream that breaks compatibility without a second thought.
The fact that the community has accepted this so willingly makes me dread the day that Linus gives up the reigns of the kernel. It's not unlikely that we'll wind up with the kernel being led by a twit, a push over or a committee.