Oct 15, 2026, 7:09 PM@nina_kali_nina Imagine we forked from last summer or whenever right before the first pro-slop policy was (ie the documentation policies that predated the code policies).
Aside from the problem of getting a team together, what do you think would be the limitations on developing from that point?
(To be clear this is not my preferred solution. I'm just trying to understand what the options are.)
@mcc well, the first problem is that it'd have to be a hard fork; it won't be possible to import fixes from upstream because they are all going to be tainted, due to the new policies. The second problem is that Linux doesn't have stable ABI, and its API is also fairly volatile, which means in the near future the binaries for Linux and the binaries for neverslop-Linux will not be compatible (which means things like flatpak, appimage and docker will be very confusing or difficult to run). And then it'd be difficult to get any support from Intel, AMD and Nvidia for their hardware, because they and the main vendors (Ubuntu and Redhat) and the main users (Google, Amazon, Microsoft, Meta) will not care about the neverslop-Linux. And then vulnerabilities found and fixed in upstream will have to be fixed in neverslop-Linux if they're old enough, but Linux now uses a horrendous practice of calling every bug a CVE, with 1000 CVEs a month, making it impossible to triage and fix.
@mcc in terms of supporting security long term: it was done by a project called Linux-CIP. But the Linux-CIP style project is only possible if there's sensible CVE reporting in upstream and the possibility to port the patches. The new policies, as I said, mean that everything is potentially and maybe even likely to be tainted
@nina_kali_nina
Are you sure ABI/API are unstable? I have compiled a niche script interpreter on Linux 2.?.? and same binary did run on my recent Linux installation, which was 5.? or 6.? then. I remember that I had to backport the program to the old libc, but it was doable.
I suppose the „glue“ is libc which has to fit the kernel.
@mcc
@hierkiosk @mcc I wouldn't be surprised if libc was doing a lot of heavy lifting there. I also wouldn't be surprised that for relatively simple applications there wouldn't be any problems with running a program that was statically compiled for 2.6.x on 5.x or 6.x kernels. However, I doubt it'll be easy to run a program compiled and linked for 5.x kernel on an older kernel. Stuff like that is a problem for both emulation layers (NetBSD compat_linux and FreeBSD Linuxulator) and hard forks (that will either have to stay somewhat frozen in time or will have to catch up to the upstream). E.g. let's say Valve ships a new Steam version that requires kernel 7.2 - this will happen almost inevitably; how much work will be needed to figure out what parts of the Linux 7.2 need to be re-implemented in the fork and in the emulators?
@nina_kali_nina @hierkiosk @mcc I would rather wager that the program had run without changes if it hadn't depended on glibc in the first place.
Compared to whatever the hell glibc does, kernel ABI is rock-solid.
@nina_kali_nina @mcc Also, Linux-CIP works on a heavily restricted set of industrial-grade hardware; if you're not a sponsor, your machine very likely isn't supported.
For instance, Linux 4.4 on CIP only works on two architectures (can't remember which) and only on specific hardware.
It's meant for big actors (like the railway or medical industries) who absolutely cannot upgrade the kernel beyond mandatory security patches because of certifications/safety constraints.
Oct 15, 2026, 10:45 PM@nina_kali_nina @mcc
Not the "stable ABI" thing again.
I remember when Slashdot Linux posts alternated between "Linux doesn't have a stable ABI" and "Linus yells at someone for making a tiny change to a 30 year old ABI that is still used by one application from 1999".
Which is it?
@leeloo @mcc it can be both :)
Also, I realised there's much better argument here: https://drewdevault.com/blog/AI-in-Linux/
Oct 15, 2026, 10:47 PM@leeloo @nina_kali_nina Is it possible that different people at different times have wanted different things for different reasons?
Anyway, from my perspective a stable kernel ABI is pointless as long as LKML/Linus Torvalds remain trustworthy entities and extremely necessary if I'm trying to make an alternate OS which is capable of consuming Linux kernel modules. Moreover if I want forward compatibility, then de jure stability can actually be more important than de facto
@nina_kali_nina @mcc I'm assuming it's not possible to run flatpak/appimage/docker on BSD for the same reason?
@aburka @mcc well, there is Linux Compat for NetBSD that is somewhat compatible with Linux 4.x and can run a bunch of software, and there's Linuxulator for FreeBSD that tries to catch up with the Linux kernel, both are successful but only to an extent.
Speaking of docker, there's podman for NetBSD that is backed by qemu, running real Linux kernel with hardware virtualization. I didn't have much success with running it, but if I figure out how to make it work, it should be possible to run a lot of stuff this way.
@nina_kali_nina @aburka @mcc It’s been a long time since I last used BSD (FreeBSD). Docker didn’t exist back then (chroot as a fs-level isolation on Linux and FreeBSD jails) The advantage of Docker (among others) is full native virtualization; If i understand correctly Podman is the same. Problem here is that relies on BSD kernel, so Linux is the overheat. However, it would be possible to have applications with full native virtualization, such as AppImage or Flatpak, if they run on a BSD kernel
@foo_bar_baz @nina_kali_nina @mcc yeah the process/network/filesystem isolation without virtualization is the magic