iproute2 and libbpf: vendoring on the small scale

Posted Nov 16, 2020 18:55 UTC (Mon) by dancol (guest, #142293)
In reply to: iproute2 and libbpf: vendoring on the small scale by mkubecek
Parent article: iproute2 and libbpf: vendoring on the small scale

It's also worth looking at the status output of both commands in detail and see why people might prefer "ifconfig" to "ip". In particular: compare this "ip" output:

2: wlp59s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 04:ed:33:4c:b4:4a brd ff:ff:ff:ff:ff:ff
    inet 192.168.86.185/24 brd 192.168.86.255 scope global dynamic noprefixroute wlp59s0
       valid_lft 71064sec preferred_lft 71064sec
    inet6 2604:4080:1321:8090:308c:1c2:a8b0:a941/64 scope global dynamic noprefixroute 
       valid_lft 3075sec preferred_lft 1275sec
    inet6 fe80::ddec:2fe4:a8b6:842f/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast   
    3125287182 3018779  0       246     0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    403122417  957242   0       0       0       0

to this "ifconfig" output:

wlp59s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.86.185  netmask 255.255.255.0  broadcast 192.168.86.255
        inet6 fe80::ddec:2fe4:a8b6:842f  prefixlen 64  scopeid 0x20<link>
        inet6 2604:4080:1321:8090:308c:1c2:a8b0:a941  prefixlen 64  scopeid 0x0<global>
        ether 04:ed:33:4c:b4:4a  txqueuelen 1000  (Ethernet)
        RX packets 3018891  bytes 3125321368 (3.1 GB)
        RX errors 0  dropped 246  overruns 0  frame 0
        TX packets 957317  bytes 403128107 (403.1 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Both outputs are a bit noisy, but the "ifconfig" one is less so and prettier. Why does "ip" output a numeric prefix before each interface ("2:" above) instead of just the interface name? Why do the statistics for "ip" have to be in the form of a table ("RX:", "TX:") instead of a simpler "ifconfig"-style one-statistic-per-line approach? The "valid_lft 3075sec preferred_lft 1275sec" bit is pure noise for most people.

And why can't "ip" wrap lines at some reasonable length?

"ifconfig" persists when "ip" exists not only because people are irrationally stubborn, but also because "ifconfig" output produces output that makes the eyes bleed less than "ip"'s output. The brain is an association machine. If typing "ip" is followed by displeasure, for whatever reason and typing "ifconfig" is not followed by similar displeasure, then people are going to type "ifconfig" regardless of the theoretical advantages of typing "ip".

A few minor human-centered tweaks to "ip"'s interface would go a long way towards making people prefer it to "ifconfig".

to post comments

iproute2 and libbpf: vendoring on the small scale

Posted Nov 16, 2020 22:08 UTC (Mon) by mbunkus (subscriber, #87248) [Link] (5 responses)

Just something to think about: us humans are rather diverse. There are very few things about that the output of either that could be said to be objectively better. It's all a matter of preference. And your personal preferences aren't everyone else's.

Therefore I think that this…

> A few minor human-centered tweaks to "ip"'s interface would go a long way towards making people prefer it to "ifconfig".

…is a fool's errand. For example:

To _me_ the tabular layout of ip's counters is much easier to grasp at a glance. To _me_ seeing the queueing discipline is important. To _me_ having long lines is actually a boon as I'm running terminals that are much wider than 80 characters (as monitors have been way wider than tall for decades now I find wrapping at 80 absolutely unreasonable). That all addresses (both IPv4 and IPv6) are written in prefix notation and that I don't have to convert between netmask & prefix length is a huge boon for me. Dealing with IPv6 a lot I absolutely need to see the relevant flags (e.g. "temporary" or "mngtmpaddr").

Last but certainly not least: whenever I need to parse that information I simply let ip output JSON. That alone is a total killer argument for _me_.

My point is not that ip is better than ifconfig, just that there is no "standard human", and therefore saying thinks like "human-centered" is so imprecise that it's worthless.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 25, 2020 23:35 UTC (Wed) by marcH (subscriber, #57642) [Link] (2 responses)

> To _me_ having long lines is actually a boon as I'm running terminals that are much wider than 80 characters (as monitors have been way wider than tall for decades now I find wrapping at 80 absolutely unreasonable).

I don't think I've ever seen anyone with a _single_ terminal spanning their entire monitor width, at least not in landscape mode. The monitor width has very little to do with line length, I don't understand how this myth persists.

The 80 characters limit is just a pure convention now: you can't have everyone choosing any random limit and expect text to look good on others' terminal without any waste of screen estate either.

Depending on the programming language and code style (not monitor width), I agree 80 tends to be a bit short but it's very hard to change conventions. 100 characters seems like a decent trade-off but during the never ending "transition" there will be frequent wrapping and 20% waste.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 26, 2020 9:36 UTC (Thu) by geert (subscriber, #98403) [Link]

Oh, once in a while I do use a single terminal spanning my entire monitor width. In fact I have used a single terminal spanning two side-by-side 2560x1440 monitors, using a substantially smaller font, to fit a large table in vim ;-) But those are exceptions.

Still, my (multiple) coding windows have 80 columns. When needed, they can be widened temporarily with a keyboard shortcut.

A wider terminal window can be useful for build or serial console output. But coding: 80 columns.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 27, 2020 22:00 UTC (Fri) by nix (subscriber, #2304) [Link]

Ignoring the actual historical contingency reasons for all this (Hollerith cards, etc)... one reason why having a limited length of line may be useful is a truly ancient typographical rule rooted in the biology of vision: in 10-point text at a typical reading distance, any text longer than 65--70 chars or so *under certain other constraints* is too long for easy reading: the eye will tend to lose its visual lock on the line and wander off onto neighbouring lines. It's obvious when this happens to you because it is *incredibly annoying* and you'll get frustrated after only a few lines like this in succession.

But, of course, there are constraints, which make this rule mostly irrelevant for source code. It came from book typesetting and before that quite possibly even handwritten manuscript production, where what is usually produced is text consisting of densely-set paragraphs, more or less rectangles of text with one shorter line at the end, perhaps with a slightly-ragged right edge, but not very ragged because that looks ugly. Source code looks nothing like this: the right edge is extremely ragged, and any lines that stretch the full width are probably standing on their own, not surrounded by text out on the right edge. Lines standing on their own like this are more or less immune from the eye losing track of which line the eye is on: the long line quite literally stands out from the lines around it.

Furthermore, source code is usually indented, and even if it was set as dense paragraphs, the typographical rule runs from the *left edge of the indentation*, not from the left edge of the file (though in books, whole-para indentations are often applied at both edges, expanding both margins, because indented regions are usually quite rare and you want them to stand out). It's perfectly all right, from the perspective of the eye losing track of a line, if the para the line is part of starts 120 chars from the left edge, as long as the *line itself* doesn't have too much text in it.

iproute2 and libbpf: vendoring on the small scale

Posted Dec 29, 2020 1:22 UTC (Tue) by Shabbyx (guest, #104730) [Link] (1 responses)

I'm sure if you made the output of ip make the ip address colored, assing that's the information most commonly sought after, it would make a huge difference.

iproute2 and libbpf: vendoring on the small scale

Posted Jan 4, 2021 16:43 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

> if you made the output of ip make the ip address colored

You mean like "ip -c addr"?

iproute2 and libbpf: vendoring on the small scale

Posted Nov 16, 2020 23:16 UTC (Mon) by mkubecek (guest, #130791) [Link] (3 responses)

Did it ever occur to you that the actual reason why you see ifconfig output as prettier, easier to read, "human centered" or even "making eyes bleed less" is that you are used to it? For me, it's exactly the opposite: whenever I have to deal with ifconfig or route output, it's much harder for me to parse it - and that's when I'm lucky that the information I'm looking for is actually there. What you call "pure noise" may be an important piece of information for someone else (and so is what you call "numeric prefix"). BtW, most people don't know and don't run either of these commands so it's rather irrelevant what is "pure noise for most people".

Ad "simpler "ifconfig"-style one-statistic-per-line approach": are you really talking about the same output as you presented? What I see is one line with two stats, one with four, then again one with two and one with four. I'm not sure what you call "one-statistic-per-line" style there.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 17, 2020 0:03 UTC (Tue) by quotemstr (subscriber, #45331) [Link] (2 responses)

> Did it ever occur to you that the actual reason why you see ifconfig output as prettier, easier to read, "human centered" or even "making eyes bleed less" is that you are used to it?

It did occur to me, but I still think the ifconfig output is better. I'm not saying that's a universal truth, but being familiar with both commands, my preference is still ifconfig's output. In general, while familiarity does affect our perception of UI quality, it is and must be possible to compare one UI against another and say one is better.

Besides: if the output style really doesn't make a difference, why *not* stick with the ifconfig style for familiarity's sake? The goal is to get everyone off obsolete tools, isn't it?

Sometimes, when people replace tool X with tool Y on the grounds that X is obsolete, they make Y differ from X in ways arbitrary ways that aren't related to X's obsolescence, causing needless pain in the transition. I say that when we replace X with Y, we make Y resemble X as much as possible to drive adoption of Y and reduce transition pain. For example, I think Python 3 should have kept its print statement: making print a function was a needless incompatibility.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 17, 2020 8:34 UTC (Tue) by mbunkus (subscriber, #87248) [Link]

> it is and must be possible to compare one UI against another and say one is better.

I wholeheartedly disagree. As long as neither is doing something immensely stupid such as presenting numbers in binary or octal, how information is perceived and digested highly depends on the human doing the digesting. We're so diverse in how we work that there cannot be one canonical best way do present it.

As said elsewhere, I highly prefer ip's output. You don't, and that's fine, but please don't think that just because you prefer ifconfig's output, that that's a universal truth or proof of it being better than ip's.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 18, 2020 0:09 UTC (Wed) by nix (subscriber, #2304) [Link]

> Besides: if the output style really doesn't make a difference, why *not* stick with the ifconfig style for familiarity's sake?

Mostly because it's wildly irregular and more or less impossible to extend. The ip output format is, uh, a bit painful to read (I suspect due to the lack of anything resembling punctuation), but it's extremely extensible and it does have one valuable extra property: each line-and-following-indented-lines group is in many cases valid or almost valid *input* to the corresponding ip subcommand, or at least similar enough that you can tell what to feed ip to replicate this configuration again (or to change it slightly). ifconfig has nothing like this.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 17, 2020 5:23 UTC (Tue) by mbiebl (subscriber, #41876) [Link]

I do like to throw in a "-c" when using ip (*). Helps readability a lot for me.

(*) I actually use alias ip='ip -c'