Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inferno Operating System

en.wikipedia.org

Post reply on HN
Print view View original

81–90 of 102 posts

Re: Inferno Operating System

#81

Post by adam_gyroscope »

fit2rule wrote: post #60
adam_gyroscope wrote: post #42

Back when I was in university we had a small course on Limbo/Inferno because of a connection my university (RIT) had to bell labs. I took the course in... 1998? and wrote a version of Tetris for limbo. The code was awful, but did find a bug in the Tk implementation. This lead me to my proudest/most embarrassing programming moment - apparently, my code ended up in front of Dennis Ritchie, who thought the code was terr…

Is that your Tetris in the screenshot?

So, I think so but can’t prove it. In 1998 I didn’t really understand open source licensing so who knows where that code went.

Re: Inferno Operating System

#82

Post by soganess »

panpanna wrote: post #4

In reality, this was an attempt to turn Plan 9 into a commercial product. Plan 9 despite it's crazy UI (the shell and editor have been ported to Linux so some people must have liked it) brought a lot of new ideas which eventually found their way into other projects such as Linux containers and Go (for obvious reasons). One really good idea that died with Plan 9 was transparent distribution of CPUs across the network.…

legoos.io

"fully" distributed resources; memory, cpu, storage, what have you...

"LegoOS is a disseminated, distributed operating system designed for hardware resource disaggregation. It is an open-source project built by researchers from Purdue University. LegoOS splits traditional operating system functionalities into loosely-coupled monitors and run them directly on disggregated hardware devices."

Re: Inferno Operating System

#83

Post by ori_b »

jstimpfle wrote: post #78
ori_b wrote: post #51

Earlier quoted context omitted.

> Linux lacks a lot of core abstraction properties No, it's worse than that: It has too many of them, leading to a mess of special cases that you have to deal with. What happens when you have a socket in your file system, and you export it over NFS? Lacking abstraction properties is fixable -- you can add them. But removing them, especially if they're widely used, is incredibly hard.

Making good abstractions is hard. On Unix I sometimes wish I could unwrap the stream abstraction, but nevertheless I think it is one of the few abstractions that have really stood the test of time. Why wouldn't a a socket exported over NFS just work seamlessly?

Because it's a kernel data structure thing that exists in the file system. The remote machine doesn't have access to it.

Re: Inferno Operating System

#84

Post by jstimpfle »

ori_b wrote: post #83
jstimpfle wrote: post #78

Earlier quoted context omitted.

Making good abstractions is hard. On Unix I sometimes wish I could unwrap the stream abstraction, but nevertheless I think it is one of the few abstractions that have really stood the test of time. Why wouldn't a a socket exported over NFS just work seamlessly?

Because it's a kernel data structure thing that exists in the file system. The remote machine doesn't have access to it.

That's true for regular files as well.

Re: Inferno Operating System

#85

Post by ori_b »

jstimpfle wrote: post #84
ori_b wrote: post #83

Earlier quoted context omitted.

Because it's a kernel data structure thing that exists in the file system. The remote machine doesn't have access to it.

That's true for regular files as well.

No, the remote machine has access to file structures via NFS, which is complicated enough.

NFS doesn't have protocol-level special cases for forwarding operations for the local sockets, handling setsockopt(), various socket ioctls -- which, mind you, are often machine specific, where the data sent in ioctl is ABI dependent. I'm not even sure how you'd do that sort of thing, since NFS is a stateless protocol.

And then you would need to repeat the exercise for these special cases for all of the other special types of node, like /dev. What does it even mean to mmap the video memory of a video card on a remote machine?

And then you'd need to fix the assumptions of all the software that assumes local semantics ("the connection doesn't drop, and poll() is always accurate").

On top of that, you'd need to run on a treadmill to add support for new ioctls.

Do you really want to implement the server side of a protocol that can handle all of the complexity of all you can do on all file systems, with all ioctls, across all node types? How many implementations providing resources via this protocol do you think would exist?

Re: Inferno Operating System

#86

Post by mortdeus »

inferno is cool because it takes a lot of great ideas Ken and rob pike came up with for plan9 to address unfixable architectural flaws inherent to Unix's overall design, and basically makes an vm based portable OS/userland that is everybit what Java could have been.

And then of course Rob Pike, Russ Cox, Ken took what they learned from their background at Lucent and paired it with Robert Griesmers background in developing innovative VMs for Javascript and Java and they essentially put everything they learned to develop the Go programming language.

Which if you get into the architectural aspects of it. You know actually dig into how it's implemented deep down you will see a lot of code that is essentially derived from plan9 and inferno's code in many ways.

Re: Inferno Operating System

#87

Post by jstimpfle »

