Patch for linux kernel adding support for enforcing Landlock rulesets from eBPF. In RFC stage now.

Comments URL: https://news.ycombinator.com/item?id=47394829

Points: 6

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47210246

Points: 1

# Comments: 1

First it's important to clarify "containers" are not an abstraction in the linux kernel. Containers are really an illusion achieved by use of a combination of user/pid/networking namespaces, bind mounts, and process isolation primitives through a userspace application(s) (podman/docker + a container runtime).

OCI container tooling is much easier to use, and follows the "cattle not pets" philosophy, and when you're deploying on multiple systems, and want easy updates, reproducibility, and mature tooling, you use OCI containers, not LXC or freebsd jails. FreeBSD jails can't hold a candle to the ease of use and developer experience OCI tooling offers.

> To solve the distribution and isolation problem, Linux engineers built a set of kernel primitives (namespaces, cgroups, seccomp) and then, in a very Linux fashion, built an entire ecosystem of abstractions on top to “simplify” things.

This was an intentional design decision, and not a bad one! cgroups, namespaces, and seccomp are used extensively outside of the container abstraction. (See flatpak, systemd resource slices, firejail). By not tieing process isolation to the container abstraction, we can let non-container applications benefit from them. We also get a wide breadth of container runtime choices.

It didn't. It made words on the internet.

He was just messing around with $current_thing, whatever. People here are so serious, but there's worse stuff AI is already being used for as we speak from propaganda to mass surviellance and more. This was entertaining to read about at least and relatively harmless

At least let me have some fun before we get a future AI dystopia.

I was excited to hear about the wafer scale chip being used! I bet nvidia notices this, it's good to see competition in some way.

All of the things listed in the blog are personal and technical disagreements, nothing morally reprehensible, no disrespect, nothing that would make anyone want to burn bridges like this.

It's fine to leave a project and to publicize disagreements but this comes across as spiteful.

All the compliants I see tend to be philisophical criticism of systemd being "not unixy" or "monolithic".

But there's a reason it's being adopted: it does it's job well. It's a pleasure being able to manage timers, socket activations, sandboxing, and resource slices, all of which suck to configure on script based init systems.

People complain in website comment sections how "bloated" systemd is, while typing into reddit webpage that loads megabytes of JS crap.

Meanwhile a default systemd build with libraries is about 1.8MB. That's peanuts.

Systemd is leaps and bounds in front of other init systems, with robust tooling and documentation, and despite misconceptions it actually quite modular, with almost all features gated with options. It gives a consistent interface for linux across distributions, and provides a familar predictible tools for administators.

ipv6 is a beautiful protocol, (not perfect, but elegant) with a lot going for it. But the momentum of ipv4 is just too strong.

It's a mess... with no good solution. I tried to turn off ipv4 and github (shame on you) stopped working. But what are we supposed to do? Have the government mandate everyone switch? (oh wait half of US government websites are ipv4 only)

We did this to ourselves...

I listened to the podcast it was interesting.

Gonna throw some questions you may or may not have gotten.

Are special devices like metadata or write-ahead log devices on the roadmap? Or distributed raid / other exotic raid types?

It would be interesting to hear your thoughts on these.

What do you think zfs got right with this and what did they get wrong?