Hacker News Reader

Comment by gjsman-1000 | Hacker News Reader

"Interestingly, Canonical actually released an open-source prototype Snap store backend a few years ago, but there was very little interest from the community in in actually maintaining and running a second Snap store, so the project bit-rotted and became incompatible with the current Snap protocol."

That open-source server was a single-python-file hacky prototype written in an employee's spare time. It's not surprising it got little interest.

Not only that, but this is the biggest omission of the truth: Making your own server is no longer possible because of assertions. All Snaps are now digitally signed by Canonical, so you actually need to have the end-user install a forked snap tool on their system to access the custom repository. You cannot disable this signing - your only way around it is to manually download the snap and install it with `--dangerous` through the CLI. And you won't get auto updates that way.

View on HN

> All Snaps are now digitally signed by Canonical, so you actually need to have the end-user install a forked snap tool

Isn't the client side open source so you can put your own signature? Digital signing things seems a good idea for security.

I wish, but the signature is actually compiled into the snapd (the software on your system)'s binary. Deliberately impossible to reconfigure.

Like I said, you can change the signature... by distributing a forked binary to users that would be incompatible with the main store.

Isn't this good? I mean if you are a distribution you compile the software yourself so you can add the distribution keys (there are some that don't compile stuff ).

Probably you are thinking there should be atext file in your home where you could add new signature to be sued, but that could be a security issue so probably needs to be something more safe,did any serious patch was sent to improve this and was it rejected or why we expect Canonical to prioritize this over other issues?

No matter who you are, having to maintain a patched version of Snap just to use your own software is absolutely ridiculous.

I knew things were bad around Snap, but I didn't think they were attacking their feet with such fire power.

You do not need that, you can just use a flag

snap install --dangerous /path/to/snap

But then you won’t get updates for that Snap

So you want something like a PPA? Is flatpack promoting each app will have it's own repo(Skype.Dropbox,Slack,Discord?)

Seems to me that you want a way to have applications and updates installed by people and bypass the review process? If you are a distro maintainer you can change the hardcoded values before you build(distros always change this stuff) but if you are not a distro then you should either submit the app for review or do what other apps do and prompt a notification that a new update is available with a link to a download page.

> Is flatpack promoting each app will have it's own repo(Skype.Dropbox,Slack,Discord?)

Flatpak CAN support the scenario, where each app can have it's own repo. It's an option, not forced down your throat. Or you can self-host your private repo (e.g. applications used inside your network) IN ADDITION to public repos.

> Seems to me that you want a way to have applications and updates installed by people and bypass the review process?

Yes, I want to have Canonical out of the way. They can have their own repo if they really want; those who want curation by Canonical are free to use it. But I want to have options of different repos, with different curators. Canonical doesn't deserve to be the single gatekeeper between me and the apps.

> If you are a distro maintainer you can change the hardcoded values before you build(distros always change this stuff) but if you are not a distro then you should either submit the app for review or do what other apps do and prompt a notification that a new update is available with a link to a download page.

And this attitude is going to be a major reason why most distributions and users won't adopt snap. It will die the same way as other Canonical dead-ends did, while damaging the Linux ecosystems for a few years.

if you are a user then you use a distribution, say Debian,Arch. This distro could setup whatever store, repo and keys they want and Canonical is not forcing themselves on other distributions (it is not systemd).

I am looking at this from a dev point of view, you are asking to prioritize a feature that almost nobody will use over other high priority tasks. The article mentions Canonical did this mistake in the past with Launchpad and it was for nothing. The store code seems to be a mess and you can't just drop the code and GitHub and you are done, it is a lot of work to refactor the code. Same for the client, it is a of work to correctly add the feature to support multiple repositories, if it was only 1 day work somebody would have forked the client, patch it and published it already.

After you work as a developer and see many bugs or problems you look at things differently, for example as a dev I could allow access to an advanced feature in my app, it seems to be just a few lines of extra code. But the reality is that this costs more

- maintenance cost as the software evolves and things under the hood change

