11 ms·

What this could and should lead to is this: a separation between system packages and user applications, prefferably with two different managers. What we have n

What this could and should lead to is this: a separation between system packages and user applications, prefferably with two different managers. What we have now are mostly system package managers, you want them to be stable, secure, having the latest features might not be necessary. But we see more and more often that that distribution channel doesn't work well with applications: you end up with old, buggy, insecure applications because the distribution just couldn't keep up with the upstream update cycle. Why not have a cross-distribution application manager which distributes AppImages? That way, application distribution is an effort concentrated over all the distributions, possibly benefiting the entire community.

vbernat 11y ago
That's hardly related to a package manager. You can for example run Debian unstable to get more up-to-date stuff or mix Debian Jessie with backports. Same package manager, different sources.
- matzipan 11y ago
  What I'm suggesting is a decoupling between system package managers and application image managers (which should run across distributions/versions). Edit: thinking about it, this should also be the perfect opportunity for a cross-distribution app store/center.
- brbsix 11y ago
  I think the whole point of OP is to have completely separate installs (e.g. system apps installed in one root and user apps in another). If you go installing latest apps from different sources/repos, you're bound to face conflicts with the system packages. E.g. while installing packages with CPAN or pip, it is really easy to cause conflicts with the system Perl or Python, respectively. Right now there are lots of varying solutions to address this such as virtualenvs and docker images. These are fine for developers, but generally not acceptable to consumers. It would be nice to have a safe consistent experience, a generic user-mode package manager.
  - e12e 11y ago
    FWIW, it's generally a bad idea to mix in testing and unstable in a stable system (or even just testing). My recommendation is to run stable along with backports (if needed) -- and use something like schroot[1] for running persistent (separate) sessions under testing, unstable etc. Schroot essentially wraps up debootstrap and chroot along with mounting /proc etc, and (optionally) bind-mounting /home (which among other things gives access to x11 session cookies, for sharing one xorg display -- so one could run firefox, gimp or mplayr from an unstable-chroot on a stable system). Overall, with SSD prices dropping as sizes are increasing -- it might be better to simply use vms (one of the nice (potential) things about rkt -- the ability to run a "container" under kvm, turning it into a vm). [1] https://wiki.debian.org/Schroot https://wiki.debian.org/Schroot
- vanous 11y ago
  Thanks for mentioning this. I have been running unstable for many years and when people ask I simply tell them that it's like running latest Ubuntu except i can stay with my favorite Debian.
michaelmrose 11y ago
I really think that although this might be a boon to packagers it results in an inferior system wherein people end up with bloated,buggy packages. I don't want to deal with 2 different package managers and new users are apt to be confused by the idea that they get packages from 2 different places.
- matzipan 11y ago
  Well, it's the system that is composed of packages. The app images would be distributed through an app center. Most users wouldn't have to touch the system packages in their daily use case.
- djsumdog 11y ago
  Yea, I agree. I personally think that this is a huge step backwards. Look at Android and MacOS. You have these self contained packaging things that contain all their dependencies. You have the same dependencies in each package. You have a TON of wasted space with packages that have the exact same built-in libraries and jar files. Especially with Android, they could have made a real package dependency system, with slotted installs of all the jar/jar-versions from the official maven repos. When you install and app, it could install all its dependent jars. You'd still be able to do multiple versions of each of those jars, probably easier than it is with standard .so/.dll libraries. Projects like this are a huge step backwards is terms of DRY principals and general package management.
  - matzipan 11y ago
    Is space really an issue in most non-mobile user devices nowadays? Consider the tradeoffs: a bit of space vs. packaging nightmare which results in old, buggy and insecure packages. This was posted a few days back on hn: https://statuscode.ch/2016/02/distribution-packages-considered-insecure/ https://statuscode.ch/2016/02/distribution-packages-consider... I am not sure if the whole jar package dependency management would work under ART.
    - veddan 11y ago
