Live data from Hacker News

LibOS – A library operating system for Linux

lwn.net

51–59 of 59 posts

Re: LibOS – A library operating system for Linux

#51
post #29

Reminded me of that quote: "An operating system is a collection of things that don't fit into a language. There shouldn't be one." --DanIngalls

There are environments that do not have a strong distinction between OS and language. While adored by their users, for some reason they are never very popular. Oberon, Smalltalk and the old Lisp Machines come to mind. (Maybe Forth too, though most "Forth OSes" never tried to do multitasking or even file systems.) I suspect there are anti-network effects holding them back. They support one language and one language on…

Using a standalone Forth is more or less a rejection of the utility of an operating system. My years of using a stand alone Forth for day to day computing instilled in me a deep cynicism when it comes to the complexity of operating systems.

Re: LibOS – A library operating system for Linux

#52
post #29

Earlier quoted context omitted.

There are environments that do not have a strong distinction between OS and language. While adored by their users, for some reason they are never very popular. Oberon, Smalltalk and the old Lisp Machines come to mind. (Maybe Forth too, though most "Forth OSes" never tried to do multitasking or even file systems.) I suspect there are anti-network effects holding them back. They support one language and one language on…

Using a standalone Forth is more or less a rejection of the utility of an operating system. My years of using a stand alone Forth for day to day computing instilled in me a deep cynicism when it comes to the complexity of operating systems.

I've been reading kragen mailing lists where they bootstrap a lot of 'utilities' on metal with asm (using alt keycodes as 'editor', funky). It's very inspiring and relaxing to see how few things you need to start using a computer. It flatten the whole abstraction stack into a thin core.

Re: LibOS – A library operating system for Linux

#53
post #26
post #24

Stupid question: why does the Linux Kernel handle the networking in the first place? Why not implement everything in userspace from the start?

For a number of reasons: - It used to be impossible to implement securely. Until very recently, there was no hardware support for virtualizing the network buffers, which would mean emulating the network hardware in userspace. This would be very slow. - Because even today, many devices don't have the required hardware virtualization support. For example, many (most?) ARM devices. If you give direct DMA access, you mig…

These are valid objections to in-process access to the networking hardware. Not to running the networking stack in user space, in a privileged process.

For the latter, performance concerns would be a bigger issue.

Re: LibOS – A library operating system for Linux

#54
post #40
post #29

Earlier quoted context omitted.

There are environments that do not have a strong distinction between OS and language. While adored by their users, for some reason they are never very popular. Oberon, Smalltalk and the old Lisp Machines come to mind. (Maybe Forth too, though most "Forth OSes" never tried to do multitasking or even file systems.) I suspect there are anti-network effects holding them back. They support one language and one language on…

IIRC the Lisp Machines supported C in addition to the system's dialect of Lisp.

https://en.wikipedia.org/wiki/Genera_%28operating_system%29#...

So that's several variants of lisp, as well as fortran, c, pascal, prolog and ada. Thats pretty much most of the languages in use in the 80s.

Re: LibOS – A library operating system for Linux

#55
post #42
post #40

Earlier quoted context omitted.

IIRC the Lisp Machines supported C in addition to the system's dialect of Lisp.

> IIRC the Lisp Machines supported C in addition to the system's dialect of Lisp. IIRC the Lisp Machines (well, CADR at least) compiled code down to some pretty high-level machine code implemented in microcode. How many standard C idioms could actually be expressed in that kind of code? I'm also not seeing how it would give a speed-up, which is the usual reason to code in C. Was the C compiled to microcode?

The reason for C, Pascal etc. on the Lisp Machine was not speed. There were two reasons:

1) using the Genera development environment, where you could interactively/incrementally develop/debug C

2) using some C/Pascal software on a Lisp Machine. Examples were the MIT X11 server and TeX.

Re: LibOS – A library operating system for Linux

#56
post #24

Stupid question: why does the Linux Kernel handle the networking in the first place? Why not implement everything in userspace from the start?

I like the following interview.

"One could start arguing about it from the historical viewpoint where network packet creation was a holy operation."

https://fosdem.org/2015/interviews/2015-antti-kantee/

Re: LibOS – A library operating system for Linux

#57
post #4

How might this relate to rump kernels and unikernels?

The other closest thing is probably an exokernel, which is essentially a rump kernel with all the of the stuff that's optionally in userspace removed from the kernel. MIT did a lot of experimentation there.

Re: LibOS – A library operating system for Linux

#58
post #10

I have to credit this blog for much of the material I've absorbed over the years, it's been fantastic how much I've learned here. I've always managed to learn something new from articles, all this to say that today is different... I really do not understand this library at all. Could someone explain me different possible uses for this library? What would be the uses of this out of the box?

alright got it, thanks everyone, i'll stay quiet the next time

Re: LibOS – A library operating system for Linux

#59
post #24

Stupid question: why does the Linux Kernel handle the networking in the first place? Why not implement everything in userspace from the start?

Not a stupid question at all. It's kind of like the question why did we have to program computers in Assembler (which was great fun, BTW) and not in high level languages. It wasn't feasible. Assembly coding did continue for quite some time in the interest of performance but once the proverbial turn is taken, there is no looking back. That's where networking is now. What we still call (rigid) "protocols" should and indeed can become freestanding application code See my paper "Tearing Down the Protocol Wall" at https://www.linkedin.com/in/yitzhakbg#background-publication...
Post reply on HN