Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux apps that run anywhere

appimage.org

Post reply on HN
Print view View original

61–70 of 117 posts

Re: Linux apps that run anywhere

#61

Post by pushpop »

im_down_w_otp wrote: post #4

One of the issues I've had with things distributed as Snaps or Flatpaks is that they tend not to pickup the settings and preferences that I've configured on my workstation. For example, if I've setup themes, fonts, scaling factors, custom keyboard shortcuts, etc., they tend not to be available/utilized by the applications which are distributed in these bundling formats. For the most part, that's why I avoid using the…

Honestly, I would much prefer using a package manager than manually installing packages. Using a package manager means you only have one place to look for the package (searching in a browser for software can be so error prone for inexperienced users. Not to mention more disruptive and time consuming). Using a package manager means you only have one place for upgrade installers (3rd party updaters are a plague on Windows) and having everything updated through a centralised package manager means you’re less likely to overlook upgrading a package, which is better for your overall system security.

My biggest gripe with OSX is that the default way of installing software is via manual downloading. Sure OSX has the AppStore, but that’s mostly garbage. Homebrew is a hell of a lot better but it’s frustrating that I have to install a 3rd party package manager on a modern OS.

I get your rant about shared libraries but you can get around those problems surprisingly easily (eg you can ship your SOs in the package directory like you might with DLLs in Windows. Or you could just statistically compile your binaries and do away without the SO problem entirely). Problems with SOs are something you’d expect a junior Linux sysadmin to learn so any developer or maintainer worth their salt should have already figured this out.

Re: Linux apps that run anywhere

#62

Post by oblio »

earenndil wrote: post #59
oblio wrote: post #58

Earlier quoted context omitted.

With your logic, you've already lost. If you don't trust the developer of an application you already run, you're screwed in any scenario. Yours is not a realistic threat model.

I think the parent means that, for opensource software, they trust their distro maintainers to read the source code and only publish trustworthy software.

I know, but with his model a random third party decides what's best for that software.

