Earlier quoted context omitted.
> 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.
Why is there only one Snap Store?
41–50 of 362 posts
Re: Why is there only one Snap Store?
#42Earlier quoted context omitted.
> 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.
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?
Re: Why is there only one Snap Store?
#43What does snap do that flatpak doesn't?
Flatpak can not currently run on servers, only desktops. I'm not sure if there are plans to change this, if anyone knows I'd be interested in finding out.
Re: Why is there only one Snap Store?
#44Earlier quoted context omitted.
The LXC/LXD folks at Canonical are doing great work with adding kernel features for namespaces etc. I think the "problem" is that Canonical has figured out - correctly - that all their worthwhile stuff needs to be done upstream of Ubuntu. Even their packagers know to try to get things in Debian first and to reduce diffs when they can. Unfortunately, that means that the unique Ubuntu secret sauce is all the weird stuf…
I got so excited about LXD ... until I found out it requires snap. My first "cup of ubuntu" was well over 10 years ago now and I've always wanted to see it succeed. It's repeated squandering of so much potential. Edit: I was referring to LXD usage on Ubuntu-20.04 and versions going forward (I should have made that clear in the post). Sure, snap isn't technically required since you can "change distros" or "compile it…
I think Arch has it in their repositories, for example.
Re: Why is there only one Snap Store?
#45Earlier quoted context omitted.
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 bud…
Re: Why is there only one Snap Store?
#46Earlier quoted context omitted.
I'm curious to try GNU Guix, does it sufffer from the same problems as Nix? (Edit: looking at https://guix.gnu.org/en/videos/everyday-use-of-gnu-guix,-par... from the top of https://guix.gnu.org/ , basic installation and removal of packages looks exactly like apt, literally the same command line with 'apt' replaced with 'guix' and 'sudo' unnecessary because you can install packages per user.)
I admit I've not checked and have just assumed the package list is both ideologically- and mindshare-crippled, due to the GNU on the name and the seemingly low rate of use, respectively. Nb I think free software goals are great and all but if I need Slack for work or need my proprietary wifi card to work using a binary blob then I f#cking need those things, and it's nice if my package manager can install them for me.…
Re: Why is there only one Snap Store?
#47Earlier quoted context omitted.
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.
"many packages" as in "less than 10 out of 10s of thousands".
Re: Why is there only one Snap Store?
#48Earlier quoted context omitted.
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 thos…
What's so impressive about Homebrew specifically?
2) Command line UI is alright. This should be a given but isn't always.
3) Can manage proprietary software for me. There's almost nothing I use (maybe actually nothing?) on my Mac that Homebrew doesn't have an up-to-date package for, aside from Apple-provided apps.
4) Enough people use it that despite being a semi-free-for-all community-run thing packages are pretty much never broken, including the proprietary ones. I'm also continually surprised by how often I find some obscure thing with five stars on Github, want to try it out, and sure enough, there's a Homebrew package.
5) Lets you manage your packages with ordinary user-level permissions. No root elevation required.
6) I can clean practically all of what it's done and get back to a nearly-vanilla system (with the exception of some of the proprietary apps) by deleting one directory. My system and GUI will still boot like nothing's happened. IMO keeping your user-level packages strictly separate from the system-level ones, and managed totally separately, is absolutely the right way to go. I didn't realize how much I wanted this until I started using Homebrew on a Mac, after many many years of Linux package management.
7) It leaves system-level packages that it upgrades alone, so doesn't break core system stuff (I would fucking love this to become a norm on Linux—system uses and assumes latest LTS version for stuff like Python, but I can install whatever version I like for my own use, without affecting that whatsoever and without having to use a different goddamn version-management tool for every single language)
8) I'm pretty sure you can have more than one version of something installed at once and there's a command to switch between them (juggling symlinks, probably), but my recollection of this is vague and may be wrong.
9) If you're actually doing multi-user on your desktop/laptop I think it lets you have per-user install directories and active packages—but I don't really know anyone who does this, and haven't known people to share a computer, really, since over 15 years ago. Amusingly enough, iPads, with practically nothing resembling multi-user support, are the exception to this use pattern, as those seem to get shared among members of a family all the time.
Bad things:
1) Requires Ruby (seems like a dumb complaint, I know, but I hate installing an entire scripting language for a single command line tool, and no not all Linux distros ship with Ruby by default, far from it)
2) I dunno if it still does (I'm working mostly on Debian now) but for approximately forever it's had a completely braindead default for how often it auto-updates its package list when running other commands, and you had to go change that every time you installed it on a new machine so you'd not rip your hair out in frustration when your command to install a package was delayed because it'd been a whopping 16 minutes since the last time it checked for updated packages. Why the hell this didn't default to, like, 12 hours or something is entirely beyond me. AFAIK everyone hates the default behavior, to the point that it's become a common jokey-reference among Mac nerds, and I've never been able to figure out why anyone would want it.
Re: Why is there only one Snap Store?
#49IMO, 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.
Re: Why is there only one Snap Store?
#50Earlier quoted context omitted.
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 bud…
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.