- this new feature needs to be documented, someone needs to write documentation, maybe record videos so the minimum number of people contacts support for help

- people don't read documentation so people will contact support and complain that the feature is not working as they expected or that is should have more X or Y

- since is an advanced feature some people might break their stuff and then complain and make a lot of noise and as a dev I need to go and add many checks in the code to prevent people breaking their shit.

> This distro could setup whatever store, repo and keys

But only one. And changing it is a matter of replacing binary/entire package. If is a far cry from `flatpak remote-add $url`.

> Canonical is not forcing themselves on other distributions (it is not systemd)

Systemd did not force itself on distribution either. Systemd was solving real problems distributions had, and others were ignoring them. Including Upstart, which only made it worse.

It's not like systemd had easy start. Even Redhat's management didn't see the point (Lennart P. couldn't work on it during his working hours). It took adoption by Arch to change Redhat's position.

> I am looking at this from a dev point of view, you are asking to prioritize a feature that almost nobody will use over other high priority tasks.

How do you know? Did you do any research among users, or it is just against Canonical modus operandi, where they try to insert themselves as gatekeeper in some layer of Linux community and be the single entity that can be approached for a given topic?

For many, it has much higher priority than forced updates, enforcing a single signing key or paid custom stores for FOSS.

> The article mentions

The article does not make honest arguments, it often misdirects. It is an apologia piece.

> Canonical did this mistake in the past with Launchpad and it was for nothing

Canonical did many more, more serious mistakes with Launchpad. Yes, PPAs were a dead-end, but for other reasons, that are for a separate debate.

> The store code seems to be a mess and you can't just drop the code and GitHub and you are done, it is a lot of work to refactor the code.

The code is a mess from the start. Somebody didn't do their homework what their users will be interested in, but only what they are interested in (see gatekeeping above).

> Same for the client, it is a of work to correctly add the feature to support multiple repositories, if it was only 1 day work somebody would have forked the client, patch it and published it already.

On the client we can see that they tried to do MVP, be first on "the market" and capture it. It is full of user visible annoyances that are not going to be solved (polluting mount namespace, visible snap dir in user homedir, no dedup, etc). They did quick and dirty job to be first, instead of doing it properly, like the Flatpak guys did.

> But the reality is that this costs more

So drop the things that make it complicated, such as routing separate stores through Canonical...

The reality is, that this is just an excuse to do what Canonical wants, not what their users want.

I don't see Linux users demanding snaps in large numbers so it seems to me that is some lay that if I create a Linux related project I need to first ask all the linux users and all the distros for approval and implement and support all of them.

I do not remember GNOME or systemd listening to what users want, they had a team with a big ego and implemented their vision.

If I would be a billionaire and I want to create my own DE or distro I would never waste time to make sure my stuff gets approval from people that think they know things because they follow steps from a wiki or read some blog post about stuff. I would respect the GPL and if some dude wants to add a feature he can fork it and add it, I would be focused on the goal (the goal would not be to destroy other distros or projects or force my vision on them)

> I don't see Linux users demanding snaps in large numbers

For me, Snap is the best package system.

When I publish new version of Wekan Snap, it's updated very fast to those 8k servers around the world where someone has installed Wekan.

Canonical has paid all that huge bandwidth, server and admin cost to maintain snap build and download servers. For me, publishing Snap version is free.

When Snap is updating on some server, there is very short amount of downtime, and then Wekan is up again.

Wekan Snap is in strict sandbox, and can not write to directories outside of /var/snap/wekan/common.

Compared to Docker, Docker updates much slower and uses much more disk space with all those layers.

Compared to Flatpak, Flatpak uses much more disk space.

> Compared to Flatpak, Flatpak uses much more disk space.

Flatpak has content-based deduplication via ostree. Snaps are squashfs images. They both have a concepts of shared common parts, runtimes.

They both take about the same space on disk. However ostree has a hardlink farm for it's content store, so if you do not know how it works and how to measure it, you might have an impression that it takes more space. It does not. IN addition, if you have multiple applications, anything they have in common at file-level granularity will get deduplicated.

