Hacker News Reader

Comment by arepublicadoceu | Hacker News Reader

> but if you say something like you don't want to use Linux because you think package management is a stupid way to manage applications then people just want you to shut up.

In my experience people respond better when you actually explain and provides arguments to why you think “package management is a stupid way to manage applications” and not simply say this blanket statement.

For instance, I believe that *not* having a package system is a stupid way to manage applications because:

- you have to trust many more parties than a single repository;

- you incentivize people to do unsafe things like running downloaded exes from sites;

- now you need to also trust that no one tampered with the websites and have to manually checksum and verify authenticity of each application whereas a good package manager should do this for you;

- Removing applications without package managers is a worse experience.

Now I would love to hear your arguments and, maybe, change my mind.

View on HN

> In my experience people respond better when you actually explain and provides arguments to why you think “package management is a stupid way to manage applications” and not simply say this blanket statement.

I have done this many times on HN, and it almost universally results in downvoting.

> Now I would love to hear your arguments and, maybe, change my mind.

Fine, whatever. I don't need the fake internet points. Let me start by saying my complaints here are specifically in regards to the way Linux packages, repos, and managers work to avoid someone from Haiku showing up to tell me I'm wrong:

- Repos are no better than walled gardens except that they are typically maintained by unpaid third parties

- Said unpaid third parties sometimes introduce bugs or arbitrary changes to the software

- You can't install applications to different disks or have multiple versions of the same application

- Copying applications from one computer to another is massively complicated because most package managers never consider this use case at all

- Package managers encourage the kind of interdependency hell and reliance on fixed paths that makes them necessary in the first place

- The proliferation of package formats and package managers has made packaging binaries for Linux an incredible pain in the ass

To address your points specifically:

> - you have to trust many more parties than a single repository;

This is true even in the repo world. You have to trust the developer of the application and the maintainer of the package for that repo at the very least. There is no reason someone cannot curate a repository of software that is not managed by and tied to a package manager and, in fact, there are many of these to choose from.

> - you incentivize people to do unsafe things like running downloaded exes from sites;

Yes, but I think that speaks to a failure of non-mobile OSs to implement proper application sandboxing once the internet became the dominant distribution medium for applications. I also think this threat is given far too much weight in comparison to being constrained in your choice of software.

> - now you need to also trust that no one tampered with the websites and have to manually checksum and verify authenticity of each application whereas a good package manager should do this for you;

Yes. Again, I don't think this is a big deal, especially when compared to restricting my choice in software. The thing I think makes personal computers valuable is that people can install pretty much whatever they want, make their own stuff, and easily pass it around. Package management and repos overcomplicates this.

> - Removing applications without package managers is a worse experience.

Only under "installer/uninstaller" paradigms. "Portable Applications" in Windows, or Application Bundles on Mac or NeXT, or the original Macintosh's single-file applications, or RiscOS AppDirs, or even DOS's buncha-files-ina-folder paradigm make removing an application as simple as deleting a single object. Not to mention they make copying or moving applications, or running them on different media, as trivial as any file operation.

I probably won't change your mind as a lot of this is subjective, equally your arguments do not sway me. Suffice it to say, the Linux community agrees with you, and that is part of the reason I don't want to use Linux.

You can use the "buncha-files-ina-folder paradigm" on Linux and Unix as well, but generally, applications are written with the assumption that they will be installed at a particular location, and can unexpectedly fail if you put them elsewhere.

The RPM Package Manager itself is an example of this. It can be configured to be installed to a custom location via the build system, but it has hard-coded paths in some scripts so the package manager would break when it hits this code months after appearing to work correctly.

Right, theoretically Linux applications can work this way, there's even AppImage to really prove the point. The problem is that basically nothing in the Linux world does do that because it just isn't the way things are done.

At the end of the day, it's the same difference to me.

Do you know about Snap and Flatpack? I think the latter may solve some of your problems.

