
Show HN: Bootrino.com – Netboot Run-From-RAM OS's on AWS, Google and Digital Ocean - andrewstuart
https://www.bootrino.com
======
andrewstuart
Hi folks - bootrino author here.

marketing website [https://www.bootrino.com/](https://www.bootrino.com/)

technical documentation [https://doc.bootrino.com/](https://doc.bootrino.com/)

bootrino console
[https://console.bootrino.com/](https://console.bootrino.com/)

bootrino is new and in beta so I'm keen to find people who'd like to give it a
try and let me know if it doesn't work.

Today, bootrino is not for booting unikernels, but that was the original idea.

bootrino lets you netboot Run-From-RAM operating systems on cloud servers, but
the origin of the project goes back a few years ago to when I became
interested in unikernels, and how they might improve security by running only
application code and minimal operating system code on a server. That seemed to
make a great deal of sense to me. If it's not possible to log in to a server
because there is no login system then surely that's got to be alot harder for
hackers to get in. So I fiddled around with unikernels and after significant
pain, got the rump kernel up and running on EC2 (for the first time).

And I thought, "wow that was way too hard". So I set out to build some sort of
application that would make it easy to build unikernel cloud images that would
run on all the common clouds. And along that path I discovered the crushing
pain, inconsistency and sometimes impossibility of building machine images for
the common cloud platforms. I targeted Amazon, Rackspace, Azure, Softlayer,
Google and Digital Ocean. All cloud platforms do machine images differently,
all cloud platforms make it hard and slow and painful, some make it
impossible. So I sat back and scratched my beard and thought "wow, actually
maybe it's not practical to build something that makes it easy to boot
unikernels on all the common clouds".

I can't remember where the idea came from, probably just woke up with it one
morning, but it struck me like lightning "hang on, I don't need to build
machine images for all these cloud platforms". Instead of making a machine
image for each cloud via its own unique process, I realised that every single
cloud vendor boots almost precisely the same version of Ubuntu, and that they
all support some sort of mechanism for providing a startup script to the
instance. I connected this realisation to something I had read recently on
Hacker News describing a way of replacing the operating system of a live
machine with a new operating system
[https://news.ycombinator.com/item?id=13622301](https://news.ycombinator.com/item?id=13622301)
and my head exploded with excitement. Instead of building and uploading
machine images, just use Ubuntu as a bootloader, format the root disk and
replace it with whatever operating system I wanted. A MUCH better approach -
faster, more consistent and guaranteed to work across all the clouds.

So I did alot of technology testing and got it to work - eureka!

The next major shift in the project was that I found that the unikernel
technology wasn't really able to run on the cloud machines, or more correctly,
it was able to run on some cloud machines under some circumstances. And at the
same time I learned alot about embedded systems, Yocto Linux, and Run-From-RAM
operating systems like Tiny Core Linux and Alpine Linux. And I realised that
in fact Linux can be trimmed down so light that it has many of the
characteristics of a unikernel - of specific interest to me is that it is
possible to cut Linux down to not much more than the kernel and the
application code, which makes things very similar to unikernels. Run-From-RAM
Linux is extremely small, fast and can be configured to be quite secure. And I
found that it's a real pain to boot Run-From-RAM operating systems in the
cloud. So the focus of bootrino shifted from unikernels to being more
generalised - bootrino would be a simple way to boot Run-From-RAM operating
systems in the cloud.

Another idea occurred to me which was that the Run-From-RAM operating systems
are so small that it would be possible to put them on web servers and have
bootrino fetch the OS code from any web server along with a shell script
(bootrino.sh) which put a huge amount of control and power into the bootrino
user. My idea was that ll they would need to do is load a shell script onto a
web server, and bootrino could then launch a cloud instance, pull down the
bootrino.sh and there you have it - netboot Run-From-RAM operating systems on
the major cloud platforms.

Along the way I dropped Rackspace (I think it was defeated by AWS and stopped
being developer friendly). I dropped SoftLayer (it's extremely locked down and
does not allow you to reformat your disk any way you want). I also dropped
Microsoft Azure (because it's API and ways of going about doing things were so
annoying I gave up on it).

So anyway thats the back story. If you've got time and inclination to boot up
a Run-From-RAM OS on your cloud then I'd really appreciate to hear from you
how it went so I can fix bugs and clean up documentation. thanks! Andrew
bootrino@gmail.com

~~~
technofiend
Dude, excellent work and what a great epiphany. I remember reading the source
code to an early X terminal project that turned old SUN workstations (and I'm
sure others but that's what I had) into X terminals ala the NCD commercial
device. The code ran the X Window server in place of SunOS's init! I was like
_you can do that?!? Wait of course you can!_ Mind blown.

~~~
andrewstuart
>>Dude, excellent work and what a great epiphany.

Thanks! Yes it's fun to be able to try out new ideas and form them into a
working whole.

------
artellectual
Wow I was just doing research on this exact topic. I’ve been trying to boot
Alpine into RAM from the network, and then run my lxd containers off the
storage drives. So imagine my happiness when I see this.

~~~
andrewstuart
You'll need this link
[https://doc.bootrino.com/alpinelinux.html](https://doc.bootrino.com/alpinelinux.html)

~~~
artellectual
Awesome! much thx!

~~~
andrewstuart
And email me with questions bootrino@gmail.com

------
indigodaddy
So, the issue I see here is that the run-from-ram aspect of this limits the
use cases for the product.

What happens if you want to make changes to files/apps, or are using it as a
webserver in conjunction with an SSG and git/CI, etc.

Anytime you want to update you'd have to update some other code on some other
http server (which in itself is fine), but then, you'd have to reboot your
run-from-ram instance to sync up to your updates/changes (which is the not so
great part, IMO).

Am I correct on this assumption, or could this type of scenario work some
other way that would prevent an instance reboot? I could be way off here, and
only skimmed the bullet points of the website, and that was my first
thought/takeaway.

In any case, this seems to be a great way to essentially package live
environments as a PaaS, with the added full code customization benefit. Really
creative, and hats off to you for thinking of this and providing it for free.
Seems there would be plenty of use cases and needs for something like this!

~~~
wmf
This is probably based on the philosophy of immutable infrastructure where you
never modify a server/VM/container after it has booted; instead you perform a
rolling reboot to a new version. It's less efficient but more reliable.

~~~
andrewstuart
Agreed - the original question is probably best answered via research into
immutable operating system deployment patterns.

Having said that, when bootrino starts a Run-From-RAM Linux instance, it
really is just plain Linux, so how you go about solving the question of
deployment is really entirely up to you.

------
CameronBanga
Why Chrome only? Any Safari support planned?

~~~
andrewstuart
Just because I didn't have time do everything on the todo list and in the end
I had to make the call that the target audience are likely to have Chrome
installed.

It will support all modern browsers in time when I get time to examine why it
doesn't work on other browsers.

~~~
butz
What features are other browsers missing that prevents them to run Bootrino?

~~~
andrewstuart
Nothing at all really that I know of - it _should_ work on any latest version
modern browser - bootrino doesn't do anything special.

But browsers are fickle beasts. It might be only something simple that
prevents it working. If it does not work then I suspect probably because
bootrino uses the web crypto API / subtlecrypto and it wouldn't surprise me if
that doesn't easily work cross browser.

------
aplorbust
There are folks who know much more about rump than I. They read HN and I stand
to be corrected. But the description of bootrino seems like it is has a
misleading definition of rump unikernels. It suggests because a Linux
distribution and a rump kernel can both be made small enough to fit in RAM and
perhap focus on a single application, they are therefore similar. That does
not sound right.

On rump:

"Two different operating modes are explored: 1) a transparent mode, in which
the file system is mounted in the typical fashion by using the kernel code as
a userspace server, and 2) a standalone mode, in which applications can use a
kernel file system as a library. The first mode provides isolation from the
trusted computing base and a secure way for mounting untrusted file systems on
a monolithic kernel. The second mode is useful for file system utilities and
applications, such as populating an image or viewing the contents without
requiring host operating system kernel support. Additional uses for both modes
include debugging, development and testing."

source:
[https://www.usenix.org/legacy/event/usenix09/tech/full_paper...](https://www.usenix.org/legacy/event/usenix09/tech/full_papers/kantee/kantee_html/)

As far as I can see (which is not far), this is quite different from, e.g., a
"trimmed down" Linux kernel plus busybox. For example, I can utilise rump to
mount corrupted filesystems that would otherwise crash the kernel. Maybe I am
missing something here about the comparison.

I applaud the bootrino authors work and struggle against the incompatibilities
between "cloud" hosting providers. Time well spent.

However I have a few alternative thoughts:

If I have an image, in a portable format such as ffs, with a bootloader and a
custom kernel with embedded filesystem that I created myself that is small
enough to fit in RAM, why do I need to bother with "cloud" hosting?

Why do I need to have a hosting provider run Linux (or another OS of the
providers choosing) in order to boot the image when the image has everything
it needs to boot on a wide variety of hardware? Is the reason one that
benefits me in all use cases?

Assuming for whatever reason I am amenable to have my kernels running on the
same computer as other customers software, along with the providers software
running as well, then do I at least get to choose the host OS (e.g., in Xen,
the dom0)? Why not? Even if my kernels run better under an alternative host
OS?

If I have a bootloader that is compatible, e.g., with Xen, and does not
require, e.g., Python or Grub to be used, why do I have to accept the hosting
providers choice of host OS and bootloader?

There is a severe absence of choice and flexibility compared to what I get
outside of the "cloud" hosting market.

What with Spectre and Meltdown, are there good reasons for me to _not_ share a
computer with other customers software and the providers software? What if
there are alternatives to "cloud" hosting that do not involve running other
peoples software on the computer I am using? What if the real advantages of
"cloud" hosting are to _the hosting provider_?

Cloud hosting may not be for everybody. Personally, I have created enough of
these small images to run from RAM that I have lost count, using small sized
USB sticks, SD cards and CF cards to store a. kernels with embedded ramdisks
and b. other stuff I might need before network access. The amount of
configuration I can do is limited only by my imagination, but none of it ever
requires a cloud hosting provider or some web-based "administration console".

I prefer having physical access to dedicated hardware, or paying someone to
access it for me. I am willing to pay more for this peace of mind, but as
others on HN have highlighted repeatedly over the years, many times dedicated
hardware is actually more economical. As always, it depends on what the
customer is doing.

Using "cloud" hosting providers is overkill for own custom kernels, and way
too much hassle. For example, I use ffs for the images and it "just works" on
every computer. The fact that every hosting provider has to have their own
"proprietary" image format is enough to keep me away. That is not user-
friendly.

But, to each her own. This is only one users opinion.

~~~
andrewstuart
>> It suggests because a Linux distribution and a rump kernel can both be made
small enough to fit in RAM, they are therefore similar. That does not sound
right.

It's a good question. Given a unikernel and an extremely trim Linux kernel
plus application code only, what's the practical difference? Does it matter at
any real level if there's 4.5 megabytes of Linux kernel in there?

~~~
BraveNewCurency
_Huge_ difference. It's not the kernel size, it's the interface (ABI).

In a unikernel, the kernel is part of the application (like a library).
Instead of a complex/slow transition from user space to kernel space, you just
call a function.

A unikernel will also know exactly what your application needs (i.e. if you
only use UDP, it doesn't bother including TCP.) It's possible to strip down
the Linux kernel, but it requires a LOT of work (basically, remove something,
then test that your application still works.)

