7 ms·

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

by 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.
    - JohnFen 4y ago
      > There are too many rust packages, and they update too frequently for apt to keep up. That sounds like a pretty large downside to using Rust.
      - josephg 4y ago
        Having a large, healthy ecosystem of well maintained 3rd party packages is a delight.
    - pabs3 4y ago
      Rust has dynamic linking and a symbol name mangling ABI now and it is potentially useful enough that distros could use it. https://wiki.debian.org/StaticLinking#Rust https://wiki.debian.org/StaticLinking#Rust https://github.com/rust-lang/rfcs/pull/2603 https://github.com/rust-lang/rfcs/pull/2603 https://github.com/rust-lang/rust/issues/60705 https://github.com/rust-lang/rust/issues/60705
      - josephg 4y ago
        The symbol mangling ABI isn't considered stable yet. And even if it was stable, rust's struct packing is still compiler-defined. Rust libraries can be dynamically linked if they look like a C library, or get wrapped by abi_stable[1] or something. But this isn't the standard. Probably less than 5% of the crate ecosystem is packaged like this. And a 5% solution is nowhere near good enough. Right now, I can build any rust package on any system, no matter what dependencies it has by just running cargo build. For apt to be competitive, it'd need to pull the ~100k cargo packages into apt's repository, wrap all of them in abi_stable or some equivalent and parse Cargo.toml files into the equivalent dpkg config. Ideally it should also work across every OS (though starting with ubuntu, debian and mint would be a start). This is possible. But for all the hand wringing about how modern packages should use apt, nobody seems to actually care enough to make any of this happen. [1] https://crates.io/crates/abi_stable https://crates.io/crates/abi_stable
        pabs3 4y ago
  - robertlagrant 4y ago
    I don't think distros are going to be fixing vulnerabilities in all their packages. Is that what you mean?
    - cuu508 4y ago
      Yes, that is what I mean.
      - phkahler 4y ago
        That's not really their job. For log4j they could update that package. Any app that breaks as a result needs to be fixed upstream anyway, and then the distro can rebuild that. Fixes like that do get through the process, but it's not specifically the distros job to fix it. These problems are all about dependencies, which fall to upstream to make managable. If your favorite app breaks all the time it's probably because the code base is a giant mess. Oh, and some of the mess comes from too many different licenses in use, which prevents tighter integration of source code.
        ticviking 4y ago
        That is the entire value dynamic linking and a stable ABI and API provide me. The ability to seamlessly replace an updated dependency by restarting an application and loading the library. If I'm just going to completely rebuild the app and all of it's dependencies I may as well statically link them and get the unique optimizations we can do after link time by analyzing the resulting executable.
        cuu508 4y ago
        It's up to the distro to define what their job is. As I said, I prefer distros that proactively patch security issues regardless of what upstream does :-)
        robertlagrant 4y ago
        Point being a log4j issue would be downstream of the distro, not upstream.
  - compsciphd 4y ago
    applications in the distro should be up to date by simply being in the distro in that case, i.e. we are more talking about applications that are outside the distro and installed on top of it. Because we have dependency issues, containerization is a good method. anything the distro ships itself should always be using the latest of everything the distro ships.
- nine_k 4y ago
  A distro often has to maintain more than one version of a,library: consider Debian stable, oldstable, and backports.
- goodpoint 4y ago
  > It's not the distro's job to ensure the application is secure and up to date On the contrary, it's the most important feature of distributions.
  - compsciphd 4y ago
    so you install Oracle on a Debian installation, it's Debian's job to ensure Oracle is secure? I'm not talking applications provided by the distribution, those aren't "applications" (i.e. in my usage, something installed onto an existent operating system), but part of the provided operating system itself, and yes, I'd agree it's their job to keep their provided operating system secure. It's not their job to keep external apps secure (but to provide the means for whoever is maintaining those apps to keep them secure).
    - goodpoint 4y ago
      > those aren't "applications" ...
    - JohnFen 4y ago
      With Linux, anyway, the operating system is just the kernel. Everything else is an application.
