razighter777

It's not a vm: It's all namespaces, baby! Unshare one or more of your mnt, pid, net, ipc, uts, user, cgroup, or time namespaces and you have a "container".

Please write like a normal human and put the effort in to type what you want to say. Using AI to make your writing is not only lazy, it's bland, tiresome, and disrespectful of the reader's time.

It's worrying that with no formal and transparent policy framework that the government will be picking winners and losers and stifling innovation.

There's been no public policy, executive order, legislation, or otherwise on this, I wonder if anyone has filed FOIA requests for these decisions or the conversations between the Executive Branch and AI companies.

This syscall overhead isn't as much as you suppose it is; for workloads where the syscall overhead actually makes a difference there are robust low-syscall paths for io/latency sensitive operations with DPDK, io_uring, and futex being a few examples.

And there are robust performant methods on linux for syscall interception/tracing, see seccomp unotify, bpf tracepoints, ftrace.

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

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...