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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