That third party has screwed the security of the package on occasion (Debian being a famous example: https://www.schneier.com/blog/archives/2008/05/random_number...), has delayed package updates for years if not decades (I don't even need to provide an example, just do a diff of stable upstream versions and your favorite distro's package versions), has even broken packages on occasion, etc. And let's not the frequent cases where there's a personality clash between the upstream developer and a package maintainer...

And this model also assumes that a package maintainer has the time or expertise to actually audit the code fully and correctly. Really bold assumption!

Re: Linux apps that run anywhere

#63

Post by vhhn »

im_down_w_otp wrote: post #4

One of the issues I've had with things distributed as Snaps or Flatpaks is that they tend not to pickup the settings and preferences that I've configured on my workstation. For example, if I've setup themes, fonts, scaling factors, custom keyboard shortcuts, etc., they tend not to be available/utilized by the applications which are distributed in these bundling formats. For the most part, that's why I avoid using the…

I was surprised when VSCode snap told me that I should start using different snap to install new versions if VSCode and that my settings would be kept. And it did. So there is some way to respect users settings across snaps at least

Re: Linux apps that run anywhere

#64

Post by Conan_Kudo »

mickael-kerjean wrote: post #44
pknopf wrote: post #29

Earlier quoted context omitted.

What if another heartbleed happens? Wouldn't it be better to update a single shared library?

In theory. In practise it's much faster to push for a fix to your users with a brand new fat binary than having to figure out the mess that is distributing your software on every possible Linux distribution (obligatory XKCD: https://xkcd.com/927/ ). Also shared libaries assumed your software will work on a different version of a library which is quite a bold assumption that may or may be true depending on the phase o…

> In theory. In practise it's much faster to push for a fix to your users with a brand new fat binary than having to figure out the mess that is distributing your software on every possible Linux distribution (obligatory XKCD: https://xkcd.com/927/).

Electron seems to have disproved this. There are many Electron based applications that are broken with glibc >= 2.28 even though a fixed version of Electron has been out for it for nearly a year.

Fat binaries (or fat binpacks) are a failure.

Re: Linux apps that run anywhere

#65

Post by flukus »

oblio wrote: post #58
bubblethink wrote: post #45

Earlier quoted context omitted.

>Finally, the big advantage is that the release is done by the author I see that as the biggest net win of the current system although it may seem inefficient or bureaucratic. I do not trust the authors. The only modicum of sanity and trust comes from the fact that debain/fedora maintainers are actually on your (the user's) side and have strong rules and guidelines about everything. Desktop linux doesn't have that mu…

With your logic, you've already lost. If you don't trust the developer of an application you already run, you're screwed in any scenario. Yours is not a realistic threat model.

Developers don't deserve that trust.

It's not just threat model, developers are increasingly focusing on fast iteration and annoying users with constant and often unwanted updates, something debian saves users from, very few users care about always having the latest features and bugs or want to become beta testers. Not to mention the privacy shitshow from developers wanting telemetry or more nefarious reasons.

Software repositories like debian and the apple app store are great because the put a layer between the developer and the users and require a 1-1 trust calculation.

Re: Linux apps that run anywhere

#66

Post by curt15 »

earenndil wrote: post #23

It makes me really sad that this is necessary. Unix has a concept of shared libraries. And somehow it managed to get ruined so irrevocably that there's no going back. This—this was a solved problem! It really was. It was solved, and then we unsolved it when we decided that 'move fast and break things' was more important than ABI stability. And now shared libraries are completely useless. I struggle to name a single u…

>HOW DID THIS HAPPEN?

Microsoft treats Windows APIs as a contract with the developer, with behavior defined by specifications. Are Linux libraries typically managed that rigorously?

Re: Linux apps that run anywhere

#67

Post by tigrezno »

Pneumaticat wrote: post #20

FYI, AppImages do not run anywhere. There are a lot of issues with them in NixOS, since NixOS is all about having explicitly-linked dependencies, and AppImages still often have implicit dependencies that aren't in the image itself, since they are assumed to exist on the host system. See https://github.com/NixOS/nixpkgs/pull/51060 for an example.

but who really uses NixOS? a 0.001% of linux users?

Re: Linux apps that run anywhere

#68

Post by TBF-RnD »

Come on guys, I see a lot of negativity here but we can have the cake and eat it. Look at the following imaginary but likely scenario. A promising coder creates an app in C using cmake or whatever. For a veteran linux user to use git and compile is not a problem. Our up and comming coder want to reach out to a wider audience however so instead of creating X packages he provides an appimage. All of the sudden all the fedora, debian and ubuntu guys etcetera can run it without the hassle.

Now imagine if the project turns out to be a silver bullet for some really important problem. What will happen, the maintainers for the bigger distros will simply download the code and there will be maintainers that steps up and maintains the software for the repos.

Voila, the best of two worlds.

... and if the project doesn't become a huge mainstream access users now can get it via source or appimage .

As far as commercial projects are concerned they will operate according to different dynamics. But who cares we want open source solutions for our linux systems anyway.

Re: Linux apps that run anywhere

#70

Post by Annatar »

pjmlp wrote: post #57
Annatar wrote: post #55

Earlier quoted context omitted.

But it won't solve the problem of developers' unwillingness to learn how to make operating system packages now will it? I don't get it: people like that will sink and waste hundreds of hours learning useless garbage like Puppet, Ansible, Chef, Docker or Kubernetes without batting an eyelash or even thinking twice about it, but they'll argue and fight back like hell come time to deliver their software as clean OS pack…

Because those providing the said technology cannot agree what it means to be a GNU/Linux OS, and we have limited time on our life to bother with thousand variants of it.

Linux is just a kernel, so every distribution is a somewhat similar yet completely different operating system.

Reality is, most software targets CentOS / RHEL, OpenSUSE / SLES and Debian / Ubuntu. That's exactly two packaging formats, RPM and DPKG.

Now, let's presume for the purpose of illustration that learning both of those takes 100 hours (it takes much less): to learn Chef, Puppet, Docker, Ansible and Kubernetes to any degree of proficiency takes about 1,000 hours. Where's the business value?

Post reply on HN