In a surprise move, Ubuntu developers have agreed to stop shipping Flatpak, preinstalled Flatpak apps, and any plugins needed to install Flatpak apps through a GUI software tool in the default package set across all eight of Ubuntu’s official flavors, as of the upcoming Ubuntu 23.04 release.
I have said and will keep saying this, Snap continues to be one of the worst things Canonical has tried to pass off as “production ready” at least in recent times, and every time they push more for it makes me consider them even more of an untrustworthy distro vendor.
My personal experience with it is that I had to nuke it off the computers I maintain last time we updated Ubuntu to the new release (unfortunately I don’t control what OS we’re using, otherwise Ubuntu would have been gone faster than you could say “Snap”), because these computers have user homes on a network drive, which isn’t under /home, and snap just flat out refuses to work when that is the case.
It wouldn’t even be such a problem if they hadn’t removed Firefox among other things from their repositories, but as it is right now, there’s no way to run Firefox on Ubuntu without mucking around with PPAs if your user home is not under /home. This bug about that has been open for 7 years!
That said, I think this is fine considering Flatpak is still going to be available in the repositories, just not installed by default. I’m much more a fan of “install what you need”, anyway. (But then again, that’s not the style of distro Ubuntu wants to go for.)
I’m okay technically with Snap, and I appreciate that it can do CLI programs as well which Flatpak can’t (to my knowledge. My issue with it is that Canonical has dug their feet in on making their store the default and only package source for everyone. It’s clear to me that they want to be the gatekeepers of software on Linux.
Yeah, it definitely does CLI applications better, I think Oracle uses it for some of their system monitoring services on Oracle Cloud for example. At least the snap issue I linked is also still open unlike the issue for better CLI handling for Flatpak which was closed without being fixed and makes the guy who closed it look like an arrogant asshole.
To be honest I don’t really like either of these because they both have big flaws like that, and of the three major “standalone app formats” I prefer AppImage the most simply because I can just download those without needing to install some other daemon first.
@2xsaiko Was this in response to my response to someone asking about new distros? New to Mastodon!
Haven’t noticed the snaps much, but when I have, it was something weird that made me think it probably wouldn’t have happened if I hadn’t installed the snap… probably my aversion to learning something new and unrelated. I absolutely hated systemd when it first got pushed by Redhat, but I’ve come around.
Yeah, not liking the tone of that developer. Maybe needs an LLM-bedside-coprocessor. ;)
@soulrx@mastodon.social It’s in response to this comment. Looks like Mastodon doesn’t really deal well with Lemmy comment threads (and I think I have to explicitly tag you for you to see it?) :P
Now do the same with snaps.
Probably the whole point is just to clear the field for their snapstore
Yeah, I know. Still, we can make it clear what we think about that. 😉
Lol. Won’t happen :D :D :D
😞
@winnie snap is not so mature as flatpaks yet. Dont know if its really a nice descision.
No, it’s not nice decision. It’s more political decision, to force Ubuntu’s own solution instead of alternative.
(I’m wondering if you would be notified for reply in mastodon?)
@winnie @jcbritobr thats usually the case for mastodon when someone replies to your post.
Yeah. But Lemmy doesn’t add @username to it’s replies.
@winnie
It shouldn’t matter. Mastodon users should get notified when you reply to their post even though they aren’t tagged in it.At least that’s the case for me on Friendica but I remember the same behaviour from back when I used Mastodon.
Business as usual considering their history of Unity and Mir, so.
but how is this solution the best business wise?
arent the development and maintenance costs of snap are currently outweighing the income?
how can an own environment be monetized in the open source realm?
Wait, how did you view this post via Mastodon? I know both Lemmy and Mastodon use ActivityPub but the UX and urlpatterns are quite different and client-specific. What is the format of the link you used to view this?
I also demand answers. Should I be able to see Mastodon posts via my Lemmy/wefwef?
I found out in the meantime. You can find communities from Lemmy on Mastodon using the
@communityname@serverpattern. So@kde@lemmy.kde.socialwill find this community. On Mastodon it’ll appear as a user boosting every post (both top post and comments) and that way you can find individual comments.It isn’t great, the UX is clearly different and not made for each other, but it works and you can favourite or boost individual posts with it.
Interesting. I was able to find a few big Lemmy communities on Mastodon. But I couldn’t find my tiny instance community.
I wonder what I need to do to get my own instance to federate with Mastodon?
The instance needs to have https://github.com/LemmyNet/lemmy-ansible/pull/114 applied, it might not be in the version you are running yet.
Flavor leads (apparently) agree
Press X to doubt
Ubuntu asking its flavors to stop using something because it doesn’t is a head scratcher. Flavors regularly use things Ubuntu doesn’t, things you could argue are more intrinsic to an “Ubuntu experience”, like installers, login managers, icon themes etc. Why single out Flatpak?
IMO Canonical wants to make snap like google play, where people sell stuff and they take a 20-30 percent commission
The most popular non-Canonical derivatives, Linux Mint and POP OS, have both totally rejected and vocally criticize Canonical’s bullshit, Snap or otherwise. This isn’t going to make the fall in line, this is going to make them finally get serious about ditching Ununtu and switching directly to the upstream Debian base.
Yup. S76 drew a pretty clear line in the sand when they went all in on Flatpak. I’m glad some derivatives have the backbone to not back Canonical’s decision making.
by making it clearer about what an “Ubuntu experience” is.
The user experience will be worse, because they can’t use Flatpaks without jumping through extra hoops.
So, I guess, a “Ubuntu experience” is a bad experience. Not going to argue with that.
Ubuntu is the stepping stone from Mac/Windows to Linux. Like the tutorial level. It’s also one of the most “corporate” Linux OS vendors outside of RedHat. Of course it’s shitty lol.
Of course it’s shitty lol.
It shouldn’t be, though.
This is bizarre. Snap has improved a tiny bit over time, but it continues to not be that great. Meanwhile, flatpak is miles ahead. Things are generally just smoother and less annoying, even when Snap is working as intended.
Personal anecdote: I was having no end of trouble with Inkscape, it was just not working, very unreliable, all sorts of very odd issues. It got worse and worse over time to the point where it didn’t even seem to understand paths to open files anymore, if it even felt like opening that day. I tried reinstalling, clearing the config, all sorts of things. I suspected maybe the version of Inkscape Snap was giving me might have a bug in it so I was looking around for alternative ways to install an older version and then for some reason I tried Flatpak. It was like some kind of magic. Totally night and day. All of a sudden Inkscape had absolutely none of the issues that the Snap version had. It just worked. After that I realized that it hadn’t been a bug in that version of Inkscape at all, it was just Snap.
I haven’t had any issues with any other Snaps, but that incident really opened my eyes to just how bad things can get if a program isn’t packaged correctly.
Omg why?? It just gets worse.
It’s because Canonical has a vested interest in pushing the solution that they spent money developing.
As much as I appreciate everything that Canonical has done for Linux, this is the problem with trusting for-profit companies in the open source realm. Profit is their motivator. They don’t care that flatpak has better performance than snap, they just know they spent money developing snap, so they have to force it onto their users, despite it being the inferior tech.
In a surprise move
No surprise to me. Canonical has been headed down this path since they started losing popularity parity with flatpak. Seems like they’re pushing for vendor lock-in.
@winnie flatpak runs much better than snap. im off ubuntu.
“surprise move”
Flatpak was a problem. This is a good move.
And Snap isn’t? If you think Flatpak is bad how exactly is locking you into an objectively worse universal package manager the solution?
yeah, Snap is magnitudes worse than Flatpak.
Can you expand on this. I’m actually curious.
It needs a daemon (lots of wasted resources).
You have to fiddle around in config files to allow access to files on the system instead of using something like Flatseal.
It basically only works with a store which is kind of proprietary.
Own repositories are hard to set up.
The packaging for software maintainers is harder than Flatpak’s.
Oh? What’s the problem?
Flatpak, snap and docker are the problem.
@federico3@lemmy.ml, @ParanoidFactoid@beehaw.org
You misunderstand problem, that Flatpak is solving. Yeah, it’s not ideal way to distribute OSS software, if it already exists in distro’s repositories. But many distros has small repository with outdated software. But FP is great to run proprietary software, as it is able to confine it into sandbox. And untrusted code won’t be able to access your home dir!
Some benefits can be for OSS software too, as some security bugs can be unintentionally introduced, or perhaps someone would intentionally introduce malicious code to codebase, and it would bypass code review. But mostly for Browsers, which might have remote code execution bugs.
No, you are confusing flatpak with sandboxing. Sandboxing is a good thing. You don’t need flatpak to implement sandboxing. Additionally, good sandboxing has to be configured by trusted 3rd parties, like package maintainers, not by upstream developers, because the latter creates a conflict of interest.
What solution would you use instead of Flatpak for sandboxing and reducing the workload of maintainers providing packages to many distributions at the same time?
I’d rather have a maintainer spend time on actually maintaining software instead of packaging it. They can package as AppImage, tarball and Flatpak and I’m happy. You don’t have to use Flatpak, you know? Linux is about choice. I have never used any software which was available exclusively as Flatpak.
You are confusing package maintainers with upstream developers. They are not the same people, and this is by design in most distros, so that maintainers provide a second pairs of eyes, provide security fixes and sometimes remove trackers and similar “features”.
No, I know what a software maintainer is. In many cases, the developers writing the software also provide builds or at least build scripts. So they’re also packaging it.
You’re obviously correct that the people maintaining packages in distributions don’t have to be, and often are not, the same people who maintain the packaging scripts in upstream repositories.
I understand that sand-boxing can be achieved by other means, and flatpak is using kernel facilities. But this is actually way to make it mainstream, and ease applications packaging. Similar thing to what happens on mobile platforms, like Android and UWP(bruh). So this is actually progress to better and safer desktop. Not perfect yet.
Most flatpaks don’t require access to root or home fs, so host files are shielded. Only way to access fs is using file access dialogs and Drag’n’Drop(which is broken currntly)
good sandboxing has to be configured by trusted 3rd parties, like package maintainers, not by upstream developers, because the latter creates a conflict of interest.
Unfortunately this is true. But you can check defined permissions before installing app. And user would be notified it application after update requires more permissions.
But I guess flathub maintainers won’t check/review packages, so not ideal.
deleted by creator
deleted by creator
