Welcome to Incremental Social! Learn more about this project here!
Check out lemmyverse to find more communities to join from here!

Props to Alpine and Kali for disabling this bullshit out of the box

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".

mlg ,
@mlg@lemmy.world avatar

me setting my interface into monitor mode manually because it can't handle being split into mon and managed.

notabot ,

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.

renzev OP ,

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, so wlan0 and eth0 are 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?

ikidd ,
@ikidd@lemmy.world avatar

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.

notabot ,

No need for a custom solution, we already had ways to make predictable names that worked better than this. Giving each interface a name that represents it's job makes life so much easier when you have several, naming them after which PCI bus they're on does not.

notabot ,

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.

renzev OP ,

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

notabot ,

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!

renzev OP ,

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.

notabot ,

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

llii ,

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.

notabot ,

I think the difference is the level it's happening at. As I said, I haven't tried it yet, but it looks like a simple, unfussy and minimal distribution that you then add functionality to via configuration. Having that declarative configuration means it's easy to test new setups, roll back changes and even easily create modified configuration for other servers.

renzev OP ,

I use nixos on my homeserver, but I'm looking to switch it to Void as well. For me personally I just realized that it's easier to set everything up with shell scripts and docker-compose. But that's just my personal experience, by all means go ahead and try out nixos if you have the time. It has lots of unique features that you can't replicate with "just a bunch of shell scripts". This video does a great job of selling nixos. Maybe my favourite part of nixos is how they make "shortcuts" for a lot of common tasks. For example, setting up a letsencrypt ssl certificate for your webserver with autorenewal can be done in just two lines of config.

crater2150 ,

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 (or wpa-cute if 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.

renzev OP ,

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!

MonkderDritte ,

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).

anyhow2503 ,

I tried using connman to setup a wireguard connection once. It was not a good experience and ultimately led nowhere, due to missing feature support.

MonkderDritte ,

Eduroam needs manual configuration but otherwise i see not what could be missing? And the cli is the same as bluetoothctl.

MalReynolds ,
@MalReynolds@slrpnk.net avatar

You're not wrong. But generally the idiocy is in response to beserkeness elsewhere, madness follows…

01101000_01101001 ,

I have to disagree with you there. Systemd sucks ass, and so does RPM.

corsicanguppy ,

so does RPM.

Careful. Jeff's format gives us really great advantages from an atomic package that we don't have elsewhere. THAT, at least, was a great thing.

Lennart's Cancer, though, can die in a fire.

01101000_01101001 ,

Atomic updates are amazing. But the package manager is slow as hell. SuSE managed to make zypper much faster using the same package format.

anyhow2503 ,

The only thing that's slow is dnf's repository check and some migration scripts in certain fedora packages. If that's the price I need to pay to get seamless updates and upgrades across major versions for nearly a decade, then I can live with that.

01101000_01101001 ,

I'll grant you that; I haven't used dnf so can't speak to its performance.

notabot ,

I'm with our binary friend; the systems they try to replace tend to be time tested, reliable and simple (if not necessarily immediately obvious) to manage. I can think of a single instance where a Redhat-ism is better, or even equivalent, to what we already have. In eavh case it's been a pretty transparent attempt to move from Embrace to Extend, and that never ends well for the users.

renzev OP ,

I can think of a single instance where a Redhat-ism is better

I don't know if it would be accurate to call it a redhat-ism, but btrfs is pretty amazing. Transparent compression? Copy-on-write? Yes please! I've been using it for so long now that it's spoiled me lol. Whenever I'm on an ext4 system I have to keep reminding myself that copying a huge file or directory will... you know... actually copy it instead of just making reflinks

notabot ,

I've never actually tried BTRFS, there were a few too many "it loses all your data" bugs in the early days, and I was already using ZFS by then anyway. ZFS has more than it's fair share of problems, but I'm pretty confident my data is safe, and it has the same upsides as BTRFS. I'm looking forward to seeing how BCachefs works now it's in kernel, and I really want to compare all three under real workloads.

renzev OP ,

Ooh, I've never heard of bcachefs, sounds exciting! I see it supports encryption natively, which btrfs doesn't. Pretty cool!

Personally I've never had any issues with btrfs, but I did start using it only a couple years ago, when it was already stable. Makes sense that you'd stick with zfs tho, if that's what you're used to.

farcaller ,

There’s a whole bunch of “it loses all your data” bugs in OpenZFS too, ironically, although it’s way way less fragile than btrfs in general.

