4 ms·

That’s what containers do - package the dependencies with a piece of running code. That’s also one of the main reasons for their quick, wide adoption, even by c

That’s what containers do - package the dependencies with a piece of running code. That’s also one of the main reasons for their quick, wide adoption, even by conservative enterprises. But this gets more challenging as the granularity of what’s being packaged reduces. You can see this even in the container case: consider a container that depends on a particular version range of another container. For any possible solution to this, there are disadvantages which make it untenable in some situations. There’s no good general solution to this other than being explicit about the version dependencies and solving the dependency issues when deploying, whether manually or automatically. A automated solver helps with that. Btw, you can see something like what you described in Java programs built with Maven (for example). Run Maven’s dependency:tree function on any non-trivial program and you’ll see different versions of the same package appearing over and over, because each package does have its own (logical) space for dependencies. But Maven still has a version solver built in, and even with your proposed solution plus a solver, you can find plenty of articles on the web saying things like “Maven dependency conflicts can be really hard to solve.” The reason for that is when it fails, it’s because it’s encountered a difficult or impossible situation that (currently) requires human intervention.

3cats-in-a-coat 3y ago
Containers are a work around for this issue, a Band-Aid.
- antonvs 3y ago
  Not at all. They do exactly what you were suggesting. If you think they’re a bandaid, then you’d need to explain why your own suggestion isn’t a bandaid.
  - eternityforest 3y ago
    How many container systems can share dependencies in both RAM and disk, and do all the same kinds of IPC, while also sharing system daemons and all that? The way Android and more recent Windows do things is my favorite solution so far. All dependencies included in static packages, not actually containerized, and with all the heavy lifting done by things built right into the OS, always there, and specifically designed to be used that way, without much emphasis on lots of separate daemons, at least not on desktop. Even just saying "The OS always has this daemon" isn't enough, because so many services are designed to be configured specifically for a deployment and there isn't any one size fits all solution. Even something as simple as MQTT has a ton of ways to configure it, and there's no way for a client to even query what permissions it has and what other clients are on what available servers, it all has to be manually set up.
    - antonvs 3y ago
      Containers aren't perfect, of course. But they do exactly what the other commenter was asking for: "Every piece of running code should have its own space for dependencies." Could it be done better? Sure. But there are tradeoffs. You mentioned Android, where the obvious tradeoff is that the entire ecosystem revolves around the Dalvik VM. That approach isn't really practical right now for more general OSes like Linux and Windows.
      - eternityforest 3y ago
        I'm not so sure the whole OS revolving around Dalvik is really a problem. You can still run C++ native code to accelerate specific things. Obviously it's a problem because of all the millions of man hours of existing stuff for other OSes, but in theory, I don't see why a managed code only ecosystem wouldn't work. I could even see it being faster than current OSes, in some future imaginary world where Android had a MakeHardwareAcceleratedCDNServer(folder, port, config). So many applications(Obviously not all, but a fair number) out there are fairly boring, probably shouldn't even be written at all, and probably could be covered with a small set of high level primitives. If we had kept on thinking the way we did in the early days of Windows, we'd probably have more things like Excel, abstractions that cover insane numbers of use cases without plugins or anything.

3cats-in-a-coat 3y ago

Containers are a work around for this issue, a Band-Aid.

antonvs 3y ago
Not at all. They do exactly what you were suggesting. If you think they’re a bandaid, then you’d need to explain why your own suggestion isn’t a bandaid.
- eternityforest 3y ago
  How many container systems can share dependencies in both RAM and disk, and do all the same kinds of IPC, while also sharing system daemons and all that? The way Android and more recent Windows do things is my favorite solution so far. All dependencies included in static packages, not actually containerized, and with all the heavy lifting done by things built right into the OS, always there, and specifically designed to be used that way, without much emphasis on lots of separate daemons, at least not on desktop. Even just saying "The OS always has this daemon" isn't enough, because so many services are designed to be configured specifically for a deployment and there isn't any one size fits all solution. Even something as simple as MQTT has a ton of ways to configure it, and there's no way for a client to even query what permissions it has and what other clients are on what available servers, it all has to be manually set up.
  - antonvs 3y ago
    Containers aren't perfect, of course. But they do exactly what the other commenter was asking for: "Every piece of running code should have its own space for dependencies." Could it be done better? Sure. But there are tradeoffs. You mentioned Android, where the obvious tradeoff is that the entire ecosystem revolves around the Dalvik VM. That approach isn't really practical right now for more general OSes like Linux and Windows.
    - eternityforest 3y ago
      I'm not so sure the whole OS revolving around Dalvik is really a problem. You can still run C++ native code to accelerate specific things. Obviously it's a problem because of all the millions of man hours of existing stuff for other OSes, but in theory, I don't see why a managed code only ecosystem wouldn't work. I could even see it being faster than current OSes, in some future imaginary world where Android had a MakeHardwareAcceleratedCDNServer(folder, port, config). So many applications(Obviously not all, but a fair number) out there are fairly boring, probably shouldn't even be written at all, and probably could be covered with a small set of high level primitives. If we had kept on thinking the way we did in the early days of Windows, we'd probably have more things like Excel, abstractions that cover insane numbers of use cases without plugins or anything.