Ubuntu 23.04 – 'Lunar Lobster'
zdnet.com
zdnet.com
I did couple of months ago clean ubuntu 22.10 install. Somehow curl was installed from snap - of course I had problem saving curled files due sandboxing. Installed mosquitto2 (MQTT server) - of course it did not read my custom confs from /etc/... anymore - due sandboxing. Installed Libreoffice from snap - it Calc (excel alternative) was exctremely slow somehow - switched to Libreoffice from APT repo - it was fast as it should be.
and to not start with the autoupdate nonesense that you can not disable.
I have been ususing Kubuntu since 2010 and thinking of switching to some other distro with KDE and all because of SNAPs
I really dislike snaps.
Ubuntu, on the other hand, will sneakily install snaps via apt.
It looks like that flatpaks have mostly won the desktop market, but on the server side docker and snaps are both really nice.
In fact, I'm in the same camp. I'm imminently replacing a very nearly EOL 18.04 install with Arch. I've tried a non-trivial amount of distros over the course of my Linux days (since Fedora Core 5) and Ubuntu has probably seen the most install time over that period, but my time with Ubuntu is now at an end. Snaps suck.
I specifically moved to 20.04 and 22.04 when they touted this. I don’t see anything amazing here though, even on the desktop side. Eventually I still had to manually configure smb, sssd, nss, and chrony to make AD auth work natively in both my lab and prod networks.
Am I missing something?
Note: I’m not a landscape user or whatever the new version of their management system is.
There's a good synopsis of what's new in this release here:
https://www.howtogeek.com/883728/whats-new-in-ubuntu-23-04-l...
Edit: I didn’t know about the new updates to snap and pinning. Thanks for the info!
- As a user: Snaps are annoying and don't work like a native app. It creates a new folder in my home directory, has little very consistency with other apps (even other packages of the same app), and feels generally unsuited for desktop use. If I'm going to use any of these godawful statically-linked-runtime package managers, it won't be the proprietary one.
- As an admin: Snaps are alright. If you just need to insta-configure something and are extremely lazy, it's a faustian deal pre-installed on every Ubuntu machine. As loathe as I am to admit it, most snaps are a cinch to install compared to native packaging or even Flatpak.
However, Snaps do an impressively poor job of implementing a sandbox.
Can you elaborate on the "necessary" part? I'm able to accomplish my computing goals without snaps.
A sanely-designed OS will provide either capabilities or sandboxing - the tech has been around for decades, and they're more needed than ever in the 21st century with its abundance of malware.
You can run something like Qubes if you want better isolation.
That's not an attitude that someone working in security would have.
It doesn't matter if "critical data is encrypted" if a keylogger is present when you enter your password. It doesn't matter that you've "never had a malware infection" because millions of other people have. And it doesn't matter that you're "pretty careful" because one of the core tenets of information security is that people are imperfect and it's best to remove as much of the human element as possible.
These are relatively basic facts that someone with a few years of experience would know.
> You can run something like Qubes if you want better isolation.
Qubes is sandboxing - but the thread topic is about sandboxing on Linux, and the need for it in OSes in general. Security should come built-in, not as something you use a special OS for.
Security is never an absolute, it's always a trade off between many different factors, such as usability, protection, and cost. You have to take a risk based approach. People who work in security have to do this on a daily basis.
For myself, the sand-boxing trade off is not worth it on my own desktop. Everything I have tried has significantly interfered with being able to do what I need to. If we were talking about what was needed on a critical, internet-exposed system, my answer might be different.
On the subject of what a good secure OS would look like, I studied capabilities extensively when I did my MSc in Info Sec. The E language and the EROS operating system were absolutely fascinating. Getting rid of ambient authority would be awesome. I have worked with people who worked on CHERI, which is also a really promising approach to use capabilities for better memory protection - and has the advantage that it can work with code not written for it.
When something like that is available, I'll be one of the first people trying it out!
Upstart -> systemd
Unity -> Gnome 3 Shell
Mir -> Wayland
Snaps -> flatpak
I’m not saying Red Hat is wrong to do this, that’s the nature of healthy competition and we all benefit from this.
And GNOME 3 as well? Unity was a reaction to GNOME 3's big changes.
Either way, I agree that competition is better.
Wayland technically was before Mir, but existed as blueprints and ideas back then. Shuttleworth tried to influence its design for his vision of linux desktop, but got rejected, so Mir was created. Mir became useful way before first implementations of Wayland, but Shuttleworth idea to expand Mir and Ubuntu to phones resulted in feature creep, lack of funding and eventually to project failure.
Gnome shell was also released after Unity. Both were influenced by MacOS LaF. The problem with Unity was that it was based on gnome 2 and compiz, that was a good compositor back in the days, but a dead end as a technology, as compositor should’ve been implemented on a lower level and be an integral part of DE. Shuttleworth started Mir and new Unity based on that, but both sank and Ubuntu had to revert to gnome-shell that became useful and more performant than earlier versions.
So while Canonical might have good initial ideas, the way they manage projects really kills them, e.g. snaps properly opensources might have been successful, instead they enforces the use of their proprietary server and ignore community requests (like moving /snap to /var/snap or making it configurable or allowing different servers/sources for snaps, while you can relatively easily make your own flatpak server and have users add the repo to their systems).
It causes problems on Windows with WSL2 as well.
And I'm not the one that criticizes Canonical just for seeking its own solutions, in fact, I liked things like Unity and Upstart. But for me, snaps came to solve a non-problem.
1. They don't scale, space-wise; libraries can take very considerable space
2. Permission issues
3. Configuration issues
4. Startup speed issues
Compared to a trusted (I stress "trusted") apt repository, for my use case, they have only downsides.
This is also a ridiculous dismissal. Snaps don't increase your startup time because it's an intrinsic limitation of the technology (e.g. like how internet connectivity necessitates higher power draw), but because they're designed badly. There's no reason for them to act like that, and people are rightly upset at it.
Without reverse engineering the protocol, it is impossible to host your own snap repository.
Other companies have and do most their own snap stores.
According to this Ubuntu documentation [3], the "dedicated snap stores" are just Canonical-hosted snap stores with more granular control, which isn't equal to hosting your own snap store.
There is an open-source implementation of snap store [4] which (assuming it works and someone is using it) would fall under "reverse engineering the protocol" part of my post, because the guy who wrote it reverse engineered the protocol [5]. Assuming that it works, this is the only part of my post that is not completely accurate - it is technically possible to host your own snap server without reverse engineering the protocol yourself, but that's only because someone else already did it. But Canonical could change the protocol any time and render this implementation obsolete, as they've done in the past [6].
[0] https://hackaday.com/2020/06/24/whats-the-deal-with-snap-pac...
[1] https://askubuntu.com/questions/1383583/is-it-true-that-snap...
[2] https://merlijn.sebrechts.be/blog/2020-08-02-why-one-snap-st...
[3] https://ubuntu.com/core/docs/dedicated-snap-stores
[4] https://github.com/freetocompute/kebe
[5] https://forum.snapcraft.io/t/announcing-project-kebe-open-so...
So, before, you said:
> Feel free to provide information that proves otherwise.
OK, then, I will.
Here's a story I researched and wrote myself about a 3rd party store:
https://www.theregister.com/2022/02/04/rudra_sarsawat_ubuntu...
Here's his announcement:
https://forum.snapcraft.io/t/lol-an-open-source-snap-server-...
I attended last year's Ubuntu Summit. There were multiple talks on Snap. Here's my report:
https://www.theregister.com/2022/11/09/canonical_conference/
One talk was by Viktor Petersson:
https://www.screenly.io/blog/author/vpetersson/
This is his company, Screenly:
Screenly does autonomous remote managed digital signes, running Ubuntu Core.
As you probably know Core has no other packaging format than Snap:
https://www.theregister.com/2022/06/17/ubuntu_core_22/
So Screenly needs to distribute updates as Snaps, and in his talk, Petersson talked about the issues around that in some detail, including that Screenly runs & hosts its own private Snap store for this, and that it's built 100% from components in the Ubuntu repos.
I also talked to the developer of the Snap format, and the Ubuntu desktop lead, and they told me that they keep their store closed as a security measure, but it's perfectly possible to run your own.
I just want that, I guess it means back to Debian?
I’m not excited or interested about spending time dealing with a package manager.
I personally can’t think of anything software related that Ubuntu provides over Debian for normal desktop users. Only the Ubuntu 6-month release schedule can be a bit nicer.
This was the same issue that passed onto linux based android os, requiring updated blobs for drivers, held older android devices to older versions.
And same issue for ARM flavors.
Same btrfs/snapshotting configuration on arch and never had any issues so far...