10 ms·

Traditional packaging is not suitable for modern applications?

59 points by pabs3 4y ago

tannhaeuser 4y ago
The question is why now? Distros have for the longest time worked as curated sets of dependencies without "nuclear" options such as containers. At the same time, there have been exactly zero new end-user apps on Linux for over a decade. Incidentally just today I bought a MBP after 12 years on Linux. Won't miss the stagnation, bike shedding, nerding around with new unproven languages, projecting everything into the "next big thing" such as rust, systemd, containers while delivering very little, the DE regressions, comical lack of apps, qa, taste, professionalism, and common sense.
qwery 4y ago
I don't want to start a war about static/dynamic linking / shared libraries, so: some people want some shared libraries for some reasons. One problem with having different applications use different versions of libraries is that you can have multiple versions of a library installed. Having multiple versions of a library installed undermines some of the reasons for using shared libraries in the first place. A lot of (most?) software was never meant to be used this way. It's uncommon to see an application that separates its data/config with unique filenames per version, for example. And there's not a global answer to whether or not that data should be shared between versions anyway. [0] Container-style software distribution largely avoids these issues by not having shared libraries[1] for the most part. This has some benefits like the sandboxing and security features and making consistent behaviour across environments more achievable[2]. But you miss out on benefits from using shared libraries. Surprise -- a software development decision is a trade-off! [0] Blender stands out for separating config files per version and also letting you easily import an existing config from an earlier version after an update. [1] or not sharing shared libraries [2] consistent behaviour across environments is more achievable as the dependencies are shipped with the application (you can ship dependencies without containers as well, e.g. static linking)
Brian_K_White 4y ago
- gsich 4y ago
  "modern" is not a quality marker, it just means that it was developed somewhat recently.
  - Brian_K_White 4y ago
    ...and not everything developed recently is incompatible with "traditional packaging". I am pointing out that the author presumes their world is the world.
- spookie 4y ago
  I know right? It's really mind boggling.
auggierose 4y ago
The text suggests to just containerise any app, so I am wondering, what is the current status for containers (on Linux): Can you access files outside of a container from inside a container? Can you access devices like an eGPU from inside a container?
- korijn 4y ago
  This is addressed in the article. Search for permissions and e.g. XDG portals.
  - auggierose 4y ago
    I have seen the link to XDG portals, but it doesn't say what is possible with it.
- IceWreck 4y ago
  Yes to both.
  - auggierose 4y ago
    Is there a good book about all of that?
    - IceWreck 4y ago
      I dont know about books but I mostly learned from experimentation and https://docs.podman.io/en/latest/ https://docs.podman.io/en/latest/
forrestthewoods 4y ago
The solution is simple: ship your fucking dependencies. Every application should ship every dependency it requires. Attempting to use random shit that may or may not be installed on the system is a disaster. Containers that include all dependencies achieves this. Infact I like to argue that the only reason containers exist is because reliably launching software is so outrageously complex the only way to do is create a full system imagine. It’s a modern day tragedy. Disk space is cheap. If every application shipped duplicate dependencies it’d be… totally fine. The downside is inability to update security vulnerabilities. But if everyone is shipping containers that seems kinda moot. iOS and Android don’t have this issue. When you install an app it just works. Windows has the issue somewhat, but it’s mostly a problem with dev tools that are trying to pretend their in Linux. If you ship your fucking dependencies it’s a non-issue.
- mab122 4y ago
  What is the difference between shipping dependencies and shipping container? Thin layer of metadata? Or am I missing something?
- mjevans 4y ago
  Every security update means updating every big bundle of packages when it's a small change in some commonly used core library. Even IF my bandwidth and time were free (neither are) that is still a ton of duplicated work and wear on non-volatile memory life.
  - forrestthewoods 4y ago
    > Every security update means updating every big bundle of packages when it's a small change in some commonly used core library. Replacing all instances of libFFMoeg.so on a drive is not particularly harder than replacing one. > that is still a ton of duplicated work and wear on non-volatile memory life. Nonsense. We’re talking about replacing libraries on the order tens to hundreds of megabytes during a monthly update. It’s peanuts. Time I’ll give you. But the current system of system-wide libraries is objectively broken. As evidenced by the increasing usage of containers to work around the brokenness. I’d wager far more time is wasted on docker orchestration. It’s probably worth differentiating between servers and personal machines. Lord knows how many vulnerabilities are in your Steam library. It’s a lot.
zokier 4y ago
I feel the article is missing the point of distros. They are supposed to be fully self-contained integrated operating systems, not just container platforms. Additionally, essentially vendoring full dependency trees for each application separately would massively increase the maintenance burden because instead of just maintaining one version of a library the distro will need to maintain n versions > Modern applications are inherently fragile. There is nothing inherent in the fragility, it is self-inflicted problem of some applications.
- compsciphd 4y ago
  I'm not sure distro needs to "maintain" N versions. The distro maintain 1, but all N remain available and able to fulfill the dependencies of the underlying application It's not the distro's job to ensure the application is secure and up to date, its up to the application packager (i.e. docker container maintainer) to do that. i.e. to rev new releases of the application image even if nothing has changed in the core app, just to take care of security updates in distro provided packages). In pr
  - cuu508 4y ago
    > It's not the distro's job to ensure the application is secure and up to date I would prefer a distro that ensures applications in its repository are up to date. Consider a log4j-type issue. In one case, the distro quickly fixes the vulnerability in a library package, the user installs the update and that is that. In the other case, the user has to track down which installed applications use the affected library, update them if there is an update available, and figure out what to do if there is no update available.
    - josephg 4y ago
      > Consider a log4j-type issue. … the user installs the update and that is that. I hear what you’re saying. But - I’ve been writing a lot of rust lately. For better and worse, most rust programs pull in dozens of crates as direct or transitive dependencies. Apt isn’t up to the task of replacing cargo: - Apt’s dynamic library mechanism is designed around C’s dynamic library support. This doesn’t work with many other languages. It certainly doesn’t work with rust, which doesn’t have an ABI. - There are too many rust packages, and they update too frequently for apt to keep up. Apt could be a bad, out of date, partial clone of cargo. But that sounds worse than cargo in every way. - Shipping deps with cargo (or whatever) is preferred by app developers because cargo is better integrated with the language. And it works reliably on every platform. A dpkg wouldn’t even work on every version of Debian. We have a similar problem with ruby gems, nodejs packages (in npm), etc etc. I could imagine apt wrapping cargo, npm, and friends and providing equivalent functionality. But the authors of apt seem to think it’s already good enough. It’s not. Cargo, npm, and friends run rings around apt from the point of view of developer mindshare, ease of use, platform independent packaging, and so on. Apt and friends don’t have the features we want, and all the browbeating in the world won’t change that.
