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!

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.

VT5xx was the budget line with limited functionality, that's why only 525 among them supports ANSI color. The only fancy stuff was multisession (TD/SMP if you have all bits to support it) and "desktop accessories" like clock and calculator.

The really interesting ones are VT340 variants with ReGIS and full SIXEL graphics

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

The references to "budget line" were from contemporary sources, and that it was heavily reduced in cost - while terminal sequences were more of "simple matter of programming" ;-) My understanding that some of the features like changing cursor shape were related to the rudimentary custom font feature which was retained from more expensive 3xx line and which accepted IIRC sixel-encoded bitmap fonts.

Funnily enough, the one VT510 I had for some time actually came from a VHS rental place that for reasons unknown to me ran Blockbuster Video customized VAX 6.1 on Alpha (which I also grabbed). BBV was not very well known in Poland, but this specific machine had unwiped disks and logs showing it was used from 1996 to 2000, then it was found lying in a corner when a moving service was asked to clean out a location after a tenant that came in after the video rental.

There was probably a DECserver missing somewhere in the pile before I got my hands on it ;)

I've started working on a VT420 emulator which is about 70% complete: https://github.com/mmastrac/blaze

xterm does and some others, I posted about this and emojis a while ago: https://dgl.cx/2025/06/can-your-terminal-do-emojis

(161 comments) https://news.ycombinator.com/item?id=44362272

Given the source isn't released, how about an IRCd in bash: https://github.com/dgl/bash-ircd