Hacker News new | ask | show | jobs
by greyw 894 days ago
Reading the section about resolved reminds me of musl having a "broken" stub resolver implementation for years (whenever the dns payload was larger than 512 bytes). "Broken" because the TCP fallback was supposedly intentionally not added for complexity reasons.

DNS and all the additions seem to be really not easy to handle.

2 comments

Yes - that lower level networking stuff is just a minefield of edge cases which most people never need but are really annoying if you’re unlucky enough to hit them, and Linux has always had this problem where if something works for Windows the people who run those broken networks and many users will say it’s a Linux problem. A lot of the systemd decisions are probably explained by someone getting a ticket saying their Red Hat laptop takes much longer than Mac to get on the corporate network or was unable to deal with the captive portal on some hotel Wi-Fi, and they realized fixing it was going to require work across 5 different code bases.
I think this is the most likely explanation for why systemd includes everything but the kitchen sink. For consistency, and ease of maintenance, having it all under one umbrella is certainly a benefit (for the developers of systemd.)

Also, NIH is a hell of a drug.

Systemd's catalogue of kitchen sinks is getting to be truly impressive. Here's an NVMe-over-TCP server, for some reason: https://github.com/systemd/systemd/blob/main/src/storagetm/s...
This is a great example of an edge case which many people might never need but is really useful in a pinch: that’s what provides the equivalent of the Mac target disk mode, which is really handy if you need to repair a no longer-bootable system.

https://github.com/systemd/systemd/commit/1761066b135f1a322c...

That's really not a great argument for why it belongs in systemd.

Kitchen sinks are generally useful, but 17 kitchen sinks in a helicopter is not a good idea.

Where would you put it instead of something started by pid 1? It needs to boot the kernel and unlike macOS they have to run on a ton of different architectures so they can’t count on the firmware.
Have you ever setup an iscsi shared device in linux? It’s quite complex and a bit messy.

If systemd can make something similar (i still get a block device from another host in the network) in a simpler manner that would be just awesome, truly a huge win for everybody.

Yeah musl enthusiasts strangely never acknowledge this enormous bugs that musl libc has, i wonder why.