On Linux you have to provide RPMs for Redhat, DEB files for Debian-variants, ??? for Gentoo users. Moreover, your dependencies have to be managed in a totally bizarre way & you need special launchers to put your shared libraries elsewhere & add them to the path to avoid making assumptions about whether or not the user has the right prerequisites. Or you run your own apt/yum/etc servers to host your packages & play nice within the ecosystem. Additionally, some do periodic releases. Some do rolling releases. Considering how small of a population Linux it makes it more headache than it's worth to target for commercial shops that are cross platform as most of their customers are. That also isn't getting into the mess that 32-bit vs 64-bit is on Linux.
Finally, the big advantage is that the release is done by the author. No more package maintainers providing questionable maintenance across a bunch of distros.
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 much meaningful isolation or sandboxing that malicous apps cannot circumvent. It's only now that we are seeing some efforts in this direction. Still, it's quite far from something like android where you can quite safely run arbitrary applications.
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.
I don't believe it was "solved", and I don't believed it was caused by people "moving fast and breaking things".
Linux became HUGE, in terms of the number of people involved, and there is no master body that would govern anything. As an application developer, you could build against libfoo, then your app break on debian because they never updated libfoo besides some strange monkeypatch, and be broken on redhat because they decided to fix bug #12494 differently from the developers of libfoo.
God himself has decided it's too hard, too complex and too much of a clusterfuck of competing motivations to expect that RedHat/Debian/FooBarLinux will reliably all provide the same shared library. And the user doesn't case, bandwidth the cheaper than disk, and its most certainly cheaper that user's time.
I will grant, however, that it is hard. Newer languages—rust, c#, java, python, js—are trying. Of them I would say rust is the best, followed closely by c#, with python and js taking a distant 3rd and 4th, but none of these match the older languages. But—rust is newer than c# and java and python and js. They decided: we're going to make a high-quality, stable package repository, with a culture of stability in packages. And aside from stuff requiring nightly, that seems to be happening, it's still pretty good, and it's still a hell of a lot better than linux. Granted, linux has a much more difficult situation to wrangle, and because it's less monolithic than those other constructions, tragedy of the commons tends to occur, but I think all it takes is a group of people deciding that they will take the work to make things right, getting support, getting lucky, making a super-dynamic linker, and we can fix this.
For example, distribution's package update cycle is so slow that some packages are never updated to upstream for some reason. For example, x11vnc's latest version is 0.9.16 but Ubuntu/Debian has locked down to 0.9.13 for more than a half of a decade [1]. ddclient is also a good example [2].
In my case, I made a program that requires >= Python3.6 but I realized Ubuntu was stuck in 3.5 for years so that I was forced to use AppImage to include in-house compiled Python3.6.
Not to mention that Electron apps are simply not compatible with distribution's dependency management.
[1]: https://packages.ubuntu.com/search?keywords=x11vnc&searchon=...
Luckily these days you package the correct versions up as Docker images so, it's much less of an issue. The amount of space you save with sharing your libraries does not really outweigh the benefits of shipping exactly those things you need as a statically linked binary.
Doing the same for user space software makes a lot of sense. Apple figured this out in the nineties already. Mac software never really needed installers. Drag the app to the Applications folder, delete to remove. Just works. The only package managers on OSX are for managing OSS linux software.
Distros screwed the pooch here.
I wanted to sort an array based on information in another array. I don't think qsort has the power to do this, so I used qsort_r.
I later found it didn't compile on another system (termux on android) because qsort_r didn't exist there.
I don't feel like 'move fast and break things' is the culprit here (although it undoubtedly is in other cases).
Having qsort_r in some unixes and not others feels wrong. And doing without qsort_r also feels just wrong. I don't know the solution.
Libcurl is the only one I frequently use that seem to take it seriously, there might be others but frustratingly few will indicate what level of binary compatibility they guarantee, it would be nice to have a list of reliable libraries. Not just for binary compatability but I would be nice to know how much churn you can expect with any given library.
On the other hand, considering the state of the software industry with relation to privacy (including some open source products) running software from arbitrary sources is becoming less and less viable anyway, I'm not sure it's a problem worth fixing.
Microsoft treats Windows APIs as a contract with the developer, with behavior defined by specifications. Are Linux libraries typically managed that rigorously?
Static binaries are just a form of vertical integration.
Snap and Flatpak, by contrast, have explicit systems in place to prevent this. Of the two, I much prefer Flatpak for being a community-driven project. Also, Snap doesn't let you disable automatic updates (without hacks to your hosts file or such). Whatever you think about the security implications, this feels very against the Linux ethos of the user always retaining ultimate control.
The downside is that Snap-packaged apps don't always integrate correctly with the underlying system. For a while theme support was pretty broken. And subtle configuration options aren't always passed in. Worth it in my case though!
I fully embrace the idea of decentralized distribution of applications, as opposed to the way package managers work (central repository mantained by the distro)
I believe the operating system should only be concerned about the base software and present a sane interface so that the user can then install the specific programs they need, the OS should not care about how or where the user gets those programs.
Appimage is the only project I know that respects that idea. Snap and Flatpak are centralized AFAIK (or are unnecessarily hard to use in a decentralized manner).
Something like Snap tries to solve distribution and updating, using a store and cryptographic signatures. For decentralized use, the snaps can be downloaded along with a signature, and they can then be installed on computers with no net access. The snapd software can verify that the binary came via the store and can be trusted that far at least. Or you can avoid the store entirely, distributing .snap files unsigned or using your own verification mechanisms exactly as a developer does with AppImage, and force the installation using the relevant CLI arguments.
See https://github.com/NixOS/nixpkgs/pull/51060 for an example.
This ability to easily provide different userlands to different applications is one of the critical advantages of these new application formats.
LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH" ./Your*.AppImage
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 them.
I assume, but don't actually know, that this also true of AppImage. Can anybody who knows better confirm, or deny, that?
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.
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.
Snaps with strict confinement can also ask for home directory access as a specific permission.
For instance, my neovim AppImage works this way (it still reads ~/.config/nvim/init.vim like regular neovim).
This is the pinnacle of destructive lazyness and amateurism in IT: as a developer it is one's job to master every operating system packaging format for the target platform one develops for. OS packaging is a tool invented for developers, not a tool meant to be subverted at every turn and opportunity like this.
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 user accounts for system services.
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 packages because they don't want to learn the technology. Technology which exists for them first and foremost: OS packaging is meant to be a developer's tool and best friend.
Also, a side point -- is it wrong to want people to spend more energy on building fat binaries? To me they are the ultimate in portability (by definition), and investing in projects like musl libc and distributions like alpine, languages like go and rust that build portable static binaries is so much more accessible to me as a developer.
All the approaches to portable apps seem to just be hacking around the problem but I wonder if we should instead be pouring energy into making fully static binaries easier to build, then trying to optimize them to get them smaller.
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 of the moon
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
A video that plays for 12 minutes before it explains the bit about using an ELF header which mounts a disk image payload using FUSE.
This is the worst of all worlds. No security updates for used libraries and no performance gain that comes with static linking.
Make it executable
$ chmod a+x Subsurface.AppImage
and run!
$ ./Subsurface
.AppImageThat was easy, wasn't it?"
No. How about click/double click the app icon in your menu/desktop/the folder where you downloaded it into?
All other major operating systems (can) work like this; download something > click it > it works. No need to launch terminal, set executable permissions and type the name of file.
I foresee someone in five years complaining about how much RAM linux on the desktop uses. And somebody else blaming it on shared libraries not actually being shared because all the "apps" load their own snowflake library. So multiple copies of glibc, multiple copies of gtk, multiple copies of everything.
RIP RAM AND WALLET.
So know what you are paying with.
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.
- Fixed social media share buttons that cover the text on mobile
- It auto-translates to German even though my system language is set to English (seems like they use geolocation for this which is bad practise)
- Center aligned text that is annoying to read