iproute2 and libbpf: vendoring on the small scale

No, I did not mean "incomplete" because the lack of features is only one part of the problem - and perhaps a minor one. For example, ifconfig (and the ioctl interface it uses) still pretends a network interface has (at most) one IPv4 address which is _set_ while kernel maintains a set of addresses which can be added to or removed from. To work around this, It also pretends there are "alias interfaces" which no longer exist since kernel 2.2, leading to its own kind of problems like "ifconfig foo:0 mtu 1400" actually changing MTU of foo. There are real people who made a remote host unresponsive because of this caveat and real poeple who keep asking why they cannot use "eth0:0" as an interface name in netfilter rules.

label NAME --- Each address may be tagged with a label string.

In order to preserve compatibility with Linux-2.0 net aliases, this string must coincide
with the name of the device or must be prefixed with device name followed by a colon. (eth0:duh)

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.

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.

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

You mean like "ip -c addr"?

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

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