3 ms·

What is really ironic is that none of this "tools" solves any fundamental problem of so-called version hell and none of this containers are fundamentally differ

What is really ironic is that none of this "tools" solves any fundamental problem of so-called version hell and none of this containers are fundamentally different from ./configure --prefix=/xxxx && make && make -s install with or without following chroot /yyyy The big "innovation" of having so-called "virtual env" (they call it "reproducible [development] environment) for each "hello world" (a whole python/ruby/java/etc installation with all packages and its dependencies in your [home] project directory) solves no real problem, only pushes it to the next guy (what they call devops). Some idiots even advocating to have a whole snapshot of an OS attached to your "hello world", and even to make it what they call "purely functional" or even "monadic" (why not, of someone pays for that). Unfortunately, there is no way to ignore complexity of versions and package dependencies or easily pushing it to "devops". Creating a zillion of "container images" with just your "reproducible development environment" or a whole "OS snapshot" just multiplies entities without a necessity. Programmer must be aware of which version of what API implemented with what version of package or library he using and explicitly assert and maintain these requirements, like all the very few sane software projects (git, nginx, redis, postgress) do. btw, the GNU autotools (which gives us ./configure) is somewhat evolved real-world solution - you have to explicitly check each version of each API both at the compile (build) time and refuse to build in case of unsatisfied dependencies and at the install time (and package manager must refuse to install if case of mismatch). This is the only way back to sanity, however "painful" it is.

TeMPOraL 11y ago
> Programmer must be aware of which version of what API implemented with what version of package or library he using and explicitly assert and maintain these requirements, like all the very few sane software projects (git, nginx, redis, postgress) do. Except that when you're doing anything that looks like an actual end-user application (as opposed to infrastructure), you end up using dozens of libraries which themselves have dependencies, so suddenly you're supposed to "explicitly assert and maintain" hundreds of different library versions, none of which is in any way relevant to the application you're building. I myself see Docker containers as the only reasonable way for giving a service application to people to deploy on their machines, because even the programming runtime I need is 5 years out of date on Debian/Ubuntu, and installing that stuff manually is a) pain, and b) different on every operating system.
- dschiptsov 11y ago
  > as the only reasonable way for giving a service application to people to deploy on their machines Take a look how git or nginx compiles from the source on any machine imaginable. There is absolutely no fundamental problem with ./configure; make; make install.
  - TeMPOraL 11y ago
    Does it work well when you have third-party dependencies?
  - lmm 11y ago
    That would be the same git that's still basically unusable on windows? And have you ever tried to cross-compile it? > There is absolutely no fundamental problem with ./configure; make; make install. The fundamental problem is incompatible versions of dependencies. Arguably it's in linux's dynamic linker rather than a problem with configure/make. But if you need to run something that depends on libfoo 2.3 and something else that depends on libfoo 2.4 on the same machine, you need something like docker.
antientropic 11y ago
I would be interested to know why you call purely functional package management "idiotic", given that one of its main goals is to solve the problem of version hell? I.e., to make it easy for a developer to specify that application X should use version V of library Y, without interfering with other applications on your system?
- dschiptsov 11y ago
  Very simple. There is so-called atomic operations, or transactions, which are good enough to solve the problem. Any "pure functionality" in this context is plain nonsense.
davexunit 11y ago
I think you are conflating purely functional, reproducible environments with the (for lack of a better term) Docker way of managing containers where you just make full disk image for everything with lots of duplication. It is very possible to have the former while avoiding the latter. Both the Nix and GNU Guix projects succeed at this. I recommend taking a look at them to see if they address your concerns.
- dschiptsov 11y ago
  I am old-school sysadmin and I still thinking in terms of what ldd command tells me, how shared libraries are implemented, how various dlopen based FFIs work, why I need this or that. The other approaches, such as Java's (where we "abstract out an OS") in practice leading only to a bigger mess, because it boils down to the very same libc, libm, libffi and friends. JVM is an ordinary userlevel program, so it obeys to the restrictions and rules for any other userlevel program. This is the sad truth for Java zealots. Basically, one cannot ignore an OS (at least when you still want to dlopen cand call the stuff instead of re-implementing it poorly) - it is just a wrong idea, leading to all these ridiculous FS-inside-JVM implementations and other messed up layers of unnecessary, redundant abstractions. System administration is still hard and it (necessity to think, understand and analyze) cannot be eliminated by some bunch of shell or ruby scripts and wishful thinking.

TeMPOraL 11y ago

> Programmer must be aware of which version of what API implemented with what version of package or library he using and explicitly assert and maintain these requirements, like all the very few sane software projects (git, nginx, redis, postgress) do. Except that when you're doing anything that looks like an actual end-user application (as opposed to infrastructure), you end up using dozens of libraries which themselves have dependencies, so suddenly you're supposed to "explicitly assert and maintain" hundreds of different library versions, none of which is in any way relevant to the application you're building. I myself see Docker containers as the only reasonable way for giving a service application to people to deploy on their machines, because even the programming runtime I need is 5 years out of date on Debian/Ubuntu, and installing that stuff manually is a) pain, and b) different on every operating system.

dschiptsov 11y ago
> as the only reasonable way for giving a service application to people to deploy on their machines Take a look how git or nginx compiles from the source on any machine imaginable. There is absolutely no fundamental problem with ./configure; make; make install.
- TeMPOraL 11y ago
  Does it work well when you have third-party dependencies?
- lmm 11y ago
  That would be the same git that's still basically unusable on windows? And have you ever tried to cross-compile it? > There is absolutely no fundamental problem with ./configure; make; make install. The fundamental problem is incompatible versions of dependencies. Arguably it's in linux's dynamic linker rather than a problem with configure/make. But if you need to run something that depends on libfoo 2.3 and something else that depends on libfoo 2.4 on the same machine, you need something like docker.

antientropic 11y ago

I would be interested to know why you call purely functional package management "idiotic", given that one of its main goals is to solve the problem of version hell? I.e., to make it easy for a developer to specify that application X should use version V of library Y, without interfering with other applications on your system?

dschiptsov 11y ago
Very simple. There is so-called atomic operations, or transactions, which are good enough to solve the problem. Any "pure functionality" in this context is plain nonsense.

davexunit 11y ago

I think you are conflating purely functional, reproducible environments with the (for lack of a better term) Docker way of managing containers where you just make full disk image for everything with lots of duplication. It is very possible to have the former while avoiding the latter. Both the Nix and GNU Guix projects succeed at this. I recommend taking a look at them to see if they address your concerns.

dschiptsov 11y ago
I am old-school sysadmin and I still thinking in terms of what ldd command tells me, how shared libraries are implemented, how various dlopen based FFIs work, why I need this or that. The other approaches, such as Java's (where we "abstract out an OS") in practice leading only to a bigger mess, because it boils down to the very same libc, libm, libffi and friends. JVM is an ordinary userlevel program, so it obeys to the restrictions and rules for any other userlevel program. This is the sad truth for Java zealots. Basically, one cannot ignore an OS (at least when you still want to dlopen cand call the stuff instead of re-implementing it poorly) - it is just a wrong idea, leading to all these ridiculous FS-inside-JVM implementations and other messed up layers of unnecessary, redundant abstractions. System administration is still hard and it (necessity to think, understand and analyze) cannot be eliminated by some bunch of shell or ruby scripts and wishful thinking.