9 ms·

My biggest problem with them all is that I don't really have a problem with my apt. I understand that this situation is problematic with vendors who want to di

My biggest problem with them all is that I don't really have a problem with my apt. I understand that this situation is problematic with vendors who want to distribute their apps. But to me it feels like that the packaging situation has always been an excuse for them to drop Linux support. If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. And a lot of vendors are doing that nowadays. Sandboxing would've been nice for sure. But again, I don't have a security problem with my Linux Desktop as of right now.

jcelerier 8y ago
> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. well, yes it is, because it only covers two families of distros over many. I develop a software with a fairly small niche and you wouldn't believe the weird distros on which people test it. With the AppImage, everyone is happy - and also the software can be installed without administrative permissions which is fairly useful when you want to use it in a class room without having to spend a week with the local system administrators to get the .deb deployed and just have the students download the AppImage and execute it.
- xfer 8y ago
  It isn't really that hard to repackage it for any packaging format after extracting the deb file. I have used those distros(arch, void, now nixos) for a long time, i never had a problem with anyone providing just a deb file.
  - X6S1x6Okd1st 8y ago
    It sounds like you are exceptional
    - adrianN 8y ago
      It sounds like a software vendor that sells their product shouldn't have problems creating packages for their customers.
      - jcelerier 8y ago
        yes, but a software vendor who provides FOSS on his free time certainly does not have time for this.
        syn0byte 8y ago
        Crazy novel idea; The FOSS developer could just give out the source code, maybe with some helper build scripts, and then users could just build the software on whatever platform they want. Maybe making changes to which features they need and which external dependencies they required. Even crazier; what if we had a standard, well supported build system that we could included with every OS and distro? Nah, thats crazy talk. Lets repackage an entire OS so you can run an OS while your running your OS so you can listen to internet radio.
        zyga 8y ago
        It's not a crazy idea, just one that entirely limits the target audience to extremely technical people. Some people would like to make their software available to a wider audience.
        jcelerier 8y ago
        > and then users could just build the software on whatever platform they want. most of my users are non-technical (yes, even on linux). Also, if you want to use a modern development environment this won't work: for instance, I use C++14 / 17 which restricts me to distros at least as recent as ubuntu 18.04 for building and cuts out an immense part of the user base. With AppImage it does not matter what OS my user is running - even if the OS isn't able to build my software, it will be able to run it. > Even crazier; what if we had a standard, well supported build system that we could included with every OS and distro? won't happen. I have users on ubuntu 12.04 which still uses e.g. CMake 2.8 which is way too old and a frankly different language than CMake > 3.0. Even if it was another build system it would be the same problem : you would have to restrict yourself to the oldest released version still in used of the build system, which really really sucks because build systems hardly ever "get it right" in their 1.0 version.
gregmac 8y ago
> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. There's also the issue of dependencies on other non-default packages. Do you ask the user to install another repository? Do you host your own repository and distribute the dependent packages in it along with yours? (Note this is much more complex than building and hosting a single .deb/.rpm) Not to mention "desktop Linux" is not a thing. Supporting Fedora, Ubuntu and opensuse, for example, are all distinct efforts with only minimal overlap in terms of effort (think not just initial dev, but ongoing maintenance and testing).
- emilsedgh 8y ago
  As far as I know, Snap, AppImage and the rest are all statically linked. You can have static linked Deb's and RPM's as well. That's what most of the vendor-provided deb's and rpm's do.
  - faho 8y ago
    Technically, they usually aren't "statically" linked as such. They usually use dynamic linking, but then ship those dynamically linked libraries in the package. This has the advantage that the user can still replace the libraries if they want (e.g. for games this is sometimes useful to replace the sdl build with one with more options enabled), and I've heard rumblings that the support for static linking on linux isn't all that great.
  - zyga 8y ago
    Your knowledge is incorrect. Snaps don't have to be statically linked. They use a mount namespace with a predictable set of libraries that are maintained and receive security updates. In addition the application can bring additional libraries but those are on the application developer to maintain (or delegate to a hosted service like build.snapcraft.io to rebuild on security updates). Sure, you can do static linking, you just don't have to and this is not how snaps work.
    - emilsedgh 8y ago
mjg59 8y ago
There's a lot of corner cases that break under static linking - anything that dlopen()s stuff using a private API is an obvious one, and that includes glibc.
jhanschoo 8y ago
> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. Many developers don't have the resources to go through the whole process needed to get their app into the distro repo. In that case, I'd consider these package formats better than deb and rpm.
- michaelmrose 8y ago
  You can provide a repo hosting your software so that prospective users can add your repo. This is essentially trivial and can even be hosted for free. After your user adds your repo updates will be handled automatically with the rest of the system and installs can be done in the same software management gui as anything else.
  - SmellyGeekBoy 8y ago
    What if the user doesn't have root access? e.g. in a school setting?
    - michaelmrose 8y ago
      Schools almost exclusively use Microsoft Windows. Linux is almost exclusively used on servers, technical peoples workstations/laptops at work, and interested users personal computers. Optimizing for users you wish you had doesn't seem optimal. In the hypothetical school setting you probably want to actively prevent the user installing insecure crap in their home directory to the degree its possible to do so.
