Context for newbies: Linux refers to network adapters (wifi cards, ethernet cards, etc.) by so called “interfaces”. For the longest time, the interface names were assigned based on the type of device and the order in which the system discovered it. So, eth0, eth1, wlan0, and wwan0 are all possible interface names. This, however, can be an issue: “the order in which the system discovered it” is not deterministic, which means hardware can switch interface names across reboots. This can be a real issue for things like servers that rely on interface names staying the same.
The solution to this issue is to assign custom names based on MAC address. The MAC address is hardcoded into the network adaptor, and will not change. (There are other ways to do this as well, such as setting udev rules).
Redhat, however, found this solution too simple and instead devised their own scheme for assigning network interface names. It fails at solving the problem it was created to solve while making it much harder to type and remember interface names.
To disable predictable interface naming and switch back to the old scheme, add net.ifnames=0 and biosdevname=0 to your boot paramets.
The template for this meme is called “stop doing math”.
Good lord, this is a top tier meme!
Thanks, glad you like it! I spent quite some time re-making the template from scratch in inkscape, because the original meme din’t have enough space for the text
Heck yeah, vectorised libre memes ftw!
I often do the same for my memes. I like them high quality
You could have definitely gotten a longer interface name for that one example. enp0s31f6mon might be a good one lol
As someone who worked on a pre-systemd linux system with multiple NICs and needed them all configured automatically from an OS image based on where it was in the rack, I can’t stress enough how good deterministic interface names are.
Booting up a system and each time having different names for each NIC was a nightmare.
Frankly 90+% of what systemd has done is tremendously positive and makes linux a better operating system to use, both for sys admins and end users.
Love the explainer to the meme.
Keep up the good work!
Thanks! Memes as education material / propaganda FTW
I was going to commend you as well. Top notch. I appreciate it
I came here to say this. I don’t really do networking so I don’t have much care for this issue, but the clarity of the explanation was enjoyable. Plus I learned a couple of little things too.
Here I am on a laptop with no ethernet ports (probably works over USB-C? No idea, haven’t tried), and a single wifi adapter. Guess I’ll give it a try:
ip link showWhat I expected
wlan0What I got
wlp242s0Neat 👍 😎 👍
enp2s0,wlp3s0, and my favenp4s0f3u1u3
I laughed so hard. Then I cried remembering good old days of
eth0.I laughed but now that I know it I’m going to change the udev rules back to eth0.
Holy shit. I must be really old.
eth0? No no, we need wlps0n1pn2d4es6vsd9c69420
I actually prefer the eth0 and wlan0.
For regular PCs or laptops, which generally have at most one of each type of adapter, I don’t see any reason not to.
That’s what the meme is saying too
Is it though? Normally it’s ironic: https://knowyourmeme.com/memes/stop-doing-math
This time it isn’t (I think)
Also, make sure your password contains L’s, 1’s, 0’s and O’s in a font deliberately chosen to make them hard to tell apart.
And commas! To mess with the CSV file that it will inevitably be dumped into!
I have no idea at all of what this is about but I feel strongly that OP is right and we must urgently fix this disgusting problem we are facing with the interfaces. Get em, OP, get the bastards. Solidarity
Having no idea what this is about and being on a Linux meme subreddit is absolutely peak Lemmy.
Solidarity, Reg.
Was that a terry pratchett reference?
Life of Brian
Redhat, however, found this solution too simple and instead devised their own scheme for assigning network interface names. It fails at solving the problem it was created to solve
I somehow first read “Redhat” as “Reddit” in this sentence, and so was briefly thinking that perhaps this bad idea originated there 😂
“reddit makes a linux distro” would be hilarious and terrifying
“the order in which the system discovered it” is not deterministic
This is the same problem they had with hard drive names and it seems to have been solved in a sensible way, i.e. /dev/sda still points to the first disk detected by the system, but you can look look in /dev/disk/by-path (or by-uuid, etc) to see the physical address of the devices on the system and what they are symlinked back to, and set your fstab or mdadm arrays to be configured based on those unique identifiers instead.
So, I guess what I’d like to know is why hasn’t this been solved the same way? When you boot up they should present every hard wired Ethernet port as
ethX, and the hardware address interface should be present as well but aliased back to theeth. Then you can build the your network configs based on either one.Shouldn’t be that hard right?
Cries in
nvme1n1p6, which is my current OS partition.As a data center engineer of 10+ years, I struggled to understand this at first. In my world, the hardware does a POST before the OS boots and has an inventory of what hardware components are available, so it shouldn’t matter in what order they are discovered, since the interface names should make a correlation between the interface and the pcie slot that NIC exists in.
Where the water gets muddled is in virtualized servers. The NICs no longer have a correlation to a specific hardware component, and you may need to configure different interfaces in the virtualized OS for different networks. I think in trying to create a methodology that is agnostic to bare metal/virtualized OSs, it was decided that the naming convention should be uniform.
Probably seems like bloat to the average admin who is unconcerned with whether these NICs are physical or virtual, they just want to configure their server.
But nobody uses /dev/sdX anymore (not after they wipe the wrong disk once anyway). They either use logical UUIDs or hardware WWN/serial.
Yeah, the point is “you can use either one”, instead of “we made the choice for you”
idk man I use /dev/sdX when running commands interactively and PARTLABELs in my
/etc/fstab. All those letters and numbers in UUIDs are too much for my monkey brain to handle lol
Kernel parameters? This is a udev thing, just change the udev rule.
It’s amazing how many linux problems stem from ‘Redhat, however, found this solution too simple and instead devised their own scheme’. Just about every over complex, bloated bit of nonsense we have to fight with has the same genesis.
What I really don’t understand is why distro maintainers feel the need to actually go along with these changes. Like, sure, if this predictable interface naming thing worked as intended, I can definitely see how it can be useful for server administrators. You could just hardcode the automatic interface names instead of assigning them manually in
/etc/mactab. But why would the rest of us ever need this? Most personal machines have at most one wifi card and one ethernet device, sowlan0andeth0are perfectly predictable. And even if you have multiple wifi or ethernet adapters, your networking is probably handled by network-manager, so you never actually have to put interface names into config files. Why force enterprise-grade bloat on users who just want a simple desktop experience?As to why distro maintainers go along, if you had to vet every time the network stack updated and make sure it doesn’t break your custom solution to predictable naming, you’d probably just go along with it and let anyone that needed it devise and maintain their own solution. 99% of users won’t worry about it.
Personally I’d do away with NetworkManager too and just configure the interfaces directly, but that might just be me being old and grumpy!
I think most distros go along because their upstream did. There are comparatively few ‘top level’ distributions, the main ones (by usage) being Redhat and Debian. Most everything else branches from those. Redhat’s got enough clout on the market that there’s a sort of pull towards complying with it just to not be left put.
I use Debian, but I think they’re crazy for swallowing everything Redhat pushes, they could easily stick to the cleaner options and have a better system for it. At least they let you opt out of systemd, so life is a little more tolerable.
Personally I’d do away with NetworkManager too and just configure the interfaces directly
Connman and iwd have nice graphical interfaces btw. I got that route after nm disbehaved and i couldn’t figure out why (same for systemd and s6/dinit after systemd-dnsd threw a fit).
I’d do away with network-manager on a stationary system too, but I’m on a laptop, and unless there’s some trick I don’t know about, configuring wifi by hand for every new network I come across sounds like a bit of a pain. Especially for corporate/institution network that use fancy things like PEAP
If by “configuring wifi by hand” you mean writing config files by hand, that’s actually not necessary with plain wpa_supplicant too. There is
wpa-gui(orwpa-cuteif you prefer Qt over GTK), which is basically a GUI frontend to wpa_supplicant, which makes adding new networks nearly as easy as with NetworkManager. But it’s a far less modern looking UI than the NM frontends.Thanks for the info, I’ll take a look. “far less modern looking” is a selling point for me haha. Give me those win95-looking gtk2 interfaces!
That’s fair, it does make sense to use it on a laptop, but it really should be the sort of thing you add when needed rather than having it jammed in whether it’s useful or not.
Every time I need to do something even slightly different to a basic setup I find myself inventing new curses for those who screwed things up with these overblown, over complex, minimally functional abominations. Just give me vi and the basic configuration files and let me get on with it!
I find myself inventing new curses for those who screwed things up with these overblown, over complex, minimally functional abominations
Gosh, tell me about it. I once tried writing a custom wifi signal strength indicator app that got its information from network-manager. Apparently the only way to programmatically communicate with network-manager is through dbus, which is just terrible. Scarce to no documentation, poor support for any language other than C/C++, and once you do get it working, it’s the most disgusting and overly verbose code you’ve ever seen, just to query the status of the wifi card. Could’ve exposed the API through raw unix sockets or something, but nope, they had to reinvent the wheel on that one as well.
Just give me vi and the basic configuration files and let me get on with it!
I’ll take this opportunity to shill for Void Linux, it sounds like exactly what you’re describing. I’ve been a happy user for like 5 years now. I particularly like how nothing ever breaks, because there’s not much to break on such a minimal system.
…well, actually, a few things did break over the years, but most of those were due to user error haha.
In news that will shock no-one, dbus was, of course, initially created by a Redhat engineer. I get the idea of having a general purpose bus that everything can communicate on, but they somehow managed to even make that complex.
You make a compelling case for Void Linux. I use Debian or a RHEL derivative for work, primarily so there’s at least a chance to hand systems off to someone else to maintain, the less known distros seem to meet with blank looks.
I want to give NixOS a try sometime, as I like the idea of declaritively defining the system
I want to give NixOS a try sometime, as I like the idea of declaritively defining the system
That seems to be even more convoluted and complex.
“Just one more abstraction layer, I swear!”
I’m a NixOS noob bytheway, so please correct me if I’m wrong.
To me it seems they followed the hdd UUID style, rather than sda0 or hda0 that can change at boot you now have a fixed UUID to work with. I can see this being important on larger server networks
But the SSD/HDD solution doesn’t replace /dev/[s|h]da# entirely, just adds a consistent way to set them in configs like fstab. You can still use the old device names so working with them at the command line is still easy for the most part.
It’s amazing how many of those started with Lennart, too.
He’s definitely off my Christmas card list. He seems desperate to leave a legacy, but he keeps trying to turn Linux into windows instead.
If anything, he gets most of his inspiration from MacOS.
He may have taken some ideas from there, but I still see more windows like ideas. We’re one bad decision away from
systemd-regedit. If that happens, I might just give up completely.systemd-regedit
That’s just dconf lol. It sounds great in theory – after all, isn’t bringing standardization to a chaotic battlefield of different formats a good thing? But in practice it’s absolute garbage. I would much rather just edit a config file. Heck, even if you program uses some obscure config format like xml or something language-specific like
.luaor.py, I would much rather take a few minutes to learn the specifics of your format than fuck around with dconf. Fuck dconf.Yes, yes, but now lets take that, make it dependent on the session management system and dns resolver for some reason, make the command longer and more convoluted and store the results in one or more of a dozen locations! It’ll be great!
/s
Dconf is bad, just imagine how bad a systemd version would be.
Considering how much systemd breaks the concept of “everything is a file”, this would not surprise me in the least
“everything is a file” is such a godsend. It makes absolutely everything so much easier and intuitive. I remember trying to get an old dot matrix printer to work using a parallel-to-usb adaptor cable. Without reading any documentation or having any prior experience I tried
echo testing12345 > /dev/lp0and it just worked lol. Meanwhile my friend spent like half an hour digging in windows gui settings trying to figure out how to print to a parallel printer.I also posted about this before, but a while back I had to configure my system so that a non-root user could start and stop a root daemon without sudo. On a runit system all you have to do is change the permissions of some control files and it works. On systemd? When I looked it up, the simplest solution involved writing a polkit policy in javascript 🤮
cries It’s amazing how much damage they’ve done to the linux ecosystem. Not just badly thought out concepts, but the amount of frustration and annoyance they caused by ramming it into existence and the cynicism it’s created.
me setting my interface into monitor mode manually because it can’t handle being split into mon and managed.
life-long Kali fan