Karellen 4y ago
> Modern applications are inherently fragile. Well, there's your problem.
compsciphd 4y ago
I literally wrote part of my phd dissertation on this (can call it proto docker as it predated it and they seemed to use much of the same nomenclature I used, also was sort of a toss in an the very in, though arguably my most important contribution). see - https://www.usenix.org/legacy/event/lisa11/tech/full_papers/Potter.pdf https://www.usenix.org/legacy/event/lisa11/tech/full_papers/...
teddyh 4y ago
People are generally opposed to forking, right? If you fork a project, you effectively take over all the responsibilities to fix bugs and security issues etc. in that project, which is, most of the time, more work that the fork is worth. Now, a popular recent trend is “vendoring” your dependencies; i.e. bundling the dependencies with your software. However, vendoring does not differ much from forking. The responsibility may be slightly less, since you only have to fix bugs and issues affecting your application’s usage of the software. But, just like a fork, the longer you go without merging from the upstream version, the more work it is to maintain your fork. I suggest that vendoring, just like forking, should be avoided, for largely the same reasons.
doubleunplussed 4y ago
vscode example notwithstanding, I do not encounter the 'conflicting packages' problem very often on Arch. In fact, I don't remember the last time I encountered it, other than when it's an explicit choice - like, Python can only have one version of a package installed for the system Python interpreter, so if you try to install both python-numpy and python-numpy-mkl-bin, well, you have to choose. That's how Python works, though you can of course make additional Python environments (venv/conda/whatever) with different packages. I notice the vscode example involves the AUR, which is not the official repositories. I consider that a broken package, and it should be fixed. One of the packages should rename its main executable or whatever. Chrome, for example, has various versions, but they ship binaries with different names, e.g. /usr/bin/google-chrome-stable. The great thing about Arch is that there is one canonical user repository, the AUR. So the official repos should not have conflicts unless absolutely necessary, and the AUR should endeavour not to have conflicts, though it's more of a wild-west so they're somewhat more likely. However, you generally don't have to think about how to not conflict with whatever random packages may be out there - you only need to consider the repos and the AUR. Anyone making their own packages that are not in the official repos or the AUR, and yet conflict with them, well, that's their problem. Arch being super up to date and the existence of the AUR really does obviate the need for containerising apps to a large degree, at least from the perspective of ensuring dependencies are satisfied (there are still security reasons to want containerisation). I don't believe I have any containerised apps, and yet I'm running loads of modern common programs like zoom, chrome, discord, spotify, the list goes on.
- tempay 4y ago
  > if you try to install both python-numpy and python-numpy-mkl-bin, well, you have to choose. That's how Python works It's possible to have as many Python versions as you like installed at the same time. All of the libraries and headers include the major/minor version, packages are installed in `lib/pythonX.Y` and the Python binary itself is available as `pythonX.Y`. Few distributions support this well for anything other than a single 2.x and 3.x but it's nothing to do with how Python itself works.
  - doubleunplussed 4y ago
ddevault 4y ago
Nonsense. There are essentially two conflicting ideals here: what developers want and what distros want. The problem is that distros are generally right and what distros want is also what users want. So it's devs against the world. Devs want to ship updates whenever they want and force them into their users' machines as soon as possible, and forget about updating dependencies and pin them to ten versions ago so they never have to eat the cost of upgrading them. Devs don't want to make sure their application plays well with others, they just want to package it up in its own universe, the user's hard drive space and bandwidth be damned. Devs never want to finish their software or declare it stable, they just want to ship their machine on Monday morning so users have it installed by Monday afternoon, just to be updated again on Wednesday. Devs want to ship spyware and adware and malware without any oversight. All of this is cheap and profitable for devs but highly antisocial. Everything is better about the distro model: security, efficiency, and stability, and they represent the users interests even when they conflict with the dev's interests. "Modern applications" are developed by children and distros are the teacher slapping them on the wrist for misbehaving. Don't bitch about it -- just grow up.
- alkonaut 4y ago
  As a user I just want the app to be exactly like you describe: a) isolated from all other apps b) self-updating and have a release cycle decoupled from all other apps on my system. In this scenario (for my personal desktop OS) I don't care about bandwidth, disk space or whether an app uses an out of date version of a library. Having a release per week isn't uncommon and isn't somehow a sign that an app has poor quality. I'm not going to say a generalization is dead because of one counterexample, but It's perhaps not as clear cut as you make it out to be.
  - ddevault 4y ago
    As a user you are asking for a measurably worse experience. And given context, I suspect you are a developer, not just a user. A release per week is a sign that an app has poor quality.
    - 4y ago
forgotpwd16 4y ago
Nix solves the mentioned issues without using containers. Not sure why they keep referring to containers as only solution when Nix is included. Also not sure why they talk specifically about graphical applications. The issues mentioned apply to every program running on the system. That said, agree on those issues.
- nine_k 4y ago
  I bet it has something to do with Dockerfile having far simpler syntax than Nix config files.
