▲ 73 points
back
61 comments
A screenshot from the author's website: https://www.durlej.net/res/vdesktop.png
And not just various existing X11 stuff running on a Unix-like OS. The UI is custom done.
I’m an outsider to os Dev and have never read posix standards or similar but I’m curious if an entirely different operating system would achieve benefits worth the cost of incompatibility. Things like the concept of treating everything as a binary stream (shell output, data transfers etc) seem like a design choice with roots in early computing which doesn’t lend well to complex and secure systems.
An example is that if we move to shells where everything is an object with a toString method for stdout, we would avoid many bash bugs in piped commands or shell scripts. I’m sure many concepts such as file io etc could achieve different but worthwhile benefits if reengineered from a modern perspective, even tcp/ip has its warts (but I’ll acknowledge we will never get away from tcp/ ip).
Am I just a clueless outsider?
No, this idea comes up semi regularly. Honestly Windows does alright for that; not POSIX, very object oriented, has powershell which you should look at.
No, that is how REPL worked on Xerox workstation environments, and was also copied into ETHZ Oberon based workstations.
Nowadays PowerShell is the only experience that ships in the box that is somehow similar to that.
Not only you have structured data, by having first class access to .NET, COM and DLLs, it means any OS API or modules from other applications, are directly accessible for scripting, besides some type declarations.
> we would avoid many bash bugs in piped commands or shell scripts
Food for thoughts: you take a step away from byte-array files. Why stick with the notion of using pipes for composition, or using the same language for the (command-line) UI and for scripting?
Or, for that matter, with a universal "file" concept that tries to treat videos, pictures, executables, application-internal data files, database files and system configuration files the same (even before taking into account Unix's "special files" that aren't persistent, and are just high-level APIs sharing the same low-level APIs as actual files).
> Food for thoughts: you take a step away from byte-array files.
> Or, for that matter, with a universal "file" concept that tries to treat videos, pictures, executables, application-internal data files, database files and system configuration files the same
POSIX and Windows have what are called "stream-oriented" or "bytestream" files – as far as the filesystem is concerned, the file is just an unstructured stream of bytes; applications can require those bytes to be in a certain format, but the filesystem is ignorant of that and won't enforce it.
Many mainframe/minicomputer operating systems support additional types of files – such as record-oriented files, in which a file is divided into records – either fixed length (every record in file must be same size) or variable length (every record is preceded by a header which stores its length in bytes, sometimes also flags). The filesystem forces all reads/writes to be of whole records (or groups of them), partial reads/writes are prohibited. Some also had indexed files, where you basically have a key-value store built into the filesystem, with each record divided into a key and a value, the filesystem had an API to retrieve records by key instead of location in the file; commonly the file was internally structured as a B-tree or hashtable, but that was hidden from applications, the filesystem looked after those details.
The designers of Unix knew about this complexity – they had extensive experience with IBM's OS/360 mainframe operating system which included it – and intentionally decided to avoid it, and give Unix only byte-stream files. The same design choice was made by designers of microcomputer/PC operating systems such as CP/M, MS-DOS and OS/2. Dave Cutler, chief architect of Windows NT, knew all about record-oriented files (OpenVMS has them), but decided against including them in Windows NT.
We can question whether those were the right decisions – or, even if they were the right decisions at the time, they are not guaranteed to forever more remain so.
Personally I think a lot of the warts with Bash are more down to it's "language" design rather than pipes. Things like how $VARIABLES are expanded before a statement is compiled into a argument (which leads to spaces in $VARIABLES breaking things) are entirely fixable and quite a number of alternative Linux/UNIX shells do address those kinds of problems directly.
That all said, I'm not disagree with your point about smarter pipelines (rather than dumb byte streams) would be advantageous too.
The very notion that $PATH is a list encoded as a colon separated string is a hack ;)
I wasn't disagreeing with your point that there are plenty of rough edges. I was just saying that a lot of common problems are really more Bashisms.
Though to address your $PATH point directly, in the literal decades that I've been using Linux and UNIX systems, I can't recall a single time when I've ran into a problem with $PATH values being colon delimited. And the reason it is structured that way is again, to work around a limitation of the shells of that time (ie they didn't support arrays).
Though if we are going to talk about problems with environmental variables then $PATH would be somewhere at the bottom of the list while the structure those values are stored at would be top (you think it's a pain parsing $PATH, trying parsing raw env var "structs" -- I've seen far more bugs introduced there) along with the fact that it was never intended to be secure yet that passing secrets seems to be one of it's primary use cases these days.
I’m also not an OS dev. However, sometimes while cutting, pasting, and grepping my program outputs I’m vaguely jealous of powershell I think they use some sort of objects over there…
You can install PowerShell on Linux now, if you like - or there's nushell: https://www.nushell.sh/
Two big differences between PowerShell (even on Linux) and traditional Unix shells: (1) multithreaded single process architecture, as opposed to multi-process architecture; (2) runs under a VM (.Net CLR) as opposed to native code.
I see nushell is written in Rust, so it doesn't have (2), although I'm less sure about (1).
I think it would be cool if you could add structured pipeline support to traditional Unix tools (bash, coreutils, etc). The problem is, Unix pipes don't have any support for passing metadata (performing content negotiation between the two ends of the pipe). Given they are a facility provided by the kernel, adding that would likely require kernel changes.
One day I started daydreaming about prototyping content negotiation support for Unix pipes. I was thinking of using CUSE (Linux character device driver in userspace) to do it. Never actually got around to trying though, other more pressing things to work on. Maybe some day I will get around with it, or maybe someone else will feel more enthusiastic about that than I do.
It's possible without any kernel changes. My shell (https://github.com/lmorg/murex) already supports doing that.
The way it works is it uses fd3 to communicate schema information so it can natively support all the existing "dumb" pipes without any modification but any new tools can be written to send objects instead (albeit byte encoded).
It's not as elegant as PowerShell sending .NET objects natively, but then PowerShell doesn't work with existing CLI tools natively (it needs wrapper scripts to convert them into PowerShell commands). Whereas my shell is fully backwards compatible while still supporting a suite of additional functionality too.
.NET CLR compiles to native code via JIT, and PowerShell also has support for calling into COM and DLL libraries.
Additionally the way Xerox and ETHZ workstations did their REPLs was native code all the way, as Interlisp, Smalltalk, Mesa XDE, Mesa/Cedar, Oberon, Oberon-2, AOS all had AOT/JIT workflows.
No, many OS devs are converging on a similar idea, myself included.
Being advertised as a "multi-user" OS, I assume this is not meant for me to noodle around at home and maybe share my PC with a few family members. That said, who is the target audience for something like this? The author's website and Github pages are very sparse in details. Is this even meant for other people to use, or is it just a longstanding hobby project?
In hobbyist OS dev, I think "multi-user" just means "I implemented user accounts and file permissions and stuff". Windows, macOS, and Linux are all multi-user operating systems.
>this is a hobby OS
If you don't even know what "multi-user" in a OS context means you should go back to the book's and learn actually something.
The last commit is 5 years ago. Seems like unmaintained.
I’ve often thought it might be time for humanity to take the lessons learned from *Nix and Windows/DOS and come up with something better.
Going by the other projects on the author's site, it looks like their primary goal is working on stuff that interests them, not reinventing operating systems that are older than a lot of the folks on this site.
I realize this is HN, but not everything needs to be an industry disrupter. Honestly, I'm here more for the weird, impractical experiments than anything else.
The problem is that 80% of the better ideas can just be bolted onto the existing systems so we can incrementally upgrade without losing compatibility and having to start from scratch.
Pity that in some platforms, e.g. Windows, what DevDiv incrementally upgrades with .NET, WinDev undoes it with COM and C++.
One of the reasons why we have all this mess with UWP, WinRT, WinUI and WinAppSDK.
They could have followed Android's approach where everyone works together for that incremental upgrade, but alas.
Android and iOS, yes they rely on UNIX like kernel, no they aren't that much exposed to Objective-C, Swift, Java, Kotlin, ISO C and ISO C++ userspace frameworks and APIs, despite UNIX folks thinking otherwise.
Genode OS
SerenityOS
BeOS/Haiku
From Oberon linage, AOS is still around at ETHZ
Inferno
Erlang, Go, Oberon, Java and .NET targeting bare metal workloads where the runtime plays the role of the OS.
And most likely a few others I have forgotten.
Maybe instead of knocking other’s hard work you should get busy doing that then.
OS Dev is a huge undertaking and not for the lighthearted, especially if you intend on having a real project as opposed to a toy.
Someone posted this quote by Linus Torvalds just some days ago:
Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project.
Sometime in order to build the "real projects", you have to learn by building toys.
And redo the decades of work put into the userspace applications for existing operating systems?
Yes.
You could build compatibility layers for porting the most complex stuff, but the idea is that an advanced, better OS would make it trivial to build the most commonly used applications for everyday use, and provide benefits on top of them that would make the switch to the new system worthwhile.
Plan9/9Front is maintained and OpenVMS comes out for x64 ~Mai ;)
You just have to use it.
Isn’t Windows NT the next generation of VMS ( rather than the other way around )?
Well Dave Cutler changed from DEC to Microsoft. VMS is the older system specialized for big servers "fast" networks, clusters and security.
When Cutler went to Microsoft the restrictions where clearly the slow and small PC's (the main customers of MS), so that really "cut" the system down (pun intended). Like the Idea to implement NT as a pure microkernel, but it was just too slow for the normal home PC, and that's why NT is kind of a hybrid.
https://en.wikipedia.org/wiki/Dave_Cutler#Microsoft_(1988_-_...
SerenityOS
The author of the software has some other interesting projects on his poersonal website: www.durlej.net/v/
I'd be interested to know if anyone is using this OS, and for what use case.
Amazing bit of work!
How does it compare to Alpine Linux in size?
Does it have support for Ethernet and USB?
Another multi-user UNIX-like OS clone, maybe it is time to actually explore other ideas?
Nobody is stopping you from doing that.
Thankfully.
Are you working on something like that?
Tangent, I know—but I am reminded of TempleOS, a pretty amazing OS written entirely by the late Terry Davis in his own variant of C. It has some amazing UI innovations and logical abstractions that never caught on elsewhere. Terry was affected by mental illness and used to make a bunch of offensive posts whenever his work came up here on hacker news. Anyone else remember him from here?
You might want to give Zeal:
https://github.com/Zeal-Operating-System/ZealOS
a try. It's 64-bit fork of TempleOS...
Vanadium is the name of the GrapheneOS browser aswell. I was expecting a related project but I'm happy to see more OS pop-up.