Wow. This headline doesn’t really cover the entirety of what’s going on. In short, Canonical is slowly bending towards the whim of properitary vendors in order to get them some sense of ‘safety’ when bringing their content to Linux users while also making it nigh impossible for downstream users to trust anything that’s put out. And, of course, actual federation becomes a farce.
Canonical is trying to force desktop Ubuntu into Windows 10 with this Microsoft Store-itization of snap. Wow, wow, wow.
Browsers are pretty much already “bundled” and exist outside the traditional distribution model. Pretty much all stable distributions have to take upstream changes wholesale (including features, security fixes and bug fixes) and no longer cherry-pick just security fixes. The packaging of browsers as snaps are merely admitting that truth.
The chromium-browser deb is a transitional package so that users who are upgrading don’t get a removed Chromium. It is done this way for this engineering reason - not a political one. The only (part) political choices here are to ship Chromium as a snap and no longer spend the effort in maintaining packaging of Chromium as a deb. Background on that decision is here: https://discourse.ubuntu.com/t/intent-to-provide-chromium-as-a-snap-only/5987
Ubuntu continues to use the traditional apt/deb model for nearly everything in Ubuntu. Snaps are intended to replace the use case that PPAs and third party apt repositories are used for, and anything else that is already shipped “bundled”. For regular packages that don’t have any special difficulties packaging with the traditional model, I’m not aware of any efforts to move them to snaps. If you want to never use snaps, then you can configure apt to never install snapd and it won’t.
Free Software that is published to the Snap Store is typically done with a git repository available so it is entirely possible for others to rebuild with modifications if they wish. This isn’t the case for proprietary software in the Snap Store, of course. The two are distinguished by licensing metadata provided (proprietary software is clearly marked as “Proprietary”). This is exactly the same as how third party apt repositories work - source packages might be provided by the third party, or they might not.
Anyone can publish anything to the Snap Store, including a fork of an existing package using a different name. There’s no censorship gate, though misleading or illegal content can be expected to be removed, of course. Normally new publications to the Snap Store are fully automated.
The generally cited reason for the Snap Store server-end not being open is that it is extensively integrated in deployment with Launchpad and other deployed server-end components, that opening it would be considerable work, that Canonical spent that effort when the same criticism was made of Launchpad, but that effort was wasted because GitHub (proprietary) took over as a Free Software hosting space instead, and nobody stood up a separate Launchpad instance anyway even after it was opened, so Canonical will not waste that effort again.
The generally cited reason for the design of snapd supporting only one store is that store fragmentation is bad.
I hope that sheds some clarity on what is going on. I tried to stick to the facts and avoided loading the above with opinion.
Opinion: Ubuntu has always been about making a bunch of default choices. One choice Ubuntu has made in 20.04 is that snaps are better for users than third party apt repositories (because the former run in a sandbox and can be removed cleanly; the latter is giving third parties root on your system and typically break the system such that future release upgrades fail). Some critics complain that users aren’t being asked before the Chromium snap is installed. But that would be a political choice. Ubuntu is aimed at users who don’t care about packaging implementation details and just want the system to do something reasonable. Ubuntu’s position is that snaps are reasonable. So it follows that Chromium packaging should be adjusted to what Ubuntu considers the best choice, and that’s what it’s doing.
Disclosure: I work for Canonical, but not in the areas related to Mint’s grievances and my opinions presented here are my own and not of my employer.
The chromium-browser deb is a transitional package
I can’t speak about Mint, but in Ubuntu the chromium-browser deb installs Chromium as a snap behind the scenes.
The generally cited reason for the Snap Store server-end not being open is that it is extensively integrated in deployment with Launchpad and other deployed server-end components, that opening it would be considerable work, that Canonical spent that effort when the same criticism was made of Launchpad, but that effort was wasted because GitHub (proprietary) took over as a Free Software hosting space instead, and nobody stood up a separate Launchpad instance anyway even after it was opened, so Canonical will not waste that effort again.
So, unless you’ll own the market with the product it’s not worth open sourcing? IMO releasing a product open source is never “wasted effort” because it may prove useful in some capacity whether you as the original author know it or not. It may spawn other ideas, provide useful components, be used in learning, the list goes on and on.
IMO releasing a product open source is never “wasted effort”
It’s very convenient to have this opinion when it’s not you making the effort. People seem to care a lot about “providing choice” but it somehow almost always translates into “someone has to provide choice for me”.
It’s very convenient to have this opinion when it’s not you making the effort.
True. I should have worded that better. I was talking about the case of simply making source available, not all the added effort to create a community, and make a “product”, etc. I still don’t believe companies like Canonical have much a leg to stand on when arguing that certain products shouldn’t be open source when open source is kinda their entire thing and something they speak pretty heavily on.
Yep. Just to be clear, open-sourcing code isn’t free. At an absolutely bare minimum, you need to make sure you don’t have anything hardcoded about your infra, but you’ll actually get massive flak if you don’t also have documentation on how to run it, proper installation and operation manuals for major platforms, appropriate configuration knobs for things people might reasonably want to configure, probably want development to happen fully in the open (which in practice usually means GitHub), etc.—even if you yourself don’t need or want any of these things outside your native use case. I’ve twice been at a company that did source dumps and got screamed at because that “wasn’t really open-source.” Not that I really disagree, but if that wasn’t, then releasing things open-source is not trivial and can indeed very much be wasted effort.
That’s true, but that cost is vastly reduced when you’re building a new product from scratch. Making sure you’re not hardcoding anything, for example, is much easier because you can have that goal in mind as you’re writing the software as opposed to the case where you’re retroactively auditing your codebase. Plus, things like documentation can only help your internal team. (I understand that when you’re trying to get an MVP out the door docs aren’t a priority, but we’re well past the MVP stage at this point.)
If the Snap Store was older I would totally understand this reasoning. But Canonical, a company built on free and open source software, really should’ve known that people were going to want the source code from the start, especially because of their experience with Launchpad. I think they could have found a middle ground and said look, here’s the installation and operation manuals we use on our own infra. We’d be happy to set up a place in our docs that adds instructions for other providers if community members figure that out, and if there’s a configuration knob missing that you need, we will carry those patches upstream. Then it would have been clear that Canonical is mostly interested in their own needs for the codebase, but they’re still willing to be reasonable and work with the community where it makes sense.
Opinion: Ubuntu has always been about making a bunch of default choices. One choice Ubuntu has made in 20.04 is that snaps are better for users than third party apt repositories (because the former run in a sandbox and can be removed cleanly; the latter is giving third parties root on your system and typically break the system such that future release upgrades fail).
I think this is a fine opinion but it seems contradicted by the fact that some packages are offered by both the off-the-shelf repos and snap.
I did say “better than third party apt repositories”. The distribution has no control over those, so what is or isn’t available in them does not affect my opinion. I’m just saying that Ubuntu has taken the position that snaps (when available) are preferable over packages from third party apt repositories (when available). And what is available through the distribution’s own apt repository is out of scope of my opinion statement.
Ubuntu has always been about making a bunch of default choices.
What is the default choice when I type jq in bash?
Command ‘jq’ not found, but can be install with:
sudo snap install jq # version 1.5+dfsg-1
sudo apt install jq # version 1.6-1
It’s fine and well opinionated choice that ubuntu prefers it for third party things. I feel like a lot of first party supported utilities are not well opinionated and i’m left thinking about trade-offs when i go with one over the other.
As somewhat of a fanboy, let me point out that Pop!_os has stayed clear of Snap since the start, although they haven’t spelled out their reasons very clearly (I think they just consider it clunky).
There are a number of aspects to this that seem strange to me.
Linux Mint is based on Ubuntu. That means they inherit the technical decisions upstream (Ubuntu) makes. Why not simply choose a different upstream distro if they’re not happy with such a foundational implementation decision on Ubuntu’s part?
Also, the way the whole decision and implementation of the ‘removal’ was handled feel very ham fist-ed and unprofessional to me. The folks at Canonical have said repeatedly that they would have been willing to work with Mint to enact this change in a less destructive way but were never given the opportunity.
The whole thing stinks like week old fish. Canonical doesn’t have to give Ubuntu away or allow it to be used as the base for all the various flavors and spins, they do because it’s in their DNA and many of them love the Linux community.
I am amazed at how Canonical always tries to make up their own technology instead of embracing existing open-source projects… and it NEVER works, and they keep trying it anyway. Let’s look at the list:
Upstart vs. systemd
Mir vs. Wayland
Snap vs. Flatpak
Unity vs. GNOME
Am I missing any? I feel like there’s more. Does anyone know why the hell they do this? Is it them and Red Hat having a technological pissing match that Red Hat usually wins (systemd and Flatpak come out of Red Hat after all)? Or do they just dream of making a de-facto standard that gives them lots of power, which this article seems to imply?
Either way, good on Mint for pushing back against this nonsense.
IMHO, what happens is that Canonical validates the existence of alternatives by beginning work, causing alternative efforts to start up or for existing alternative efforts to gain momentum. Then a certain vocal faction publicly trash Canonical’s efforts and try to swing the community towards one of the alternatives.
None of this is intended to diminish the value of the alternatives. Alternatives are good. They’ve always existed in the our ecosystem (eg. sendmail, qmail, postfix, exim; apache, nginx; etc). But in the case of a Canonical-led effort, a specific vocal crowd makes it political.
An exception is Unity vs. GNOME. That happened after GNOME didn’t want to follow Canonical’s design opinions on how the desktop should work (even though they represented the majority of GNOME desktop users!), and refused patches. But then, as above, politics happened anyway.
Author’s note: I use RedHat as a stand-in for the entire RedHat/CentOS/Fedora ecosystem a lot in this.
tl;dr Redhat is trying to address pain points for existing users, Ubuntu is going after new markets. Both are laudable goals, but Ubuntu’s strategy is riskier.
I think a lot of this comes down to market demand. With both the “Mir v Wayland” and “Unity v GNOME” RedHat and Canonical were both trying to address a market need.
With Wayland and GNOME, Redhat wanted a more modern display server and desktop environment so that it’s existing customers didn’t have to deal with the big ol’ security hole that is X. (Don’t get me wrong, I love X11 and still think it’s valuable, but I think RedHat’s market disagrees).
With Mir and Unity, Ubuntu wanted a display server and DE that would scale from a phone to a multi-monitor workstation. This is a laudable goal, and it did see a market need to address.
The difference is, Ubuntu was trying to address a market that it wanted while Redhat was trying to address the needs of a market that it actually had. Redhat has tons of customers actively using Wayland and GNOME for their intended purpose, and that gives a project momentum. Ubuntu also had loads of customers using Mir and Unity, but for only one of the multiple purposes that it was intended to be used for. Engineering always has trade-offs, designing a display server and DE for such a wide array of purposes is bound to have rough edges for any single one of those purposes. Ubuntu was asking it’s primary market, desktops and laptops, to suffer those rough edges for the greater Canonical purpose.
Even with snap v flatpak, again Ubuntu’s goals are much wider with snap than Redhat’s are with Flatpak, judging from what I’ve seen. Flatpak is a way for Redhat to distribute software to Linux/systemd in a way that’s more robust than the current RPM method, and Fedora is actively using flatpaks as a base to their Silverblue variant. whereas with snap, I think that Ubuntu wants to be the one stop shop for distributing software on Linux. Again: engineering, trade-offs, rough edges, etc.
The Redhat method of integrating the new package format seems to be coming up with an entirely different distribution to leverage flatpak functionality to it’s fullest while kinks are worked out . Canonical’s method seems to be: “Let’s shove it into our flagship product, and work out the kinks there”. This comes with a lot of inherent risks.
One quote I think is quite relevant to the current discussion:
“Some people claimed Bazaar did not have many community contributions, and was entirely developed inside of Canonical’s walled garden. The irony of that was that while it is true that a large part of Bazaar was written by Canonical employees, that was mostly because Canonical had been hiring people who were contributing to Bazaar - most of which would then ended up working on other code inside of Canonical.”
Note: Apparently Canonical’s solutions often are the forerunners and other people the copycats… I didn’t actually know that, thanks for the corrections. Frankly it makes the fact that their solutions tend to come out on the losing side even more interesting…
Canonical is taking risks by forcing snap onto his users. Two weeks ago, when an automatic chromium upgrade told me that chromium would switch to snap on my computer, didn’t let me the choice to refuse the new installation, and basically broke apt until I accept, I decided to change distribution.
The reason I’m not on Ubuntu anymore and probably won’t be back is only this one: I don’t want to have such change forced on me. This isn’t the linux way.
Wow. This headline doesn’t really cover the entirety of what’s going on. In short, Canonical is slowly bending towards the whim of properitary vendors in order to get them some sense of ‘safety’ when bringing their content to Linux users while also making it nigh impossible for downstream users to trust anything that’s put out. And, of course, actual federation becomes a farce.
Canonical is trying to force desktop Ubuntu into Windows 10 with this Microsoft Store-itization of
snap. Wow, wow, wow.[Comment removed by author]
Note that:
Browsers are pretty much already “bundled” and exist outside the traditional distribution model. Pretty much all stable distributions have to take upstream changes wholesale (including features, security fixes and bug fixes) and no longer cherry-pick just security fixes. The packaging of browsers as snaps are merely admitting that truth.
The
chromium-browserdeb is a transitional package so that users who are upgrading don’t get a removed Chromium. It is done this way for this engineering reason - not a political one. The only (part) political choices here are to ship Chromium as a snap and no longer spend the effort in maintaining packaging of Chromium as a deb. Background on that decision is here: https://discourse.ubuntu.com/t/intent-to-provide-chromium-as-a-snap-only/5987Ubuntu continues to use the traditional apt/deb model for nearly everything in Ubuntu. Snaps are intended to replace the use case that PPAs and third party apt repositories are used for, and anything else that is already shipped “bundled”. For regular packages that don’t have any special difficulties packaging with the traditional model, I’m not aware of any efforts to move them to snaps. If you want to never use snaps, then you can configure apt to never install snapd and it won’t.
Free Software that is published to the Snap Store is typically done with a git repository available so it is entirely possible for others to rebuild with modifications if they wish. This isn’t the case for proprietary software in the Snap Store, of course. The two are distinguished by licensing metadata provided (proprietary software is clearly marked as “Proprietary”). This is exactly the same as how third party apt repositories work - source packages might be provided by the third party, or they might not.
Anyone can publish anything to the Snap Store, including a fork of an existing package using a different name. There’s no censorship gate, though misleading or illegal content can be expected to be removed, of course. Normally new publications to the Snap Store are fully automated.
The generally cited reason for the Snap Store server-end not being open is that it is extensively integrated in deployment with Launchpad and other deployed server-end components, that opening it would be considerable work, that Canonical spent that effort when the same criticism was made of Launchpad, but that effort was wasted because GitHub (proprietary) took over as a Free Software hosting space instead, and nobody stood up a separate Launchpad instance anyway even after it was opened, so Canonical will not waste that effort again.
The generally cited reason for the design of snapd supporting only one store is that store fragmentation is bad.
I hope that sheds some clarity on what is going on. I tried to stick to the facts and avoided loading the above with opinion.
Disclosure: I work for Canonical, but not in the areas related to Mint’s grievances and my opinions presented here are my own and not of my employer.
Thanks a lot. While I don’t agree about the opinion at all, background explanation is much appreciated.
I can’t speak about Mint, but in Ubuntu the
chromium-browserdeb installs Chromium as a snap behind the scenes.So, unless you’ll own the market with the product it’s not worth open sourcing? IMO releasing a product open source is never “wasted effort” because it may prove useful in some capacity whether you as the original author know it or not. It may spawn other ideas, provide useful components, be used in learning, the list goes on and on.
It’s very convenient to have this opinion when it’s not you making the effort. People seem to care a lot about “providing choice” but it somehow almost always translates into “someone has to provide choice for me”.
True. I should have worded that better. I was talking about the case of simply making source available, not all the added effort to create a community, and make a “product”, etc. I still don’t believe companies like Canonical have much a leg to stand on when arguing that certain products shouldn’t be open source when open source is kinda their entire thing and something they speak pretty heavily on.
Yep. Just to be clear, open-sourcing code isn’t free. At an absolutely bare minimum, you need to make sure you don’t have anything hardcoded about your infra, but you’ll actually get massive flak if you don’t also have documentation on how to run it, proper installation and operation manuals for major platforms, appropriate configuration knobs for things people might reasonably want to configure, probably want development to happen fully in the open (which in practice usually means GitHub), etc.—even if you yourself don’t need or want any of these things outside your native use case. I’ve twice been at a company that did source dumps and got screamed at because that “wasn’t really open-source.” Not that I really disagree, but if that wasn’t, then releasing things open-source is not trivial and can indeed very much be wasted effort.
That’s true, but that cost is vastly reduced when you’re building a new product from scratch. Making sure you’re not hardcoding anything, for example, is much easier because you can have that goal in mind as you’re writing the software as opposed to the case where you’re retroactively auditing your codebase. Plus, things like documentation can only help your internal team. (I understand that when you’re trying to get an MVP out the door docs aren’t a priority, but we’re well past the MVP stage at this point.)
If the Snap Store was older I would totally understand this reasoning. But Canonical, a company built on free and open source software, really should’ve known that people were going to want the source code from the start, especially because of their experience with Launchpad. I think they could have found a middle ground and said look, here’s the installation and operation manuals we use on our own infra. We’d be happy to set up a place in our docs that adds instructions for other providers if community members figure that out, and if there’s a configuration knob missing that you need, we will carry those patches upstream. Then it would have been clear that Canonical is mostly interested in their own needs for the codebase, but they’re still willing to be reasonable and work with the community where it makes sense.
I think this is a fine opinion but it seems contradicted by the fact that some packages are offered by both the off-the-shelf repos and snap.
I don’t see a contradiction. Can you elaborate?
I did say “better than third party apt repositories”. The distribution has no control over those, so what is or isn’t available in them does not affect my opinion. I’m just saying that Ubuntu has taken the position that snaps (when available) are preferable over packages from third party apt repositories (when available). And what is available through the distribution’s own apt repository is out of scope of my opinion statement.
What is the default choice when I type jq in bash?
It’s fine and well opinionated choice that ubuntu prefers it for third party things. I feel like a lot of first party supported utilities are not well opinionated and i’m left thinking about trade-offs when i go with one over the other.
As somewhat of a fanboy, let me point out that Pop!_os has stayed clear of Snap since the start, although they haven’t spelled out their reasons very clearly (I think they just consider it clunky).
There are a number of aspects to this that seem strange to me.
Linux Mint is based on Ubuntu. That means they inherit the technical decisions upstream (Ubuntu) makes. Why not simply choose a different upstream distro if they’re not happy with such a foundational implementation decision on Ubuntu’s part?
Also, the way the whole decision and implementation of the ‘removal’ was handled feel very ham fist-ed and unprofessional to me. The folks at Canonical have said repeatedly that they would have been willing to work with Mint to enact this change in a less destructive way but were never given the opportunity.
The whole thing stinks like week old fish. Canonical doesn’t have to give Ubuntu away or allow it to be used as the base for all the various flavors and spins, they do because it’s in their DNA and many of them love the Linux community.
I am amazed at how Canonical always tries to make up their own technology instead of embracing existing open-source projects… and it NEVER works, and they keep trying it anyway. Let’s look at the list:
Am I missing any? I feel like there’s more. Does anyone know why the hell they do this? Is it them and Red Hat having a technological pissing match that Red Hat usually wins (systemd and Flatpak come out of Red Hat after all)? Or do they just dream of making a de-facto standard that gives them lots of power, which this article seems to imply?
Either way, good on Mint for pushing back against this nonsense.
Note that Upstart considerably predates systemd.
Snaps predate Flatpak.
IMHO, what happens is that Canonical validates the existence of alternatives by beginning work, causing alternative efforts to start up or for existing alternative efforts to gain momentum. Then a certain vocal faction publicly trash Canonical’s efforts and try to swing the community towards one of the alternatives.
None of this is intended to diminish the value of the alternatives. Alternatives are good. They’ve always existed in the our ecosystem (eg. sendmail, qmail, postfix, exim; apache, nginx; etc). But in the case of a Canonical-led effort, a specific vocal crowd makes it political.
An exception is Unity vs. GNOME. That happened after GNOME didn’t want to follow Canonical’s design opinions on how the desktop should work (even though they represented the majority of GNOME desktop users!), and refused patches. But then, as above, politics happened anyway.
Author’s note: I use RedHat as a stand-in for the entire RedHat/CentOS/Fedora ecosystem a lot in this.
tl;dr Redhat is trying to address pain points for existing users, Ubuntu is going after new markets. Both are laudable goals, but Ubuntu’s strategy is riskier.
I think a lot of this comes down to market demand. With both the “Mir v Wayland” and “Unity v GNOME” RedHat and Canonical were both trying to address a market need.
With Wayland and GNOME, Redhat wanted a more modern display server and desktop environment so that it’s existing customers didn’t have to deal with the big ol’ security hole that is X. (Don’t get me wrong, I love X11 and still think it’s valuable, but I think RedHat’s market disagrees).
With Mir and Unity, Ubuntu wanted a display server and DE that would scale from a phone to a multi-monitor workstation. This is a laudable goal, and it did see a market need to address.
The difference is, Ubuntu was trying to address a market that it wanted while Redhat was trying to address the needs of a market that it actually had. Redhat has tons of customers actively using Wayland and GNOME for their intended purpose, and that gives a project momentum. Ubuntu also had loads of customers using Mir and Unity, but for only one of the multiple purposes that it was intended to be used for. Engineering always has trade-offs, designing a display server and DE for such a wide array of purposes is bound to have rough edges for any single one of those purposes. Ubuntu was asking it’s primary market, desktops and laptops, to suffer those rough edges for the greater Canonical purpose.
Even with snap v flatpak, again Ubuntu’s goals are much wider with snap than Redhat’s are with Flatpak, judging from what I’ve seen. Flatpak is a way for Redhat to distribute software to Linux/systemd in a way that’s more robust than the current RPM method, and Fedora is actively using flatpaks as a base to their Silverblue variant. whereas with snap, I think that Ubuntu wants to be the one stop shop for distributing software on Linux. Again: engineering, trade-offs, rough edges, etc.
The Redhat method of integrating the new package format seems to be coming up with an entirely different distribution to leverage flatpak functionality to it’s fullest while kinks are worked out . Canonical’s method seems to be: “Let’s shove it into our flagship product, and work out the kinks there”. This comes with a lot of inherent risks.
You could also mention
bzrvsgit/hgand like the other software you mention Bazaar(-NG) is essentially dead.On Bazaar, there’s a very interesting retrospective here: https://www.jelmer.uk/pages/bzr-a-retrospective.html
One quote I think is quite relevant to the current discussion:
“Some people claimed Bazaar did not have many community contributions, and was entirely developed inside of Canonical’s walled garden. The irony of that was that while it is true that a large part of Bazaar was written by Canonical employees, that was mostly because Canonical had been hiring people who were contributing to Bazaar - most of which would then ended up working on other code inside of Canonical.”
Upstart predates sytemd, and pretty successful, even Redhat adopts it for RHEL.
Note: Apparently Canonical’s solutions often are the forerunners and other people the copycats… I didn’t actually know that, thanks for the corrections. Frankly it makes the fact that their solutions tend to come out on the losing side even more interesting…
Canonical is taking risks by forcing snap onto his users. Two weeks ago, when an automatic chromium upgrade told me that chromium would switch to snap on my computer, didn’t let me the choice to refuse the new installation, and basically broke apt until I accept, I decided to change distribution. The reason I’m not on Ubuntu anymore and probably won’t be back is only this one: I don’t want to have such change forced on me. This isn’t the linux way.
For reference, Linux Mint blog a year ago stating its concerns: https://blog.linuxmint.com/?p=3766
Last month stating what it’s doing: https://blog.linuxmint.com/?p=3906
Bad, despite correct, headline - but very insteresting article.