OS News Archive
Earlier today, I made the decision to remove all advertising from OSNews. From here on out, you will no longer see any ads, cookie banners, and other ad-related privacy-invasive technologies on this website. While this means a hit to my income, making OSNews even more reliant on our Patreon supporters and Ko-Fi donors, it genuinely feels liberating. I should’ve made this decision years ago. Read on for how you can support us, and our big fundraiser. I have always been open and honest about my dislike for the modern online advertising industry. It’s incredibly privacy-invasive, a massive security risk, generally lacking in taste, and genuinely intrusive. As such, despite running ads on OSNews, I have always advocated for the concept of “your computer, your rules”, meaning only you, the user, gets to decide what gets run on your computer and displayed on your screen. This includes the use of ad-blockers. I have a Pi-Hole, and you can pry it from my cold, dead hands. Because of this, maintaining ads on OSNews became untenable. Everything about the ads on our site, from the actual ads themselves to the annoying cookie banners talking about “our 1500 partners”, gave me the ick, as the young, hip people say, and I’ve been considering turning them off for a long time. Today, after yet another reader rightfully pointing out how absurd our cookie banner was, I finally made the call. One email to our owner, David Adams, later, and we’re now entirely ad-free, for everyone. This is a hit to my income, and as such, I kindly ask anyone capable of doing so to support the continued existence of OSNews. How can you support OSNews? We’ve been online since 1997, meaning soon we’ll be hitting our 30-year anniversary. Very few websites can boast about such a long, uninterrupted existence, and despite all the changes both the industry and the world at large have gone through, OSNews is still here, doing what it has always done. The removal of ads means we’re even more dependent on you, dear readers, but I’m confident in saying that we’ll make it another 30 years. Thank you for all your continued support over the decades, and let’s keep going. Without icky ads.
Choosing human-readable file formats is an act of technological sovereignty. It’s about maintaining control over your data, ensuring long-term accessibility, and building systems that remain comprehensible and maintainable over time. The slight overhead of human readability pays dividends in flexibility, durability, and peace of mind. These formats also represent a philosophy: that technology should serve human understanding rather than obscure it. In choosing transparency over convenience, we build more resilient, more maintainable, and ultimately more trustworthy systems. ↫ Adële It’s hard not to agree with this sentiment. I definitely prefer being able to just open and read things like configuration files as if they’re text files, for all the same reasons Adële lists in their article. It just makes managing your system a lot easier, since I means you won’t have to rely on the applications the files belong to to make any changes. I think this also extends to other areas. When I’m dealing with photo or music library tools, I want them to use the file system and directories in a human-readable way. Having to load up an entire photo management application just to sort some photos seems backwards to me; why can’t I use my much leaner file manager to do this instead? I also want emails to be stored as individual files in directories matching mailboxes inside my email client, just like BeOS used to do back in the day (note that this is far from exclusive to BeOS). If I load up my file manager, and create a new directory inside the root mail directory I designated and copy a few email files into it, my email client should reflect that. As operating systems get ever more locked down, we’re losing the human-readability of our systems, and that’s not a good development.
Main highlight of this update is a modernized core built upon Debian 13 “Trixie”, ensuring a robust foundation for the platform. Proxmox VE 9.0 further introduces significant advancements in both storage and networking capabilities, addressing critical enterprise demands. A highlight is the long-awaited support for snapshots on thick-provisioned LVM shared storage, improving storage management capabilities especially for enterprise users with Fibre Channel (FC) or iSCSI SAN environments. With newly added “fabric” support for Software-Defined Networking (SDN), administrators can construct highly complex and scalable network architectures. ↫ Proxmox press release I’ve only very recently accepted the gospel of Proxmox, and I now have a little mini PC running Proxmox, hosting a Debian Pi-Hole container, a 9front virtual machine, and a Windows 7 retro virtual machine. I’m intending to use it as an easy shortcut for running retro stuff, as well as any fun tools I might run into that work best in a container. I haven’t updated yet to this new release, but I’m interested to see how easy the upgrade process will be. Considering it’s just Debian, it can’t be too involved. I’m curious of anyone else here is using Proxmox or similar tools at home, or at work for more complex use cases.
Patchwork is a 64-bit monolithic NON-POSIX operating system for the x86_64 architecture that rigorously follows a “everything is a file” philosophy. Built from scratch in C it takes many ideas from Unix, Plan9, DOS and others while simplifying them and sprinkling in some new ideas of its own. ↫ PatchworkOS GitHub page Patchwork is a surprisingly advanced operating system considering it’s a hobby project. It has multithreading with a constant-time scheduler, fully preemptive mutitasking, SMP, file-based IPC (including pipes, shared memory, sockets and Plan9 inspired “signals” called notes), and much more. It also uses a Linux-style VFS and has a custom C standard library. On top of that, there’s a modular window manager that supports themes, in which everything is a window, and so much more. It supports x86_64, but only supports running in RAM. It’s licensed under the MIT license.
BlueOS kernel is written in Rust, featuring security, lightweight, and generality. It is compatible with POSIX interfaces and supports Rust’s standard library. ↫ BlueOS kernel GitHub page This is the kernel for the BlueOS operating system, developed by Vivo, a Chinese consumer electronics company. Sadly, all of the websites and documentation for BlueOS are written in Mandarin, making it virtually impossible to really get a grip on what they’re developing, and I certainly don’t trust Google Translate or whatever enough to give me a proper, trustworthy, and accurate translation. I hope the company either hires some translators, or perhaps enthusiasts with the right skillset can provide some more insight over the coming years. It seems similar to Huawei’s HarmonyOS Next, and it’s apparently shipping on one of Vivo’s smartwatches.
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.
