> think the only piece nineties Linux didn't anticipate was the level of hot-swapping hardware
They did, modular kernels date back as 2.2 at least. And USB was born in that era.
They did, modular kernels date back as 2.2 at least. And USB was born in that era.
* My USB webcams wouldn't show up in a different order each time I reboot. This works fine under Windows and Mac.
* My monitor configuration wouldn't be hardcoded in my xorg config file, or swapped around manually with xrandr. I'd have a way to code up config options for whatever is plugged in, and if something unanticipated happens, it'd do something reasonable until I coded that config in too.
* I wouldn't need to reconfigure my drawing tablet to connect to the right monitor each time I plug it in.
* The system wouldn't get into an unrecoverable, unstable state with e.g. an unreliable USB cable.
.. and so on. It's designed for a fixed set of hardware, with layers on top of that to support hotswapping. I don't have "USB 4k Logitech Webcam" on the native level. I have /dev/video3. I then have layers to map names back.
Same thing with HDDs too, actually. I refer to them as /dev/sdc4, rather than by a GUID or name or similar. Layers with onions.
$ ls /dev/disk/by-uuid/
266c945c-1c6d-40e7-b770-73864a5541fa
$ cat /etc/fstab
UUID=266c945c-1c6d-40e7-b770-73864a5541fa /1) https://www.raspberrypi.org/documentation/installation/insta...
2) man fdisk
3) man mkfs
And so on. The /dev/sd_ is primary, with UUIDs as kind of an afterthought
It ought to be the other way around, with UUIDs as the primary, proper, canonical name and interface, and a legacy backwards-compatibility layer for /dev/sd_ devices. It's even reflected in the directory structure. Yes, I CAN list disk "by-uuid," label, id, partuuid, or path, but those are special cases with sd_ as canonical.
It's kinda retrokludged in there. I never said USB/etc. didn't work. Just that it wasn't architected for it.