qwery 4y ago
> However, Electron based applications vary, as they are built on top of different versions of Electron. I thought one of the selling points of Electron et al. was building apps on web standards. What is changing so fundamentally between versions of Electron that prevents apps from running on the latest release? I wouldn't expect Element to not work on Firefox 432[0] after using it on Firefox 431... [0] I lost track of Firefox version numbers somewhere between 3 and 50
kkfx 4y ago
I think many, too many still fail to see two thing: - packages/package management is intimately tied to filesystems and so installers. Actual package models are based on '80s Unix model that do not scale anymore since decades. Such model was designed decoupling "system code" to "user code" (script, mostly) while all along the IT history, both before and after unix we see a better model (see below); - packages in FLOSS are NOT meant do be made by upstream developers, that's a need of commercial only software. In FLOSS systems packagers of any distro package upstream code. Now a step at a time: classic systems where designed as a single application, indefinitively extensible by many, and users included. At a certain point in time AT&T/IBM and others say "ah, no that's bad" IMVHO just to deprive users of much power and gain the ability to sell limited, limiting and poorly designed crap. For more than a decade such decoupling take shape. After decades of big mess frameworks spring to life as a kind of middle-ground and they prove to be no better than the decoupled crap they try to solve without coming back to the classic OS-as-a-single-application model. Now essentially ALL non trivial applications being unable to effectively integrate each others try to be "the only one application" and finding no way to do so some pull out of the hat an even worse cage: hiding the OS on someone else computer, used as a bootloader of a modern more limited and limiting Java VM: the WebVM improperly named browser for legacy reasons. Pushing "the network is the computer" to "the cloud is the system". To solve this mess what we need is the original solution: the OS as a single application where source code is in the runtime, no "packaging" just SCM. Oh, surely that does not solve version conflict between source, these actually are ALREADY solved in architectural terms by the FLOSS distribution model: packagers assemble code. But working directly on source makes that far easier with simple sharable patches who happen to be also a bit distro-neutral. Nix/Guix offer the actual middle ground. To solve the storage mess it's far more complex. Today most solutions simply use a backend storage service, a kind of DB, no matter if SQL-alike or key-value or something else. SUN with zfs realize a very first limited evolution in that sense, but far from current needs. BeOS with if raw "query-able file system" have done another very small part before. https://twizzler.io https://twizzler.io seems to offer something more modern, but that's still an open issue.
edent 4y ago
There is, I think, a bit of a paradigm shift in action. In the old world, disk space was limited and download speeds were slow. So it made sense for every app to use the system-provided version of Library X. Additionally, stability and backwards compatibility was assumed. So if the distro updated to Library X v1.2, and your app relied on v1.1, everything would still work. Today's world is very different (for many users). Disk space is cheap and plentiful and downloading a couple of GB takes an instant. So why not bundle everything together? Additionally, developers can't be sure of stability in their dependencies. And the app developer is the person who receives the complaints from angry users, not the library developer. So it makes perfect sense to use a self-contained set of libraries and dependencies. The pendulum will swing the other way in time. We'll all get annoyed at having a dozen different Electron libraries taking up space, and we'll go back to one-library-to-rule-them all. But - as someone who used to hate battling dependency hell - I love Flatpack.
- Karellen 4y ago
  > Additionally, stability and backwards compatibility was assumed. So if the distro updated to Library X v1.2, and your app relied on v1.1, everything would still work. I thought all the cool kids had adopted `semver` these days, so this shouldn't be a problem? Except for crappy libraries/dependencies, in which case surely the answer is: Don't use crappy dependencies; find an alternative that does the same thing, without sucking. > Additionally, developers can't be sure of stability in their dependencies. Again, be more judicious in which dependencies you use. Stay away from the crap ones, find ones that do the right thing. > Disk space is cheap and plentiful and downloading a couple of GB takes an instant. Maybe for you. But not for everyone on the planet. Or, maybe people who live in places with intermittent internet connectivity don't deserve new software, or for their needs to be considered? > So why not bundle everything together? Security. If a serious vulnerability is found in Library X v1.1, I want to be able to upgrade it to Library X v1.1.1 and know that every single app that uses it is safe, without even needing to know which apps use it. I don't want to have to figure out which apps use it (which, OK, might not be too hard if the tools are written to find that out), and then have to download an update for every single one. Even if I do have unlimited gigabit broadband, that could still be awkward if the library is sufficiently popular and widely used.
choeger 4y ago
The problem is that containers are opaque and authors simply don't care about quality. If say, fedora would allow containers by having deviating Versions of rpms per app, it would be quite cool. The OS could inform me about apps using deprecated Versions, dependencies could be shared, etc. But people don't want to put up much effort when shipping their app. They want to build on some version of Ubuntu, add some manual hacks and expect everyone to use that container for the next decade or so. No one cares about dependencies, security or other nonfunctional aspects, sadly.
kasabali 4y ago
Yet another article arguing against distribution package managers without understanding them a bit. Traditional packaging is perfectly suitable for modern applications. What author is arguing against is the distributions' packaging policies. Distribution policies are what prevents shipping multiple versions of the same library or program, not package managers. These policies are in place because they're necessary for releasing and maintaining a 50000 package distribution. But for shipping your own software you're free to ignore distribution policies. Package managers have always provided the necessary mechanism. Nothing is preventing you from shoving in all library, binary or data dependencies your program needs into a deb package. You're also free to embed version number in package name and installation paths so different versions could be installed in parallel. The package manager will obey dutifully. Build systems have always been capable of installing libraries into arbitrary paths, and deb/rpm packages are just dumb archive files with metadata slapped on top. If you shove everything needed into it and declare no dependencies, it'll be no different than a dumb tar file and it'll work just fine if you did it right. You can even imitate flatpak runtimes if you want. Put same things a flatpak runtime has into /usr/lib/freedesktop-sdk-21.08 into a package like freedesktop-sdk-2108.deb, and make your application deb depend on freedesktop-sdk-2108 and you're good to go. I'm really tired hearing of these baseless arguments over and over over the years. I just wish everyone could be honest and just say "We don't like deb/rpm, they're not cool, they're not hip, we just want to NIH them" so we could be spared of these made up justifications. P.S. I have nothing against nix. Nix is legit innovation.
hnaccountme 4y ago
Better title would be "Traditional Packaging Is Not Suitable For Low Skilled Developers"
eqvinox 4y ago
> Traditional packaging introduces several issues, such as dependency and package conflicts, which usually require workarounds that differ from one distribution to another. I feel that there was no thought here at all regarding the reverse perspective: Current application development and deployment practices introduce several issues, such as dependency and package conflicts, which usually require workarounds that differ from one application to another.
friendzis 4y ago
The fundamental problem is not that distribution maintainers do not leverage containers, but rather we do not understand dependency models/trees of our programs. Containers are golden images. You find combination of stuff that works, carefully package them together and ship this whole package. Gold images run on bare metal, containers run on container runtime enabled kernel. Sure, containerizing an application is /easier/ than working out the dependency trees and solving dependency conflicts between them. It is by no means fundamentally better approach. If anything, this argument dismisses most work done by distros - building and solving those dependency trees. Maintainers of free OSes sometimes do not bother to solve all possible conflicts, however instead of breaking the system/packages, they do inform you of possible conflicts that are not solved. Inability to cherry-pick dependencies is deceptively wrong. Traditional distributions resort to use of so called meta-packages and alternatives to keep the system up to date. Deb/rpm packages are simple archives with additional metadata slapped on. The packaging system is transparent to contents: nothing forbids you to package versions 1.0 and 2.0 and have them happily coexist as long as they do not share common paths. In fact, a lot of packages are distributed in exactly the same way. It seems that the author has a solution - containers - and tries to find a problem for said solution.
- jasode 4y ago
  >Sure, containerizing an application is /easier/ than working out the dependency trees and solving dependency conflicts between them. It is by no means fundamentally better approach. [...] The [distro] packaging system is transparent to contents: nothing forbids you to package versions 1.0 and 2.0 and have them happily coexist as long as they do not share common paths. I think your comment is analyzing the problem from a different abstraction level than the author's examples. In other words, your alternative approach of "solving dependency conflicts" is abstract advice unless you try to make it concrete by focusing who solves those dependency conflicts. Using the author's example of a VSCode conflict (collision of "/usr/bin/code") with Actor in italics: - Microsoft owns commercial the build of /packages/visual-studio-code-bin - Filipe Laíns & Massimiliano Torromeo owns the open-source-license build of /packages/community/x86_64/code/ - Levente Polyak, et al owns the Arch Linux distribution - end user owns the computer that needs to run conflicting software Generalize the above matrix to every software package and consider which of those 4 actors can practically solve the conflicts in a scalable way? Filipe Laíns & Massimiliano Torromeo can't control what Microsoft does and vice-versa. (Ironically, the freedom to not be controlled by the other actor is one reason there's a package conflict!) And Levente Polyak could "solve" it by blessing Filipe Laíns's package and rejecting Microsoft's but this creates a new "problem" for users who specifically want Microsoft's commercial build. The fundamental issue is that you have independent actors that can't control what others do. Result is that sometimes software packages clash (namespace collisions, dependent libraries not in sync, incompatible licenses, etc). The approach of using containers -- however flawed it is -- gets past the stalemate of independent actors in the software landscape being incompatible with each other.
