The first half of the 7.0 merge window

By Daroc Alden
February 13, 2026

The merge window for Linux 7.0 has opened, and with it comes a number of interesting improvements and enhancements. At the time of writing, there have been 7,695 non-merge commits accepted. The 7.0 release is not special, according to the kernel's versioning scheme — just the release that comes after 6.19. Humans love symbolism and round numbers, though, so it may feel like something of a milestone.

The most important changes included in this release were:

Architecture-specific

The kernel now supports atomic 64-byte loads and stores on Arm CPUs that provide the feature.

Core kernel

Rust support is officially no longer experimental. Rust is here to stay, although individual subsystem maintainers are still free to keep it out of their subsystems.
BPF can be used to filter io_uring operations; see this article for details. The change adds a way to potentially enforce sandboxing on io_uring operations, given that seccomp() can't block individual io_uring operations — and that therefore administrators with seccomp()-based sandboxes typically disable io_uring altogether.
Users have the option of using non-circular io_uring queues for better cache performance in applications where requests are usually completed before the submission system call returns. In a circular queue, the slots where new messages are stored continue advancing in memory until they wrap around. This causes churn in the cache. A non-circular queue will reset the queue's pointers whenever it is empty, hopefully keeping the start of the queue's memory in cache.
Looking up types in BPF type format (BTF) debugging information now uses a binary search, which should make loading BPF programs more efficient.
As reported in January, BPF kfuncs can accept implicit arguments.
The scheduler has changed to only support two preemption modes on most architectures: PREEMPT_LAZY and PREEMPT_FULL. Only architectures that do not support preemption at all can still configure PREEMPT_NONE, and only architectures that don't support lazy preemption can configure PREEMPT_VOLUNTARY. See this article and its sequel for details on the different modes.
The time-slice extension proposal for restartable sequences has been merged. This change allows processes that are almost done with a lock at the end of their time slice to request a short grace period to finish their work and release it.
Administrators of systems that need to panic when workqueues stall can set a new build-time configuration option to force that behavior.
The deprecated linuxrc-based initial ramdisk (initrd) code has been removed. The other initrd code is scheduled to follow in 2027, which will leave initramfs (which uses a filesystem in RAM instead of a disk image in RAM) the only supported way to boot the kernel.

Filesystems and block I/O

Non-blocking updates to file modification times now actually work. Previously, they would return -EAGAIN unconditionally; now, that only happens when the filesystem would actually block. This makes non-blocking direct writes work on filesystems with fine-grained timestamps.
Filesystems no longer implement leases by default, and must instead opt-in. This resolves a number of problems caused by leases being available on filesystems that were never designed to handle them. Most popular filesystems do implement leases, but 9p and cephfs don't, for example.
Historically, filesystems have reported errors in mutually incompatible ways. A new set of helper functions makes it easier for filesystems to report errors to fsnotify in a consistent way.
A new filesystem — "nullfs" — has been added for use as the root filesystem of Linux systems. It's immutable and completely empty, containing no data whatsoever. This simplifies the boot process, because user space can mount other filesystems on top of it and then use the pivot_root() system call to make those the new root, rather than having to clean up the contents of initramfs and re-use the root filesystem.
In support of Checkpoint/Restore in Userspace (CRIU), the statmount() system call can now report information about the mount associated with a file descriptor.
The EROFS maintainers have enabled LZMA compression by default, and marked DEFLATE and Zstandard compression as no longer experimental. The filesystem also shares page-cache entries for identical files on separate EROFS filesystems.
Filesystems that need to calculate checksums or parity over data can use bounce buffers to store a copy of the data during direct I/O. See this article for details.
Btrfs now supports direct I/O when the block size exceeds the system's page size.
XFS's autonomous self-healing support has been merged; see this article for details.

Hardware support

GPIO and pin control: ROHM bd72720 GPIO devices.
Graphics: CSW MNE007QB3-1 panels, AUO B140HAN06.4 panels, AUO B140QAX01.H EDP panels, Sitronix ST7920 panels, Samsung LTL106HL02 panels, LG H546WF1-ED01 panels, HannStar HSD156J panels, BOE NV130WUM-T08 panels, Innolux G150XGE-L05 panels, Anbernic RG-DS panels, RK3368 HDMI controllers, RK3506 chips, Genio 510/700/1200-EVK HDMI outputs, and Radxa NIO-12L HDMI outputs.
Hardware monitoring: MT8196 and MT7987 Mediatek heat sensors, RZ/T2H and RZ/N2H Renesas heat sensors, HiTRON HAC300S power supplies, Monolithic MP5926 hot-swap controllers, STEF48H28 hot-swap controllers, Pro WS TRX50-SAGE WIFI A and ROG MAXIMUS X HERO chips, Dell OptiPlex 7080 computers, F81968 I/O chips, ASUS Pro WS WRX90E-SAGE SE chips, SHT85 sensors, P3T1035 temperature sensors, and P3T2030 temperature sensors.
Media: TI video input ports, os05b10, s5k3m5, and s5kjn1 camera sensors, and Synopsys CSI-2 receivers.
Miscellaneous: Renesas RZ/V2N SoCs and Rock Band 4 PS4 and PS5 guitars, ATCSPI200 SPI devices, AXIADO AX300 SPI devices, NXP XPI SPI devices, and Renesas RZ/N1 SPI devices.
Networking: Huawei hinic3 PF ethernet cards, Motorcomm YT6801 PCIe ethernet controllers, MaxLinear MxL862xx switches, RealTek RTL8127ATF 10G Fiber SFP NICs, RZ/G3L GBETH SoC NICs and QCC2072 WiFi chipsets.
Power: Maxim MAX776750 PMICs, Realtek RT8902 level shifters, Samsung S2MPG11 PMICs, and Texas Instruments TPS65185 PMICs.
Sound: NXP i.MX952 application processor, Realtek RT1320 and RT5575 audio codecs, and Sophogo CV1800B chips.

Miscellaneous

The vDSO now provides a 64-bit version of clock_getres().
With this version, the kernel supports SPI devices with multiple data lanes that transmit in parallel.

Security-related

SELinux can now control BPF token access. BPF tokens allow unprivileged processes to perform certain privileged BPF operations; see this article for details.
The kernel supports ML-DSA post-quantum signatures, and can use them to authenticate kernel modules.
The option to sign kernel modules with schemes involving SHA-1 hashes has been removed, although the kernel remains able to load modules signed this way, for now.
NETFILTER_PKT audit records now contain the source and destination port numbers for inspection.

Virtualization and containers

Container runtimes can use the new OPEN_TREE_NAMESPACE option to open a new mount namespace without cloning an existing mount namespace. This should make starting a new container faster on systems with many mounts.

Internal kernel changes

A reimplementation of RCU task traces has resulted in the deprecation of the rcu_read_lock_trace() and rcu_read_unlock_trace() functions.
The kernel has added an official policy on tool-generated content. To encourage the tools themselves to follow it, there is also documentation aimed at LLMs.
The kmalloc_*() family of functions (which allocate based on the required size) are poised to be replaced with kmalloc_obj_*() functions (which allocate based on the provided type) during this release cycle. The new functions will both make object-length-calculation errors less common and provide for possible type-based hardening of the kernel.
A number of Rust changes were made to use the recently-vendored syn crate to implement macros — changes which, ironically, actually reduced the amount of Rust code in the kernel by cleaning up the previous ad-hoc macro definitions.
Support for Sparse context analysis (which helps find locking bugs, although not well) was removed in favor of compiler-based context analysis in Clang 22. The compiler-based analysis should catch more locking bugs with fewer false positives; see this article for details.
The kernel's build configuration has new syntactic sugar: "depends on X if Y", standing in for "depends on X || !Y".
Sheaf caches are all cached per-CPU, a change that has been in the works for nearly a year. This change reduces the amount of cross-CPU contention caused by allocating new pages from the kernel's slab allocator.
s390 machines now have the same kinds of poison pointers (which have hex value 0xdead000000000000 on s390) as other architectures, which allow the kernel to track DMA mappings from the networking page pool, among other things.
The DRM subsystem has given up on integration with the kernel debugger (kgdb) for now. The move is motivated by the difficulty of supporting kgdb on modern hardware.
The new __counted_by_ptr() annotation marks members of a structure that specify the length of an object behind a pointer, like __counted_by() does for arrays in a structure.

