4 ms·

If this was anticipated by the architecture: * My USB webcams wouldn't show up in a different order each time I reboot. This works fine under Windows and Mac.

by wegs 6y ago

If this was anticipated by the architecture: * 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.

sergeykish 6y ago
You've described need for UUID but then discard it for disks, why? $ ls /dev/disk/by-uuid/ 266c945c-1c6d-40e7-b770-73864a5541fa $ cat /etc/fstab UUID=266c945c-1c6d-40e7-b770-73864a5541fa /
- wegs 6y ago
  Mostly, because as of 2020, most things don't use UUIDs. See e.g. 1) https://www.raspberrypi.org/documentation/installation/installing-images/linux.md 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.

by wegs 6y ago

sergeykish 6y ago

You've described need for UUID but then discard it for disks, why? $ ls /dev/disk/by-uuid/ 266c945c-1c6d-40e7-b770-73864a5541fa $ cat /etc/fstab UUID=266c945c-1c6d-40e7-b770-73864a5541fa /

wegs 6y ago
Mostly, because as of 2020, most things don't use UUIDs. See e.g. 1) https://www.raspberrypi.org/documentation/installation/installing-images/linux.md 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.