Hacker News Reader

Comment by smoldesu | Hacker News Reader

Stuff like Flatpak and Snap exists because the framework side kinda is built-out. Isolation technology had matured, newer desktops emphasized per-window security and needed APIs to portal in and out of each instance. The desktops needed a packaging/infrastructure solution to tie that together and make it presentable to the user.

View on HN

Yet I still can't compile an app on some arbitrary release of some arbitrary distro and just run the darn exe on another and be 100% sure it will work.

On a large enough timescale I don't think you can reasonably expect this on any of this big 3 OSes. From a less macro perspective, I think tools like Appimage and Flatpak will fill that role.

On a long enough time scale we are all dead, and Linux doesn't exist. That doesn't mean that in the decades that computer software has to be useful to actual people that things have to suck this badly right now.

The "actual people" using Linux on the desktop are not running .so files off the internet. I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too.

Packaging is fairly simple on Mac and Windows if you use the dev tools for the platform and are not doing things like installing services or drivers or changing OS configuration.

Your packaged app will almost always work too. There are not 50 distributions of these OSes.

exactly

> The "actual people" using Linux on the desktop are not running .so files off the internet.

They do this all day every day when they use a little something called Steam or when they install Google Chrome.

> I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too.

It is...

> They do this all day every day when they use a little something called Steam

Which while (initially) officially only released for a specific Ubuntu version ran on pretty much any up to date distro from day zero.

The trouble is you're trying to distribute it as a binary yourself. The there are two traditional ways for distributing software for Linux:

1) The system package manager. It will download a binary from the repository which is the right one for that system.

2) make && make install. This is mostly for software in development that hasn't made it into the package manager yet. It will compile from source and produce a binary for the target system.

All the problems are from people trying to do something other than this.

That's the problem. The Linux way of distributing apps is wrong for trying to compete with the other consumer platforms. The ChromeOS or electron style of doing things is another story though.

What exactly is wrong with it?

If you have a stable widely used application suitable for being installed by unsophisticated consumers, have the distributions put it in their package managers. This is hardly any different than consumer mobile platforms that require you to use an app store, except that it isn't actually required, just the thing you ought to do absent a good reason to do otherwise.

If you're distributing something sufficiently esoteric or experimental that the package managers won't touch it, your correspondingly sophisticated or adventurous users can compile it from source.

We don't need some malware-facilitating norm that encourages users to install opaque binaries from random websites.

Alot of you may be looking at it wrong.

Each distribution is a different operating system. You cannot package the "same" app for Windows and mac, so why should you be able to package the same application for Debian and Arch, which, even though they run a lot of the same code, have different underlying layers and assumptions?

On other platforms people don't even try to support anything but one "distro".

You could make an AppImage or snap that would work across pretty much any mainstream non-hobbist-oriented distro, and Snap/AppImages is pretty much the Linux equivalent of EXE.

Raspberry Pi OS just moved to NetworkManager and they have PipeWire, which was the last reason I had to deal with less common software stacks, so it seems like stuff is getting more standardized.

+1 AppImages. And the beauty is you can make them portable by creating a folder with the same name as the AppImage and append .home to the end, and boom: portable software. For example

    image-editor.AppImage
    image-editor.AppImage.home (folder, all settings are stored there)

Actually, I don't think I've tried AppImage. Does it do static linking or does it do something more similar to flatpak?

It's a self-mounting image so closer to flatpak than static linking but without the strict isolation.

Snaps will not work on anything but Ubuntu.

AppImages are just a fancy self-mounting disk image. If you do it right and include all required contents then it will work ~anywhere but you can just as well do that in a .tar.{gz,xz,zstd}/whatever archive.

>Snaps will not work on anything but Ubuntu.

I installed VSCode as a snap on my Fedora install and it worked fine as far as I could tell. This was in Mar 2021, and I chose the snap because code.visualstudio.com/docs/setup/linux said that "Due to the manual signing process and the system we use to publish, the yum repo may lag behind and not get the latest version of VS Code immediately. . . . Updates are automatic and run in the background for the Snap package."

(I don't have an opinion on Snap as compared to Flatpak or AppImage or none of the 3.)

Reply on news.ycombinator.com