ori_b wrote: post #85
jstimpfle wrote: post #84

Earlier quoted context omitted.

That's true for regular files as well.

No, the remote machine has access to file structures via NFS, which is complicated enough. NFS doesn't have protocol-level special cases for forwarding operations for the local sockets, handling setsockopt(), various socket ioctls -- which, mind you, are often machine specific, where the data sent in ioctl is ABI dependent. I'm not even sure how you'd do that sort of thing, since NFS is a stateless protocol. And then…

What does it mean to mmap a file on an NFS server? Isn't it a connection drop when a local process dies, too? What happens when a disk is suddenly removed?

> On top of that, you'd need to run on a treadmill to add support for new ioctls.

Absolutely, it'd be a lot of work. So it's a better idea to not implement many of these things and instead simply return an error.

Re: Inferno Operating System

#88

Post by ori_b »

jstimpfle wrote: post #87
ori_b wrote: post #85

Earlier quoted context omitted.

No, the remote machine has access to file structures via NFS, which is complicated enough. NFS doesn't have protocol-level special cases for forwarding operations for the local sockets, handling setsockopt(), various socket ioctls -- which, mind you, are often machine specific, where the data sent in ioctl is ABI dependent. I'm not even sure how you'd do that sort of thing, since NFS is a stateless protocol. And then…

What does it mean to mmap a file on an NFS server? Isn't it a connection drop when a local process dies, too? What happens when a disk is suddenly removed? > On top of that, you'd need to run on a treadmill to add support for new ioctls. Absolutely, it'd be a lot of work. So it's a better idea to not implement many of these things and instead simply return an error.

> What does it mean to mmap a file on an NFS server?

It means you have issues around synchronization and performance, if you use it as anything other than a private read only mapping.

And some things are just impossible, like a shared memory ringbuffer. Which is exactly what you do with the memory you mmap from a video card: submit commands to the command ringbuffer.

> So it's a better idea to not implement many of these things and instead simply return an error.

And now you need to start writing multiple code paths in user code, testing which calls work and which don't, one of which will be broken due to lack of testing. And when you guess wrong at the needed operations, software often goes off the rails instead of failing gracefully. Failure modes like blindly retrying forever, or assuming the wrong state of the system and destroying data.

Too many complicated abstractions break the ability to do interesting things with a system. It's death by a thousand edge cases.

On plan 9, you have 9p.

https://9p.io/magic/man2html/5/0intro

That, and process creation/control/namespace management, are the only ways to do anything with the system. There are few edge cases. Implementing a complete, correct server is a matter of hours, not weeks.

Re: Inferno Operating System

#89

Post by giancarlostoro »

adam_gyroscope wrote: post #42

Back when I was in university we had a small course on Limbo/Inferno because of a connection my university (RIT) had to bell labs. I took the course in... 1998? and wrote a version of Tetris for limbo. The code was awful, but did find a bug in the Tk implementation. This lead me to my proudest/most embarrassing programming moment - apparently, my code ended up in front of Dennis Ritchie, who thought the code was terr…

I'm a little weirded out cause I can't view any of the files or download, either it's a bug you found on GitHub (ha!) or it's a permissions thing? I came here for code, and got bugs... hah

Re: Inferno Operating System

#90

Post by jstimpfle »

ori_b wrote: post #88
jstimpfle wrote: post #87

Earlier quoted context omitted.

What does it mean to mmap a file on an NFS server? Isn't it a connection drop when a local process dies, too? What happens when a disk is suddenly removed? > On top of that, you'd need to run on a treadmill to add support for new ioctls. Absolutely, it'd be a lot of work. So it's a better idea to not implement many of these things and instead simply return an error.

> What does it mean to mmap a file on an NFS server? It means you have issues around synchronization and performance, if you use it as anything other than a private read only mapping. And some things are just impossible, like a shared memory ringbuffer. Which is exactly what you do with the memory you mmap from a video card: submit commands to the command ringbuffer. > So it's a better idea to not implement many of t…

> like a [remote] shared memory ringbuffer.

Technically just as possible, only very slow... Performance is abstracted out by the VFS. You need to stay sane through other measures, like having your software configured right, etc.

> And now you need to start writing multiple code paths in user code

I don't think the number of paths is increased. Any software should handle calls that fail - if only by bailing out. That's acceptable for any operation that just can't complete due to failed assumptions - whether it's about file permissions or that the resource must be "performant" / not on an NFS share, etc.

> 9p.

Now what is the point? How's that different or better? They actually are much more into sharing resources over the network... which means less possible assumptions about availability/reliability/performance. I doubt they can make the shared ringbuffer work better.

Post reply on HN