LibOS – A library operating system for Linux • Hacker News Board

Re: LibOS – A library operating system for Linux

#41

Post by justincormack » Wed, Mar 25, 2015, 9:40 AM UTC

keenerd wrote: post #29

agumonkey wrote: post #14

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…

We are getting there with the rump kernel (rumpkernel.org). It now runs PHP, Lua, LuaJIT, C, C++. This is very much work in progress and it is not particularly user friendly, but it is improving rapidly. I plant to look at Go soon, which has built in syscall traps, which need replacing with library calls. There are a whole bunch of environment assumptions, like existence of dynamic linkers, build systems and so on that need to be worked around.

OSv is another option, it makes life easier by supporting Linux binaries modified to be dynamic libraries, and runs several languages too, although it was initially mainly targeted at JVM languages.

Re: LibOS – A library operating system for Linux

#42

Post by cbd1984 » Wed, Mar 25, 2015, 10:32 AM UTC

draven wrote: post #40

keenerd wrote: 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.

> 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?

Re: LibOS – A library operating system for Linux

#43

Post by eps » Wed, Mar 25, 2015, 10:33 AM UTC

agashka wrote: post #12

eps wrote: post #11

Earlier quoted context omitted.

You have a very peculiar comment history - https://news.ycombinator.com/threads?id=agashka

thanks for bringing that up! Adobe air, bitcoins, and signals. I still don't really get signals, but I'd like to understand this library lol

Why are you thanking me?

Re: LibOS – A library operating system for Linux

#44

Post by agumonkey » Wed, Mar 25, 2015, 10:49 AM UTC

cbd1984 wrote: post #42

draven wrote: 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?

I think pjmlp showed some Lisp Machine bytecode and it was indeed taylored to lisp, and impractical for C semantics.

Re: LibOS – A library operating system for Linux

#45

Post by jrk_ » Wed, Mar 25, 2015, 10:53 AM UTC

My first thought was that this sounds like an idea taken from microkernels. Is this a correct analogy? Would it be sufficient to use libos and fuse to call the Linux kernel a microkernel? What would be missing?

Re: LibOS – A library operating system for Linux

#46

Post by icebraining » Wed, Mar 25, 2015, 11:12 AM UTC

agumonkey wrote: post #31

keenerd wrote: 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…

a CLR on metal ? I know all these names, unfortunately only by reading and not by experience. Some lispers are also keen on bypassing OS interface and emit binary code on the go.

Microsoft has already put CIL on metal, using Bartok¹. They used that to build a whole OS, called Singularity².

¹http://en.wikipedia.org/wiki/Bartok_%28compiler%29

² http://en.wikipedia.org/wiki/Singularity_%28operating_system...

Re: LibOS – A library operating system for Linux

#47

Post by icebraining » Wed, Mar 25, 2015, 11:13 AM UTC

nightcracker wrote: post #32

keenerd wrote: 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…

A native JVM system?

The JVM can go even lower: http://en.wikipedia.org/wiki/Java_processor

Re: LibOS – A library operating system for Linux

#48

Post by Millennium » Wed, Mar 25, 2015, 11:24 AM UTC

jrk_ wrote: post #45

My first thought was that this sounds like an idea taken from microkernels. Is this a correct analogy? Would it be sufficient to use libos and fuse to call the Linux kernel a microkernel? What would be missing?

My first thouvht on hearing the name "libOS" was that someone had gotten Linux running on an exokernel, which is in some ways a variation on the microkernel theme.

Linux on a microkernel has been done before. The MkLinux projext is one example, though it also doubled as a port to PowerPC. I haven't heard of any exokernel attempts, though.

Re: LibOS – A library operating system for Linux

#49

Post by tachyonbeam » Wed, Mar 25, 2015, 11:32 AM UTC

cbd1984 wrote: post #42

draven wrote: 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?

No reason you can't compile C down to that. It's just that there will be less of a clear performance advantage for C as some of the semantics will be slightly awkward to map to that instruction set.

You might still get a speedup by writing C in some areas, but I think the real reason for supporting it is that you have a bunch of legacy software and drivers written in C, and it's easier to get a C compiler working on that platform than to port all that software.

Re: LibOS – A library operating system for Linux

#50

Post by anttiok » Wed, Mar 25, 2015, 11:38 AM UTC

jrk_ wrote: post #45

My first thought was that this sounds like an idea taken from microkernels. Is this a correct analogy? Would it be sufficient to use libos and fuse to call the Linux kernel a microkernel? What would be missing?

For one, the microkernel would be missing ;)

More seriously though, you're absolutely right in that it's a step in the direction of an "optional" microkernel architecture. That's actually how rump kernels on NetBSD started: running the kernel file system driver as a library in userspace on top of a FUSE-like subsystem. It's pretty useful functionality, since it allows you to handle untrusted file system images safely in userspace, while not imposing performance penalty on the trusted images which can be handled by the same driver running in the kernel. Unlike with FUSE-specific drivers, you don't run into issues with unsymmetric driver support in userspace vs. kernel.