Live data from Hacker News

Why is there only one Snap Store?

merlijn.sebrechts.be

351–360 of 362 posts

Re: Why is there only one Snap Store?

#351
post #57

Control. 1. Get market share with free product. 2. Start charging once monopoly is achieved. 3. Profit!

That 3. Profit seems to be for Enterprise use only.

For my development:

- I download and use Snap on Kubuntu/Xubuntu/Debian for free

- I have developed and published Snaps for free

- Canonical pays huge cost of build and downloads servers, where I can download Ubuntu-based distros and Snap packages for free

I really wish Canonical will have enough profit from Enterprise use so it can provide all that for free also in the future for me.

Re: Why is there only one Snap Store?

#352

My main reason for disliking Snap is the fact that it allows anybody in the world to publish a package with minimal moderation. This completely undermines the inherent trust that system package managers should have. When installing critical system packages, I want to be absolutely certain that these are legitimate/official, and that even if I make a minor error in typing a command, I won't inadvertently install some…

> My main reason for disliking Snap is the fact that it allows anybody in the world to publish a package with minimal moderation. This completely undermines the inherent trust that system package managers should have.

Where do we get more maintainers? Sometimes in my development I release one new Wekan version per day. Canonical's Snap build servers download Wekan source code directly from GitHub, it is very transparent.

> On the sandboxing - it's good in principle, but rarely seems to be implemented in a truly meaningful way

Wekan Snap has strict sandbox, so code can not access any other directory that /var/snap/wekan/common. So in case someone would find exploit for web service, it can not escape sandbox. It is very important.

Re: Why is there only one Snap Store?

#353
post #218

Earlier quoted context omitted.

Note that the sandboxing security theater of flatpak and snap etc is largely just that. You can have very secure deb packages by having default-deny apparmor rules. This is basically how Android works, it just asks you to grant the permissions in real time (and uses a frankenmix of custom Google fu Android Java API and selinux). You can also use cgroups to control kernel feature access like devices, networking, perip…

>You can have very secure deb packages by having default-deny apparmor rules. Nobody would do this on a desktop because it is massively inconvenient to go through every single app you want to run and debug which app armor rule that it's violating. Even when running a service with a pre-written app-armor profile you usually have to spend a while to figure out what the hell went wrong. Flatpak's sandboxing is a complet…

Snaps have already taken off in a big way. Many individuals, companies and enterprises have selected Snap because of secure sandbox and automatic updates.

It is just that FUD from Linux Mint causes many HN articles with FUD.

Re: Why is there only one Snap Store?

#354

Earlier quoted context omitted.

From my understanding the new packaging is designed to move the control from the distribution maintainer to the developer. So depending on software and distribution you get a range of advantages and disadvantages. You can continue using apt, snap, flatpack,Stram and binaries from tar.gz so we only gained in choices.

Also, moving control from the user to the developer. Snaps automatically update, and until recently had no way to disable this behavior. This is a poor security choice, and means that a stable system cannot be made. While apt can still be used, many packages were replaced by snaps, completely defeating the purpose.

Snaps running in secure sandbox is better than installing apt package as root.

Automatically updating Snap package with latest security and bug fixes is better than old vulnerable deb package.

Re: Why is there only one Snap Store?

#355
post #353

Earlier quoted context omitted.

>You can have very secure deb packages by having default-deny apparmor rules. Nobody would do this on a desktop because it is massively inconvenient to go through every single app you want to run and debug which app armor rule that it's violating. Even when running a service with a pre-written app-armor profile you usually have to spend a while to figure out what the hell went wrong. Flatpak's sandboxing is a complet…

Snaps have already taken off in a big way. Many individuals, companies and enterprises have selected Snap because of secure sandbox and automatic updates. It is just that FUD from Linux Mint causes many HN articles with FUD.

Yeah, but Linux Mint still has snapd removed by default and refuses to support it; so do most of the other popular downstream distros (PopOS, elementaryOS) for desktops. Together, they have way more desktop share than Ubuntu does.

Sure, there are other distros not based on Ubuntu that technically support snapd, but I have yet to encounter one that does it well; Manjaro's still breaks on many snaps, Fedora's snapd stopped working completely for over 3 months and nobody noticed. Pretty much nobody but Ubuntu users actually care about snaps; Flatpak has way, way more support and penetration than snaps do, and it looks as if that isn't going to change any time soon due to Canonical's refusal to open-source the snap store. I don't think snaps have much of a future as a widely-supported method of package distribution if this doesn't change.

Re: Why is there only one Snap Store?

#356

Earlier quoted context omitted.

> It's not for nothing that Snap is considered dangerous by SUSE and is not officially supported. They even fail basic upstream responsibilities. Care to provide a link to support your claims?

The security issues SUSE raised were actually fixed, but the Snap developers did not respond quickly enough with the info that the issues were fixed. > I'd like to point out that the reason for the closure was not a failure at addressing any of the raised issues, but a failure to reply to either of the requests for a status update in July and September. https://twitter.com/sysrich/status/1206593475833151488

That's interesting, since it looks like the issues raised by the SUSE Security audit are not all fixed yet: https://github.com/snapcore/snapd/projects/4

Re: Why is there only one Snap Store?

#357
post #54

Earlier quoted context omitted.

Red Hat did use upstart before adopting systemd FWIW.

> Red Hat did use upstart before adopting systemd FWIW RHEL added support for Upstart as a hybrid with SysV, however it was never heavily used and not by most of their own packaged RPMs. Spin up a CentOS 6 server, install a bunch of daemons then go compare /etc/init/ to /etc/rc.d/init.d/.

We tried to use Upstart properly in Fedora. We spent three Fedora releases trying to do that (Fedora 9, Fedora 10, Fedora 11, and Fedora 12). We gave up by Fedora 13.

Re: Why is there only one Snap Store?

#358
post #239

Earlier quoted context omitted.

Red Hat: Hires Alex to work on Flatpak. Loved by Community, almost a dozen distros supporting Flatpak as a next-gen package format by default. Snap: Loved only by Canonical devotees. Zero distros supporting Snap exclusively by default. Red Hat: SystemD Canonical: Upstart, dead to SystemD. Red Hat & Others: Wayland Canonical: Mir. Dead to Wayland. Red Hat & Others: GNOME 3 Canonical: Unity1-7. Dead to GNOME.

ChromeOS still uses upstart.

There is work going on to port Chrome OS to systemd: https://bugs.chromium.org/p/chromium/issues/detail?id=583671

Re: Why is there only one Snap Store?

#359

Earlier quoted context omitted.

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")…

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 thir…

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.

Re: Why is there only one Snap Store?

#360

That reminds me of the stake Ubuntu Core was born with in its heart: > An Ubuntu SSO account is required to create the first user on an Ubuntu Core installation. They just keep flinging shit at nothing and hoping to hit a wall they can build a gate in. They're trying to boil the frog slowly with Snap on the Server/Desktop branches. There is no possible genuine motive for these maneuverings to be in the position of ga…

Canonical doesn't seem to understand that if I wanted a gate-kept system, there are plenty of better, non-Linux options in this world. Canonical seems to have forgotten why Linux exists to begin with.

Free and stable (so possibly Linux) gate-locked system is obviously needed on market. See Android.
Post reply on HN