forrestthewoods 4y ago
> self-inflicted problem of some applications It sure seems distro inflicted to me. The architecture induces fragility. Apps needing to very carefully step to avoid breaking things is the definition of fragile.
throw_a_grenade 4y ago
This is written from the point of view that implicitly assumes only a single application installed (= a container), where distro is reduced to API provider and some common utils the app author doesn't care about. It would be correct only if I was building an appliance. But as the user I have a general purpose computer which gets the work done over multiple apps. I think there lies deeper, cultural division between developers, who think the world (at least the computer) revolves around their app and their downstream, who desperately try to avoid more and more code shipped unto them for the upstream's convenience. It's not really a difference for upstream if they bundle a dependency or not (or 10k+, in the case of npm), but it quickly becomes a big support burden if you have multiple such "apps" installed.
- microtonal 4y ago
  It's not really a difference for upstream if they bundle a dependency or not (or 10k+, in the case of npm), but it quickly becomes a big support burden if you have multiple such "apps" installed. But only because distributions want to take control of everything. If a distribution just provided the necessary infrastructure to empower developers to maintain their own dependencies (like eg. Flatpak does), we wouldn’t have this issue.
  - qwery 4y ago
    > distributions want to take control of everything. I'm not sure where that's coming from. Distros/packagers (should) rightly feel a responsibility for a packaged application's quality, security, interoperability. > If a distribution just provided the necessary infrastructure to empower developers to maintain their own dependencies To stick with the Arch Linux example in the article, is the flatpak you get from `# pacman -S flatpak` not suitable for some reason?
    - iudqnolq 4y ago
      > I'm not sure where that's coming from. Distros/packagers (should) rightly feel a responsibility for a packaged application's quality, security, interoperability. This seems like false advertising. Ensuring an application is secure would require reading it's source. Based on maintainer complaints (like when that python package added a rust dependency) they don't seem to have the resources to even read all the changelogs.
kkfx 4y ago
> There is nothing inherent in the fragility, it is self-inflicted problem of some applications. The architecture is fragile due to too many layers. Anything is "fragile" in the sense that you can't really design a really complex, generic system with all possible state pre-computed and handled up front, the point is how to handle the fragility. Classic systems was "the OS is a single application where anything is ready available source code", this was utterly fragile in potential faults BUT far easier to correct any error so in the end far more robust. Think about some CL systems: you'll easily get far more issues in normal usage, but essentially any issue is easy to handle. The real underneath issue is business: software can't be a commercial product, must be a common open knowledge, like a kitchen recipe, where any party involved can see and act and anything is designed ONLY for the human. We need desktops in a network not dummy terminals of a central service designed to serve their owner.
- nine_k 4y ago
  > software can't be a commercial product, must be a common open knowledge, like a kitchen recipe Kitchen recipes rarely need features added or even bugs fixed. But when this happens, it's usually done by a cook on the spot. This is only possible due to utter simplicity of a typical recipe, compared to any substantial piece of software. Also, small variations in cooking usually result in pretty edible dishes, while small variations in a program can have drastic results. So no, sadly, software already cannot be like a cookbook.
  - kkfx 4y ago
    Try to compare commercial support, 99% of the time crappy and utterly slow vs community support and you'll get the answer. Even hyper-expensive commercial software have terrible support. Most FLOSS devs acts far better. Surely without formal legal guarantees.
    - nine_k 4y ago
      While I can agree in many cases (YMMV), the point is that there still need to be expert cooks, and pretty few of them cook a particular piece of software right. Very unlike NYT plum pie recipe which exists as common knowledge and which even I can cook adequately.
alkonaut 4y ago
> massively increase the maintenance burden The maintenance burden for who? Using isolated apps (Assuming that no-shared-libraries is what we want, which is probably true for desktop systems like and less true for security critical systems or "traditional" linux systems) just places the maintenance burden on the apps where it belongs. Yes, unmaintained apps should run out-of-date libraries.
- JohnFen 4y ago
  > Assuming that no-shared-libraries is what we want That's certainly not what I want on any system, desktop or otherwise.
deleted 4y ago
[deleted]