nailer 11y ago
We use HTML5 clipboard and webcrypto and frequently get support requests from Linux users with outdated versions of supposedly 'evergreen' browsers.
rythie 11y ago
Not everyone has root on their Linux box and even if you do, you ought to be able to install applications as you without sudo'ing anything. Right now most Linux applications guide you to a deb/rpm which runs as root (and who knows if you can trust it). TBH this is just the start of making applications more secure, they ought to be sandboxed too, so one application can't read the data from another application by default (similar to how phones work).
- matzipan 11y ago
  I believe Ubuntu has done a some progress in this area with Snap packages.
- jonotime 11y ago
  There's also NIX, which I think does a good job of issolation in user space. https://nixos.org/nix/ https://nixos.org/nix/
- michaelmrose 11y ago
  You actually cannot make malicious applications safe you can however make nonmalicious applications inconvenient.
- jhasse 11y ago
  GNOME is working on it: https://wiki.gnome.org/Projects/SandboxedApps https://wiki.gnome.org/Projects/SandboxedApps
  - michaelmrose 11y ago
    You can make it slightly harder to infect the rest of the system leaving the factual truth that the moment you install malware you are hosed unchanged
- chmike 11y ago
  Wouldn't this raise the issue of application updates ? If the app imports its own libraries, who will take care to update them if a security issue is detected ? That's the point to enforce using shared libraries on unix system.
hasenj 11y ago
Yea I never understood why there's no separation between these two. The fact that apt-get needs root password only makes sense if apt-get is meant for system packages. User applications should not require root privileges to install.
- michaelmrose 11y ago
  Installers regularly install packages to system dir because it would be idiotic on a multi user system for each user to install different versions of Firefox to their home dir. It also serves to keep unprivileged users from installing software. You are free to install software to your home but it shouldn't be the default behavior
  - hasenj 11y ago
    The overwhelming use case for desktop users is there's usually one user on the system.
    - michaelmrose 11y ago
      Which is not a good reason to design anything based on that assumption it's extremely easy for a single user to use a multi user system but not the reverse.
toyg 11y ago
> preferably with two different managers. That's overcomplicating things. The "user" manager would have to figure out where the specific distribution is storing this or that lib. Doing it reliably across even a small subset of distributions (say, Ubuntu, Debian, Fedora and RedHat) and a small subset of their releases, would be very challenging. It would make much more sense to add a "user mode" option for the likes of apt-get, whereby it does not need sudo and it will install the specified package in ~/bin, ~/usr etc, symlinking necessary libraries. That doesn't seem too hard to pull off, in theory.
- pdonis 11y ago
  > It would make much more sense to add a "user mode" option for the likes of apt-get, whereby it does not need sudo and it will install the specified package in ~/bin, ~/usr etc, symlinking necessary libraries. And then any random piece of malware running in your browser can in principle hose all your applications. There's a very good reason that ordinary users do not have write access to application binaries on Linux.
  - toyg 11y ago
    It would hose only your "usermode" apps, which would be a small subset -- likely smaller unpopular apps that lag in the distro repository. The system as a whole would remain intact, so you can logoff and clean up the mess as root. What hack would rely on some specific app being deployed in user-mode anyway? To do what, steal user files it already has access to? It's obvious that "usermode" should be the exception and not the norm, but from a security standpoint it's exactly the same as compiling and installing with custom prefixes.
    - deleted 11y ago
      [deleted]
    - pdonis 11y ago
      > It would hose only your "usermode" apps, which would be a small subset Until more and more user apps start to get out of sync with the "system" versions of things, and therefore need to be installed with the "user" option in order to work. > What hack would rely on some specific app being deployed in user-mode anyway? A hack that doesn't care about specific apps but just wants to compromise whatever it can. Like, you know, a virus. > To do what, steal user files it already has access to? And send them to the Internet, without your knowledge. Like viruses already do--only it's a lot harder to get them to run on Linux. At least, it is now.
