6 ms·

Will there ever be a desktop version of Ubuntu with snappy ? Snappy seems to have some very interesting advantages..

baldfat 12y ago
I have been saying that Linux traditional package management is out dated and needs to be re-invented. Why do we need to share all the libraries? Shouldn't most of them be self contained? Can't we just intall into a directory and uninstall by removing a directory? Sounds a lot like containers to me but simpler and not virtual. So maybe we can see a systemd packagemanagement system :) Just kidding but hmmmm.
- vinay427 12y ago
  While I think it's FAR better than anything Windows or Mac have come out with (both are entirely closed to corporate approval with no alternative repositories), I would want to see more unification between distros in terms of package managers. Right now, only source files seem to be consistent, with different package managers requiring different dependencies for every package, despite large environments such as GNOME which provide a consistent experience on any distro. With divergent systems such as Ubuntu's PPAs this seems less likely, but I'm not very qualified to comment. Perhaps someone else knows more on the possibility of this? Are distros still too different under the rug?
  - pyre 12y ago
    > Are distros still too different under the rug? Yes and no. You could probably make a packaging system that could handle multiple distros cleanly, but then the package maintainer would need to maintain said package on all of those distros.
    - derefr 12y ago
      And that's just third-party vendor packages. The real problem comes with people thinking that "these two distros both use [package standard] so I can take a system package only provided on one, and just install it on the other!" The difference between the world of RPMs and the world of DEBs isn't really the package format standard; if that was the only problem, it would have been solved long ago. It's that, hiding behind RPM and DEB, there are two separate package dependency graphs shared by all the distros that make use of either. They don't have names, but effectively they're "the Debian dependency graph" and "the Fedora dependency graph." All derivative OSes that keep packages updated from "upstream" (like e.g. Ubuntu does with Debian) are forced into the upstream's dependency graph. If Debian packages X.org split into three packages and makes everything graphical depend on one of them, then if Ubuntu wants to ship the "upstream" version of any of those graphical programs, it has to also ship the upstream version of X.org (or, at least, a virtual package that has the same name as the one of the three that those packages depend on, and hope that the package doesn't actually depend, implicitly, on any of X.org's own Debian-specific dependencies that thusly won't be getting installed.) Which is all to say, if you want to unify package management, you're going to have to come up with one base set of packages everyone can agree to depend on. Or, at least, a graph of virtual packages that get fulfilled by different base packages on each OS. Otherwise, for now, it's actually handy to see .rpm and .deb on packages—it tells you whether the contents of the package are built for your dependency graph, or for the other one.
- vezzy-fnord 12y ago
  Can't we just intall into a directory and uninstall by removing a directory? https://en.wikipedia.org/wiki/Klik_%28packaging_method%29 https://en.wikipedia.org/wiki/Klik_%28packaging_method%29 https://www.slax.org/en/documentation.php https://www.slax.org/en/documentation.php More like an image, but close enough.
- wmf 12y ago
  You're kidding but they aren't: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu... xdg-app is similar but with less btrfs: https://wiki.gnome.org/Projects/SandboxedApps https://wiki.gnome.org/Projects/SandboxedApps
  - baldfat 12y ago
    1) I was kidding but I also thought this was possibly where some would want to take it. I personally would like to see something more Linux central and not systemd central. 2) I really like th idea of sandboxed apps. It was basically what I was saying except if there were some kind of git magic sauce in the middle of it that would be fantastic. Unfortunately I am thinking in terms of Desktop Linux and not Corporate settings with servers. Though servers really are moving into containers.
- rdtsc 12y ago
  Security updates and bloat are some reasons. If there is a serious bug in glibc a single OS update usually fixes it. If you installed 20 applications with their own statically or privately stashed (but still dynamically linked) glibc versions, unless you have an agreement with the app author/vendor it will be hard to maintain updates. This might not matter for consumer applications but in large environments (banks, DoD etc, this matters). Not saying I agree or advocate that way is better and nothing should be changed, I am just presenting what the typical arguments are.
- digi_owl 12y ago
  Meh, library sharing is not the problem. LD can easily figure out what version of a lib the binary wants. You don't need to go whole hog container to "fix" the issue. Look at distros like NixOS, Guix, or Gobolinux.
brlewis 12y ago
In the last paragraph of the article I don't see anything to indicate it won't be part of the desktop version. This new version of Ubuntu is also the first one to offer a stable version of Canonical’s Snappy Ubuntu Core, the company’s stripped-down version of its operating system for container hosts and small connected devices. You can read more about Snappy in our earlier coverage here.