camgunz 4y ago
I generally think these arguments (containers, flatpak) boil down to: I don't want to figure out how a distro works. I'm unsympathetic to that; it's actually pretty easy to figure that out: they almost all use systemd and making a deb/rpm is also straightforward (there are great guides). Distros are also great at updates, to the degree devs can largely outsource a lot of it to them (compared with Windows where you're writing update functionality into your app, or whatever). I'm not even sympathetic to weird cases like OBS needing a forked version of ffmpeg. 1 this sounds like a wacky thing to do, 2 it sounds like they created a new project that is a different dependency. Call it something else (I suggest obsmpeg), package it for distros, pull in updates from ffmpeg whenever you want, reap the benefits of FOSS. Inventing an entirely new software delivery system instead seems like an overreaction. I am sympathetic to working this out across multiple distros though. Finding the intersection of packages across multiple versions of Ubuntu, Debian and Fedora isn't super easy, and it can really hamstring you when building an app (you want to use libcool-1.8.x, Ubuntu LTS has libcool-1.2.25, :sad:). The ecosystem isn't set up for this and it's a pain to deal with in your app (you more or less #ifdef functionality out, which product managers will freak out about).
- iudqnolq 4y ago
  As a regular Linux user who doesn't publish apps but has been reading this argument for years I've never understood the value distros provide. They're clearly doing a huge amount of work editing everything, but it also doesn't seem like they have the resources to properly test their edits. And while their edits are necessary to make everything work with their system, from a high level perspective they don't seem to be making the software better at what I want it to do. Given that, their model looks like dangerous busywork that at best delays updates and at worst introduces new bugs. Distros use the word "maintain" to describe what they're doing, but they don't seem to be doing that. To maintain a piece of software I'd expect the maintainer to need a deep understanding of the source code and to continually monitor changes. The complaints maintainers post that software changed seem to prove they aren't doing that. When I first saw a maintainer complain a library only posted about a breaking build change in their release notes and mailing list I was shocked. I had been assuming they were reading diffs, when they weren't even reading the changelog.
Roark66 4y ago
How can one write an article like this and fail to mention guix? It solves _a_lot_ of the problems mentioned. Guix (and all its channels) is a great piece of software, but unfortunately its potential for populartity is severely diminished by the insistence of the core user/dev group that its goals are not purely technological, but ideological(perhaps even primarily ideological). It seems that for many devs guix is less of a technical achievemt,and more a way of preventing people from being able to run what they call "non free software". BTW, "non free software" also includes open source software that was released under certain non-compliant licenses. The biggest issue I have with guix is that any effort of packaging "non-free" software (such as cuda, intel MKL, nvidia drivers etc). Is heavily discouraged, and if it it does happen its discussion is banned from official channels and all authors which make such software available in their personal repos seem to meekly include various pledges in the READMEs "to not advertise this horrible evil thing, or otherwise let people know of its existence". To me this behaviour is very far away from encouraging "free software", but my and their definition of free differ a lot. My second issue with guix is that the language used to write everything(guile) still lacks many crucial debugging and ease-of-use features such as: being able to display more meanigful error messages, being able to show on which line of compiled code the error/exception happens at, being able to easily interrogate variable value types (there seem to be lots of is_this_value_a_string?, or is_this_value_an_integer? functions, but no what_type_is_this?), no standard way to convert nested objects to string, or to pretty-print deeply nested objects. To this one has to add pretty substantial, but really poorely laid out documentation of the language (from the very first chapter the authors in their examples use all language features that may not be explained until 300 pages in - so the reader basically has to read the whole thing multiple times to "get it"). And so on... All those things matter a lot to beginners and they matter less to advanced users. If this language and guix in general is to catch on, it has to be more beginner friendly. However as a package manager it really is pretty good. It delivers everything nix does, but uses a more standardised and powerfull general purpose language. I can't wait until someone forks guix without the whole ideology thing.
- forgotpwd16 4y ago
  >I can't wait until someone forks guix without the whole ideology thing. There's no reason to fork Guix since ideology doesn't affect the software itself at all. Rather what you want is make an alternative definitions repo. Pretty sure I've seen such one that includes software not accepted on official channels.
al2o3cr 4y ago
I dunno about "modern" - I can recall distro packaging making a total disaster of Ruby gems over a decade ago.
noobermin 4y ago
Just spit balling ideas here, how much of the problems containerizing is meant to solve would be solved by merely static linking? Because it feels like that's what containers are mostly used for. Static linking + a sandbox to get most of everything. Using shared libraries but then shipping the .so's in a container defeats the point of a .so in the first place. If the reason containers are okay now since disk space is cheap, why not return to static linking of executables?

59 points by pabs3 4y ago

The question is why now? Distros have for the longest time worked as curated sets of dependencies without "nuclear" options such as containers. At the same time, there have been exactly zero new end-user apps on Linux for over a decade. Incidentally just today I bought a MBP after 12 years on Linux. Won't miss the stagnation, bike shedding, nerding around with new unproven languages, projecting everything into the "next big thing" such as rust, systemd, containers while delivering very little, the DE regressions, comical lack of apps, qa, taste, professionalism, and common sense.

qwery 4y ago

I don't want to start a war about static/dynamic linking / shared libraries, so: some people want some shared libraries for some reasons. One problem with having different applications use different versions of libraries is that you can have multiple versions of a library installed. Having multiple versions of a library installed undermines some of the reasons for using shared libraries in the first place. A lot of (most?) software was never meant to be used this way. It's uncommon to see an application that separates its data/config with unique filenames per version, for example. And there's not a global answer to whether or not that data should be shared between versions anyway. [0] Container-style software distribution largely avoids these issues by not having shared libraries[1] for the most part. This has some benefits like the sandboxing and security features and making consistent behaviour across environments more achievable[2]. But you miss out on benefits from using shared libraries. Surprise -- a software development decision is a trade-off! [0] Blender stands out for separating config files per version and also letting you easily import an existing config from an earlier version after an update. [1] or not sharing shared libraries [2] consistent behaviour across environments is more achievable as the dependencies are shipped with the application (you can ship dependencies without containers as well, e.g. static linking)

Brian_K_White 4y ago

gsich 4y ago
"modern" is not a quality marker, it just means that it was developed somewhat recently.
- Brian_K_White 4y ago
  ...and not everything developed recently is incompatible with "traditional packaging". I am pointing out that the author presumes their world is the world.
spookie 4y ago
I know right? It's really mind boggling.

auggierose 4y ago

The text suggests to just containerise any app, so I am wondering, what is the current status for containers (on Linux): Can you access files outside of a container from inside a container? Can you access devices like an eGPU from inside a container?

korijn 4y ago
This is addressed in the article. Search for permissions and e.g. XDG portals.
- auggierose 4y ago
  I have seen the link to XDG portals, but it doesn't say what is possible with it.
IceWreck 4y ago
Yes to both.
- auggierose 4y ago
  Is there a good book about all of that?
  - IceWreck 4y ago
    I dont know about books but I mostly learned from experimentation and https://docs.podman.io/en/latest/ https://docs.podman.io/en/latest/

forrestthewoods 4y ago

The solution is simple: ship your fucking dependencies. Every application should ship every dependency it requires. Attempting to use random shit that may or may not be installed on the system is a disaster. Containers that include all dependencies achieves this. Infact I like to argue that the only reason containers exist is because reliably launching software is so outrageously complex the only way to do is create a full system imagine. It’s a modern day tragedy. Disk space is cheap. If every application shipped duplicate dependencies it’d be… totally fine. The downside is inability to update security vulnerabilities. But if everyone is shipping containers that seems kinda moot. iOS and Android don’t have this issue. When you install an app it just works. Windows has the issue somewhat, but it’s mostly a problem with dev tools that are trying to pretend their in Linux. If you ship your fucking dependencies it’s a non-issue.

mab122 4y ago
What is the difference between shipping dependencies and shipping container? Thin layer of metadata? Or am I missing something?
mjevans 4y ago
Every security update means updating every big bundle of packages when it's a small change in some commonly used core library. Even IF my bandwidth and time were free (neither are) that is still a ton of duplicated work and wear on non-volatile memory life.
- forrestthewoods 4y ago
  > Every security update means updating every big bundle of packages when it's a small change in some commonly used core library. Replacing all instances of libFFMoeg.so on a drive is not particularly harder than replacing one. > that is still a ton of duplicated work and wear on non-volatile memory life. Nonsense. We’re talking about replacing libraries on the order tens to hundreds of megabytes during a monthly update. It’s peanuts. Time I’ll give you. But the current system of system-wide libraries is objectively broken. As evidenced by the increasing usage of containers to work around the brokenness. I’d wager far more time is wasted on docker orchestration. It’s probably worth differentiating between servers and personal machines. Lord knows how many vulnerabilities are in your Steam library. It’s a lot.

zokier 4y ago

I feel the article is missing the point of distros. They are supposed to be fully self-contained integrated operating systems, not just container platforms. Additionally, essentially vendoring full dependency trees for each application separately would massively increase the maintenance burden because instead of just maintaining one version of a library the distro will need to maintain n versions > Modern applications are inherently fragile. There is nothing inherent in the fragility, it is self-inflicted problem of some applications.

compsciphd 4y ago
I'm not sure distro needs to "maintain" N versions. The distro maintain 1, but all N remain available and able to fulfill the dependencies of the underlying application It's not the distro's job to ensure the application is secure and up to date, its up to the application packager (i.e. docker container maintainer) to do that. i.e. to rev new releases of the application image even if nothing has changed in the core app, just to take care of security updates in distro provided packages). In pr
- cuu508 4y ago
  > It's not the distro's job to ensure the application is secure and up to date I would prefer a distro that ensures applications in its repository are up to date. Consider a log4j-type issue. In one case, the distro quickly fixes the vulnerability in a library package, the user installs the update and that is that. In the other case, the user has to track down which installed applications use the affected library, update them if there is an update available, and figure out what to do if there is no update available.
  - josephg 4y ago
    > Consider a log4j-type issue. … the user installs the update and that is that. I hear what you’re saying. But - I’ve been writing a lot of rust lately. For better and worse, most rust programs pull in dozens of crates as direct or transitive dependencies. Apt isn’t up to the task of replacing cargo: - Apt’s dynamic library mechanism is designed around C’s dynamic library support. This doesn’t work with many other languages. It certainly doesn’t work with rust, which doesn’t have an ABI. - There are too many rust packages, and they update too frequently for apt to keep up. Apt could be a bad, out of date, partial clone of cargo. But that sounds worse than cargo in every way. - Shipping deps with cargo (or whatever) is preferred by app developers because cargo is better integrated with the language. And it works reliably on every platform. A dpkg wouldn’t even work on every version of Debian. We have a similar problem with ruby gems, nodejs packages (in npm), etc etc. I could imagine apt wrapping cargo, npm, and friends and providing equivalent functionality. But the authors of apt seem to think it’s already good enough. It’s not. Cargo, npm, and friends run rings around apt from the point of view of developer mindshare, ease of use, platform independent packaging, and so on. Apt and friends don’t have the features we want, and all the browbeating in the world won’t change that.

Karellen 4y ago

> Modern applications are inherently fragile. Well, there's your problem.

compsciphd 4y ago

I literally wrote part of my phd dissertation on this (can call it proto docker as it predated it and they seemed to use much of the same nomenclature I used, also was sort of a toss in an the very in, though arguably my most important contribution). see - https://www.usenix.org/legacy/event/lisa11/tech/full_papers/Potter.pdf https://www.usenix.org/legacy/event/lisa11/tech/full_papers/...

teddyh 4y ago

People are generally opposed to forking, right? If you fork a project, you effectively take over all the responsibilities to fix bugs and security issues etc. in that project, which is, most of the time, more work that the fork is worth. Now, a popular recent trend is “vendoring” your dependencies; i.e. bundling the dependencies with your software. However, vendoring does not differ much from forking. The responsibility may be slightly less, since you only have to fix bugs and issues affecting your application’s usage of the software. But, just like a fork, the longer you go without merging from the upstream version, the more work it is to maintain your fork. I suggest that vendoring, just like forking, should be avoided, for largely the same reasons.

doubleunplussed 4y ago

vscode example notwithstanding, I do not encounter the 'conflicting packages' problem very often on Arch. In fact, I don't remember the last time I encountered it, other than when it's an explicit choice - like, Python can only have one version of a package installed for the system Python interpreter, so if you try to install both python-numpy and python-numpy-mkl-bin, well, you have to choose. That's how Python works, though you can of course make additional Python environments (venv/conda/whatever) with different packages. I notice the vscode example involves the AUR, which is not the official repositories. I consider that a broken package, and it should be fixed. One of the packages should rename its main executable or whatever. Chrome, for example, has various versions, but they ship binaries with different names, e.g. /usr/bin/google-chrome-stable. The great thing about Arch is that there is one canonical user repository, the AUR. So the official repos should not have conflicts unless absolutely necessary, and the AUR should endeavour not to have conflicts, though it's more of a wild-west so they're somewhat more likely. However, you generally don't have to think about how to not conflict with whatever random packages may be out there - you only need to consider the repos and the AUR. Anyone making their own packages that are not in the official repos or the AUR, and yet conflict with them, well, that's their problem. Arch being super up to date and the existence of the AUR really does obviate the need for containerising apps to a large degree, at least from the perspective of ensuring dependencies are satisfied (there are still security reasons to want containerisation). I don't believe I have any containerised apps, and yet I'm running loads of modern common programs like zoom, chrome, discord, spotify, the list goes on.

tempay 4y ago
> if you try to install both python-numpy and python-numpy-mkl-bin, well, you have to choose. That's how Python works It's possible to have as many Python versions as you like installed at the same time. All of the libraries and headers include the major/minor version, packages are installed in `lib/pythonX.Y` and the Python binary itself is available as `pythonX.Y`. Few distributions support this well for anything other than a single 2.x and 3.x but it's nothing to do with how Python itself works.
- doubleunplussed 4y ago

ddevault 4y ago

Nonsense. There are essentially two conflicting ideals here: what developers want and what distros want. The problem is that distros are generally right and what distros want is also what users want. So it's devs against the world. Devs want to ship updates whenever they want and force them into their users' machines as soon as possible, and forget about updating dependencies and pin them to ten versions ago so they never have to eat the cost of upgrading them. Devs don't want to make sure their application plays well with others, they just want to package it up in its own universe, the user's hard drive space and bandwidth be damned. Devs never want to finish their software or declare it stable, they just want to ship their machine on Monday morning so users have it installed by Monday afternoon, just to be updated again on Wednesday. Devs want to ship spyware and adware and malware without any oversight. All of this is cheap and profitable for devs but highly antisocial. Everything is better about the distro model: security, efficiency, and stability, and they represent the users interests even when they conflict with the dev's interests. "Modern applications" are developed by children and distros are the teacher slapping them on the wrist for misbehaving. Don't bitch about it -- just grow up.

alkonaut 4y ago
As a user I just want the app to be exactly like you describe: a) isolated from all other apps b) self-updating and have a release cycle decoupled from all other apps on my system. In this scenario (for my personal desktop OS) I don't care about bandwidth, disk space or whether an app uses an out of date version of a library. Having a release per week isn't uncommon and isn't somehow a sign that an app has poor quality. I'm not going to say a generalization is dead because of one counterexample, but It's perhaps not as clear cut as you make it out to be.
- ddevault 4y ago
  As a user you are asking for a measurably worse experience. And given context, I suspect you are a developer, not just a user. A release per week is a sign that an app has poor quality.
  - 4y ago

