> 1. I hate package managers as an application installation paradigm

wat

so you prefer go to vlc.com for vlc, 7-zip.com for 7-zip, update them by hand or add custom system services constantly running for every program to install themselves, etc etc instead of a `pacman -S 7z vlc krita libreoffice [every other software you need]`

Yes. I like having software that is up to date and delivered direct from the developer. I like having portable applications that don't even need installation. I like being able to put applications on different disks. I like being able to have multiple versions of an application.

There is not a single package manager in existence for Linux that gives me these things.

> I like having software that is up to date and delivered direct from the developer.

I really think your argument against package managers on Linux is incorrect. Many linux distributions provide "some recent version" of common tools, but of course you can get the latest package directly from the developers.

Nothing stops you from getting the latest packages directly from the developer (assuming the developer provides packages in the first place). Some developers even offer their own repository you could add to the package manager so you can stay up to date regardless of whatever version you don't like in the OS repository.

> I like having portable applications that don't even need installation.

You can build from source and run without installing. That's probably not quite what you mean though.

> I like being able to put applications on different disks.

No problem here. You can mount disks to wherever you want and you can install using a prefix path to those locations.

> I like being able to have multiple versions of an application.

Prefix path to the rescue here too.

Edit: answered more of your concerns

> but of course you can get the latest package directly from the developers.

If you're willing to compile it from source, which I'm not since it isn't the 70s anymore.

>...

The rest of these are all the same thing: you can do these things as long as you compile from source. As I've already mentioned, I consider that a backwards and tedious way to deal with application installation. I mean ffs, getting build environments right is such a pain that many devs ship a docker container of a working environment. Not to mention it is only viable with OSS software.

Compiling most things is decidedly nontrivial. Half an hour of wasted time is not appropriate just to install something in a different directory.

A package manager really should be able to do prefixed installs on any package, but that's far from a universal feature right now.

> Compiling most things is decidedly nontrivial.

I've spent the past five years building a lot of things from source. I agree that there are definitely a lot of things that it's nontrivial for. However, I've found that the hardest part is satisfying dependencies. Once dependencies are satisfied, building is usually really easy. And the software that isn't easy to build after satisfying dependencies is usually not worth building in the first place.

Of course, that's just my experience as a C++ developer.

Gentoo can do prefixed installs, I'm reasonably certain alpine can as well. If you're on debian you can always just make a chroot with debootstrap.

AppFS is a package manager for Linux that exists and solves all these problems, except the "putting them on different disks", which it doesn't prevent you from doing but it doesn't really make any sense either.

http://appfs.rkeene.org/

If its one thing I have learned about software development, its that you must account for people doing completely non sensical things.

I knew a guy who had MS word 97, 2000, 03, and 07 all installed on the same machine, and he used all of them for various tasks. Insane? Most certainly, but welcome to humanity.

AppFS has no problem with that. The problem comes from keeping different packages on different disks -- since it caches them all into the same directory by default. It would be trivial to make it cache files from certain packages into different places as part of the configuration -- that's easy enough. The issues come into place for files that are shared (having the same SHA1) between packages, then you either have to duplicate the file or have some policy of searching for it.

