That is, rather than use an LLM to generate boilerplate code from an ambiguous natural-language prompt, use a high-level programming language to precisely, concisely, and directly express what you want.
The best reason I can come up with to mimic Cocoa, rather than Win32, is that macOS users are the most... discerning about native versus non-native apps. So a Windows-first app on macOS will certainly be noticed, but that's not as true for a macOS-first app on Windows.
Redox's IPC is a fair bit weaker of a design than that of QNX or my seL4-derived kernel. It works sort of like that of QNX in that it has direct copying of messages between address spaces and RPC-like semantics with direct context switch from sender to receiver and back, but it is more limited and implemented in a slower way. Also, there seems to be no consideration for real-time performance at all.
Outside the core IPC model, the namespace model is also more limited than that of QNX; QNX allows multiple servers of a given type mounted anywhere within a namespace, whereas Redox's scheme-based namespace model only allows a single server of a given type per namespace, mounted on a fixed top-level prefix.
I think elaborate IPC designs are too much trouble, and I favor seL4's "context switch with benefits" approach of delegating larger messages to shared memory. It avoids performance and security hiccups with copying or kernel-mediated shared memory, like in EROS. To be fair, I'm less focused on efficiency and more on simplicity/robustness of the kernel, similar to seL4. Could you elaborate on your thoughts in the IPC space?
I see this was submitted to HN a couple times over the last few years and has not received any comments. Can you describe the goals and status of this project? Does it fit into any larger ecosystem? Is it a research project or intended for eventual mainstream adoption?
I'll start by saying that micro-kernel OS development is a bit beyond my skill set but I can tell you that the goal is more or less to make an open source QNX with features from Plan 9 that is suitable for desktop use and higher level embedded platforms.
I'm not sure what you mean by larger ecosystem but a compatibility layer with Linux binaries is on the feature list. You can read the extremely detailed architecture notes document here[0]
It is absolutely intended for mainstream adoption and the project has recently received interest and funding from a very large OEM. I don't want to say who it is because I am not certain if they want it publicized yet. It's probably okay for me to say but I'm erring on the side of caution.
If you or anyone you know is interested in contributing to the project let me know or reach out to Andrew Warkentin on gitlab.[1]
Basically I'm trying to write a better Linux than Linux and a better QNX than QNX, at least for certain use cases that is. At least initially, my primary focus is on workstation/enthusiast desktops and higher-end embedded systems (some types of servers, especially ones where high security is important, are also a focus as well but maybe not quite as much for now). Pure consumer desktops aren't really much of a priority; the goal is to make something that's approachable but definitely not dumbed down. Almost every day I see people complaining about mainstream OSes and I think there's an opportunity for an OS that's cleaner and more integrated than Linux and has various advanced features not found in Linux, but still tries to maintain a high degree of compatibility with it. I'm not really trying to clone QNX or Linux 1:1, but I am trying to maintain similar enough semantics to allow easy implementation of compatibility layers for both systems.
At the moment I have a working microkernel and an incomplete process server with a partially-implemented VFS but no support for running regular user processes. Currently I am working on some of the first special filesystems built into the process server (specifically an early log/console device at the moment).
The kernel is a hard fork of seL4 (the biggest addition at the moment is a preliminary implementation of QNX-style arbitrary-length arbitrary-address message copying); I've forked it because seL4 is focused on lower-end static embedded systems, and full verification of just the kernel isn't really particularly useful for a dynamic OS when all of the servers are unverified. The process server is written in Rust, and it's likely most of the other low-level servers will be as well, although I'm not really writing a "Rust OS" as such. Many of the basic utilities will most likely be BSD-derived, and some of the higher-level desktop-related stuff may be written in various other languages (haven't completely decided there).
Interesting, but sounds like much more than a lifetime achievement. As far as I understand, it is written in Rust; this raises the question of whether there are significant differences to Redox OS, which seems to share most of the goals. But sel4 on the other hand is written in C; are you going to migrate sel4 to Rust?
Like I said, it's not meant to be a "Rust OS" and will incorporate a lot of C code still (and various other languages as well). I doubt that the kernel will ever get completely rewritten in Rust, although eventually some Rust code might get added (once I break up the giant kernel lock I am thinking I'll use the same locking library I'm using in the process server, so that would add some Rust code to the kernel). I don't see a lot of point to rewriting the kernel since it's probably not going to see lots of new code being added all the time and is generally pretty limited as to what it includes (I'm not quite as reluctant to add stuff to the kernel as the seL4 developers are, but I still am going to try avoiding it unless there's no other good way to do something).
Redox has several of what I consider to be questionable design/implementation decisions. I explained a couple of them in a previous comment (the limited filesystem namespace and IPC models and the lack of real-time support). Some other things include the weak implementation of locking (it uses pure spinlocks instead of something like the adaptive queue-based locking that I'm using in the process server), a rather limited heap allocator that doesn't support growing/shrinking the heap or custom object sizes for slabs (the heap allocator I'm using is a derivative of the same one that Redox uses but it's been heavily enhanced with support for shrinking/growing the heap and custom slab sizes), and the rather boilerplatey implementation of some of the libraries (for example fork() is implemented as a library function that copies process context through a filesystem-based API, but rather than having object-oriented wrappers on top of the filesystem for the various state objects that it's manipulating, the fork() implementation directly invokes open(), read(), and write() a lot).
That's interesting, thanks for the explanations. Which of the many OS text books do you think covers the topics you are confronted with in this projectk best (especially how to implement an efficient microkernel and integrated ipc)?
> I tend to feel that static linking is overrated.
For me, the big win of static linking is startup time. Just mmap the executable and go. No need to slow down the startup process with the very branchy process of resolving and loading DLLs.
That's true, although pre-linking means the bad old days of apps spending most of their time in the dynamic linker during startup are mostly behind us even when a program uses a reasonable number of libraries.
This is the standard response, and I've given it myself, but I refuse to accept that we need all of the bloat of Chromium in order to do internationalization, accessibility, fast high-resolution rendering, etc.
I use a different retro point of reference than josephg, though it happens to involve the same microprocessor. One of my favorite programs as a child was Diversi-Tune, an early music program for the Apple IIGS. It could play and record MIDI, and also show song lyrics, karaoke-style. The total program size is just under 48 KB, including one file that appears to contain configuration data. Granted, that doesn't count the Apple IIGS ROM or the ProDOS 8 operating system. When you add those, the total comes to just under 200 KB (for a ROM version 01 Apple IIGS).
And Diversi-Tune didn't even use all of the ROM. I know this because one of the areas where Diversi-Tune fell short, even by Apple IIGS standards, was accessibility. The documentation for the Textalker GS screen reader specifically called out that the screen reader didn't work with Diversi-Tune because Diversi-Tune didn't use QuickDraw II for text output. Needless to say, Diversi-Tune didn't support modern internationalization either.
But how much code would it really take to implement a modern Diversi-Tune with accessibility, internationalization, and so on? It must be well short of the ~180 MB (and growing) for an Electron binary. Current work on Rust GUIs suggests that the binary size might fall between 5 and 15 MB, depending on which compiler optimizations one chooses. And that's with an advanced GPU-based renderer that compiles shaders at run time. I'm sure it's possible to do better on that front. Of course, that's on top of the OS, but one could easily imagine a sub-500-MB Linux-based OS as the platform. I don't know about memory usage.
Yeah the other reference point I sometimes think about is the old windows IRC client mIRC. mIRC was super fully featured - it supported downloads, scripting (I think it had its own embedded scripting language), colors, and all sorts of other wild things that I never learned to use. It had way more features than modern discord, although it was missing discord's voice chat, video chat and screen sharing. (And it obviously didn't have any of the modern encryption algorithms).
I downloaded it over my 56k modem and if I'm remembering right, the download was around 2-3mb.
Programs like mIRC benefitted a lot from the hundreds of megabytes of Windows libraries that the OS shipped with. These days applications all seem to ship their own copy of every system DLL so they can work on every platform without having to support different APIs. As a result, mIRC only worked on Windows.
If mIRC is all you need, mIRC still works just fine. It's still maintained, so unlike ancient versions of MS Office, you can be reasonably safe while using it!
> Programs like mIRC benefitted a lot from the hundreds of megabytes of Windows libraries that the OS shipped with.
Hundreds of megabytes is overstating it. Windows 98 was 175mb for the entire OS, including the kernel and all included applications. I doubt the windows UI library of the day (winforms, gdi, etc) totalled more than 20mb. (But please fact check!)
And, I don’t think browser engines like electron do ship their own system dlls. Dlls are only relevant on windows - they won’t do you any good on Linux or macOS. And windows always comes with those dlls. I’m pretty sure chrome on windows still makes use of a lot of the underlying windows APIs to render content on webpages in a system-native way. It just has its own layer of heavily custom UI code layered on top.
But yeah, it’s cool that applications like mirc still work. It would definitely be a fun project to make a Spotify client or something in zig using winforms. It would be a fun exercise to make something so small.
Shouldn't developers be the most self-reliant users possible, especially when working with open-source tools? That is, shouldn't we expect that when a developer has a problem, they dive into the code and figure it out on their own?
No, generally developers prefer to request help or work around an issue than dive in and fix it. The activation energy for contributing to an upstream project is high and very few do it.
Developers are support intense because dev tools and platforms get used in a bazillion ways and combinations you can't predict. It's not like a nice consumer app where the user can only press a limited combination of buttons, and test coverage can be quite exhaustive. GUI toolkits are especially a bottomless pit of edge cases and bugs because they have tens of thousands of API methods, enormous numbers of features, they can all be used in combination, they have to run on multiple platforms usually and those platforms also have bugs etc. The support costs of a GUI toolkit are basically unbounded.
no, if I'm using your platform, it's because I really don't want to deal with the stinking pile of abstraction below that. so on the contrary, I would see it as a negative if the abstraction was that leaky.
I think maybe the GP's point is that we should use systems languages, with their focus on efficiency, for things that the OP defines as out of scope, as an antidote to the creeping software bloat that we all like to complain about from time to time.
And let's not forget that Word 97 felt bloated in its day, however fondly we may look back on it now.
reply