forgotpwd16 4y ago

Nix solves the mentioned issues without using containers. Not sure why they keep referring to containers as only solution when Nix is included. Also not sure why they talk specifically about graphical applications. The issues mentioned apply to every program running on the system. That said, agree on those issues.

nine_k 4y ago
I bet it has something to do with Dockerfile having far simpler syntax than Nix config files.

qwery 4y ago

> However, Electron based applications vary, as they are built on top of different versions of Electron. I thought one of the selling points of Electron et al. was building apps on web standards. What is changing so fundamentally between versions of Electron that prevents apps from running on the latest release? I wouldn't expect Element to not work on Firefox 432[0] after using it on Firefox 431... [0] I lost track of Firefox version numbers somewhere between 3 and 50

kkfx 4y ago

I think many, too many still fail to see two thing: - packages/package management is intimately tied to filesystems and so installers. Actual package models are based on '80s Unix model that do not scale anymore since decades. Such model was designed decoupling "system code" to "user code" (script, mostly) while all along the IT history, both before and after unix we see a better model (see below); - packages in FLOSS are NOT meant do be made by upstream developers, that's a need of commercial only software. In FLOSS systems packagers of any distro package upstream code. Now a step at a time: classic systems where designed as a single application, indefinitively extensible by many, and users included. At a certain point in time AT&T/IBM and others say "ah, no that's bad" IMVHO just to deprive users of much power and gain the ability to sell limited, limiting and poorly designed crap. For more than a decade such decoupling take shape. After decades of big mess frameworks spring to life as a kind of middle-ground and they prove to be no better than the decoupled crap they try to solve without coming back to the classic OS-as-a-single-application model. Now essentially ALL non trivial applications being unable to effectively integrate each others try to be "the only one application" and finding no way to do so some pull out of the hat an even worse cage: hiding the OS on someone else computer, used as a bootloader of a modern more limited and limiting Java VM: the WebVM improperly named browser for legacy reasons. Pushing "the network is the computer" to "the cloud is the system". To solve this mess what we need is the original solution: the OS as a single application where source code is in the runtime, no "packaging" just SCM. Oh, surely that does not solve version conflict between source, these actually are ALREADY solved in architectural terms by the FLOSS distribution model: packagers assemble code. But working directly on source makes that far easier with simple sharable patches who happen to be also a bit distro-neutral. Nix/Guix offer the actual middle ground. To solve the storage mess it's far more complex. Today most solutions simply use a backend storage service, a kind of DB, no matter if SQL-alike or key-value or something else. SUN with zfs realize a very first limited evolution in that sense, but far from current needs. BeOS with if raw "query-able file system" have done another very small part before. https://twizzler.io https://twizzler.io seems to offer something more modern, but that's still an open issue.