sjellis 8y ago
> I don't have a security problem with my Linux Desktop as of right now. Matthew Garrett (who does internal Linux desktop security at Google) gave a great talk at GUADEC about the current state of Linux desktops: https://www.youtube.com/watch?v=DUa-nnjjQcc https://www.youtube.com/watch?v=DUa-nnjjQcc TLDR: It's not good. User-level processes have free, unrestricted access to all of your data, unless you use Wayland and desktop containerization.

jcelerier 8y ago

> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. well, yes it is, because it only covers two families of distros over many. I develop a software with a fairly small niche and you wouldn't believe the weird distros on which people test it. With the AppImage, everyone is happy - and also the software can be installed without administrative permissions which is fairly useful when you want to use it in a class room without having to spend a week with the local system administrators to get the .deb deployed and just have the students download the AppImage and execute it.

xfer 8y ago
It isn't really that hard to repackage it for any packaging format after extracting the deb file. I have used those distros(arch, void, now nixos) for a long time, i never had a problem with anyone providing just a deb file.
- X6S1x6Okd1st 8y ago
  It sounds like you are exceptional
  - adrianN 8y ago
    It sounds like a software vendor that sells their product shouldn't have problems creating packages for their customers.
    - jcelerier 8y ago
      yes, but a software vendor who provides FOSS on his free time certainly does not have time for this.
      - syn0byte 8y ago
        Crazy novel idea; The FOSS developer could just give out the source code, maybe with some helper build scripts, and then users could just build the software on whatever platform they want. Maybe making changes to which features they need and which external dependencies they required. Even crazier; what if we had a standard, well supported build system that we could included with every OS and distro? Nah, thats crazy talk. Lets repackage an entire OS so you can run an OS while your running your OS so you can listen to internet radio.
        zyga 8y ago
        It's not a crazy idea, just one that entirely limits the target audience to extremely technical people. Some people would like to make their software available to a wider audience.
        jcelerier 8y ago
        > and then users could just build the software on whatever platform they want. most of my users are non-technical (yes, even on linux). Also, if you want to use a modern development environment this won't work: for instance, I use C++14 / 17 which restricts me to distros at least as recent as ubuntu 18.04 for building and cuts out an immense part of the user base. With AppImage it does not matter what OS my user is running - even if the OS isn't able to build my software, it will be able to run it. > Even crazier; what if we had a standard, well supported build system that we could included with every OS and distro? won't happen. I have users on ubuntu 12.04 which still uses e.g. CMake 2.8 which is way too old and a frankly different language than CMake > 3.0. Even if it was another build system it would be the same problem : you would have to restrict yourself to the oldest released version still in used of the build system, which really really sucks because build systems hardly ever "get it right" in their 1.0 version.

gregmac 8y ago

> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. There's also the issue of dependencies on other non-default packages. Do you ask the user to install another repository? Do you host your own repository and distribute the dependent packages in it along with yours? (Note this is much more complex than building and hosting a single .deb/.rpm) Not to mention "desktop Linux" is not a thing. Supporting Fedora, Ubuntu and opensuse, for example, are all distinct efforts with only minimal overlap in terms of effort (think not just initial dev, but ongoing maintenance and testing).

emilsedgh 8y ago
As far as I know, Snap, AppImage and the rest are all statically linked. You can have static linked Deb's and RPM's as well. That's what most of the vendor-provided deb's and rpm's do.
- faho 8y ago
  Technically, they usually aren't "statically" linked as such. They usually use dynamic linking, but then ship those dynamically linked libraries in the package. This has the advantage that the user can still replace the libraries if they want (e.g. for games this is sometimes useful to replace the sdl build with one with more options enabled), and I've heard rumblings that the support for static linking on linux isn't all that great.
- zyga 8y ago
  Your knowledge is incorrect. Snaps don't have to be statically linked. They use a mount namespace with a predictable set of libraries that are maintained and receive security updates. In addition the application can bring additional libraries but those are on the application developer to maintain (or delegate to a hosted service like build.snapcraft.io to rebuild on security updates). Sure, you can do static linking, you just don't have to and this is not how snaps work.
  - emilsedgh 8y ago

mjg59 8y ago

There's a lot of corner cases that break under static linking - anything that dlopen()s stuff using a private API is an obvious one, and that includes glibc.

jhanschoo 8y ago

> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. Many developers don't have the resources to go through the whole process needed to get their app into the distro repo. In that case, I'd consider these package formats better than deb and rpm.

michaelmrose 8y ago
You can provide a repo hosting your software so that prospective users can add your repo. This is essentially trivial and can even be hosted for free. After your user adds your repo updates will be handled automatically with the rest of the system and installs can be done in the same software management gui as anything else.
- SmellyGeekBoy 8y ago
  What if the user doesn't have root access? e.g. in a school setting?
  - michaelmrose 8y ago
    Schools almost exclusively use Microsoft Windows. Linux is almost exclusively used on servers, technical peoples workstations/laptops at work, and interested users personal computers. Optimizing for users you wish you had doesn't seem optimal. In the hypothetical school setting you probably want to actively prevent the user installing insecure crap in their home directory to the degree its possible to do so.

sjellis 8y ago

> I don't have a security problem with my Linux Desktop as of right now. Matthew Garrett (who does internal Linux desktop security at Google) gave a great talk at GUADEC about the current state of Linux desktops: https://www.youtube.com/watch?v=DUa-nnjjQcc https://www.youtube.com/watch?v=DUa-nnjjQcc TLDR: It's not good. User-level processes have free, unrestricted access to all of your data, unless you use Wayland and desktop containerization.