Genode 20.05 takes our road map’s focus on the consolidation and optimization of the framework and its API to heart. It contains countless of under-the-hood improvements, mostly on the account of vastly intensified automated testing, the confrontation of Genode with increasingly complex software stacks, and stressful real-world work loads. You will find this theme throughout the release notes below. The result of this overhaul is captured in the updated version of the Genode Foundations book (Section New revision of the Genode Foundations book). I wish every project had release notes as detailed as Genode’s always are. Excellent work.
OS News Archive
Visopsys is a hobby OS for x86-compatible PCs, started in 1997. Version 0.9 was released this morning, and there’s a change log. The summary: This major release offers a subtly updated look, enhanced networking capabilities and associated programs, Unicode support, a software packaging/download/install/uninstall infrastructure with an online ‘store’, a user space window shell, VMware mouse integration, HTTP, XML, and HTML libraries, some C++ and POSIX threads (pthreads) support, ‘pipes’ for interprocess communication, and additional hashing algorithms. Visopsys has a long history on OSNews – the oldest mention being from 2005. It’s been in relatively steady development ever since.
Hobbyist licenses for OpenVMS have been a notable option for users of the VAX, Alpha, and Integrity business servers. HP 3000 users tried for a similar license for MPE/iX, especially in the months following HP’s news it wouldn’t continue its 3000 business. HP declined to create the kind of license the users wanted to power the basement and in-garage 3000 servers they’d brought home. With the change in ownership of OpenVMS — HP Enterprise turned over the business to VMS Software Inc. — the hobbyist program is ending at HPE. VSI is considering one option to continue hobbyist-class licenses. That’s one hell of a bummer. I hope they can come to sort of solution or agreement.
This post will give you a quick intro to the basics of GUI programming for SerenityOS. A one-line introduction that covers the article perfectly. A rarity, indeed. We covered SerenityOS late last year.
Speaking about LSDJ, the premiere music software for the Game Boy, George Buckenham writes: But it also got me thinking about chorded input schemes. LSDJ is a workhorse of a program, able to do a lot of stuff. And it’s designed to let you do that stuff quickly – to let you iterate fast, put down a tune fast, adjust things while you’re standing on stage. But also… a Gameboy has 8 buttons – 4 directions, A, B, SELECT and START. So it has to make those buttons work hard. And that’s where chording comes in. Chording is a means of inputting commands to software by holding down multiple buttons at once. Ctrl-C is an example of a chorded command. Hold down Ctrl, then press C while you’re doing it. Text copied. But you can also make chording work harder than that. It requires a lot of planning and thinking to make a complex application controllable by only a few buttons, such as the mere 8 buttons on the original Game Boy. I wouldn’t want to be in the shoes of developers who have to make things work with limitations such as these.
Alan Kay said: “Simple things should be simple, complex things should be possible”. This sentence was the inspiration for the founder of RT-Thread to stick to his beliefs. RT-Thread is an open source embedded real-time operating system, and this project started in 2006. I know you have no idea what RT-Thread is, but you are using an IoT OS system now, that’s where this article may be of interest. Let’s take a quick tour of RT-Thread. RT-Thread: background RT-Thread, short for Real Time-Thread, is, as its name implies, an embedded real-time multi-threaded operating system. One of its basic properties is to support multitasking. Allowing multiple tasks to run at the same time does not mean that the processor actually performs multiple tasks at the same time. In fact, a processor core can only run one task at a time. Every task is executed quickly, and through the task scheduler (the scheduler determines the sequence according to priority), the tasks are switched rapidly, which gives the illusion that multiple tasks are running at the same time. In the RT-Thread system, the task is implemented by threads. The thread scheduler in RT-Thread is the task scheduler mentioned above. RT-Thread is mainly written in C, making it easy to understand and easy to port. It applies object-oriented programming methods to real-time system design, making the code elegant, structured, modular, and tailorable. For resource-constrained Microcontroller Unit (MCU) systems, the NANO version of RT-Thread (tailored from the standard version of RT-Thread), which requires only 3KB of flash and 1.2KB of RAM, can be tailored with easy-to-use tools. For resource-rich IoT devices, RT-Thread can use the online software package management tool, together with system configuration tools, to achieve intuitive and rapid modular cutting, seamlessly import rich software feature packs, thus achieving complex functions like Android’s graphical interface and touch sliding effects, smart voice interaction effects, and so on. RT-Thread’s architecture RT-Thread is not only a real-time kernel, but also has a rich middle-tier component, as shown in the following figure. It includes: The kernel layer: RT-Thread kernel, the core part of RT-Thread, includes the implementation of objects in the kernel system, such as multi-threading and its scheduling, semaphore, mailbox, message queue, memory management, timer, etc.; libcpu/BSP (Chip Migration Related Files/Board Support Package) is closely related to hardware and consists of peripheral drivers and CPU transport. The components and service layer: Components are based on upper-level software on top of the RT-Thread kernel, such as virtual file systems, FinSH command-line interfaces, network frameworks, device frameworks, and more. Its modular design allows for high internal cohesion within the assembly and low coupling between components. The RT-Thread software package: A general-purpose software component running on the RT-Thread IoT operating system platform for different application areas, consisting of description information, source code or library files. RT-Thread provides an open package platform with officially available or developer-supplied packages that provide developers with a choice of reusable packages that are an important part of the RT-Thread ecosystem. The package ecosystem is critical to the choice of an operating system because these packages are highly reusable and modular, making it easy for application developers to build the system they want in the shortest amount of time. RT-Thread supports more than 174 software packages. RT-Thread has launched more than a decade ago, and this is the first time we make an official self-introduction to the world, especially at the beginning of 2020, it feels great! We welcome suggestions for RT-Thread, and you can feel free to contact us on Twitter or send us an e-mail. And if you have any great ideas, you are very welcome to contribute to our Github.
System calls are a way for unprivileged, user applications to request services from the kernel. In the RISC-V architecture, we invoke the call using the ecall instruction. This will cause the CPU to halt what it’s doing, elevate privilege modes, and then jump to whatever function handler is stored in the mtvec (machine trap vector) register. Remember, this is the “funnel” where all traps are handled, including our system calls. We have to set up our convention for handling system calls. We can use a convention that already exists, so we can interface with a library, such as newlib. But, let’s make this ours! We get to say what the system call numbers are, and where they will be when we execute a system call. This is part 7 in a long series about writing a RISC-V operating system in Rust.
KnightOS is an operating system I started writing about 10 years ago, for Texas Instruments line of z80 calculators — the TI-73, TI-83+, TI-84+, and similar calculators are supported. It still gets the rare improvements, but these days myself and most of the major contributors are just left with starry eyed empty promises to themselves that one day they’ll do one of those big refactorings we’ve been planning… for 4 or 5 years now. Still, it was a really interesting operating system which was working under some challenging constraints, and overcame them to offer a rather nice Unix-like environment, with a filesystem, preemptive multiprocessing and multithreading, assembly and C programming environments, and more. The entire system was written in handwritten z80 assembly, almost 50,000 lines of it, on a compiler toolchain we built from scratch. The things people can squeeze out of these limited devices astounds me every single time.
Why is Wednesday, November 17, 1858 the base time for OpenVMS (VAX VMS)? Interesting answer for sure.
Lilith is “a POSIX-like x86-64 kernel and userspace written in Crystal”, which only raises the question what Crystal, exactly, is. It’s a programming language whose syntax is “heavily inspired by Ruby’s, so it feels natural to read and easy to write, and has the added benefit of a lower learning curve for experienced Ruby devs”.
Linking to The Verge, because the original report is stuck behind a paywall: Facebook is developing its own operating system that could one day reduce the company’s reliance on Google’s Android, according to a new report by The Information. Development is currently being led by Mark Lucovsky, a Microsoft veteran who co-authored the Windows NT operating system. The report provides a limited amount of information about how the new operating system could be used, but it notes that both Facebook’s Oculus and Portal devices currently run on a modified version of Android. According to one of Facebook’s AR and VR heads, Ficus Kirkpatrick, “it’s possible” that Facebook’s future hardware won’t need to rely on Google’s software, which would reduce or remove entirely the control Google has over Facebook’s hardware. Nope. Nope. Nope. Nope. Nope.
CP/NC is a CP/M-compatible operating system for the Amstrad NC100 Notepad Computer. It is based on Russell Marks’ ZCN operating system, but focuses more on CP/M compatibility and makes the computer “feel” more like an old-fashioned CP/M box. While ZCN is a rather playful system that adopts lots of features and external programs from DOS and Unix, CP/NC goes back to the roots: you will find a rather minimal CCP and the usual external commands, such as DUMP, PIP, STAT, and SYSGEN. CP/NC also changes the layout of the LCD console from 120×10 characters to a more readable 80×8. Here is a summary of what CP/NC is and is not as well as a list of differences between CP/NC and ZCN. This is such an oddly specific operating system.
Seriously, what do you do with your computer? Over time 9front sanded off its rough edges. I can do just about everything I need to do from a bare metal install. Today, we even have vmx(1) for hosting OpenBSD or Linux virtual machines (just in case you need to interface with the U.S. government via the now-required modern web browser). A previous release of the 9front DASH1 manual was created entirely on a ThinkPad running 9front (and Gimp running inside OpenBSD running inside vmx(1)). 9front now even ships with a primitive Microsoft Paint clone, several native Sega and Nintendo emulators, and a full port of DOOM. I never would have dreamed anything like this was possible back in 2009. As time goes by, there is less and less reason to boot anything else. For what I do, I’m perfectly happy with it. Clearly not the most typical user, but that doesn’t make their experiences any less interesting.
webOS OSE 2.1.0 has been released. Since I’m sure not everyone has kept track of where webOS has ended up, this is where we stand today: webOS is a web-centric and usability-focused software platform for smart devices, which has proven its performance and stability in over 70 million LG Smart TVs. Since its adaptation to display products, webOS has come a long way and evolved into a software platform applicable to a broader range of products. The open source project of webOS, called webOS Open Source Edition (OSE), was announced in March 2018 under the philosophy of open platform, open partnership, and open connectivity. On top of the core architecture of webOS, webOS OSE offers additional features that allow extension to more diverse industry verticals. This release seems light on changes, as the release notes illustrate.
When a homeless man was accidentally killed by a train on the 11/08/18 in The Dalles, Oregon, no one realised how many people it would effect. The man was a computer programmer called Terry Davis and he was on a mission from God. He’d designed an entire operating system called Temple OS and according to Terry its creation had been a direct instruction from God himself. As a fellow programmer explained it, ‘you can imagine how over time one man might build a house, but this is like building a sky scraper, on your own!’ And this was all done while Terry battled a diagnosis of schizophrenia. Aleks Krotoski searches the emails, web posts and live streams to piece together the life of a remarkable individual who’s work touched so many and is now celebrated not just as a technological achievement but an artistic one. Davis’ story was a sad one, and partially intertwined with OSNews and the crew here. His behaviour meant we eventually had to ban him from the site, but even after that, then-OSNews editor Kroc Kamen worked with him for an OSNews article.
LegoOS is a disseminated, distributed operating system designed for hardware resource disaggregation. It is an open-source project built by researchers from Purdue University. LegoOS splits traditional operating system functionalities into loosely-coupled monitors and run them directly on disggregated hardware devices. LegoOS also manages distributed resources and handles hardware component failures in a disaggregated cluster. For more information, please check out our recent awarded paper. You can get LegoOS here.
SerenityOS, a UNIX-like OS written from scratch has turned one year old today. The authors have made huge progress and impressively it can now run Doom and render HTML content in its own HTML engine. Be sure to scroll down the page for an overview of the progress that’s been made, including a bunch of screenshots that really show just how fast the project has evolved.
From the obtuse press release: • First and only real-time operating system to support C++17, Boost, Python, and Rust collection of technologies, along with continued support for languages like Ada and SPARK • New LLVM-based infrastructure that enables support for a broad set of modern and productive tools and frameworks • New open source board support packages (BSPs) such as Raspberry Pi and TI Sitara AM65x for quick prototyping and flexibility of choice • OpenSSL 1.1.1 for the most up-to-date cryptography libraries Very informative headline, I know, but VxWorks isn’t exactly a very approachable topic, so I had to make do.
I expect our global supply chain to collapse before we reach 2030. With this collapse, we won’t be able to produce most of our electronics because it depends on a very complex supply chain that we won’t be able to achieve again for decades (ever?). Among these scavenged parts are microcontrollers, which are especially powerful but need complex tools (often computers) to program them. Computers, after a couple of decades, will break down beyond repair and we won’t be able to program microcontrollers any more. To avoid this fate, we need to have a system that can be designed from scavenged parts and program microcontrollers. We also need the generation of engineers that will follow us to be able to create new designs instead of inheriting a legacy of machines that they can’t recreate and barely maintain. This is where Collapse OS comes in. That’s one way to introduce an operating system. This is a very unique project aimed at creating an operating system that can run on microcontrollers and which can self-replicate.
Eventually, that’s going to mean a single software stack common across VW Group’s vehicles—everything from the instrument displays and the infotainment to powertrain and chassis management (think traction and stability control or advanced driver assistance systems), plus a common connected car infrastructure and cloud. However, each brand will still get to develop its own UX in the same way that Porsche and Audi can build very different-looking vehicles from the same MLB Evo toolbox. They’re going to base it on Android, but without much of the Google parts because of privacy concerns (i.e., VW wants that data for itself, not share it with Google). And, as always in the car world, it will be many, many years before this initiative will make its way to VW Group’s cars – the unit won’t be fully staffed until 2025.