> Canonical, stop trying to be Apple, please.

I love that they try to be Apple, before them only Mandrake and SuSE cared for what actually matters to desktop users.

As for "yet-another-bifurcation of OSS solutions", that is the nature of the game.

Isn't that what so many praise about FOSS?

Welcome to the UNIX wars, re-edited as GNU/Linux wars.

They have a serious case of NIH though. They put a lot into desktop linux but most of it seems to be a replication of effort.

I sympathize with them more than I used to. I attended a meeting of the Linux Standard Base working group back when systemd was truly awful compared to it's current state, and the main item on the agenda from employees of the other major Linux companies was how they were going to force Debian / Ubuntu to go along with systemd so LSB didn't have to shrink their scope or not apply to them. I no longer blame them for not wanting to play politics to be part of a community like that. I don't really like Ubuntu's style personally anymore, but for what they're trying to do, going with everyone else's solutions is probably a good thing to avoid.

Didn't Snap appear first? Why is FlatPak not an example of NIH?

Exactly. Snaps grew out of the work to make Ubuntu mobile phone apps secure and easy to update. They are a great way to publish software, worth creating regardless of all the anti-canonical trolling. And they work fine across distros except where RH has actively tried to cripple them. That's their right, but wow, toxic.

Snap is not vendor neutral - it has hard coded dependence on Canonical infrastructure. If you want to provide your own, tough luck.

Calling to attention about that is not anti-canonical trolling. It's avoiding creating a dependence on a third-party.

s/tough luck/patches welcome/

Patches here: https://github.com/flatpak/flatpak ;)

> RH has actively tried to cripple them

Source?

Snaps require AppArmor which is used by Ubuntu and openSUSE. This makes it harder to integrate Snaps into Red Had (SELinux) distros, but I wouldn't say that this is something RH does actively to cripple them.

Snaps need a security backend like AppArmor in order to run in confinement. Without it, they can still be run unconfined. And while AppArmor+seccomp is the only working security backend, snapd is designed to support alternate backends, so one could be made for SELinux, we just need someone with SELinux experience to write it (our in-house expertise is in AppArmor)

It is rare to see something come out of Fedora that is not NIH.

As for all the mentioned package/image managers, IMO they all bring more problems then solutions (except maybe nix). Dependency resolution brings sloppiness and keeping the programs dependencies up to date would kill the internets and hard drives (compared to a normal package manager). They should just build a build bot and amen (or just not do anything). The only "problem" they solve is proprietary program distribution, and that is solved by a Filesystem Hierarchy Standard (and fd.o) compliant installer such as MojoSetup (as used by GoG).

Yeah, my worry is that when a vulnerability hits libc we have to download all the snaps again and the vulnerable libc is still there in the abandoned snaps. There are many other libraries used by many programs that would suffer from the same problem. I'm thinking about openssl.

Edit: somebody answered to my doubts in a comment here https://news.ycombinator.com/item?id=13559060

FlatPak is a rename of xdg-app, which is the successor of Glick2, which is the successor of Glick, which was released in 2007, all by the same author.

My impression is the other way around... ish. Canonical tends to release their own solution to problems that the broader community is trying to solve, but not fast enough for their liking. Hence Mir before Wayland, upstart before systemd, etc.

You could call the broader community's refusal to adopt the Canonical solution NIH too, but my view is more that Canonical's shipped - but usually inferior for non-Ubuntu users - solutions prompt the community to stop trying to perfect their version's architecture and just polish and release it already.

There are two ways this has played out over the last 13 years. a) Canonical develops an open source solution to a real problem but RH and others choose not to contribute or adopt (e.g. bzr, Launchpad, upstart, Mir, Unity, LXD, Juju, Snaps, et al.). Or b) Canonical adopts open source tech from RH or others and works hard to deliver it nicely for Ubuntu users (e.g. KVM, Compiz, systemd, Ceph, etc.). Either way, inevitably Canonical is perceived as evil by an unweilding segment of the tech community, for either not adopting RH's solution or not contributing enough to RH's solution. How much should Canonical care about the unreasonable opinions of a handful of noisy Fedora fans?

How is it that Canonical is accused of NIH, but literally NO ONE ELSE IS?

Because Mir.

And upstart maybe. And Unity.

Because they have their own stuff and no one else has, roughly speaking (there's no Fedora desktop environment, no RedHat init system, okay, now there's systemd, but that's seen as Lennart's not RH's, or whatever).

Also, it's mostly noise, don't take it too seriously.

Newsflash: Canonical want the 'desktop' to die.

"Snaps are Canonical's choice for "cross distro" package management that they are trying to force on everyone else."

How are they trying to force it on anyone?

I understand that there is a Canonical / Red Hat rivalry. But I think language like this adds more heat than light to the discussion which should really be about the merits of the different solutions.

They supposedly put words into Red Hat's mouth by saying Snappy had support it clearly didn't have.

This is not what I expect to read on HN. Take your anti-Ubuntu zealotry elsewhere.

> it uses a Git-like distribution system that's specifically built for operating system size snapshots. You get to pick your underlying distribution (or roll your own) and the sandboxing mechanism just wraps around secomp-bfp so it stacks well with SELinux or AppArmor or whatever.

Is security compatibility the primary advantage over docker? When I see these I always think, why not docker? Git like distribution, pick underlying / roll your own. I'm not sure why these are better than a docker or rkt.

Docker doesn't work for desktop gui apps. Also it doesn't provide great security sandboxing. Also docker is not the first containerisation solution why not LXC?

> why not LXC

The git-like version control available with docker or rkt (and apparently these package manager based systems too).

It works for GUI apps, see eg. https://hub.docker.com/r/tomparys/skype/

OK but now you've forwarded your x you're not really containing the gui app very strongly anymore.

Docker doesn't support user namespaces properly so this is the situation anyway. Good reason to use LXD - or to run Docker under LXD[1] :)

[1] https://insights.ubuntu.com/2016/04/13/stephane-graber-lxd-2...

It was far too laggy for real use when I tried with Firefox a couple of months ago.

That might be XQuartz's fault rather than Docker's - I only tried on macOS.

X11 only, no Wayland :-/

I understand that Canonical proposes Snaps as a standard, but can you be specific about how they are trying to force it on everyone else?

Competition between every one of those projects have made each of them better.

Having tried Elementary OS, various versions of Fedora, Suse, and even Mageia and Bodhi (e17 desktop), I have never found a compelling story away from Ubuntu's overwhelming advantage in online resources for non-greybeards like me. Last night, compiling mesa, with all the weirdo dependencies, this was brought home to me as half the time as I typed in an obscure package that I had to find, Google was autocompleting it with "ubuntu" appended on it. Says it all. And in my mind, snap is already gaining massively more mind-share than flatpak and everything else and that's why it's almost certain to win. And that's a good thing. It's good because Ubuntu does desktop awareness better than anyone else, in my opinion, and of course, half the battle is community building. Not just the tech.

That said, I will hand it to Fedora on ARM, where I use it quite extensively on dev boards.