Hacker News Reader

Comment by DblPlusUngood | Hacker News Reader

It sounds you like you asking for more toy OSes.

Supporting POSIX is necessary if the designer wants the OS to run real software.

I'm pretty sure the software that requires an OS that runs POSIX software is sufficiently catered to. You have your Linuxes of every sort of flavor anyone could ever want (ranging from LFS/Gentoo Stage 3/Arch for the tuners and minimalists, to the 'I want to have Docker/git at my OS level' NixOS-esque machines, to the Ubuntu's for the "anything-but-Microsoft" demographic. (Not to mention, your BSDs, your QNX's (+3 or 4 other POSIX RTOS that are well supported in their ecosystem), your AIXes for the DB2's, ... ) It's sufficiently been explored and the need has been catered to.

Pjmlp (correct me if I'm wrong) would rather see exploratory endeavors rather than Yet-another-POSIX-impl. (And for the sake of argument, should that new platform garner steam and you absolutely, 100%, completely and totally need POSIX support! you can get pretty far creating PE/ELF on a non-POSIX OS with an emulation layer with ~3-4% overhead[VMware had a few whitepapers on it, and Unity is a component in production that demonstrates such behavior])

And if he were motivated enough to write a POSIX impl from scratch, while not trivial, it shouldn't be too hard (see: BusyBox, Yocto/Poky, hell, remember the NetBSD days? Any idiot could port to platform foo in a weekend.)

I would rather see designs like Xerox PARC, ETHZ Oberon, Midori and so forth.

There is no value in making clones the C runtime library.

POSIX is just the part of UNIX that was left out of ANSI C, only usable for command line and daemons written in C.

Other language runtimes don't really depend on POSIX.

Do you consider the Xerox Star a toy OS versus what UNIX was capable of doing in 1981?

Do you consider iOS, Windows, ChromeOS, Android, IBM i, z/OS, Unisys MCP toy OSes given their architecture and minimal use of POSIX?

POSIX only defines the necessary to write CLI and daemon software, nothing more.

What I consider real software is a bit more than that.

I never felt the need for POSIX when I am not using C.

My point is simply this: maybe the author wanted to write an OS that he could use on his PC without rewriting all of his programs.

Maybe he did not want to do OS interface research.

Yep, that was my whole point. I'm curious about how much (if any) an improvement there would be by switching an existing OS (namely Linux) to a "more modern" language like D or Rust, which are purported to be better for writing OS kernels. You're not going to find that out definitively by writing a research OS in them; you need to write an actual OS kernel in it, which has a counterpart already written in C, so that you can compare directly.

Writing a research OS in D/Rust seems to me like someone claiming (before Tesla/LEAF were released) "electric motors are better for cars! Electric cars are superior to gas-powered cars!", but then instead of making an electric car that's actually comparable to a gas-powered car, they build an electric tricycle (velomobile) out of mostly bicycle components that weighs 40 pounds and seats one person and has a custom carbon-fiber fairing and a max speed of 30mph. Yeah, it's nice that you can build that, but it doesn't prove the assertion at all, because the vehicles are totally dissimilar and incomparable.

That sounds somewhat defeatist. Taken to it's logical extreme, wouldn't that mean we'll never have anything better than POSIX?

Or are you suggesting more of an 'embrace and extend' thing, where a new OS supports POSIX for backwards compatibility but adds whatever new API(s) and then tries to grow adoption of those slowly?

No, taken to its logical extreme, that means we'll never have anything better than Win32.

Basically, if you want to make an OS that's immediately useful, it has to run software that's available right now. That means either Windows (Win32 or .NET) or POSIX or maybe whatever Mac uses. That's it.

Now of course, you can try to build an OS that has backwards compatibility for one standard and adds a new one. MacOSX did that to an extent to ease the transition from their older version. Windows does that too, supporting multiple APIs (even POSIX at one point).

However, even here, these standards still require an OS to work a certain way underneath, which all current OSes do to a good extent. If you want to do something really, really different, it might not be so easy to build an emulation or compatibility layer. That's just the price of progress; if you want to do a clean-sheet design, you're going to sacrifice compatibility with everything that came before. If you build in backwards compatibility, that's going to limit how different you can be.

Reply on news.ycombinator.com