Sorry, what I meant is that people that don't run Ubuntu don't seem interested in having snap by default in their distribution , at least I only see the voices shouting that deb is enough or flatpack is better. So in the end if I were Canonical leader I would say fuck them and now put my few developers on implementing a different store for the other distributions.

Why would Canonical leader use such words like "fuck them" ? That's just a absurd conspiracy theory.

For example Wekan Snap is used in very many different distros: https://snapcraft.io/wekan

> I don't see Linux users demanding snaps in large numbers

There is a demand for a way to package and distribute applications independently of distribution and with sandboxing. Hence Flatpak, who are doing it right.

> I need to first ask all the linux users and all the distros for approval and implement and support all of them.

Did you ever worked with some folks doing system-level work? Adoption by distributions is definitely a concern for them. They don't want to work on something that no one would use and by being mostly independent, they can not cram it into distribution as Canonical is doing. Even Redhat people have to prove worth of their solutions.

> I do not remember GNOME or systemd listening to what users want, they had a team with a big ego and implemented their vision.

Because you never met them. Both teams do listen to what users want. Just do not mistake what users want with what a few loudmouths want.

> If I would be a billionaire and I want to create my own DE or distro I would never waste time to make sure my stuff gets approval from people that think they know things

Even if you had your own distro, you would be probably interested in it's adoption, right? It is a bummer to have a distro that nobody would want to use ;).

But I understand; it is a different thing to work with people who have an idea what they are doing, vs. listening to bikeshedding.

However, this is not a case of snap and Canonical. They are doing the wrong thing, because they have different objectives than the ones publicly communicated, and they know it (they communicate technical hows, but not business whys).

Because I am developer and I have experience with different technology and with different kind of users, no I would not try to get the largest number of users. What we need is more science and data, I would not do X because some designer things looks cool or some here developer wants to play with some cool tech.

