The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. Namely that it would be expensive to open source it with little benefit in return.
Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Mainly because the majority of the costs are for operating an instance which most other distros aren't willing to spend.
Not even Mint operate run or operate their own launchpad infrastructure. They experienced large backlash back then, open sourced it and nobody contributed.
The same problem applies here. Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad. Such a cost operating would benefit nobody but Canonical because
nobody else is bothering footing the bill to run an instance.
Second aspect that they wanted to avoid was the same pitfalls that they experienced previously with ppas and now being experienced with flatpak. Namely they want one location to find software, and one location to serve software.
If users have to use the command line to add a external repo that has unfetted access, then that defeats any usability gains. That and the whole aspects of malware/trust goes out the window.
I will remind people that the most popular PPA to this day is a Java PPA being run by some 3rd party that doesn't offer Java. That PPA has root access to thousands of machines.
> Namely that it would be expensive to open source it with little benefit in return.
Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why?
> Namely they want one location to find software, and one location to serve software.
And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software.
> That and the whole aspects of malware/trust goes out the window.
Malware has already been successfully pushed to the Snap Store. The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code, we now trust software because it came from a store that removes well known malware.
> Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why?
If all you're doing is taking an internal repository and hosting it externally, then it takes no time. But if you make sure licenses are being used correctly throughout the code, audit to make sure no internal secrets accidentally made their way into the internal repository (this happens as much in closed source as it does in open source), and you try to remove any problematic code, commit messages or references from the code, it takes time.
Isn't it a bad look for Canonical, a major open source company, to not have developed core software for their major open source product in an open source friendly manner?
Why should they do everything open source? To keep happy a few bored FOSS maximalists, who have neither real interest, nor use for the code?
We develop open source applications ourselves, and the amount of jerks who drop in from time to time and teach us how to do what (without contributing any code or donations, of course) is overwhelming. They don't care how you pay your bills and how much effort it takes to make things happen.
> Does it have lots of dependencies on proprietary software?
Not so much proprietary software (those dependencies would be owned by Canonical and therefore released in the same lot) but I understand there is considerable dependency on deployment machinery. Documentation for that machinery will need to be split out into private (contains secrets, references to customers, etc) and public (consumable by someone looking to replicate a Snap store deployment) and so on.
> Rather than trusting software because it has verifiable source code, we now trust software because it came from a store that removes well known malware.
The world has moved to that. I don't like it. I would prefer to install only distribution-curated software. However that doesn't help me get a bunch of software that isn't available that way. Where it is (and at the version I need), I use it. Note that this particular statement of yours applies equally to AppImage, Flatpak and everything else that isn't distribution-curated. It's not just an argument against Snaps.
The world has also moved to casually clicking links to "install" arbitrary apps (which in turn call stacks of arbitrary libraries and frameworks the dev probably found by casually clicking links).
You could give Debian and Ubuntu another decade to work on their packaging infrastructure and they still wouldn't reach parity with what we get through the web with the current browser security model.
>Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why?
Im not too sure as I don't work for Canonical. However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare.
Things like potentially giving some mechanism that could enable a user to sign/publish on behalf of Canonical snaps/packages for example. That kind of thing would probably need to be removed. Deep integration between CI/operational infrastructure for things like building images. I can imagine after Canonical's experience of launchpad that they probably did hardcode aspects and it isn't some modular thing you can just spin up on docker.
>And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software.
Snaps I checked aren't there to replace apt. They don't prevent the install of flatpak, appimages or any alternative. Canonical has no agreement that prevents parties like Mozilla/KDE from only publishing on the snap store.
>Malware has already been successfully pushed to the Snap Store. We now trust software because it came from a store that removes well known malware.
There was one case of a snap bundled with a cryptominer. That was settled within 3 days and addressed to the community in a blog. Since then, it has been deliberately looked for. As someone who has published on the snap store, yes there are some checks present to ensure malicious software isn't being pushed.
>The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code,
It is really easy for me to see exactly what is being run/executed on the snaps that I install. In fact I have built/used snaps successfully without even the snap store all together.
> However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare.
If Canonical, as a Linux company, is not willing to spend the effort to open source their software, then Snap can continue to be rejected by Linux distributions. Canonical's most obvious reason for keeping the Snap server closed source is to lock its users into a proprietary and centralized system that it has full control over. This strategy is no different from Apple disallowing installations outside of the App Store on iOS, and Google disallowing alternative app stores in Google Play.
You haven't really at all explained any justifiable reason for Canonical to open source it. You still haven't argued at all the resource aspects which are I think the primary motivator here.
Canonical has done this experiment precisely in the past, and we see the results of nobody operating their own launchpad instance. Nobody contributing back. That experience probably trumps all of this goodwill and opinions from the community.
Canonical is more importantly getting users, publishers and numbers behind them. A discussion I remember reading was that every snap has 10x more installs than the corresponding flatpak. That and they have 1st party support from major publishers like Google, Microsoft, Amazon, Spotify, Mozilla, Jetbrains, KDE etc....
Those aspects are more important for usability for the average user.
> You haven't really at all explained any justifiable reason for Canonical to open source it.
I've explained why it would be in the users' interest for Canonical to open source the Snap store: it reduces vendor lock-in and allows the users to enjoy the benefits of open source software (the ability to use, study, share, and improve the software with no restrictions).
Whether open sourcing the Snap server benefits Canonical is irrelevant to the users.
No you think it would be in the users' interest but it absolutely isn't. I'm willing to bet money you haven't looked at launchpad's source code at all. Nor have you or anyone else considered operating their own. That is how most of the Ubuntu based distros right now are already getting their software.
If Canonical goes down, a huge part of the usable linux market goes down with it. Possibly Linux Mint too, unless im mistaken.
>vendor lock-in
You are not vendor locked in. You can install flatpak, install via apt, appimages etc... Canonical doesn't ban the removal of snapd from ubuntu distros.
In fact, from a Linux dev I would argue that half the fragmentation for pointless nonsense like packaging and distributions has harmed the community far more. Namely because it's increased the cost of development for these things to a degree that companies won't even bother developing/publishing software on Linux. That has been the primary problem for Linux so far.
Canonical is actually getting first party support from major publishers and people still lampoon them. This includes publishers in the past who never would have considered publishing for Linux before.
> No you think it would be in the users' interest but it absolutely isn't.
If you don't understand the value of free and open source software, you're not obligated to use it. The maintainers of Linux Mint and other Linux distributions do understand, and that is one of the reasons they have rejected Snap.
> I'm willing to bet money you haven't looked at launchpad's source code at all. Nor have you or anyone else considered operating their own.
Your assumption is wrong and you've lost the bet. Additionally, Flatpak is available and Flatpak servers are already being hosted independently:
> You are not vendor locked in. You can install flatpak, install via apt, appimages etc... Canonical doesn't ban the removal of snapd from ubuntu distros.
Canonical has already transformed apt installs of Chromium into Snap installs, which motivated Linux Mint to reject Snap. Vendor lock-in is not black and white. For example, Android users can also install F-Droid or a variety of third-party app stores, but considering Google Play's default status on Android, most users are effectively locked in. The same applies to Canonical's handling of Chromium, and the Linux community is opposing this to discourage Canonical from continuing this dark pattern.
> half the fragmentation for pointless nonsense like packaging and distributions has harmed the community far more
Snap increases the fragmentation, and is more hostile to the FOSS community than all of the other options because its server is closed source.
Linux Mint maintains a Debian derivative (https://linuxmint.com/download_lmde.php) so that they can continue operating should something happen to make the Ubuntu derivative unfeasible.
Also, for what it's worth, I remain entirely unconvinced by your argument that this is fine from a users point of view. If they want to stop the push back, they need to ensure that they are not the only one with the ability to host a Snap store similar to how Flatpak does it. You can claim that this is irrelevant as it won't be used, and I suspect that you're right about that, but they will not be trusted until this happens.
>The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. Namely that it would be expensive to open source it with little benefit in return.
Perhaps a business reason left unsaid is that an open source snap store would undermine Canonical's paid "enterprise edition" snap store. Why would an organization pay $30000 (https://ubuntu.com/internet-of-things) for a private app store if they could easily set up their own snap store?
There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories. GNOME Software and KDE Discover both set Flathub as the default repository, which serves as the primary software source, and users can optionally add more repositories if they choose to do so. Users who don't want additional repositories can simply stay with Flathub without having to do anything.
The Snap server's closed-source nature is not a benefit to users, and there is no excuse that can justify this from the users' perspective.
>There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories.
There are always tradeoffs. I would argue there are advantages for having a trusted party vetting my software repos. It's why I even use Ubuntu because I trust Canonical to make some sane decisions when vetting their repositories.
You give multiple repository support and suddenly users have to one find a way to add another repo, and second there is no way of removing software from those repositories if they do end up malicious.
Which is why I brought up the webupd8 java instance having root access to thousands of machines.
>users can optionally add more repositories if they choose to do so.
Ubuntu is the version of Linux designed to be used by your grandmother. They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors.
It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains released software as a snap long before it is even possible on flatpak but nevermind that. I don't think you can even get VSCode, Spotify or Intellij on Flatpak.
> You give multiple repository support and suddenly users have to one find a way to add another repo, and second there is no way of removing software from those repositories if they do end up malicious.
> Ubuntu is the version of Linux designed to be used by your grandmother. They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors.
By default, GNOME Software and KDE Discover only use the Flathub repository. Your grandmother won't be adding other repositories to the Flatpak client. Users who don't add any extra repositories will use Flathub, which is a trusted source of software that runs on an open source server.
> It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains released software as a snap long before it is even possible on flatpak but nevermind that. I don't think you can even get VSCode, Spotify or Intellij on Flatpak.
None of those 3 links are provided by Microsoft, Spotify or Jetbrains. Yes they are there, but they are published from 3rd parties. Why exactly do you think that is?
The microsoft, spotify and Jetbrains software comes directly from their respective publishers. Problems are supported and debugged directly. That is a major difference.
Canonical very publicly collaborated with these companies to get their software on the Snap store while Flathub has been handled in a more free-for-all manner. If you build it, they will come, and all that. Moreover, I'm not so sure Red Hat is as explicitly interested in monopolizing the Linux application ecosystem as Canonical, especially since their acquisition by IBM. Maybe IBM has other ideas, but we likely won't see similar marketing efforts on that front in the near future.
> They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors.
Canonical deciding that Ubuntu won't allow third-party Snap repositories is completely orthogonal to open sourcing their Snap server and/or making it easy for people to develop alternatives. They can perfectly well do both.
Can we not pretend that the single source nature is anything other than a money grab? It's pretty clear that all you have to do to ensure grandma doesn't add sources is make adding it require the cli.
You can watch the discussions from Popey, Martin Wimpress etc... It's pretty clear from their perspective that they built the tech from users/devs first approach.
Do you really think Canonical is looking for money over here? If so do please precisely explain in the short-term how exactly you think they are gonna achieve that.
Do you think they are suddenly going to be able to dominate the entire 100% Linux desktop software market and charge 30%? Do you think a company like Microsoft/Spotify/Jetbrains would just roll over with that? I don't imagine they can do that considering Red Hat/Suse market position. Nor do I see the total Linux Desktop applications being a blip at all on their revenue streams.
Last I checked, they are still providing infrastructure to the Linux community for free. They still have more market share then the rest of the Linux distros combined. That and without them, Linux Mint wouldn't be operating as they do now.
Frankly they don't deserve the hatred the FOSS community throws at them and you are being somewhat disingenuous by presenting them as such.
The FOSS community opposes Snap because its server is closed source and forces vendor lock-in to Canonical, among other reasons. This is fairly simple to understand and not "disingenuous".
> The FOSS community opposes Snap because its server is closed source
If this was true FOSS projects wouldn't be publishing things on the snap store (they are, and they publish on google play, winget, and other closed app stores).
No one can claim they speak for whatever you think "the FOSS community" is, let alone what it opposes or supports.
You haven't even explained how it's vendor lock-in. Canonical has no way designed their approach to ban the use of apt, rpm, deb, flatpak or appimages. They are in no way of a position to dominate the market in the way Google does with Android and it's stupid to even think that is their aim.
It should be pretty obvious to you why they aren't exactly going to claim 30% commission on nothing from users who are as cost averse as possible. It should be plainly obvious to you also how they don't have the clout to bully software vendors to publish for them.
They have already plenty of evidence that profitability of distribution of linux software isn't exactly a lucrative market like Google or Apple. The fact that you think that is their aim or that it is feasible in the FOSS Linux community with large scale players like Google/Microsoft/IBM is ludicrous. Canonical tries to attempt to get such vendor lock-in and they would lose so much marketshare apps on their store instantaneously. They aren't even in a position like Apple/Google/Microsoft here who charge money to publish apps.
I have already explained how that argument is complete nonsense.
There are degrees to vendor lock-in, and it's not black and white as you portray it to be. Flatpak and apt exhibit minimal lock-in, because they are decentralized and fully open source. Snap, on the other hand, has a closed source server that is controlled solely by Canonical. Since the Snap Store is the only preinstalled app store on Ubuntu, this results in a greater degree of lock-in than Flatpak and apt.
The backlash from Linux Mint and other distributions was partly caused by Canonical using Snap for Chromium when the user intended to install it through apt. This sleight of hand is not as extreme as a 30% commission, but it's a step in the wrong direction. The FOSS community is able to reject moves toward vendor lock-in even if the closed source Snap server does not mandate a 30% commission.
>There are degrees to vendor lock-in, and it's not black and white as you portray it to be. Flatpak and apt exhibit minimal lock-in, because they are decentralized and fully open source. Snap, on the other hand, has a closed source server that is controlled solely by Canonical. Since the Snap Store is the only preinstalled app store on Ubuntu, this results in a greater degree of lock-in than Flatpak and apt.
You keep repeating yourself. Having a default mechanism for installing software installed on Ubuntu distros that is using Ubuntu based infrastructure does not constitute vendor lock in. Guess what, Ubuntu uses apt rather than yum. That isn't vendor lock in either.
Having a proprietary back end does not constitute vendor lock in.
What you are saying is the equivalent of using spotify is vendor lock in. That or using Firefox. Heck Canonical's model here is practically no different from Firefox with their addon store.
A developer can choose to ignore snap all together and still distribute on Ubuntu. A user can choose to ignore snap all together and still install software on Ubuntu. They will have to face the consequence of not having to use chromium because nobody is willing to maintain it other than Canonical.
What is this nonsense that you are spouting.
>The backlash from Linux Mint and other distributions was partly caused by Canonical using Snap for Chromium when the user intended to install it through apt. This sleight of hand is not as extreme as a 30% commission, but it's a step in the wrong direction. The FOSS community is able to reject moves toward vendor lock-in even if the closed source Snap server does not mandate a 30% commission.
Because any move that you or Mint disagrees with is a 'step' in the wrong direction? So be it, I and probably Canonical would rather be wrong.
Snap has 10x the install base for each snap compared to flatpak. It also has more first party software support.
> Guess what, Ubuntu uses apt rather than yum. That isn't vendor lock in either.
Apt and yum both support configuring multiple repos, their protocols are well-documented, there are an abundance of repo implementations, etc. If apt only supported a single upstream repo and Debian kept the source proprietary, do you think Ubuntu would exist?
Nearly every packaging system is able to successfully divorce building of software from offering artifacts for download let alone ops. This is arguing that having failed to design their system appropriately we ought to accept the fruits of that bad design instead of dumping Ubuntu. Compare this with apt.
Second what you describe as a defect. There being multiple sources of software is a plus it means the power is in the hands of the user to decide whom to trust. What you don't want is a situation where people must configure additional sources just to have commonly needed software. The example you provide about the Java PPA is apt, pun intended, ideally commonly required software would be provided by the vendor instead of siloed in a third party source. Of course the vendor and the license must make this possible.
> Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it.
Launchpad has a weird user experience and was for a long time too much focussed on bazaar when git won.
At work we used bazaar and lp for a while, but still I always have to search for the right path for getting to a project's code. The bug tracker was more useful than GitHub's but that didn't help ...
Aside from that there are the legal implications of AfferoGPL which prevent many people from touching it.
But yes, doing infrastructures is hard. I however don't know how complicated hosting is and how well it's packaged. For software starting for in-house use this often is a mess ...
> Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it.
I posit that this doesn't matter.
Presumably Ubuntu's infrastructure should be open source so that it can be inspected if necessary, for security reasons. It shouldn't matter if nobody else is actually hosting an alternative copy... it is still important that their copy be open source.
Disclaimer, I like the snap packaging format, and I'm not familiar with the history of launchpad.
Operationally:
- I can trivially host and control my own apt repository, either as a mirror of some upstream repository, or with bespoke packages.
- I can't do the same with snaps.
So launchpad and snap store isn't quite apples-to-apples. It would help of course if a snap store could be statically hosted or re-implemented, but the full API is quite complex.
> The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times.
I just think it's weird that a supposedly open source company like Canonical would build close source infrastructure. Like, just develop it in the open to begin with?
Sure, there's "even better" ways to go above what they did, but it seems to be than an open source company would at least by default develop open source software.
They had to have actively chosen to build this closed-source software, no.
My point was only that I expect an company like Canonical to not just open source everything, but to design it in such a way that it is useful for third parties.
To make the distinction with "open source waste", where companies Open Source the software they no longer want, maintain or monetize.
I'm curious... what is that Java PPA that you are talking about? I tried searching for it but I couldn't find anywhere that had a list of the most downloaded PPAs.
The short story is - developers typically need to target more than one version of Java and the long lifetime of LTS releases don't line of up very well with that.
Canonical historically provided a single "system" version of Java (meaning any system packages that depends on Java depended on this package) which meant that that was the version of Java that you got with Ubuntu XX.XX - even for LTS releases which had a 5 year lifespan.
Ubuntu 16.04 - which is still in support came with openjdk-7 and Canonical refused to provide an openjdk-8 package for it despite Java 8 being the prevalent development platform from late 2016 onwards and despite numerous requests to do so. No one was expecting Canonical to replace openjdk-7 with openjdk-8 - they only wanted to be able to install openjdk-8 along side the existing openjdk-7 system Java.
Ubuntu 18.04 - slightly different scenario but still the same problem - openjdk-8 and openjdk-11 are available but that still doesn't cover all development use cases.
Thus, people add the PPA and install the openjdk from there because someone currently is doing the work of keeping the PPA up to date.
Ubuntu provides Java the same way as Debian does, enabling applications to run with any compatible Java implementation. There is one version which gets pulled by default, but you can totally switch to a different one.
Oracle Java cannot be packaged or used in any but personal setup, and there’s no need for it these days when OpenJDK is the official Java implementation.
> Namely that it would be expensive to open source it with little benefit in return.
I don't think that's the real reason; I think it's that Canonical wants to maintain control. Their dream of being the App Store of linux isn't working out.
> Canonical already spent a large amount of investment opensourcing launchpad
If their development practices make open-source development expensive, that's Canonical's problem, not anyone else's. Nobody else uses Launchpad because Launchpad is not a compelling platform. It's still tied to bazaar, which frankly lost the version-control wars. Treating git as a second-class citizen is not how to engender contributors.
> Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad.
Another example of having to choose: did Canonical engineer themselves into a corner, causing all of Launchpad to become technical debt from under which Snap cannot escape? Or was it a deliberate business decision to try to maintain control of the store? An affirmative conclusion in either case doesn't look good for Snap.
> Namely they want one location to find software, and one location to serve software. If users have to use the command line to add a external repo that has unfetted access, then that defeats any usability gains.
Users pretty clearly do not want this. Many people use Ubuntu expressly because of the PPA system; I'd argue that it directly caused Fedora's COPR system to exist because of the user demand. There's no mandate that PPA installation require command-line configuration; it would be trivial to create a bespoke per-PPA using e.g. Vala. Synaptic already allows configuration of PPAs via GUI. It's total non-issue.
> That and the whole aspects of malware/trust goes out the window.
They're already out the window. Snap packages are not reviewed for content and anyone can just cram software into it from random GitHub repositories. Wouldn't it be nice if it were possible to set up a 'curated' Snap store with strong promises of software quality and review? We can't, because it's apparently too hard to run. Another drag on Snap.
I'll not bother to respond to the whataboutism regarding PPAs. Literally the only difference between "a giant PPA that Canonical hosts" and the Snap store is that anyone can upload to the Snap store.
None of the problems Snap store purports to solve are compelling, so these explanations don't really further the cause.
Red herring. The Linux Mint teams' main complaints have to do with issues around the way snap wrests control from the user.
>I will remind people that the most popular PPA to this day is a Java PPA being run by some 3rd party that doesn't offer Java. That PPA has root access to thousands of machines.
>Red herring. The Linux Mint teams' main complaints have to do with issues around the way snap wrests control from the user.
Like Linux Mint is doing the same? There is no control being lost by using Ubuntu versus Mint. I could remove snapd there without people making that decision for me.
Worse would be Mint's decision of removing the only FOSS built version of chromium without offering an alternative in place. Canonical only installed the chromium snap because they did not have the resources to support a deb version instead.
>Imagine strawman-ing this hard.
It isn't a strawman. It is precisely what their reasoning was and it makes perfect sense. The snap store has already seen people attempt to install cryptominers. There is no way in Flatpak of banning known malicious flathub repos.
> Canonical only installed the chromium snap because they did not have the resources to support a deb version instead
So Canonical has the resources to make an entire DE, an init system, a mobile OS, a new display server (all of which were dumped on the roadside), and then going all in on a brand new sandboxing/package management system developed from scratch, but merely compiling a web browser officially supported by google and used by nearly every single one of their users is too much work?
> Like Linux Mint is doing the same? There is no control being lost by using Ubuntu versus Mint.
If I understood the issue correctly (and I may very well be mistaken!) the problem Mint has with Canonical is that Ubuntu has "hijacked" (for lack of a better term) some apt packages so that they now actually install snapd and the snap. So you think you're opting out of snap, but when you use apt to install Chromium you end up using snap anyway.
If I understand correctly, this is Mint's main complaint: that Ubuntu seems to be hijacking apt packages with snap.
Canonical couldn't afford the maintenance costs for it. On Ubuntu distributions it's either the snap or you have to create some weird frankendeb aspect by pulling from Debian.
They explained it better than I would.
In other cases, I don't think of a case where apt installs snaps over apt. I think the only priority for the decision choice was based on most recent version. Although this aspect I am slightly unclear.
In previous versions of ubuntu, that package would install chromium, as one would expect.
In recent versions of ubuntu, this package is a stub that installs snapd, and then snapd installs chromium.
There is a substantial difference between those two things. Users that try to install chromium through an open package management system are being pushed to Canonical's proprietary store.
Oh. If there is no Chromium apt package, isn't the following from TFA (lwn) misleading?
> The problem was the decision to change the Ubuntu chromium-browser APT package itself upstream in Ubuntu. Previously, that package would simply install Chromium directly. With the change, it would instead install the Snap package-management tools first and then install the Snap equivalent of the Chromium package — without making it clear to the user what was happening.
And yet they have all the time in the world to spend on an invasive daemon that pulls updates OTA without user consent. Plus all the other bullshit they've tried (Mir, unity, juju or whatever it's called). Thankfully Debian is still true to the game.
If you keep breaking the site guidelines, we're going to have to ban you. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting here?
Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Mainly because the majority of the costs are for operating an instance which most other distros aren't willing to spend. Not even Mint operate run or operate their own launchpad infrastructure. They experienced large backlash back then, open sourced it and nobody contributed.
The same problem applies here. Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad. Such a cost operating would benefit nobody but Canonical because nobody else is bothering footing the bill to run an instance.
Second aspect that they wanted to avoid was the same pitfalls that they experienced previously with ppas and now being experienced with flatpak. Namely they want one location to find software, and one location to serve software. If users have to use the command line to add a external repo that has unfetted access, then that defeats any usability gains. That and the whole aspects of malware/trust goes out the window.
I will remind people that the most popular PPA to this day is a Java PPA being run by some 3rd party that doesn't offer Java. That PPA has root access to thousands of machines.