edent 4y ago

There is, I think, a bit of a paradigm shift in action. In the old world, disk space was limited and download speeds were slow. So it made sense for every app to use the system-provided version of Library X. Additionally, stability and backwards compatibility was assumed. So if the distro updated to Library X v1.2, and your app relied on v1.1, everything would still work. Today's world is very different (for many users). Disk space is cheap and plentiful and downloading a couple of GB takes an instant. So why not bundle everything together? Additionally, developers can't be sure of stability in their dependencies. And the app developer is the person who receives the complaints from angry users, not the library developer. So it makes perfect sense to use a self-contained set of libraries and dependencies. The pendulum will swing the other way in time. We'll all get annoyed at having a dozen different Electron libraries taking up space, and we'll go back to one-library-to-rule-them all. But - as someone who used to hate battling dependency hell - I love Flatpack.

Karellen 4y ago
> Additionally, stability and backwards compatibility was assumed. So if the distro updated to Library X v1.2, and your app relied on v1.1, everything would still work. I thought all the cool kids had adopted `semver` these days, so this shouldn't be a problem? Except for crappy libraries/dependencies, in which case surely the answer is: Don't use crappy dependencies; find an alternative that does the same thing, without sucking. > Additionally, developers can't be sure of stability in their dependencies. Again, be more judicious in which dependencies you use. Stay away from the crap ones, find ones that do the right thing. > Disk space is cheap and plentiful and downloading a couple of GB takes an instant. Maybe for you. But not for everyone on the planet. Or, maybe people who live in places with intermittent internet connectivity don't deserve new software, or for their needs to be considered? > So why not bundle everything together? Security. If a serious vulnerability is found in Library X v1.1, I want to be able to upgrade it to Library X v1.1.1 and know that every single app that uses it is safe, without even needing to know which apps use it. I don't want to have to figure out which apps use it (which, OK, might not be too hard if the tools are written to find that out), and then have to download an update for every single one. Even if I do have unlimited gigabit broadband, that could still be awkward if the library is sufficiently popular and widely used.

