Hacker News new | ask | show | jobs
by p-e-w 1501 days ago
I'm always surprised to see discussions about desktop Linux software place such a heavy emphasis on the security aspect. In practice, malicious software (which is ubiquitous on other platforms in the form of adware and apps stealing personal information) is almost a non-issue on the Linux desktop platform. And I don't see it becoming a bigger issue in the future either. The desktop Linux market is too small and too fragmented, and its clientele are too tech-savvy and privacy-aware on average, to be of interest to Big Ads and co.

The elephant-in-the-room issue, and the one that any debate about the Linux desktop as a platform must necessarily focus on, is: How do I get my application to my users? For historical reasons, there hasn't been a good answer to this question for a long, long time, and anything that improves on the status quo (Flatpak, Snap, AppImage) is indeed (part of) "the future".

Of course, this being Linux, "the future" won't consist of "this one thing that everybody uses". If that's the goal, it was unattainable from the beginning. I love that Flatpak is repository-agnostic. I love that Snap applications update automatically. But most importantly, I love that I have a choice between the two.

4 comments

Pretty much anyone can avoid at least 90% of malware really easily these days.

You just don't install things from media sharing sites with full page ads, and if it doesn't have it's own subreddit and nobody blogs about it... never mind you're going to install cleanmyram.exe.deb anyway aren't you?

NPM supply chain attacks are slightly scary, but for now it seems to happen a lot less in popular apps than it does in the smaller stuff.

I think Linux probably will eventually pick a "Thing everyone uses", it will just have a significant minority that reject it, like with systemd or NetworkManager.

Another factors is that most of the software used by an average linux user is curated by the distro repository maintainers. Moreover, free software is almost always privacy-respecting, so you don't really need much in the way of security to use them, unlike on other systems. I think these new packaging solutions are only really meant to push proprietary software onto linux.
> How do I get my application to my users? For historical reasons, there hasn't been a good answer to this question for a long, long time

What is wrong with a binary in a tarball, like Firefox and Blender and VSCode and everyone else uses? This always seemed like a non-problem to me.

Linker errors
You just bundle all libraries except glibc in the tarball. You build against the oldest glibc you're willing to call "supported". Firefox and Blender (among many others) have been doing this for as long as I can remember, and as long as I can remember their tarballs have never failed to work for me, on any distro.

The problem seems to me to be that there's some kind of cultural imperative to attempt to dynamically link against whatever the system version of a library is, which is clearly insanity.

Static linking.
You can't statically link glibc and you shouldn't statically link openssl or libcrypto, and Linux distributions make it extremely difficult to do reliably without compiling everything from source.
You don't have to statically link everything. You should choose based on (a) if the lib has to be dynamic (eg. portability layers, crypto) (b) if the lib is widespread and has stable ABI.
and now your tarball will break on an indeterminate number of linux user machines without (often extensive) manual intervention to fix .so versioning issues. That's why things like flatpak exist.
> How do I get my application to my users?

I was concerned about that but I just thought of it. For example I want to install VSC on a new device, I go to their website and download binary or .deb file.

It is nice to be trusted/be sudo apt installable say... But also requires being vetted I believe.

I'm case of KDE they have their software "marketplace" which to my surprise had a lot of options. (Context was Pinephone)