While xargs definitely has some rough edges this seems to add actual security issues instead of a simple replacement. It feels like some of the other handling is a bit lax too, although I haven't tried that in detail.
Zip isn't useful for random access here; the problem with random access in HTTP serving is then you have to decompress the data and potentially recompress.
The more interesting trick you can do with zip files for HTTP serving is to serve the compressed deflate stream as gzip, or use Zstd inside zip. Then you have a valid zip file from which bytes can be served directly.
I tried using their Magic Containers product and there were issues that showed a lack of attention to detail as well.
It's supposed to scale globally (magically!) but I found multiple cases where particular nodes were problematic and the health checks didn't detect them (in fact to start with the health checks didn't even work properly if you had multiple containers, they did fix that). The support was quite slow too, after finding multiple product issues they'd escalate to developers and then come back a month later and ask to retest, but some of this took multiple round trips. I was only using this on a side project, but definitely wouldn't consider them for anything critical, even if they are quite cheap.
GitHub manage to do it. Most URLs you'd think of are either redirects to other bits of the site, or accounts owned by GitHub themselves. It just takes a bit of planning.
> Part #2 to me, I also want observability as to what the agent changed.
You could potentially combine https://github.com/binpash/try with bubblewrap (I'm not sure how well they compose and as the docs say it isn't a full sandbox).
The good (and bad because it's confusing and can lead to surprises if misconfigured) thing about Linux containers is all the pieces of containers can be used independently. The "try" tool lets you use the overlay part of containers on your host system, just like Bubblewrap lets you combine the namespacing parts of containers with your host system.
Instead you can create multiple Wireguard interfaces and use policy routing / ECMP / BGP / all the layer 3 tricks, that way you can achieve similar things to what vxlan could give you but at layer 3.
There's a performance benefit to doing it this way too, in some testing I found the wireguard interface can be a bottleneck (there's various offload and multiple core support in Linux, but it still has some overhead).
The BSD socket API has 3 parameters when creating a socket with socket(), the family (e.g. inet) the kind (datagram in this case) and the protocol (often 0, but IPPROTO_ICMP in this case).
Because when the protocol is 0 it means a UDP socket Rust has called its API for creating any(?) datagram sockets UdpSocket, partly resulting in this confusion.
The kernel patch introducing the API also explains it was partly based on the UDP code, due to obviously sharing a lot of properties with it.
https://lwn.net/Articles/420800/
> My immediate question which isn't (I think) answered in the repo is how do you interface the NVMe? Can you put NVMe on PCI as opposed to PCIe? How?
PCI to PCIe adapter and then PCIe to M.2:
https://www.vogons.org/viewtopic.php?t=78987
(PCIe has some level of backwards compatibility, although like that thread shows there are some limits as to what will work).
> On the QR topic, I don't understand how logos in the middle work. You are losing pixels and checks with the logo in the middle which is fine until you make the logo too big.
The VT3xx ones that were color did not support ANSI SGR to set them. I don't think VT5xx was a budget line, it has more escape sequences than the previous ones (including interesting ones like changing cursor shape, which modern terminals implement too). It's more that they never made a graphical version of the VT5xx (this was the early 90s, whether physical VTs made sense anymore is debatable, but terminal graphics likely didn't).
VT340 is definitely interesting and if someone were to emulate one that would also be great! (there's been some good research, e.g.: https://github.com/hackerb9/vt340test, which you might be surprised to learn has been used to make Windows Terminal one of the more conformant terminals...)
If MAME could support the VT525 (nearly the last terminal DEC made and unlike the previous DEC models it supports ANSI color) people might use it a bit more. It would be very useful for compatibility testing as there aren't many people with a real VT525! Last I looked someone had dumped the ROMs but there wasn't any support code.
> the 1Password browser plugin would have noticed that “members-x.com” wasn’t an “x.com” host.
But shared accounts are tricky here, like the post says it's not part of their IdP / SSO and can't be, so it has to be something different. Yes, they can and should use Passkeys and/or 1password browser integration, but if you only have a few shared accounts, that difference makes for a different workflow regardless.
This isn't really that different to GWT, which Google has been scaling for a long time. My knowledge is a little outdated, however more complex applications had a "UI" server component which talked to multiple "API" backend components, doing internal load balancing between them.
Architecturally I don't think it makes sense to support this in a load balancer, you instead want to pass back a "cost" or outright decisions to your load balancing layer.
Also note the "batch-pipelining" example is just a node.js client; this already supports not just browsers as clients, so you could always add another layer of abstraction (the "fundamental theorem of software engineering").