The brilliance of the McMaster-Carr website is best appreciated when viewed alongside the print version of the McMaster-Carr catalog. As a child, I literally grew up on that bright yellow book, since my parents used it as my booster seat for the kitchen table. It is a thick tome, second only to the thinner Grainger catalog, which became the next booster seat after a few years.

TIL finite state transducers. The BurntSushi blog post is now in my browser tab queue. Thanks!

The premise is good, but the linked article is too short to explain why protocols encourage decentralization, which protects against authoritarism, censorship, and promotes bona-fide free speech (not to be confused with “BuH mAh FrEe SpEeCH!” morons that only like free speech when it agrees with them and don’t when it doesn’t).

For a more lengthy discussion, which includes Internet history, the legacy of the USA’s Section 230 of the CDA and how that impacts the modern web, and what precisely a protocol should avoid doing to successfully achieve the goal of practical decentralization, Mike Masnick’s 2019 paper “Protocols, not Platforms” is particular apt.

Yes, I know I’ve mentioned him a number of times in my comments, but there aren’t too many people who are abreast of technologcal history, the legal framework surrounding the internet, and are skilled writers to condense into words the necessary clarity upon which to build an internet that works for everyone, not just the rich or few.

As a note, BlueSky was directly inspired by his paper and he now sits on the board of BlueSky. Is that antithetical to his 2019 paper? I don’t think so, since commercial success of a protocol is how it has staying power: Amazon’s S3 API, email’s SMTP, and QUIC are all examples of protocols where everyone benefits by their ubiquity, but they had to be commercialized first, by the likes of AWS, AOL and CompuServe, and Google. BlueSky’s opponent is not another protocol like ActivityPub, but rather they challenge the platform formerly known as Twitter. The very existence of a bridge between the ATmosphere and the Fediverse proves that platforms are the real enemy, and we all need to keep that in mind.

No enemies to the left.

Your understanding is not wrong, but “within namespaces” is doing a lot of the heavy lifting. After all, there isn’t just one namespace but many simultaneous namespaces at play. A process namespace is where process IDs (PIDs) begin from 1 and fork()'d processes are assigned incrementing PIDs. These values are meaningless outside of the namespace, and might even get mapped to different values in the parent namespace. A process namespace gives the appearance that the process with PID 1 is the init process, which is customarily the first userspace process started once the kernel is running.

There are also network namespaces, where network interfaces (netif) can be switched (Layer 2) or routed (Layer 3), independent of what the global/default/parent network namespace is doing. This gives the appearance that all the network configuration is wholly independent, and allows neat things like crafting specialty routing (eg Kubernetes overlay networks).

Then there are user namespaces, where the root user has the appearance of total authority, and normal users can be created, but these are entirely distinct from the global/default/parent users and groups on the machine. This pairs well with filesystem namespaces, where a sub-tree of the real filesystem is treated as though it is a full tree, which allows the namespaced users to do standard manipulations like changing file ownership or permissions. This is essentially what UNIX chroot() does, but IIRC, chroot() did not also create user namespaces.

Taken together, namespaces in Linux are less about isolation – although they certainly work for that – and more about abstracting everything else in userspace away: no need to deal with other people’s processes, netifs, files. It’s like having the whole machine to yourself. In the history of computer science, isolation is often achieved precisely by making everything else invisible and out of the way. Virtual Memory did that, as did x86 Protected Mode, as did Virtual Machines. And so too does namespacing. Containers are the result of namespacing all the key kernel interfaces.

Perhaps the crucial thing then is what interfaces aren’t namespaced. In Linux, a big one is device drivers. Folks that want to share a USB TV capture card or a PCIe GPU or even a sub-NIC using SR-IOV, will find that /dev files are not namespaces. They exist in the global space and aren’t isolated. So the only thing that can be done is to pretend to “move” the device file into a container, with everyone else promising not to try using that device anyway. This is not isolation because accidental or malicious action will break it. To do “device isolation” would require every driver to be namespace aware, so that it could treat requests from two different namespaces as distinct. That does not exist at all in Linux, and such low-level work continues to be difficult with containers, often surprising people that think that Linux containers are complete abstractions. They are not.

There are terminology issues here, both in the Lemmy post title, in the article body, and in the article’s TL;DR. Basically, nothing is internally consistent except maybe the OCI Runtime spec itself, although its terminological relevancy is a separate issue.

Lemmy title: Containers are not Linux containers

Article title: What Is a Standard Container: Diving Into the OCI Runtime Spec

Both titles imply the existence of non-Linux containers, yet only the latter actually describes the contents of the article, specifically naming the “other” type of container, being “Standard Containers” defined by the OCI Runtime spec. As a title, I greatly prefer the latter, whereas the former is unnecessarily antagonistic.

That aside, the article could really be helped by a central glossary section, as it refers to all of these as containers, without prefacing that these can all validly be called “containers”:

• OCI-compliant containers
• Standard containers
• Linux containers
• Docker containers
• Kata VM-based containers
• Other VM-based containers that have been deprecated

If the goal was to distinguish what each of these mean, the article doesn’t do that great of a job, other than to say “these exist and aren’t Linux containers, except Linux containers are obviously Linux containers”.

