
Why is there only one Snap Store? - reddotX
https://merlijn.sebrechts.be/blog/2020-08-02-why-one-snap-store/
======
1_person
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 gatekeeper.

If anyone at Canonical is listening, you should be aware it doesn't matter how
slowly and carefully you approach this, or how you justify it, the first time
I'm forced to kiss the ring to get my software to work, your software is gone
from any system I own or manage, immediately and forever.

You're not going to get within a thousand miles of monetizing the ecosystem by
gatekeeping it -- the moment you even so much as assert the position of
gatekeeper you're trying to create for yourselves you're dead to me.

~~~
jeroenhd
To be completely honest, if Canonical ever wants the theoretical "year of the
Linux desktop" to happen, they need a way to get proper cloud accounts
working.

A big part of the value of Apple's ecosystem is iCloud. Microsoft has done the
same thing with the syncing and cross platform capabilities of their Microsoft
Accounts.

Most Linux users today don't care much if they need to create separate email,
cloud storage, backup storage, password recovery and application store
accounts. That's because many Linux users have a preference for one service or
even self host.

Normal people aren't like that. A desktop without a cloud account is like an
Android phone without Google apps or a theoretical Apple phone without Apple
apps. Technically fully functional and customisable via sideloading, but
ultimately pointless because nobody wants to go through that. Just ask any
regular Jane or Joe on the street if they can set up IMAP email on their
phone; I bet they just use Gmail or Outlook.

It's not the Linux power users Canonical wants to attract; it's regular users.
Their requirements are different from yours or mine. The Ubuntu Core website
specifically says it's built for business. It's focus is on configurability
and enterprise deployment, making it closer to a managed Windows 10 enterprise
network than something you run on your laptop at home. Lockdowns and
gatekeeping are practically what the service is intended to do.

~~~
sevensor
For my money, the year of the Linux Desktop was 2008. It's just that nobody
noticed.

Since 2008, Linux has had the best combination of performance and hardware
support on older machines, and the advantage has only grown since then.
Windows and MacOS keep falling further behind in usability on machines older
than four years, and that's the only hardware I would purchase for personal
use. Why throw your money away on planned obsolescence, on an OS that keeps
getting worse and worse, when you could use Linux on an older machine and have
things keep getting better and better?

~~~
kunai
In terms of usability, yes, but the problem with Linux in recent years has
rarely been usability, it's the lack of workstation-level applications that
are readily available on Windows and MacOS.

As long as Linux lacks native support for Autodesk, Adobe CC, Office 365, FL
Studio, Pro Tools, etc. and dozens of other niche programs by ISVs it will
never approach the mainstream with any sort of widespread appeal. Currently
Linux on the desktop is suitable for people who are aware of these limitations
and either circumvent (through technical means such as WINE, which are opaque
to the typical end-user) or tolerate them, acknowledging the limitations and
doing nothing to mitigate them while embracing Linux's strengths as a web and
educational medium (think Chromebooks).

I legitimately have tried going Linux-only several times in my life and I've
just come back to Windows every time. I know it's not ideal from a security
perspective, a privacy perspective, etc. but there is just zero competition
with Windows in terms of a software support perspective. Windows' backwards
compatibility and range of software support is a masterclass in how to enable
productivity. Even MacOS doesn't come close, with how frequently Apple breaks
stuff that's expected to be supported (32-bit app support, Rosetta, etc) and
how frequently they change architectures (68k > PowerPC > Intel > RISC, vs
Microsoft with 32-bit Intel > 64/32-bit Intel)

~~~
the_af
That seems like a moving goalpost to me.

First, it wasn't usable. Then, it didn't have drivers. Then, it crashed a lot.
Now it doesn't have Autodesk stuff? For the record, my mom doesn't know what
Autodesk is. A "desktop" for me is where you can play movies, edit documents,
browse the net and check email.

~~~
kunai
And Linux is fantastic for that, until you come across a use case that is
outside those typical bounds.

Say your mom decides she likes photography one day and decides to buy a camera
and take some lessons. Say her teacher says "we use lightroom and photoshop so
you'll need to have these because they're industry standard" and she has no
idea what to do and why the Adobe CC launcher won't load on Linux. Then she'll
call you up and ask why it won't work, you'll respond with "there's no
photoshop, you can use GIMP though" and your mom being a regular computer user
won't be familiar with the eccentricities of GIMP as editing software and will
be lost and unable to follow through on her new hobby.

