How long are the blocks on this point-based train control system? They were 25kms away from the other train when LZB went offline

Tbf in the recent years Gitlab has become quite enshittified (most new work is focused around selling LLM subscriptions) and the people working on more prominent public issues seem to have been laid off, so I dont have great confidence in its future.

Forgejo has fewer features, but those features work a lot better than the equivalent Gitlab features.

Tbf there are always bad implementations. Good "smart" devices nowadays should be based on the Matter standard, which natively uses IPv6 addressing

https://en.wikipedia.org/wiki/Matter_(standard)

much easier than `cafe.local` with mDNS :)

i find NAT64 acceptable

You can always just use IPv6 where there is plenty of address space available. You can even get a /44 as a hobbyist easily

For what cost? Last I saw you had to pay at least a few hundred dollars a year and run enough network infrastructure to justify it.

It's a lot cheaper than ipv4, for the most part.

There is also HTTPS boot, which might be a lot more secure than PXE

https://tianocore-docs.github.io/EDKIIHttpsBootGettingStarte...

some arm64 sbcs support edk2/uefi btw. I make sure I just use those. Look for "Arm SystemReady" certification, which requires this

Any chance you could recommend a board or two?

I'm currently using the Radxa Q8B, which already includes EDK2 OOTB and provides the device tree to the linux kernel. But its still a new board and some things are not supported in mainline linux yet.

There are also less-powerful RK3588-based boards like the Radxa Rock5 series which are supported by this edk2 port: https://github.com/edk2-porting/edk2-rk3588#platinum. Thanks to collabora the mainline support is quite advanced: https://gitlab.collabora.com/hardware-enablement/rockchip-35...

If you are searching for more powerful enterprise hardware, AmpereOne SoCs have ARM SR certification. You can just use any modern linux distro uefi generic aarch64 iso and it will boot.

they also provide device trees to the kernel on modern arm uefi environments. And in servers they provide an interface for the baseboard management controller to interact with the firmware directly.

Before you manually configure a rule in your WAF you might as well just fix the vulnerability in the vulnerable component directly ^^

especially in free/open source software like edk2