Reframing what I think the article tried to convey, while borrowing some terminology from C++/Python, the OCI Runtime specification defines an Abstract Base Class known as a Standard Container. A Standard Container supports the most minimal functions of starting and stopping an execution runtime. For Linux, FreeBSD, Kata, etc, those containers are subclasses of the Standard Container.

For the most part, unless your containerized application is purely computational and has zero dependencies upon the OS, your container will be one of the subclasses. There are essentially zero practical container images that can meet the zero-dependency requirements of being a Standard Container. So while it’s true that any runtime capable of running the container subclasses could also run a Standard Container, it is of little value in production. Hence why I assert that it’s an abstract base class: it cannot really be instantiated in real life.

This is the reality of containers: none can abstract away an application’s dependency upon the OS. The container will still rely upon Win32 calls, POSIX calls, /proc, BSD sockets, or whatever else. So necessarily, all practical containers need a kernel layer. Even the case of Kata’s VM-based containers just mean that the kernel is included within the container. Portability in this context just means that the kernel version can change beneath, but you cannot take a Linux container and run it on FreeBSD, not without shims and other runtime kludges.

The Linux kernel itself doesn’t really express an opinion – it’s a kernel, it enables you to do most things – but it’s Docker itself that imposes an opinion. And I say this after Docker Engine has basically delegated the runtime to containerd. At bottom, Docker has some serious baggage that needs to eventually be addressed, chiefly IMO the sorry state of networking.

What was done to make Docker usable initially has reared its ugly head a decade later, such as a focus on only supporting Legacy IP and NAT, with very little regard for IPv6. For example, Docker does do IPv6 today but only with NAT66 and zero support for DHCP6-PD upstream routing. This makes it incompatible to how actual v6 networks are set up, where NAT is neither desirable nor necessary. Docker’s idea of networking is so very 1990s that it’s genuinely stifling any improvements beyond the server/client TCP/UDP model.

All the meanwhile, Kubernetes is built atop sensible networking on Linux, and the BSDs have had solid networking primitives for decades. Linux is not the problem, IPv6 is not the problem, BSD is not the problem; it’s just Docker being stuck because of a lack of vision and too many users dependent on the existing behavior.

Credit where it’s due, Docker images defined as files and stores as artifacts in a central repository are a genuine innovation, and that’s precisely what BSD Bastille brings to BSD jails. So in 2026, where the OCI specification has genericized Docker images, anything that’s Docker-specific is slowly losing relevance.

The short answer is that Linux did not approach namespacing from a holistic view, but rather introduced each one at the time when they were deemed useful individually or necessary. Meanwhile, the BSDs looked at what they had from UNIX (ie chroot) and then thought about the fullest logical extent of that idea. And in doing so, looked at every kernel interface and added support to namespace (or jail) them all.

Sure, BSD jails have had their own bugs over the years, but as a design, it’s an incredible testament to building a framework that was ahead of its time by focusing on the fundamentals.

To be clear, there are sometimes use-cases where Docker containers are ran without creating separate namespaces (eg sharing the host’s network namespace) but it’s rarer than the equivalent in BSD jails, where it’s a neutral choices between isolate or reuse namespaces. In that sense, Docker is lightly opinionated into defaulting to all-isolation and makes it hard to remove all the layers, if that’s your jam.

For pointers in particular, this seems like a good starting point: https://sites.cs.ucsb.edu/~mikec/cs16/misc/ptrtut12/pointers.htm

As for compiling for old C/C++ versions, fortunately most compilers can be set to restrict what standard they will compile for. So you could turn the compiler all the way back to something like C99 and it should work, although you’ll have to avoid using modern syntax.

That said, with regards to compiling for an old platform, be advised that complete and functional toolchains will be harder to come across. They may not even work anymore, if they haven’t been upkept. That’s another complexity that you may have to deal with, and it will no doubt be aggravating, than working with a modern platform but limiting yourself to only older C/C++ standards and graphics libraries.

Basically, the starting effort is quite high for developing for older targets. Be certain that this is the direction you want to start with.

This distinction is both illogical and ahistorical. Python is a scripting language that has a compiler. Indeed, any scripting language can be translated into a compilable language and then compiled, a process called transpiling.

There’s also Java, which definitely compiles down to bytecode, but for a machine which physically doesn’t exist. The Java Virtual Machine is an emulator that runs on supported hardware, in order to execute Java programs. Since the Java compiler does not produce, say, x86 assembly, your definition would assert that Java is not a compiled language, despite obviously having a compiler.

As an exercise for everyone else, also have a look at Lisp, a very-clear programing language with a compiler, but some specially-built machines were constructed that optimized for Lisp programs, with hardware support to do checks that would take longer on other architectures.

Your original post was in c/linuxmemes , found here. Your follow-up question about phone security was a comment under that post. Although someone passing by might happen to be a senior pentester with a major mobile OS vendor, that is a community for posting funny memes.

To ask the commenters at-large there for a detailed, well-elucidated answer to “how does phone hacking work?” is to expect too much.

Fortunately, this is Lemmy so you just have to find the right community to ask, and to set your expectations accordingly.