by zokier 4y ago

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.
  - JohnFen 4y ago
    > There are too many rust packages, and they update too frequently for apt to keep up. That sounds like a pretty large downside to using Rust.
    - josephg 4y ago
      Having a large, healthy ecosystem of well maintained 3rd party packages is a delight.
  - pabs3 4y ago
    Rust has dynamic linking and a symbol name mangling ABI now and it is potentially useful enough that distros could use it. https://wiki.debian.org/StaticLinking#Rust https://wiki.debian.org/StaticLinking#Rust https://github.com/rust-lang/rfcs/pull/2603 https://github.com/rust-lang/rfcs/pull/2603 https://github.com/rust-lang/rust/issues/60705 https://github.com/rust-lang/rust/issues/60705
    - josephg 4y ago
      The symbol mangling ABI isn't considered stable yet. And even if it was stable, rust's struct packing is still compiler-defined. Rust libraries can be dynamically linked if they look like a C library, or get wrapped by abi_stable[1] or something. But this isn't the standard. Probably less than 5% of the crate ecosystem is packaged like this. And a 5% solution is nowhere near good enough. Right now, I can build any rust package on any system, no matter what dependencies it has by just running cargo build. For apt to be competitive, it'd need to pull the ~100k cargo packages into apt's repository, wrap all of them in abi_stable or some equivalent and parse Cargo.toml files into the equivalent dpkg config. Ideally it should also work across every OS (though starting with ubuntu, debian and mint would be a start). This is possible. But for all the hand wringing about how modern packages should use apt, nobody seems to actually care enough to make any of this happen. [1] https://crates.io/crates/abi_stable https://crates.io/crates/abi_stable
      - pabs3 4y ago
- robertlagrant 4y ago
  I don't think distros are going to be fixing vulnerabilities in all their packages. Is that what you mean?
  - cuu508 4y ago
    Yes, that is what I mean.
    - phkahler 4y ago
      That's not really their job. For log4j they could update that package. Any app that breaks as a result needs to be fixed upstream anyway, and then the distro can rebuild that. Fixes like that do get through the process, but it's not specifically the distros job to fix it. These problems are all about dependencies, which fall to upstream to make managable. If your favorite app breaks all the time it's probably because the code base is a giant mess. Oh, and some of the mess comes from too many different licenses in use, which prevents tighter integration of source code.
      - ticviking 4y ago
        That is the entire value dynamic linking and a stable ABI and API provide me. The ability to seamlessly replace an updated dependency by restarting an application and loading the library. If I'm just going to completely rebuild the app and all of it's dependencies I may as well statically link them and get the unique optimizations we can do after link time by analyzing the resulting executable.
      - cuu508 4y ago
        It's up to the distro to define what their job is. As I said, I prefer distros that proactively patch security issues regardless of what upstream does :-)
        robertlagrant 4y ago
        Point being a log4j issue would be downstream of the distro, not upstream.
- compsciphd 4y ago
  applications in the distro should be up to date by simply being in the distro in that case, i.e. we are more talking about applications that are outside the distro and installed on top of it. Because we have dependency issues, containerization is a good method. anything the distro ships itself should always be using the latest of everything the distro ships.
nine_k 4y ago
A distro often has to maintain more than one version of a,library: consider Debian stable, oldstable, and backports.
goodpoint 4y ago
> It's not the distro's job to ensure the application is secure and up to date On the contrary, it's the most important feature of distributions.
- compsciphd 4y ago
  so you install Oracle on a Debian installation, it's Debian's job to ensure Oracle is secure? I'm not talking applications provided by the distribution, those aren't "applications" (i.e. in my usage, something installed onto an existent operating system), but part of the provided operating system itself, and yes, I'd agree it's their job to keep their provided operating system secure. It's not their job to keep external apps secure (but to provide the means for whoever is maintaining those apps to keep them secure).
  - goodpoint 4y ago
    > those aren't "applications" ...
  - JohnFen 4y ago
    With Linux, anyway, the operating system is just the kernel. Everything else is an application.

forrestthewoods 4y ago

