[NormenKD]

They aren't happy with this, either:

"[...]And of course, the journey isn't over yet－we'd love your help, particularly if you're excited about:

- Helping bring Zed to your distro. Either by packaging Zed or by making Zed work the way it should in your environment (we know many people want to manage language servers by themselves).[...]"

Give them a hand ;) https://zed.dev/docs/development/linux#notes-for-packaging-z...

[AndyKelley]

I sympathize with the situation that Zed developers are in. They are thinking of the user experience first and foremost, and when trying to distribute on Linux, faced with an overgrown, chaotic landscape that utterly fails to provide the basic needs of application developers, such as the ability to distribute a binary that has no dependencies on any one particular distribution and can open a window and interact with the graphics driver, or the ability to require permissions from the user to do certain things.

I do think that my work contributes to help with this use case. Looking elsewhere on this thread I see that they are having problems fetching and running a nodejs binary successfully. Fortunately, nodejs is a piece of software that can be built and distributed statically. I have not packaged up this one in such a manner but I have done a proof of concept with CPython: https://github.com/allyourcodebase/cpython

That said, if they want to allow users to install Zed through a system package manager, they will need to cooperate with the system and rely on system nodejs instead of trying to fetch it at runtime. Fetching and running software at runtime is fundamentally incompatible with the core mission of Linux distributions (curation, vetting, and compatibility patching of all software that is to be run on the system).

[logicprog]

> I sympathize with the situation that Zed developers are in. They are thinking of the user experience first and foremost, and when trying to distribute on Linux, faced with an overgrown, chaotic landscape that utterly fails to provide the basic needs of application developers, such as the ability to distribute a binary that has no dependencies on any one particular distribution and can open a window and interact with the graphics driver, or the ability to require permissions from the user to do certain things.

But Linux does provide a very simple and easy way to do this — Flatpaks. They're completely distro-independent, allow you to package up and distribute exactly the dependencies and environment your program needs to run with no distro maintainers fucking with it, allow you to request permission to talk to the graphics drivers and anything else you need, and you can build it and distribute it directly yourself without having to go through a million middlemen. It's pretty widely used and popular, and has made the silent majority of Linux users' lives much better, although there's a minority of grognards that complain endlessly about increased disk usage.

[kelnos]

Maybe I'm just old-fashioned, but I don't like Flatpak (or Snap or AppImage). They still don't seem to have solved all the desktop integration issues. I do not like running apps that bundle their own dependencies, because I don't trust the app developers to be on top of security issues. I trust Debian maintainers (despite mistakes in the past) to keep my system's base libraries up to date and patched. Why would I trust some random developers of some random app to do the same?

[logicprog]

> Maybe I'm just old-fashioned, but I don't like Flatpak (or Snap or AppImage).

That's certainly your prerogative, and I hope traditional distro packages stick around — I think they will, since they are the basis of so much fundamental infrastructure. And I'm sure there will be a cottage industry of converting flatpaks to .debs or .RPMs in the future if flatpaks become the dominant way of distributing GUI software :)

> They still don't seem to have solved all the desktop integration issues.

They haven't solved all of the issues yet, but while snaps and appimages are still struggling mightily, flatpaks seem to be making pretty good progress on that front, at least if you stick with modern Electron (not the old version Discord has!), QT, and GTK applications. And I think generally all of the issues are solvable, and not only that, but solving them will leave the Linux desktop in a much better place than it was before, because we can build in broker-based sandbox permissions, and things like making each GUI toolkit automatically use the native file-picker of the user's desktop environment (something GTK4 and Qt5 support via the relevant Flatpak portal).

> I don't trust the app developers to be on top of security issues. I trust Debian maintainers (despite mistakes in the past) to keep my system's base libraries up to date and patched. Why would I trust some random developers of some random app to do the same?

I understand where you're coming from here and this is a common objection to sandbox packaging solutions, but I think there are a few problems with it.

First of all, Dependabot exists: all maintainers of Flatpaks need to do to keep their dependencies up-to-date is enable it for their application repository and then just keep an eye out for emails from the bot and approve the automated pull request when those emails show up. You can do it all from your smartphone! I've done it. Importantly, there would be absolutely no need to manually patch system libraries or backport patches, or any of that nonsense, if we didn't adhere to the distribution model of packaging, because then there would be no delay in releasing libraries, you could just get the libraries directly from upstream, and there would be no point releases or anything of the sort. So a lot of the very appreciated and difficult work that distribution maintainers have to do every day is work that is made necessary by the model of distribution in the first place. So yes, we'd be expecting application maintainers to keep their dependencies up to date, but that job would itself become much easier.

You might say that part of the distribution maintainers' job is to actually inspect library updates from upstream to find vulnerabilities or whatever, but there are far too many packages and dependencies for them to actually do that. I very highly doubt they are actually trawling through all of the code to try to spot vulnerabilities, and that seems like a job best left to the far greater number of much more knowledgeable eyes directed at open source libraries upstream.

This model doesn't just eliminate a lot of unnecessary work either — it distributes the workload; now, instead of one team having to break themselves to keep every system library up to date, everyone shares the burden of keeping the libraries they use up to date. This does open up the possibility of lazy application developers not pressing the "fix my dependencies" button, to be sure, but the amount of dependency hell and cross-distribution portability problems that packaging dependencies with applications solves I think outweighs that concern. Security isn't the only consideration here, there's also other practical considerations. Otherwise, we'd all be using Qubes xP

Furthermore, it should be noted that many of the larger dependencies of Flatpaks, at least, are handled through platforms and platform extensions and SDKs, where bundles of interrelated dependencies are actually separate packages from the application Flatpaks, and thus can be updated by upstream independently. The key with them is just that they, too, like regular applications, become insoluble independent of distribution, and capable of being maintained by upstream as a result, and you can also install multiple versions of them if necessary.

In the end, I think it's a trade-off. But I seriously don't think dynamic linking and having to keep all of the versions of every package on your operating system in perfect lockstep to keep them all using the same version of a dependency, tying your system library versions and app versions and OS versions itself into one big tangled ball of interdependency, where you can't upgrade application B because it shares a dependency with application A and would require a newer version than application A knows how to use if you upgraded it, and having to continually backport security patches from newer versions of that dependency to the version that your system is still in lockstep with is a sustainable and sensible model, especially because of how much work it foists on one single team.

[AndyKelley]

I appreciate all your comments in this thread. I wasn't aware of how competitive Flatpak was and I still haven't played with the technology - but I am more interested in it now.

Also for the record, I wouldn't have complained about them primarily linking to a Flatpak. It seems like a perfectly reasonable alternative to a shell script installation.

[doublepg23]

The best part of Linux’s single universal packaging system is there’s three of them.

[logicprog]

Sure, but all of them are actually universal, so it doesn't matter which one you choose, unlike their being multiple regular package formats.

[doublepg23]

It seems to me the most neutral one is AppImage. Flatpak being the favorite of “not-Ubuntu” people and Snap being only preferred by Ubuntu…but still having a huge user base due to their enormous market share.

[tjoff]

People don't prefer snap, they are forced into it.

[aidenn0]

I have a shell script that will recursively copy and rewrite the rpaths of every shared-object that all elf files in a sub-directory reference to bundle it up. It obviously can't handle dlopen(), and ld-linux cannot be specified as a relative-path to the executable, but it works for many binaries.

Of course that has the problem that vendoring always has; you have pinned every dependency, which is great for making the software work, but you miss out on security updates.