A better approach, if you care about this, is simply to have a lifecycle policy where more recently used blocks live on the SSD and less recently used blocks move to slower storage (bcache can do this for you), or are deleted (this is a planned feature: http://appfs.rkeene.org/web/tktview?name=930821d0fb ).

>but it doesn't really make any sense either.

I don't need every program on my SSD. Makes perfect sense.

Aside from the obvious missing feature, there isn't even enough information to very your claims. Can I really have two versions of, say Krita, installed? Can I make a copy of that to take to an offline PC?

Yes. Since there's no explicit install step you can run as many versions as you want. You can of course copy the files to the cache of any system.

Sounds like AppImages would satisfy all your requirements.

Yeah, they do actually. I really like AppImage, it's a shame they aren't really embraced at all by the community. Good luck getting them to show up with icons in your file manager (even Nitrux, which supposedly embraces AppImages, can't seem to do it).

Occasionally, I still run into a piece of software which makes me yearn for the days when I built my own /usr/local from source. But as the repos have got better, this is getting to be a rare event. I still don't like the feeling of being boxed into the package management system. And the extra level of complication trying to manage issues from building software from source which reference package managed libraries and other dependencies.

There's no reason that they need to come from the developers. I'm maintaining over a dozen packages that build directly from HEAD that are all integrated with my package manager and allows anyone else to leverage my work and get my packages.

Nix is the package manager that does this. It literally does damn near everything that comes out of every HN discussion of package managers, ever, but very few seem to bother investigating it.

There's several reasons for that, like it still means building from source, or that nix is basically its own programming language you have to learn.

Also, if I understand how nix works correctly, it still can't create portable applications.

And then how do you find the software? Google? That’s fine until the top link is a third party that adds adware to the installer.

I like how homebrew cask does it, where each cask is a formula to download the app into /Applications . You get the reproducibility of package lists, the speed of just typing an install / search command vs searching a website and the connivence of normal app installation and management.

Snapcraft?

Not portable, can't install applications to different disks.

In open source world, this is fine. In the closed source world, this is one step closer towards walled garden. Just the other day, I could not install something because my Windows 10 was set to "install only from store" and I had go in and turn that off. How long before that's no longer even an option?

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.

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.

> 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

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?

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.

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.

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.

Unfortunately Microsoft has embraced hardcoding paths for their own software. However, I've found that the vast majority of Windows applications already are or can easily be made portable. Updating them is a bit more manual, but that's a tradeoff I'll make every time. After all, you never know when an update to your mail client will suddenly introduce ads.

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.

Theoretically, yes, realistically, not really. For all its talk of openness and freedom for the user, the Linux community has a remarkable amount of disdain for anyone who isn't a C greybeard.

AppImage has already pretty much solved everything I want as far as application distribution. It is at least the third such implementation that has.

However, the community refuses to embrace it and so very little software is distributed that way, just like the last two times.

> the Linux community has a remarkable amount of disdain for anyone who isn't a C greybeard

I feel like you're the one providing disdain simply by saying "greybeard". Please don't disrespect people who have lots of C experience.

I've found plenty of non-C applications in Ubuntu's and Fedora's repositories though. I've found Python, Ruby, and Perl applications and developer tools (in addition to the obvious C and C++ ones). That's just off the top of my head. Erlang, Ocaml, R, and (maybe?) D also exist. Of course there's also the package-building tools.

Mailing lists and bug reports are usually open to the public too. And there's usually policies around offensive behavior. If you see a problem that hasn't been addressed satisfactorily then I highly encourage you to bring it forward to the maintainers.

> AppImage has already pretty much solved everything I want as far as application distribution. It is at least the third such implementation that has.

Search engine brought me here: https://appimage.org/

It looks like it supports every major Linux distribution I've come across. Then what's stopping you from using it?

> the community refuses to embrace it and so very little software is distributed that way, just like the last two times.

This sounds like you need to get application developers on board. Get software developers to provide an AppImage of their application.

Make sure to include source code for distributions to build their own version of the AppImage -- including any patches which might be necessary to tweak and support the distributions' different and unique environments.

> I've found plenty of non-C applications in Ubuntu's and Fedora's repositories though. [etc.]

You've missed the point. I could go on for quite a while about what the point was, but ultimately it comes down to this: "You can fix it yourself!" isn't really true. Professional programmers who work on Linux for a living haven't even managed to fix a lot of its problems.

> It looks like it supports every major Linux distribution I've come across. Then what's stopping you from using it?

Nothing, except that hardly any applications are available as AppImages and they're a 3rd class citizen at best on all major distributions.

> Make sure to include source code for distributions to build their own version of the AppImage -- including any patches which might be necessary to tweak and support the distributions' different and unique environments.

The whole point of AppImage is that that's completely unnecessary. The only thing that really aught to be done is that file managers should display AppImage icons and not harass the user about double clicking one to run it. My point isn't that such things are holding me back, it's that such things are indicative of the community's attitude towards AppImage.

> You've missed the point.

Maybe.

> ultimately it comes down to this: "You can fix it yourself!" isn't really true. Professional programmers who work on Linux for a living haven't even managed to fix a lot of its problems.

I could say the same thing about every OS.

> The whole point of AppImage is that that's completely unnecessary.

Unnecessary to you perhaps. Being able to see the source code of applications I run is important to many Linux users.

> The only thing that really aught to be done is that file managers should display AppImage icons and not harass the user about double clicking one to run it.

I don't see why AppImage should be treated any differently than any other executable -- trusted or not. If that's not how it is now then you definitely have a point.

Have you built any AppImage-based programs?

Consider FreeBSD and its ports model. You'll be building your own ports from sources but you needn't touch another package someone else built, if you don't want to.

At some point aren't you going to have to choose between software requiring shared libraries and take the package-complexity or source build-hit, or have everything statically linked and take the program size hit?

My preference would be to have everything statically linked. The extra storage cost is worth the complexity trade off.

But afaik, this usually isn't an option in the Linux world. Unless, again, I'm compiling stuff myself.

Only if I insist on doing things the way UNIXs do, which is what is keeping me on Windows.

If Linux had a stable and consistent base system that was comprised of the most commonly used libraries, then developers would only have to statically link or include their own copy of less common libraries. I'm totally ok with that.

And let's be real for a minute, the program size hit is negligible. You can get a 1TB SSD for under $200. The largest part of almost any program that's in any way large are its assets, not its code.

You're wrong, tiresome and ignorant.

Windows allows multiple instances of the same app to work via the WinSxS mechanism which keeps copies of basically every DLL ever installed, including system DLLs. So it is basically keeping duplicates of everything, regardless. This includes some executables as well. [1]

Before WinSxS you could achieve the same effect by keeping copies of the DLL dependencies in the app directory beside the executable. Windows would then choose the DLLs from the app current directory before looking at system directories and the path. [2]

Linux gives you the same choices and a couple more options.

   Work with the system package manager [1].

   Link dynamically and keep copies of differing DLLs in a different prefix and... take a size hit. [2]

   Link statically and take a size hit.

   Link dynamically and build everything yourself, minimizing your dependencies.

You can't do the last two with Windows, for the most part because you do not have source code.

So, which of those options do you choose?

You cannot have your cake and eat it too.

> Linux gives you the same choices and a couple more options.

Only as the builder of an application. The application developers for Linux, on the whole, only ever chose option one, leaving everyone who uses their software no option that doesn't involve recompiling from source (which, as I've mentioned, is a ridiculous thing to expect people to do just to use your software).

I have several dozen applications on Windows that are not installed. Many of them aren't even designed to be portable, yet were easily made such just by extracting their files from the installer into a directory. I can put these applications on a thumb drive and take them to an entirely different Windows system and run them without installing them their either. These directories are exactly as they'd exist in C:\Program Files.

This is of course because they have copies of their dependent DLLs in their install directory, but only the ones that aren't part of the Windows distribution. Let's look at one: WinDirStat. It is 2.1MB total, 856KB for the executables, 844KB for dlls, and the rest is assets, docs, and configuration. This is a GUI application, but you'll notice it doesn't have to include a toolkit because it uses the one that comes with every Windows install. The DLLs, as far as I can tell, are unique to WinDirStat, so it wouldn't be unfair to say that this application actually doesn't have any dependencies other than the base OS.

That's what Linux can't get you. There is no base OS above syscalls. You can't depend on anything being there because there are hundreds of distributions and what's available to link with changes with configuration, distribution, and often version.

If I could, I'd have all my Linux applications as AppImages which follows pretty much the same model as portable applications do on Windows. As I said though, Linux developers rarely offer that as an option.

>> Only as the builder of an application. The application developers for Linux, on the whole, only ever chose option one,

Again, wrong.

The people that package distributions usually make these choices. Gentoo and distros like it give you a choice of how things are built.

Off the top of my head I cannot think of a popular library that does not have the option to be statically or dynamically linked.

>> I have several dozen applications on Windows that are not installed. Many of them aren't even designed to be portable, ....

>> ... The DLLs, as far as I can tell, are unique to WinDirStat, so it wouldn't be unfair to say that this application actually doesn't have any dependencies other than the base OS.

This works in Linux too, somewhat. You have to have compatible ABIs though.

>> ... dependent DLLs in their install directory........

And Windows has 8 tons of different versions of system DLLs and C library runtimes in the WinSxS directories. MSVC runtimes are not interchangeable. Linux in general does not go to that length since a large majority of the apps are source available.

> GPU drivers still perform worse for my card

Which GPU?

nVidia GTX 1080ti

In addition to the performance degradation, nVidia and the kernel maintainers don't currently get along so I'd also have to deal with that.

Ah, yes. nvidia is a thorn. In other news, the AMD and Intel drivers are as good as, if not better, than their windows counterparts!

Legitimately asking; does AMD still do that thing where they unceremoniously drop support for an older card on newer kernels - so you do a apt-get upgrade at some point and reboot to a black screen, and your options are either never upgrade your kernel or get a new GPU?

This, unfortunately is not as true as I wish it was. I bought an RX 560 and tried to install Ubuntu 18.04. It could not propery drive my 4k display that uses DP 1.2 MST. That display has been working fine with a few different cards on Mac and Windows since 2014 when I bought it.

I even tried the AMD pro drivers. Granted, the open source nvidia drivers couldn’t do it with a 1030 on 18.04 either, but the proprietary ones had no issue.

edit: I should note, the RX 560 runs fanless up to 60c on Windows, but the fans always spin on Linux.

It seems that support existed in KDE/Plasma workspaces in late 2014.

https://www.phoronix.com/scan.php?page=news_item&px=MTg2NTY

Though if you follow the DP MST keyword there's still some corner cases being polished...

https://www.phoronix.com/scan.php?page=search&q=DP%20MST

https://www.phoronix.com/scan.php?page=news_item&px=DRM-Misc...

The Mesa drivers Ubuntu (and Debian, and many other distros) provide CAN be rather old. As you mentioned Ubuntu, follow the directions here to have a stack that's as updated as possible.

https://github.com/ValveSoftware/Proton/wiki/Requirements

I also tend to like checking Arhc Linux support page, but it doesn't seem to be helpful for this issue: https://wiki.archlinux.org/index.php/Radeon

I have no problems running my RX 580 with the amdgpu driver and recent versions of Mesa.. If I had to guess, Ubuntu 18.04 has some archaic versions of both the kernel and userspace drivers.

Do you have a 4K display that requires DP 1.2 MST?

I tried the latest proprietary amdgpu-pro drivers also.

I even bought the RX 560 because some other Linux users assured me the AMD Linux drivers were excellent. My post here is to help other people so they can make a more informed choice in the future.

Shame their hardware isn't as good. Especially Intel's.

> I hate package managers as an application installation paradigm

Flatpak has you covered, or at least, it's getting there pretty fast. You'll still need to manage debs for base system stuff but you can install most gui apps as flatpaks now.

If only it did. For one, its absolutely a package manager. You need a special tool to manage flatpaks.

Also, flatpak has a lot of problems in my opinion, not the least of which is that it has no mechanism for installing to a different disk without creating an entirely new "installation", which in its terminology means a completely new dependency chain too.

The "portals" idea is a pretty good one though, on the whole.

It's still a package manager, and it still has dependencies, but the dependency chain is "flat" such that it's always comprehensible and you'll never be stuck modifying large parts of your system to update one program. I see it as similar to Windows's Visual C++ and DirectX runtimes in that regard.

I hear you on installing to different disks, though. Appimages are also an option, but I've found they have a tendency to not actually work between different distros and system versions.

Unfortunately that's a problem with they way Linux is structured, or rather it's lack of structure. There's no consistent base system that can be relied upon like you have with other platforms. The community seems unwilling to deal with this issue, some outright deny that it is an issue.

One thing that would be interesting would be to use flatpak "runtimes" to provide a target base system for AppImages, but I don't think that level of cooperation is actually possible within the Linux community.

cough LSB cough

I don't really think it's an issue though, if you really want portability you shouldn't rely on any software provided by the distribution unless you want to depend on that specific distro.

Flatpak runtimes are basically interchangeable base systems, it seems silly to commit to any one in particular when you can use any number in parallel.

> As a vocal critic of the Linux Desktop

well, go on then, elaborate...

Not the OP but my most recent attempt to ditch Windows on my gaming desktop ~6 months ago was tripped up when I discovered that core software like file managers and such still crash or wig out constantly (it's always been that way, I simply used to put up with stuff like that, just hoped that had changed since I'd been away) and generally basic interactions (e.g. drag & drop) are still inconsistent and buggy. This on Ubuntu which is allegedly relatively polished. Tried KDE and Gnome both (Gnome's performance was also terrible, incidentally).

And all of it looked pretty bad. I'm a fan of (though not insistent upon using) "ugly" old school interfaces, so it's not that it wasn't "flat" or "beautiful" enough or whatever the current trend is, just lacking consistency and the result of a whole bunch of small, poorly-chosen defaults adding up to a big stew of gross. I could overlook that if it weren't also crash-prone and janky as hell, but it is.

So I'm still stuck on Mac for anything serious, and my gaming desktop sits in storage because I can't be bothered these days to screw with either Windows post-10 or Linux. Sigh.

FWIW my favorite desktop I've ever used, as far as core software, stability, desktop UI/X, compared to its contemporaries, was BeOS.

If you want to love windows again, find the Eurpean LTSB version, it is incredible. No app store, no cortana, none of that shit.

As for linux, I went through a bunch until I found my love for fedora. It still requires some tinkering, but for the most part everything works.

Cannot agree at all.

I switched to Arch Linux when RedHat was swallowed by IBM. KDE Plasma 5 is my thing. Windows 10 is a VM guest in Arch host. 32GB workstation, multiple monitors - 2 24 inch Dell monitors, 1 Haeir 55 inch, SSDs and Western Digital Caviar Blacks and Transcend External HDDs... no issues to report.

Same experience with Fedora for more than 2 years. FreeBSD with Xfce 4 and TWM on my laptop. No crashes, no issues.

Huh. I hit a ton just trying to manage some files and burn a cd or two. Workflow inconveniences, crashes in various applications, little "some KDE service you've never heard of has crashed" messages from the system tray. Firefox scrolling was jerky until I googled a bit and found the right setting to change which is apparently the stop-being-broken switch, which is a thing that exists for some reason. Stuff like that, and on what's supposedly one of the most just-works distros. Weird. Fits with my experience running Linux as my main desktop (and laptop) OS from ~2002-2008, though once I switched to Gentoo everything was less buggy at the cost of having to configure everything manually.

Too off topic for this thread, also past experience has shown that all that will happen is a bunch of evangelists will come out of the woodwork to tell me variations of: you're using the wrong distro, you're using the wrong hardware, or your workflow is wrong and you should change how you do things.

Why don't you like package managers?