Live data from Hacker News

Bottlerocket: An operating system designed for hosting containers

github.com

71–80 of 121 posts

Re: Bottlerocket: An operating system designed for hosting containers

#71
post #34

Opening line from their announcement blog post: >It is safe to say that our industry has decided that containers are now the chosen way to package and scale applications. Curious how the HN community feels about that statement. Not so much about the truth of the statement but about the fact that containers are becoming the de facto method of packaging applications.

You need to prefix "applications" with "web" or "cloud."

Desktop and mobile is actually where you want containers most. Servers rarely run untrusted or semi-trusted code because everything comes from a trusted source, usually open source, or in house.

But users want to run lots of shady apps, either that they find on random websites or places like the Google Play store.

Re: Bottlerocket: An operating system designed for hosting containers

#72
post #58

Earlier quoted context omitted.

An operating system is not defined only by its kernel. It's kernel + APIs + user land. If one of those components is changed radically, it's indeed a new operating system. That's why Ubuntu and Debian are distinct, even if both are based on Linux.

You're correct. Debian and Ubuntu are technically different operating-systems. Due to the similarity of 'operating-systems' built around the Linux kernel they're typically referred to as 'Linux distributions'. In the context of software development, if you tell someone you're developing a new operating-system you're probably going to conjure up images of writing a new kernel. If you tell people you're developing a ne…

It’s not that simple. I wouldn’t use the word distribution for GUIX, NixOS, Android and several OSes that use the Linux kernel.

Re: Bottlerocket: An operating system designed for hosting containers

#73
post #58

Earlier quoted context omitted.

An operating system is not defined only by its kernel. It's kernel + APIs + user land. If one of those components is changed radically, it's indeed a new operating system. That's why Ubuntu and Debian are distinct, even if both are based on Linux.

You're correct. Debian and Ubuntu are technically different operating-systems. Due to the similarity of 'operating-systems' built around the Linux kernel they're typically referred to as 'Linux distributions'. In the context of software development, if you tell someone you're developing a new operating-system you're probably going to conjure up images of writing a new kernel. If you tell people you're developing a ne…

Exactly. It is yet another Linux distribution added into the list of many, but specifically tied to AWS. But the magic word that changes everything is something called 'Rust' but not what you actually think it is used for in terms of implementation when first looking at the HN title.

> ...a new Linux-based open source operating system that we designed and optimized specifically for use as a container host.

Even the points made for creating this distro was really for stripping out the unnecessary software in a default Linux distro install and to also increase the startup time for the essential userland processes and optimizing the OS from any possible bottlenecks and security pot-holes.

It's a shame really that it is built on top of Linux rather than an actual new Rust operating system by Amazon. I'm not sure why I would use this particular one if it is based on Linux while it also promotes another lock-in opportunity for AWS.

Re: Bottlerocket: An operating system designed for hosting containers

#75
post #68

A link to the actual source code (90% Rust) and README: https://github.com/bottlerocket-os/bottlerocket And here is a post from AWS with more technical details: https://aws.amazon.com/blogs/aws/bottlerocket-open-source-os...

Given that Red Hat recently killed CoreOS, it's great to see new alternatives coming up. I cannot wait to give it a spin!

https://github.com/coreos/fedora-coreos-tracker has some activity, but it's far from robust.

Re: Bottlerocket: An operating system designed for hosting containers

#76
post #34

Opening line from their announcement blog post: >It is safe to say that our industry has decided that containers are now the chosen way to package and scale applications. Curious how the HN community feels about that statement. Not so much about the truth of the statement but about the fact that containers are becoming the de facto method of packaging applications.

As far as I'm concerned, this is an obvious truth. Linux containers are processes with better sandboxing -- who would not want this? As kinks in the kernel support and tech get worked out, and OSs deepen support I can't imagine that it will ever make sense to say something like "I could have run the process with cgroup and namespace isolation but I chose not to, choosing to make a new user-level isolation or run ever…

The runtime and packaging format are orthogonal things .

Containers the package format (docker) is completely rubbish in my opinion

Re: Bottlerocket: An operating system designed for hosting containers

#77
post #16

Earlier quoted context omitted.

The update system is image-based; when an update is downloaded, it's written out to an alternate set of partitions, and then it can flip over to those partitions with a reboot. That makes it easy to roll back with the same kind of single flip, too. It's different than filesystem-level rollbacks because it's all-or-nothing, so you don't have to worry about update failures after a few packages, and because all of the c…

How does this compare to something like nix or Fedora Silverblue?

Nix has upside that you just need to flip a symlink to do the same . Downside is that you don't have thinks like dm-verity that can prove that your update wasn't tampered with.

In nix the nix store is remounted over itself read-only, but nothing stops someone from ripping out the disk and flipping bits. This is not possible with these kind of 2-partition schemes if you have dm-verity set up

Re: Bottlerocket: An operating system designed for hosting containers

#78
post #9

Earlier quoted context omitted.

Glad you're enjoying them! We have a glossary just in case: https://github.com/bottlerocket-os/bottlerocket/blob/develop... (my personal favorite is Laika, the first dog in space and our pre-init binary)

Honestly, reading the glossary gives me Urbit [1] vibes :( > bork: A setting generator called by sundog to generate the random seed for updog, determining where the host falls in the update order. [1]: https://urbit.org/docs/glossary/

Agree. It's cool so long as the number of names is small, and the names actually are a pun on the function and not just e.g. names of planets. If "updog" is what brings something "up" that's a good name.

WiX (windows installer creation) has a multi-phase command line interface where the compiler/linker/.. has different names indicating the order they are applied: candle, light, smoke... Also a working system I guess.

Re: Bottlerocket: An operating system designed for hosting containers

#79
post #18

Their take on using cargo for packaging is quite interesting: https://github.com/bottlerocket-os/bottlerocket/tree/develop...

They are using tradicional RPM for packaging. The cargo.toml workspaces relates more to make IMHO.

Wouldn’t something like Bazel make more sense? Using cargo to track inter-dependencies seems a bit weird to be honest.

Re: Bottlerocket: An operating system designed for hosting containers

#80

Earlier quoted context omitted.

You need to prefix "applications" with "web" or "cloud."

Desktop and mobile is actually where you want containers most. Servers rarely run untrusted or semi-trusted code because everything comes from a trusted source, usually open source, or in house. But users want to run lots of shady apps, either that they find on random websites or places like the Google Play store.

It's also the rare case where you can't accept a 5% performance hit because that's 5fps in a game or 5 seconds on a 100 second render time or 5ms instead of 95ms wait in an interactive app.

I find that the key to running desktop OS/apps is never use sensitive data and always be ready to wipe your machine and start over.

Post reply on HN