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

I always had problems with both of them. I use Docker a lot and Flatpak/Snap are intended to be a type of Docker for desktop apps. I know with Flatpak it has some shims to integrate with your system UI libraries so themes try to match up, but there are issues with that too (and flatpak apps just not starting up half the time).

I really hate Snap/Flatpak conceptually. Use the package manager. That's what it's there for. FPM is a way to make package building easier.

Snap/Flat tools feel like they're about the same as Electron cancer; and I bet we'll see more closed source commercial stuff pushed to the Linux world via them as well.



Flatpak is marketed as a better Snap (it surely has some advantages: no vendor lockdown), but at the end of the day, the system integration is not that good, I tried to use the Flatpak of Wireshark back in the day when I tried Fedora Silverblue, I ended up regretting that experiment.


> a type of Docker for desktop apps

By the way, what is it with Docker that makes it hard or impossible for it to be used for this exact purpose?


Desktop apps are not designed to operate in isolated fs namespace/network/etc from the host. So the user experience won't be seamless unless there are standards that enable desktop apps to be aware of how they are dockerized. Which there aren't afaik


It's not that hard. I remember using it to run Slack at one point, and while it wasn't easy it's definitely possible if you need it bad enough.


Docker is poorly designed as well.


can you elaborate? I can google for "docker sucks" blogposts, but I trust the HN opinion to be a bit more thoughtful. Any specific pain points you can identify?


The most commonly mentioned flaw was/is the root daemon. That can be worked around with other tools. The command line and docker files are a bit clumsy as well. Many images have security flaws. It didn’t clean up after itself for a looong time, etc.

It doesn’t “suck,” and many of the ideas are compelling. But, the design and implementations could be better. I was interested in rkt until it was acqui-abandoned.


I think what the author wanted to say is that the tradeoffs made by Docker's authors are different than those he would have made.




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

Search: