OS News Archive
Tilck is an educational monolithic kernel designed to be Linux-compatible at binary level. It runs on i686 and RISCV64 at the moment. Project’s small-scale and simple design makes it the perfect playground for playing in kernel mode while retaining the ability to compare how the very same usermode bits run on the Linux kernel as well. That’s a rare feature in the realm of educational kernels. Because of that, building a program for Tilck requires just a gcc-musl toolchain from bootlin.com. Tilck has no need to have its own set of custom written applications, like most educational kernels do. It just runs mainstream Linux programs like the BusyBox suite. While the Linux-compatibility and the monolithic design might seem a limitation from the OS research point of view, on the other side, such design bring the whole project much closer to real-world applications in the future, compared to the case where some serious (or huge) effort is required to port pre-existing software on it. Also, nothing stops Tilck from implementing custom non-Linux syscalls that aware apps might take advantage of. ↫ Tilck GitHub page Tilck implements about 100 Linux syscalls, and is not focused on replacing the Linux kernel or even becoming a generic desktop or server operating system. It supports both i686 and RISC-V, has support for FAT, and a whole slew of other features. It can run a number of console and even a few framebuffer applications, but don’t expect things like X11 to work, or to ever work.
We need a new framework for how to defend against “trolls”. The feeding metaphor ran its course many years ago. It is done and will not be coming back. New online risks demand that we adapt and become proactive in protecting our spaces. We have to loudly and proudly set the terms of what is permissible. Those holding social or institutional power in communities should be willing to drop a few loud fuck offs to anyone trying to work their way in by weaponizing optics, concern trolling, or the well known “tolerance paradox”. Conceding through silence, or self-censorship, only emboldens those who benefit from attacking a community. ↫ diegoebe Een volk dat voor tirannen zwicht, zal meer dan lijf en goed verliezen, dan dooft het licht.
Asterinas is a new Linux-ABI-compatible kernel project written in Rust, based on what the authors call a “framekernel architecture”. The project overlaps somewhat with the goals of the Rust for Linux project, but approaches the problem space from a different direction by trying to get the best from both monolithic and microkernel designs. ↫ Ronja Koistinen at LWN.net Ronja Koistinen has done an outstanding job diving into this new operating system kernel and approach to kernel architecture, including its intended focus and goals. Head on over to the source and read it over there.
rou2exOS is a 64-bit DOS-like operating system (OS). The system is mainly written in Rust, but some portion of x86 assembly is used as well (inline + freestanding code for the stage2 kernel loading). ↫ Blog post about rou2exOS at blog.vxn.dev It can do basic VGA operations, comes with a very barebones networking stack, realtime clock support, a FAT12 driver, and a few more tidbits. It’s a rewrite of the previous iteration of the hobby operating system.
And I’ve got another custom hobby operating system for you today: Munal OS. An experimental operating system fully written in Rust, with a unikernel design, cooperative scheduling and a security model based on WASM sandboxing. ↫ Munal OS GitHub page Munal OS has no bootloader, but is instead compiled into a single EFI binary that contains all it needs to function, including a few applications. Since Munal OS relies on a PCI driver that communicates with QEMU via the VirtIO 1.1 specification for things like input and graphics, it can’t yet run on real hardware. It has its own UI toolkit, and comes with applications like a basic web browser, a text editor, and a Python terminal.
Xeneva is an operating system for both x86_64 and ARM64 architectures, built from the ground up. The Kernel is known as ‘Aurora’ with hybrid kernel design and the entire operating system is known as ‘Xeneva’. ↫ XenevaOS GitHub page It’s remarkably complete, with driver loading and linking, up to SSE 3 support, USB3 and Intel HD audio support, networking, and a whole lot more of the basics that make up a modern complete operating system. On top of all this, it also has a compositing window manager, a desktop environment, a terminal with VT100 support, Freetype2 font rendering, and much more. It also comes with a few basic applications like a file manager, calculator, audio player, and so on. It’s written in C (and some C++), and uniquely, can only be built in a Windows environment, something you don’t see very often. It definitely looks quite impressive.
An incredibly primitive operating system, with just two instructions: compile (1) and execute (0). It is heavily inspired by Frank Sergeant 3-Instruction Forth and is a strip down exercise following up SectorForth, SectorLisp, SectorC (the C compiler used here) and milliForth. Here is the full OS code in 46 bytes of 8086 assembly opcodes. ↫ 10biForthOS sourcehut page Yes, the entire operating system easily fits right here, inside an OSNews quote block: 50b8 8e00 31d8 e8ff 0017 003c 0575 00ea5000 3c00 7401 eb02 e8ee 0005 0588 eb47b8e6 0200 d231 14cd e480 7580 c3f4 ↫ 10biForthOS sourcehut page How do you actually use this operating system? Once the operating system is loaded at boot, it listens on the serial port for instructions. You can then send the instruction 1 followed by a byte of an assembly opcode which will be compiled into a fixed location in memory. The instruction 0 will then execute the program. There’s also a version with keyboard support, as well as a much bigger version compiled for x86-64. Something like this inevitably raises the question what an operating system really is, and if this extremely limited and minimalist thing can be considered as one. I’m not going to deep into this existential discussion, mostly because I land firmly on the side that this is indeed just as much an operating system as, say, Windows or MorphOS. This bit of code, when booted, allows you to operate the system. It’s an operating system.
We are today officially deprecating two installation methods and three legacy CPU architectures. We always strive to have Home Assistant run on almost anything, but sometimes we must make difficult decisions to keep the project moving forward. Though these changes will only affect a small percentage of Home Assistant users, we want to do everything in our power to make this easy for those who may need to migrate. ↫ Franck Nijhof on the Home Assistant blog Home Assistant is quite popular among the kind of people who read OSNews, and this news might actually hit our little demographic particularly hard. The legacy CPU architectures they’re removing support for won’t make much of a difference, as we’re talking 32bit x86 and 32bit ARM, although that last one does include version 1 and 2 of the Raspberry Pi, which were quite popular at the time. Do check to make sure you’re not running your Home Assistant installation on one of those. The bigger hit is the deprecation of two installation methods: Home Assistant Core and Home Assistant’s Supervised installation method. In Core, you’re running it in a Python environment, and with Supervised, you’re installing the various components that make up Home Assistant manually. Supervised is used to install Home Assistant on unsupported operating systems, like the various flavours of BSD. What this means is that if you are running Home Assistant on, say, OpenBSD, you’re going to have to migrate soon. Apparently, these installation methods are not used very often, and are difficult for Home Assistant to support. These changes do not mean you can no longer perform these installation methods; it just means they are not supported, will be removed from the documentation, and new issues with these methods will not be accepted. Of course, anyone is free to take over hosting any documentation and guides, as Home Assistant is open source. Home Assistant generally wants you to use Home Assistant OS, which is basically a Linux distribution designed to run Home Assistant, either on real hardware (which is what I do, on an x86 thin client) or in a container.
OSle is an incredibly small operating system, coming in at only 510 bytes, so it fits entirely into a boot sector. It runs in real-mode, and is written in assembly. Despite the small size, it has a shell, a read and write file system, process management, and more. It even has its own tiny SDK and some pre-built programs. The code’s available under the MIT license.
Few things in life make me happier than a new 9front release. This new release, 9front “CLAUSE 15 COMMON ELEMENTS OF MAUS AND STAR TYPE”, comes with a variety of fixes and new features, such as temperature sensor support for Ryzen processors, a new Intel i225 2.5 GbE driver, a number of low-level kernel improvements, and so, so many more small fixes and changes. If you use 9front, you already know all of this, and you’re too cool to read OSNews anyway. If you’re new to 9front and want to join the cool people club, you can download images for PC, Raspberry Pi, MNT Reform, and QEMU.
RetrOS-32 is a 32bit operating system written from scratch, with graphics, multitasking and networking capabilities. The kernel is written in C and assembly, while the userspace applications are written in C++, using Make for compilation, all licensed under the MIT license. It runs on Qemu, of course, but a variety of real hardware is also supported, which is pretty cool and relatively unique for a small hobby project like this. The UI is delightfully retro – as the name obviously implies – and it comes with a set of basic applications, as well as games like Wolfenstein 3D.
TacOS is a UNIX-like kernel which is able to run DOOM, among various other smaller userspace programs. It has things like a VFS, scheduler, TempFS, devices, context switching, virtual memory management, physical page frame allocation, and a port of Doom. It runs both on real hardware (tested on my laptop) and in the Qemu emulator. ↫ TacOS GitHub page TacOS – great name – is written in C, and explicitly a hobby and toy project. The code’s licensed under the Mozilla Public License 2.0.
As some of you may have noticed, we’ve been having some issues with captchas. The powers that be – which isn’t me, I don’t know anything about web development – are looking into it, and once we’ve pinpointed the problem we’ll get it fixed. It’s annoying us too, so we want this resolved as quickly as possible. OSNews readers just trying to visit the site to read some tech stuff should not be subjected to selecting squares with buses or crosswalks. Our apologies for the annoyance, and I’ll update this post once the issue’s been resolved.
With FreeDOS being, well, DOS, you’d think there wasn’t much point in putting out major releases and making big changes, and you’d mostly be right. However, being a DOS clone doesn’t mean there isn’t room for improvement within the confines of the various parts and tools that make up DOS, and that’s exactly where FreeDOS focuses its attention. FreeDOS 1.4 comes about three years after 1.3. This version includes an updated FreeCOM, Install program, and HTML Help system. This also includes improvements to many of the utilities including FDISK, JEMM, 7Zip, FORMAT, FASM, MORE, RUNTIME, and more! ↫ FreeDOS website If you’re using FreeDOS, you’re most likely doing so for a highly specialised task, and racing to upgrade isn’t exactly high on your list of priorities. Still, it’s great to see FreeDOS moving forward and improving where it can.
This question was asked during my Boot Camp presentation last fall in Boston, and over the past 35 years dozens of times people have asked, how big is VMS? That translates into “how many lines of code are in VMS”? I thought it was time to at least make a stab at pursuing some insight into the answer. I wrote some command procedures to count the number of source lines in .B32, .B64, .C, .MAR, .M64, and .S files. Not counted are blank lines and lines beginning with the standard comment characters and miscellaneous directives for the particular language. ↫ Clair Grant As always with the ‘lines of code’ metric, there’s some real arbitrariness going on, and in this case that means things like excluding networking, which to me seems like a core part of an operating system, but alas, choices need to be made. The final tally for lines of code, as per the definition used in the article, in the most recent version of OpenVMS, version 9.2-3, is almost 1.9 million. Do with that information as you please. What’s really fascinating, though, are the deltas between the versions investigated in this article: V6.2 (May 1995, port to Alpha), V7.2 (February 1999, kernel threads, 64-bit APIs, Galaxy, and more), V8.2 (February 2005, port to Itanium), V9.2-3 (december 2024, port to x86). Going from one version to the next, roughly 400000 lines of code were added each time – the article doesn’t theorise about the consistency of this number, and I suspect it’s mostly just a fun coincidence, but it does jump out.
This whitepaper provides an introduction to and overview of seL4. We explain what seL4 is (and is not) and explore its defining features. We explain what makes seL4 uniquely qualified as the operating-system kernel of choice for security- and safety-critical systems, and generally embedded and cyber-physical systems. In particular, we explain seL4’s assurance story, its security- and safety-relevant features, and its benchmark-setting performance. We also discuss typical usage scenarios, including incremental cyber retrofit of legacy systems. ↫ Gernot Heiser Some light reading for Monday.
As of the 18th of February, OpenVMS, known for its stability and high-availability, 47 years old and ported to 4 different CPU architecture, has a package manager! This article shows you how to use the package manager and talks about a few of its quirks. It’s an early beta version, and you do notice that when using it. A small list of things I noticed, coming from a Linux (apt/yum/dnf) background: There seems to be no automatic dependency resolution and the dependencies it does list are incomplete. No update management yet, no removal of packages and no support for your own package repository, only the VSI official one. Service startup or login script changes are not done automatically. Packages with multiple installer files fail and require manual intervention. It does correctly identify the architectures, has search support and makes it way easier to install software. The time saved by downloading, manually copying and starting installation is huge, so even this early beta is a very welcome addition to OpenVMS. ↫ Remy van Elst Obviously, a way to install software packages without having to manually download them is a huge step forward for OpenVMS. The listed shortcomings might raise some eyebrows considering most of us are used to package management on Linux/BSD, which is far more advanced. Bear in mind, however, that this is a beta product, and it’s quite obvious these missing essential features will be added over time. Luckily it at least lists dependencies, so let’s hope actually automating installing them is in the works and will be available soon. I actually have an OpenVMS virtual machine set up and running, but I find using it incredibly difficult – but only because of my own lack of experience with and knowledge about OpenVMS, of course. Any experience of knowledge rooted in UNIX-based and Windows operating systems is useless here, even for the most basic of CLI tasks. If I find the time, I’d love to spend more time with it and get more acquainted with the way it works, including this new package manager.
It’s been a while, but there’s a new release of Ironclad, the formally verified, hard real-time capable kernel written in SPARK and Ada. Aside from the usual bugfixes, this release moves Ironclad from multiboot to Limine, adds x86_64 ACPI support for poweroff and reboot, improvements to PTY support, the VFS layer, and much more. The easiest way to try out Ironclad is to download Gloire, a distribution that uses Ironclad and the GNU tools. It can be installed in both a virtual machine and on real hardware.
JotaleaOS is an open source, minimalistic, experimental operating system made by Jotalea, designed for extreme low-resource environments. It does not support external programs or games, as it lacks a standard application execution environment. The system is entirely self-contained, running only its built-in commands. ↫ JotaleaOS website Exactly what is says on the tin: a tiny operating system created entirely as a learning experience. That’s it.
During a weekend of tidying up – you know, the kind of chore where you’re knee-deep in old boxes before you realize it. Digging through the dusty cables and old, outdated user manuals, I found something that I had long forgotten: an old Plan 9 distribution. Judging by the faded ink and slight warping of the disk sleeve, it had to be from around 1994 or 1995. I couldn’t help but wonder: why had I kept this? Back then, I was curious about Plan 9. It was a forward-thinking OS that never quite reached full potential. Holding that disk, however, it felt more like a time capsule, a real reminder of computing’s advancements and adventurous spirit in the 1990s. ↫ Bill Dyer at It’s FOSS As the article notes, 9front is the way to go if you want to try Plan 9 today. Plan 9/9front appeals to a very specific type of person, but when you dive into the excellent – and incredibly entertaining – documentation, it really seems quite easy to grasp and get started with. There’s definitely things you’ll need to unlearn and some compromises you’ll need to make, but I think you’ll be able to get a lot more work done than you might think. Also, if you start adding software to 9front, you get to use the best GitHub alternative of all time: shithub. That alone makes it worth it to try 9front.