welterde (u/welterde)

welterde commented on IPv6 just turned 30 and still hasn't taken over the world theregister.com/2025/12/3... · Posted by u/Brajeshwar

SoftTalker · 2 months ago

Is there an obvious reason why it would not have worked to just say that all ipv4 addresses are ipv6 addresses with an implicit leading 96 zero bits?

welterde · 2 months ago

This is already a thing in IPv6 pretty much. You can write applications IPv6-only and support IPv4 via IPv4-mapped addresses (::ffff:1.2.3.4 for the IPv4 1.2.3.4). The host still needs to be dualstacked for that to work though. In case the host is IPv6-only you can use NAT64 (or similar technologies), where the IPv4-space is embedded behind some other prefix, but the application just talks plain IPv6 and doesn't have to care too much what happens in the background.

welterde commented on IPv6 just turned 30 and still hasn't taken over the world theregister.com/2025/12/3... · Posted by u/Brajeshwar

pif · 2 months ago

I think 30 years should be much more than enough to realise the idiocy of proposing a non-backward-compatible standard to the general public.

welterde · 2 months ago

The problem is that IPv4 has no provisions to be forward-compatible with anything with a larger address space. Thus whatever replacement you can think of will have the same problems as IPv6.

welterde commented on Ancient X11 scaling technology flak.tedunangst.com/post/... · Posted by u/todsacerdoti

inetknght · 9 months ago

"reasonably well" as in... yeah it works. But it's extremely laggy (for comparison, I know people who forwarded DirectX calls over 10Mbit ethernet and could get ~15 frames/sec playing Unreal Tournament in the early 00's), and any network blip is liable to cause a window that you can neither interact with nor forcefully close.

It felt like a prototype feature that never became production-ready for that reason alone. Then there's all the security concerns that solidify that.

But yes, it does work reasonably well, and it is actually really cool. I just wish it were... better.

welterde · 9 months ago

For applications that were written with X11 in mind it works much much better than that. One example was the controlling a telescope. The computers in the control room were thin clients pretty much and displayed various windows from various machines across the mountain - even across multiple different operating systems! Some machines were running Solaris and some linux. The different machines belonged to different aspects of the telescope: some controlled the telescope itself and some machines belonged to the different scientifc instruments on the telescope. And it all worked quite well with no real noticeable lag.

welterde commented on Hard numbers in the Wayland vs. X11 input latency discussion mort.coffee/home/wayland-... · Posted by u/todsacerdoti

wmanley · a year ago

> It'll be challenging to even figure out which one of the things connecting to $DISPLAY is the real window manager.

I suspect it would be less challenging than writing a whole new wayland server.

Off the top of my head, I'd use a separate abstract domain socket for the window manager including some UUID, and then pass that to the window manager when launching it.

You could create these sockets on demand - one for each security context. On linux typically a different security contexts will either have different UIDs - in which case filesystem permissions would be sufficient - or they have different mount namespaces - in which case you make different sockets visible in different namespaces.

For SSH forwarding you could have SSH ask the X server for a new socket for forwarding purposes - so remote clients can't snoop on local clients.

> Good luck on your lonely[1] journey! > > [1]: The people who actually developed Xorg are now working on various Wayland-related things.

This is what I mean by a failure of technical leadership.

welterde · a year ago

> For SSH forwarding you could have SSH ask the X server for a new socket for forwarding purposes - so remote clients can't snoop on local clients.

SSH pretty much already does this. Per default (using -X) X11 forwarding is in untrusted mode, which makes certain unsafe X11 extensions unavailable. So remote clients already cannot snoop the whole keyboard input.

welterde commented on Hard numbers in the Wayland vs. X11 input latency discussion mort.coffee/home/wayland-... · Posted by u/todsacerdoti

uecker · a year ago

X always had the capability to isolate clients, but it is not used it would need some work which nobody does because of Wayland.

welterde · a year ago

Some aspects of the client isolation are used by default when doing X11 forwarding via SSH. A remote keylogger will not work for instance.

welterde commented on The IPv6 Transition potaroo.net/ispcol/2024-1... · Posted by u/todsacerdoti

x3n0ph3n3 · a year ago

Oh, is IPv6 now backwards compatible with IPv4? No? I guess not a complete list of fallacies.