choeger 4y ago

The problem is that containers are opaque and authors simply don't care about quality. If say, fedora would allow containers by having deviating Versions of rpms per app, it would be quite cool. The OS could inform me about apps using deprecated Versions, dependencies could be shared, etc. But people don't want to put up much effort when shipping their app. They want to build on some version of Ubuntu, add some manual hacks and expect everyone to use that container for the next decade or so. No one cares about dependencies, security or other nonfunctional aspects, sadly.

kasabali 4y ago

Yet another article arguing against distribution package managers without understanding them a bit. Traditional packaging is perfectly suitable for modern applications. What author is arguing against is the distributions' packaging policies. Distribution policies are what prevents shipping multiple versions of the same library or program, not package managers. These policies are in place because they're necessary for releasing and maintaining a 50000 package distribution. But for shipping your own software you're free to ignore distribution policies. Package managers have always provided the necessary mechanism. Nothing is preventing you from shoving in all library, binary or data dependencies your program needs into a deb package. You're also free to embed version number in package name and installation paths so different versions could be installed in parallel. The package manager will obey dutifully. Build systems have always been capable of installing libraries into arbitrary paths, and deb/rpm packages are just dumb archive files with metadata slapped on top. If you shove everything needed into it and declare no dependencies, it'll be no different than a dumb tar file and it'll work just fine if you did it right. You can even imitate flatpak runtimes if you want. Put same things a flatpak runtime has into /usr/lib/freedesktop-sdk-21.08 into a package like freedesktop-sdk-2108.deb, and make your application deb depend on freedesktop-sdk-2108 and you're good to go. I'm really tired hearing of these baseless arguments over and over over the years. I just wish everyone could be honest and just say "We don't like deb/rpm, they're not cool, they're not hip, we just want to NIH them" so we could be spared of these made up justifications. P.S. I have nothing against nix. Nix is legit innovation.

hnaccountme 4y ago

Better title would be "Traditional Packaging Is Not Suitable For Low Skilled Developers"

eqvinox 4y ago

> Traditional packaging introduces several issues, such as dependency and package conflicts, which usually require workarounds that differ from one distribution to another. I feel that there was no thought here at all regarding the reverse perspective: Current application development and deployment practices introduce several issues, such as dependency and package conflicts, which usually require workarounds that differ from one application to another.

friendzis 4y ago

The fundamental problem is not that distribution maintainers do not leverage containers, but rather we do not understand dependency models/trees of our programs. Containers are golden images. You find combination of stuff that works, carefully package them together and ship this whole package. Gold images run on bare metal, containers run on container runtime enabled kernel. Sure, containerizing an application is /easier/ than working out the dependency trees and solving dependency conflicts between them. It is by no means fundamentally better approach. If anything, this argument dismisses most work done by distros - building and solving those dependency trees. Maintainers of free OSes sometimes do not bother to solve all possible conflicts, however instead of breaking the system/packages, they do inform you of possible conflicts that are not solved. Inability to cherry-pick dependencies is deceptively wrong. Traditional distributions resort to use of so called meta-packages and alternatives to keep the system up to date. Deb/rpm packages are simple archives with additional metadata slapped on. The packaging system is transparent to contents: nothing forbids you to package versions 1.0 and 2.0 and have them happily coexist as long as they do not share common paths. In fact, a lot of packages are distributed in exactly the same way. It seems that the author has a solution - containers - and tries to find a problem for said solution.