1. https://snapcraft.io/

2. https://www.flatpak.org/

https://news.ycombinator.com/item?id=28409524

good news for you is that linux is moving a bit more and more towards the portable application paradigm, with things like snap packages and AppImage. E.g. for texstudio I found that the version in my repos was outdated, so I just downloaded an AppImage file off their website and am using that now. Same for ultimaker cura. And you can use multiple versions in parallel.

Snap and Flatpak are very much not portable (in the Portable Application sense). Snap relies on a repo and Flatpak heavily encourages one, although it does have a single-file bundle concept. Sadly both of them suffer from many of the other restrictions I mentioned.

AppImage is pretty great, I wish more projects used it.

The problem with those approaches is that they bundle all the dependencies with the application, rather than using the system libraries. That means that if a security bug comes out, I need to (e.g. heartbleed), I need to track down every single application, check their version, cross my fingers that they at least used a shared library and didn't build against the static library, and update each one individually. For well-behaved software that uses the system libraries, I only need to update the system library and be done with it.

I get that snaps are easier for developers because managing versions can be painful. Pushing that pain onto the users isn't the solution.

Windows apps also bundle all dependencies, go check out any dotnet app(all crypto stuff is in some dotnet library..). Windows docs also encourage you to do this.

The difference is there is a set of base windows libraries that you can expect, so if you just use those with your win32 program then it's good. But most dotnet apps don't do this. It's just like using Appimage.

I'm a Windows user with as-portable-as-possible software catalog, and I approve of this message.