welterde · a year ago

IPv6 clients (or in theory any kind of IPv4 successor) can reach IPv4 servers via some kind of translation layer (for example NAT64) - so IPv6 is backwards-compatible with IPv4 in that direction. The inverse direction (IPv4 client to IPv6 server) is however not possible, since IPv4 is not forward-compatible with any possible successor, because it is not possible to encode more information into 32-bit than 32-bit.

welterde commented on When railroad dining cars were the height of luxury cnn.com/2024/10/11/style/... · Posted by u/teleforce

jhugo · a year ago

The lack of dedicated tracks for high-speed passenger service matters a lot though. It’s part of the reason why those (very impressive) scheduled Munich-Berlin times are so often not achieved. The “slot” for the service is relatively small because slower trains (in particular freight) must be scheduled as well, so if the slot is missed for any reason, delays can compound very badly. I take the train between Munich and Berlin reasonably often and it’s usually running late, and sometimes by an hour or more.

welterde · a year ago

Reliability is certainly one aspect where dedicated tracks helps a lot, but is not the only solution (see for example Switzerland). For Germany the issue is the overall too large utilization of the network and the large backlog of required maintenance of the rail infrastructure (in my opinion).

welterde commented on When railroad dining cars were the height of luxury cnn.com/2024/10/11/style/... · Posted by u/teleforce

jhugo · a year ago

Maybe not so relevant to the economics of a dining car, but I have to take issue with “just as much of a bullet train”. Shinkansen are proper high speed rail with dedicated tracks, top speeds of 320km/h, and high speeds (260km/h or higher) across basically the entire network.

ICE trains run on the same lines used by slower services, and no train in Germany exceeds 300 km/h, with even that speed being attained only on quite small upgraded parts of the network.

The European rail network most similar to Shinkansen would be TGV.

welterde · a year ago

That has very little to do with the ICE train itself though, which can do above 320 km/h just fine in regular service (on international connections though, since in Germany the global train speed limit is 300 km/h I believe).

While the high-speed tracks in Germany are indeed quite a bit of a patch-work, there are over 1000 km of track certified for >= 250 km/h (as of 2015; quite a number of more lines got finished since then, but I could not find the updated number that included them) and by now really rather long corridors are very high-speed. The route from Munich (south of Germany) to Berlin is now mostly covered with upgraded routes for example. I think the 4 hours for that route are quite competitive to Shinkansen times. The fastest Shinkansen route (from the listed operating speed the only one that actually operates at 320 km/h; all others only operate at 260-300 km/h) is the Tōhoku Shinkansen line, which takes 3 hours and 20 minutes for the same distance traveled.

welterde commented on Raspberry Pi Pico 2, our new $5 microcontroller board, on sale now raspberrypi.com/news/rasp... · Posted by u/MartijnBraam

polishdude20 · 2 years ago

Woah an on-chip switch mode power supply? How does that work? I've put together these before on a PCB and they require an inductor and a bunch of other supporting passive elements. How does all that fit onto a chip?

welterde · 2 years ago

If I read the datasheet correctly you still need an inductor and some passive components externally. The only thing that is not needed is an external switch mode power supply chip.

welterde commented on Debian KDE: Right Linux distribution for professional digital painting in 2024 davidrevoy.com/article103... · Posted by u/abhinavk

jwells89 · 2 years ago

On the other hand, I think it’d make total sense to implement an optional mode that blocks programs’ ability to read the clipboard until the user explicitly approves them. I understand why some people might not want that (which is why I’d like it to be a setting), but it’s always felt a little weird that any program on desktop programs can grab the clipboard at will.

Things like making the clipboard “intelligent” might help too. On macOS there’s a bit of this when copying passwords from the system password manager, where the clipboard is cleared either after paste or after some short period of time to reduce chances of grabby programs pulling it.

welterde · 2 years ago

The X11 primary selection buffer is an even better variant of that though. It allows single-shot copy&paste (meaning only one application can grab it) from the password manager to the target application and it tells the password manager the name of the application that grabbed it.

I think it shouldn't be too hard to hack in a dialog to password managers to confirm if the destination is correct before replying to the data request. But even without that one at least notices that a malicious/wrong application grabbed the password.