Live data from Hacker News

Linux apps that run anywhere

appimage.org

111–117 of 117 posts

Re: Linux apps that run anywhere

#111
post #91

Earlier quoted context omitted.

Yeah, but the user accounts are at the application level not the os level. I doubt there is a top internet company around that makes a unix account for each web user. That would be an antipattern...

Search for "free shell accounts". You might be surprised.

It kind of reminds me of shared hosting providers without root access. Sure they exist but really have been overtaken in a big way by virtual private servers... That's what I mean by they seem going out of style.

Re: Linux apps that run anywhere

#112
post #88
post #65

Earlier quoted context omitted.

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. Softwa…

Distributions in their current form are almost harmful. I like what they do, conceptually, but that model you're describing should only apply for the base system. I want Firefox to update ASAP, I want VLC to update ASAP. The distribution model should only apply to libraries and base tools. And even those should be versioned so they can coexist easily and I'm easily able to install any app, from the ones that want GTK…

> I want Firefox to update ASAP

Firefox is the perfect example of why I hate user facing apps updating constantly. They're always adding random features, breaking plugins (still don't have vertical tabs working properly) and shifting the UI around. It was much better back when they had stable releases.

> The distribution model should only apply to libraries and base tools.

As long as nothing breaks it doesn't worry me how many times libc is updated, it's the user facing changes that interrupt me I want to avoid.

> And even those should be versioned so they can coexist easily and I'm easily able to install any app, from the ones that want GTK1 to the ones that want GTKLatest.

If they can't commit to stable releases and non-breaking API then they aren't going to commit to maintaining the 15 versions of GTK that you'd end up with on your system, that's the worst of every world.

Re: Linux apps that run anywhere

#113

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…

Private developer wants to distribute binary + shared dependency libs. On Windows they package it into an installer which unpacks it into the target destination & everything works. On MacOS the user gets a folder that acts like file within which everything is stored. Additionally there are reliable releases so something targeting a minimum of MacOS 10.14 has a reliable way to specify that in the toolchain & know that…

It really isn't that hard on Linux. Basically:

1. define your dependencies (try to be conservative so you're not reliant on bleeding edge features) 2. Make a good app that people want with a fairly simple build step 3. Support one or two major distributions 4. Ask for help in bundling for everything else 5. Fix issues as they're discovered

If you ask nicely and people want your app, the community will help you out with the rest. Just look at Steam, which is really only supported on Ubuntu and SteamOS, but is packaged by pretty much everyone.

Re: Linux apps that run anywhere

#114

What people use it for at the top, what it does in the middle, and how it works at the bottom, buried in a video - typical modern sites (except this one at least has the video). What I would like to see: 1. Problem statement 2. How this solves it 3. Usage guide 4. Source code link 5. No appeal to authority of who's using it

Eh, I think 5 is important because it shows that there's a vested interest in keeping the project going. I absolutely do make decisions on what to use based on who is using it because switching to something else after a project dies is a royal pain, and I don't have the time to maintain it myself (though I can certainly submit patches here and there).

Re: Linux apps that run anywhere

#115
post #86
post #79

Earlier quoted context omitted.

Always use musl for static linking. As a bonus you might get an even smaller binary than a dynamically linked glibc binary.

Keep in mind, however, that AFAIK musl won't respect /etc/nsswitch.conf, so if for instance the machine is configured to lookup users on ldap, a musl static linked program won't be able to correctly lookup users.

There are certainly cases where you need the features of glibc over musl, but those are pretty rare IMO, and you can always implement a missing piece yourself if using musl saves you enough in maintenance overhead.

Re: Linux apps that run anywhere

#116

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?

There are dozens of us.

Re: Linux apps that run anywhere

#117

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…

It was never really solved. Shared libraries create huge integration testing headaches and the linux landscape fragmented early. This means that there are a lot of combinations of libraries out there in lots of different versions. Some distributions stick to really old versions of stuff to preserve backwards compatibility. E.g. Red Hat is really awful if you are a developer since it pretty much has the wrong version…

Nowhere is it written that a system can only have one version of each library. Indeed, there is an entire system (soname) for resolving which of many versions of a library a binary should run with. There is no reason at all why you couldn't have a system where all the libraries are shipped in your application folder, but it uses the system ones where available. There's also no reason why every distro couldn't have every version of every library, and all software since ever would just work with the system version.

Distros screwed the pooch here.

Post reply on HN