The linked article is precisely about how in 2024 they started rewriting their proxy layer from nginx (a C app). While "They haven't had an incident that bad since they switched from C to Rust." might be true, it has also been almost 9 years since cloudbleed, of which 8 were in C world.
Not good, thanks for sharing. Also different, however. One is a routine part of criminal investigations in which over 4 million people are swept up, while around 2000 were swept up in the linked article at the border. I’m not okay with even the 2000, but it’s a different thing.
The goal of this kind of system is not to replace the application server. This is intended to work on the data plane where you do simple operations but do them many time per second. Think things like load balancers, cache server, routers, security appliances, etc. In this space Kernel Bypass is still very much the norm if you want to get an efficient system.
> In this space Kernel Bypass is still very much the norm if you want to get an efficient system.
Unless you can get an ASIC to do it, then the ASIC is massively preferrable; just the power savings generally¹ end the discussion. (= remove most routers from the list; also some security appliances and load balancers.)
¹ exceptions confirm the rule, i.e. small/boutique setups
You don't develop an ASIC to run a router with, you buy one off the shelf. And the function of a router doesn't exactly change day by day (or even year by year).
Change keeps coming, even when the wire format of a protocol has ossified. I've spent years in security and router performance at Cisco, wrote a respectable fraction of the flagship's L3 and L2-L3 (tun) firewall. I merged a patch on this tried-and-true firewall just this year; it's now deployed.
As vendors are eager to remind us, custom silicon to accelerate everything between L1 to L7 exists. That said, it is still the case in 2025 that the "fast path" data-plane will end up passing either nothing or everything in a flow to the "slow path" control-plane, where the most significant silicon is less 'ASIC' and more 'aarch64'.
This is all to say that the GP's comments are broadly correct.
My colleagues are always writing new features for our edge and core router ASICs released more than 10 years ago. They ship new software versions multiple times a year. It is highly specialised work and the customer requesting the feature has to be big enough to make it worth-while, but our silicon is flexible enough to avoid off-loading to slow CPUs in many cases. You get what you pay for.
We do storage systems and use DPDK in the application, when the network IS the bottleneck it is worth it. Saturating two or three 400gbps NICs is possible with DPDK and the right architecture that makes the network be the bottleneck.
There are more ACME-compatible CAs than just Let's Encrypt, should they ever become the bad guys, or if you don't want to trust them for any reason, see [0].
I understand that people get annoyed at shorter cert lifetime, for instance if you are managing appliances or use SSL certs for other reasons than the common use case. But if you just want to serve a website, there are not so many reasons not to use HTTPS today, either on Let's Encrypt or on something else.
Android delegated some security features to a different kernel called Trusty that is separated from the main Linux kernel using virtualisation. That kernel runs high value security services.
Yes, but that's not the main load-bearing security part of the system. Trusty doesn't isolate apps from each other. It doesn't isolate work profiles from user profiles. Regular SELinux-augmented thoughtfully-used uid- and process-isolation does that.
Romansh is a national language, not an official one. (At the federal level) Which means that Switzerland considers it a part of it’s culture but that for instance laws and executive orders are not translated in Romansh.
In arch at least it is reasonnably easy to download the source for a package, modify it locally, build it and install it. Not sure if that's what you are asking for?
I think no matter how easy a seperate source package is, it's still a seperate thing, and not the same (not as good) as the source being a built in part of the package.
freebsd/gentoo ports comes close where if you pretend that pkg doesn't exist, or at least imagine a world where it's only used for the absolute minimum necessary bootstrap, then ports is probably the closest.
The source is still actually a seperate thing even then so I think even ports with no pkg usage is still not really there.
Imagine the package itself being the source, the one and only form of the package is the source. If it builds an executable, that executable is actually just an automatically generated throw-away artifact that you don't care about and don't save or distribute. Maybe most normal users don't even know where the compiled bin really lives, buried in some /var tree or something, or maybe even in a kind of kernel level db. All the user ever overtly interacts with is actually the self-building source package. When you want to copy it or delete it etc, that's the only thing you touch and everything else is just automatically managed cache.
Then it's not merely easy to get the source and modify it, it's simply THE package in the first place. If you can even run a thing, then you automatically and indellibly also have the full source to that thing. That would be pretty huge I think.
It would probably result in slow installs and updates like gentoo or freebsd ports, but only if we only imagine switching to this today as the only variable changed, out of context, without also imagining the last 40 years of tooling and os development optimizing pain points to make whatever we do most go faster, if we had decided to package apps this way all along.
Indeed, but I also don't see why this couldn't extend to the kernel too: it would self-compile upon boot.
There is an obvious bootstrapping issue (there has to be a compiler for any language you want to compile, including the one your compiler is in), but it's certainly interesting food for thought.
Google used to indulge employees' interests. They fund, or used to fund, "the generator", a build shop in Reno. I know a Googler who openly worked on a small art project at the office, albeit a small part of the work.
I'm not saying that Google has machine shops purely for burning man. But I strongly suggest that when the idea has been floated in various locations, one recurring theme is "yeah let's! And let's get some lasers and propane burners!", and I also believe that some managers were thinking "great, this is the culture we want."
The register calls it "the chocolate factory" as a reference to Willy Wonka. Shame they descended into evil.
I don’t mean the rank and file but Page and Brin. They’ve only ever gone the glamping sparkle pony route.
> I'm not saying that Google has machine shops purely for burning man. But I strongly suggest that when the idea has been floated in various locations, one recurring theme is "yeah let's! And let's get some lasers and propane burners!", and I also believe that some managers were thinking "great, this is the culture we want."
There was! It was the predecessor to the Garage. I suspect because the machine shop boys wouldn’t let them use the real toys.