jasode 4y ago
>Sure, containerizing an application is /easier/ than working out the dependency trees and solving dependency conflicts between them. It is by no means fundamentally better approach. [...] The [distro] packaging system is transparent to contents: nothing forbids you to package versions 1.0 and 2.0 and have them happily coexist as long as they do not share common paths. I think your comment is analyzing the problem from a different abstraction level than the author's examples. In other words, your alternative approach of "solving dependency conflicts" is abstract advice unless you try to make it concrete by focusing who solves those dependency conflicts. Using the author's example of a VSCode conflict (collision of "/usr/bin/code") with Actor in italics: - Microsoft owns commercial the build of /packages/visual-studio-code-bin - Filipe Laíns & Massimiliano Torromeo owns the open-source-license build of /packages/community/x86_64/code/ - Levente Polyak, et al owns the Arch Linux distribution - end user owns the computer that needs to run conflicting software Generalize the above matrix to every software package and consider which of those 4 actors can practically solve the conflicts in a scalable way? Filipe Laíns & Massimiliano Torromeo can't control what Microsoft does and vice-versa. (Ironically, the freedom to not be controlled by the other actor is one reason there's a package conflict!) And Levente Polyak could "solve" it by blessing Filipe Laíns's package and rejecting Microsoft's but this creates a new "problem" for users who specifically want Microsoft's commercial build. The fundamental issue is that you have independent actors that can't control what others do. Result is that sometimes software packages clash (namespace collisions, dependent libraries not in sync, incompatible licenses, etc). The approach of using containers -- however flawed it is -- gets past the stalemate of independent actors in the software landscape being incompatible with each other.

camgunz 4y ago

I generally think these arguments (containers, flatpak) boil down to: I don't want to figure out how a distro works. I'm unsympathetic to that; it's actually pretty easy to figure that out: they almost all use systemd and making a deb/rpm is also straightforward (there are great guides). Distros are also great at updates, to the degree devs can largely outsource a lot of it to them (compared with Windows where you're writing update functionality into your app, or whatever). I'm not even sympathetic to weird cases like OBS needing a forked version of ffmpeg. 1 this sounds like a wacky thing to do, 2 it sounds like they created a new project that is a different dependency. Call it something else (I suggest obsmpeg), package it for distros, pull in updates from ffmpeg whenever you want, reap the benefits of FOSS. Inventing an entirely new software delivery system instead seems like an overreaction. I am sympathetic to working this out across multiple distros though. Finding the intersection of packages across multiple versions of Ubuntu, Debian and Fedora isn't super easy, and it can really hamstring you when building an app (you want to use libcool-1.8.x, Ubuntu LTS has libcool-1.2.25, :sad:). The ecosystem isn't set up for this and it's a pain to deal with in your app (you more or less #ifdef functionality out, which product managers will freak out about).

iudqnolq 4y ago
As a regular Linux user who doesn't publish apps but has been reading this argument for years I've never understood the value distros provide. They're clearly doing a huge amount of work editing everything, but it also doesn't seem like they have the resources to properly test their edits. And while their edits are necessary to make everything work with their system, from a high level perspective they don't seem to be making the software better at what I want it to do. Given that, their model looks like dangerous busywork that at best delays updates and at worst introduces new bugs. Distros use the word "maintain" to describe what they're doing, but they don't seem to be doing that. To maintain a piece of software I'd expect the maintainer to need a deep understanding of the source code and to continually monitor changes. The complaints maintainers post that software changed seem to prove they aren't doing that. When I first saw a maintainer complain a library only posted about a breaking build change in their release notes and mailing list I was shocked. I had been assuming they were reading diffs, when they weren't even reading the changelog.

Roark66 4y ago

How can one write an article like this and fail to mention guix? It solves _a_lot_ of the problems mentioned. Guix (and all its channels) is a great piece of software, but unfortunately its potential for populartity is severely diminished by the insistence of the core user/dev group that its goals are not purely technological, but ideological(perhaps even primarily ideological). It seems that for many devs guix is less of a technical achievemt,and more a way of preventing people from being able to run what they call "non free software". BTW, "non free software" also includes open source software that was released under certain non-compliant licenses. The biggest issue I have with guix is that any effort of packaging "non-free" software (such as cuda, intel MKL, nvidia drivers etc). Is heavily discouraged, and if it it does happen its discussion is banned from official channels and all authors which make such software available in their personal repos seem to meekly include various pledges in the READMEs "to not advertise this horrible evil thing, or otherwise let people know of its existence". To me this behaviour is very far away from encouraging "free software", but my and their definition of free differ a lot. My second issue with guix is that the language used to write everything(guile) still lacks many crucial debugging and ease-of-use features such as: being able to display more meanigful error messages, being able to show on which line of compiled code the error/exception happens at, being able to easily interrogate variable value types (there seem to be lots of is_this_value_a_string?, or is_this_value_an_integer? functions, but no what_type_is_this?), no standard way to convert nested objects to string, or to pretty-print deeply nested objects. To this one has to add pretty substantial, but really poorely laid out documentation of the language (from the very first chapter the authors in their examples use all language features that may not be explained until 300 pages in - so the reader basically has to read the whole thing multiple times to "get it"). And so on... All those things matter a lot to beginners and they matter less to advanced users. If this language and guix in general is to catch on, it has to be more beginner friendly. However as a package manager it really is pretty good. It delivers everything nix does, but uses a more standardised and powerfull general purpose language. I can't wait until someone forks guix without the whole ideology thing.

forgotpwd16 4y ago
>I can't wait until someone forks guix without the whole ideology thing. There's no reason to fork Guix since ideology doesn't affect the software itself at all. Rather what you want is make an alternative definitions repo. Pretty sure I've seen such one that includes software not accepted on official channels.

al2o3cr 4y ago

I dunno about "modern" - I can recall distro packaging making a total disaster of Ruby gems over a decade ago.

noobermin 4y ago

Just spit balling ideas here, how much of the problems containerizing is meant to solve would be solved by merely static linking? Because it feels like that's what containers are mostly used for. Static linking + a sandbox to get most of everything. Using shared libraries but then shipping the .so's in a container defeats the point of a .so in the first place. If the reason containers are okay now since disk space is cheap, why not return to static linking of executables?