this post was submitted on 08 Jul 2023
232 points (93.9% liked)

Linux

47356 readers
1422 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

A new ‘app store’ is expected to ship as part of Ubuntu 23.10 when it’s released in October — and it’ll debut with a notable change to DEB support.

you are viewing a single comment's thread
view the rest of the comments
[–] CassiniWarden@infosec.pub 8 points 1 year ago (4 children)

I've been using more and more flatpaks lately on arch and fedora based distros, i have no idea how snaps compare but seems similar? Seems an odd push from Ubuntu, but could make more sense than deb packages for non techy users perhaps?

[–] ISMETA@lemmy.zip 12 points 1 year ago (1 children)

A big issue for me with snap is, that the server side software is proprietary. So it really really does feel like they are trying for lock-in

[–] avidamoeba@lemmy.ca -2 points 1 year ago (1 children)

The server side is fairly trivial and has already been prototyped separately.

[–] knewe@discuss.tchncs.de 3 points 1 year ago (1 children)

If it is trivial, why is Canonical keeping it proprietary?

[–] avidamoeba@lemmy.ca 3 points 1 year ago* (last edited 1 year ago)

Because it's extra work to make it open source and few outside of Canonical are interested in contributing. Open sourcing an existing component and maintaining it as such has non-trivial overhead. In that case that work is better spent on other, higher priority items. My guess is that they've gauged that the cloud end being open source won't move the needle on who uses Snap and Ubuntu so they've deemed it low priority. Personally I'm using Debian and Ubuntu and therefore Canonical has root on some of my systems. Given I can implement a cloud end for Snap, it bares very little importance to me that today the cloud end isn't open source since it's run by the folks that have root on my system anyways as well as supply all other packages on my Ubuntu systems. In fact we don't even know what the cloud end for the apt repos is. It could easily be Sonatype Nexus. For me the important bit is the client and installer side of Snap since I can't implement that in a relatively small amount of time. :)

[–] avidamoeba@lemmy.ca 8 points 1 year ago* (last edited 1 year ago)

Ubuntu / Canonical were working on Snap for some years when Flatpak came on the scene. They've been shipping Ubuntu bits using it since 2016. In addition to the legacy, Snap is more versatile than Flatpak in that it can be used to package pretty much anything, including system bits. It's also had a secure sandbox from the start. Changing to Flatpak would be a functionality downgrade for Canonical and Ununtu maintainers using Snap. In addition Flatpak can be used along with Snap on Ubuntu so there's no need to not use both for whoever finds that useful. Snap lets Ubuntu ship software using less work, which means more up-to-date bits in Ubuntu. Users can install other software via Snap or Flatpak, whichever they find more useful.

[–] AProfessional@lemmy.world 7 points 1 year ago (1 children)

Snap is very similar just not portable to most other distros. It makes a lot of sense both for users and for vendor lock-in.

[–] Vittelius@feddit.de 3 points 1 year ago (1 children)

Snap is portable to other distros, look at the official website and you see a list of distros, you can use snap on. That doesn't mean that there is no vendor lock-in, just a different kind. Snap as a format grew out of Cannonicals effort in the mobile field. Snaps where supposed to be the truly convergent successor to click, the packaging format used by Ubuntu Touch. And this history is baked into its DNA. It's right there on the snapcraft website: "The app store for Linux". As such Cannonical has always courted proprietary software and/or software by big companies (VS Code was first released as a snap for a reason). I think that they have always have had an eye on one day adding app payments and the sweet, sweet 30% cut they can take from every sale

[–] AProfessional@lemmy.world 4 points 1 year ago (1 children)

The sandbox requires apparmor, so doesn’t work on anything else by default except OpenSUSE I think.

[–] Vittelius@feddit.de 2 points 1 year ago (1 children)

Solus and Manjaro are shipping Snap installed by default and I've never had a problem installing snapd on fedora. All I ever had to do for that was run a single standard dnf install. Apparmor doesn't pose the problem you think it does

[–] AProfessional@lemmy.world 2 points 1 year ago* (last edited 1 year ago)

Running software unsandboxed is breaking most of the value of snap. Not only is it insecure many of the portability promises are actually broken and it can load incorrect libraries, etc.

Fedora deleted snap from its repos years ago then it returned. It is a broken mess.

Canonicals response has been: We don’t care, fix it yourself.

It is an awful non-portable solution when a real portable solution exists.

[–] piranhaphish@lemmy.world 6 points 1 year ago* (last edited 1 year ago)

In my experience, performance of snap apps is just abhorrent. The consume a huge amount of disk space and, whether it's due to that or not, they have extremely long load times.

Principles aside, this just makes them unusable for me. I use flatpak when there's no other option, but strive to use deb either natively or through PPA.