"Commit 901e325f772f "ARM: bugs: add support for per-processor bug
checking" added a new member to struct processor. This structure
is always instantiated in built-in code and the new member is only
used in built-in code. Therefore we can safely add the new member
at the end instead.
Move it to the end and hide it from genksyms. Also hide it when
building modules, to make sure they really don't use it."
This is actually 100% true. Stable is the culmination of the Debian Release Engineering / Testing Freeze process.
In Unstable, packages are promoted from Experimental as I understand it which is a comparatively easy threshold to get past. In Testing, packages are only promoted from Unstable if they 1) don't have any bugs open against them, and 2) there is not a freeze on. 50% of the time (1 year) there is a freeze on.
In Freeze, only bug fixes are promoted to Testing. New features have to take a number.
When the freeze is over, Testing is cut and becomes the new Stable. I might have described some part of this subtly wrong, but this is the Debian release management process in a nutshell. To read more: https://release.debian.org/
In short, "Stable" should be read like stable compound, not like we usually interpret it to mean "doesn't crash" in IT.
It's a side effect of not changing often, that it probably doesn't crash too much. The crashing bugs wouldn't have made it into testing, or through the testing/freeze process. Hopefully, at least.
I personally prefer to run Unstable on my developer machines, because it gets fixes more frequently:
> Security updates are made by the maintainer; they may not be effective on all architectures, and may be delayed. Packages uploaded may not meet release standards, but any breakage is expected to be fixed promptly. Updates are made by maintainers.
>It's a side effect of not changing often, that it probably doesn't crash too much.
I don't think that's true, it's likely that the actual causes of crashes are better known and documented, I don't think there is a particular way you can make a software release be less likely compared to other releases of the same software.
Anyway I phrased that all wrong. I meant to say, that if it doesn't crash as much for you, you can expect that to stay the same throughout the stable release. The changes are universally where the new bugs are coming from. So it follows that you should expect less new bugs, because there are so few changes allowed in the stable distro.
Security fixes and Updates are delivered separately. I don't know this process inside and out but I've been exposed to it for 20 years, here are some more good current links:
> Even stable is updated once in a while. Those updates are called "Point Releases". They usually incorporate the security fixes released until the time of the update and fixes for grave bugs in the current release.
Misleading label to say, e.g. "The horse is unstable." when intending to explain how the horse is outside the stable. (re: Stable == Compound in Debian-speak.)
Hmm, I meant stable compound in the sense of a noble gas, not highly volatile or reactive. Or say, lower energy states that are not as likely to emit a photon.
The horse is "unstable'd", maybe another way of saying it. Unstable is developed outside of the stable release engineering process. That does not mean it's without safeguards. The unstable releases tend to be very stable. There are extra safeguards, and time-based safety measures that protect users of the Stable distribution. They say that Unstable might take longer to get fixes, and while that's likely true in the case of critical fixes with special attention, it's almost never true in practice other than that. Unstable receives fixes much more quickly, in general.
There actually used to be a "debian-volatile" project, too, for things like virus definitions that should be used in a stable distribution, and also didn't make sense to govern through the stable release process, but it is defunct now.
> "Because when it breaks, it is broken in a stable way."
Hubris.
How can you declare something "stable" if you don't perpetually run tests to verify it is indeed "stable"?
And to state the obvious: certain bugs will lead to instability, non-deterministic, and undefined behavior - that's the very nature of things breaking down.
We do at https://fosdem.org on our custom made video gear. That's 56 boxes in a crucial spot in our operation. We went out of our way to make sure we had plain vanilla mainline Debian stable packaged linux running on the Allwinner A20 based boards that power them, instead of some binary arm kernel with all kinds of issues.
I'm sure it's small, but at least a few of us are here. Also worth noting is that (most) Raspberry Pi (an ARM SBC) users are indirectly Debian users too. (and I'm a Pi user as well)
There's just about zero chance that this bug would make it into raspbian stable, though, since they are always at least several months behind debian-stable on AMD64.
I have 10 Raspberry Pi's with Debian Stretch and Jessie - the Raspbian variant. I updated a "sacrificial" Pi and rebooted without error.. this time!
Package: linux-libc-dev
Version: 4.9.82-1+deb9u3+rpi1
Priority: optional
Section: devel
Source: linux-4.9
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Installed-Size: 4,466 kB
Provides: linux-kernel-headers
Homepage: https://www.kernel.org/
Download-Size: 1,300 kB
APT-Manual-Installed: no
APT-Sources: http://raspbian.raspberrypi.org/raspbian stretch/main
armhf Packages Description: Linux support headers for userspace
development This package provides userspaces headers from the Linux
kernel. These headers are used by the installed headers for GNU libc
and other system libraries.
As others have mentioned, Raspbian kernel updates are delayed behind the Debian ones. The linked bug report states it was introduced between 4.9.135-1 and 4.9.144-1 (of linux-image-4.9.0).
I use 2 Olimex A20 Micro with Debian stable as personal servers (Web, Email, Backup).
One of them had already installed the toxic update via unattended-upgrades.
Fortunately I did not configure automatic reboot.
So I had the chance to read about the issue here on Hacker News and reinstall the old version:
I'm glad I can. It's a known, trusted distribution I've been using since 2001 on my main PC. It runs my personal web server since 2013 on a Cuibeboard and it works well. I've got a stable system which I'm familiar with, plus automatic updates, no binary blobs, vanilla kernel and all.
I can't think of a better solution if the SBC is supported. What would you recommend as an alternative?
I do, at least for some personal projects. They're more than capable enough for many tasks, and cheap enough to be willing to just grab another if you have a quick task.
love this note on it:
"Sure, maybe. I've suggested kernelci as a useful thing to help here, but we really need to be testing kernels complete with all the Debian patches to..."
so does that mean they test the kernel but not their own patches to it? seems silly :D
The problem patch is in http://deb.debian.org/debian/pool/main/l/linux/linux_4.9.144... (I think)
"Commit 901e325f772f "ARM: bugs: add support for per-processor bug checking" added a new member to struct processor. This structure is always instantiated in built-in code and the new member is only used in built-in code. Therefore we can safely add the new member at the end instead.
Move it to the end and hide it from genksyms. Also hide it when building modules, to make sure they really don't use it."