6 ms·

VanadiumOS: Portable, multi-user Unix-like OS

73 points by nateb2022 4y ago

xx__yy 4y ago
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!
hsbauauvhabzb 4y ago
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?
- bee_rider 4y ago
  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…
  - dflock 4y ago
    You can install PowerShell on Linux now, if you like - or there's nushell: https://www.nushell.sh/ https://www.nushell.sh/
    - skissane 4y ago
      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.
      - hnlmorg 4y ago
        It's possible without any kernel changes. My shell (https://github.com/lmorg/murex 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.
        skissane 4y ago
        Interesting idea. Although I worry about relying on fd3, it seems like it could be a bit fragile. An executable might have a bug in its file descriptor management which only gets triggered when it inherits an extra fd. The developers might never notice because they never run it under your shell, and then someday some user does. An idea I've had before: the shell should listen on a Unix domain socket, and put the path to that in an environment variable. Then commands could talk to the shell which invoked them. That could be used for this kind of content negotiation stuff. It could also be used to do other things – for example, a subprocess could modify the current directory of the user's shell, or its environment – there are scenarios in which being able to do that would be useful. A Unix domain socket path in an environment variable seems less likely to cause unexpected issues than inheriting an extra file descriptor.
- yjftsjthsd-h 4y ago
  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.
- junon 4y ago
  No, many OS devs are converging on a similar idea, myself included.
- moring 4y ago
  > 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).
  - skissane 4y ago
    > 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.
- pjmlp 4y ago
  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.
- hnlmorg 4y ago
  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.
  - hsbauauvhabzb 4y ago
    The very notion that $PATH is a list encoded as a colon separated string is a hack ;)
    - hnlmorg 4y ago
      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.
skrowl 4y ago
How does it compare to Alpine Linux in size?
yuppie_scum 4y ago
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.
- LastTrain 4y ago
  Maybe instead of knocking other’s hard work you should get busy doing that then.
  - junon 4y ago
    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.
    - _zzaw 4y ago
      Sometime in order to build the "real projects", you have to learn by building toys.
      - junon 4y ago
        Yes, that's obvious. But to construct a real OS intended for adoption and production use is a huge undertaking.
        _zzaw 4y ago
        It certainly is. I think what's bothering LastTrain, though—and is definitely bothering me—is the kneejerk dismissal of personal projects because they're not sufficiently innovative/useful/etc. As far as I can tell, it wasn't even the VanadiumOS author who shared it here in the first place. I've noticed, and I'm not the only one, that HN has developed a particular reputation in the tech community. A number of people I know don't actually like having their work show up on "the orange site" because of that Comic-Book-Guy culture. Just seems counter to the spirit of hacking to judge somebody's experiments through the lens of a VC pitch.
xeeeeeeeeeeenu 4y ago
A screenshot from the author's website: https://www.durlej.net/res/vdesktop.png https://www.durlej.net/res/vdesktop.png
- tyingq 4y ago
  And not just various existing X11 stuff running on a Unix-like OS. The UI is custom done.
- deleted 4y ago
  [deleted]
nerdponx 4y ago
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?
- forgotpwd16 4y ago
  >this is a hobby OS https://github.com/p-durlej/newsys#api https://github.com/p-durlej/newsys#api
- nix23 4y ago
  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.
- csande17 4y ago
  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.
jacob019 4y ago
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?
- anta40 4y ago
  You might want to give Zeal: https://github.com/Zeal-Operating-System/ZealOS https://github.com/Zeal-Operating-System/ZealOS a try. It's 64-bit fork of TempleOS...
worldsavior 4y ago
The last commit is 5 years ago. Seems like unmaintained.
pjmlp 4y ago
Another multi-user UNIX-like OS clone, maybe it is time to actually explore other ideas?
- Narishma 4y ago
  Nobody is stopping you from doing that.
  - pjmlp 4y ago
    Thankfully.
    - Narishma 4y ago
      Are you working on something like that?
morjom 4y ago
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.
- deleted 4y ago
  [deleted]