The merge window is not quite half over, so as usual there will be a follow-up article once it closes, on February 22 if all goes as planned. For now, though, the 7.0 release is following the trend of recent Linux releases: packed with incremental improvements, and no huge changes. One thing that didn't make it into this release is support for revocable driver interfaces in C; that patch set may just be pushed off to 7.1, or may face stiffer resistance.

to post comments

Growing major version

Posted Feb 13, 2026 15:55 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (29 responses)

<http://www.kroah.com/log/blog/2025/12/09/linux-kernel-ver...>

> The minor number is incremented by Linus every release that he makes, while the major number is only incremented every few years when the minor number gets too large for people.

I don't think it's very smart to raise the major number to avoid large minor version numbers.

Eventually, we'll have a large major version number, and there's nothing that could fix that.
Once major version reaches 20, what to do?

Growing major version

Posted Feb 13, 2026 16:04 UTC (Fri) by corbet (editor, #1) [Link] (18 responses)

At current rates, the 19.19 kernel release can be expected sometime around 2069 or so. I suspect that Linus doesn't feel the need to plan around that milestone for a little while yet.

Growing major version

Posted Feb 13, 2026 16:07 UTC (Fri) by alx.manpages (subscriber, #145117) [Link]

Yup; that might be a problem. I expect to live past that date. :)

Growing major version

Posted Feb 13, 2026 16:09 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (3 responses)

FWIW, I've decided to settle the man-pages project at major version 6 for as long as I'm the lead maintainer. Once someone else takes care of it, it would grow to 7. That would happen less often. And then, major version is somewhat meaningful.

Growing major version

Posted Feb 17, 2026 23:30 UTC (Tue) by aphedges (subscriber, #171718) [Link] (2 responses)

Given how close the man-pages version is to the kernel version, I assumed the versioning was tied together. Is them both being 6.1x just a coincidence?

Growing major version

Posted Feb 17, 2026 23:36 UTC (Tue) by alx.manpages (subscriber, #145117) [Link] (1 responses)

They have been tied in the past.

When Michael was the lead maintainer, he followed the kernel version closely (weeks or a month).

I have been following it too, more or less, but not so closely. I wasn't happy by the fact that the project also documents glibc, but the versioning and name seems to imply that it only cares about the kernel. I think decoupling the versioning would be positive.

And after all, the version of the manual pages isn't very meaningful. We sometimes document stuff from the next kernel release, before it's even released.

The rule of thumb should be: always take the latest version of the manual pages. We never remove information (with very few exceptions). And being documentation, you don't risk regressions (or they are less dangerous than software regressions).

Growing major version

Posted Feb 17, 2026 23:40 UTC (Tue) by aphedges (subscriber, #171718) [Link]

Good to know. Thanks for clarifying!

Growing major version

Posted Feb 13, 2026 17:14 UTC (Fri) by daroc (editor, #160859) [Link] (12 responses)

Personally, I think that when that happens we should add a new major number in front, go back to 1.0.0.0 ... It wouldn't be any worse than Windows's numbering scheme.

Growing major version

Posted Feb 13, 2026 17:47 UTC (Fri) by mb (subscriber, #50428) [Link] (10 responses)

I don't really get why the numbers are separated by dots, if there's no meaning to the major/minor parts.
Why not stop this nonsense and just count a number up (like systemd)?
The individual digits would grow *slower* than with the current scheme where the two digit minor counts to 20 instead of 99.

Just release the next kernel as 7, then 8, then 9, etc and leave the dotted parts to cases where it actually makes any sense (e.g. stable).

Growing major version

Posted Feb 13, 2026 20:22 UTC (Fri) by rschroev (subscriber, #4164) [Link] (9 responses)

I'm in favor of date-based version numbers. E.g. <year>.<month>.<sequencenumber>. Makes it clear that there's no meaning to the major/minor parts other than when the kernel was released. It has the benefit that you can always immediately see how old a kernel is. The numbers will grow quite big, especially if you use 4 digits for the year, but I don't really see that as a problem when the numbers have meaning.

Growing major version

Posted Feb 13, 2026 21:13 UTC (Fri) by mb (subscriber, #50428) [Link] (8 responses)

The problem with a date based versioning is that you either have to commit to a specific date before the release, or you can't reference to a future version number before the release.
I'm not a fan of that.
I like the extremes: single number increments or semantic versioning. In-between is nonsense.

>The numbers will grow quite big, especially if you use 4 digits for the year, but I don't really see that as a problem when the numbers have meaning.

Yes, that's not a problem.

Growing major version

Posted Feb 13, 2026 22:51 UTC (Fri) by NHO (subscriber, #104320) [Link] (5 responses)

C2y begs to differ.
So, Linux 2036.0a will become 2036.01.001

Growing major version

Posted Feb 13, 2026 23:18 UTC (Fri) by mb (subscriber, #50428) [Link] (4 responses)

That I don't understand your post proves my point.

Growing major version

Posted Feb 13, 2026 23:49 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (3 responses)

ISO C uses x as a placeholder for the year of the release before the actual release. So, when ISO C23 was being developed, it was called C2x. Now that we're developing the next revision, it's called C2y, and it will eventually be C28 or C29. It wouldn't be too bad if it ends up being C30; we might just rename the temporary name to C3x if we reach 2030 without a release.

Growing major version

Posted Feb 14, 2026 0:30 UTC (Sat) by mb (subscriber, #50428) [Link]

Yeah. This is nonsense.
You end up with different version names referring to the same thing, historically.

Growing major version

Posted Feb 14, 2026 0:51 UTC (Sat) by excors (subscriber, #95769) [Link] (1 responses)

I suspect the main reason that works for C is that there's only one significant release per decade, so most people only need to remember the first digit and don't care about the placeholder. Probably won't scale well to something with a release every two months.

(I think it's pretty confusing even for C++ with three releases per decade, where C++0x = C++11, C++1y = C++14, C++1z = C++17. Apparently they've now committed to a strict 3-year release cycle so the dates are predictable and shouldn't need placeholders, but GCC/Clang still refer to C++2a and C++2c anyway.)

Growing major version

Posted Feb 15, 2026 1:55 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

GCC and Clang do this (AFAIK) to differentiate "C++23 in progress" from "C++23 as standardized" in the run up to C++23 actually being completed.

Growing major version

Posted Feb 14, 2026 13:24 UTC (Sat) by iabervon (subscriber, #722) [Link]

If you've got a very regular cycle like the kernel does, you can use the date when the cycle starts and get versions that are just as good as using the end of the cycle (particularly if it's only the year that's date-based). Of course, this all depends on a process where changes aren't assigned to a release until they're ready to release, with every time period seeing enough changes getting to that point to make the releases worthwhile, which is why I don't think it's a good system for the vast majority of projects.

Growing major version

Posted Feb 15, 2026 2:00 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Even with incremental numbers, you may run into the issue where you need a major bump rather than a minor. Depending on the maintenance guarantees, this may mean the current major version is "undead".

What we've ended up doing is that the release branch is x.y.z where "z" is "small". But the main development branch pushes "z" way above any actual patch release number by using the integer formed by YYYYMMDD. This is then bumped nightly. So while, say, 5.3.3 is the "latest release", development is at 5.3.20260214. Below any future release, but also way higher than any conceivable incremented patch number. Then if you end up saying "yep, 6.0 is coming" then walking it back to "whoops, the big feature missed the schedule, back to 5.4", you're still monotonic.

Growing major version

Posted Feb 13, 2026 19:38 UTC (Fri) by alx.manpages (subscriber, #145117) [Link]

I expect that would break the world.

Growing major version

Posted Feb 13, 2026 20:10 UTC (Fri) by jmalcolm (subscriber, #8876) [Link] (1 responses)

> Eventually, we'll have a large major version number, and there's nothing that could fix that

That is true, but the major version numbers change much less often. So, it is not really that hard to keep track of them. And I can keep track of recent minor versions but I agree with Linus that they all start to run together after a while.

Linux kernel version 6 was released about three years ago with version 5 about three years before that. Even if it were 156 currently and 155 three years ago, I think I could tell you the current major version number of Linux and, if you gave me a previous one, I would have a sense of how old it was. I would also have a pretty good idea of the major features that appeared in each one.

Without looking it up, I can say that Linux kernel 5 brought the introduction of Apple Silicon, io_uring, and exFAT. Apple Silicon then matured very nicely in Linux kernel 6 which aligns with the experimental period for "Rust in the Linux kernel". The major new architecture in kernel 6 has been RISC-V which is maturing nicely but, like Rust, will probably hit its stride in kernel 7. Kernel 6 also contained the bcachefs saga and the long-awaited real-time merge. Kernel 6 aligns with when most people started to trust btrfs (I still don't). We do not even have 7 and it already feels like it will be the release where both Rust and RISC-V go mainstream. Maybe bcachefs will come back. If not, perhaps a competitor. In short, the major version numbers seem meaningful in terms of marking different eras of kernel evolution.

I can tell you that "Docker containers" appeared in the kernel 4 timeframe but that you really need at least kernel 5 to run Docker today.

Contrast that to the situation where we had 2.6 forever and there was 2.6.38.8 and 2.6.25.20 three years before that (had to look that up just now). Without checking the date, could you have told me in rough terms how old the latter was or what had changed since then? Not me.

And kernel 2.4 goes all the way back to the Windows XP days. It feels like the beginning of 2.4 and the end of 2.6 is half the history of Linux.

The current system works pretty well in practice.

Growing major version

Posted Feb 13, 2026 20:29 UTC (Fri) by alx.manpages (subscriber, #145117) [Link]

Sounds reasonable. Thanks!

Growing major version

Posted Feb 13, 2026 20:24 UTC (Fri) by joib (subscriber, #8541) [Link] (1 responses)

Firefox, for instance, seems to be at version 147 at the moment. I don't lose sleep over it, so I don't see a problem with kernel 20.20 either.

If we're worried about too long version strings, one could display them as hex. :)

Growing major version

Posted Feb 13, 2026 20:29 UTC (Fri) by Wol (subscriber, #4433) [Link]

> so I don't see a problem with kernel 20.20 either.

If we have perfect vision, we'll see it :-)

Actually, when we get that far, we might decide to roll the major version every time the minor catches up. That'll slow the rise ...

Cheers,
Wol

Growing major version

Posted Feb 14, 2026 1:53 UTC (Sat) by hallyn (subscriber, #22558) [Link] (5 responses)

Lol - forget that. Imagine how many maintainer scripts and update programs will break when we switch from 9.19 to 10.0, because 9 > 1 :)

Growing major version

Posted Feb 15, 2026 2:03 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (4 responses)

Likely few as anything doing that already has problems with 6.9 > 6.10 already.

Growing major version

Posted Feb 15, 2026 2:55 UTC (Sun) by hallyn (subscriber, #22558) [Link] (3 responses)

So you don't think that https://man7.org/linux/man-pages/man2/personality.2.html will need an extension for UNAME919 alongside UNAME26? I admire, but do not share, your optimism :)

Growing major version

Posted Feb 16, 2026 2:01 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (2 responses)

What is the behavior today of UNAME26? It seems to ignore the major version. Is 4.1 reported the same as 3.1? The docs seem to indicate that it should…

Growing major version

Posted Feb 16, 2026 7:25 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (1 responses)

The comment at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/... says:

/*
* Work around broken programs that cannot handle "Linux 3.0".
* Instead we map 3.x to 2.6.40+x, so e.g. 3.0 would be 2.6.40
* And we map 4.x and later versions to 2.6.60+x, so 4.0/5.0/6.0/... would be
* 2.6.60.
*/

You can check if you distro does not patch it more with `setarch --uname-2.6 uname -r`. For me, `6.18.9-200.fc43.x86_64` gets mapped to `2.6.78-200.fc43.x86_64`.

Growing major version

Posted Feb 17, 2026 14:22 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Fun, so 4.5 and 5.5 overlap then? Yeah, I think anyone who needed this has since migrated. Of course, those without the ability to recompile may be stuck with oodles of other bugs. And it's not as if they'd be able to care about 4.4 vs. 5.4 without fixing the behavior anyways.

Hooray for lazy preemption

Posted Feb 13, 2026 18:01 UTC (Fri) by joib (subscriber, #8541) [Link]

The preemption mode change is kind of significant, considering most distros have defaulted to voluntary preemption for a couple of decades.

Version 7 Linux

Posted Feb 13, 2026 19:09 UTC (Fri) by bof (subscriber, #110741) [Link] (20 responses)

That'll really be a milestone, Version 7 Linux, just 47 years after the original.

https://en.wikipedia.org/wiki/Version_7_Unix

Version 7 Linux

Posted Feb 13, 2026 20:00 UTC (Fri) by devnull13 (subscriber, #18626) [Link] (5 responses)

Red Hat did something similar. There was originally Red Hat 1-9, with the last release in 2003. Then they renamed it Red Hat Enterprise Linux (RHEL) and restarted the numbering scheme with RHEL 2.1. RHEL 9 was released in 2022, 19 years later. (The current release number is 10.)

Version 7 Linux

Posted Feb 13, 2026 20:23 UTC (Fri) by jmalcolm (subscriber, #8876) [Link] (1 responses)

I cannot wait for Windows 95

Version 7 Linux

Posted Feb 13, 2026 22:00 UTC (Fri) by abatters (✭ supporter ✭, #6932) [Link]

There actually was a "Slackware 96" back in the day.

Version 7 Linux

Posted Feb 13, 2026 21:33 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

There was a bit more than just resetting the version number. Red Hat started in the days when Linux was mostly for individual users and maybe some small businesses, and the idea of an Enterprise distribution wasn't on anyone's mind. Over the course of time, they started to make real money charging for support contracts, but the standard Red Hat distribution was for everyone, home user and enterprise client alike.

When they created RHEL, it wasn't just a name change to give them an excuse to restart their numbering. It was mostly about formally splitting the Red Hat distribution into two tracks: a paid support RHEL version and a community supported Fedora version. You can reasonably claim that Fedora is as much a successor to Red Hat Linux as RHEL is. It really was a big change in the way everything was done, and I guess they decided it made more sense to restart numbering from 1 rather than having both RHEL and Fedora start at 10.

Version 7 Linux

Posted Feb 16, 2026 10:50 UTC (Mon) by paulj (subscriber, #341) [Link]

Red Hat's more "stable releases" product offerings had already split off from RHL prior to Fedora Core. E.g., Red Hat Linux Advanced Server. RHL ostensibly still was the desktop product, but then even Red Hat's desktop customers (based on my experience from Sun and who they had as desktop customers, that would have largely been banks, trading companies and EDA firms) found RHL too fast moving, given that Red Hat then also created a RHEL Workstation edition. The next release after RHL 9 was then FC 1.

Version 7 Linux

Posted Feb 16, 2026 10:34 UTC (Mon) by paulj (subscriber, #341) [Link]

It wasn't Red Hat 1-9, it was "Red Hat Linux" (RHL). And RHL wasn't renamed to "Red Hat Enterprise Linux". RHEL started out as "Red Hat Advanced Server", and via few more rebrandings to "Red Hat Linux Enterprise Edition", as a more stable fork of RHL. E.g,, RHEE 6.2 was based off RHL 6.2 / 7, RHEL 2.1 from RHL 7.2.

RHL became Fedora Core Linux, not RHEL.

Version 7 Linux

Posted Feb 13, 2026 20:05 UTC (Fri) by devnull13 (subscriber, #18626) [Link]

Thanks for making me feel even older. Version 6 was one of the first operating systems I used at work. (Along with PWB UNIX and Version 7.) 👴💾

Version 7 Linux

Posted Feb 13, 2026 20:20 UTC (Fri) by jmalcolm (subscriber, #8876) [Link] (2 responses)

> Version 7 Linux, just 47 years after the original

Version 7 was already repeated with the introduction of UnixWare 7 in 1998. That is a bit less than half-way between the first UNIX v7 and now.

Version 7 Linux

Posted Feb 13, 2026 20:36 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

MacOS 7 seems to have been 1991. Though…it wasn't a Unix at that point, was it?

Anyways, it looks like this was my first computing device (provided to the school and used in our "computer lab" (the school stage or cafeteria floor once the stage was repurposed as the library during construction too)) as MacOS 8 doesn't look as familiar.

Version 7 Mac

Posted Feb 14, 2026 18:01 UTC (Sat) by notriddle (subscriber, #130608) [Link]

There's https://en.wikipedia.org/wiki/A/UX, but that was an add-on.

Version 7 Linux

Posted Feb 13, 2026 20:20 UTC (Fri) by jmalcolm (subscriber, #8876) [Link] (8 responses)

> Version 7 Linux, just 47 years after the original

Version 7 was already repeated with the introduction of UnixWare 7 in 1998. That is a bit less than half-way between the first UNIX v7 and now.

Version 7 Linux

Posted Feb 14, 2026 4:59 UTC (Sat) by willy (subscriber, #9762) [Link] (7 responses)

HP-UX made it to version 7 in 1990!
Solaris 7 was 1998
FreeBSD 7 was 2008
AIX 7.1 was 2010
IRIX stopped at 6.5.30
Tru64 and Ultrix both stopped before 7

Any major Unix variants I forgot?

Version 7 Linux

Posted Feb 14, 2026 6:54 UTC (Sat) by bof (subscriber, #110741) [Link]

The last Sinix (by Siemens) version, which was the first Unix that I got to use back in the days, stopped at 5.43, in 1995. By then I was already fully on Linux, and did not miss it at all.

Version 7 Linux

Posted Feb 14, 2026 12:12 UTC (Sat) by alx.manpages (subscriber, #145117) [Link]

There's the UNIX V7 certification:
<https://unix.org/unixv7.html>

It's called V7 because it certifies that a system conforms to Issue 7 of the SVID/XPG/SUS/POSIX lineage of specifications.

In practice, it means conformance to POSIX.1-2008 plus some extensions required for SUS.

Probably the worst of all names they could have chosen.

Version 7 Linux

Posted Feb 14, 2026 21:49 UTC (Sat) by Sesse (subscriber, #53779) [Link] (4 responses)

> Any major Unix variants I forgot?

Emacs was at version 13 (after renumbering from 1.12) already in 1985.

Version 7 Linux

Posted Feb 14, 2026 22:09 UTC (Sat) by willy (subscriber, #9762) [Link] (3 responses)

But Emacs is a Lisp Machine, not a Unix derivative

Version 7 Linux

Posted Feb 19, 2026 23:52 UTC (Thu) by jschrod (subscriber, #1646) [Link] (2 responses)

Na, na - as everybody knows, "Emacs is an operating system" that just happens to have an integrated editor. Google searches confirm that, and we know that Google is always right.

;-) :-)

Version 7 Linux

Posted Feb 20, 2026 0:12 UTC (Fri) by willy (subscriber, #9762) [Link] (1 responses)

Yes, my point is that Emacs is of an entirely different heritage from Unix. Its lineage starts on ITS, then it was ported to the MIT Lisp Machine, then to Unix. Essentially it treats Unix as a grudging substrate; the Emacs OS is a universe of Lisp

Version 7 Linux

Posted Feb 20, 2026 0:31 UTC (Fri) by jschrod (subscriber, #1646) [Link]

Agreed, and well said.

Version 7 Linux

Posted Feb 19, 2026 17:33 UTC (Thu) by andy_shev (subscriber, #75870) [Link]

For Version 7 Linux it took only 35 years.

nullfs?

Posted Feb 13, 2026 20:21 UTC (Fri) by chexo4 (subscriber, #169500) [Link] (2 responses)

I’m confused what the point of nullfs is. I thought most init scripts worked by doing pivot root already anyway, why would you need to clean up the initramfs in that case?

Are files from the previous rootfs present after a pivot??

nullfs?

Posted Feb 13, 2026 20:38 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Hmm…isn't `nullfs` the "filesystem" for bind mounts on BSD too?

nullfs?

Posted Feb 14, 2026 12:50 UTC (Sat) by zhalas (subscriber, #114013) [Link]

> I’m confused what the point of nullfs is. I thought most init scripts worked by doing pivot root already anyway, why would you need to clean up the initramfs in that case?

pivot_root does not work on rootfs, (see: https://man7.org/linux/man-pages/man2/pivot_root.2.html):

> EINVAL The current root is on the rootfs (initial ramfs) mount;
> see NOTES.

> The rootfs (initial ramfs) cannot be pivot_root()ed. The
> recommended method of changing the root filesystem in this case is
> to delete everything in rootfs, overmount rootfs with the new
> root, attach stdin/stdout/stderr to the new /dev/console, and exec
> the new init(1). Helper programs for this process exist; see
> switch_root(8).
```

see: https://man7.org/linux/man-pages/man2/pivot_root.2.html