How about a Unix-like in C#? Get the Unix and .NET folks interested in this stuff.
Even if the OS never leads to anything, maybe the tooling might prove useful. I am sure someone somewhere would have uses for bare-metal GoLang.
Saying that, I really don't think we need any more Unix-like OSes. There are far far too many of those already. There is a huge problem space to be explored here, and there used to be fascinating OSes that did things no Unix-like ever did.
OSes that are by modern standards tiny and simple but explored interesting areas of OS design, and are FOSS, with code out there under permissive licenses:
Plan 9 imposes and enforces considerably more simplicity on C as it is: you can't #include stuff that already has #include statements of its own. The result is a compilation speedup of around 3 orders of magnitude. That would be a benefit to the would-be C replacements too, wouldn't it?
> Yes I know Ada is not a good fit, but there has already been a Unix-like OS entirely implemented in a derivative of Pascal: TUNIS.
Isn't it? There is a very well-developed kernel written in ADA with SPARK and formally verified at that: https://ironclad.nongnu.org
And PASCAL-derived languages were very popular for operating systems in the 80s. To name a few: Apple's LISA OS, DEC's VAXELN, and OBERON. There were others as well that didn't quite make it, like DEC's MICA and Acorn's ARX.
I had a look at the available literature. Many of the ideas are pretty similar to the work of Per Brinch Hansen a decade earlier. Actually the successor of Concurrent Euclid, called Object-Oriented Turing, is pretty interesting, because it is still a Pascal descendant, but supports modules, declarations in the statement flow, OO and concurrent programming. As it seems it's worth a closer look.
Dijkstra famously said that programmers who started with BASIC are "mentally mutilated". But I think this applies a lot more to C and UNIX.
Most of them don't seem to understand how anything substantially different could exist in the world of computing - every other language and operating system is seen as either an inferior copy, or as another layer of abstraction building on top of C and UNIX.
To be fair, he was talking about classic BASIC which didn't even have user defined procedures but just goto and gosub similar to jumps and calls in assembly language. I remember when I started learning Pascal after BASIC on the Apple II and there was so much to unlearn about programming because how you wrote BASIC was so different from any other high level programming language.
Sure. Pascal btw. had a pretty "flexible" goto statement, I would say nearly as flexible as BASIC; Apple ][ Pascal was a bit more structured though. In original Pascal, you could use goto to even jump out of a procedure; Apple Pascal could only jump within a procedure, and only if goto was enabled at all, if I remember correctly.
There are very good kernels written in Ada, like Ironclad[1].
Besides, what's the point of this comment? What if people wanted to write a million more Unix-like kernels in C? Do you think this is bad? Why do you care? If you want, just write your own in whatever language you want, with whatever design you want.
> Why not Plan 9 in Zig, or Hare, or even D?
Because nobody to this point was interested in doing this. It's really that simple.
I agree. the GP's comment has a flavour of "people shouldn't like the things I don't like".
"Make your own kernel" is a thing-in-itself, and "runs on <X> hardware/VM" + "provides <Y>-like API for programs" are tangible, concrete goals to aim for, even if you personally don't like the <Y> API or the architectural choices it implies.
To give an analogy: https://www.nand2tetris.org/ is an amazing learning experience, even though games other than Tetris should and do exist
Personally, I like the AROS project, aiming to provide an operating system that implements the AmigaOS APIs and runs on many architectures, but lots of users are interested in running it on 680x0 Amigas and spiritually-related PowerPC devices: https://en.wikipedia.org/wiki/AROS_Research_Operating_System
It's OK for programmers to write a thing just for the learning experience. If it gains adoptees, that's a happy accident.
> There are very good kernels written in Ada, like Ironclad[1].
Interesting. Thanks.
> Besides, what's the point of this comment? What if people wanted to write a million more Unix-like kernels in C? Do you think this is bad? Why do you care?
Because it seems to me that modern OS design is caught in a deep deep rut, and the "OS in 1000 lines" article that we are discussing is digging that rut even deeper.
Don't repeat the mistakes of the past. Make interesting new mistakes. It's more fun.
OS’s written in Ada included MaRTE OS (open source), Intel’s BiiN system, and the Army Secure Operating System (ASOS) (IIRC).
The Muen Seperation Kernel (muen.sk) is a secure hypervisor written in SPARK Ada.
Ada was designed for low-level programming. It makes sense it does operating systems fairly easily. Parts of them will break its safety features. They can be validated with external tools, though.
Another trick, used in House with H layer, is to wrap the lowest-level parts which you might do in assembly. Build the GC or whatever, too. Then, everything else is in the higher-level language. These data, the lowest-level portions can be specified, verified, and implemented.
What I really wanted from a developer was the i960. Specifically, the version with the object protections. That might be worth buying today for secure, embedded work. If I found the right person, I'd ask them to open-source, or at least dual-license, the i960. For embedded systems, leave it as a RISC-V alternative or port it to RISC-V.
It was. (If you ever see this, thank you again, Mr Buchanan.)
> What I really wanted from a developer was the i960.
Interesting choice!
Given that Intel has a number of distinctive architectures in its historical portfolio, and is in trouble these days due to the competition from Arm and perhaps even RISC-V, I would love to see it do either experimental revivals of some of its architectures, or open up the specs for other ones.
(Someone there must bitterly regret selling off its Arm architecture license cheaply to Marvell; now, Marvell is worth more than Intel itself.)
How about modern die-shrinks of i860 and i960, or even just FPGA versions?
After the DEC/Compaq/HP implosion, Intel also ended owning the Alpha. I would not be at all averse to a resurrected Alpha chip, even if a very low-end chip on some old cheaper process tech.
Die shrinks and Alpha? A man after my own heart on these things! Yes, I recommended both in the past (maybe Schneier’s blog).
Yes, even shrinks to nodes like 180-350nm would be helpful. The older nodes are still more reliable than modern ones due to the physics involved in deep-sub micron. While not power-efficient, both i960 and Alpha would be fast and reliable.
On FPGA’s, that’s a likely use. Crash-safe.org used Alpha ISA in their early prototype. It’s also just easy for experimentation. In security and accelerators, we’re seeing many companies just throw a fat FPGA. Then layer the improvements on it to avoid the NRE cost.
Btw, Alpha had something worth continuing to talk about in new designs: PALcode. From what Alpha people told me, it is in between microcode and kernel code in nature. They can switch to PAL mode to run a series of instructions as an atomic block with more access to internal parts of the CPU. Projects could essentially extend the CPU to make things like secure, context switching or concurrent GC’s easier. They don’t have to open their internals up as much as custom microcode either.
On that note, what I’d really prefer is custom microcode on an open ISA. There were HLL to microcode compilers, at least in academia, that let you synthesize the microcode from HLL algorithms. That would be super-helpful since one could eliminate problematic instructions or add better ones with no hardware changes. Intel could still differentiate on that, too.
The original design did for your CPU what Jesus Christ does for your soul. Keeps it from burning up due to user failures or external attacks. The product can’t guarantee eternal life but others are researching that.
Back to the devices, there’s at least two families of coprocessors: typed, tagged designs like Burroughs B5000 and capability security like CHERI. SAFE was more like Burroughs or even System/38’s object-centered approach. If patents are a concern, one could always just redo B5000 model itself since it’s more secure than any mainstream architecture.
As an industry are we not supposed to be trying to move away from hoary old unsafe C?
Could we not have a hobbyist educational OSes in more of the C replacements?
Drew DeVault wrote Bunnix in Hare, in one month. There's the proof of concept.
How about tiny toy Unix-likes in Zig, Nim, Crystal, Odin, D, Rust, Circle, Carbon, Austral?
How about ones that aren't ostensibly suitable for such tasks, such as Go or Ada?
Yes I know Ada is not a good fit, but there has already been a Unix-like OS entirely implemented in a derivative of Pascal: TUNIS.
https://en.wikipedia.org/wiki/TUNIS
This might need work from skilled expert practitioners first. That's good. That's what experts are for: teaching, and uplifting newbies.
There was a project to do C# on the bare metal.
https://migeel.sk/blog/2023/12/08/building-bare-metal-bootab...
How about a Unix-like in C#? Get the Unix and .NET folks interested in this stuff.
Even if the OS never leads to anything, maybe the tooling might prove useful. I am sure someone somewhere would have uses for bare-metal GoLang.
Saying that, I really don't think we need any more Unix-like OSes. There are far far too many of those already. There is a huge problem space to be explored here, and there used to be fascinating OSes that did things no Unix-like ever did.
OSes that are by modern standards tiny and simple but explored interesting areas of OS design, and are FOSS, with code out there under permissive licenses:
* Plan 9 https://github.com/plan9foundation/plan9
* Inferno https://github.com/inferno-os/inferno-os
* Symbian https://github.com/SymbianSource
* Parhelion HeliOS https://archive.org/details/Heliosukernel
There is already an effort at Plan 9 in Rust:
https://github.com/dancrossnyc/r9
Why not Plan 9 in Zig, or Hare, or even D?
Plan 9 imposes and enforces considerably more simplicity on C as it is: you can't #include stuff that already has #include statements of its own. The result is a compilation speedup of around 3 orders of magnitude. That would be a benefit to the would-be C replacements too, wouldn't it?