LWN: Comments on "iproute2 and libbpf: vendoring on the small scale"

iproute2 and libbpf: vendoring on the small scale

nybble41 — Mon, 04 Jan 2021 16:43:16 +0000

> 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

mathstuf — Tue, 29 Dec 2020 13:55:51 +0000

You can see this effect when trying to make useful CI Docker images for Windows builds. I believe that Windows Docker containers are limited to around 20G by default (almost certainly by Docker Hub). I don't know how changeable this is (e.g., it might be baked in at (base) image creation time). Fun things with Windows container usages:

- Base images are usually 4GB+ (the Linux image with "all possible external dependencies" is 2.6GB)
- Visual Studio requires a specific base image that is 6GB+ which contains a .NET Runtime install which apparently can't be done in any other image (so much for composability)
- Installing one Visual Studio version and toolchain is another 3GB+
- Dependencies (e.g., Qt) can be another GB or more

This leaves you with very limited space for doing what you'd want inside of a container (such as a CI build). We're still using bare metal for Windows builds despite the existence of Docker on Windows.

iproute2 and libbpf: vendoring on the small scale

Shabbyx — Tue, 29 Dec 2020 01:27:31 +0000

How is this different from any application depending on any library? You have semantic versioning for exactly this.

iproute2 and libbpf: vendoring on the small scale

Shabbyx — Tue, 29 Dec 2020 01:26:26 +0000

Also, that "solution" means windows with 10 applications takes 200GB of disk, while ubuntu with a thousand applications takes 20GB. They say storage is cheap and thus ok to waste, but observe every single instance of a new storage technology getting invented (SSDs most commonly).

Not to mention every library is loaded 50 times because it's duplicated in every application.

iproute2 and libbpf: vendoring on the small scale

Shabbyx — Tue, 29 Dec 2020 01:22:17 +0000

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

marcH — Mon, 14 Dec 2020 05:14:58 +0000

This problem hasn't been "solved" for 30 years because there is no silver bullet; no simple, one-size-fits-all solution.

This isn't to say nothing has changed, we most notably have the Internet now. Now even when ignoring the 8 fallacies of distributed computing, no one would go for the extreme of the entire Internet downloading and using the same library every time! Oh, wait... https://lwn.net/Articles/681410/ :-D

No simple solution for building, versioning, distributing and configuring software, only a large panel of engineering trade-offs for various situations. The reason these arguments keep coming is because many developers underestimate these problems and are even sometimes condescending with the people who are trying to solve them. Imagine hearing that soon enough computers will be capable to write better code than the one you're writing right now because you're not really solving difficult problems, "just do this, it's not hard". It is hard actually. The very first step is to acknowledge it is and respect (not: agree with) different approaches.

iproute2 and libbpf: vendoring on the small scale

nix — Fri, 27 Nov 2020 22:19:09 +0000

I think it's supposed to indicate that the -s option applies to many ip subcommands. Quite a lot of other commands these days do the same thing: git for one. I find it a bit annoying, too, but it does allow git -P diff and git diff -P to mean different things... which matters a lot for a metastasized mega-command like git and... not so much at all for ip.

iproute2 and libbpf: vendoring on the small scale

nix — Fri, 27 Nov 2020 22:00:42 +0000

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

opsec — Thu, 26 Nov 2020 15:59:25 +0000

Write a wrapper named ifconfig ? That uses 'ip l' and 'ip a' to get what you need ?

I'm a FreeBSD user, we still have ifconfig, so I feel the pain as well, when I get to a linux box 8-}

iproute2 and libbpf: vendoring on the small scale

ecree — Thu, 26 Nov 2020 10:20:54 +0000

But it's crazy that I have to type `ip -s addr` and can't `ip addr -s`, when command-subcommand-options is *so* much more natural. `tc` has this problem too. And `ip` doesn't understand `-h` at *all*, which is a cardinal sin for a Unix utility. (Though what can one expect from a Cisco-ism.)

iproute2 and libbpf: vendoring on the small scale

geert — Thu, 26 Nov 2020 09:36:55 +0000

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

marcH — Wed, 25 Nov 2020 23:35:22 +0000

> 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

Jandar — Mon, 23 Nov 2020 17:32:06 +0000

> I think a lot of users of an LTS distro want is just something without bugs.

If the user runs some important application not included within the distro a serious bug with this application could be introduced by a change in the distro. So LTS isn't only about a bug free distro but about bug free application+distro. From a user perspective any bug of my important application caused by a change in a LTS distro is a bug of the distro.

