2018-03-31
Using a local database to get consistent device names is a bad idea
People like consistent device names, and one of the ways that Unixes have historically tried to get them is to keep a local database of known devices and their names, based on some sort of fingerprint of the device (the MAC address is a popular fingerprint for Ethernet interfaces, for example). Over the years various Unixes have implemented this in different ways; for example, some versions of Linux auto-created udev rules for some devices, and Solaris and derivatives have /etc/path_to_inst. Unfortunately, I have to tell you that trying to get consistent device names this way turns out to be a bad idea.
The fundamental problem is that if you keep a database of local device names, your device names depend on the history of the system. This has two immediate bad results. First, if you have two systems with identical hardware running identical software they won't necessarily use the same device names, because one system could have previously had a different hardware configuration. Second, if you reinstall an existing system from scratch you won't necessarily wind up with the same device names, because your new install won't necessarily have the same history as the current system does.
(Depending on the scheme, you may also have the additional bad result that moving system disks from one machine to an identical second machine will change the device names because things like MAC addresses changed.)
Both of these problems are bad once you start dealing with multiple systems. They make your systems inconsistent, which increases the work required to manage them, and they make it potentially dangerous to reinstall systems. You wind up either having to memorize the differences from system to system or needing to assemble your own layer of indirection on top of the system's device names so you can specify things like 'the primary network interface, no matter what this system calls it'.
Now, you can have this machine to machine variation problems even with schemes that derive names from the hardware configuration. But with such schemes, at least you only have these problems on hardware that's different, not on hardware that's identical. If you have truly identical hardware, you know that the device names are identical. By extension you know that the device names will be identical after a reinstall (because the hardware is the same before and after).
I do understand the urge to have device names that stay consistent even if you change the hardware around a bit, and I sometimes quite like them myself. But I've come to think that such names should be added as an extra optional layer on top of a system that creates device names that are 'stateless' (ie don't care about the past history of the system). It's also best if these device aliases can be based on general properties (or set up by hand in configuration files), because often what I really want is an abstraction like 'the network interface that's on network X' or 'the device of the root filesystem'.
My new Linux home machine for 2018
Back in the fall I planned out a new home machine and then various things happened, especially Meltdown and Spectre (which I feel made it not a great time to get a new CPU) but also my natural inertia. This inertia sort of persisted despite a near miss scare, but in the end I wound up losing confidence in my current (now old) home machine and just wanting to get things over with, so I bit the bullet and got a new home machine (and then I wound up with questions on its graphics).
(There will be better CPUs in the future that probably get real performance boosts from hardware fixes for Meltdown and Spectre, but there are always better CPUs in the future. And on my home machine, I'm willing to run with the kernel mitigations turned off if I feel strongly enough about it.)
The parts list for my new machine is substantially the same as my initial plans, but I made a few changes and indulgences. Here's the parts list for my future reference, if nothing else:
- Intel Core i7-8700K
- This is the big change from my initial plans,
where I'd picked the i7-8700. It's an indulgence, but I felt like
it and using an overclocking capable CPU did eliminate most of
my concerns over high-speed DDR4 memory.
I'm not overclocking the 8700K because, well, I don't. After I
didn't run into any TDP issues with my work machine
and its 95W TDP Ryzen, I decided that I didn't have any concerns
with the 8700K's 95W TDP either.
(My concerns about the TDP difference between the 8700K and the 8700 turn out to be overblown, but that's going to be another entry.)
- Asus PRIME Z370-A motherboard
- I saw no reason to change my initial
choice (and it turns out Phoronix was quite positive about it
too,
which I only found out about later). The RGB LEDs are kind of
amusing and they even show a little bit through the some air
vents on the case (especially in the dark).
- 2x 16GB G.Skill Ripjaws V DDR4-3000 CL15 RAM
- I can't remember if
the G.Skill DDR4-2666 modules were out of stock at the exact point
I was putting in my order, but they certainly had been earlier
(when I assembled the parts list at the vendor I was going to
use), and in the end I decided I was willing to pay the slightly
higher cost of DDR4-3000 RAM just as an indulgence.
(Looking at the vendor I used, the current price difference is $4 Canadian.)
I opted not to try to go faster than DDR4-3000 because the RAM modules I could easily see stopped having flat CL timings above that speed; they would be eg CL 15-18-18-18 instead of a flat CL15. There were some faster modules with flat CL timings, but they were much more expensive. Since I think I care more about latency than slight bandwidth increases, I decided to stick with the inexpensive option that gave me flat latency.
- Noctua NH-U12 CPU cooler
- I quite liked the Noctua cooler in
my work machine, so I just got the general
version of it. I've been quite happy on my work machine not just
with how well the Noctua cooler works, but also how quiet it is
with the CPU under heavy load (and in fact it seems quite difficult
to push the CPU hard enough that the Noctua's fan has to run very
fast, which of course helps keep any noise down).
In short: real (and large-ish) CPU coolers are a lot better than the old stock Intel CPU coolers. I suppose this is not surprising.
(The Noctua is not inexpensive, but I'm willing to pay for quality and long term reliability.)
- EVGA SuperNova G3 550W PSU
- As with my work machine, the
commentary on my original plans pushed me to
getting a better PSU. Since I liked this in the work machine, I
just got it again for the home one. It's an amusing degree of
overkill for the actual measured power draw of either machine,
but I don't really care about that.
(For my own future reference: always use the PSU screws that come with the PSU, not the PSU screws that may come with the case.)
- Fractal Design Define R5 case
- I got this in white this time
around (the work version is black). The story about the colour
shift is that we recently built a new Ryzen based machine for one
of my co-workers and basically duplicated my work machine for
the parts list, except his case is white because he didn't care
and it was cheaper and in stock at the time. When
his case came in and I got a chance to see it in person, I decided
that maybe I liked the white version better than the black one
and in the end my vacillation settled on the white one.
(When I pulled the trigger on buying the hardware, the two case colours were the same price (and both in stock). So it goes.)
- LG GH24NSC0 DVD/CD Writer
- I gave in to an emotional temptation
beyond the scope of this entry and got an optical drive, despite
what I'd written earlier. But
I haven't actually installed it in the case; it's apparently
enough that I could if I wanted to.
(It helps that powering the drive would be somewhat awkward, because the PSU doesn't come with SATA modular cables that are long enough or have enough plugs on them.)
I'm running the RAM at full speed by activating its XMP profile in the BIOS, which was a pleasant one-click option (without that it came up at a listed 2133 Mhz). There didn't seem to be a one-click option for 'run this at 2666 MHz with the best timings it supports', so I didn't bother trying to set that up by hand. The result appears stable and the BIOS at least claims that the CPU is still running at its official normal speed rating.
(Apparently it's common for Intel motherboards to default to running DDR4 RAM at 2133 MHz for maximum compatibility or something.)
In general I'm quite happy with this new machine. It's not perfect, but nothing seems to be under Linux, but everything works, it's pretty nice, and it's surprisingly fast. Honestly, it feels good simply to have a modern machine, especially one where I can't clearly hear the difference between an idle machine and one under CPU load.
(There's still a little bit of noise increase under full load, but it's pretty subtle and I have to really pay attention in a quiet environment to hear it. On my old machine, the stock Intel CPU cooler spinning up created a clearly audible difference in noise that I could hear over, eg, my typing. The old machine might have been improved by redoing the thermal paste, but my old work machine, with the redone paste, still had the same sort of audibility under load.)
After my experiences with UEFI on my work machine, I didn't try to switch from BIOS booting to UEFI on this one either (contrary to earlier plans for this). The two machines probably have somewhat different BIOSes (although their GUIs look very similar), but I didn't feel like taking the chance and I've wound up feeling that BIOS boot is better if you're using a mirrored root filesystem (which I am), fundamentally due to an unfortunate Linux (or Fedora) GRUB2 configuration choice.
PS: Given my experiences with Ryzen on my new work machine (eg, and), I wound up with absolutely no interest in going with a Ryzen home machine. This turned out to be a good choice in general, but that's another entry.
(The short version is on Twitter.)