riquito 11y ago
If you don't share common dependencies you're doomed to have security hazards. Consider it this way: if you install package FOO with its dependencies A,B and C, and FOO's developer thinks it's "feature complete", the package will never be updated, but every time a vulnerability is disclosed in his dependencies you'll be it. For _every_ program maintained this way.
- matzipan 11y ago
  My argument is that you'd have cross-distribution appimage maintainers who would press a button and rerun the build script with the new library if it's needed.
  - cben 11y ago
    So appimage becomes yet another distro? (with the somewhat unique property that you can overlay it over other distros)
    - matzipan 11y ago
      More like app ecosystem.

vbernat 11y ago

That's hardly related to a package manager. You can for example run Debian unstable to get more up-to-date stuff or mix Debian Jessie with backports. Same package manager, different sources.

matzipan 11y ago
What I'm suggesting is a decoupling between system package managers and application image managers (which should run across distributions/versions). Edit: thinking about it, this should also be the perfect opportunity for a cross-distribution app store/center.
brbsix 11y ago
I think the whole point of OP is to have completely separate installs (e.g. system apps installed in one root and user apps in another). If you go installing latest apps from different sources/repos, you're bound to face conflicts with the system packages. E.g. while installing packages with CPAN or pip, it is really easy to cause conflicts with the system Perl or Python, respectively. Right now there are lots of varying solutions to address this such as virtualenvs and docker images. These are fine for developers, but generally not acceptable to consumers. It would be nice to have a safe consistent experience, a generic user-mode package manager.
- e12e 11y ago
  FWIW, it's generally a bad idea to mix in testing and unstable in a stable system (or even just testing). My recommendation is to run stable along with backports (if needed) -- and use something like schroot[1] for running persistent (separate) sessions under testing, unstable etc. Schroot essentially wraps up debootstrap and chroot along with mounting /proc etc, and (optionally) bind-mounting /home (which among other things gives access to x11 session cookies, for sharing one xorg display -- so one could run firefox, gimp or mplayr from an unstable-chroot on a stable system). Overall, with SSD prices dropping as sizes are increasing -- it might be better to simply use vms (one of the nice (potential) things about rkt -- the ability to run a "container" under kvm, turning it into a vm). [1] https://wiki.debian.org/Schroot https://wiki.debian.org/Schroot
vanous 11y ago
Thanks for mentioning this. I have been running unstable for many years and when people ask I simply tell them that it's like running latest Ubuntu except i can stay with my favorite Debian.

michaelmrose 11y ago

I really think that although this might be a boon to packagers it results in an inferior system wherein people end up with bloated,buggy packages. I don't want to deal with 2 different package managers and new users are apt to be confused by the idea that they get packages from 2 different places.

matzipan 11y ago
Well, it's the system that is composed of packages. The app images would be distributed through an app center. Most users wouldn't have to touch the system packages in their daily use case.
djsumdog 11y ago
Yea, I agree. I personally think that this is a huge step backwards. Look at Android and MacOS. You have these self contained packaging things that contain all their dependencies. You have the same dependencies in each package. You have a TON of wasted space with packages that have the exact same built-in libraries and jar files. Especially with Android, they could have made a real package dependency system, with slotted installs of all the jar/jar-versions from the official maven repos. When you install and app, it could install all its dependent jars. You'd still be able to do multiple versions of each of those jars, probably easier than it is with standard .so/.dll libraries. Projects like this are a huge step backwards is terms of DRY principals and general package management.
- matzipan 11y ago
  Is space really an issue in most non-mobile user devices nowadays? Consider the tradeoffs: a bit of space vs. packaging nightmare which results in old, buggy and insecure packages. This was posted a few days back on hn: https://statuscode.ch/2016/02/distribution-packages-considered-insecure/ https://statuscode.ch/2016/02/distribution-packages-consider... I am not sure if the whole jar package dependency management would work under ART.
  - veddan 11y ago

nailer 11y ago

We use HTML5 clipboard and webcrypto and frequently get support requests from Linux users with outdated versions of supposedly 'evergreen' browsers.

rythie 11y ago

Not everyone has root on their Linux box and even if you do, you ought to be able to install applications as you without sudo'ing anything. Right now most Linux applications guide you to a deb/rpm which runs as root (and who knows if you can trust it). TBH this is just the start of making applications more secure, they ought to be sandboxed too, so one application can't read the data from another application by default (similar to how phones work).

