With this approach I managed to get to sub-10ms start (to pid1), if you can accept a few constraints there's plenty of room!

Though my version was only tested on Linux hosts

would be interested to see how you do it, how can I connect with you - emotionally?

Start with booze; always works :)

Have played it a few times, it's really good

Thanks!

Working (again) on an offline translator for Android: https://github.com/davidventura/offline-translator

This week I added TTS support, which needed multiple inference pipelines, it was not easy to find models for 50 languages!

At this point, it mostly works as a crude implementation of Google translate+Google lens, but 100% offline and 100% Google-free

This looks really excellent, looking forward to giving it a try, thank you for sharing!

OmniVoice has wide language support.

Niiiiiice, I've been working on something like this, but reducing linux boot time instead of snapshot restore time; obviously my solution doesn't work for heavy runtimes

Says fast, but how fast? Didn't really see any measurements

That's a good shout. I will update/port it back from here - https://github.com/cloud-hypervisor/cloud-hypervisor/pull/78..., but quite fast

TCC is fantastic! Very hackable, easy to compile to WASM for some interesting in-browser compilation

I thought it only targeted x86? What's the point running in a browser?

Would it be cheating to use the kernel's nolibc?

See another comment.

Using nolibc is fine when you compile it together with the kernel.

The parent article is about a C header that you can use to compile your program independently of the source files of the Linux kernel.

Even the presence of the Linux kernel sources on your computer is not enough to enable the compilation of a program that uses directly the syscalls, as the raw sources do not contain any suitable header. You must first compile the kernel with the desired configuration, because header files are selected or auto-generated accordingly. That is enough for nolibc, which lives in the kernel source tree, but it would still be difficult to identify which are the header files that could be used to compile an external program.

Moreover, including Linux header files in your program is an extremely bad idea, because they are not stable. It is frequent that a minor version increase of the Linux kernel breaks the "#include" directives of external programs (such as out-of-tree device drivers), because items are moved between headers or some headers disappear and other headers appear.

That makes sense, I guess this was not a problem for the times I needed nolibc.

I do agree that trying to extract data/logic from linux is a pain -- I've tried a few times to extract some of the eBPF verifier handling, but end up pulling most of the kernel along.

This is really well written, thanks for sharing.

I didn't understand the point of using Unikraft though, if you can boot linux in much less than 150ms, with a far less exotic environment

Hey! Co-founder of Unikraft here.

Unikraft aims to offer a Linux-compatible environment (so it feels familiar) with the ability to strip out unnecessary internal components in order to improve both boot-time/runtime performance and operational security.

Why would you need a memory allocator and garbage collector if you serve static content? Why would you need a scheduler if your app is run-to-completion?

Linux gives you the safety-net of generality and if you want to do anything remotely performant, you by-pass/hack it altogether.

In the article, Unikraft cold-boots in 150ms in an emulated environment (TCG). If it was running natively with virtualization hardware extensions, it can be even shorter, and without the need for snapshots which means you don't need to store this separately either.

Unikraft is cool, I still have it in my 'todo' list to play around with sometime.

Linking the app with the 'kernel' seems pretty nice, would be cool to see what that looks like for a virtio-only environment.

Just wanted to point out that the 150ms is not snapshot based, you can get <10ms for small vms (128MB ram, 2GB ram moves you to ~15ms range), for 'cold' boots.

Security, it isn't only memory footprint.

Which architecture can boot it in 150ms ?!

Boot is a misleading term, but you can resume snapshotted VMs in single digit ms

(and without unikernels, though they certainly help)

You can boot a vm without snapshots in < 10ms, just need a minimal kernel.

I think "in a VM" was elided. It's easy to tune qemu + Linux to boot up a VM in 150ms (or much less in fact).

Real hardware is unfortunately limited by the time it takes to initialize firmware, some of which could be solvable with open source firmware and some (eg. RAM training) is not easily fixable.

Stripping away unused drivers (.config) and other "bloats" can get you surprisingly far.

And most importantly and TFA mentions it several times: stripping unused drivers (and even the ability to load drivers/modules) and bloat brings very real security benefits.

I know you were responding about the boot times but that's just the icing on the cake.

Mostly depends on how bloat correlates to attack surface, but you're right

But 150ms? That's boot time for dos or minix maybe (tiny kernels). 1s sure.

FreeBSD did some work to boot in 25ms.

Source: https://www.theregister.com/2023/08/29/freebsd_boots_in_25ms...

You can do <10ms. I was working to see if I could get it under 1ms, but my best was 3.5ms

for example: https://firecracker-microvm.github.io/

Microvm's

Because it will be slightly faster and you will use less resources? For a lot of use cases that probably does not matter but for some it does.

Thanks for sharing my site!

I've been thinking about building a platform like this for a while, and it was quite fun to build.

Let me know if you have questions or ideas for new exercises.

This is really cool.

Are you planning to add "lessons" related to deployment? For example, using libbcc vs CO-RE?

I wanted to add all kind of exercises, but I'm not sure what's a good way of presenting a deployment exercise.

On libbcc specifically, I'm not sure it's worth it, CO-RE / BTF is where things are heading, and any reasonably new kernel supports it (<5 years old)

Thanks for making this, looking forward trying it out!

Downsizing from a 27" 5k to a 24" 4k, could not find anything besides a new company called JAPANNEXT (they are French)

yeah, I've tried their 24" 4k monitor, was okay, but not great, so returned. 24" is the max size I can tolerate with short-sightedness, but avoid using glasses for the monitor.