What does HackerNews think of nanos?
A kernel designed to run one and only one application in a virtualized environment
[0] https://en.wikipedia.org/wiki/Rump_kernel
[1] https://github.com/nanovms/nanos
[2] https://www.gula.tech/blog/files/135c832f92668268f1e9140a524...
There are also packages available through AUR/homebrew and the like: https://ops.city/downloads .
The script is only there facilitate the 'install' such as ensuring you have qemu installed locally or assessing whether you have kvm/hvf rights/etc.
Also, I don't think this is documented yet but you can target various PRs/builds with ops via this way:
ops run /bin/ls --nanos-version d632de2
Google Cloud is probably the most friendly one for hobby osdev cause they are based on KVM.
For instance when starting with https://github.com/nanovms/nanos (whom I'm with) we targeted the t2 instances first and it actually took a longer time to come up with support for some of the newer t3 instances because we had to add ENA and NVMe drivers.
NanoVMs is building out unikernel tooling and infrastructure. We have open source at https://github.com/nanovms/nanos && https://github.com/nanovms/ops. We can run things like go and rust webservers up to 2x as fast on platforms like google cloud today.
We are specifically looking for more full-time kernel engineers so we can increase our velocity. We are well-funded by great investors and have revenue from extremely large customers.
You can submit here:
or just email me.
This is listed as remote but it's really just corona remote. We have a very strong preference for those who are either in the Bay Area or willing to relocate. We do have an office that we intend to fill up. Second choice would be New York as we have engineers based there as well. We are open for remote anywhere else in the US for now so don't be shy if you're 50 miles from nowhere in WY as long as you have a great internet connection and the mad skills.
We've found some of our great engineers have backgrounds coming from {networking, storage} companies and traditional embedded backgrounds.
For the right candidate we can move extremely fast.
It also runs rust very well.
each closure is a function which takes a number of saved arguments and a number of new arguments. construct a set of macros to define a closure structure. this structure contains a function pointer to the closure, plus all the saved arguments. another macro defines function to take the new arguments and construct a complete call to the handler function with the saved arguments. this solution carries the type information for all the arguments and flags at compile time attempts to call the closure with non-unifying new arguments. this general approach is from Sergei T and is used quite heavily here: https://github.com/nanovms/nanos
dynamically synthesize a function to shift the new arguments to the right in the call, and fill in the saved arguments from immediates. this is faster and application can use normal function calls, but its not type safe. working on a little c->c front end that maintains type safety
these are both really implementations of partial application rather than general closures. they are both heap based which allows them to be used for general callbacks without worrying about lifetime, but they become a big memory management problem.
with the exception of the memory issues - i think c+closures is a great environment for systems programming.