Jokes aside, I am mostly in a complete agreement with you on it. I'd only add that both approaches should exist, and that the package-people should (learn to?) provide a more portable variant of their software. I don't have much experience with Linux (which some of my comments just might show), but all that "black box magic" that happens behinds the scenes never sat right with me... especially since I have a supernatural ability to hit some edge cases where install fails halfway, and now you can't deinstall nor reinstall, and you're stuck in limbo. (Or finishes, but just won't run on account of something not working in the background, and, well, good luck finding out what exactly and how.)

Sure, portable-style applications on Windows are not immune from not working here and there, but across two decades now - it's mostly been set it and forget it. Different versions of software can usually co-exist, or even the same one (e.g. I specialize one for specific purposes), some even co-run.

I do miss some features of the Linux (file system versatility, mostly), but I've grown to live with it. And while Microsoft is increasingly making Windows unbearable, as long as I can bypass/block their idiotic decisions (Start menu, telemetry, updates) and make them work when I want, and how I want... I guess I'll stick to it.

[[Now, when the hell does Microsoft plan on fixing up the Exporer shell and its antiquated 25X-char path issues? (LONGPATH is enabled, but Explorer still shits itself on such a path. But I try to use DOpus, anyway...).

Also, custom(izable) open/save dialog replacements, I'd kill for those.]]

> I'd only add that both approaches should exist, and that the package-people should (learn to?) provide a more portable variant of their software.

The great thing about portable applications is that you can still put them in a repo and use software to manage them, you just don't actually have to!

NixOS -- what I use -- gets mentioned here pretty frequently, so I don't just want to do an ad. But: walled garden? there's no wall. Multiple versions? Trivially. Copying applications between machines? `nix-copy-closure` is a joy to use, no exaggeration. And interdependency hell? Nix takes some pretty heroic measures to make builds reproducible, which work surprisingly well.

The proliferation of formats is pretty irrefutable; you're meant to put your source code out there and let the distro maintainers worry about it. That's no help of course if you want to ship closed-source binaries, but Linux emphasizing open source goes a little deeper than package managers.

Anyhow, maybe these are counterarguments and maybe it's just "some people who agree with you wrote a package manager." The main thing is the downsides can be fixed, and have been.

Maybe. I've only looked at Nix from a distance because I'm reluctant to learn a new language just to effectively manage applications, and I don't really want to have to create my own packages for things or build them from source. Also I'm pretty sure it still can't install applications to arbitrary disks and, as mentioned, it is worthless for closed source software.

If you ask me, it's an incredibly overengineered solution to a problem that is entirely self-inflicted. Still, it might eventually be preferable to Microsoft's current direction with Windows.

> Repos are no better than walled gardens except that they are typically maintained by unpaid third parties

It's a garden alright but there is no wall. I've made packages out of my own programs and installed them on my system. Arch Linux literally has a repository of user packages.

> Said unpaid third parties sometimes introduce bugs or arbitrary changes to the software

Yeah. Debian is famous for their patching. Not all distributuons do this though. Arch Linux offers unpatched software.

> You can't install applications to different disks or have multiple versions of the same application

I don't get the multiple disks thing. Personally I want to virtualize disks away into a single magical root file system. Do you mean like portable Windows applications? That's possible, but would require a lot more static linking than distributions are comfortable with.

Windows makes this easy because the application's directory is magically added to the library search path. Applications can just dump all their DLLs into the same folder as the EXE and it will work. They essentially statically link their dynamic libraries. Users end up with tons of duplicated DLLs, distributions don't like that.

Multiple versions of applications and libraries is technically possible, some distributions have attempted this. Most reject this idea because it would increase maintainer workload.

> Copying applications from one computer to another is massively complicated because most package managers never consider this use case at all

This use case is strange to me as well. When I set up a new computer with Linux, I download the applications from the repository.

> Package managers encourage the kind of interdependency hell and reliance on fixed paths that makes them necessary in the first place

Yes. Linux users and distribution maintainers usually look at the operating system like a complete system, not just a support layer for applications. When maintainers package software, they integrate the software's parts into the overall system, every file in its proper place, every link is maintained. I believe this is cultural.

> The proliferation of package formats and package managers has made packaging binaries for Linux an incredible pain in the ass

It's better to just release your software. The community will package and integrate it for you if there's enough demand.

Alternatively, I've found that Arch Linux packages are really easy to create. Just one simple shell script and there's plenty of documentation and examples online. I just ignore all the other distributions.

> It's a garden alright but there is no wall. I've made packages out of my own programs and installed them on my system. Arch Linux literally has a repository of user packages.

What I'm saying is, you have to go out of your way and put in a bunch of work to install something if it isn't in the repo. This is not the case on Windows or MacOS (or DOS, or RiscOS, or the original Mac, or NeXT, or basically any desktop operating system that has ever existed except for Linux).

> I don't get the multiple disks thing. Personally I want to virtualize disks away into a single magical root file system.

It's a bad abstraction that hides the true origin of files and causes significant problems if one of those disks ever disappears. In sane desktop operating systems I can run applications off of a USB drive and remove it when I'm done. This is possible in Linux, of course, it's just that absolutely nothing is designed to handle it so you have to put in a ton of work to make it happen.

> but would require a lot more static linking than distributions are comfortable with.

You don't even need static linking, you can use LD_LIBRARY_PATH and a custom startup script in a lot of cases, it's just a lot more work than it should be and fails in weird ways because no one expects this kind of thing. Trust me, I've been doing this for years and years now.

> Windows makes this easy because the application's directory is magically added to the library search path. Applications can just dump all their DLLs into the same folder as the EXE and it will work. They essentially statically link their dynamic libraries. Users end up with tons of duplicated DLLs, distributions don't like that.

Which is silly in my opinion, and also an artifact of Linux Desktop never having the concept of separation between platform and application. This makes Linux great for appliances and shitty for a personal computer. When you have a reliable base system of commonly used libraries a lot of the problems go away, you get security updates for libc and openssl and whatnot, and chances are whatever other DLLs you're using you are the only application on the system using them anyway[0].

> Multiple versions of applications and libraries is technically possible, some distributions have attempted this. Most reject this idea because it would increase maintainer workload.

Yeah, poorly thought out ways of doing things have consequences like that. In sane desktop OSs you don't need an army of unpaid third party maintainers. I've used some of those distributions you're talking about (Gobolinux, for instance) and they never caught on because the community hates the concept.

> This use case is strange to me as well. When I set up a new computer with Linux, I download the applications from the repository.

What about computers not connected to a network? One that I have to drive several miles away from a non-metered network to get to? This is my point, many such use cases are never considered.

> Yes. Linux users and distribution maintainers usually look at the operating system like a complete system, not just a support layer for applications. When maintainers package software, they integrate the software's parts into the overall system, every file in its proper place, every link is maintained. I believe this is cultural.

I agree, and it's why I think Linux will never make a good desktop because all that neat and orderly curation means things will break the second the unpaid third party package maintainer leaves, or a core library makes a non-backwards-compatible ABI change, or someone dared to try and install a library that "conflicts" (usually by being more up to date) with one you already have installed. This is why you only have a choice between crusty-but-stable distros and rolling release distros that break frequently. I can run almost every program available for Windows today on Windows 7, which is nearly 12 years old. I can run applications compiled for Windows 95 on Windows 11 without writing a single line of C or changing a build script.

> It's better to just release your software. The community will package and integrate it for you if there's enough demand.

If it is open source, and if there's a enough demand. I think that's bullshit. I should have the freedom to put any license I want on my software and the user should still be able to have a low-effort install experience. I shouldn't have to kowtow to some unpaid third party package repo for distribution, I should be able to mail my application to you on an SD card. That, to me, is the freedom of personal computing.

> Alternatively, I've found that Arch Linux packages are really easy to create. Just one simple shell script and there's plenty of documentation and examples online. I just ignore all the other distributions.

I don't think I should have to setup finicky build environments and compile software from source to make my own package just to use some goddamned software. I honestly don't know why Linux desktop people think this is a reasonable expectation.

Needless to say, I have a very strong opinion on this point, and you haven't made any arguments I haven't seen before in my 20 years of using Linux. You are not going to change my mind, just as I am not going to change yours, because we have different priorities and culture regarding the tradeoffs of the different methods.

Knowing this, you felt for some reason it was necessary to argue with me, why? The only reason I can think of is that you want to argue for the sake of some imaginary "undecided" reader, as a form of advertisement for Linux. Unfortunately this happens literally every time I mention not liking Linux, hence my initial reluctance to even mention why I don't like Linux. Because another reason I hate the Linux desktop is that its community is full of people who feel the need to engage in performative argumentation.

[0] https://drewdevault.com/dynlib

> Knowing this, you felt for some reason it was necessary to argue with me, why?

I didn't see it as an argument, more like a conversation. I wanted to understand your opinions better. Your post mentioned several points I had never thought about before and it was interesting. Certainly made me rethink a few things such as offline software sources. I even agree with you that many of these differences are cultural and those are slow to change.

> The only reason I can think of is that you want to argue for the sake of some imaginary "undecided" reader, as a form of advertisement for Linux.

I don't do that. I'd rather Linux remained an obscure programmer's operating system, actually. I don't really care about the Linux desktop.

> You don't even need static linking, you can use LD_LIBRARY_PATH and a custom startup script in a lot of cases, it's just a lot more work than it should be and fails in weird ways because no one expects this kind of thing. Trust me, I've been doing this for years and years now.

You don't even need a startup script to adjust the library search path, ELF binaries have the DT_RUNPATH field for that where '$ORIGIN' refers to the directory containing the executable. Using the -Wl,-rpath,$ORIGIN flag when linking gives you more or less the Windows behavior, just make sure to escape the $ORIGIN appropriately so it is passed as is and not expanded by the shell/make/your build system. And if you want, you can even put libraries in a subdirectory.

Yeah but that only works if you're compiling it yourself. LD_LIBRARY_PATH lets you get binaries working this way, at least sometimes.

Reply on news.ycombinator.com