JPLeRouzic 4y ago
Does it have support for Ethernet and USB?

73 points by nateb2022 4y ago

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!

hsbauauvhabzb 4y ago

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?

bee_rider 4y ago
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…
- dflock 4y ago
  You can install PowerShell on Linux now, if you like - or there's nushell: https://www.nushell.sh/ https://www.nushell.sh/
  - skissane 4y ago
    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.
    - hnlmorg 4y ago
      It's possible without any kernel changes. My shell (https://github.com/lmorg/murex 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.
      - skissane 4y ago
        Interesting idea. Although I worry about relying on fd3, it seems like it could be a bit fragile. An executable might have a bug in its file descriptor management which only gets triggered when it inherits an extra fd. The developers might never notice because they never run it under your shell, and then someday some user does. An idea I've had before: the shell should listen on a Unix domain socket, and put the path to that in an environment variable. Then commands could talk to the shell which invoked them. That could be used for this kind of content negotiation stuff. It could also be used to do other things – for example, a subprocess could modify the current directory of the user's shell, or its environment – there are scenarios in which being able to do that would be useful. A Unix domain socket path in an environment variable seems less likely to cause unexpected issues than inheriting an extra file descriptor.
yjftsjthsd-h 4y ago
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.
junon 4y ago
No, many OS devs are converging on a similar idea, myself included.
moring 4y ago
> 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).
- skissane 4y ago
  > 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.
pjmlp 4y ago
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.
hnlmorg 4y ago
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.
- hsbauauvhabzb 4y ago
  The very notion that $PATH is a list encoded as a colon separated string is a hack ;)
  - hnlmorg 4y ago
    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.

skrowl 4y ago

How does it compare to Alpine Linux in size?

yuppie_scum 4y ago

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.

LastTrain 4y ago
Maybe instead of knocking other’s hard work you should get busy doing that then.
- junon 4y ago
  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.
  - _zzaw 4y ago
    Sometime in order to build the "real projects", you have to learn by building toys.
    - junon 4y ago
      Yes, that's obvious. But to construct a real OS intended for adoption and production use is a huge undertaking.
      - _zzaw 4y ago
        It certainly is. I think what's bothering LastTrain, though—and is definitely bothering me—is the kneejerk dismissal of personal projects because they're not sufficiently innovative/useful/etc. As far as I can tell, it wasn't even the VanadiumOS author who shared it here in the first place. I've noticed, and I'm not the only one, that HN has developed a particular reputation in the tech community. A number of people I know don't actually like having their work show up on "the orange site" because of that Comic-Book-Guy culture. Just seems counter to the spirit of hacking to judge somebody's experiments through the lens of a VC pitch.

xeeeeeeeeeeenu 4y ago

A screenshot from the author's website: https://www.durlej.net/res/vdesktop.png https://www.durlej.net/res/vdesktop.png

tyingq 4y ago
And not just various existing X11 stuff running on a Unix-like OS. The UI is custom done.
deleted 4y ago
[deleted]

nerdponx 4y ago

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?

forgotpwd16 4y ago
>this is a hobby OS https://github.com/p-durlej/newsys#api https://github.com/p-durlej/newsys#api
nix23 4y ago
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.
csande17 4y ago
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.

jacob019 4y ago

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?

anta40 4y ago
You might want to give Zeal: https://github.com/Zeal-Operating-System/ZealOS https://github.com/Zeal-Operating-System/ZealOS a try. It's 64-bit fork of TempleOS...

worldsavior 4y ago

The last commit is 5 years ago. Seems like unmaintained.

pjmlp 4y ago

Another multi-user UNIX-like OS clone, maybe it is time to actually explore other ideas?

Narishma 4y ago
Nobody is stopping you from doing that.
- pjmlp 4y ago
  Thankfully.
  - Narishma 4y ago
    Are you working on something like that?

morjom 4y ago

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.

deleted 4y ago
[deleted]

JPLeRouzic 4y ago

Does it have support for Ethernet and USB?