That said, the latter is pretty much solid too, unless you do raid5-like things.

notabot ,

Yeah, I know there was one a while back, and if you don't use ECC RAM, given enough time, it will eat your data as it tries to correct checksum errors due to memory corruption. That's why we keep backups, right. Right?

I tend to assume that every storage system will eventually lose data, so having multiple copies is vital.

corsicanguppy ,

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.

Ansible can be heard mumbling incoherently and so, so slowly, from the basement.

Remember who saw apt4rpm and said "too fast, too immune from python fuckage, so let's do something slower and more frail". twice.

thesporkeffect ,

I won't hear any sass about Ansible. It doesn't scale up to infinity but it's the best there is at what it's good at (modular, small scale declarative orchestration)

possiblylinux127 ,
@possiblylinux127@lemmy.zip avatar

You can totally can scale Ansible and especially Ansible pull. It will work with thousands of VMs and can be used with other tools to completely automate deployments.

thesporkeffect ,

Oh agreed entirely. You can also use different execution strategies to mitigate most performance issues, but it can require some tuning at full enterprise scale.

notabot ,

I do use Ansible, partly because it's easier to tell people that's how you do it rather than "I wrote a shell script, it took half the time to write, it's 20% the size and runs several times faster". To be fair to Ansible, if you're configuring a number of servers at the same time, it's not too bad speedwise as it'll do batches of them in parallel. Configuring one server at a time is agony though.

Count042 ,

It's amazing how many of those started with Lennart, too.

notabot ,

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.

anyhow2503 ,

If anything, he gets most of his inspiration from MacOS.

notabot ,

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.

laurelraven ,

Considering how much systemd breaks the concept of "everything is a file", this would not surprise me in the least

notabot ,

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.

renzev OP ,

"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/lp0 and 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 🤮

renzev OP ,

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 .lua or .py, I would much rather take a few minutes to learn the specifics of your format than fuck around with dconf. Fuck dconf.

notabot ,

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.

jonne ,

Also, canonical decided to try and solve the same 'problem' in a different, equally convoluted way.

notabot ,

I try not to think about the things they've done, it's not good for my blood pressure. They had a decent desktop distro, but they seem determined to trash it with terrible decisions.

BCsven ,

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

laurelraven ,

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.

BCsven ,

It is but they change....so becarefilul with dd LOL

laurelraven ,

I mean, you should be careful with destructive changes and commands whether the interface names can change or not... And since they won't change outside of a reboot, I've yet to run into a scenario where that becomes a problem as I'm looking at and making sure I'm talking to the correct device before starting anyway

BCsven ,

Yep, i always type the line and take a break, and check the drives in another terminal first, before committing, but the web is full of people "argg I just dd the wrong drive".

notabot ,

Having consistent interface names on servers that have several is useful, but we already had that option. The interface names they generate are not only hard to remember, but not terribly useful as they're based on things like which PCI slot they're in, rather than what their purpose is. You want interface names like wan0 and DMZ, not enp0s2. Of course, you can set it up to use useful names, but it's more complicated than it used to be, so while the systemd approach looks like a good idea on the surface, it's actually a retrograde step.

suction ,

Small world thinking. Because you haven't seen the need for it doesn't mean it doesn't exist. Also, did you lose your CTRL, C, and V keys?

laurelraven ,

Yes, because everyone has need of this solution, and wants to have to copy and paste interface names every time they need to touch them, rather than having deterministic naming be an option to enable for those who actually need it...

suction ,

You know Linux isn’t just used by nerdy kids cosplaying as Mr Robot, right?

laurelraven ,

You know Linux isn't just used by enterprise sysadmins, right?

And even speaking as an enterprise sysadmin myself, I've not had need or use for deterministic interface naming once in my career. I have no clue how common that is, but most of the servers, both physical and virtual, that I've worked on only had one Ethernet port connected.

I see the purpose of this, but don't see a reason why it should be the default, or why it couldn't have been implemented like HHD/SSD UUIDs where the old dev names were left intact for easy use outside of fstab and the like where consistency could become a problem

ETA: you also seemed to miss the part of my initial reply to you about it being something that can be enabled by those who need it... And if you're going to say that the enterprise professionals who need it shouldn't have to turn it on every time they spin up a system, I'll remind you that enterprise admins working at that level where they're setting up enough servers for that to be a hassle are probably using orchestration like Ansible, Chef, or Puppet, and can just add that into their configs once

suction ,

TLDR

