Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I know - however these things are seldom demarcated on merit and more on ideology.

I wish the next generation of linux has a single package manager :(



> I wish the next generation of linux has a single package manager :(

Package management used to be my biggest frustration with computers. A couple years ago, I switched to nix [1][2] and now use it across all my unix-like systems (not sure how well it works on Windows, I haven't tried). Most under-rated piece of software I use, I'm surprised it hasn't blown up yet.

[1] http://nixos.org/nix/ [2] https://news.ycombinator.com/item?id=10714102


i have the greatest of respect for nix and 0install - however its an inexorable fact that I would like a mainstream, fully supported OS on my desktop - which is either Fedora or Ubuntu.

Let me flip this question - what does nix have that snap or flatpak does not ? From what I have read, they are pretty much the same.


I run Ubuntu primarily, and forgo apt-get in favor of nix. I've never run NixOS before (some day..).

I haven't used flatpak or snap before, but the comment I linked outlines a lot of the benefits I see with nix. Conceptually it's more like Make + a package manager, if Make were a (well designed) pure functional language and wasn't afflicted with grotesque generated code.


I think in case of Snap, it is part of money making server business. So it is less likely Canonical is going to give up on that.


(Disclaimer: I don't work for Canonical, I just use Ubuntu for my work.) I think it will end up like so:

* apt/dpkg will remain the base packaging software on desktop and server. They're well-tested and familiar.

* flatpak will become the primary format for installing desktop software outside of repo. This'll be nice for some large open-source projects that cause grief for distro packagers, and will also give companies a single target for major Linux desktops. Flatpak is too narrowly-targeted to replace snap in all cases snap was designed for.

* snap will become a mechanism for image-based application deployment, primarily IoT.

* docker/lxd/whatever will be used to target immutable deployments, primarily servers.


But then you're competing with Docker images. Not that Docker is that amazing, but I just don't see why anyone would want to use Snap instead of Docker?


I am not sure e.g. how docker image is better for openoffice or eclipse/intellij idea and so on for desktop. I think Snap fits usecase much better. May be multiple snaps combined to create a service/image for a server.


Containers are for a completely different use case than system packages.


CoreOS and RancherOS have shown how everything can either be built into the base OS image or running in Docker, with no system packages needed.


I think this had been shown somewhat before the time of these whippersnapper distros (Slackware, LFS etc), indeed before the days of RPM, make && make install directly on production servers were how things were done.. and it was not good.

Also; in the case of CoreOS, the base image is still built using a package manager (portage). Not sure about that other guy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: