Skip to content
This repository has been archived by the owner on Feb 28, 2023. It is now read-only.

Doubts about path that Nebulet is taking. #72

Open
lachlansneff opened this issue Sep 9, 2018 · 3 comments
Open

Doubts about path that Nebulet is taking. #72

lachlansneff opened this issue Sep 9, 2018 · 3 comments
Labels
design Design Discussions

Comments

@lachlansneff
Copy link
Contributor

I recently found this comment on hackernews about an envisioned platform that sounded suspiciously similar to nebulet, just having taken a different path early on.

Here's the comment in full:

I think, eventually, the whole stack will get rewritten from the ground up. Someone is going to come up with a minimal OS that can be run on virtual machines that implements LLVM in a provably correct way, the OS hooks will get reimplemented as libraries for all the languages, and over a few years or so the entire cloud infrastructure will simply switch over.

I think we're already half the way there, Amazon Linux is how widely deployed already? The surface area between application logic and OS code is shrinking by the year, once serverless goes mainstream then even application code will start to get rare, pushed to only those specific projects that require human interaction. Everything else is 'mere' computation, something that can be specified purely algorithmically and executed by anything.

The OS will only be relevant in the context of personal computing, the human interface to the machine kingdom which shed those trappings decades ago.

20-30 years down the road I see a translation layer unifying all three major, now solely personal, operating systems, and a fundamental, free software core being driven out, eventually supplanting proprietary development. Apple will do its best to retain tight coupling between their hardware and software, but they'll slowly fade just like Microsoft did as programming itself is revealed to consist of two main activities, intricate UX and comparatively dumb data plumbing, with a small priesthood of hardware driver maintainers / database developers for those who still want to do 'real' programming.

Everybody will be able to code at some level and it'll be amazing.

- vinceguidry


It's food for thought. Should nebulet have taken a different path earlier on? Really, the essential concept here is architecture-independent processing of data. It doesn't matter if nebulet is a microkernel or what it's running on or what the drivers are written in.

It just need to be a platform that you can drop code on that will receive data, process it, and send it back out.

@lachlansneff lachlansneff added the design Design Discussions label Sep 9, 2018
@AleVul
Copy link

AleVul commented Sep 20, 2018

Nebulet doesn't have to be a general purpose kernel, it may not even be specialized for something, all it has to do is to offer the building blocks for its users to create a "specialized" os that does that one thing and it does well.
For example, most of web services are build with n-tier architecture pattern, where there is a layer for presentation, one for business logic and one for database access. This 3 can be separated on 3 machines, since one might need the entire machine resources for each of those. So the user could compile a version of Nebulet for each of those, where the entire machine resource is available to the service.
Embedded systems are also a good target to use Nebulet on, since those are limited in resources and one might need every drop of performance on those, but the current OS'es for embedded system have an user space and thus have to make expensive context switches.

@chpio
Copy link

chpio commented Jun 4, 2019

Everything else is 'mere' computation, something that can be specified purely algorithmically and executed by anything.

Lucet is designed to take WebAssembly beyond the browser, and build a platform for faster, safer execution on Fastly’s edge butt.

-- https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime

So they are already doing that?

there's also WASI that can be made to work on ButtABI, which then runs in my butt.


"specialized" os that does that one thing and it does well.

sound like a unikernel to me.

Embedded systems are also a good target to use Nebulet on

Why? Why would it be more efficient to compile some bytecode (wasm) just-in-time to native machine code? Or are you saying that there should be a nebulet "compiler"/"builder", that can compile one wasm executable ahead-of-time for a specified cpu architecture, so that we end up with a some-sort-of native unikernel?

@AleVul
Copy link

AleVul commented Jun 4, 2019

a nebulet "compiler"/"builder", that can compile one wasm executable ahead-of-time for a specified cpu architecture

that's what i was thinking at the time

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
design Design Discussions
Projects
None yet
Development

No branches or pull requests

3 participants