[systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 15-04-16 18:06:
> 
> 
> Am 15.04.2016 um 18:02 schrieb Xen:
>> Reindl Harald schreef op 15-04-16 17:55:
>>>>> so 3 seconds is unacceptable and the idea ist a joke in general
>>>>> because
>>>>> you wait for something possibly happen while you don't know how
>>>>> long you
>>>>> have to wait and jsut hope for luck - that's not a good design and
>>>>> won't
>>>>> bew accepted anywhere
>>>>
>>>> You are the only one taking 3 seconds seriously as something to hang
>>>> onto just so you can say that I am full of shit
>>>
>>> it don't matter *how long* you wait for something you don't know if it
>>> ever appears and how long it take to appear - period
>>
>> That's why you *don't* and you just proceed with it in line with the
>> current booting of the system, you just postpone the renaming to a later
>> stage where you rename all in one go, instead of each time a device is
>> discovered
> 
> * you don't know *when* that later is
> * until that has happened all other services have to wait
> * this won#t work in real life
> * if it would work that way it would have been implemented
> 
> HONESTLY: i *hate* that predictable stuff too, i don't need it, i
> disable it and would prefer that the ones who *really* need it has to
> enable it instead you need to touch your config on the majority of
> machines which have only one NIC (since current mainboards don't have
> dualport NICs as some yaers ago)
> 
> BUT: i would be careful to pretend i have a doable solution which works
> for *all* usecases when people working for many years on the kernel did
> not found one

Well thank you for these kind words.

But what you say is just not entirely accurate.

You do not respond to this statement that by default, and by definition,
almost, networking services have to wait on networking hardware anyway.

The only time when what you say would make sense, if is there exists the
condition where *some* networking devices are allowed to show up at a
later time, and networking *services* are capable of dealing with that.
I do not think that is common reality and current boot systems are also
not designed around that. I mean, am I so stupid here or is this just
common sense?

Show me the system that can handle networking devices showing up after
network service start on those devices.

Either it knows what to wait for, or it will fail.

So not all other services would have to wait, only network services, and
you do NOT wait, you just go ahead.

At least if what I say makes sense, but what you have said until now
does not disprove that. And there are other solutions as well.

*The udev solution that uses biosdevname (program) falls completely
along the line of what I have proposed here and it already exist, it is
packaged, and apparently it works*. It is apparently a udev rule that
renames devices one by one (in the all_ethX policy) provided there is no
hotplugging.

If this system already exists and demonstrably works, why are you
battling against it? Just because I am stupid or have a big mouth???

> * if it would work that way it would have been implemented

Not if political choices are being made. Conversely, only if those
kernel/systemd developers are somehow infallable beings that never make
a partial choice.

> BUT: i would be careful to pretend i have a doable solution which
> worksfor *all* usecases when people working for many years on the
> kernel did not found one

That entirely depends on what interests they are trying to harmonize
with each other and this is a willfull choice.

If you want every house to have a sink, and you also want every house
for the new owners to choose their own sink, you will have a problem
because these things cannot be united.

These designers have wanted ALL linux systems to have like hardware
addresses encoded into network device names.

Andrei suggested that this is just impossible to begin with.

He also suggested that other vendors have different solutions.

For instance, Windows from what I know keeps a track record of devices
and only changes something about their configuration if they suddenly go
missing or new ones appear.

The Linux kernel / system does not normally maintain persistent records
of what hardware has been found and retries the same procedures on every
boot.

Even simply maintaining a saved mapping of
hardware-address-to-device-names would instantly solve this issue
provided you provide for a way to handle mutations.

That is because if hardware-addresses in this case are reliable and
persistent, the device names they are mapped to would be identical on
each boot as it would not depend on the time the driver or device made
itself known.

Gives its own complications but this is what Windows has done (I believe).

Moreoever you can also use different froms of identification such as
vendor ID and all of that. You don't have to use hardware address
exclusively.

If I remove a device from my slot the sound card in the next slot will
have a different address and now the configuration for the sound card
fails because it doesn't know that the new device at the new position is
the same device as that at the old position. That's just stupid.

My configuration now contains two devices -- one defunct, the other
there -- and I cannot even manipulate that normally.

That falls along the lines of what we are talking about here:


* Any kind of persistent mapping that saves data on /etc and keeps using
that same mapping would solve all of the "regular" problems that were
used as forming the basis for this new scheme.

It's obvious. Other operating systems do that too.

Oh, by the way, I believe you should not underestimate mr. Borkenzov
either. I do not know much about you (Andrei) but I do know he has
worked on Grub for instance. I don't think you are talking to a novice
there if that is what you think.

If you have no persistent record on disk, you get to the issue of "how
do we emulate that".

And in this case we emulate that by pretending or hoping that if we wait
long enough IN the boot process (not actually waiting, not actively
prolonging) that the devices we need will all be present so that we can
make an automated default choice that is going to be persistent across
reboots.

Never said it was going to be a perfect solution. It was just a
solution. If you have something better, name it, but I think that some
people may not want to change the solution for political reasons, rather
than technical ones.

Again: the system we have now favours a very select class of system
administrators and is only intended to saveguard against the possible
anomolous situation where some important dude has forgotten to turn the
system on and suddenly sees some massive data breach happening.

Most of that. (Why else turn it on by default?).

My original statements were about the DEFAULT.

A default is usually a form of political choice.

Microsoft hiding extensions by default in the file explorer. A choice
about what they want people to be, not what actually works for most people.

The "hidden extensions" in Windows Explorer is one of the most glaring
examples of a political choice that does not really serve anyone,
because it makes regular computer work much harder for basically
everyone. Icons are absolutely no fit way to differentiate between
different classes of files. I doubt any Linux designer has ever even
considered hiding extensions of files.

It's wishful thinking on Microsoft's part. It is not a technical choice.

So we see that most defaults are not going to be about technicians but
about people dealing with people and also with clients.

In this case the default is absolutely no necessity unless you want to
prevent a certain very specific event or class of events from occurring.

My original thread was about the default.

I wanted a discussion about the default.

In this my second thread, I just proposed something that could end up
being at least an idea of something that would glue together both groups
of people. I mean something that could be a common solution for more
people, instead of what we have now, which is just not.

What we have now is "fuck you, we don't care about you, our clients want
this".

Michael Jackson: All I wanna say is that, they don't really care about us.

I have not heard any actual technical objections to what I proposed. In
order to object to it you need to make plausible the idea that
networking can get started before all devices are found, as well as that
people have thought about what would or should happen if they do / it
does. Thus far everyone (mostly you perhaps) has ignored that.

The whole renaming thing could be run as a boot target as a prereq of
networking starting.

This is only meant to "simulate" a persistent record of what device
should be called what.

Apparently biosdevname /already does/ what I propose here, or can do it
(using all_ethX). Anyone sufficiently knowledgeable would probably be
able to say "Oh yeah, that, we can do it, but ....".

But what we see happening is that:

* I propose something with a certain amount of technical detail
* Someone doesn't like where this is going
* That person attacks my idea on some technical impossibility that would
not be relevant if the broader outline of the idea were followed and the
people with knowhow would actually design a solution around that.

What we see is not technical limitation, but unwillingness.

So what I say is: don't get hung up on details but think along to reach
a point where it actually does work.