this post was submitted on 27 Jun 2024
894 points (96.6% liked)

linuxmemes

21291 readers
1309 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
  •  

    Please report posts and comments that break these rules!


    Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't fork-bomb your computer.

    founded 1 year ago
    MODERATORS
     

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

    you are viewing a single comment's thread
    view the rest of the comments
    [–] notabot@lemm.ee 4 points 4 months ago (2 children)

    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@lemmy.world 6 points 4 months ago (2 children)

    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@lemm.ee 2 points 4 months ago (1 children)

    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@lemmy.world 2 points 4 months ago (1 children)

    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@lemm.ee 3 points 4 months ago (1 children)

    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@discuss.tchncs.de 2 points 4 months ago* (last edited 4 months ago) (1 children)

    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@lemm.ee 2 points 4 months ago

    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.

    [–] crater2150@feddit.de 1 points 4 months ago

    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.

    [–] MonkderDritte@feddit.de 0 points 4 months ago* (last edited 4 months ago) (1 children)

    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@lemmy.world 2 points 4 months ago (1 children)

    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@feddit.de 1 points 4 months ago

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