laurelraven ,

And I don't care, so whatever

Fades ,

life-long Kali fan

neclimdul ,

I really appreciate this change. Prior to it was always a struggle to deploy servers successfully. You'd reboot and your database would be on the wrong interface and you could even remote in because the management interface was suddenly on a firewalled external only network. Ask me how I know.

With virtualization and containers this just got more complicated. I would constantly have to rewrite kvm entire configs because I'd drop a new nic in the machine. A nightmare.

Sure, it's gibberish for the desktop user but you can just use the UI and ignore the internal name. Not even sure the last time I saw it on my laptop. So no big deal.

bitwaba ,

"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 the eth. Then you can build the your network configs based on either one.

Shouldn't be that hard right?

nekusoul ,
@nekusoul@lemmy.nekusoul.de avatar

Cries in nvme1n1p6, which is my current OS partition.

partizan ,

Taking a sip of Rum and chuckles at the look on the name of my OS partition: /dev/mapper/vg-root and /dev/mapper/vg-home 🙃

phx ,

That's because you're using LVM though.
In most distros you could also use something like:

/dev/vg/root

jj4211 ,

And at least in some distributions, they do exactly that, a number of aliases for the same interface. And you can add your own.

lemmyvore ,

But nobody uses /dev/sdX anymore (not after they wipe the wrong disk once anyway). They either use logical UUIDs or hardware WWN/serial.

renzev OP ,

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

bitwaba , (edited )

Yeah, the point is "you can use either one", instead of "we made the choice for you"

thisisnotgoingwell , (edited )

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.

fruitycoder ,

No idea what mactab is, but maybe it solves it for me, but being able to go from interface name back to a rack full of heterogeneous PCI cards and go "yep it should be this port" was a wildly useful feature.

I feel like there should be automatic alias creation for simply interface names though.

NaoPb ,

I actually prefer the eth0 and wlan0.

caden ,

That's what the meme is saying too

Laser ,

Is it though? Normally it's ironic: https://knowyourmeme.com/memes/stop-doing-math

jagungal ,

This time it isn't (I think)

MacNCheezus ,
@MacNCheezus@lemmy.today avatar

For regular PCs or laptops, which generally have at most one of each type of adapter, I don't see any reason not to.

jadedwench ,

I had to change mine to mac address naming on my proxmox server after the second time the name changed due to a GPU or SSD being added. It was kind of like, so what, if an SSD dies suddenly or I have some issue with a device you are going to rename my fucking nic card again while I am trying to troubleshoot? Absolutely deranged.

NutWrench ,
@NutWrench@lemmy.world avatar

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.

interdimensionalmeme ,

Wlan1? how would you bridge different channels with only wlan0?

maxinstuff ,
@maxinstuff@lemmy.world avatar

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 show

What I expected

wlan0

What I got

wlp242s0

Neat 👍 😎 👍

derpgon ,

enp2s0, wlp3s0, and my fav enp4s0f3u1u3

apfelwoiSchoppen ,
@apfelwoiSchoppen@lemmy.world avatar

I miss seeing this meme format on Lemmy. It's so good, and this one is no exception.

renzev OP ,

Thanks! I love this format so much. I can't find it now, but one of my favourite memes in this genre was something like this:

STOP DOING

  • Tasks were never meant to be completed
  • Years of working, but there's STILL MORE SHIT TO DO
  • Wanted to get some work done anyway, for a laugh? We had a tool for that: it was called SIMULATION GAMES
  • "Please let me sacrifice a third of my life to justify my existence. Please let me spend eight hours a day working just to be able to do it again the next day" - statements dreamt up by the utterly deranged

Look at what people have been demanding our respect for all this time, with all the schedules and todo lists we have built for them:

These are REAL things done by REAL people

<Pictures of gmail, microsoft outlook, and some TODO list app>

They have played us for absolute fools

kureta ,

this is beautiful

NegativeLookBehind ,
@NegativeLookBehind@lemmy.world avatar

eth0? No no, we need wlps0n1pn2d4es6vsd9c69420

fossphi ,

Good lord, this is a top tier meme!

renzev OP ,

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

fossphi ,

Heck yeah, vectorised libre memes ftw!

RustyNova ,

I often do the same for my memes. I like them high quality

Technoguyfication ,

You could have definitely gotten a longer interface name for that one example. enp0s31f6mon might be a good one lol

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • linuxmemes@lemmy.world
  • incremental_games
  • meta
  • All magazines
    •