Basically, Ubuntu phones were using click packages (predecessor to snaps) back in 2011 and 2012, with snapcraft shipped in January 2013, whereas xdg-app (later renamed to Flatpak) was started in December 2014.
Another thing to consider is that Canonical is orders of magnitude smaller than RedHat, and they do have a problem getting the community involved, but part of that is the size and limited time their developers have.
Now, even as a long time Ubuntu fan, I'll probably be switching to Debian just because I dislike the snap upgrade model.
Basically, Canonical will start at a project first, but RedHat specifically will look for ways to not join them, and start their own project instead.
Part of that is certainly due to Canonical itself, but I can't help but think a lot of it is RH making a call and then throwing more developers at something.
Canonical has quite a history of the behavior you're dinging Red Hat for: Mir, Unity, LXD, Juju/Charms, Launchpad, and I'm sure I'm forgetting several.
Also it’s Orwellianly named “Harmony” effort to popularize CLAs because Canonical has long sought to control upstream technologies - and consistently failed because they do not play well with others.
Though I don't think CLAs are a problem (FSF requires them for GNU projects too), but lack of committment not to switch to a non-free license.
Unity happened as GNOME 3.0 already went in an entirely different direction (mostly led by RH engineers) from 2.x series and as Canonical simply couldn't influence GNOME design. With a paradigm shift one way or another, it was a sensible move.
Launchpad was created as a tool to develop Ubuntu and free software: there was nothing else (and there still isn't) quite like it. Sure, it took a while to get it open sourced, but lack of contributions afterwards kinda proved the point that that wasn't really important (I mean, GitHub wasn't and still isn't).
Mir/LXD/Juju were attempts to improve on the incumbents (Wayland/Docker mostly).
Read this thread:
https://web.archive.org/web/20140928104327/https://plus.goog...
Here, Upstart author and former Canonical employee Scott James Remnant wrote:
Had the CLA not been in place, the result of the LF Collab discussions would have almost certainly been contributions of patches from +Kay Sievers and Lennart (after all, we'd all worked together on things like udev, and got along) that would have fixed all those design issues, etc.
But the CLA prevented them from doing that (I won't sign the CLA myself, which is one reason I don't contribute since leaving Canonical - so I hold no grudges here), so history happened differently. After our April 2010 meeting, Lennart went away and wrote systemd, which was released in July 2010 if memory serves.
You can use any container registry (including self hosted) with docker and it will work. Last I checked, you cannot use any other repo at all with snap without recompling it to add support for your snap repo.
IOW, if RH wanted to "join in", there was a cheaper path forward.
https://en.wikipedia.org/wiki/Snap_(software)
So I don't see how RedHat or any other FOSS distributor could have been happy with Snaps.
A tiny inconsequential part. The bigger one is their refusal to give a shit about usage outside of Ubuntu with Canonical-controlled servers and their insistence on CLAs. Canonical has noone but themselves to blame for Red Hat to continously win the community for their solutions even when they were late to the party.
https://web.archive.org/web/20071012194830/http://www.gnome....
There was also glick2 in 2011.
https://web.archive.org/web/20111022070435/http://people.gno...
You may have heard of Alex Larsson as author of xdg-app.
I think the oldest related project was Klik, started in 2004 (and later renamed to AppImage).
This is his blog about the history of Flatpak.
https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/
Also, the reason why Canonical have "a problem getting the community involved" is that they put a KEEP OUT sign on every one of their projects in the form of a CLA requiring copyright assignment.
This. Also bzr. They seem to want to control their projects completely and so even when they have good tech they lose out to more open, community developed, equivalents that build wide engagement and momentum.
I honestly don't understand it, you would have thought they would have learned by now that they don't have the engineering resources to do everything by themselves.
Compare that to Red Hat who always try (and sometimes even succeed!) at developing projects with the community and are far more successful at getting their projects adopted (I know people don't like them, but you cant deny they are effective at it)
Bzr "lost" because git had GitHub, whereas Launchpad was one too many things and slow to optimize for modern sensibilities.
(And Linux used a different VCS before git, so that didn't matter in adoption)
Imagine a world without GitHub, and I don't think git would be our go-to VCS. Though maybe not even Baazaar, but there are things like Mercurial too.
In GNOME, a decision was delayed and bzr and git were pretty evenly matched.
Linux has previously used BitKeeper, but that didn't make it "win out", just like it didn't do so for Git. Sure, it wouldn't have existed if there wasn't a need for Linux.
I am only pointing out that it was GitHub that helped popularize arguably the worst UX among DVCSes: I don't hear people say "your free software contributions portfolio" — they'll just say "your GitHub profile".
For my own sanity I began avoiding Canonical's software years ago, but to me they always built stuff with shiny UI that demoed well but with performance seemingly a distant afterthought. Their software aspirations always seemed much larger than the engineering resources/chops/time they were willing to invest.
The question then becomes: why not Mercurial which still had a better UX than git itself?
My point is that git won because of GitHub, despite lots of suckiness that remains to this day (it obviously has good things as well).
I'm struggling to find a way to characterize the difference between Red Hat/IBM and canonical's approach to the community. The most succinct I can come up with is that canonical releases projects and assumes that they are the one responsible for their creation., Red Hat releases rough ideas and code. There also seems to be a heavy political/disinformation campaign going on tearing down any solutions by canonical.
In either case, none of us can resolve the conflict. It's a pissing contest between canonical and IBM/Red Hat. I will keep choosing solutions that let me get my job done and get paid which is all that matters.
I think you're right that Canonical creates and releases projects and assumes they are in charge of them, but I disagree about Red Hat (honestly not sure what you mean by "rough ideas and code"), I think they tend to see whats already out there and then throw their weight behind that, then only if there isn't do they create their own and even then they are more open about how the project runs. That difference means Red Hat gets more momentum behind its projects, and that is what counts. (of course RH can throw more engineers at stuff as well, and that also helps a lot)
Its not some sort of conspiracy, nothing Canonical has ever done has had the same amount of hate as systemd has, its just a difference in approach.
My experience with Red Hat is that it's frequently IKEA level assembly required. Canonical projects tend to be read the docs and just use it. Although there are some exceptions. For example a couple of years ago, cloud-init was not documented well enough for my taste. Took a second look just now and found new documentation that may revise my opinion.
Or rather because they're proprietary, often closed-source, like Snap server.
The simple answer is that the company culture really, really wants to be "the Apple of Linux", with all that it entails. Whereas RedHat wants to be the Linux of Linux, they've learnt how the opensource game really works and they play it every day.
What distribution doesn't support at least half a dozen desktop environments these days?
Most usually come out of the box with official support for only 2 DEs. Of course they can theoretically support every one out there if you manually install them.
- Gnome
- KDE
- Xfce
- Cinnamon
- Mate
- LXDE/LXQt
- Several *box stacked and assorted tiling window managers and assorted glue scripts
That's a fairly solid base of "support" even if the distributions don't provide live CDs with any particular setup preinstalled.
The only exception I've seen are the "we took an existing distro, threw away half the repository, patched 2 packages and slapped our own logo on top" wannabe hipster distributions that last an entire two years before folding due to being pointless.
It's as simple as
apt-get install $DEAlso, having multiple DEs in parallels rarely plays well with most distros. That's why they usually give you a downloads with one or two options already setup and tested.
Using apt, yum, pacman or the equivalent is still just a single command. Your implication that "manual installation" is extra work when it is a single command on all the desktop distros.
Saying that "executing a single command" is too much manual work is simply delusional.
> Also, having multiple DEs in parallels rarely plays well with most distros.
Nonsense. I'm currently running Plasma, which was not the default. I've installed so many in the past on this machine that I lost track of them.
I've switched DEs and window managers multiples on this machine, with no problems.
Through nix-env it even already has the idea (albeit discouraged) of imperative package management like apt.
Having spent a while with NixOS, running containers for user applications seems like using a cannon to kill a fly. The 'simple' alternative is to drop FHS altogether - which containerization is kind of doing in a roundabout way by isolating the app filesystem from system fhs.
As for it being for developers only... I get that perspective. Debian/Ubuntu packaging is also hard, AUR packaging has its quirks. A lot of this is hidden behind the package manager, wheras with NixOS it is more obvious.
The killer idea for NixOS would be to make package management for Joe Q Public as easy to use as apt while. Tools like MyNixOS[1] are emerging which might bridge that gap.
When there's a package manager / runtime that does both then I'm extremely interested.
It looks... somewhat abandoned, but I'd wager it still works today. Failing that, setting up a shell alias to launch a regular binary in bubblewrap isn't too hard either.
But, I'm all for competition, long may it continue. The only real negative here is that some apps will only release Snaps, others will only release Flatpaks and people will end up having to just revert to copr/AUR like before.
Choosing a distro is basically choosing a DE and package manager these days anyway - a single unified packaging format that works everywhere is more frustrating than an alternative DE or windowing system.