4 ms·

That's basically correct. But the more general problem is that engineers simply lost the ability to succinctly package applications and their dependencies into

by bane 1y ago

That's basically correct. But the more general problem is that engineers simply lost the ability to succinctly package applications and their dependencies into simple to distribute and run packages. Somehow around the same time Java made .jar files mainstream (just zip all the crap with a manifest), the rest of the world completely forgot how to do the equivalent of statically linking in libraries and that we're all running highly scheduled multithreaded operating systems now. The "solution" for a long time was to spin up single application Virtual Machines, which was a heavy way to solve it and reduced the overall system resources available to the application making them stupidly inefficient solutions. The modern cloud was invented during this phase, which is why one of the base primitives of all current cloud systems is the VM. Containers both "solved" the dependency distribution problem as well as the resource allocation problem sort of at once.

procaryote 1y ago
> engineers simply lost the ability to succinctly package applications and their dependencies into simple to distribute and run packages. but this is what docker is If anything, java kinda showed it doesn't have to suck, but as not all things are java, you need something more general
- BSVogler 1y ago
  With the difference that with docker you are shipping the runtime to your source code as well.
  - arccy 1y ago
    which is great when you realize that not all software is updated at the same time. how managing multiple java runtime versions is supposed to work is still beyond me... it's a different tool at every company, and the instructions never seem to work
    - qcnguy 1y ago
      Java runtimes is just: export JAVA_HOME=/path; ./app.sh
      - procaryote 1y ago
        But the java runtime needs to be at /path then, and it needs to stay there as long as ./app.sh needs it. And when app2.sh needs a different version you need that to be at /path2
    - oftenwrong 1y ago
      It's less complicated than you might think. A Java Development Kit (JDK) is a filesystem directory, and includes everything necessary to run a Java program. Most of the mysterious installers and version managers are managing a collection of these JDK directories in some fixed location on disk. You can download a JDK directory (tarball), and use the `java` binary within it directly. There is also a convention of using the `JAVA_HOME` environment variable to allow tools to locate the correct JDK directory. For example, in a unix shell, add `$JAVA_HOME/bin` to your `PATH`.
  - procaryote 1y ago
    You need the runtime though
bborud 1y ago
I would argue that the traditional way to install applications (particularly servers) on UNIX wasn’t very compatible with the needs that arose in the 2000s. The traditional way tends to assume that there will be only one version of something installed on a system. It also assumes that when installing a package you distribute binaries, config files, data files, libraries and whatnot across lots and lots of system directories. I grew up on traditional UNIX. I’ve spent 35+ years using perhaps 15-20 different flavors of UNIX, including some really, really obscure variants. For what I did up until around 2000, this was good enough. I liked learning about new variants. And more importantly: it was familiar to me. It was around that time I started writing software for huge collections of servers sitting in data centers on a different continent. Out of necessity I had to make my software more robust and easier to manage. It had to coexist with lots of other stuff I had no control over. It would have to be statically linked, everything I needed had to be in one place so you could easily install and uninstall. (Eventually in all-in-one JAR files when I started writing software in Java). And I couldn’t make too many assumptions about the environment my software was running in. UNIX could have done with a re-thinking of how you deal with software, but that never happened. I think an important reason for this is that when you ask people to re-imagine something, it becomes more complex. We just can’t help ourselves. Look at how we reimagined managing services with systemd. Yes, now that it has matured a bit and people are getting used to it, it isn’t terrible. But it also isn’t good. No part of it is simple. No part of it is elegant. Even the command line tools are awkward. Even the naming of the command line tools fail the most basic litmus test (long prefixes that require too many keystrokes to tab-complete says a lot about how people think about usability - or don’t). Again, systemd isn’t bad. But it certainly isn’t great. As for blaming Python, well, blame the people who write software for _distribution_ in Python. Python isn’t a language that lends itself to writing software for distribution and the Python community isn’t the kind of community that will fix it. Point out that it is problematic and you will be pointed to whatever mitigation that is popular at the time (to quote Queen “I've fallen in love for the first time. And this time I know it's for real”), and people will get upset with you, downvote you and call you names. I’m too old to spend time on this so for me it is much easier to just ban Python from my projects. I’ve tried many times, I’ve been patient, and it always ends up biting me in the ass. Something more substantial has to happen before I’ll waste another minute on it.
andoando 1y ago
And even a java program may need a system wide install of ffmpeg or opencv or libgtk or VC runtime 2019 but not 2025 or some other dependency. And sometimes you want to ship multiple services together. In any case 'docker run x' is easier and seemingly less error prone than a single sudo apt get install