iproute2 and libbpf: vendoring on the small scale

giraffedata — Sat, 21 Nov 2020 05:31:01 +0000

targeted, contained and backward compatible updates - which is what users of an LTS distro want.

I think a lot of users of an LTS distro want is just something without bugs. If you don't have a lot of money to spend finding and fixing bugs, the only way to get something without bugs is to keep it stable. Change it only to to fix bugs, and it will get less and less buggy as time goes on.

But if those users could have it all - modern function and no bugs - they would.

iproute2 and libbpf: vendoring on the small scale

nix — Wed, 18 Nov 2020 00:18:32 +0000

'ip addr' displays all the information 'ip link' does about links and then adds address info to that, so that is usually enough unless you're looking for. ip -s addr if you want packet stats too (which I almost never do, so I'm glad it's off by default). ('ip link' is still valuable because that's what you use to *configure* the link layer: you can't use ip addr to do that.)

iproute2 and libbpf: vendoring on the small scale

nix — Wed, 18 Nov 2020 00:15:55 +0000

> I just used to type "ifconfig" - no bothering with arguments and it told me all the basic stuff I needed to know.

Only if the basic stuff you need to know includes nothing at all about the routing table. It's hard for me to imagine what networking problem that might be :) and the route output is, uh, completely different (and even more wildly inaccurate than ifconfig's, to such an extent that it's often impossible to use it to tell what's going where).

Meanwhile in the ip world we have 'ip route get', which can tell you which route will be used for a packet to a given address. This is immensely valuable with complex multi-table routing setups and would on its own justify the existence of ip, in my eyes (though of course you can't set up such things at all with the ifconfig/route tools).

iproute2 and libbpf: vendoring on the small scale

nix — Wed, 18 Nov 2020 00:09:58 +0000

> 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

mkubecek — Tue, 17 Nov 2020 17:48:51 +0000

This IMHO the best solution. It is already mentioned in the paragraph starting "Toward the end...", I just don't understand its last sentence as the e-mail linked by "seems unwilling" doesn't really seem to disagree with this approach. AFAICS Stephen just wanted to make sure the requirement for new iproute2 to work with old kernel (even if with features limited to what that kernel supports) is going to be preserved.

iproute2 and libbpf: vendoring on the small scale

bluca — Tue, 17 Nov 2020 10:24:34 +0000

If it's an observation, then where was it observed?

iproute2 and libbpf: vendoring on the small scale

mbunkus — Tue, 17 Nov 2020 08:34:27 +0000

> 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

jem — Tue, 17 Nov 2020 06:44:13 +0000

From iproute2.doc:

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)

An example: ip addr add 203.0.113.1/24 dev eth0 label eth0:0

iproute2 and libbpf: vendoring on the small scale

mbiebl — Tue, 17 Nov 2020 05:23:02 +0000

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

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

iproute2 and libbpf: vendoring on the small scale

foom — Tue, 17 Nov 2020 05:11:07 +0000

If the next iproute2 requires a new-enough libbpf version in order to build, this problem quite simply solves itself -- the priority of updating iproute2 will transfer to libbpf, and the package will get updated.

iproute2 and libbpf: vendoring on the small scale

khim — Tue, 17 Nov 2020 00:07:15 +0000

If you think Windows is immune… Sorry, but no.

I can assert you as someone who spent few hours recently trying to convince Visual Studio Express to install on a certain Windows 8 system. I have no idea what happened to .NET install there, but all attempts to solve that issue and attempts to use tools provided by Microsoft and others to solve that issue… failed. The mere fact that there are numerous tools shows that debate is far from being “settled”.

The only thing that Windows have done right is just a simple reduction of scope: most programs bring most dependencies with them which means chance to get crazy breakage is reduced. But when you need something which is part of an OS… you get the same dismal experience on Windows, too.

P.S. Since my friend only needed some C++ IDE for the University courses in the end problem was solved by using MinGW and CLion. Neither needs .NET at all thus everything worked beautifully.

iproute2 and libbpf: vendoring on the small scale

quotemstr — Tue, 17 Nov 2020 00:03:50 +0000

> 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

quotemstr — Mon, 16 Nov 2020 23:57:03 +0000

ISTM the problem was that the removal of alias interfaces broke userland. Was it infeasible to keep supporting them or something? It's too late to add them back now, but still.

iproute2 and libbpf: vendoring on the small scale

