4 ms·

To put things into context, snaps were created before flatpak: in a sense, RedHat wanted to go at it "alone" (or at least separately from Canonical) with xdg-ap

To put things into context, snaps were created before flatpak: in a sense, RedHat wanted to go at it "alone" (or at least separately from Canonical) with xdg-app/Flatpak. These ideas were already present even before those times and outside of both RH/Canonical, so it was more of a who's committed first. 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.

bantunes 4y ago
I thought flatpak was a response to Ubuntu not open-sourcing the snap store code.
- necovek 4y ago
  Sure, but I don't think it would have been much effort to build a snap store server with the client and package format open source. IOW, if RH wanted to "join in", there was a cheaper path forward.
  - toyg 4y ago
    You don't want to be a sharecropper; using a format you can't meaningfully influence for something as key as application installation, is an obvious non-starter for any serious distribution.
SSLy 4y ago
snap's original sin was the moat of server being closed source and client /really/ wanting to talk only to the Canonical's instance. The latter is shared by Docker, in a way.
- schmorptron 4y ago
  It's so upsetting that canonical will continually come up with cool tech, try to keep complete control over it and ideally make it so it long term becomes the only option, which people understandably don't jive with. Had they learned that in the space theyre in an open approach works better, we could still be using mir, upstart and most importantly unity now. God I miss unity.
- IceWreck 4y ago
  I dont use docker anymore (podman ftw) but that is unfair criticism of docker. 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.
  - SSLy 4y ago
    By "in a way" I've meant the encroachment of the default namespace. Much less smaller sin than snap's, but then docker is much bigger.
necovek 4y ago
And lets not forget an even more prominent example: Upstart by Canonical that RedHat replaced with Systemd. 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.
- jzb 4y ago
  Upstart’s CLA was a non-starter. 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.
  - BossingAround 4y ago
    Just to add to those wondering, CLA = Contributor License Agreement.
    - jzb 4y ago
      Ah, yes. Thank you - sorry for assuming on that one. I tend to get lazy when replying on my phone...
  - necovek 4y ago
    Sure, I have acknowledged there are plenty of missteps by Canonical too. 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).
esarbe 4y ago
Isn't the server software proprietary? https://en.wikipedia.org/wiki/Snap_(software) 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.
fanatic2pope 4y ago
Flatpak development actually started much earlier than that. The first version happened in 2007 when it was known as "Glick". https://github.com/flatpak/flatpak/wiki/Flatpak's-History https://github.com/flatpak/flatpak/wiki/Flatpak's-History
- account42 4y ago
  And AppImage was already a thing in 2004. To bad that everyone has to reinvent the wheel when it comes to packaging instead of building on the existing solutions.
account42 4y ago
> they do have a problem getting the community involved, but part of that is the size and limited time their developers have. 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.
the_why_of_y 4y ago
Click was preceded by Alex Larsson's glick project, see this page from October 2007. https://web.archive.org/web/20071012194830/http://www.gnome.org/~alexl/glick/ https://web.archive.org/web/20071012194830/http://www.gnome.... There was also glick2 in 2011. https://web.archive.org/web/20111022070435/http://people.gnome.org/~alexl/glick2/ 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/ 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.

bantunes 4y ago

I thought flatpak was a response to Ubuntu not open-sourcing the snap store code.

necovek 4y ago
Sure, but I don't think it would have been much effort to build a snap store server with the client and package format open source. IOW, if RH wanted to "join in", there was a cheaper path forward.
- toyg 4y ago
  You don't want to be a sharecropper; using a format you can't meaningfully influence for something as key as application installation, is an obvious non-starter for any serious distribution.

SSLy 4y ago

snap's original sin was the moat of server being closed source and client /really/ wanting to talk only to the Canonical's instance. The latter is shared by Docker, in a way.

schmorptron 4y ago
It's so upsetting that canonical will continually come up with cool tech, try to keep complete control over it and ideally make it so it long term becomes the only option, which people understandably don't jive with. Had they learned that in the space theyre in an open approach works better, we could still be using mir, upstart and most importantly unity now. God I miss unity.
IceWreck 4y ago
I dont use docker anymore (podman ftw) but that is unfair criticism of docker. 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.
- SSLy 4y ago
  By "in a way" I've meant the encroachment of the default namespace. Much less smaller sin than snap's, but then docker is much bigger.

necovek 4y ago

And lets not forget an even more prominent example: Upstart by Canonical that RedHat replaced with Systemd. 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.

jzb 4y ago
Upstart’s CLA was a non-starter. 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.
- BossingAround 4y ago
  Just to add to those wondering, CLA = Contributor License Agreement.
  - jzb 4y ago
    Ah, yes. Thank you - sorry for assuming on that one. I tend to get lazy when replying on my phone...
- necovek 4y ago
  Sure, I have acknowledged there are plenty of missteps by Canonical too. 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).

esarbe 4y ago

Isn't the server software proprietary? https://en.wikipedia.org/wiki/Snap_(software) 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.

fanatic2pope 4y ago

Flatpak development actually started much earlier than that. The first version happened in 2007 when it was known as "Glick". https://github.com/flatpak/flatpak/wiki/Flatpak's-History https://github.com/flatpak/flatpak/wiki/Flatpak's-History

account42 4y ago
And AppImage was already a thing in 2004. To bad that everyone has to reinvent the wheel when it comes to packaging instead of building on the existing solutions.

account42 4y ago

> they do have a problem getting the community involved, but part of that is the size and limited time their developers have. 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.

the_why_of_y 4y ago

Click was preceded by Alex Larsson's glick project, see this page from October 2007. https://web.archive.org/web/20071012194830/http://www.gnome.org/~alexl/glick/ https://web.archive.org/web/20071012194830/http://www.gnome.... There was also glick2 in 2011. https://web.archive.org/web/20111022070435/http://people.gnome.org/~alexl/glick2/ 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/ 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.