by bane 1y ago

procaryote 1y ago

> engineers simply lost the ability to succinctly package applications and their dependencies into simple to distribute and run packages. but this is what docker is If anything, java kinda showed it doesn't have to suck, but as not all things are java, you need something more general

BSVogler 1y ago
With the difference that with docker you are shipping the runtime to your source code as well.
- arccy 1y ago
  which is great when you realize that not all software is updated at the same time. how managing multiple java runtime versions is supposed to work is still beyond me... it's a different tool at every company, and the instructions never seem to work
  - qcnguy 1y ago
    Java runtimes is just: export JAVA_HOME=/path; ./app.sh
    - procaryote 1y ago
      But the java runtime needs to be at /path then, and it needs to stay there as long as ./app.sh needs it. And when app2.sh needs a different version you need that to be at /path2
  - oftenwrong 1y ago
    It's less complicated than you might think. A Java Development Kit (JDK) is a filesystem directory, and includes everything necessary to run a Java program. Most of the mysterious installers and version managers are managing a collection of these JDK directories in some fixed location on disk. You can download a JDK directory (tarball), and use the `java` binary within it directly. There is also a convention of using the `JAVA_HOME` environment variable to allow tools to locate the correct JDK directory. For example, in a unix shell, add `$JAVA_HOME/bin` to your `PATH`.
- procaryote 1y ago
  You need the runtime though

bborud 1y ago

I would argue that the traditional way to install applications (particularly servers) on UNIX wasn’t very compatible with the needs that arose in the 2000s. The traditional way tends to assume that there will be only one version of something installed on a system. It also assumes that when installing a package you distribute binaries, config files, data files, libraries and whatnot across lots and lots of system directories. I grew up on traditional UNIX. I’ve spent 35+ years using perhaps 15-20 different flavors of UNIX, including some really, really obscure variants. For what I did up until around 2000, this was good enough. I liked learning about new variants. And more importantly: it was familiar to me. It was around that time I started writing software for huge collections of servers sitting in data centers on a different continent. Out of necessity I had to make my software more robust and easier to manage. It had to coexist with lots of other stuff I had no control over. It would have to be statically linked, everything I needed had to be in one place so you could easily install and uninstall. (Eventually in all-in-one JAR files when I started writing software in Java). And I couldn’t make too many assumptions about the environment my software was running in. UNIX could have done with a re-thinking of how you deal with software, but that never happened. I think an important reason for this is that when you ask people to re-imagine something, it becomes more complex. We just can’t help ourselves. Look at how we reimagined managing services with systemd. Yes, now that it has matured a bit and people are getting used to it, it isn’t terrible. But it also isn’t good. No part of it is simple. No part of it is elegant. Even the command line tools are awkward. Even the naming of the command line tools fail the most basic litmus test (long prefixes that require too many keystrokes to tab-complete says a lot about how people think about usability - or don’t). Again, systemd isn’t bad. But it certainly isn’t great. As for blaming Python, well, blame the people who write software for _distribution_ in Python. Python isn’t a language that lends itself to writing software for distribution and the Python community isn’t the kind of community that will fix it. Point out that it is problematic and you will be pointed to whatever mitigation that is popular at the time (to quote Queen “I've fallen in love for the first time. And this time I know it's for real”), and people will get upset with you, downvote you and call you names. I’m too old to spend time on this so for me it is much easier to just ban Python from my projects. I’ve tried many times, I’ve been patient, and it always ends up biting me in the ass. Something more substantial has to happen before I’ll waste another minute on it.

andoando 1y ago

And even a java program may need a system wide install of ffmpeg or opencv or libgtk or VC runtime 2019 but not 2025 or some other dependency. And sometimes you want to ship multiple services together. In any case 'docker run x' is easier and seemingly less error prone than a single sudo apt get install