FreeBSD can now boot in 25 milliseconds
theregister.com
theregister.com
I don't think that's correct. While the optimized sorting algorithm is 100x times faster than the old sorting algorithm, it was only a small part of the boot process (2ms), so the boot speed up is only 7%.
450 m/s is 1620 km/h
https://www.youtube.com/watch?v=FYdAT0v4DHs (Scott Manley)
For many simple embedded systems that plug into the wall, the "boot" process will happen in under a millisecond. But it will take considerably longer than that for the voltage levels to stabilize.
The real thing which differentiates these from a PC or phone is that they are not running what we would typically call an OS. They may be running an RTOS (a very simplified OS), but for many of them, as soon as they have stable power, they are off to the races (Just like the home-computers of the 80s. Just plug in and go.)
Of course the definition of "usable" work can be argued over but even a C64 released in the 80s will run your code in less then 10us
1ms is an enormous amount of time. I'm really curious why you would think otherwise
Like I said link a microcontroller that can meet that. 'Usable work' can be as little as adding two half-precision floating point numbers together, and sending it can be any possible method.
From the article, Colin Percival on how Linux does as well. Impressive (though would be good to see other benchmarks to corroborate Colin's).
(Which is an HN comment actually: https://news.ycombinator.com/item?id=37205578.)
But in the cloud it still takes several more seconds more seconds to download the container full of 200 megs of javascript shite from the local docker repo and fire it up before being able to service requests...
Hmm, actually I’m not sure I even understand the whole “serverless” thing that much to be honest.
Running FreeBSD as if it’s a “process” on Linux is interesting in a way but - who does this?
Spinning up additional "servers" in the cloud when you receive many incoming requests. If requests are held in a queue waiting for the new server to start, a fast boot process will reduce the latency for those requests.
> Running FreeBSD as if it’s a “process” on Linux is interesting in a way but - who does this?
Cloud providers run VMs of different customers on the same physical machine. Hypervisors like Firecracker minimize the attack surface (smaller risk of local privilege escalation) and VM overhead (run more instances on one machine).
> We can see a lot of potential uses for microVMs, not just in cloud scenarios. The ability to run a single program built for one OS on top of a totally different OS, without the overhead of running a full emulated environment all the time, could be very handy in all kinds of situations.
Also this is meant to make things easier and cheaper. But they are anything but easier and anything but cheaper compared to non serverless. It also leads to captive customers. But it drives a whole industry of training, consulting and selling AWS services.
A whole bunch of folks have given up on shared operating systems at a security, access control, data governance, and maintainability (reproducibility) level. At least if your goal is to create software for some purpose other than building server infrastructure.
Some of them have decided that if you’re going to want things like database servers and ssh bastions and VPN servers and cache servers et c to live on dedicated machines or VMs for various good reasons anyway… and you let something else trigger your custom code as needed, as distinct processes with maybe a little hot caching, like in old school PHP or CGI or Inetd (remember that?!), why, now it’s looking an awful lot like you don’t really have a reason to manage a server for that at all, if someone else can provide some service to trigger your code under certain circumstances, if your code and your new unit of process isolation (a whole damn OS) can start up fast enough.
Now if you pay for managed versions of all those other 3rd party software packages you use, so you don’t need to hire a couple PostgreSQL experts to make upgrades anything but nail-biting, for example—congrats, you’ve fully reached “serverless” in the “cloud”.
Arguably POSIX doesn't really matter anymore does it? It's Linux or it doesn't matter in a lot of cases (sadly).
Seems like overkill. Sometimes optimal solutions are the available ones, sure, but is no one working on a POSIX exokernel "includeos" like thing?
Yes, it's a summary of that, overall, and I linked to that post in my article. That blog post is by the developer who did the work. Of course it came first: it is the source material!
Did you not even notice that I linked to it and recommended reading it?!
It is a hard line to walk as a journo.
I have discovered, the hard way, that:
* _many_ people can't skim
* but they don't know that they can't
* so they misunderstand and blame the writer
* no matter if you provide links to explain everything, many won't follow any of 'em
* but you _must_ provide citations for every fact or claim
What I try to do is boil down long stuff to shorter punchier summaries, and explain harder tech stuff so non-experts can follow it.
If the reasons for something, or what it means, or why it matters, are not very obvious, I try to explain the whys and wherefores.
But when it's simple, some will complain there's not enough. If it's not simple, some will complain it's too hard. No matter how well referenced, some will argue. Even if it's my direct personal experience, some will tell me I am wrong.
Essentially limited stack and input known to be bounded to reasonable size, along with low complexity of implementation.
And no, AFAIK, as your PC has to wait for hardware to initialize and such. This is for booting VMs.
This is obviously not true.
All seriousness, this is for VM booting right? Not hardware booting.
(I did not write the headline.)
Primary sources are some HN threads, which I linked to, so I am surprised to see it here. That's why I didn't post it.
It's for one very specific VM with one very specific role, which I carefully explained in the article.