Re: Discussion? New names of betwork devices
On Fri, Mar 22, 2019 at 04:14:50PM -0600, ghe wrote: But when I'm looking to connect a cable, the location of the port on the outside of the box is much more useful to me than the address number on the bus. Unfortunately, the software doesn't know what was written on the outside of the box.
Re: Discussion? New names of betwork devices
On Fri 22 Mar 2019 at 17:40:43 (+0100), Hans wrote: > Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco: > > No, this is done by udev. It can be disabled, it can be configured, and > > it can be left as is. > > > I know, that the old style can be kept by either using udev (withg persistent- > net.rules for example) or by a kernel parm (something like "ifnet.rename=0, > or > similar, forgot the correct syntax) > > > > However, I discovered many packages, where are still the old names > > > preconfigured with the old names. > > > > Some examples are in order. > > > I had to correct /etc/network/interfaces, kismet, wicd-*, powertweak, snort > and some others. No big deal. I don't think we've been told whether /e/n/i needed correcting after installation, after a dist-upgrade, or some other circumstance. > > Most of the server-side packages that I can think of are either bind to all > > available interfaces by default, or bind to lo, which is still here. > > There were more the desktop users with laptops in my mind. > > > > > > I know, the last one might be problematic, because the developer never can > > > know, whhich interface is used (eth0? eth1? wlan0? whatever) > > > > Or, for instance, en0p2gibberish. They call them Unpredictable Device > > Named for a reason. > > Yes, thsis is another thing, which I am thinking of: The names could change > (in case, when there are more than one network devices are active or the > order > of activing changed). Can you elaborate on these name changes. AIUI the reason they're jokingly called Unpredictable Device Names is because anyone who's not into hardware is not going to know the name when they buy a laptop/ add a new NIC/whatever. After that, the name stays Predictable and Persistent regardless of activation, booting'sorder of discovery etc. > In the past, I forced the order with persistent- > net.rules. Dunno, if normal users can deal with it. Can it your Mom or your > Dad? Grandpa? Grandma? > > > > For myself I got the solution: just edited all configs to the new names, > > > but I believe, for unexperienced users, this could be problematic. > > > > So-called "unexperienced" users should not meddle in servers' > > configuration in the first place. > > And NIC configuration is hardly relevant for a typical desktop. > > > > > And I also believe, an unexperienced user gets in trouble, when nobody > > > points him, where to look. > > > > I don't know about that. I mean, you wrote here, isn't it? Nobody's > > stopping this hypothetical "unexperienced" users to do the same. > > Remember, this list is in English, not all people do speak English well > (included myself), and I doubt, most people want to spare the time, to crawl > through all the lists. They want it just work. > > > > > You do not need to look for a solution for me, I just wanted to remember > > > this thing and hope, we should keep this little problem in mind. Maybe > > > this is worth a discussion, if not, please excuse the noise. Cheers, David.
Re: Discussion? New names of betwork devices
On Sat 23 Mar 2019 at 23:29:07 (-0400), Felix Miata wrote: > David Wright composed on 2019-03-23 23:03 (UTC-0400): > > > On Sat 23 Mar 2019 at 04:39:21 (-0400), Felix Miata wrote: > > >> The ATX is on the left when looking at the rear from the rear with > >> the slot openings facing up. ghe wanted a frame of reference. I gave the > >> ATX > >> position, CPU position and PS/2 port position as usual "left" references, > >> and > >> last PCI slot as "right" reference. A BTX is to an ATX oppositely situated > >> adjacent to the last (if any) slot. > > > How does this differ from a race condition? > > ??? > > Relative physical positions of motherboard components are for the > motherboard's > entire life. > > Time is an implicit element of every race. > > Time can't change motherboard components' relative physical positions. It takes two to shake hands: the time it takes to complete the handshake depends on the cooperation or otherwise of the other person. Same with mobos and NICs. Cheers, David.
Re: Discussion? New names of betwork devices
deloptes composed on 2019-03-24 07:21 (UTC+0100): > Felix Miata wrote: >> Time can't change motherboard components' relative physical positions. > this is true, but to conclude that the numbering of the ethernet devices > depends on the position of the ATX or whatever is a bit too much. Keyword: "IME". I never wrote anything about "depends". What I wrote was starting from ATX power supply end of motherboard end is how it has (always) been observed here when net.ifnames=0 is on the kernel cmdline. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Discussion? New names of betwork devices
Felix Miata wrote: > Time can't change motherboard components' relative physical positions. this is true, but to conclude that the numbering of the ethernet devices depends on the position of the ATX or whatever is a bit too much. Naturally it is left to right when you look at the back. regards
Re: Discussion? New names of betwork devices
David Wright composed on 2019-03-23 23:03 (UTC-0400): > On Sat 23 Mar 2019 at 04:39:21 (-0400), Felix Miata wrote: >> The ATX is on the left when looking at the rear from the rear with >> the slot openings facing up. ghe wanted a frame of reference. I gave the ATX >> position, CPU position and PS/2 port position as usual "left" references, and >> last PCI slot as "right" reference. A BTX is to an ATX oppositely situated >> adjacent to the last (if any) slot. > How does this differ from a race condition? ??? Relative physical positions of motherboard components are for the motherboard's entire life. Time is an implicit element of every race. Time can't change motherboard components' relative physical positions. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Discussion? New names of betwork devices
On Sat 23 Mar 2019 at 04:39:21 (-0400), Felix Miata wrote: > deloptes composed on 2019-03-23 07:29 (UTC+0100): > > Felix Miata wrote: > > >> IME, using net.ifnames=0, the motherboard NIC closer to an ATX power > >> supply is always eth0. With BTX I've never had two NICs, but have to > >> suppose it would be the opposite. I think PCI(e) resources flow the same > >> direction, from CPU & PS/2 port end to last slot end. > > > interesting theory, but I must disappoint you that it is not true. Usually > > it is from the left to the right. It has nothing to do with the ATX, except > > if it would be on the left. > > What "if"? The ATX is on the left when looking at the rear from the rear with > the slot openings facing up. ghe wanted a frame of reference. I gave the ATX > position, CPU position and PS/2 port position as usual "left" references, and > last PCI slot as "right" reference. A BTX is to an ATX oppositely situated > adjacent to the last (if any) slot. How does this differ from a race condition? Cheers, David.
Re: Discussion? New names of betwork devices
I suppose I should add this. In datacenters of a certain size, when the network cabling leaves control of the OS administrators (yes, even the Wintel admins), network admins aren't there to make your life easier. You do it yourself. I encountered the same issue with SAN admins a bit later over fiber cabling to my servers. If the OS adds complication you deal with it, even if you didn't have to before. You can argue that admins should have been explicitly configuring NICs with salt, cobbler, etc. We did. On Sat, Mar 23, 2019, 2:30 PM Nicholas Geovanis wrote: > My 0.02€ > It's interesting how this topic is so often resurrected. The first time we > upgraded a RedHat server and the network interfaces were renamed, our > supervisor was.angered :-) > The issue is the order of enumeration of devices on a PCI bus. Even > identical models of NIC at the same level of firmware will become ready in > non-uniform ways. Temperature plays a role, etc. If the systemd designers > (same as the udev guys, right?) made a mistake here, perhaps it was > overreach. > > On Sat, Mar 23, 2019, 1:20 PM Mart van de Wege wrote: > >> Hans writes: >> >> > Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco: >> >> Or, for instance, en0p2gibberish. They call them Unpredictable Device >> >> Named for a reason. >> >> >> > >> > Yes, thsis is another thing, which I am thinking of: The names could >> change >> > (in case, when there are more than one network devices are active or >> the order >> > of activing changed). >> >> No. Changes in the activation order or the number of devices do not >> matter. The naming scheme is based on what bus the devices are on and >> what position on that bus they hold[1]. Once a name is assigned, unless >> you plug the card into a different slot, you will get the same name >> (note that this may not apply on hotplug architectures that don't assume >> fixed slot positions, like USB). >> >> It is the *old* way that lead to unpredictable renames unless you >> implemented udev rules to hardcode names to e.g. MAC addresses. >> >> > In the past, I forced the order with persistent- net.rules. Dunno, if >> > normal users can deal with it. Can it your Mom or your Dad? Grandpa? >> > Grandma? >> > >> Is it any worse than expecting them to write a udev rule? >> >> In the end it is a hard problem to solve because the Linux kernel does >> dynamic enumeration of devices, so you either need a deterministic >> algorithm to assign a name (ask the firmware) or a userspace workaround >> in identifying the device (e.g. using udev rules, or using UUIDs in >> /etc/fstab, etc). >> >> Mart >> >> [1] OK, not *entirely* true, it's based on what the firmware reports as >> the device position (it used to be called 'biosdevname'. Don't know if >> that still is the name in these (U)EFI times). >> >> -- >> "We will need a longer wall when the revolution comes." >> --- AJS, quoting an uncertain source. >> >>
Re: Discussion? New names of betwork devices
My 0.02€ It's interesting how this topic is so often resurrected. The first time we upgraded a RedHat server and the network interfaces were renamed, our supervisor was.angered :-) The issue is the order of enumeration of devices on a PCI bus. Even identical models of NIC at the same level of firmware will become ready in non-uniform ways. Temperature plays a role, etc. If the systemd designers (same as the udev guys, right?) made a mistake here, perhaps it was overreach. On Sat, Mar 23, 2019, 1:20 PM Mart van de Wege wrote: > Hans writes: > > > Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco: > >> Or, for instance, en0p2gibberish. They call them Unpredictable Device > >> Named for a reason. > >> > > > > Yes, thsis is another thing, which I am thinking of: The names could > change > > (in case, when there are more than one network devices are active or the > order > > of activing changed). > > No. Changes in the activation order or the number of devices do not > matter. The naming scheme is based on what bus the devices are on and > what position on that bus they hold[1]. Once a name is assigned, unless > you plug the card into a different slot, you will get the same name > (note that this may not apply on hotplug architectures that don't assume > fixed slot positions, like USB). > > It is the *old* way that lead to unpredictable renames unless you > implemented udev rules to hardcode names to e.g. MAC addresses. > > > In the past, I forced the order with persistent- net.rules. Dunno, if > > normal users can deal with it. Can it your Mom or your Dad? Grandpa? > > Grandma? > > > Is it any worse than expecting them to write a udev rule? > > In the end it is a hard problem to solve because the Linux kernel does > dynamic enumeration of devices, so you either need a deterministic > algorithm to assign a name (ask the firmware) or a userspace workaround > in identifying the device (e.g. using udev rules, or using UUIDs in > /etc/fstab, etc). > > Mart > > [1] OK, not *entirely* true, it's based on what the firmware reports as > the device position (it used to be called 'biosdevname'. Don't know if > that still is the name in these (U)EFI times). > > -- > "We will need a longer wall when the revolution comes." > --- AJS, quoting an uncertain source. > >
Re: Discussion? New names of betwork devices
Hans writes: > Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco: >> Or, for instance, en0p2gibberish. They call them Unpredictable Device >> Named for a reason. >> > > Yes, thsis is another thing, which I am thinking of: The names could change > (in case, when there are more than one network devices are active or the > order > of activing changed). No. Changes in the activation order or the number of devices do not matter. The naming scheme is based on what bus the devices are on and what position on that bus they hold[1]. Once a name is assigned, unless you plug the card into a different slot, you will get the same name (note that this may not apply on hotplug architectures that don't assume fixed slot positions, like USB). It is the *old* way that lead to unpredictable renames unless you implemented udev rules to hardcode names to e.g. MAC addresses. > In the past, I forced the order with persistent- net.rules. Dunno, if > normal users can deal with it. Can it your Mom or your Dad? Grandpa? > Grandma? > Is it any worse than expecting them to write a udev rule? In the end it is a hard problem to solve because the Linux kernel does dynamic enumeration of devices, so you either need a deterministic algorithm to assign a name (ask the firmware) or a userspace workaround in identifying the device (e.g. using udev rules, or using UUIDs in /etc/fstab, etc). Mart [1] OK, not *entirely* true, it's based on what the firmware reports as the device position (it used to be called 'biosdevname'. Don't know if that still is the name in these (U)EFI times). -- "We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source.
Re: Discussion? New names of betwork devices
Hi folks, interesting thing, I found this little article in internet: https://www.freedesktop.org/wiki/Software/systemd/ PredictableNetworkInterfaceNames/ So, it looks like, since systemd v197, all devicenames are now predictable by udev. If so (just an idea) packagers or developers may add a routine for the installation, which may ask for the actual names of the devices in the system and add them automatically into the configuration of the installing application. As these (the devicenames) will never change, also non experienced users have to quarrel with the devicenames any more. Just an idea, I do not know, how difficult it is, to write and add such a routine into the installer as a script (I am no coder). However, if one gets such a thing working, it can be used for EVERY package. My idea is, to add a variable or a special keyword into the configuration file, which will be automatically exchanged with the correct devicename. Sorry, I can not do this myself (I am no coder, did I tell you?), just sharing my ideas. Maybe someone think my ideas usefull. If not - just ignore them. In this case I apologize for all the noise. Have a nice weekend! Best Hans signature.asc Description: This is a digitally signed message part.
Re: Discussion? New names of betwork devices
deloptes composed on 2019-03-23 07:29 (UTC+0100): > Felix Miata wrote: >> IME, using net.ifnames=0, the motherboard NIC closer to an ATX power >> supply is always eth0. With BTX I've never had two NICs, but have to >> suppose it would be the opposite. I think PCI(e) resources flow the same >> direction, from CPU & PS/2 port end to last slot end. > interesting theory, but I must disappoint you that it is not true. Usually > it is from the left to the right. It has nothing to do with the ATX, except > if it would be on the left. What "if"? The ATX is on the left when looking at the rear from the rear with the slot openings facing up. ghe wanted a frame of reference. I gave the ATX position, CPU position and PS/2 port position as usual "left" references, and last PCI slot as "right" reference. A BTX is to an ATX oppositely situated adjacent to the last (if any) slot. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Discussion? New names of betwork devices
Felix Miata wrote: > IME, using net.ifnames=0, the motherboard NIC closer to an ATX power > supply is always eth0. With BTX I've never had two NICs, but have to > suppose it would be the opposite. I think PCI(e) resources flow the same > direction, from CPU & PS/2 port end to last slot end. interesting theory, but I must disappoint you that it is not true. Usually it is from the left to the right. It has nothing to do with the ATX, except if it would be on the left. Thinking is good but knowing is better! regards
Re: Discussion? New names of betwork devices
ghe composed on 2019-03-22 16:14 (UTC-0600): > But when I'm looking to connect a cable, the location of the port on the > outside of the box is much more useful to me than the address number on > the bus. > When writing software, though, the bus address becomes more important > than the location. > A labeling algorithm useful in both situations would be nice... IME, using net.ifnames=0, the motherboard NIC closer to an ATX power supply is always eth0. With BTX I've never had two NICs, but have to suppose it would be the opposite. I think PCI(e) resources flow the same direction, from CPU & PS/2 port end to last slot end. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Discussion? New names of betwork devices
On 3/22/19 1:56 PM, Joe wrote: > The 'p' is for PCI, and they are numbered for their PCI bus position. That makes some sense. But when I'm looking to connect a cable, the location of the port on the outside of the box is much more useful to me than the address number on the bus. When writing software, though, the bus address becomes more important than the location. A labeling algorithm useful in both situations would be nice... -- Glenn English
Re: Discussion? New names of betwork devices
On Fri, 22 Mar 2019 13:53:33 -0600 ghe wrote: > > The powers that be are calling my Ethernet devices enp6s0 and enp7s0. > I guess enp (EtherNet Port) is OK. But 6 and 7 aren't. There are only > two of them, and numbers on my computers don't start at 6. The 'p' is for PCI, and they are numbered for their PCI bus position. Hence the hope that the name will never change. -- Joe
Re: Discussion? New names of betwork devices
On 3/22/19 9:06 AM, Hans wrote: > since some time the names for network devices have changed. So its is no more > "ethX" , but "enp1s10" or similar or "wlan0" and now "wlp5s0". You know, what > I mean. Interesting that this came up this morning. I'm on Buster.alpha5. I tried to relabel my Ethernet interfaces the eth names a few days ago. It didn't seem to work, so I tried to undo everything I'd done. This morning, after another reboot, it came up with the eth names. The powers that be are calling my Ethernet devices enp6s0 and enp7s0. I guess enp (EtherNet Port) is OK. But 6 and 7 aren't. There are only two of them, and numbers on my computers don't start at 6. Another suggestion: The front panel of my Juniper firewall has a row of Ethernet ports across it. It calls all of those ethernet0/. Ethernet ports in the plugins in the back start at ethernet1/. Eth sounds good to me, as long as nothing non-Ethernet is labeled eth. But Juniper's naming algorithm makes a lot of sense. The connectors on the motherboard could be called eth0. And added boards could be eth1, 2, 3, etc. > This is made by the kernel. Not in Buster.alphs5, it ain't. The naming is quite complex, and there are several files that've been chattr'ed so they cant be changed. > However, I discovered many packages, where are still the old names > preconfigured with the old names. Change them to check the Ethernet port labels? I suspect that'd be fairly easy for the Debian maintainers. But udev can do all this well and nicely, if people'd just leave it alone and let it do its job. And make sure things use the correct device labels. -- Glenn English
Re: Discussion? New names of betwork devices
On Fri, Mar 22, 2019 at 05:40:43PM +0100, Hans wrote: > Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco: > > No, this is done by udev. It can be disabled, it can be configured, and > > it can be left as is. > > > I know, that the old style can be kept by either using udev (withg persistent- > net.rules for example) or by a kernel parm (something like "ifnet.rename=0, > or > similar, forgot the correct syntax) They did confuse you. All this renaming is done by udev. Kernel does not need "net.ifnames" at all as it names network interfaces in the first place. Udev abuses kernel commandline do grab "net.ifnames", and then udev's rules check the parameter. > > > However, I discovered many packages, where are still the old names > > > preconfigured with the old names. > > > > Some examples are in order. > > > I had to correct /etc/network/interfaces, User-written by definition. > kismet, Yep, that's valid. I prefer aircrack-ng though. > wicd-*, Probably. ifupdown is more than enough for me (that includes 802.11x), but don't they give a GUI for wicd? > powertweak, [1]. Is it a Debian package at all? > snort Comes with debconf and interface detection as far I can see it. But I accept this particular one for the sake of simplicity. > > Most of the server-side packages that I can think of are either bind to all > > available interfaces by default, or bind to lo, which is still here. > > There were more the desktop users with laptops in my mind. Does not invalidate my point. One can install a server package on a laptop if a need arises. I have nginx installed on my *phone* because it's convenient, for instance. > > > I know, the last one might be problematic, because the developer never can > > > know, whhich interface is used (eth0? eth1? wlan0? whatever) > > > > Or, for instance, en0p2gibberish. They call them Unpredictable Device > > Named for a reason. > > > > Yes, thsis is another thing, which I am thinking of: The names could change > (in case, when there are more than one network devices are active or the > order > of activing changed). Long story short, they invented Unpredictable Device Names to prevent this very scenario. I'm aware of one major case when it failed miserably (VMWare), and two minor ones (renaming didn't happen for virtio, and cannot be configured for USB devices). > In the past, I forced the order with persistent-> net.rules. Dunno, if > normal users can deal with it. I don't hold by breath. > > > For myself I got the solution: just edited all configs to the new names, > > > but I believe, for unexperienced users, this could be problematic. > > > > So-called "unexperienced" users should not meddle in servers' > > configuration in the first place. > > And NIC configuration is hardly relevant for a typical desktop. > > > > > And I also believe, an unexperienced user gets in trouble, when nobody > > > points him, where to look. They have this list here. They have LUGs. They have serverfault/stackoverflow (I know, it's a bad manners to mention *these*). Last, but not least, there's paid support. > > I don't know about that. I mean, you wrote here, isn't it? Nobody's > > stopping this hypothetical "unexperienced" users to do the same. > > Remember, this list is in English, not all people do speak English well > (included myself), Ditto. But this list is where all the fun happens, so I hang here. And yes, it has surprising variance of questions. > and I doubt, most people want to spare the time, to crawl > through all the lists. They want it just work. If one desires that one should pay someone who can actually force a device do the job. No amount of pre-configuration can change that. Even if we're considering M$/Apple. Reco [1] https://packages.debian.org/search?searchon=names&suite=all§ion=all&sourceid=mozilla-search&keywords=powertweak
Re: Discussion? New names of betwork devices
Am Freitag, 22. März 2019, 17:15:29 CET schrieb Reco: > Hi. Hi Reco, > > No, this is done by udev. It can be disabled, it can be configured, and > it can be left as is. > I know, that the old style can be kept by either using udev (withg persistent- net.rules for example) or by a kernel parm (something like "ifnet.rename=0, or similar, forgot the correct syntax) > > However, I discovered many packages, where are still the old names > > preconfigured with the old names. > > Some examples are in order. > I had to correct /etc/network/interfaces, kismet, wicd-*, powertweak, snort and some others. No big deal. > > Most of the server-side packages that I can think of are either bind to all > available interfaces by default, or bind to lo, which is still here. There were more the desktop users with laptops in my mind. > > > I know, the last one might be problematic, because the developer never can > > know, whhich interface is used (eth0? eth1? wlan0? whatever) > > Or, for instance, en0p2gibberish. They call them Unpredictable Device > Named for a reason. > Yes, thsis is another thing, which I am thinking of: The names could change (in case, when there are more than one network devices are active or the order of activing changed). In the past, I forced the order with persistent- net.rules. Dunno, if normal users can deal with it. Can it your Mom or your Dad? Grandpa? Grandma? > > For myself I got the solution: just edited all configs to the new names, > > but I believe, for unexperienced users, this could be problematic. > > So-called "unexperienced" users should not meddle in servers' > configuration in the first place. > And NIC configuration is hardly relevant for a typical desktop. > > > And I also believe, an unexperienced user gets in trouble, when nobody > > points him, where to look. > > I don't know about that. I mean, you wrote here, isn't it? Nobody's > stopping this hypothetical "unexperienced" users to do the same. Remember, this list is in English, not all people do speak English well (included myself), and I doubt, most people want to spare the time, to crawl through all the lists. They want it just work. > > > You do not need to look for a solution for me, I just wanted to remember > > this thing and hope, we should keep this little problem in mind. Maybe > > this is worth a discussion, if not, please excuse the noise. > > That's OK. It's Friday and it's been an eventful week, so a list can use > a flamewar. > No, a flamewar will be funny for some people, but IMO it has got not much worth. For myself, I can only tell: Upredictable Device Name is nice, but only a good idea for specialists. But this is my opinion, and no one is forced, to take it over. Happy hacking and a nice weekend! > Reco Best Hans signature.asc Description: This is a digitally signed message part.
Re: Discussion? New names of betwork devices
Hi. On Fri, Mar 22, 2019 at 04:06:33PM +0100, Hans wrote: > Hi folks, > > since some time the names for network devices have changed. So its is no more > "ethX" , but "enp1s10" or similar or "wlan0" and now "wlp5s0". You know, what > I mean. Yep, so called Unpredicable Device Names. > This is made by the kernel. No, this is done by udev. It can be disabled, it can be configured, and it can be left as is. > However, I discovered many packages, where are still the old names > preconfigured with the old names. Some examples are in order. > I think, this may be led to confusion, so let > me offer some suggestions: > > - during installation there should be an advice, to check the name of the > interface File a "wishlist" bug report against an appropriate package. > - interface entries should be generally commented, so that the user has > forcedly to check the entry Most of the server-side packages that I can think of are either bind to all available interfaces by default, or bind to lo, which is still here. > I know, the last one might be problematic, because the developer never can > know, whhich interface is used (eth0? eth1? wlan0? whatever) Or, for instance, en0p2gibberish. They call them Unpredictable Device Named for a reason. > For myself I got the solution: just edited all configs to the new names, but > I > believe, for unexperienced users, this could be problematic. So-called "unexperienced" users should not meddle in servers' configuration in the first place. And NIC configuration is hardly relevant for a typical desktop. > And I also believe, an unexperienced user gets in trouble, when nobody > points him, where to look. I don't know about that. I mean, you wrote here, isn't it? Nobody's stopping this hypothetical "unexperienced" users to do the same. > You do not need to look for a solution for me, I just wanted to remember this > thing and hope, we should keep this little problem in mind. Maybe this is > worth a discussion, if not, please excuse the noise. That's OK. It's Friday and it's been an eventful week, so a list can use a flamewar. Reco
Discussion? New names of betwork devices
Hi folks, since some time the names for network devices have changed. So its is no more "ethX" , but "enp1s10" or similar or "wlan0" and now "wlp5s0". You know, what I mean. This is made by the kernel. However, I discovered many packages, where are still the old names preconfigured with the old names. I think, this may be led to confusion, so let me offer some suggestions: - during installation there should be an advice, to check the name of the interface or - interface entries should be generally commented, so that the user has forcedly to check the entry or - preconfigure (and repreconfigure) configs, which are preinstalled with the new names I know, the last one might be problematic, because the developer never can know, whhich interface is used (eth0? eth1? wlan0? whatever) For myself I got the solution: just edited all configs to the new names, but I believe, for unexperienced users, this could be problematic. And I also believe, an unexperienced user gets in trouble, when nobody points him, where to look. You do not need to look for a solution for me, I just wanted to remember this thing and hope, we should keep this little problem in mind. Maybe this is worth a discussion, if not, please excuse the noise. Best regards Hans signature.asc Description: This is a digitally signed message part.
