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 have some code which does this at https://git.sr.ht/~dgl/deserve/

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.

FreeBSD has supported Linux emulation for a long time (https://docs.freebsd.org/en/books/handbook/linuxemu/). The emulation is at the syscall level but enough to run most apps.

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.

> It just takes a bit of planning.

Haha, no it just takes forcing user account name changes.

github.com/copilot, github.com/claude, github.com/models, basically everything you can think of for the last few years has been through this approach.

I wonder how they prompted these users to change their usernames. Was it just a "we need your username for our business, so comply" notice?

https://web.archive.org/web/20210702114132/github.com/copilo... some proof this was an actual user

Looks like he's now https://github.com/ogcopilot

Some more discussion on similar things: https://news.ycombinator.com/item?id=38380344

"Hey, remember the username you've had for twenty years? Yeah we want it now"

It's what you get for being a tenant rather than owning your own site.

And yet it's worth it for the network effects, sadly. These companies should be regulated, the moats are just too deep.

I like that the EU recognised this and did start to regulate that these companies need to interoperate.

You can plan every "top level" path you'll ever want on the site from now until forever? Or do you mean planning as in plan to force account name changes on users when someone's username conflicts with a new feature name?

You could probably get away with banning all common english words as usernames if you wanted to.

Even if you don’t ban all words, there are some you should filter:

• <https://ldpreload.com/blog/names-to-reserve>

• <https://xkcd.com/1963/>

Or put all user pages under some top level path and then you never need to ban anything as this problem becomes completely moot.

Until you invent a product or concept name that is taken by one of the users ;-)

In that case it's not really different if the usernames are prefixed to be clearly identifiable as usernames - most companies still wouldn't want any user accounts that look like official company accounts.

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

This.

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/

The std api can only create UdpSockets, the trick here is that you use Socket2 which allows more kinds of sockets and then you tell UdpSocket that some raw file descriptor is a upd socket through a unsafe api with no checks and I guess it works because they use the same api on posix.

Edit: It is possible in safe rust as well, see child comment.

The macro used by socket2: https://docs.rs/socket2/0.6.1/src/socket2/lib.rs.html#108

The FromRawFd trait: https://doc.rust-lang.org/stable/std/os/fd/trait.FromRawFd.h...

From/Into conversion via OwnedFd is the safe API, RawFd is the older and lower-level one.

Ahh I guess that means that its possible in safe rust to cast a file descriptor to a different type. I was just looking at how socket2 did it and forgot to have a proper look.

Thanks, that's quite the misnomer then.

That happens when someones learning project ("I rewrite a library in the new language I want to learn") ends up in productive code.

This is in the standard library; it's not a learning project. And it also isn't even incorrect - see erk__'s comment.

Rust is an excellent language and fully capable of production use.

It's not, it's the `socket2` library. The standard sockets don't allow (ab)using actual `UdpSocket`s as a different kind of datagram socket.

Sure it does.

    let f = std::fs::File::open("/dev/null").unwrap();
    let f: std::os::fd::OwnedFd = f.into();
    let socket: std::net::UdpSocket = f.into();

This is really no different. In this example it's not even a socket.

We're talking about UdpSocket: https://doc.rust-lang.org/stable/std/net/struct.UdpSocket.ht...

Yes, I know, but the point is that the standard UdpSocket is correctly named as it doesn’t represent any other datagram socket. Uh, we’re pribably in agreement here actually.

Yeah exactly! :-D

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

This does work on a compaq DS10. You can't boot directly from it but linux will see the nvme disk right away from a livecd.

Also the UK seems to include the Grand Union canal and River Severn but not the River Thames. It seems quite random.

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

It is possible to add logos without (well, differently) abusing the error correction: https://research.swtch.com/qart

Of course most images in the middle aren’t doing that and rely on some level of error correction fixing it.

I love how dedicated some people are to hacking random things for fun. What a great read!