iproute2 and libbpf: vendoring on the small scale
Iproute2 is a collection of network-configuration tools found on almost any Linux system; it includes utilities like arpd, ip (the command old-timers guiltily think they should be using when they type ifconfig), ss, and tc. That last command, in particular, is used to configure the traffic-control subsystem, which allows administrators to manage and prioritize the flow of network traffic through their systems. This subsystem has, for some years, had the capability to load and run BPF programs to both classify packets and make decisions on how to queue them. This mechanism gives administrators a great deal of flexibility in the management of network traffic.
The code for handling BPF programs within iproute2 is old, though, and lacks support for many of the features that have been added to BPF in the last few years. Since that code was written, the BPF community has developed libbpf (which lives in the kernel source tree) as the preferred way to work with BPF programs and load them into the kernel. This is not a small task; libbpf must interpret the instructions encoded as special ELF sections in an executable BPF program and make the necessary calls to the sprawling bpf() system call. This work can include creating maps, "relocating" structure offsets to match the configuration of the running kernel, loading programs, and attaching those programs to the appropriate hooks within the kernel. Libbpf has grown quickly, along with the rest of the BPF ecosystem.
The obvious way to add support for current BPF features to iproute2 is to
dump the old code used there in favor of libbpf; patches to that effect
have been posted by Hangbin Liu, starting in late
October. Shortly thereafter, David Ahern, one of the iproute2
maintainers, pointed
out that the posted patches fail to compile on an Ubuntu 20.10 system;
Liu responded
that Ahern needed to update to a newer version of libbpf, and libbpf
developer Andrii Nakryiko suggested
including libbpf as a submodule of iproute2. That is where
the trouble began; Ahern asserted
that libbpf is provided by distributions and that iproute2 needs to
work with the version that is available. Nakryiko
argued
instead that libbpf is "a fast moving target right now
" and that
packaging it with iproute2 is "pragmatic
". Needless to say,
this feeling did not find universal agreement.
The arguments against "vendoring" libraries like libbpf in this way have been made many
times, and they appeared here as well. Jesper Dangaard Brouer repeated the usual security
argument: copies of libraries buried within other packages are difficult to
find and update if a problem is found. Jiri Benc added that the end
result of this process would be a massive bundling of dependencies, which
"would be nightmare for both distros and users
". Distributors
have long been opposed to bundling dependencies in this way, and the
iproute2 developers do not see any reason to go against this policy for
libbpf.
The BPF developers see things differently and were not shy about expressing
their feelings. Alexei Starovoitov asserted
that Ahern is "deaf to technical arguments
" and raised the
idea of forking iproute2 in response. He later said
that using the distribution-provided libbpf would be worse than not using
libbpf at all, and that if he could remove the existing BPF support from
iproute2, he would do so. Things reached a point where Toke
Høiland-Jørgensen asked him
to "stop with this 'my way or the highway' extortion
" so that
the discussion could make some progress.
The argument for bundling libbpf with iproute2 seems to come down to a distrust in the version of libbpf that distributors will ship. There are two aspects to this, one being that iproute2 could end up linking to a version of libbpf that introduces bugs; as Starovoitov put it:
Benc disagreed:
In a separate branch of the discussion, Starovoitov extolled
the compatibility of libbpf releases, saying that "users can upgrade
and downgrade libbpf version at any time
". Others agreed that
libbpf releases are managed well and do not create compatibility problems.
So it is not really clear what the concern is here.
The related issue, though, is the worry that using the distribution-provided libbpf will lead to inconsistency across systems and an inability for users to know which features will be supported just by looking at the version of iproute2 they are running. Beyond that, the BPF developers fear that distributors will stick with an old libbpf, depriving users of newer features even if they have a current version of iproute2. Nakryiko said that users do want the newer features supported by libbpf, but BPF maintainer Daniel Borkman repeatedly claimed that distributors cannot be trusted to keep up with libbpf releases. That, it is argued, will lead to a poor experience for iproute2 users. Tying a specific version of libbpf to each iproute2 release, instead, would make life more predictable.
Ahern didn't entirely buy that line of reasoning, though:
That brought out a few other developers who complained about the need to keep multiple components all at the latest versions for things to work properly. Edward Cree, for example, complained about the lack of attention to interoperability in general:
Starovoitov actually agreed that the
situation needs to improve — someday. "BPF ecosystem eventually
will get to a point of fixed file format, linker specification and 1000
page psABI document.
" For now, though, things are evolving too
quickly for that, he added.
Toward the end, Nakryiko suggested
that, if distributors make a point of updating libbpf and setting
the dependencies for iproute2 to require the updated versions, things might
work well enough. Benc replied that Red
Hat, at least, works that way now, leading Nakryiko to reply
that this "would be sufficient in practice
". Starovoitov
still pushed
for iproute2 to require a minimum libbpf version that increases with each release so that
there would be at least some correlation between the iproute2 and libbpf
versions. Stephen Hemminger, who also maintains iproute2, seems unwilling to
impose that sort of requirement, though.
In the end, it appears that iproute2 will be packaged like almost all other Linux utilities; it will use the version of libbpf shipped by the distribution it is running on rather than supplying its own. The distributors will just have to be sure that they keep libbpf current with other kernel-derived utilities; this is something they have long since learned to do.
The tensions around the quickly evolving BPF subsystem seem
unlikely to go away, though; one group of users is already relying on
BPF-based tools while the developers continue to evolve the whole ecosystem
in a hurry. Ahern described
the situation this way: "The trend that related s/w is outdated 2-3
months after a release can be taken as a sign that bpf is not stable and
ready for distributions to take on and support
".
But that, too, should be a tractable problem;
Linux as a whole has been supporting users while undergoing constant
modification for nearly 30 years, after all.
| Index entries for this article | |
|---|---|
| Kernel | BPF |
Posted Nov 12, 2020 19:43 UTC (Thu)
by nysan (guest, #81015)
[Link] (1 responses)
Posted Nov 13, 2020 3:03 UTC (Fri)
by danobi (subscriber, #102249)
[Link]
But to your point, yeah, you’re absolutely right. bpftrace is at the intersection of all these fast moving pieces of software and we dynamically link (by default) all our dependencies. We do our best to feature detect what’s available on the system but sometimes stuff slips through. Vendoring is very tempting at times...
Posted Nov 12, 2020 21:13 UTC (Thu)
by xnox (guest, #63320)
[Link]
There is no reason why libbpf cannot be part of that train as an -hwe variant if that's what is state of the art and needed to function well on top of the latest backport kernel.
So we can totally make that happen.
Posted Nov 12, 2020 22:26 UTC (Thu)
by ballombe (subscriber, #9523)
[Link]
And what makes that possible ? For most users, distribution-maintained kernels
Posted Nov 13, 2020 7:36 UTC (Fri)
by ismail (subscriber, #11404)
[Link] (7 responses)
Of course, we try to avoid this to lower the security overhead, but if there is a good reason for this (as in the libbpf case), there is no reason to patch upstream and introduce possible problems.
[0] https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packa...
Posted Nov 13, 2020 10:10 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (6 responses)
Except it isn't though, this whole rigamarole was about "outdated" packages, but Debian has the very latest iproute2 always uploaded at most a couple of days later after the release to unstable, and a week or two later to stable-backports. I know because I do it.
Debian and Ubuntu also statically link golang stuff and use a similar mechanism to track sources (Built-Using) as SUSE does.
That whole thread seems to be a much-ado-about-nothing, lots of ideology and lots of contempt for distros, and little else. Not exactly good publicity for the BPF ecosystem, I must say.
Posted Nov 13, 2020 16:20 UTC (Fri)
by cavok (subscriber, #33216)
[Link]
Posted Nov 15, 2020 13:58 UTC (Sun)
by Conan_Kudo (subscriber, #103240)
[Link] (4 responses)
If there was something I could erase from the Linux distribution landscape, it is the equivalency of "LTS" to "stale". 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.
Posted Nov 16, 2020 15:14 UTC (Mon)
by imMute (guest, #96323)
[Link] (3 responses)
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.
Posted Nov 16, 2020 22:28 UTC (Mon)
by bluca (subscriber, #118303)
[Link] (2 responses)
Posted Nov 21, 2020 5:31 UTC (Sat)
by giraffedata (guest, #1954)
[Link] (1 responses)
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.
Posted Nov 23, 2020 17:32 UTC (Mon)
by Jandar (subscriber, #85683)
[Link]
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.
Posted Nov 13, 2020 18:22 UTC (Fri)
by rweikusat2 (subscriber, #117920)
[Link] (34 responses)
Posted Nov 13, 2020 18:54 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (33 responses)
Why can't it just be updated to take advantage of the new features, rather than ditching it and starting afresh?
I don't care much about which tools I use, I just wish the UI wouldn't change or disappear. I now need to learn a complete new command and options, just to do something simple like find out my computer's IP address!
Cheers,
Posted Nov 13, 2020 20:20 UTC (Fri)
by MaZe (subscriber, #53908)
[Link] (21 responses)
(b) the primary 'benefit' of ifconfig is familiar syntax (to old timers)... but that syntax (both in terms of cli flags, and in terms of text output) is exactly what has to evolve/change to support the new features... so you wouldn't actually end up with something all that familiar anyway...
Posted Nov 16, 2020 1:47 UTC (Mon)
by dancol (guest, #142293)
[Link] (20 responses)
It may seem silly or trivial, but making the default output of "ip" look like "ip addr" would help get people off "ifconfig".
Posted Nov 16, 2020 2:24 UTC (Mon)
by MaZe (subscriber, #53908)
[Link]
ip<space>a<enter>
But, yeah I do sort of get where you're coming from.
Posted Nov 16, 2020 17:11 UTC (Mon)
by mkubecek (guest, #130791)
[Link] (18 responses)
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."
Posted Nov 16, 2020 17:18 UTC (Mon)
by sfeam (subscriber, #2841)
[Link] (5 responses)
Posted Nov 16, 2020 17:37 UTC (Mon)
by mkubecek (guest, #130791)
[Link] (4 responses)
Posted Nov 16, 2020 17:56 UTC (Mon)
by pizza (subscriber, #46)
[Link] (3 responses)
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.
Posted Nov 16, 2020 23:42 UTC (Mon)
by mkubecek (guest, #130791)
[Link] (2 responses)
Posted Nov 16, 2020 23:57 UTC (Mon)
by quotemstr (subscriber, #45331)
[Link] (1 responses)
Posted Nov 17, 2020 6:44 UTC (Tue)
by jem (subscriber, #24231)
[Link]
From iproute2.doc:
An example:
Posted Nov 16, 2020 18:55 UTC (Mon)
by dancol (guest, #142293)
[Link] (11 responses)
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".
Posted Nov 16, 2020 22:08 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link] (5 responses)
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.
Posted Nov 25, 2020 23:35 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (2 responses)
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.
Posted Nov 26, 2020 9:36 UTC (Thu)
by geert (subscriber, #98403)
[Link]
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.
Posted Nov 27, 2020 22:00 UTC (Fri)
by nix (subscriber, #2304)
[Link]
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.
Posted Dec 29, 2020 1:22 UTC (Tue)
by Shabbyx (guest, #104730)
[Link] (1 responses)
Posted Jan 4, 2021 16:43 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link]
You mean like "ip -c addr"?
Posted Nov 16, 2020 23:16 UTC (Mon)
by mkubecek (guest, #130791)
[Link] (3 responses)
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.
Posted Nov 17, 2020 0:03 UTC (Tue)
by quotemstr (subscriber, #45331)
[Link] (2 responses)
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.
Posted Nov 17, 2020 8:34 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link]
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.
Posted Nov 18, 2020 0:09 UTC (Wed)
by nix (subscriber, #2304)
[Link]
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.
Posted Nov 17, 2020 5:23 UTC (Tue)
by mbiebl (subscriber, #41876)
[Link]
(*) I actually use alias ip='ip -c'
Posted Nov 13, 2020 22:34 UTC (Fri)
by rweikusat2 (subscriber, #117920)
[Link] (10 responses)
I'm still using the exact fvwm2 configuration I did already use in 1998 and with how many "turn everything upside down and paint everything which used to be green in pink with orange flowers on it !" cycles has everyone else put up with since 1998? But using "ip addr" instead of "ifconfig" is just too much of a botheration?
:-))
Posted Nov 15, 2020 14:59 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (9 responses)
I just used to type "ifconfig" - no bothering with arguments and it told me all the basic stuff I needed to know. I don't think "ip" does that - you need the argument? Which means I need to remember more than just the basic command, and I don't use it much so I'm faffing around with man pages all the time ...
To my mind the obvious solution would have been to keep the single binary, but make the functionality dependent on the name it's called by. New functionality would require calling by the new name.
Still, hindsight is always 20/20 :-)
Cheers,
Posted Nov 15, 2020 15:51 UTC (Sun)
by dtlin (subscriber, #36537)
[Link] (7 responses)
Posted Nov 15, 2020 18:22 UTC (Sun)
by geert (subscriber, #98403)
[Link] (6 responses)
Posted Nov 15, 2020 20:30 UTC (Sun)
by dtlin (subscriber, #36537)
[Link] (5 responses)
Posted Nov 16, 2020 8:04 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (4 responses)
If that's what I want, how do I get multiple bits of information in one go?
Cheers,
Posted Nov 18, 2020 0:18 UTC (Wed)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Nov 26, 2020 10:20 UTC (Thu)
by ecree (guest, #95790)
[Link] (1 responses)
Posted Nov 27, 2020 22:19 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Nov 26, 2020 15:59 UTC (Thu)
by opsec (subscriber, #119360)
[Link]
I'm a FreeBSD user, we still have ifconfig, so I feel the pain as well, when I get to a linux box 8-}
Posted Nov 18, 2020 0:15 UTC (Wed)
by nix (subscriber, #2304)
[Link]
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).
Posted Nov 13, 2020 23:44 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link] (3 responses)
Posted Nov 15, 2020 14:02 UTC (Sun)
by Conan_Kudo (subscriber, #103240)
[Link] (2 responses)
Posted Nov 15, 2020 14:15 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 15, 2020 15:14 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link]
In any case, have you reported a bug whenever you got this unpredictable failure mode?
Posted Nov 13, 2020 23:58 UTC (Fri)
by jonesmz (subscriber, #130234)
[Link]
In late 2019, I spent well over a full week doing research on how to load an ebpf program into the network stack. It's like climbing a brick wall.
Posted Nov 14, 2020 7:06 UTC (Sat)
by ncm (guest, #165)
[Link]
The Kubernetes problem can be solved by treating all Golang programs as if they were scripts, and compiling them, with all their dependencies, at package installation time. (This is akin to what we already do when installing Elisp and Python modules, or kernel modules.) Then, a Golang library package just maintains a local repository shared among all the installed versions. The dependency annotations for each program package identify everything needed, so that installing a Golang program package would amount to fetching the all the right revisions to local repositories, checking them out, building, and then discarding the checkouts.
In fact the C compiler is also fast enough that libbfd and other fast-moving dependencies could be treated much the same way.
Posted Nov 14, 2020 8:40 UTC (Sat)
by madhatter (subscriber, #4665)
[Link] (1 responses)
If you're going to try to do this kind of thing, and thus add a dependency, start with the oldest version of the library used by any still-supported version of a major distro. If you want to use newer features, that's fine, you can do feature-detection at compile time and use newer stuff if (and only if) it's there (as danobi mentions the bpftrace people do, in a comment above). Distros that happen to be on newer versions can thus take advantage of that, without introducing show-stoppers for distros that don't.
If instead you start off your refactoring by requiring a library version that's not even in the very latest version of a major distro, you're heading for trouble. When you hit it, saying it's the distro user's fault, and that they need to upgrade the library, isn't going to impress the user community, or speed up acceptance of your work.
Posted Nov 14, 2020 16:41 UTC (Sat)
by ballombe (subscriber, #9523)
[Link]
Posted Nov 14, 2020 13:38 UTC (Sat)
by foom (subscriber, #14868)
[Link] (6 responses)
Normal users won't ever replace either one, so they don't need new iproute2 to have compatibility with old libbpf.
Distro maintainers working on a new version can trivially upgrade libbpf while upgrading iproute2, so they surely don't need it.
Developers of iproute2 can install a local copy of the latest libbpf to do their development work, if need be. It takes maybe an extra 5 minutes, really not a big deal...
Who _actually_ needs to be able to install a new iproute2 (replacing the distro version!) but cannot build a new version of libbpf2, first, when the distro version is too old?
Posted Nov 14, 2020 18:57 UTC (Sat)
by cjwatson (subscriber, #7322)
[Link]
I've done just the same kind of thing with man-db and libpipeline: for a while there were several occasions when man-db needed a new feature in libpipeline, so I released a new version of libpipeline and bumped its required minimum version in man-db. Distros upgraded both and got on with their lives. Nobody has ever complained.
In the Kubernetes case I at least have some sympathy for people with genuinely incompatible needs trying to solve a hard problem. In this case it sounds more like people looking for an excuse to complain about distribution models, and not really coming up with a terribly convincing one.
Posted Nov 16, 2020 19:22 UTC (Mon)
by nivedita76 (subscriber, #121790)
[Link] (4 responses)
Posted Nov 16, 2020 23:49 UTC (Mon)
by mkubecek (guest, #130791)
[Link] (3 responses)
Posted Nov 17, 2020 5:11 UTC (Tue)
by foom (subscriber, #14868)
[Link] (1 responses)
Posted Nov 17, 2020 17:48 UTC (Tue)
by mkubecek (guest, #130791)
[Link]
Posted Nov 17, 2020 10:24 UTC (Tue)
by bluca (subscriber, #118303)
[Link]
Posted Nov 16, 2020 1:45 UTC (Mon)
by dancol (guest, #142293)
[Link] (4 responses)
Posted Nov 17, 2020 0:07 UTC (Tue)
by khim (subscriber, #9252)
[Link] (2 responses)
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.
Posted Dec 29, 2020 1:26 UTC (Tue)
by Shabbyx (guest, #104730)
[Link] (1 responses)
Not to mention every library is loaded 50 times because it's duplicated in every application.
Posted Dec 29, 2020 13:55 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
- Base images are usually 4GB+ (the Linux image with "all possible external dependencies" is 2.6GB)
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.
Posted Dec 14, 2020 5:14 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
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.
Posted Dec 29, 2020 1:27 UTC (Tue)
by Shabbyx (guest, #104730)
[Link]
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
This is something to keep in mind before blaming the Linux distribution model.
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
Obviously an LTS does not update packages wholesale - that's the entire point of an LTS distribution. Customers and users of an LTS distro by and large do _not_ want constant churn. Stable means stable. There are rolling distros or fast-release-cycle distros for those who want that - if you want latest and greatest every day of every week, they are there for that exact purpose.
Still, Debian has backports to _optionally_ get new stuff if one wants to, and Ubuntu has hwe.
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
Obviously an LTS does not update packages wholesale - that's the entire point of an LTS distribution.
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
targeted, contained and backward compatible updates - which is what users of an LTS distro want.
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
Wol
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
vs
ifco<tab><enter>
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
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)
ip addr add 203.0.113.1/24 dev eth0 label eth0:0
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:
iproute2 and libbpf: vendoring on the small scale
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
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
Wol
ip l + ip a provide equivalent information to no-options ifconfig. How Linux handles multiple IP addresses/masks per network interface (exposed directly by iproute2) just doesn't match the ifconfig command-line interface, though.
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
$ ip
Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
ip [ -force ] -batch filename
where OBJECT := { link | address | addrlabel | route | rule | neigh | ntable |
tunnel | tuntap | maddress | mroute | mrule | monitor | xfrm |
netns | l2tp | fou | macsec | tcp_metrics | token | netconf | ila |
vrf | sr | nexthop }
OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
-h[uman-readable] | -iec | -j[son] | -p[retty] |
-f[amily] { inet | inet6 | mpls | bridge | link } |
-4 | -6 | -I | -D | -M | -B | -0 |
-l[oops] { maximum-addr-flush-attempts } | -br[ief] |
-o[neline] | -t[imestamp] | -ts[hort] | -b[atch] [filename] |
-rc[vbuf] [size] | -n[etns] name | -N[umeric] | -a[ll] |
-c[olor]}
$ ip enp0s31f6 # Another annoyance, fortunately "ifconfig" helps me to remember it ;-)
Object "enp0s31f6" is unknown, try "ip help".
$ ip l + ip
Command "+" is unknown, try "ip link help".
$
</pre>
Giving up.
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
Wol
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
Because what QEMU does is insane! It's the worst of all worlds, because now there's an unpredictable failure mode with it switching to something that may not necessarily be adapted to the environment it's being built for. One of the reasons I hate shipping QEMU is that this brittle setup messes with my ability to build QEMU properly.
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
At some point you hit bugs or missing feature in the library you intent to use, so you send patches for those and depend on the first version of the library that have the fix or needed feature, even though it was not what was planned.
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale
- 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
iproute2 and libbpf: vendoring on the small scale
iproute2 and libbpf: vendoring on the small scale