This has literally happened to people in my life I've recommended Ubuntu to.
Too many times to count.

~~~
the_af
That is a real problem, but in my opinion unrelated to whether an OS is "ready
for the desktop". That's just a business problem, not a technical problem:
Adobe cares about platforms where the money is.

It's not a technical problem because people like my mom can learn to use GIMP
(note: people who use photo editing software are "pros" of a kind, anyway;
"regular" users don't know how to edit photos, either) or Krita or whatever.
But even if you fix GIMP's UX issues, it's still not Photoshop or Lightroom,
so the problem remains: there's no Adobe software for Linux.

But that's not what being ready for the desktop is about. That's not what a
desktop is for most people, either. All in my opinion, of course.

PS: if Lightroom magically makes it to Linux (hypothetical thought
experiment), but _then_ it's Overwatch or some other high profile AAA game
that doesn't run natively, is it still a problem of the Linux desktop?

~~~
coldtea
> _That is a real problem, but in my opinion unrelated to whether an OS is
> "ready for the desktop". That's just a business problem, not a technical
> problem: Adobe cares about platforms where the money is._

Only back in the day part of the idea around "Linux for the Desktop" was that
everybody would use the "better" FOSS programs, and not wait for
MS/Adobe/Autodesk/Avid/etc.

But, as you note, this hasn't happened, and "even if you fix GIMP's UX issues,
it's still not Photoshop or Lightroom".

> _But that 's not what being ready for the desktop is about. That's not what
> a desktop is for most people, either. _

Well, pragmatically the desktop is a Windows machine, which just works,
doesn't require them to think long and hard about which
cpu/memory/laptop/peripherals/etc to buy, has drivers for all of their
devices, has all kinds of apps they might use (beyond email and web), and so
on.

~~~
the_af
> _Only back in the day part of the idea around "Linux for the Desktop" was
> that everybody would use the "better" FOSS programs, and not wait for
> MS/Adobe/Autodesk/Avid/etc._

That wasn't really like I and many others envisioned, no. Free software have
other benefits that make them "better", not merely technical issues.

------
gjsman-1000
"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.

~~~
simion314
> 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.

~~~
gjsman-1000
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.

~~~
simion314
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?

~~~
msla
> 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.

~~~
gjsman-1000
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.

------
Conan_Kudo
_" Although they invested significant resources in open sourcing Launchpad,
there is still only one instance of Launchpad running and they have not
received any significant contributions from non-Canonical employees."_

For what it's worth, there _is_ another Launchpad instance in existence:
[https://quickbuild.io/](https://quickbuild.io/)

From personal experience, I found it functionally impossible to get a local
instance working when I tried a few years ago. I applaud someone else managing
to pull it off.

~~~
rosywoozlechan
Launchpad is also objectively more complex and hard to use than alternatives,
and subjectively I'd say it's ugly and looks dated. Launchpad isn't probably
something people want to use because of product design, and thus there's not
much activity around it outside of Canonical.

I think it would be silly to assume that a separate project that is liked
wouldn't get traction outside of Canonical because of their experience with
Launchpad.

~~~
galgalesh
> Launchpad is also objectively more complex and hard to use than
> alternatives, and subjectively I'd say it's ugly and looks dated

Launchpad is _really_ old though. When it was open sourced, there were very
few alternatives and those were often even more complex and harder to use.

I think part of the reason why it was almost never used was because it does so
much: project management, bug trackers, build service, package hosting, ISO
and distro building, ..

If you only need a few of these features, you are much better of using
alternatives with a smaller scope.

~~~
stubish
Launchpad actually predates Ubuntu :) A lot of the methodologies and practices
used to develop it (both good and bad) didn't even get names until years
later. I even hear monoliths are becoming fashionable again.

------
acgkmopvvgvmgv
It's not for nothing that Snap is considered dangerous by SUSE and is not
officially supported. They even fail basic upstream responsibilities.

[https://blog.linuxmint.com/?p=3906](https://blog.linuxmint.com/?p=3906)

> A year later, in the Ubuntu 20.04 package base, the Chromium package is
> indeed empty and acting, without your consent, as a backdoor by connecting
> your computer to the Ubuntu Store. Applications in this store cannot be
> patched, or pinned. You can’t audit them, hold them, modify them or even
> point snap to a different store. You’ve as much empowerment with this as if
> you were using proprietary software, i.e. none. This is in effect similar to
> a commercial proprietary solution, but with two major differences: It runs
> as root, and it installs itself without asking you.

> First, I’m happy to confirm that Linux Mint 20, like previous Mint releases
> will not ship with any snaps or snapd installed.

~~~
galgalesh
> Applications in this store cannot be patched, or pinned. You can’t audit
> them, hold them, modify them or even point snap to a different store.

This is not entirely correct. Distributions can use a "brand store" to have
complete control over which packages their users get.

> You can’t audit them

Many Snaps contain a build manifest in `/snap/snap-
name/current/snap/manifest.yaml`. This manifest contains a log of everything
that is used to build the package. For snaps built on Launchpad, this is
automatically enabled and includes a link to the Launchpad build log for that
snap. This is one of the build logs for the Chromium package, for example:
[https://launchpad.net/~osomon/+snap/chromium-snap-
firstrun-n...](https://launchpad.net/~osomon/+snap/chromium-snap-firstrun-
notice/+build/1071421)

Using Launchpad as the source of truth, you can be 100% certain that the snap
you're running is built from the source it presents. This is the same
infrastructure that builds and provides trust for Ubuntu itself.

The snapcraft build service uses Launchpad in the background, so any snap
built using that can be audited just like regular Ubuntu packages. Snaps built
on third-party infrastructure can enable this manifest using an environment
variable.

I don't know why Linux Mint is spreading such misinformation, but this is
harmful.

~~~
comex
> This is not entirely correct. Distributions can use a "brand store" to have
> complete control over which packages their users get.

By “you” I assume they are referring to users, not distributions.

~~~
galgalesh
Hm, maybe you're right. So in that case:

> hold them

Users have many ways to hold snaps temporarily. If they want to hold snaps
indefinitely, then they should install them using he `--dangerous` flag. That
won't give them any updates, but I'm guessing that's the point. They can
always get the latest version of the app manually using `snap download
snapname` and install it using `snap install snapname.snap --dangerous`.

> modify them

Just like a `.deb` package, users can unpack a snap, modify any file, repack
and install the modified version. Alternatively, you can unpack the snap,
modify any file and install the directory using "snap try". You can then
modify files and rerun the app without having to reinstall it for every
change.

> or even point snap to a different store.

The signing keys are baked into the Snap binary but the URL is configurable
via an environment variable. So users can change to a different Brand Store
without any issue. If they want to use a store with a different signing key,
they have to install a different version of snapd which is compiled with the
signing keys of the other vendors.

This isn't an insurmountable problem, but it is less flexible than apt, yes.
Although I think "apt remove snapd; apt install snapd-fsnap" is still pretty
easy..

------
war1025
Semi-related:

Does anyone else feel like Ubuntu has lost a lot of its momentum over the past
few years? I don't hear about things they're doing nearly as often anymore.

~~~
dyingkneepad
Things they're currently doing that benefit the larger Linux community as a
whole:

\- still engaging with vendors into making hardware work on Linux

\- they're contributing optimizations to gnome 3

\- their still massive user base is testing stuff, discovering bugs and then
those things get fixed upstream or at least get into Debian

\- making bad decisions so people jump off Ubuntu and go back to Debian, my
beloved distro

~~~
war1025
> \- making bad decisions so people jump off Ubuntu and go back to Debian, my
> beloved distro

Amen. Debian is the best.

~~~
ewzimm
When I fist started using Debian, it was a bit of a potato. It improved over
time but still felt a little wooden. Ubuntu brought a lot of people back into
the Debian ecosystem, ensured that it improved constantly to the point where
it's a corporate power buster, and I feel like the next release will hit the
bullseye for sure.

~~~
dane-pgp
Why did you squeeze so many release names into that comment?

~~~
type0
you would need to be a bookworm to know all of them

------
curt15
This is easy to explain if you think of it as a business decision. Why would
anyone pay $30000 for a custom "enterprise edition" snap store[1] -- which
among other features restores full control of updates -- if anyone could
easily set up their own snap stores?

[1][https://ubuntu.com/pricing/devices](https://ubuntu.com/pricing/devices)

~~~
galgalesh
I don't think open sourcing the store would significantly cut their sales.
Running a world-wide package distribution network in itself is an incredible
cost which many companies are willing to pay for. CentOS did not cut into the
sales of RHEL either, for example. It's useful to have someone to yell at when
things break.

Also note that there are already alternatives. I personally know a few
companies who built their own stores internally and it's actually very easy to
do so if you install the apps using side-loading.

------
clvx
I do like the snap concept, but some implementations are just not that great.
For instance, kustomize as snap doesn't let you read anything outside that is
not in the snap fs. Not even in --classic mode. A similar issue happens with
nextcloud which is good on paper, but if you tweak something inside the snap
fs it will be overridden in the next update(expected behavior); however, for
services that require mutable configuration there needs to be a way to
preserve that data (I tested that nextcloud behavior more than half a year
ago).

~~~
galgalesh
> For instance, kustomize as snap doesn't let you read anything outside that
> is not in the snap fs. Not even in --classic mode.

Classic snaps have complete access to the host filesystem. It is up to the
publisher, however, to request classic confinement. If the publisher creates a
`strict` snap, users cannot override this (because strict snaps would break
when their container and dependencies suddenly disappear)

> for services that require mutable configuration there needs to be a way to
> preserve that data (I tested that nextcloud behavior more than half a year
> ago).

Snaps have access to multiple locations to store mutable data like
`SNAP_COMMON`, `SNAP_USER_COMMON`, `SNAP_DATA` etc. Snaps can optionally also
access regular directories.

Afaik, Nextcloud stores its configuration in one of those directories. I think
what you experienced might be an issue with the NextCloud snap because snapd
itself already supports this.

------
Animats
Control.

1\. Get market share with free product.

2\. Start charging once monopoly is achieved.

3\. Profit!

~~~
kd913
Lol as if there is oodles of money to be gained from hosting a store like that
on Linux. We can see all these steam game publishers desperate to release
games to a community that is rather famous fo being cheapskates.

Also, snap existing doesn't hinder flatpak or appimage or debs or rpms.

~~~
teraflop
They aren't going for a model like Steam where they sell software to end-
users. The idea is to get enterprises hooked on using snaps to distribute
their software internally, and then charge them for private repository
hosting.

~~~
kd913
Then fair play for Canonical to get revenue streams from enterprise?

From my perspective the primary motivation seems rather simple in minimizing
the maintenance costs/testing of having to publish software for 5-6
distributions.

That to me seems more plausible than evil mustache twisting capitalist
reasons.

------
crashbunny
I tried not to interpret the article in the worst possible way, but I failed,
it feels disingenuous to me.

I don't think comparing ppa's to snaps is a good comparison.

ppa's have the disadvantage of potential dependency problems which might break
things like upgrades, and that has nothing to do with having a distributed
store.

snaps solve this and that has nothing to do with a proprietary single company
controlled store.

~~~
galgalesh
I'm sorry you feel this is disingenuous. I really tried to explain why there
is only one Snap Store from a neutral point of view. Let me know if you have
any tips to make it more genuine.

You are right that this has nothing to do with the dependency problems Snap
solves. Snap does many things differently but this article only focusses on
one to keep it relatively short.

This article doesn't try to present a comprehensive comparison and definitely
not between Snap and PPA. The article only focuses on the question why there
is only one Snap store. The answer to this question has nothing to do with
Snap bundling dependencies.

I also wrote a separate blog post about bundling dependencies here:
[https://merlijn.sebrechts.be/blog/2020-07-06-why-snap-
flatpa...](https://merlijn.sebrechts.be/blog/2020-07-06-why-snap-flatpak/)

That blogpost lumps Snap and Flatpak together since, for the sake of bundling
dependencies, the two technologies are pretty similar.

------
jamieweb
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 sort of typosquatted fake
version of the package.

When using Apt with the default repositories, this isn't a problem at all, as
only known, trusted packages are available. In other words, there's no chance
of someone publishing a fierfox or apahce2 package to try to typosquat
someone.

I don't even want to talk about the forced automatic updates either... these
make it essentially impossible to have a stable/reliable system for specialist
use cases, e.g. browser testing, bastion host, build environment, where
control over updates is very important.

On the sandboxing - it's good in principle, but rarely seems to be implemented
in a truly meaningful way, as ultimately once you have home drive access, you
don't even need to worry about escalating privileges as everything valuable is
probably in your home area! There's an xkcd about this somewhere...

~~~
xet7
> 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.

------
ISL
Debian user here, who has apparently missed the memo: What do snaps do that
apt doesn't?

~~~
spanhandler
Pollute your mount list and make your software start way slower and take up
more space. Also sometimes break or require intervention for basic operation
due to security restrictions on it.

The benefits are supposed to be that they're more secure, more portable, and
don't junk up your system with files strewn everywhere.

Personally I'm waiting for a better solution than anything we've seen so far
for the first of those benefits, and would prefer a cross-platform user-
oriented package manager like Homebrew or Nix (but better-supported-on-Linux
in the former case and with a UX less like studying for a math exam in the
latter) for the other two. IMO every solution to these problems on Linux
desktop currently sucks to one degree or another.

~~~
AsyncAwait
What's so impressive about Homebrew specifically?

~~~
kelvie
Also curious. I'm waiting, or even begging for something like flatpak on mac
os just due to the number of times pip/npm/python in general has broken due to
homebrew.

~~~
boogies
What's wrong with elementary OS? (pls don't kill me HN — Edit: yup, downvoted
for a simple question)

~~~
spanhandler
• Nothing available that's as lightweight and good as Apple's "office"-type
suite.

• Nothing as all-around good as Preview (yes, seriously).

• Worse battery life, partly due to worse OS optimizations and partly due to
not having Safari available. Solutions to this in Linux that actually yield
good results usually involve hard-capping performance at a pretty low level,
IME.

• Little things like screen recording and screenshot capabilities not being as
nice for basic use, out of the box.

• AFAIK not only is the default English keyboard on Linux far worse at the
task of writing in English than that on macOS, there's not a single
alternative layout that's close to as good as the Mac default. Yes, I'm dead
serious about this, and frankly it's friggin' weird they'd have such a
significant advantage on something like that in the year 2020, and I _really_
wish other operating systems would catch up because I _do not_ like being
forced to use Apple products just so my experience composing documents in
English isn't bad. I do not understand how they still have such a large
advantage here, but somehow, they do. Totally baffling.

• If you do anything serious with software-UI-related graphic design, or work
closely with people who do, you _pretty much_ need a Mac because odds are good
you'll be using at least some mac-only software or have things shared with you
that work only in mac programs.

• You lose a variety of time-saving integrations with i-devices, if you're
someone who takes advantage of those.

~~~
PaulBGD_
I'm not understanding the English keyboard complaint, am I missing something?

~~~
spanhandler
Look up how you type: those • characters I used in my post, an m-dash (—), a
c-cedilla (ç), a german double-S (ß), basic accented characters for various
Western European languages (we have many, many loan words and phrases from
those in English—façade, résumé, áñ∂ §ò öñ), punctuation for French and
Spanish (no, you don't strictly need these for English—but in practice,
depending on the register you're writing in, actually you do), major world
currency symbols ($, £, €, ¥, ¢), basic mathematical symbols and mathy Greek
letters (≤, ∑) and so on.

Look up how you do that on US English keyboard layouts in macOS, Linux, or
Windows. Then check AltGr and US International alternative layouts for the
latter two. Marvel at how macOS manages to crush all those options in
usability with their default, without affecting the experience for someone who
doesn't need those _at all_. Join me in wondering how no-one else has at least
matched them on this, which _is not_ some recently-added feature in macOS, but
is practically ancient in computing terms.

~~~
boogies
> Look up how you type: those • characters I used in my post, an m-dash (—), a
> c-cedilla (ç), a german double-S (ß), basic accented characters for various
> Western European languages

No thanks! I already new how to type — (Compose - - -), and I was able to
guess how to type the others simply by trial and error in less time than it
would take to duck/google how to type them:

Compose + . + - → · (close enough for me Edit: Compose + . + = → •) ┃ Compose
+ c + , → ç ┃ Compose + s + s → ß

Compose + e + ` → è ┃ Compose + e + ' → é ┃ Compose + ` + e → è ┃ Compose + '
\+ e → é

Bonus: Compose + - + > → → ┃ Compose + = + / → ≠ ┃ Compose + / \+ = → ≠ ┃
Compose + : + ) → ┃ Compose + L + L + A + P → (Edit: HN seems to have stripped
out the last two, a smiley face emoji and the \\\// / Star Trek/Live Long And
Prosper hand. So I guess the compose key can type more characters than HN even
allows.)

ß°ηυ5 þē 5€¢•ηⅾ: Pressing the alt key reveals underlines under selectable gui
elements. Press any letter that's underlined (while still holding alt) to
activate the element (menu item, button, etc.). Try this in every GUI you use
regularly and then race a macOS user stuck with reaching for a trackpad or
mouse everytime they need to click something. Јоⅰη ⅿе ⅰɳ wօɳԁеrⅰηg Һօw ɳօ‐օɳе
аt Аррⅼе tҺօυgҺt tо аⅾԁ tҺіѕ, wҺⅰϲҺ іѕ ɳօt ѕоⅿе rесеɳtⅼу‐аԁԁеԁ fеаtυrе ⅰɳ
ԌΝU⁄Ⅼіɳυⅹ, Ьυt ⅰѕ рrасtіϲаⅼⅼУ аɳсіеηt ⅰη ϲоⅿρυtⅰɳg tеrⅿѕ (¡ΝаѕtУ Wⅰηԁоwѕ,
рrеҺⅰѕtоrіс Wіηԁօwѕ _95_ , Һаⅾ tҺеѕе υηⅾеrⅼіɳеѕ аⅼwаУѕ ⌵іѕⅰЬⅼе!).

~~~
spanhandler
Great! Linux, I assume? _goes looking_ OK yep, I'll enable it and start re-
training myself on that, for when I'm not on mac. It's not quite as quick for
most of the things I need frequently, but seems tolerable.

Remaining questions: 1) why would the default be bad? Like, why ever would one
make a default bad if there are non-bad options? Especially for something
everyone should want to be good on a computer, like composing text in the
user's language, and 2) ugh of course even once enabled the default compose
key is bad (there's a theme here) and both enabling it and configuring it
depends on which WM/DE you're in, Wayland vs. Xorg, and so on, and from some
googling it's even possible to run into inconsistent behavior between
different friggin' GUI toolkits under the same DE.

OK that second one is a comment, not a question. Still.

I'd _recently_ googled the problem of (specifically) typing an em-dash on
Linux, and just tried it again, and sure enough this solution doesn't come up
until the sixth hit, in an unassuming Google documentation style guide. "Just
memorize a 4-digit number" is the overwhelming answer to that question, on
search engines, for some reason, despite plainly being awful. Maybe the
configuration hurdle and bad default behavior is why that's the go-to
solution, I dunno.

[EDIT] none of the above irritation aimed at you, I hope is clear, and
sincerely, thanks for the pointer.

~~~
zajio1am
1) why would the default be bad? Like, why ever would one make a default bad
if there are non-bad options?

Because it is not bad, it just chooses different advantages and disadvantages.

Right Alt could be configured to do regular Alt modifier, or could be
configured to enter additional characters (Alt Gr - third/fourth level).

The first case has advantage that Alt-based keyboard shortcuts on right side
can be conveniently entered by one hand. That is why there are Shift, Control
and Alt on both sides of keyboard.

Second case has advantage that you can enter more characters, but entering
rightside Alt-based shortcuts is more awkward.

Conventionally, US keyboard uses the first approach (as there are less need
for entering more characters), while many non-US keyboards use the second
approach.

Also, why Compose key is not accessible by default? Because there is no
Compose key on common PC keyboard (in constrast to some old Unix keyboards).
Therefore, Compose key need to 'steal' some existing key, which is
problematic, because users expect existing keys to work as expected. I
personally use Menu key as Compose key, but other users may have different
expectations.

------
justaguy88
What does snap do that flatpak doesn't?

~~~
gjsman-1000
Well, if you are building an IoT Device, lots of stuff for reliability.
Automatic rollbacks, self-repairing, immutable FS...

For a desktop user, honestly, very little.

~~~
AgentME
That reliability stuff sounds good on desktop too. I don't exactly enjoy re-
running apt after it has mysterious failures halfway through installs.

~~~
gjsman-1000
You might find Fedora Silverblue fascinating. It's an OS that uses Flatpak for
Desktop Apps exclusively, which disposable "toolboxes" for non-Flatpak apps.

~~~
m4rtink
And all the systrm stuff is immutable and managged by OSTree. This makes it
posdoble to diff only download a new system state and then atomically switch
to it after reboot. And if you hit any issues with it, just boot to the
previous one (you can have multiple previous states).

------
hajile
Have they fixed the unearthly slowness of SquashFS? Is there a filesystem out
there that is slower?

~~~
galgalesh
The fault isn't SquashFS itself but the compression they use. They use an old
compression algorithm by default to support older kernels. They are working on
optionally enabling quicker compression on distros that support it though.

See this for more info: [https://forum.snapcraft.io/t/squashfs-performance-
effect-on-...](https://forum.snapcraft.io/t/squashfs-performance-effect-on-
snap-startup-time/13920)

------
inshadows
> Snap is designed so each device only connects to a single store for three
> reasons: > users can easily discover new applications, > developers can
> easily publish their apps, > and developing Snap itself is easier.

Just a PR bullshit to cover for lack of freedom and need for control.
Disregard.

------
Awelton
The better question is why is there a snap store? With flatpack and appimage
already working well, why muddy the waters with another offering, much less
one that it awful.

------
johnisgood
God, I could not hate Snap more. At least a .snap file can be mounted as a
SquashFS and salvage what you can to run the program without snapd. Unrelated,
but it is curious that some applications I have encountered depended on some
proprietary library. To the bin it went. :D

------
richardfey
The author mentions popularity as a justification and good reason to go with a
central snap store. I am baffled.

~~~
galgalesh
(author here)

I'm not sure what you are referring to exactly, where do you think I say that?

These are the reasons I talk about in the blog:

* users can easily discover new applications, * developers can easily publish their apps, * and developing Snap itself is easier.

~~~
richardfey
> That said, I’m pragmatic about the proprietary back-end. DockerHub and
> GitHub are insanely popular and they are completely proprietary.

------
seaghost
I highly recommend switching to Pop!_OS.

------
snicker7
It does not seem that the author is affiliated with Canonical. Ideally,
Canonical should be the ones defending their product.

IMO, it is okay for the backend to be propriety as long there is a published,
easy to implement protocol for talking to snapd (along with an accessible way
for clients to configure snapd). Otherwise, there is lock-in to the service.
It's not just the FOSS community that should be concerned, but business users
as well. Do you want to internally distribute in-house snaps via Canonical's
servers?

> DockerHub and GitHub are insanely popular and they are completely
> proprietary.

These are arguments against, not for, using these services. And many
proprietary SaaS companies sell installations on on-prem air gapped servers.

~~~
galgalesh
Canonical has defended their product in many places. This article contains a
lot of the same info, for example: [https://www.techrepublic.com/article/why-
canonical-views-the...](https://www.techrepublic.com/article/why-canonical-
views-the-snap-ecosystem-as-a-compelling-distribution-agnostic-solution/)

------
zubairq
There is only one Snap store as this is what Microsoft is actually buying if
it buys Canonical and turns the Snap store into the Microsoft store.

------
Ericson2314
Ahaha crap on all sides. Please come to Nix (or, hell, GUIX) and side-step
_all_ these issues.

~~~
galgalesh
Nix is really cool! You can actually use Nix to build Snap packages! Not sure
if that's actually used a lot though.

One of the advantages of Snap over Nix is that snap has security builtin. Snap
is built to support a store where anyone can publish any application without
curation. Nix Flakes look really cool for third-parties to "publish"
applications for Nix, but I wonder how they will do security..

In Snap, the default permissions of an app are stored and distributed out-of-
band with the package itself. The package defines what permissions it _can_
use and the declaration defines what permissions it is _allowed_ to use by
default. Users can then override the default permissions.

You could get the same level of confinement in a Nix package, but then the
package contains both the app and the confinement, so the packager or software
provider gets to decide what permissions a package has on your system. Any
idea how Nix could address this?

~~~
Ericson2314
The _building_ of nix packages is completely sandboxed and secure. The running
of them is currently an after-thought.

\- [https://spectrum-os.org/](https://spectrum-os.org/) is a _big_ idea for
secure running of applications, which leverages Nix for some things.

\- I would like to see some CloudABI/Capsicum experiments, as anything that is
not capability based seems baroque, difficult to, ill-fitting the problem at
hand, and generally going to end in tears.

\- There is currently some wrapping around systemd-nspawn which could be
improved.

BTW when I say "The running of them is currently an after-thought" this isn't
as bad as it sounds. I would say all the good solutions are not the scope of
Nix, but instead the scope of NixOS, Nix home-manager, nix-darwin, etc. Still,
a real problem that deserves a solution. Thanks for bringing it up.

------
johnisgood
If I wanted spyware, I would just install Windows 10, really. Screw Canonical.

------
liability
Because Shuttleworth has notorious Apple-envy.

------
zaro
This article is disingenuous at best!

~~~
galgalesh
Author here. I'm happy to address any issues in the article. Let me know if
there are any issues.

