We are excited to announce the availability of VSI OpenVMS E9.2 for x86-64, field test version of the upcoming V9.2 release. This is the next step in the journey to migrate OpenVMS to the x86-64 platform. The E9.2 release allows you to use the operating system with some of the most commonly-used hypervisors and includes a host of newly migrated applications. VSI has been porting OpenVMS to x86-64 for a while now, and it seems they’re getting quite close to general availability. E9.2 is focused on x86 hypervisors, and the porting effort as a whole should provide a future upgrade path for VMS users for a long time to come.
OS News Archive
Sculpt OS version 22.04 introduces the concept of service-level sandboxing and features completely new drivers for wireless, graphics, and USB. On the user-visible surface, the new version of Sculpt OS looks and feels familiar to users of the previous version. Under the hood, however, at the nitty-gritty hardware-support level, it features completely revamped device drivers for Intel wireless, Intel graphics, and USB. Get Sculpt OS’ latest release from the download page, and be sure to read the documentation for more detailed information.
A lot has changed since release 0.6.0! First thing, it is impossible to collect all the changes that happened since December 24, 2020 into one set of release notes, so this will focus on the highlights. It was very important to me that this be a release targeting the foundations of Redox OS. This includes, the bootloader, the filesystem, the package manager, the kernel, the drivers, and much more. The focus was on enabling Redox OS to boot on the widest set of hardware possible. Redox is a Rust-based operating system with a microkernel and a UNIX-like paradigm and an optional GUI. Its lead developer works for System76 as principal engineer.
Known as right angle with downwards zigzag arrow, angle with down zig-zag arrow, \rangledownzigzagarrow, and &angzarr;, no one knows what ⍼ is meant to represent or where it originated from. Section 22.7 Technical Symbols from the Unicode Standard on the Miscellaneous Technical block doesn’t say anything about it. Who doesn’t love a good what-the-hell-is-this-glyph story?
Believe it or not, not everything is based on C. There are current, shipping, commercial OSes written before C was invented, and now others in both newer and older languages that don’t involve C at any level or layer. There’s tons of examples.
The 22.02 release is dominated by three topics, the tightening and restructuring of the code base, device-driver infrastructure, and the transition of Sculpt OS towards a versatile toolkit for building specialized operating-system appliances. Genode’s release notes are always a sight to behold. Detailed, interesting, and always worth a read.
Neptune OS is a Windows NT personality of the seL4 microkernel. It implements what Microsoft calls the “NT Executive”, the upper layer of the Windows kernel NTOSKRNL.EXE, as a user process under the seL4 microkernel. The NT Executive implements the so-called NT Native API, the native system call interface of Windows upon which the more familiar Win32 API is built. These are exposed to the user mode via stub functions in NTDLL.DLL (a somewhat redundant name if you ask me) with names such as NtCreateProcess. The NT Executive is also responsible for the Windows kernel driver interface (known as the Windows driver model), which includes functions like IoConnectInterrupt and IoCallDriver. On Windows these are loaded into kernel mode and linked with the NTOSKRNL.EXE image. On Neptune OS, we run all the Windows kernel driver in user mode and they communicate with the NT Executive process via standard seL4 IPC primitives. The eventual goal of the Neptune OS project is to implement enough NT semantics such that a ReactOS user land can be ported under Neptune OS, as well as most ReactOS kernel drivers. In theory we should be able to achieve binary compatibility with native Windows executables provided that our implementation of the NT Native API is sufficiently faithful. We should also be able to achieve a high degree of source code compatibility with Windows kernel drivers. The main obstacle of achieving binary compatibility of kernel drivers is that many Windows kernel drivers do not follow the standard Windows driver communication protocol (ie. passing IRPs when you need to call another driver) and instead just pass pointers around and call into other drivers directly. In Neptune OS unless it’s a driver-minidriver pair we always run “kernel” drivers in their separate processes so it is not possible to do that. Very cool idea for a project, and awesome to see that they plan on integrating the work done by the ReactOS team.
A few years ago, I got the crazy idea to try porting the Commodore 64 KERNAL and BASIC ROMs to the NES, since their CPUs are mostly the same. But I gave up when things got complicated with the PPU. Then a couple weeks ago, I saw that someone ported it to the Atari 1200XL, so I decided I’d give it another shot. This time, I was able to make a (mostly) working system. Quite impressive.
GNU/Hurd is the original Free Software operating system started in the 1980s. Its microkernel design has been evolving over the years and the project has not quite hit mainstream use. I believe this is due to one main reason: the lack of drivers for peripherals and hardware. In this talk, I explain how NetBSD kernel drivers have been reused in a microkernel setting and demonstrate their use to boot up a GNU/Hurd system via a userspace rump disk driver, with a driverless Hurd kernel, gnumach. The ACPI management, PCI management, and actual driver are in separate processes with RPC interfaces between them, which separates out their debugging, licencing concerns and execution. Hurd is a neverending story, derailed by the massive popularity and uptake of the Linux kernel as the de facto standard kernel for the GNU project. I’d love for it to become more competitive, but the situation isn’t exactly looking great.
As many of you have no doubt noticed, a recent bug in our CMS flipped everyone over to our experimental dark mode (along with some other quirks). We haven’t had the time to address the issue at its core yet, but for the time being, if you’re a registered user, you should be able to get light mode back now by clicking the “Revert to Light Mode” link in your right sidebar. We’ll get light mode working for non-logged-in users ASAP. I sincerely appreciate that so many people emailed us to tell us how much you hate the dark mode. Really! Let us know in the comments if you notice anything else.
RTM/Z80 is a multitasking kernel, built for Z80 based computers, written in Z80 assembly language, providing its users with an Application Programming Interface (API) accessible from programs written in the C language and the Z80 assembly language. It is intended to be a simple and easy to use learning tool, for those who want to understand the tips and tricks of the multitasking software systems. This is certainly not the only hobby operating system for Z80-based computers, but the more the merrier.
Genode 21.11 puts the spotlight on device drivers. Interactive Genode scenarios come to the Pinephone, hardware-accelerated graphics becomes available on Intel Gen9+ and Vivante GPUs, and Xilnx Zynq receives new love. Excellent progress, as always from the Genode team.
Oxide announced Hubris, their microkernel OS for embedded systems, and Humility the debugger for it. As time went on in early 2020 and we found ourselves increasingly forcing existing systems out of the comfort of their design centers, we wondered: was our assumption of using an existing system wrong? Should we in fact be exploring our own de novo operating system? Instead of having an operating system that knows how to dynamically create tasks at run-time (itself a hallmark of multiprogrammed, general purpose systems), Cliff had designed Hubris to fully specify the tasks for a particular application at build time, with the build system then combining the kernel with the selected tasks to yield a single (attestable!) image. This is the best of both worlds: it is at once dynamic and general purpose with respect to what the system can run, but also entirely static in terms of the binary payload of a particular application — and broadly static in terms of its execution. Oxide is working on producing what is basically a rack sized blade server. It’s a rack pre-populated with hardware controlled by a single control plane. The rack is meant to be a single, sealed unit, and as such, they needed something which could be embedded into the various controllers in the rack. Hubris is written in Rust, it’s MPL licensed, and there is a GitHub repository.
Airyx OS has seen its first beta release, with a quite a few big improvements. • Default application bundles: Firefox, Terminal, and Kate• A new AppKit-based ObjectiveC installer (Install airyxOS.app)• Java SDK 17.0.1+12• Updated to FreeBSD 12.3RC base OS and kernel• Improvements to AppKit including better support of color catalogs and color lists, more Mac-like default colors, support for pop-up menus, fixed scrollbar icons, improved font handling, system key bindings, improved NIB support, fixed glitches in window resizing and moving, and more.• Updated many packages You can read more about Airyx on its website, and be sure to follow the project’s account on Twitter for more updates.
The “desktop-engine” Arcan has put out a new release after close to a year of development, continuing its current focus on improving network transparency. A recent and long post on Arcan as OS Design is also a worthwhile and interesting view into this fascinating project.
Today we celebrate the third birthday of SerenityOS, counting from the first commit in the git repository, on October 10, 2018. Previous birthdays: 1st, 2nd. What follows is a list of interesting events from the past year, mixed with random development screenshots and also reflections from other developers in the SerenityOS community. SerenityOS is simply a great project, with a good mindset, good people, and lots and lots of talent. These birthday posts are a great way to check if you’ve missed any of the developments around the project this year.
First and technically most exciting, the new version enables the use of hardware-accelerated graphics on Intel GPUs, paving the ground for graphics-intensive applications and games. The GPU support is based on the combination of the Mesa library stack with our custom GPU multiplexer as featured in Genode 21.08. Note that this fresh new feature should best be regarded as experimental and be used with caution. Second, our port of the Chromium-based Falkon web browser has become able to present media content like videos and sound. Look out for the browser in the tools menu of cproc’s depot. It is accompanied with a ready-to-use audio driver and a mixer component. In cases where audio output is not desired, the browser – or any other component that requests audio output – can be connected to a new component called black hole, which merely mimics an audio driver without any audible effect. That’s excellent progress for this fascinating operating system that’s been steadily improving for years now. And it’s not even everything that’s in this release – read the announcement for all the details.
Quickly create and run highly optimised desktop virtual machines for Linux, macOS and Windows; with just two commands. You decide what operating system you want to run and Quickemu will figure out the best way to do it for you. Excellent idea.
The FyneDesk project is taking a fresh look at what it means to be a desktop environment. Using the same beautiful and user friendly graphics of the Fyne toolkit you will find it a great place to call home on your computer. We also want to make it easy to update, add to or change your desktop just like you can with any other Open Source software. And so the design of our desktop project has put ease of learning and development in the centre of how we work. Now you can have the desktop of your dreams – and share the result for others as well. That’s some flowery language, but look past it and there’s a number of very interesting projects here. The desktop environment itself seems a bit rough around the edges, but the underlying toolkit is quite fascinating – it’s not yet another Qt or GTK derivative, but instead completely new and written in Go. There’s a number of applications, too.
An operating system I’ve been writing since ~June 2017. Although it’s a long shot (and very optimistic), I ultimately intend it to replace Linux and Windows as a desktop operating system. Very optimistic, but there’s quite a few things here already. The code is on gitlab, where you can find more information, too.