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 other commenter have described the challenge, but I’d like to clarify the terminology, since the distinctions might not be obvious. For tech, we generally speak of the separate qualities of being Free (as in, use it however you want) and Open (aka being open to study, reimplement, and extend). If both qualities are had, then that’s called Free And Open.

The most common designation is for software, which if both Free and Open, then that’s Free And Open-Source Software (FOSS). Examples include the Linux kernel (GPL license) and FreeBSD in its entirety (MIT license). This means you can remake the software and use it how you like.

For hardware, there’s also the equivalent concept of Free And Open, and that means the PCB design can be remade and used for whatever you want. If you wish to use Free And Open hardware for war or for hobby use, that’s entirely up to you.

But there’s also the realm of silicon, which is the most esoteric and specialized, and there’s a lot less Free And Open silicon designs available. For example, the x86 CPU architecture is not Free nor Open. It is patented and its logic is proprietary and trade secrets of Intel, AMD, and Via. They document the behavior of registers, but they never publish the silicon designs so that you could make your own at home.

ARM is slightly different, in that they’ll gladly help you build your own ARM silicon (eg Apple Silicon system-on-chips) but you need to pay them a license. So it’s not Free nor Open because: 1) you have to pay money, and 2) the plans aren’t available for examination until you pay up.

LoRA silicon is more akin to x86, because they just don’t publish anything except the register behavior. The license to use the LoRA design is baked into the sale price that the LoRA Alliance charges. And yet still, you at home receive no right to remix or examine that silicon design yourself, unless you do actual reverse engineering. And even then, they have patents.

LoRA is not Open nor Free silicon. And it never claimed to be. Meshtastic and MeshCore use Free and Open hardware and software but that’s it. You do not have as many rights to the silicon as you do for the hardware and software.

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.

It could make sense, but what would be gained? A geographically-broader mesh sounds nice, until you realize that it means messages will go across the IP link and continue propagating on the other end, tying up the RF spectrum, even for traffic that didn’t need to cross the IP link.

It also detracts from what a fair number of people use the mesh for: comms without reliance on fallible singular links. Single points of failure are not ideal in a mesh, and an IP link would be adding exactly that.

Note that Reticulum has a much more developed routing structure, so that flood messages do not propagate everywhere uselessly. In that regard, Reticulum has learned what Ethernet and 802.11 WiFi have known for decades, while Meshtastic finds itself playing catch-up.

A managed flood is still a flood, so introducing a trunk link will increase the “broadcast domain”, to use Ethernet parlance. For two quiet, small meshes, a link between them might be alright. But for two busy, small meshes, the extra floods are just noise and drown out traffic.

Interest rate: the percent increase per compounding period . Almost totally useless unless the compounding period is also known.

APR: a metric which extrapolates an interest rate and compounding period out to one year, less any unavoidable fees. Because this metric can be computed for any savings instrument or any loan, it can be used to directly compare rates between different savings or lending institutions.

APR is still computable even for something which won’t last for 1 year (eg a 6-month Certificate of Deposit), for things with a compounding period longer than 1 year, and can deal with promotional offers, such as a savings account that pays 5% for the first 3 months and then returns to a normal rate of 1% ongoing.

Whereas before APR came into existence, it would have been possible to trick people with a seemingly “high” interest rate but it would have a longer compounding period, or they would charge an obligatory “exit fee” that takes a haircut off the interest at the end.

While the law cannot change the mathematical fact that an interest rate must also have a compounding period to be usable, USA law enforces that whenever an APR is given alongside an interest rate, it must have been computed accurately, with large penalties if not.

As the other commenters have noted, what sort of adversary are you trying to protect against? There is no such thing as “security for its own sake” but rather security measures like E2EE are to protect against specific types of attacks. Do you believe a ticketing system is vulnerable to attacks that E2EE would mitigate?

As an aside, please do not consider PGP to be a pinnacle of signing or encryption. I’ve opined in another project before about why Late 20th Century PGP isn’t that good in the 21st Century.

But even with a modern replacement for PGP, how would E2EE even work for a multi-user ticketing system? If everyone on the support side has the same key, then key management becomes (as usual) the most crucial part of the operation, and remains an unsolved problem at scale. This is no different than physical key management, when every member of the custodial team needs to have the “super key” that opens every door of a university campus.

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.

I very much don’t care for AI, but yeah, I posted it because an unexpected Rickroll – whether from AI or not – is still as funny as ever.

That said, I’m also aware that Mike Masnick is a recognizable name, of “Protocols, not Platforms” fame, also the person who coined the Streisand Effect, and probably most relevant, is a BlueSky board member (therefore not as interested in ActivityPub), those may be part of the downvotes too. Nevertheless, we take the rough with the smooth.

Citation needed

Code has never been able to be copyrighted. You cant copyright a for loop. I cant create a car class that has properties like make, model, year and copywrite it. Thats never been a thing. Thats why projects are copyrighted. An entire piece of work.

Every single complete sentence in this quote is factually wrong, under both USA copyright law and international copyright law.

Copyright accrues the moment that some work is rendered into a fixed format, such as a sheet of paper but also includes a computer text file. Writing a “for” loop as a homework assignment does create copyright. Ten students writing their homework all create their own copyright, even if the result is coincidentally identical. This isn’t even a point of serious doubt in the law: copyright is very much an exercise of provenance, not of bitwise comparisons.

From when a work is created, every transformation, edit, or addition must all occur within the parameters of some sort of license from the copyright owner, or else an infringement has occurred.

Two people may stand at the same position at the foot of Mt Whitney in California and set up their own camera, one after another, on the same tripod to take the same frame of the scenery. And under copyright law, each owns the copyright to their own photo. One may decide to sell their photo and copyright to an East Coast newspaper, while the other has theirs committed to canvas. The newspaper may not assert a copyright claim against the canvas owner, and the canvas owner cannot assert a claim against the newspaper.

!Meshcore@feddit.org

Please be considerate: how would anyone know that you meant your last post? Why not the last post on c/programming? If you’re asking a question, please try to make it easy for people to answer. A link is easy to add and avoids ambiguity.

When you say “the last post”, please link to it since different people have wildly different client settings that may not show every community’s posts in an adjacent fashion.

Generally, assume the lower result unless explicitly stated otherwise. If there are two pins supplying 12vdc but only a single output rating, then the assumption should be that the PSU produces a single 12vdc rail, and the total of both pins is 5A max. It is implied (unless otherwise stated) that the full rating of 5A can be drawn from just a single pin.

From a marketing perspective, if there were multiple output rails, they have an incentive for them to list them out in detail. ATX PSUs for PCs do this.

From a safety perspective, it would be downright irresponsible to design a connector on a finished product (like this standalone PSU) that has a lower per-pin rating that what the supply can offer, so any decent pre-built PSU will not have per-pin limits that are lower than the total output limit of that group of pins. As a counterexample, ATX PSUs are a component in a larger product (a computer) and so individual pin limits must be adhered to.

I used a generous definition of “supported” to include old firmware that GrapheneOS doesn’t support any longer on their latest releases but a release did exist at one point. It’s further down the FAQ.

Basically, I gave the benefit of the doubt and still the statement is still demonstrably false because the largest set of phones “supported” is still a tiny subsection of all phones in the market.