Didier Kryn <kryn@???> writes:
> Le 03/10/2015 09:49, Simon Hobson a écrit :
>> Lets face it - there is no "right" answer to this other than a system
>> with enough intelligence to read the user/admin's mind and work out
>> what they intend to happen - and I think we're a bit off that yet !
>> Looking back, I think I've "moved" something at least as often as
>> I've replaced it with a different something in the same location -
>> probably more in fact.
>

>     This is exactly the point. But let's consider which devices are a
> concern.

>

>     As was remarked already, disks are no longer a problem since
> partitions are uniquely identified, so that nobody cares of a random
> device name. And even symlinks are created in /media, named after the
> labels of the partitions.

All of these 'UUID' and 'partition labeling' is the exact same kind of
workaround for the exact same kind of "udev design strangeness" as for
the ethernet interfaces and I'm not using that anywhere except on a 'USB
install disk' where the intended root partition needs to be found by the
booting kernel and OS regardless of which mass storage devices may be
found as part of the computer the system is booting on. Which is how
these things should work: Use the more complicated solution for the more
complicated case, don't just use it for the simple cases because it can
also handle them.

[...]

>     Ethernet interfaces are maybe the only issue, which explains why
> distros have implemented a solution by the means of udev rules. The
> way it is implemented is secure: every new ethernet device is given a
> new device name (ethX) and no entry is created in
> /etc/network/interfaces; therefore the interface isn't connected
> without an action of the admin. If it is a replacement, then the admin
> should just edit the MAC address in
> /etc/udev/rules.d/70-persistent-net.rules. Not a big deal, compared to
> replacing the hardware.

As I already wrote: A file

/etc/udev/rules.d/75-persistent-net-generator.rules

can be created (on Debian up to wheezy at least) to avoid this "install
the system to new hardware and get a whole bunch of new ethN instead of
the onese which aren't available anymore" mess altogether.

>     The new policy Poettering et al are enforcing means to relieve the
> admin from this little and rare work, at the cost of a nightmare for
> all the rest.

It's not that simple as MAC addresses are neither necessarily persistent
nor necessarily unique. Eg, by default, so-called "virtual ethernet pair
interface" (used to connect containers to physical interfaces via bridge
interfaces) use random MAC addresses. It's also often/ usually possible
to change the MAC address of an interface. That's just something the
people who came up with the previous less-than-bright idea didn't think/
know about at the time they did come up with it (according to the 'code
comment' documenting the new scheme).