Live data from Hacker News

Linux apps that run anywhere

appimage.org

71–80 of 117 posts

Re: Linux apps that run anywhere

#71
post #63

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

Possibly how it's done: the settings are stored in a config directory, like ~/.vscode or something.

For instance, my neovim AppImage works this way (it still reads ~/.config/nvim/init.vim like regular neovim).

Re: Linux apps that run anywhere

#72

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.

Yeah, AppImages are not really comparable to snap and Flatpak, which both address this issue by managing shared sets of libraries as well as applications. Flatpak calls these sets of libraries "runtimes", and snap calls them "base snaps". The metadata for each application declares one runtime or base snap that it uses.

This ability to easily provide different userlands to different applications is one of the critical advantages of these new application formats.

Re: Linux apps that run anywhere

#73
post #17

"No need to install". This is every system administrator's nightmare: users running arbitrary executables bypassing operating system packaging. Come time to upgrade or reinstall what can happen? If there are security updates which are needed to the program, what could happen, since this is statically linked? This is the pinnacle of destructive lazyness and amateurism in IT: as a developer it is one's job to master ev…

Literally the reason why PCs won over mainframes. Users want to run the software they want to run. If you don't trust your users to run software on your server you probably shouldn't let them on your server in the first place... or else contain and isolate them with a VM or similar. Multi-user operating systems are feeling a bit like they are going the way of the dodo, to me... That is acutall multi-user systems, not…

What do you think powers the InterNet that you're connected to right now? Multiuser systems, running applications under different logins. Even the much hated systemd brought physical multiuser computing back to GNU/Linux.

Re: Linux apps that run anywhere

#74
post #40

If you want portable apps just make one fully staticly compiled binary. This is the worst of all worlds. No security updates for used libraries and no performance gain that comes with static linking.

The static linking ship has sailed years ago for glibc based apps (no static linking support).

Re: Linux apps that run anywhere

#75
post #57
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.

But you don't have limited time to re-invent the wheel over and over again by inventing new programming languages, learning new frameworks and re-implementing what already exists? How many headlines here were of the "why do it inefficiently? Because I can!" type? The limited time argument is a fallacy in this context.

Re: Linux apps that run anywhere

#76
post #63

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

The official VS Code snap is unconfined, ie. it only uses snap for package management without the sandbox. This means it can access the settings stored in your home directory just the same as if it was installed through apt.

Snaps with strict confinement can also ask for home directory access as a specific permission.

Re: Linux apps that run anywhere

#77
post #61

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 Wind…

I assume you install different browser than Safari. So is it frustrating that you have to install 3rd party browser?

Come on homebrew is awesome. Install is easy and then you just point brew bundle to file with everything you need, go for coffe and your computer is ready.

Re: Linux apps that run anywhere

#78
post #73

Earlier quoted context omitted.

Literally the reason why PCs won over mainframes. Users want to run the software they want to run. If you don't trust your users to run software on your server you probably shouldn't let them on your server in the first place... or else contain and isolate them with a VM or similar. Multi-user operating systems are feeling a bit like they are going the way of the dodo, to me... That is acutall multi-user systems, not…

What do you think powers the InterNet that you're connected to right now? Multiuser systems, running applications under different logins. Even the much hated systemd brought physical multiuser computing back to GNU/Linux.

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

Re: Linux apps that run anywhere

#79
post #74
post #40

If you want portable apps just make one fully staticly compiled binary. This is the worst of all worlds. No security updates for used libraries and no performance gain that comes with static linking.

The static linking ship has sailed years ago for glibc based apps (no static linking support).

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

Re: Linux apps that run anywhere

#80
post #70
post #57

Earlier quoted context omitted.

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…

Try to install a random RPM package targeted to Red-Hat on SLES to see how far you will go.
Post reply on HN