I have been saying that Linux traditional package management is out dated and needs to be re-invented. Why do we need to share all the libraries? Shouldn't most of them be self contained? Can't we just intall into a directory and uninstall by removing a directory? Sounds a lot like containers to me but simpler and not virtual. So maybe we can see a systemd packagemanagement system :) Just kidding but hmmmm.

vinay427 12y ago
While I think it's FAR better than anything Windows or Mac have come out with (both are entirely closed to corporate approval with no alternative repositories), I would want to see more unification between distros in terms of package managers. Right now, only source files seem to be consistent, with different package managers requiring different dependencies for every package, despite large environments such as GNOME which provide a consistent experience on any distro. With divergent systems such as Ubuntu's PPAs this seems less likely, but I'm not very qualified to comment. Perhaps someone else knows more on the possibility of this? Are distros still too different under the rug?
- pyre 12y ago
  > Are distros still too different under the rug? Yes and no. You could probably make a packaging system that could handle multiple distros cleanly, but then the package maintainer would need to maintain said package on all of those distros.
  - derefr 12y ago
    And that's just third-party vendor packages. The real problem comes with people thinking that "these two distros both use [package standard] so I can take a system package only provided on one, and just install it on the other!" The difference between the world of RPMs and the world of DEBs isn't really the package format standard; if that was the only problem, it would have been solved long ago. It's that, hiding behind RPM and DEB, there are two separate package dependency graphs shared by all the distros that make use of either. They don't have names, but effectively they're "the Debian dependency graph" and "the Fedora dependency graph." All derivative OSes that keep packages updated from "upstream" (like e.g. Ubuntu does with Debian) are forced into the upstream's dependency graph. If Debian packages X.org split into three packages and makes everything graphical depend on one of them, then if Ubuntu wants to ship the "upstream" version of any of those graphical programs, it has to also ship the upstream version of X.org (or, at least, a virtual package that has the same name as the one of the three that those packages depend on, and hope that the package doesn't actually depend, implicitly, on any of X.org's own Debian-specific dependencies that thusly won't be getting installed.) Which is all to say, if you want to unify package management, you're going to have to come up with one base set of packages everyone can agree to depend on. Or, at least, a graph of virtual packages that get fulfilled by different base packages on each OS. Otherwise, for now, it's actually handy to see .rpm and .deb on packages—it tells you whether the contents of the package are built for your dependency graph, or for the other one.
vezzy-fnord 12y ago
Can't we just intall into a directory and uninstall by removing a directory? https://en.wikipedia.org/wiki/Klik_%28packaging_method%29 https://en.wikipedia.org/wiki/Klik_%28packaging_method%29 https://www.slax.org/en/documentation.php https://www.slax.org/en/documentation.php More like an image, but close enough.
wmf 12y ago
You're kidding but they aren't: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu... xdg-app is similar but with less btrfs: https://wiki.gnome.org/Projects/SandboxedApps https://wiki.gnome.org/Projects/SandboxedApps
- baldfat 12y ago
  1) I was kidding but I also thought this was possibly where some would want to take it. I personally would like to see something more Linux central and not systemd central. 2) I really like th idea of sandboxed apps. It was basically what I was saying except if there were some kind of git magic sauce in the middle of it that would be fantastic. Unfortunately I am thinking in terms of Desktop Linux and not Corporate settings with servers. Though servers really are moving into containers.
rdtsc 12y ago
Security updates and bloat are some reasons. If there is a serious bug in glibc a single OS update usually fixes it. If you installed 20 applications with their own statically or privately stashed (but still dynamically linked) glibc versions, unless you have an agreement with the app author/vendor it will be hard to maintain updates. This might not matter for consumer applications but in large environments (banks, DoD etc, this matters). Not saying I agree or advocate that way is better and nothing should be changed, I am just presenting what the typical arguments are.
digi_owl 12y ago
Meh, library sharing is not the problem. LD can easily figure out what version of a lib the binary wants. You don't need to go whole hog container to "fix" the issue. Look at distros like NixOS, Guix, or Gobolinux.

brlewis 12y ago

In the last paragraph of the article I don't see anything to indicate it won't be part of the desktop version. This new version of Ubuntu is also the first one to offer a stable version of Canonical’s Snappy Ubuntu Core, the company’s stripped-down version of its operating system for container hosts and small connected devices. You can read more about Snappy in our earlier coverage here.