I can see that, but surely there wouldn’t be much difference matching the first 4bits (0x2XXX, 0xfXXX) vs the first 16 (0x0001)?
0:: is presumably all for loopback-type stuff, but I don’t see a reason not to use 1:: through 1fff:: and they would be much easier to type/remember/validate for public DNS servers which are needed before name resolution is available.

Why start at 0x2001 though? Why not 0x0001? Then we could have addresses like 1:1:1::1 or 1:2:3::4.

2606:4700:4700::1111

Hmm, maybe Google is easier:
2001:4860:4860::8888

Quad9 is 2620:fe::fe or 2620:fe::9

I don’t understand why they can’t get better addresses than that. Like surely 1::1 would be valid?

Edit: So IANA only control addresses 2001:: and up and there are quite a few IETF reservations within that. I don’t know why they picked such a high number to start at. Everything else seems IETF reserved with a little space allocated for special purposes (link-local, multicast, etc.).

Still easy to miss. Would be better in red.

https://knowyourmeme.com/memes/you-vs-the-guy-she-told-you-not-to-worry-about

I just take a chip

Cheers.

I got an overpriced 250×200mm sheet off Amazon, just because it was easy. It’s definitely available cheaper elsewhere. I was trying to get blank black G10 / FR4 board to match the PCB but it doesn’t seem easily available in small quantities (except from China). I just searched for 1.6mm sheet and this stuff came up (it’s 0.06 inch but close enough). It cuts really well with a hacksaw - didn’t chip or crack at all and cleans up with a file or just a craft knife. I roughed it up the surface with sandpaper to CA glue it together and they’re holding together great.

The key cap set I got only had 1 and 1.5U. There are some 1.25U caps available separately online so I may well do that, thanks!

Is there any reason to keep the existing set-up? If it’s just one drive, you could replace it with another and install Alma or something fresh. Then you could copy over whatever config the old system had to get up and running again. You could swap to the old drive if you needed to revert. If you have a spare machine, you could stand up the fresh setup side-by-side with the old one before swapping over.

I’ve been wondering, what are midichlorians?

That’s supposed to be travelling at 153,545 mph, so not even half the speed of Aladdin and Jasmine. Also, the Parker Solar Probe is in space.

Ah, come-on, why do you think Eliza could do that 60 years ago?

Does that question interest you?

and having seen quite a few 'shops in my time.

I find it odd, because venv is a “Suggested package”, actually. It isn’t in the list of new packages that will be installed with python3 by default.

I think the next major release of apt is supposed to be easier to read. Unless Debian neuter it.

Thants.

*Screams in CUDA*

The one-liner: *parses HTML with a regex*

I mean, we have systemd-bsod now…

Not that I’ve ever seen it of course.

Ah, that’s the misunderstanding. The original comment was talking about “watching something on another pc”. Like playing a video from a desktop PC on a laptop in another room. So it’s the samba server we want to prevent from sleeping, not the client. Yes it’d be nice to have a 24/7 media server set up, but for the simple case of sharing a file from one PC to another, it’d be nice for the server not to sleep in the middle of it by default.

For sure, I don’t know the internals of Samba, but surely the server knows that it’s serving a file no matter how the client accesses it. I don’t think a few dbus messages would cause issues.

I have my own service that looks at the network traffic via /proc and a few other things. That sends the system to sleep itself if everything looks truly idle.

I do think it would be nice for a file server like samba to inhibit sleep using the standard interface for it. But yeah, I appreciate there are complications, like video playback is presumably pulling a small extent of a file at a time, so there would have to be some kind of timer before releasing the inhibition or the system would sleep between transfers.

EDIT: I just took a look; with loglevel set to 3 for smb and smb2 I see log messages like:

smbd_smb2_read: fnum 1712966762, file my_video.mkv, length=262144 offset=82366464 read=262144

These occur at most 10 seconds apart when playing a video over a share from another host. I don’t see why the smbd daemon couldn’t inhibit sleep untill smbd_smb2_read hasn’t run for a minute or so. You could have a script that monitors that log output and does this externally but it’d be nice to have built in.