> self-inflicted problem of some applications It sure seems distro inflicted to me. The architecture induces fragility. Apps needing to very carefully step to avoid breaking things is the definition of fragile.

throw_a_grenade 4y ago

This is written from the point of view that implicitly assumes only a single application installed (= a container), where distro is reduced to API provider and some common utils the app author doesn't care about. It would be correct only if I was building an appliance. But as the user I have a general purpose computer which gets the work done over multiple apps. I think there lies deeper, cultural division between developers, who think the world (at least the computer) revolves around their app and their downstream, who desperately try to avoid more and more code shipped unto them for the upstream's convenience. It's not really a difference for upstream if they bundle a dependency or not (or 10k+, in the case of npm), but it quickly becomes a big support burden if you have multiple such "apps" installed.

microtonal 4y ago
It's not really a difference for upstream if they bundle a dependency or not (or 10k+, in the case of npm), but it quickly becomes a big support burden if you have multiple such "apps" installed. But only because distributions want to take control of everything. If a distribution just provided the necessary infrastructure to empower developers to maintain their own dependencies (like eg. Flatpak does), we wouldn’t have this issue.
- qwery 4y ago
  > distributions want to take control of everything. I'm not sure where that's coming from. Distros/packagers (should) rightly feel a responsibility for a packaged application's quality, security, interoperability. > If a distribution just provided the necessary infrastructure to empower developers to maintain their own dependencies To stick with the Arch Linux example in the article, is the flatpak you get from `# pacman -S flatpak` not suitable for some reason?
  - iudqnolq 4y ago
    > I'm not sure where that's coming from. Distros/packagers (should) rightly feel a responsibility for a packaged application's quality, security, interoperability. This seems like false advertising. Ensuring an application is secure would require reading it's source. Based on maintainer complaints (like when that python package added a rust dependency) they don't seem to have the resources to even read all the changelogs.

kkfx 4y ago

> There is nothing inherent in the fragility, it is self-inflicted problem of some applications. The architecture is fragile due to too many layers. Anything is "fragile" in the sense that you can't really design a really complex, generic system with all possible state pre-computed and handled up front, the point is how to handle the fragility. Classic systems was "the OS is a single application where anything is ready available source code", this was utterly fragile in potential faults BUT far easier to correct any error so in the end far more robust. Think about some CL systems: you'll easily get far more issues in normal usage, but essentially any issue is easy to handle. The real underneath issue is business: software can't be a commercial product, must be a common open knowledge, like a kitchen recipe, where any party involved can see and act and anything is designed ONLY for the human. We need desktops in a network not dummy terminals of a central service designed to serve their owner.

nine_k 4y ago
> software can't be a commercial product, must be a common open knowledge, like a kitchen recipe Kitchen recipes rarely need features added or even bugs fixed. But when this happens, it's usually done by a cook on the spot. This is only possible due to utter simplicity of a typical recipe, compared to any substantial piece of software. Also, small variations in cooking usually result in pretty edible dishes, while small variations in a program can have drastic results. So no, sadly, software already cannot be like a cookbook.
- kkfx 4y ago
  Try to compare commercial support, 99% of the time crappy and utterly slow vs community support and you'll get the answer. Even hyper-expensive commercial software have terrible support. Most FLOSS devs acts far better. Surely without formal legal guarantees.
  - nine_k 4y ago
    While I can agree in many cases (YMMV), the point is that there still need to be expert cooks, and pretty few of them cook a particular piece of software right. Very unlike NYT plum pie recipe which exists as common knowledge and which even I can cook adequately.

alkonaut 4y ago

> massively increase the maintenance burden The maintenance burden for who? Using isolated apps (Assuming that no-shared-libraries is what we want, which is probably true for desktop systems like and less true for security critical systems or "traditional" linux systems) just places the maintenance burden on the apps where it belongs. Yes, unmaintained apps should run out-of-date libraries.

JohnFen 4y ago
> Assuming that no-shared-libraries is what we want That's certainly not what I want on any system, desktop or otherwise.

deleted 4y ago

[deleted]