[ashrk]

Re: [0], what about them do you hate?

For my part, I've discovered since switching to Mac that I don't like having system packages managed alongside user packages.

It's one thing when I'm all-in on handling everything from the kernel up (it was fine back when I used Gentoo, for example) but the middle ground of massive meta-packages and such mingled with user-installed individual packages on e.g. Ubuntu is a train wreck. MacOS w/ homebrew's great. I can delete the entire directory with my brew installed crap in it and the system's unaffected. System upgrades are separate from my stuff. That plus the occasional drag+drop installed program cover my needs nicely, and better than everything's-a-bespoke-GUI-installer on Windows.

[AnIdiotOnTheNet]

Lots of things. They're basically the same walled garden you get from Apple, Google, or Microsoft, only with a different gardener. They're also ludicrously inflexible in that they don't allow multiple versions of the same application to be installed, install applications to different disks, or often even get timely updates when a developer makes a change.

I agree that "installers" are not a good paradigm either, but a lot of Windows software can be had in portable (or at least non-installer) form.

[inetknght]

> They're also ludicrously inflexible in that they don't allow multiple versions of the same application to be installed

They actually do allow multiple versions of the same application to be installed. It's just difficult to get it to work.

The package itself will install to (for example) /usr/bin. A new version of the package will have the same file names, so they get overwritten.

Most well-built packages will allow you to override the installation path though. This is perfect in case you want to install to your home directory (instead of globally) or some versioned directory.

For example you can relocate RPM installations given an example.rpm file:

    rpm -i --relocate=/=/home/myuser example.rpm

[AnIdiotOnTheNet]

Correct me if I'm wrong, but won't all of the dependencies also need to be installed to the same prefix? So I could end up with half the OS on there for one application?

[inetknght]

When you stray from the beaten PATH (and LD_LIBRARY_PATH) then yes you can start encountering trouble. Most good tools provide the options for you to do that. If you want to start building from scratch then `configure` and `make` often have PREFIX (and flavors such as BINPREFIX, LIBPREFIX, etc). `cmake` has similar variables to control where it looks for dependencies. Other languages' tools undoubtedly do too. I highly recommend you to read the documentation of the tools you use.

And when all else fails, there's docker.

[AnIdiotOnTheNet]

In other words, I can get what I want, which is very simple on Windows and Mac, in Linux by compiling things from source or otherwise jumping through a bunch of containerization hoops.

No thanks.

[Accacin]

But I can't do these things on Windows 10 either, I tried to put all my installed software on D: and when I had an update I was unable to install it because Windows couldn't work out where my stuff was which required a reinstall to install the update. Now I have to manually enter 'D' prefix on all installations, and that's for software that actually lets me!

The Linux package managers aren't perfect, but overall offer more flexibility for what I personally need.

[inetknght]

Unfortunately for now :)

One of the awesome things about Linux and it being open source is that if you don't like it then you can work to improve it.