I realized I was long overdue for a hardware refresh when I learned that nvme drives are /dev/nvme and not /dev/sd[x] and I realized every single computer I interacted with was pre-nvme
An unintended benefit of using Qubes is that everything is a virtual machine and physical disks have to be manually attached to a vm before doing operations like dd. I haven’t had to worry about accidentally nuking my main partition for a while.
Huh, yeah I suppose that’s true. Qubes is an interesting project but I’m not sure it’s for me. I selectively isolate apps I worry about using containers, I actually should give flatpak a try as it basically does that for me but I haven’t seriously tried it yet.
What do you mean? The nvme device label convention is far easier to screw up IMO. At least on my system the first drive would be labeled “nvme0n1”, second “nvme1n1”, etc and partitions get an additional suffix like “nvme0n1p1”.
I am far more likely to screw that up compared to “sda” vs “sdb”. Especially since I noticed that if I have both my internal and external SSDs hooked up at boot time their number gets assigned on a seemingly random basis.
Eh? Idk if I agree. My original comment was entirely a joke based on the fact that the literal argument of=/dev/sda has no affect on my system but to address your actual point. I personally don’t find nvme naming any more confusing than SCSI. /dev/nvme0n1 is only one char away from /dev/nvme1n1 just like sda vs sdb. Additionally if you understand how the kernel comes up with those names they make a lot of sense. The first number is the controller, the second is the namespace or drive attached to that controller, the 3rd if present is the partition on the given drive. It is entirely possible to have a controller with more than one namespace. That aside aside…I think there is a genuine benefit to be argued for having USB drives, which are SCSI and fall into sdX naming separate from system drives as I dd far more USB media than system media. Making it a lot harder to screw my system up when trying to poke a flash drive.
That might make it even more dangerous, because you get used to flash to usb sticks on “/dev/sda”. And when you then use a device with a built-in sata drive, you might forget checking in a hurry.
Happened to me a once or twice. I am now only using bmap tools for this.
I am immune to /dev/sda for I only have nvme
I realized I was long overdue for a hardware refresh when I learned that nvme drives are /dev/nvme and not /dev/sd[x] and I realized every single computer I interacted with was pre-nvme
An unintended benefit of using Qubes is that everything is a virtual machine and physical disks have to be manually attached to a vm before doing operations like
dd. I haven’t had to worry about accidentally nuking my main partition for a while.Huh, yeah I suppose that’s true. Qubes is an interesting project but I’m not sure it’s for me. I selectively isolate apps I worry about using containers, I actually should give flatpak a try as it basically does that for me but I haven’t seriously tried it yet.
I love the nvme partition naming. Looking at you nvme1n1p3
/dev/nvme1s²2s²2p⁶3s²3p⁶4s²3d¹⁰4p²
What do you mean? The nvme device label convention is far easier to screw up IMO. At least on my system the first drive would be labeled “nvme0n1”, second “nvme1n1”, etc and partitions get an additional suffix like “nvme0n1p1”.
I am far more likely to screw that up compared to “sda” vs “sdb”. Especially since I noticed that if I have both my internal and external SSDs hooked up at boot time their number gets assigned on a seemingly random basis.
Eh? Idk if I agree. My original comment was entirely a joke based on the fact that the literal argument of=/dev/sda has no affect on my system but to address your actual point. I personally don’t find nvme naming any more confusing than SCSI. /dev/nvme0n1 is only one char away from /dev/nvme1n1 just like sda vs sdb. Additionally if you understand how the kernel comes up with those names they make a lot of sense. The first number is the controller, the second is the namespace or drive attached to that controller, the 3rd if present is the partition on the given drive. It is entirely possible to have a controller with more than one namespace. That aside aside…I think there is a genuine benefit to be argued for having USB drives, which are SCSI and fall into sdX naming separate from system drives as I dd far more USB media than system media. Making it a lot harder to screw my system up when trying to poke a flash drive.
That might make it even more dangerous, because you get used to flash to usb sticks on “/dev/sda”. And when you then use a device with a built-in sata drive, you might forget checking in a hurry.
Happened to me a once or twice. I am now only using bmap tools for this.