For example a few years ago KDE Plasma had a maintainer in charge with a big ego(yeah, KDE has some people like this not only the other DE), users wanted an option to disable a thing on desktop (the cashew https://www.omgubuntu.co.uk/2019/10/kde-kills-desktop-toolbo...) .We had patches but (similar to GNOME devs) the maintainer ego was too big and it took years for normality to happen.

IMO is snap is bad or this feature is really needed it will happen or snap will die, same for tray icons in GNOME they will add them back when the big ego guy that is against it will find something else to focus on(not sure we will ever have UX study and use data for decisions)

Tray icons in Gnome are not about big ego guy. The issue is entirely different, rooted in different problem.

Systray appeared for a first time in Windows 95, which had no notion of services, say nothing of user services. Here it started to be abused, at first for quicklaunch scenarios (where an app preloaded itself into ram or disk cache at least at login, so when the user clicked the app icon, it launched "quickly"). Later it started to be abused by apps to make them difficult to turn off (Skype is the classic example). The respective developers redirected all the WM_CLOSE to just minimizing the app, removing it from taskbar, but kept the app running and restorable in the systray. Many users were frustrated that they are not able to quit the app (if they noticed), power users just nuked them from the taskbar.

Models like this are not acceptable on a modern desktop. Even if some people are used to this and cannot imagine something different.

It was Android that came with solution for this: split the app into the UI (Activity in Android parlance) and the background task (the service). The background task cannot interact with the user directly, but it can communicate with the UI (if/when it is running) and send notifications when it needs attention, so the user can launch the UI for ecample (one nice thing is that notifications persist even if the process originating it crashes). It can be launched by the system at login (i.e. as systemctl user service on linux desktop), or it can be launched on demand by the UI part, and it can be similarly terminated. The UI can do many things, but one thing it can't do is to keep it's process running once the user closed all it's windows (Gnome-on-Wayland started to check for this and complains to the user about that, offering whether to quit the app or not).

This model works greatly for apps that genuinely need to run in the background, check for things and on some event notify the user (mailbox monitors, instant messaging, file sync, media players etc). It does not work for apps, which want force themselves on the user, do something that the app developer wants but user doesn't (i.e. Skype) or those who have no reason to be in a background, but they do anyway (VLC for example, where users click on video, but since it is already running and it allows only for one instance so nothing happens then, frustrating user again). The split into UI/service is also positive in that the resources needed to run while in background are lower; all the assets the UI needs are only loaded, when the user launches the UI part.

Meanwhile, AppIndicators & co extensions are there until the developers migrate their app to the newer model. Which takes a while, Rome wasn't built in a day either.

This logic is fine for GNOME apps, sure use client side decorations, use background jobs, remove advanced options etc but GNOME can't force non GNOME apps top follow their big ego designer vision, there are also old application and games that can't just implement client side decorationbs because GNOME want to force their shit.

So I see people like you that complaint hat Canonical did not implement X in snap(like third party repo) but defend GNOME that is rejecting keeping functionality with other applications with excuses like

- GNOME devs are too busy to read and accept your patch (maybe Canonical devs are busy too)

- GNOME devs don't want to add your patch that adds a checkbox to give you an option because is to much work maintining it (maybe Canonical thinks is too much work to maintain that third party repos patch)

- GNOME devs don't want to support other applications and toolkits, is only the GNOME way or if you don't like it use KDE (then same should apply for snaps, you don't like it use flatpack)

- systemd has some Google DNS hardcoded int he code, if you don't like it ask your distro to change it or recompile it yourself (then please apply same for snap, ask you distro to recompile, patch it , etc)

- there is a large number of GNOME users that want tray icons, then GNOME response is "you are stupid, we know better, use something else or patch the code with an extension - you should apply same excuse for Canonical)

Hope I made it clear, there are some double standards here, so we should be more consistent, probably both snap and GNOME are less user targeted and dev/designer ego driven since nobody pays for the product the user requests are ignored.

I will use just one example to demonstrate that your double standards are not really double:

> - systemd has some Google DNS hardcoded int he code, if you don't like it ask your distro to change it or recompile it yourself (then please apply same for snap, ask you distro to recompile, patch it , etc)

Systemd has a default fallback hardcoded to Google DNS. Yes, distributions can compile in another default fallback. At the end of the chain, someone had to pick something, that works. The users can configure whatever they want - no need to recompile anything, just config file - and once they configure something, the default fallback is no more, the option picked by the user is used.

Canonical's snap store, on the other hand, is not a default fallback. It is only one option allowed, and if you don't like it, tough luck.

Wrt. the discussion, there are tree possibilities:

- you don't understand the nuance that makes the difference between those two situations; - you willingly misrepresent two different situations as one; - you don't understand what you are talking about.

Anyway, in all three cases, there's no point to any further discussion.

> a major reason why most distributions and users won't adopt snap

What "most distributions" you mean? Snap is already available for many distros.

And the ones based on Ubuntu are removing it.

On the rest, available doesn't mean anything, it is a low quality packaging. On any distro that doesn't run apparmor, the snap sandbox doesn't work, for example. That's not something you would use outside of experiments.

Linux Mint put in an apt rule to avoid it installing as a dependency of other apps. This decision was triggered by Canonical's announcement to stop maintaining the Chromium deb package. Linux Mint was pissed they had to either switch to the Debian version or to the Snap, so they made some fuss.

I know of at least three Ubuntu derivatives who have Snap preinstalled and every snap I maintain has between 5% and 10% non-Ubuntu users.

> On any distro that doesn't run apparmor, the snap sandbox doesn't work, for example. That's not something you would use outside of experiments.

Given that every AppArmor thing Snap needs is in the upstream kernel, any distribution with a fairly recent kernel an userspace has full confinement. The main limitation is that Snap can't run when SELinux is running at the same time. Canonical is working with a bunch of other people on LSM stacking in order to make that work.

> That's not something you would use outside of experiments.

That might not be something you use outside of experiments, but don't generalize statements like that.

> I know of at least three Ubuntu derivatives who have Snap preinstalled and every snap I maintain has between 5% and 10% non-Ubuntu users.

Pop!_OS doesn't install snap by default, but it does Flatpak.

> Given that every AppArmor thing Snap needs is in the upstream kernel, any distribution with a fairly recent kernel an userspace has full confinement

Just because it is in upstream kernel, does not mean it is used by other distributions. Only that it can be used. But so can be SELinux, which is also in upstream kernel.

> The main limitation is that Snap can't run when SELinux is running at the same time.

Exactly, different distributions have chosen different LSMs in the past and they are going to stick with them. RHEL or Fedora are not going to switch to AppArmor anytime soon.

> Canonical is working with a bunch of other people on LSM stacking in order to make that work.

Good for them that they are realizing this is a problem. Flatpak was developed from the start with the different LSMs in mind.

> That might not be something you use outside of experiments, but don't generalize statements like that.

OK, some people might be too brave ;)

> Canonical's announcement to stop maintaining the Chromium deb package

Funny twist. They hijacked it to install snap.

> Probably you are thinking there should be atext file in your home where you could add new signature to be sued, but that could be a security issue so probably needs to be something more safe,did any serious patch was sent to improve this and was it rejected or why we expect Canonical to prioritize this over other issues?

If someone can replace that text file, they can replace the binary the key is compiled into.

Yeah, but this isn't really any worse than APT or RPM at the moment. More like, if they can change the text file, you've got bigger problems.

Apt has utilities for managing keys, You could keep it simple with plain text file that anyone can read and write but some dude can paste the wrong thing and corrupt the file, or you need to update the format and old scripts would corrupt the file etc. It can be done but as a developer I put in my code constant numbers and paths because there is not enough of a reason to justify the effort to save this values somewhere else. From the article it seems that there is not enough interest from distributions to have their own app store so there is no justifications to prioritize this feature over other ones.

No, this is incredibly bad. Think about the pain we're all going through to rotate UEFI certificates. There is almost no system where this is worth it.

You can always modify the Linux Kernel system call "open" to detect when an attempt to open the certificate is being attempted and then read out your own certificate.

Ideally you'd be able to add the alternative store's public key to the existing snap client. Like you can do with existing package managers to include alternative repos

They deliberately designed the software to not allow that without you forking. I mean, it is trivially easy for Canonical to just put the public key in a file and have Snap read from that key. Instead, they've hard-compiled it in.

Three years ago, I actually had a discussion with them about External Repositories. It's called "External Repositories?" on the forum and has, like, over 200 messages on it. They didn't budge one bit despite our arguments on why this was a very bad idea on their part.

Was there a competent patch submitted about keys and was this discussed in public? I imagine you can't just drop the keys in a random text file, it must be protected like the passwords file.

They're public keys so they can be in plaintext and protected by 0644. They don't really have to be different from apt keys.

You still need to protect from getting updated by errors or malicious code. For apt you have utilities to edit the keys you don't edit a test file by hand.

Sure. I only hope to answer "like the passwords file".

Would canonical be interested in accepting such a patch?

No idea, but honestly I would not spend my time on writing such a patch yet , only if I intend to create a great snap store to rival Canonical , otherwise we have enough working alternatives for all use cases that are not about third party binaries that are reviewed by Canonical.

> Not only that, but this is the biggest omission of the truth: Making your own server is no longer possible because of assertions. All Snaps are now digitally signed by Canonical, so you actually need to have the end-user install a forked snap tool on their system to access the custom repository. You cannot disable this signing - your only way around it is to manually download the snap and install it with `--dangerous` through the CLI. And you won't get auto updates that way.

The blogpost is very clear that each _device_ is made to point to a single store. If you want to point it to a different store, you have to recompile snapd to include your own certificate.

This is why I talk about, for example, Manjaro having their own store. Since they compile snapd, they get to choose what certificate is used and so what store is being used.

It's a right PITA open-sourcing a server component that ties into various back-end business processes, and a completely thankless task. Not at all surprised they didn't bother. It's not like they're swimming in money anymore, they have to be more careful what they spend time and money on.

Reply on news.ycombinator.com