matzipan 11y ago
I believe Ubuntu has done a some progress in this area with Snap packages.
jonotime 11y ago
There's also NIX, which I think does a good job of issolation in user space. https://nixos.org/nix/ https://nixos.org/nix/
michaelmrose 11y ago
You actually cannot make malicious applications safe you can however make nonmalicious applications inconvenient.
jhasse 11y ago
GNOME is working on it: https://wiki.gnome.org/Projects/SandboxedApps https://wiki.gnome.org/Projects/SandboxedApps
- michaelmrose 11y ago
  You can make it slightly harder to infect the rest of the system leaving the factual truth that the moment you install malware you are hosed unchanged
chmike 11y ago
Wouldn't this raise the issue of application updates ? If the app imports its own libraries, who will take care to update them if a security issue is detected ? That's the point to enforce using shared libraries on unix system.

hasenj 11y ago

Yea I never understood why there's no separation between these two. The fact that apt-get needs root password only makes sense if apt-get is meant for system packages. User applications should not require root privileges to install.

michaelmrose 11y ago
Installers regularly install packages to system dir because it would be idiotic on a multi user system for each user to install different versions of Firefox to their home dir. It also serves to keep unprivileged users from installing software. You are free to install software to your home but it shouldn't be the default behavior
- hasenj 11y ago
  The overwhelming use case for desktop users is there's usually one user on the system.
  - michaelmrose 11y ago
    Which is not a good reason to design anything based on that assumption it's extremely easy for a single user to use a multi user system but not the reverse.

toyg 11y ago

> preferably with two different managers. That's overcomplicating things. The "user" manager would have to figure out where the specific distribution is storing this or that lib. Doing it reliably across even a small subset of distributions (say, Ubuntu, Debian, Fedora and RedHat) and a small subset of their releases, would be very challenging. It would make much more sense to add a "user mode" option for the likes of apt-get, whereby it does not need sudo and it will install the specified package in ~/bin, ~/usr etc, symlinking necessary libraries. That doesn't seem too hard to pull off, in theory.

pdonis 11y ago
> It would make much more sense to add a "user mode" option for the likes of apt-get, whereby it does not need sudo and it will install the specified package in ~/bin, ~/usr etc, symlinking necessary libraries. And then any random piece of malware running in your browser can in principle hose all your applications. There's a very good reason that ordinary users do not have write access to application binaries on Linux.
- toyg 11y ago
  It would hose only your "usermode" apps, which would be a small subset -- likely smaller unpopular apps that lag in the distro repository. The system as a whole would remain intact, so you can logoff and clean up the mess as root. What hack would rely on some specific app being deployed in user-mode anyway? To do what, steal user files it already has access to? It's obvious that "usermode" should be the exception and not the norm, but from a security standpoint it's exactly the same as compiling and installing with custom prefixes.
  - deleted 11y ago
    [deleted]
  - pdonis 11y ago
    > It would hose only your "usermode" apps, which would be a small subset Until more and more user apps start to get out of sync with the "system" versions of things, and therefore need to be installed with the "user" option in order to work. > What hack would rely on some specific app being deployed in user-mode anyway? A hack that doesn't care about specific apps but just wants to compromise whatever it can. Like, you know, a virus. > To do what, steal user files it already has access to? And send them to the Internet, without your knowledge. Like viruses already do--only it's a lot harder to get them to run on Linux. At least, it is now.

riquito 11y ago

If you don't share common dependencies you're doomed to have security hazards. Consider it this way: if you install package FOO with its dependencies A,B and C, and FOO's developer thinks it's "feature complete", the package will never be updated, but every time a vulnerability is disclosed in his dependencies you'll be it. For _every_ program maintained this way.

matzipan 11y ago
My argument is that you'd have cross-distribution appimage maintainers who would press a button and rerun the build script with the new library if it's needed.
- cben 11y ago
  So appimage becomes yet another distro? (with the somewhat unique property that you can overlay it over other distros)
  - matzipan 11y ago
    More like app ecosystem.