mkubecek — Mon, 16 Nov 2020 23:49:05 +0000

I think this is exactly the problem and I'm afraid it's an observation rather than an assumption. As for why, my guess is that while iproute2 is considered to be one of core packages so that there is a pressure to keep it up-to-date, this may not always be the case for libbpf, unless there is a sufficiently enthusiastic maintainer.

iproute2 and libbpf: vendoring on the small scale

mkubecek — Mon, 16 Nov 2020 23:42:30 +0000

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.

iproute2 and libbpf: vendoring on the small scale

mkubecek — Mon, 16 Nov 2020 23:16:52 +0000

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

bluca — Mon, 16 Nov 2020 22:28:06 +0000

Debian doesn't get any cash, and yet there are daily updates to stable via -security and quarterly-ish via -updates. Of course they are targeted, contained and backward compatible updates - which is what users of an LTS distro want.

iproute2 and libbpf: vendoring on the small scale

mbunkus — Mon, 16 Nov 2020 22:08:17 +0000

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

nivedita76 — Mon, 16 Nov 2020 19:22:36 +0000

From the bpf side, the argument seems to boil down to the assumption that distro's would keep updating iproute2 with every kernel release, but would not update libbpf the same way. I don't understand why this would happen though.

iproute2 and libbpf: vendoring on the small scale

dancol — Mon, 16 Nov 2020 18:55:31 +0000

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

iproute2 and libbpf: vendoring on the small scale

pizza — Mon, 16 Nov 2020 17:56:54 +0000

> A tool serving as a configuration interface for kernel networking which has been incompatible with kernel networking for almost 22 years is definitely obsolete, no matter how many people still refuse to acknowledge it.

I think you meant to say _incomplete_ -- because ifconfig is very much _compatible_ with modern kernels; it just can't configure every possible option. Indeed, even today ifconfig does everything that most users need.

iproute2 and libbpf: vendoring on the small scale

mkubecek — Mon, 16 Nov 2020 17:37:55 +0000

A tool serving as a configuration interface for kernel networking which has been incompatible with kernel networking for almost 22 years is definitely obsolete, no matter how many people still refuse to acknowledge it.

iproute2 and libbpf: vendoring on the small scale

sfeam — Mon, 16 Nov 2020 17:18:35 +0000

If there are indeed so many people who have been using it and prefer to continue using it, then the logical conclusion is that it is not "obsolete".

iproute2 and libbpf: vendoring on the small scale

mkubecek — Mon, 16 Nov 2020 17:11:35 +0000

Sadly, that wouldn't help. Even if "ip" without arguments did show something like "ip -s addr show" (or "ip -s a") does - i.e. everything "ifconfig" does and more, the ifconfig fanclub would still complain. They don't care that ifconfig shows you things that don't exist, they don't care that it does not show important information, they don't care that it sometimes does something completely different than you would expect, they don't care that it uses different syntax for IPv4 and IPv6 addresses, they didn't care that it used to truncate interface names to 9 characters. It's their pet and they won't accept anything else on principle, even if it has more consistent syntax, actually works and is way more powerful.

The real problem is that even today, new articles and books are being written which teach people to use ifconfig (route, arp, netstat, ...). Thus even people who only learned about ifconfig when it had been already obsolete for 15 years, keep saying "I'm used to it, I don't want to learn something new."

iproute2 and libbpf: vendoring on the small scale

imMute — Mon, 16 Nov 2020 15:14:07 +0000

>There are a number of models where long-term supported distribution releases do not freeze the stack for the entire life of the release. Neither Red Hat Enterprise Linux nor SUSE Linux Enterprise do this, and clearly their customers aren't throwing pitchforks at them. If anything, they are asking for more updates and rebases! So clearly that's not it.

You're right. The difference is the word "Enterprise". The customers aren't throwing pitchforks because they're throwing cash. Cash that can be used to keep a long-term distribution stable AND keep it up to date.

iproute2 and libbpf: vendoring on the small scale

Wol — Mon, 16 Nov 2020 08:04:44 +0000

So in order to get the informatiion I might want, I have to type three or four commands? Whereas ifconfig was just one command?

If that's what I want, how do I get multiple bits of information in one go?

Cheers,
Wol

iproute2 and libbpf: vendoring on the small scale

MaZe — Mon, 16 Nov 2020 02:24:15 +0000

Just FYI, but 'ip' is actually technically less typing...

ip<space>a<enter>
vs
ifco<tab><enter>

But, yeah I do sort of get where you're coming from.