6 ms·

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 brin

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-zed https://zed.dev/docs/development/linux#notes-for-packaging-z...

AndyKelley 2y ago
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 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 2y ago
  > 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.
  - doublepg23 2y ago
    The best part of Linux’s single universal packaging system is there’s three of them.
    - logicprog 2y ago
      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 2y ago
        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 2y ago
        People don't prefer snap, they are forced into it.
        doublepg23 2y ago
        Funny enough I have a friend at Microsoft who likes it as a secure, lightweight alternative to Docker.
  - kelnos 2y ago
    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?
    - 2y ago
- aidenn0 2y ago
  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.

AndyKelley 2y ago

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 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 2y ago
> 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.
- doublepg23 2y ago
  The best part of Linux’s single universal packaging system is there’s three of them.
  - logicprog 2y ago
    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 2y ago
      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 2y ago
        People don't prefer snap, they are forced into it.
        doublepg23 2y ago
        Funny enough I have a friend at Microsoft who likes it as a secure, lightweight alternative to Docker.
- kelnos 2y ago
  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?
  - 2y ago
aidenn0 2y ago
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.