Hacker News Reader

Comment by gnulinux | Hacker News Reader

I'm sorry but this doesn't work. Over the last 10 years so I was fucked over by countless "software that includes all its dependencies" that stopped working when I upgraded some other totally irrelevant software because "well duh it obviously uses system libC" or whatever. Examples: critical .AppImage binaries stopping working after random system upgrades. Nothing runs on my computer is ever fully isolated, not even Docker. So, any isolation guarantee I get is guarantee I'll take. You claim today that your software is isolated, but I don't know if 3 years down the road I'll upgrade my freaking text editor and your program will stop working because that one library from 1987 has to be exactly version A.X but my text editor upgraded it to A.Y. Thanks but no thanks.

View on HN

> your program will stop working because that one library from 1987 has to be exactly version A.X but my text editor upgraded it to A.Y.

Perhaps you misunderstand. This issue is fully solved by including dependencies and not relying on anything in the system path. Programs should not touch the system path. If a program requires library A.Y then it should include and use A.Y. But it should not touch the system path and thus should not impact any other program. Nor will it be impacted by other programs wanting A.Z.

It's often literally not possible to ship everything. You wouldn't want to spin up a second X11 (or Wayland) server, for example, because you can't have two of them talk to the same video card device at the same time usefully.

The number of things that can't be shipped is extremely small. And I don't think that Docker is a silver bullet for Wayland vs X11 issues? Although I'm not sure about the fine details as I don't have a ton of experience there. Shouldn't you be using an abstraction that can automatically support which ever is available?

I tend to ship code that needs to run on Linux + macOS + Windows + Android. So Docker is a total non-option. And it's totally fine! Very easy in fact.

It's the same thing everywhere — there are some dependencies you can't ship. On Linux, you can't ship the window server (because you need to share it with all of the other apps also running). On mac, you can't ship Core Foundation. On Windows, kernel32.dll etc. I assume Android is similar — I haven't tried figuring out what a purely static app on Android would be, since I think the bootstrap is Dalvik…

It's literally impossible to _not_ depend on the system path.

Let me rephrase. If a dependency can be bundled then it should be bundled.

The "Linux Way" is to depend on a bunch of random garbage pooped by lord knows bullshit script into one of several global search paths. This is bad, stupid, and wrong. Programs should include as many of their dependencies as is possible.

The number of dependencies that a program can not deploy and must assume are provided by the system are extremely minimal and special case. It's a short and static list.

In general no script or program should add libraries into the global search paths. On Windows user programs do not add random crap to System32. On Linux the existence of /usr/lib is an abomination that should not exist.

Is that better? I'm fairly certain you understand what I'm trying to say.

I know that the Linux way is not perfect, but I don't know how companies can't do better than the distro maintainers. Most repositories packages are driven by some kind of build scripts. I don't expect it would be that hard of a job to create one for your software for the most popular ones. Anyone using obscure distros are familiar enough with Linux to do container or chroot environments. I like the fact that my environment is a complete one, not siloes where the developer is more than happy to let the software lingers. At least macOS force developers to upgrade, Microsoft's backward compatibility's promise is keeping so much crust around in the system.

Reply on news.ycombinator.com