[piranna]

Yesterday November 18th it has been released NodeOS 1.0-RC1, a Linux-based operating system build on top of Node.js as userspace and mostly intended for cloud servers and embeded systems.

The best advantages of such a system are performance and memory foot-print, since there are no intermediate layers between the Node.js binary and the Linux kernel making Node.js applications to run almost on the metal, but also making it easier to understand and learn since all the applications are written in Javascript and it's code is easily accesible. It has some particular characteristics that make it different of other OSes, like a build system fully managed by the npm package manager, full unpriviledged access to system devices in a secure way, or the combination of OverlayFS and chroot jails to provide per-user root filesystems, allowing to each of them to create its "own" OS inside NodeOS while being isolated from the other users.

The project was winner on the systems category of the spanish national Universitary Free Software Championship 2014-2015, and it's a participant of the 2015-2016 edition and of the University of Granada Free Projects Championship 2015-2016. Future roadmap includes ARM support and a graphical HTML5-based GUI.

You can download NodeOS source code, build instructions, prebuild ISO images and contribute to its development at https://github.com/NodeOS/NodeOS (pull-request are highly welcome).

P.D.: Thank you to @dang (https://news.ycombinator.com/user?id=dang) by advice me how to publish correctly the message :-)

[jeswin]

I'd love to use it if it can give me sub-second boot times in VM like hyper.sh. My intended use is to execute un-trusted JS on the server.

Having said that, you're going to get challenged on the performance (runtime) statement. In my understanding (correct me if I'm wrong), the layers between the node binary and the kernel will be the same in NodeOS and in other OSes. You'd be able to offer much better start up performance though.

[piranna]

hyper.sh seems to be a Docker images manager, isn't it? When running NodeOS on Docker or vagga (another LXC container mechanism) it boot instantly, and on QEmu or real hardware it doesn't spend more than 3 seconds, mostly only init the Linux kernel.

[BinaryIdiot]

> since there are no intermediate layers between the Node.js binary and the Linux kernel making Node.js applications to run almost on the metal

Isn't this true running node.js on practically any nix platform? What exactly did you do to remove these intermediate layers and what were these layers?

[piranna]

There are no SystemD, ssh server, udev... all these little bits that consume CPU cycles and RAM. In NodeOS Node.js runs directly on top of the Linux kernel, no more.

[BinaryIdiot]

> In NodeOS Node.js runs directly on top of the Linux kernel, no more

It's still not really clear to me what this statement means. Do you mean only node.js and nothing else runs? Surely the "runs directly on top of the Linux kernel" is just hyperbole, right? Unless you are literally compiling Node.js with hooks into the kernel instead of separately but I'm not convinced that would be helpful and would just end up a security risk (though if that's the case I'd love to see benchmarks).

So it sounds like none of the helpers from Linux are present just node.js. I can see the use case just seems incredibly niche.

[coke12]

> since there are no intermediate layers between the Node.js binary and the Linux kernel making Node.js applications to run almost on the metal,

I'd love to see some benchmarks! This sounds really cool.

[piranna]

It's one of the tasks of my bachelor thesis, let's see how it goes! :-)

[anon6_]

Have there been any benchmarks?

I'm all for abstracting the userland out into different languages.

I wish systems like Debian / Ubuntu / Fedora had clear specifications of how they want the interface of their OS to work. Then people could choose to rewrite package managers and other userland utilities in languages they see fit.

Not for real usage, of course, but I always wondered what it'd be like if apt-get we rewritten in rust/golang.