The "Devuan" Debian fork

Posted Dec 1, 2014 21:08 UTC (Mon) by dlang (guest, #313)
In reply to: The "Devuan" Debian fork by raven667
Parent article: The "Devuan" Debian fork

the kernel does have to deal with this sort of thing when dealing with hardware. Just because Intel released a new chip with a neat feature doesn't mean that they don't have to keep supporting old chips that lack that feature.

As a result, the kernel gets written to take advantage of the new feature, but have a fallback if that feature doesn't exist (that fallback may be to emulate the feature, or just report an error if someone tries to use that feature, but it isn't to refuse to boot without that feature)

The problem is that too many userspace developers only look at the latest. The comments about systemd supporting kernels for the last two years and consider themselves enlightened to be so good about supporting older kernels is a good example of this. While the systemd folks are congratulating themselves for being so good, other people are looking at this and saying that this is way too short a timeframe, that two years is barely enough to get a kernel from kernel.org into the hands of users in many environments.

Userspace developers who have to deal with large installed bases of third party stuff tend to be much better about this. So Samba, *syslog, browsers, webservers, e-mail software, etc all tend to look for the latest to take advantage of it, but have fallbacks to keep working in the absence of these features.

It's mainly in the Desktop Environment space that the developers seem so willing to expect that everyone will upgrade everything at once and nobody has any business running anything older.

The "Devuan" Debian fork

Posted Dec 1, 2014 22:17 UTC (Mon) by raven667 (subscriber, #5198) [Link] (2 responses)

We aren't really talking about issues which are different in kind, like the kernel supporting hardware, we were talking about the userspace plumbing that is kind of part of the kernel family, like udev or iptables or iproute2 or conntrack (I work with networking so I have more network examples) which may have a limited range of kernels a particular build of the tool supports because of supporting new APIs as they are added to the kernel.

I think that to really have a good discussion about this topic one would need to always refer to the actual list of kernel APIs which are causing the support break what specifically doesn't work across those kernel API versions and why, we are beyond the point where we can only discuss generalities as this is working code which has been deployed for years.

v217 2014-08 * Userspace firmware loading support has been removed and
the minimum supported kernel version is thus bumped to 3.7.

http://cgit.freedesktop.org/systemd/systemd/tree/README

The previous changes were updating to support writing to cgroup.procs which bumped the requirement to Linux 3.0 in v206 2013-07 and the bump to 2.6.39 from 2.6.30 from early in the development in 2011-08

The "Devuan" Debian fork

Posted Dec 1, 2014 22:23 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

this is more than just the minimum kernel version, it's also things like cgroups (which are useful if you need that capability, but wasted overhead if you don't). But it's mostly about the attitude of the developers who think that testing with a two year old kernel means that they are maintaining great backwards compatibility and aren't willing to try to do better (and from other responses, would not be willing to accept patches that did better because of the 'ongoing maintenance burden' that such patches would cause)

The "Devuan" Debian fork

Posted Dec 2, 2014 1:06 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Systemd only needs cgroups themselves. If you don't enable any cgroups controllers (and it's a supported feature in systemd) then the overhead is negligible - just a couple of in-kernel callbacks on process completion and startup.