Comment by foxfluff

I was actually ranting about this on IRC last night (yeah now my laptop has two enp* interfaces and enx[MAC])..

One thing I like about OpenBSD is that buses are scanned and drivers probe in order and there's no race between drivers coming up. Unless your hardware is physically tampered with or broken, all interfaces come up with the same name across reboots. Linux isn't like that (even if you don't touch your hardware, interfaces could swap across reboots), so you need to do something about it.

As is typical on Linux, the default is unergonomic and if you want something nice, you're on your own to make it so.

If you already have userspace daemons responsible for device insertion and naming, it really wouldn't have been so hard for it to e.g. automatically add a config file / database entry for each interface the first time is seen. So the devices that came up as eth0 and eth1 are still eth0 and eth1 on the next boot; if I unplug eth0 and add a new card, the new one would be eth2 because eth0 is still reserved for the first card I had.

Missed the 's', it's:

https://wiki.debian.org/NetworkInterfaceNames

> These are supposedly more stable across device changes.

No. These are stable across reboots. The old eth? weren't. And yes, that had been a PITA.

If netwok interfaces were files we could just have both short names and stable names, like what we have for block devices.

You state that as if that were objective.. but that's not my subjective experience at all. Somehow I have a hard time remembering these long names, (is it --conf or --config or --config-file or --config-path? -c would've done it for me. --set or --set-prop or --set-property or --prop or --property?), and I need to look them up in a man page anyway, and I make more typos typing them, and shell completion rarely works well if at all. I also find it harder to read and edit long lines that wrap.

Somehow these short letters stick much better for me, and the effort for finding them in the manual is the same, although in case of extra complexity as with xinput, it's even worse with the long names. I don't use either command often, but it's hard to forget xset m. The only thing I remember about xinput is that it's a horribly long lithany of things which I need to look up every time, and the syntax still feels weird.

Spaces don't make anything more descriptive, they just cause completely unnecessary quoting and escaping hassle.

The amount of time that has been wasted by Windows using "C:\Program Files" instead of "C:\Program_Files" far outweighs any highly questionable aesthetic benefit IMO.

Short option for interactive terminal. Long option in automation.

I’ll be damned if I have to remember or lookup what -n means to some obscure program, when reading someone else’s script. Exception given for super common tools where everybody knows like ls -la.

With the disclaimer that shell scripts, especially ls, aren’t exactly suitable for reliable automation in the first place.

By this point, I'm pretty sure there are people at gnome who compete to see who will make the stupidest suggestion that gets put in production.

Weird, I haven't had to do this. Most(/all?) connections have nice names you can see with `nmcli c`... and so I can do `nmcli c up id DroidNet` and that's pretty dang nice. Pretty sure this worked with Ubuntu 14.04 (though, nmcli has gotten much more featureful since then)

(The ability to shorthand connection->c and similar is great, too; obviously not unique to nmcli)

apt-get install nmtui # it's better

Sure. One could also make "move-down-one-line" be the incantation to move the cursor down a line in vi, but I prefer j.

Ergonomics isn't all about making everything self-descriptive for someone seeing the thing for the first time. It's about making things comfortable to actually use. If it's so long and complicated that you can't even remember how to do it, it's not very comfortable to use. Even if I could remember, xset m 0 0 is still far more comfortable.

And fwiw you still don't know what 0, 1 in accel profile do; you need to look that up or take a wild guess, and if you want to use that command, you'll also have to know how to look up the device because chances are yours is not the same as mine. So it's not any less magical in the end, just more verbose.

The "cool" thing about the xinput command is that you don't even find accel profile in the man page. You gotta look elsewhere if you want to understand what it is and what it does and what the parameters are.

xset m? Yes, that is documented in the man page.

Another interpretation is:

On the first, you think you know what it does, but you're not sure. So maybe it gets looked up.

On the second, you know you don't know what it does. You so know to look it up.

Personally, I'll take the second. Assumptions during debugging are dangerous things.

But which case should software interfaces optimize for? Ergonomics of someone who uses a tool frequently, or interpretability for casual by-standers of some out-of-context shell command?

That may be a part of the problem but honestly I don't feel like all these new crazy interfaces are easy to learn either. I mean how do you come up with the lithany xinput calls for? You need to understand the syntax for specifying a device. You need to know that you're to set a libinput property, and you need to know the name of that property, and it's not documented in xinput man page, and of course you need to know the values to pass which again are not documented in xinput man page. You can play with --list-props and then take your search elsewhere because it is completely opaque and doesn't explain what the properties actually do.

I suspect the number of people who figured all that out without having to find it by googling / arch wiki / whatever is very very low.

Now I'm not gonna say xset is the easiest interface to figure out, but the syntax for setting mouse acceleration is right there in the synopsis, and if you search down the man page, you'll learn a little more (and also if you just run xset without arguments, it'll tell you how to set mouse acceleration). It might not be the best designed tool but it's something I learned back in the day as a teenager just by looking at the man page.

I think the real issue is that people nowadays are designing these interfaces to be consumed by interactive configuration tools, GUI apps, and desktop environments; they're more dynamic, more complex, more flexible, but not easier to figure out, not for you on the command line. The command line is just a last resort. Second class citizen if you will.

In a world of broken promises and tool churn, minimizing tooling investment isn't laziness, it's a defense mechanism.

This is a lesson I had to learn the hard way, multiple times.

On some level it makes sense. The problem with the command line is familiarity.

How often do you reach for iptables? If you're like myself, and most home/desktop users, then probably once in a blue moon to set it up and then you leave it alone. But a system admin? Maybe they touch it a few times a week or month. Every time I use iptables I have to relearn how Linux networking works.

Similarly, the xset/xinput thing. When I need those tools I just create a script or throw it in .bashrc. I adjust the settings once and will not touch them again for a couple years. It makes sense to have long parameters that are readable. I can look at my .bashrc and see exactly what device is getting adjusted.

> Long option names are ... easier to remember ... Your shell should be intelligent enough to provide tab completion

They are so easy to remember that you need to configure your shell to remember them for you?

>Your shell should be intelligent enough to provide tab completion for option names, assuming it is configured to.

Wait, are you saying that I need to change my shell or config to make up for another tool's poor design?

No, thanks.

Long option names are more difficult to remember because a long option name can be spelled multiple ways and it is difficult to remember which spelling is correct.

IMO, powershell got it right. Yeah, it’s syntax is strange, but it has standard flag usage with proper autocomplete, and you can shorten any flag the way you want (eg. fuzzy match) if it is unambiguous.

There's a tendency away from snake_case and towards kebab-case in things you interact with via CLI. Even moreso towards nocase.

Programs like Powershell eschew ease of use in CLI for readability in scripts.

camelCase is objectively harder to read than snake_case or kebab-case, though familiarity can mitigate that.

Needlessly long parameter/command names and the bizarre insistence on capital letters are the #1 and #2 reasons I detest PowerShell. Like GP, I resent that Linux tools are moving in that direction.