Timothée Besset, a software engineer who works on the Steam client for Valve, took to Mastodon this week to reveal: “Valve is seeing an increasing number of bug reports for issues caused by Canonical’s repackaging of the Steam client through snap”.
“We are not involved with the snap repackaging. It has a lot of issues”, Besset adds, noting that “the best way to install Steam on Debian and derivative operating systems is to […] use the official .deb”.
Those who don’t want to use the official Deb package are instead asked to ‘consider the Flatpak version’ — though like Canonical’s Steam snap the Steam Flatpak is also unofficial, and no directly supported by Valve.
I’m sure Canonical’s neverending death march towards Snap, along with the OS running outdated packages, is why Valve no longer uses Ubuntu for SteamOS development. The greatest April Fools was Ubuntu dropping Snaps because so many people were saying how they could go back to using Ubuntu again…then they noticed it was a joke and the sadness set in.
I was certain you had to be joking in this post, holy removed.
deleted by creator
That’s gotta be the funniest backfire for an April Fools’ joke I’ve seen in a while lmao
And still is, as Google still has it on the first page of results for “Ubuntu without snaps”.
Why do people hate snap over flatpak? I feel like I’ve read a thread or two about it, but I haven’t seen an answer that was particularly satisfying (almost definitely for a lack of trying on my part, to be clear).
-
Proprietary on the server/distribution end
-
Controlled 100% by Canonical
-
Worse performance, particularly in terms of app startup times
-
Snaps are mounted as separate filesystems, so it can make things look cluttered in your file explorer or when you’re listing stuff with lsblk
-
Canonical often forces users to use Snaps even when users have explicitly tried to install with apt. e.g. you run sudo apt install firefox and it installs a Snap
-
It hasn’t gained traction with other distros like Flatpak has, and Canonical’s insistence on backing the “wrong” standard means Linux will continue to be more fragmented than it would be if they also went along with what has become the de facto standard
There are however benefits of snaps. It works for better for terminal programs, and Canonical can even package system stuff like the kernel as a snap - as you can imagine, this might be a very powerful tool when it comes to an immutable version of Ubuntu.
Proprietary on the server/distribution end
Zoinks!
Snaps just act strange. They update in weird ways, it’s always automatic and it’s confusing how to keep something in a version that won’t auto update. It’s been a bad experience for me.
Snap startup times are awful, tens of seconds to open a simple text editor, even on an nvme ssd…
edit: Also it doesnt bother following XDG specifications, further cluttering our home folders.
-
- Flatpak is open source, Snap isn’t
- Flatpak allows other repositories besides the official one, therefore having the ability to be decentralised, Snap doesn’t
- Canonical (the company behind Snap and Ubuntu) is hated for some past decisions they made with Ubuntu
- and more
(The only thing I really prefer Snap over Flatpak is that you need the whole package name in Flatpak (like com.valvesoftware.Steam for Steam) whilst you can simply use “steam” in snap but that’s due to decentralisation vs centralisation I guess and overall a minor problem for me)
The article says that steam showing a notice on snap installs that it isn’t an official package and to report errors to snap would be extreme. But that seems pretty reasonable to me, especially since the small package doesn’t include that in its own description. Is there any reason why that would be considered extreme, in the face of higher than normal error rates with the package, and lack of appropriate package description?
It’s not extreme. This is an opinion piece posted on OMGUbuntu, so I’ll let you figure out where their biases lie.
Honestly, that seems like the nicest way to solve the problem. Afaik Valve would be fully within their rights to C&D them from unofficially rehosting their binaries. In any other situation, that would be a blatant security risk.
Was an unextreme solution mentioned? I don’t see one. It seems very reasonable.
What would more extreme, but not inappropriate, is for Valve to send a cease and desist to stop Canonical from using the Steam logo on a package Valve does not maintain. I don’t think that’s warranted. But calling a little text clarification “extreme” is nonsense.
But Canonical using that logo is pretty misleading. I notice the thumbnail adds some Canonical-flare to the logo, but it’s not there on snapcraft.
Canonical’s SteamSnap is Causing Headachesfor Valve-
Ubuntu wants to own snap, with their own proprietary store etc which runs against alternatives like Flatpak and goes against the FOS ethos
-
Snap is slower and worse than Flatpak (the most popular alternative) in most ways, with very few pros that will likely be caught-up-to soon too
-
Thanos snapped the uptime
I don’t even want to hate on Snap, I just think Flatpak is probably superior in almost every way and it’s probably not great that there are three competing formats for “applications with dependencies included”. It was supposed to be “package your app to this format, dear developer, so everyone can use it no matter the distro they use”, now it’s a bit more complicated. Frustrating, as this means developers without that many resources will only offer some formats and whichever you (or your distro) prefers might not be available.
I know that you can get every format to work on every distro (AppImages are just single binaries you can execute), but each has their own first class citizen.
By the way, the unofficial Steam Flatpak has been working well for me under Fedora 39 KDE Spin, but an official one would be great to have.
Obligatory xkcd
obligatory reply to obligatory xkcd
Yeah but Snap isn’t an improvement.
I know, I’m on the Flatpak side, just appreciate the intention behind snaps (although I quite frankly hate the execution).
Nice. I haven’t seen that one before!
Creating standards to trap users is not improving technology.
Snap isn’t a standard actually. It’s closed off.
Hence I picked the word “format”.
Mmm.
Every line of snap code that touches your computer is open source, so “closed off” is absolute hyperbole when you are discussing the format
Canonical specifically went out of their way to create a closed ecosystem with snaps, and you think that’s not “closed off” because they only allow you to download the open source parts of the snap software?
The server is proprietary.
Which is why I phrased my above comment in the very precise and deliberate way I did.
You don’t need to interface with canonical’s server to use snaps, you only need to do so if you want snaps that have been approved by and signed by canonical. Anyone can create a snap and privately distribute and install it, and every part of that process is open source.
Yeah, but nobody cares about your technical “gotcha.”
APK isn’t a closed source format just because Google operates the main store.
If there was community effort someone could spin up their own snap store, this person did it https://forum.snapcraft.io/t/lol-an-open-source-snap-server-implementation/27109 - problem is, it would serve no benefit because you would have to create your own signing authority and patch snapd to use those assertions instead - and then you are still relying on a central authority to vet and sign releases and frankly I would rather have my software signed by canonical than someone random guy operating their own snap store
Again: nobody cares because practically speaking, the only people using snaps are getting them from Ubuntu, and Ubuntu pushing snaps as the default is the only reason they aren’t using flatpaks intead.
Interestingly though unless it has changed recently, you can’t add a third party snap repository. Canonical’s is hard coded, and when people requested alternate repo support, the issue was closed with a response that users seeking third party repos could just edit the string and recompile. Not the most useful solution
I didnt want to hate snap either, until I found out its proprietary technology… on a foss OS… since then I‘m pretty over it - and ubuntu for that matter. I‘ll probably switch to debian once ubuntu 23.10 runs out of support.
Well… Flatpak ships Propietary Software too. And at this point Propietary Software is almost avoidable (unless you have a LibreBoot. I want one too). But it’s reasonable to be frustrated that an operating system as influential as Ubuntu has ended up falling so down in its technology, and that it has the support of a company like Chanonical.
Edit: Thank you for the comments. I didn’t noticed Snap itself is propietary.
Not sure if I understand you correctly. Flatpak itself is not proprietary afaik and while people might make flatpaks of proprietary software, the problem with snap is that the snap system itself is proprietary afaik.
So every open source software packaged in snap gets this proprietary stain added to it. Thats what actually bothers me.
There’s a misunderstanding here. What we mean is that the Snap system itself is proprietary. The server side is proprietary and there’s no way to add repos other than Canonical’s.
Flatpak is open, and anybody can create/add a remote.
Both can be used to package and distribute proprietary software. But the same could be said of .deb or .rpm
I think they meant that the Snap itself (or part of it) is proprietary. But I’m not sure.
Personally, I don’t get why devs would elect to package for Snap, in favor of Flatpak or AppImage. I guess, if your toolchain offers Snap packaging out of the box, then might as well. But aside from that, do you not just reach fewer users…?
Yes and no. Last time I checked, Ubuntu was the most used desktop Linux OS, and it obviously uses Snap (and has Flatpak disabled by default).
Ah, I hadn’t realized Canonical was so awful as to disable the format everyone else agreed on, but seems you’re right: https://www.omgubuntu.co.uk/2023/02/ubuntu-flavors-no-flatpak
They didn’t “disable the format”
From your own link:
Do keep in mind that “not installed by default” is not the same as “not available to install at all”. To this end, Flatpak continues to be available in the Ubuntu repos, and users of Ubuntu flavors are free to install Flatpak
Well, yeah, you can enable it. But if it’s not active in their GUI software store by default, then many users will not find / look for it. It’s rather important for a package format that you don’t have to separately install it.
Why do you need to have two package formats that do the same thing installed by default? If you could install snaps and flatpaks both from the same store you could have 2 (or 3 if you also installed the .deb) copies of the same app, like steam etc installed, and user sessions and games set up on one wouldn’t be launchable from the other because they all store their state and config in different locations - the only way to know what config your program is launching with would be to inspect and rename the launcher scripts. If you are intending to support naive users this is the absolute worst case scenario. It would be like debian including pacman by default as well alongside apt for maximum user
accessibilityconfusion.Because many apps will (or would prefer to) only be bundled as Flatpak. I agree that the deduplication is not a trivial problem to solve, even if they might have already solved it for DEBs (I don’t know).
But your entire comment could just as well be a rant why Canonical shouldn’t have introduced Snaps in the first place. It might be good for their bank account, if they can somehow monetize part of the cake, but splitting the cake even further, after it’s already split into DEB, RPM, AppImage, Flatpak, Docker, APK etc., that’s maximum user confusion.
Ubuntu itself never natively came with Flatpak though. Some flavours might have, but their marketshare is also a lot smaller.
Of course, if Ubuntu ever decided to ship with Flatpak natively, that would instantly become the obvious choice.
How do you figure? For example, Arch Linux community on r*ddit is bigger than the Ubuntu one
Where did you get the numbers?
Hard to find raw numbers backed by good sources.
If you filter the Steam Hardware Survey for December 2023 by Linux, you can see Arch has a market share of 7.85% (excluding SteamOS on the Deck, which is technically based on Arch and has 40.53%) while Ubuntu 22.04.3 LTS - a specific Ubuntu version - already has 7.04% on its own.
But that’s also just Steam users. Ubuntu is one of the few Linux distributions that OEMs ship preinstalled and officially support on some of their devices (Dell for example). Another example is Fedora iirc, which Lenovo ships or at least used to ship as an option on some of their ThinkPad notebooks.
I’d assume the Arch community on Reddit is bigger than the Ubuntu community as it’s geared towards tech-savvy people. Going by Reddit community size wouldn’t make much sense though. Even if you add up the member count of the r/windows, r/windows10 and r/windows11 community (which doesn’t make a lot of sense as most users are probably not unique), it’s only like 3-4x the members of r/archlinux, which doesn’t translate to market share whatsoever.
I don’t really have hard numbers, sorry. Should’ve checked first. I guess I just assumed because of the OEM support and being relatively easy to install and maintain for the average guy (in comparison) that it was the leading Linux desktop distro in terms of marketshare. I’m still assuming this is the case for the reasons stated, but can’t tell you with 100% certainty.
I don’t really have hard numbers, sorry.
It’s impossible to measure since sharing copyleft stuff can’t be tracked like sales of proprietary software can. There’s no need to apologize about not doing the impossible.
Well, most of windows users don’t even know they are using it, they think they are using a “PC” as opposed to Mac
Any Linux desktop user is already very tech savvy, I doubt there are any Ubuntu users that don’t know they are using Ubuntu so the windows commission is not apt
If you’re on Ubuntu, you can just ask your question in the normal Linux community or in a search engine. You don’t need to go to a special Ubuntu community.
That’s at least, how it makes sense to me. In general, I’ve seen many niche distros have very active communities, because everyone just ruts together and helps each other out.
…which is to say, I don’t think there are accurate marketshare statistics, because no telemetry, but my impression is also that Ubuntu is still popular out in the wild.
So? The AMD subreddit is larger than either Nvidia’s or Intel’s (in the case of Intel, by a lot). Both of them have a greater market share than AMD in their respective markets.
Porsche has over double the subs of Toyota, yet Toyota sells 33x the amount of cars.
Subs means zero.
Again, my mom is not on the Intel subreddit because she doesn’t know she has an Intel processor. In fact, she used to work for Intel, and she still doesn’t care
Ubuntu is nowhere near popular enough to be a default. I’m just wondering how to count the market share accurately
The thing with AppImages is: it requires FUSE2 which doesn’t really get packaged/included by default anymore in a lot of places and the recommendation is “build on the most old and crusty distro you want to support” which just sounds like a nightmare in multiple ways :)
And with snaps the sandboxing only really works on Ubuntu and nowhere else last time I looked into it (then there is also the entire problem if you want to host your own repository/“storefront”).
So really the only universal sandboxing method that effectivly makes sense is Flatpak.
Flatpak with Fedora 39 must have come a long way. Almost every tutorial with workarounds or discussion of broken features you can find online is now obsolete. It just works out of the box, especially under KDE. Mostly. That makes searching for actual issues extremely hard because I find myself chasing down paths of issues that have long been resolved.
Agreed. the only “workarounds” I’ve needed to do (on arch) is install
gtk-desktop-portal-{gtk,kde}because it’s not included withkde-plasma5for some reason.
and it’s probably not great that there are three competing formats for “applications with dependencies included”.
Ok in snap/flatpak but i tink that’s a bit unfair in appimage. First two are runtimes, second is a file format that does stuff with fuse. That’s like saying there should only be one I/O scheduler.
now it’s a bit more complicated
Do native for system/environment stuff and simple projects, flatpak for frontend molochs with lots of dependencies, no?
I don’t think AppImage is a bad technology, but with the comparatively minuscule marketshare Linux desktop has barely any developer/software company can invest the resources to test and maintain packages in all these formats. It’s often not worth it for commercial software to offer packages in every possible format (yeah, yeah, open source is great, I know; still, commercial software is real and many people (need to) rely on it).
I’ve been using Fedora for a couple of weeks (one of my New Year’s Resolutions is to completely ditch Windows, so my main computer is now on Fedora :D) and most of the software I use is either available in the official repositories, as an rpm or a Flatpak. But there’s the odd piece of software where I can only find AppImage or Snap versions, and often if a Flatpak is available, it’s non-official (Steam for example).
So, you potentially have packages from the package manager (mostly deb- or rpm-based, and whatever format Arch uses), then you have AppImage, Snap and Flatpak and some applications are simply an archive with an executable binary. That’s a far cry from installing everything from one or two places, which I feel like used for be one of the selling points for Linux (years ago).
Nothing most users can’t handle, but it could certainly be more streamlined. Now before I install software, I check the website, then I check whether they offer an official flatpak or an rpm package if it’s not in the official Fedora repositories, and if they don’t, I check if there’s an unofficial one on Flathub, which sometimes has implications. If there’s no Flatpak whatsoever, I fall back to standalone binaries/archives when available. It’s probably easier to install software on Windows now: download the installer from the official website, install it and done. Most software auto-updates itself.
Having options is great and one of the great things about OSS, but I feel like when it comes to “standards” like these, more collaboration instead of reinventing the wheel over and over again would be better.
That’s a far cry from installing everything from one or two places, which I feel like used for be one of the selling points for Linux (years ago).
That’s because years ago you had a choice between using the repo or compiling the package yourself.
Now before I install software, I check the website, then I check whether they offer an official flatpak or an rpm package if it’s not in the official Fedora repositories, and if they don’t, I check if there’s an unofficial one on Flathub, which sometimes has implications.
Imagine if Fedora came with software specifically made to install and update software from all of those different sources through a simple and unified gui. That would really streamline that whole ordeal. It could even include a snap backend for masochists.
PS
Wait till you learn about nix and guix
Having options is great and one of the great things about OSS, but I feel like when it comes to “standards” like these, more collaboration instead of reinventing the wheel over and over again would be better.
The “Discover” app from KDE and the “Software” app from GNOME actually support backend plugins, but it’s far from ideal. I had an issue where a Flatpak (Tor Launcher) showed up in Discover with an update available, but when trying to update it would fail silently and show up as an update again. Updating via CLI revealed that the package was deprecated in favor of another one and it asked whether I wanted to replace it.
Even if it’d work great, it wouldn’t really solve the issue that developers have to try and package their app in many different formats because not all distributions support all formats (out of the box). There isn’t a clear “release in this format” for developers. And as I said, unofficial packages aren’t ideal.
Refer to the xkcd. There’s never going to be a single universal standard to unite them all and in light bind them. The best you’re going to get is improved support and integration.
I thought that valve distributed statically compiled files
My only complaint about flatpak is that updating them fails like 50% of the time for seemingly no reason, and I just have to run the update command over and over until they are all updated.
I’ve never had an update fail with flatpaks?
It happens constantly both on my laptop (suse) and my Steam Deck (arch). Same exact behavior. I gave up trying to debug it, and I just keep retrying the update command until the list is empty.
I am honestly surprised, my arch desktop and my steam deck got no problems of those types. If you find what makes it happens on your systems then maybe it will help improve the tech!
If no one else has this issue, it could very well be something unique to my internet connection!
I’ve never had anything like this when I used to run arch (with Archivstall). Also not on fedora for months and now back on LMDE.
How are you closing the program? I don’t mean with the X button on the desktop environment. I mean command line programs.
What program? I just let
flatpak updaterun through until it returns me to my shell.I’m sorry, I must have responded to the wrong comment. That comment was supposed to be in an entirely different conversation.
Edit: Oh, I just reviewed my inbox. I thought you replied to a different comment of mine. I’m so dumb. Carry on.
Welcome to Linux.
Thanks buddy
Just tell the billion dollar company to allow people to download the games on their browser. The Client only exists as a means to DRM and analytics, there’s no actual reason for games not to become standalone.
That’s pretty unfair. Before Valve’s efforts, the first thing we PC gamers asked eachother about a new game was always “could you get it running?”
Three bad old days were quite bad, and they started getting better in lock step with Valve’s improvements to Steam.
Correlation/causation and all that. But for a lot of us Valve earned a lot of goodwill simply by allowing “request a refund” on games that run poorly. (Edit: which was apparently forced on Valve by a government. Valve got lucky there!)
Their refund policy is due to getting slapped around in EU courts, not because valve is benevolent or anything. I do like steam a lot, but it is a near monopoly which acts as DRM to a degree. They did and would abuse that power unless regulated.
I believe their refund policy is actually from ACCC in Australia, rather than European rulings
You’re correct, Australia played a big role in it, and the EU was passing regulation around 2015 on that issue as well. So they got slapped around in Australia and changed it up before getting slapped around in the EU.
A lot of people these days have no idea what has happened outside of the few years they’ve been in contact with the industry. Computing might as well have started in 2005 when you listen to them.
As someone who was during those times, your Zgen knowledge is very incorrect. The games did work, including Crisis (original). As to why the myth you hear from fellow Zgen gamers; it’s because graphics cards were invented. Brand new, no one knew what they were doing with them. The companys Renzen and Nvidia started sponsoring games, it’s how they became popular, their logos were part of the game, Metal Gear Solid revengeance is proof of this.
Steam had no part in gaming history, they were not the first online platform. Dell made wild target before Valve Corporation was founded. Lootbox was invented before Steam launched it, Yahoo games (anyone remember them) in japan had the concept down to almost todays standards. Valve had nothing to do with gaming history, they are just known for their lawsuits and anti competitive behavior.
I’m incorrect that my PC games didn’t work on my PC?!
removed. Thanks for clearing that up.
Your points about Vavle part of the same bullremoved are worth raising, though.
But a unified store with reviews, a refund policy, , and installers that actually removeding worked was a really big deal, especially to those of us without bleeding edge hardware - which was most of us.
Edit: and don’t start talking about gaming history to me, I was there for all of it. Pong didn’t come with an installer, it came with the hardware. Turn those paddle knobs folks. Pong is still better than a lot of the removed you kids are playing.
You fake, everyone in the older days knows how the controls work. All except you younger people, you didn’t turn it, you slide it.
https://www.youtube.com/watch?v=FvT8jG1OVdI&tWhat you describe was the Arcade version, not the popular console versions.
Valve is in a lawsuit: https://news.bloomberglaw.com/antitrust/valve-loses-bid-to-end-antitrust-case-over-steam-gaming-platform
Dell did make wild target: https://m.youtube.com/watch?v=ibz8kpsRHdk
you didn’t turn it, you slide it.
Like the cx30 on the popular 8 bit home console Atari 2600 which was a knob you turn?
Here is an alternative Piped link(s):
https://www.piped.video/watch?v=FvT8jG1OVdI&t
https://m.piped.video/watch?v=ibz8kpsRHdk
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
Steam had no part in gaming history, they were not the first online platform.
Lmao. This is like saying the iPhone or iPad had no part in smartphone/tablet history, because neither were first to the market. It’s a ludicrous take.
Valve had nothing to do with gaming history
Lol
they are just known for their lawsuits and anti competitive behavior.
I’m willing to bet this isn’t true lol. Valve is only known for anti-competitive behaviour? Come off it.
The Iphone wasn’t part of touchscreen technology either. They were just the first to try heating sensors. It’s still being used in android devices too. The ability to use physical sensors is gone. Apple killed it off.
Valve is in a lawsuit, do your research next time: https://news.bloomberglaw.com/antitrust/valve-loses-bid-to-end-antitrust-case-over-steam-gaming-platform
Lmao
That’s the problem with doing everything yourself.
You also have to maintain everything, yourself.
removed snaps 🖕
Yeah. Hey wait? removed you!
I’m sorry but Linux Council has already decided your fate.
I thought it was the GNU wizards circle that decides these things.
Are you telling me I have been going to the wrong meetings?!
I swear this Linux fragmentation will be the death of it.
I am the Linux Council!
Oh yeah? Then I’ll make my own Linux Council! With blackjack and hookers!
Are you threatening me master jedi?
🫰removed 🫰Snaps 🫰
Who the removed was asking for a Steam Snap.
JFC
Give up on snaps. It’s not gonna happen. Whatever benefits they claim they could provide could be merged into Flatpak and everyone wins.
It’s Canonical. They’ll perfect snaps in 8 years, then give it up
Snap is what finally got me to drop Ubuntu for Debian. Such a pain.
Already gave up. Switched to Debian and it’s been great. I loved Ubuntu, but removed snap all the bullremoved that comes with it.
Flatpak is not designed to solve all the same problems as snap they have very different scopes and goals. It’s really only Linux hobbyists that see these as comparable technologies.
Also the Steam flatpak is unofficial just like the snap, they would be unwilling to support flatpak issues as well.
Linux hobbyists
Who else has opinions on snaps vs. flatpacks? Are they distinct to the “Linux professional” somehow?
Yes? How is this a question?
Counterpoint: Snaps work fine for me, really convenient. But flatpak always removeds the bed on my internet, it also needs huge Nvidia driver packages of it’s own if you have an Nvidia GPU (my laptop has one)
Snap on the other hand is very much fire and forget
I know the “Arch BTW” meme exists for a reason, but one of the reasons I haven’t been able to drag myself away from Arch-based distros in recent years is that it allows me to always have current versions of my software while also just not having to care about all this appimage/flatpak/snap brouhaha.
I guess it’s somewhat of a “pick your poison” kind of situation, but I find dealing with the typical complaints about Arch based distros to be both less of a problem than detractors would have you believe, and less of a headache than having to pick one of three competing alternative packaging approaches, or worse, to use a mix of them all. Standing on the sidelines of the topic it seems like a small number of people really like that these options exist, and I’m happy for those people. But mostly I’m grateful that I don’t have to care about this kind of thing.
Edited to add: Seeing how this thread has developed in the past 5 hours convinces me anew that “on the sidelines” is where I want to stay on this topic. 😁
I’ve always found the most time consuming thing about arch is having to spend half your life telling everyone you use it.
Nah, it’s repeating the installation process until you finally get enough stuff working to have internet, and then you can bootstrap installing every other bit of software that you need. Thank goodness for rolling release - I can’t imagine having to go through that again.
You can install Arch directly from a UEFI shell over the Internet: https://archlinux.org/releng/netboot/
If your BIOS has a UEFI shell that supports DHCP, HTTP and IPv4 PXE you can load the ipxe-arch.efi over HTTP and start installing.Does UEFI shell have wget?
The important question is if the UEFI shell can run Doom.
Of course it can. What did you expect?
Depends on the version. All of them (the newer ones with networking) have TFTP. Some even have HTTPS. I think HP Servers even have HTTPS-Boot with client TLS certificates.
None of it works with Wifi though. iPXE has wifi support for some devices but you obviously can’t start it over the Internet. You need to flash a ROM you don’t need or use a USB drive to load it. Then you can boot Linux from the Internet. (That also works if you don’t have a UEFI Shell in BIOS). https://netboot.xyz can also boot other OSes than Arch.
I haven’t done a vanilla arch install for years either, because if that sort of thing is fun for some folks great, but it was only fun once or twice for me. I think a lot of the vanilla arch faithful end up scripting it for fresh installs.
But, FWIW there’s always endeavouros, manjaro, and I’m sure other Arch derivatives I’ve forgotten about. I just did an endeavouros install on new hardware I was given last weekend, and it’s certainly no harder to install than Ubuntu.
I haven’t used it in years, so hard to remember now.
100% all this. Canonical has been pushing snaps for awhile, and I wonder if the 12 year LTS for Ubuntu is part of that strategy - want something newer? It’s in the snap store. snap is terrible, worse than flakpak and appimage - but just as you say, as an arch user I don’t have to care. Whatever I want is probably in the AUR if not the main repos. Rolling distros, done right (arch), are an amazing experience.
Yup, the AUR is a godsend. I barely touch the other methods and only use AppImages when I’m too lazy.
Appimages when you’re lazy? The fact you have to chmod them is annoying compared to an AUR helper
I mean Dolphin gives a prompt for the same thing when I launch it.
I was like you using arch packages for everything until ferdium was hit by a terrible bug that broke its zoom function and wont be fixed in months since it is an issue with electron. Now I use the appimage version of it to downgrade to an older version.
And then there are the rust programs that you can only find as aur git packages which means installing a bunch of dependencies and all the crap that cargo puts into my home dir just to build one binary, for that I just instead take the appimage version or sometimes the binary if they release it and place it in ~/.local/bin.
Another good thing is that the appimages get compressed and take less disk space, for example the libreoffice package in arch is 600 MiB while the appimage is 300 MiB.
And the great thing is that I can just drop my homedir into any distro and as long as I make sure that fuse is installed everything will work out of the box.
It sounds like NixOS would solve all your problems. And it makes coffee too!
Still figuring out Nix for my daily driver (too many fun customizations moving away from gnome), but love it so far and built my last self-hosted box with it. So easy to redeploy after the initial learning curve. Boot from ISO, partition with disko, upload SSH key to decrypt sops, install.
Oh and since practically everything can be overridden, its easy to get bleeding edge using existing packages!
Nix is objectively a bad language. Glancing past the syntax (which is atrocious and the parser is completely unhelpful) it’s just a bad idea to mix lazy evaluation and dynamic typing, the only way to get understandable error messages with nix is to put asserts all over the place, hoping one of them gets triggered by the evaluator.
That said I still love the system to bits and fixing the language actually wouldn’t be that hard: Add static typing, with inference most stuff should just run as-is. Exception are the two or three uses of the y-combinator (yes, seriously, that’s how you recurse in nix) deep in the bowels of nixpkgs, e.g. during stdenv bootstrap. Just make
fixa primitive, or maybe a plain fold I don’t think nix even needs to be Turing-complete. Reason it’s not being done is that there’s enough other stuff to work on and, well, Stockholm syndrome. Good news: Nix doesn’t support constructing import paths dynamically, that would have been a nightmare to sort out in a static setting.I don’t mind most of the language having FP experience, but I agree the lack of static typing just sucks. I’m using the repl a lot to try and track down why things aren’t aligning quite right when trying different techniques to keep things DRY and organized. Documentation is also a headache as a newb with the multiple ways of structuring a repo while trying to grok all the implicits and how it all gets merged.
Is NixOS xdg base dir compliant? that is one of the reasons I don’t use flatpak.
Yes, all the environment variables are set automatically and programs respect them.
As someone who knows nothing about Arch, what do you do if your app exists only as a .deb file? Can you install it?
I know you already got another answer, but - it’s very rare that any software for Linux exists that is both 1) not present in the official Arch repos, and also 2) not packaged by a user for the AUR.
Probably 99% of what a typical user (I know we all define that differently) will want doesn’t even require AUR access - it will be in the official Arch repositories and will be up to date to within a few weeks of release.
There are some potentially substantial downsides to the AUR (it’s the Arch USER Repository - so these are not official arch packages) but IME the real world problems are minimal. I would suggest anyone who is new to the Arch way of distributing software should hit up the relevant page on the Arch wiki and make up their own mind before using the AUR - but it’s about being aware of what you are doing more than it is a real warning, if that makes sense. I suspect few Arch or Arch-based users don’t have at least a smidgen of AUR packages on their system. (Edit: That page is very thorough. I think it makes installing from the AUR sound much harder than it needs to be. For most people the command is just “yay -S packagename.” There are gui options that handle all packages including AUR, and yay is not the only cli option, either.)
Interestingly, there are some AUR packages that work by pulling down the deb and deconstructing it for installation on your system - AFAIK it can be that, RPM, a true “compile from source” situation, or I’m guessing some AUR packages are deconstructing snaps\flatpaks\appimages during the install. Whatever the origin of the files, they include a pkgbuild file that tells your system how to either compile or deconstruct and install the software.
I know I ran into this years ago. I think it was some collection manager app for a trading card game that someone had on GitHub and only had .deb releases. Eventually you will want to install something niche.
I have found no such instances. Software which is only officially packaged as deb will usually be unofficially repackaged on the AUR regardless.
I distribute an app I made for Linux, macOS and Windows. The Linux version I only have available as a .deb. Released recently and has about 200 users so far, but definitely exists. No Arch user contacted me yet.
When folks start wanting it, someone will package it for the AUR, or if it becomes even somewhat mainstream it will end up in the main repos eventually.
Possibly, though I wonder how updates would work then. Currently I have a Debian repository that contains a single package, and installing the .deb from my website also installs the repository so you get updates as with any other package.
If someone repackages it on AUR, I guess they will also need to update it every time I update the .deb, so it’s always behind? Of course it would be better if I provided a first party package for AUR, but I can spend time on that when there is actual interest. Most of my users are on Windows anyway.
Usually what you describe is what they do. Someone “owns” the AUR package (and it’s not quite literally any random user IIRC - you have to be accepted as an AUR maintainer I think) and they then take on the responsibility to repackage it whenever the author (you) releases a new version. There is also a mechanism for users to flag the AUR package as out of date in case that maintainer misses a release, and if they abandon it (or even if folks just don’t like how they package it) someone else can package it, assuming someone else wants to.
Sometimes the AUR maintainer is the dev themselves. I can’t think of a good example currently, but I know I’ve seen it before.
I don’t know the process for how things end up in the official repos, but I would guess it’s similar to however any other distros identify software they want to officially package.
They may not have to. For example, Plex on nixos just unpacks the deb and installs the files the “nix” way.
It isn’t recommended, but dpkg will install it if you really want to. You just need to handle dependencies manually.
But it’s a pretty rare issue. If something isn’t available in the official repo, AUR probably has it.
Debian-trixie is pretty up to date and flatpak fills the holes perfectly.
I think if we could drag users (at least gamers) away from these Debian/Ubuntu based distros we could have developers just shipping packages that wouldn’t need to be compatible with some ancient LTS library release, and maybe we wouldn’t need appimage/flatpak/snap at all anymore (or at least only in rare cases).
Debian catching strays over Ubuntu’s ubullremoved.
Well, the only thing holding me from switching to Debian is the absence of up to date KDE packages…
What about in unstable or testing? I moved to Arch from Debian because I wanted faster releases and it just made sense to move to rolling instead of testing Debian install.
I think Debian has a place in the Desktop market, it’s just not gamers or anyone wanting anything new (unless they of course go the flatpak route). Not a perfect analogy, but it’s kinda like gaming on Windows 7 these days because it “just works” for you. Sure you can, but you’re not getting the best of anything that way and all the underlying libraries are outdated and some things just aren’t going to work at all.
From my perspective as someone who is both getting into gaming on Linux and also not much of a power user, Arch would have to make the installation and maintenance process a lot simpler to attract more people, and I’m not sure that’s something they actually want to do.
Looking at the official Arch installation guide, the average gamer may be overwhelmed by the process here, especially if they’re not comfortable with the terminal. Something like Linux Mint, on the other hand, has a built-in GUI installer with reasonable partitioning defaults, and it comes packaged with stuff like an app manger and update manager, something that will feel much more familiar to someone coming from windows.
If you want, or are interested in looking at an easier to manage Arch install I would suggest CachyOS, EndeavorOS, or Garuda Linux.
Canonical is a joke
At this point, a bad joke
It’s too bad. I feel like they’re a versions of Ubuntu from 2006 to, say, 2012 or so, that were beautiful and perfect and were accessible to me as a college student. It set a new standard. It seems like half the battle is having people with good vision making important decisions so things don’t go off the rails.
Yeah Ubuntu really used to be the go-to distro for me, now they’re really my distro of last resort (of the top options).
Canonical does a heck of a lot more for the Linux ecosystem than snap. For instance they have an entire (growing) team dedicated to fixing reported bugs in various upstream packages.
This is a big issue with Snap. It may be like Flatpak, allowing devs to set their own dependencies for ALL distros, but its poor uptake outside of Ubuntu’s ecosystem means that it’s no different to yet another distro repackaging system.
Flatpak, or even Nixpkgs, are the future because they allow devs to have control over the distribution of their software. Snap being such a closed ecosystem in comparison only means it will replicate many of the problems we’ve found with traditional (re)packaging systems.
I can’t speak for Flatpak as I haven’t tried it but nixpkgs are beautiful to work with and configuration of my system has become completely reproducible in a clean format.
As a dev, you can just distribute a nixpkg with whatever build tool inside. That beats the current system of “native” packages where your software is repacked and then maintained by half a dozen teams for different distros that use different dependencies and update cadences.
Bottles has gone as far as to demand its fedora package be removed and now shows a warning if you’re not using the flatpak version because repackers just don’t properly test all their software (how can they? there are thousands of apps in these repos!)
Yeah there are some issues with compatibility, I’ve found a couple of apps that error on my Mac.
How does it compare to Flatpak?
nix is a “native” packaging format. Apps are compiled for your host OS and run in that environment with no restrictions, for better or worse.
Flatpaks are containers. They provide a virtual OS to the application such as the file system, and accessing host OS features is done through “portals” which just means you can give/revoke the ability of the app to access your host OS resources such as networking, file access etc.
Flatpaks are therefore much safer in theory. But Nix packages are lower overhead, and can interact like any built-in software binary that you’d have when you spin up a fresh install of, say, debian.
Nix packages are harder to use IMO thanks to their poor documentation and lack of GUI package manager support (not that it’s impossible, just that it’s been a niche system for most of its life) and since most people are accustomed to flatpaks and their permissions system (and the fact it comes preinstalled on most distros) so flatpak is still pretty ubiquitous, even for NIxOS users
The one Linux Distro that people will look for out of popularity, removeding up the of the Linux user base? Of course, thanks canonical.
Snaps were designed to solve dependency hell, get modern software, security, among other issues. If it weren’t for the fact Flatpak does a better job, many more people would be praising Snap.
It’s good that Canonical is trying to make the desktop better. It would be better if they focused their efforts elsewhere.
deleted by creator
Flatpak is intended for end-user graphical applications, not many terminal applications are packaged by Flatpak so it makes sense why it wouldn’t show up. Snap IIRC was first intended for their embedded system.
Let me simplify that:
Canonical’s SteamSnap is Causing Headachesfor ValveUbuntu used to get a lot of undeserved hate but lately the hate feels deserved. Ubuntu has been the face of the usable desktop Linux for a long time and they just keep tripping over themselves every time they try to move forward.
Their intentions are usually good. A lot of things they propose usually end up being adopted by the community at large (just not their implementation). They seem to just yank everyone’s chain a little too hard in the direction we’re eventually going to go and we all resent them for that.
Off the top of my head, there was Upstart (init system), there was unity (desktop), and now snaps (containerized packaging). All of these were good ideas but implemented poorly and with a general lack of support from the community. In almost each case in the past what’s happened is that once they run out of developers who champion the tech, they eventually get onboard with whatever Debian and Rhel are doing once they were caught up and settled.
Valve’s lack of interest in maintaining the snap makes sense. The development on the Ubuntu platform is very opinionated in a way where the developers of the software (valve) really want nothing to do with Canonicals snaps.
On another note: my favorite thing about the Ubuntu server was LXD + ZFS integration. Both have been snapified. It was incredibly useful and stable. Stephane Graber has forked the project now into INCUS. It looks very promising.
This might be an unpopular opinion but I really don’t get this trend of wanting to containerized just about everything, it feels like a FOTM rather than doing something that makes sense.
I mean, containers are fantastic tools and can help solve compatibility problems and make things more secure, especially on servers, but putting everything into containers on the desktop doesn’t make any sense to me.
One of the big advantages Linux always had over Windows is shared components, so packages are much smaller and updating the whole system is way faster, if every single application comes with its own stuff (like it does on Windows) you lose that advantage.
Ubuntu’s obsession with snaps is one of the reasons I stopped using it years ago, I don’t want containers forced upon me, I want to be free to decide if/when to use them (I prefer flatpack and appimage).
Debian derivatives that don’t “reinvent the wheel” is the way to go for me, I’ve been using Linux MX on my gaming desktop and LMDE on laptop for years and I couldn’t be happier, no problem whatsoever with Steam either.
Shared components work brilliantly in a fantasy world where nothing uses new features of a library or depends on bug fixes in new versions of a library, and no library ever has releases with regressions or updates that change the API. That’s not the case, though, so often there’ll exist no single version of a dependency that makes all the software on your machine actually compile and be minimally buggy. If you’re lucky, downstream packagers will make different packages for different versions of things they know cause this kind of problem so they can be installed side by side, or maintain a collection of patches to create a version that makes everything work even though no actual release would, but sometimes they do things like remove version range checks from CMake so things build, but don’t even end up running.
Shared containers work beautifully for a lot of things, though, many programs aren’t all that sensitive either. Making snaps for the tricky ones makes sense. Having snaps for all of them is ridiculous.
I can count the software requiring repo-pins on one hand on my desktop. For those, snaps make sense, replacing the need for any pins. Snaps are less confusing than pins. IMO.
It reminds me of Python programming, with requirements pinned to version ranges. Some dev-teams forget, and their apps won’t work out of the box. Sometimes, software still works ten years later, if they only use the most common arguments and commands from the packages.
Snaps <==> Virtualenv.
I agree with a lot of your points but I do think containers a great solution.
I’ve been a really big fan of Universal Blue lately. It presents a strong argument for containerizing everything. Your core is immutable and atomic which makes upgrades seamless. User land lives in a container and just gets layered back on top afterwards.
Wasn’t there MIR as well?
Yeah, I think as the replacement for x before Wayland?
LXD got better with the AGPL license, so Canonical did the right thing there.
(I know they added a CLA but it’s still way better than the permissive license they had before)
I do think the idea behind snap isn’t all about pushing the Linux platform as such forward, but to specifically gain a market advantage to Ubuntu.
Why else is finding documentation for changing the default store so difficult? And I don’t think you can even have multiple “repositories” there–quite unlike all other Linux packaging systems out there. (Corrections welcome!)
The ZFS stuff was exciting! Are they still incorporating zfs in current releases though?
I think they are! I’m still trying to do more with ZFS everyday.
Would be cool if they just straight up supported flatpaks. That’s been my main way of gaming for a couple years now, and it works great. The downside is that the folder structure is confusing so it makes things like modding pretty difficult.
Maybe they’ll get there eventually, considering this is their method of choice for installing 3rd party apps on SteamOS 3.0.
or, you know, you can use your distro packages
Steam’s runtime is already sandbox-ception. Flatpak might be more appealing to Valve than it seems.
I see no value in switching from current situation (in-repo deb pkg + steam autoupdates) to flat/snap/farts, which I don’t use at all…
It’s not about you, it’s about what’s easier for Valve. If Valve is fine packaging, and getting bug reports, from all the different distributions, they’ll keep doing things as is. But as a Linux app developer myself, I exclusively publish to Flatpak because it guarantees everyone has the same system.
you’re at best uninformed about how the process actually works and what’s the role of a distro maintainer, a distro project, upstream authors. Not that every piece of software has enough value to be included in this process so maybe it will make sense to package your stuff by yourself.
or, you know, you could use a much better and consistent platform
Well, no, neither approach is better than the other, it’s apples and oranges.
There will always be a place for installing native applications. In the least analysis, the container itself should probably have some dependencies packaged for the target program.
The benefits of containerisation are obvious, but it’s been a lot of work and there are still edge cases to iron out.
FreeBSD has had jails since 2000. Linux, however, only got namespaces in 2008 and the first bubblewrap release on GitHub was 2016.
I’ve been using chroots and containers for development for about 2 years now and it’s been fantastic, however, I’m still grateful I don’t have to jump inside one every time I need to write a python script.
I’m still grateful I don’t have to jump inside one every time I need to write a python script.
Honestly, I’m on NixOS and it’s not a bother because it saves time down the line when your script would break during a system upgrade which it doesn’t on NixOS as without you telling it to, it will still use all the old dependencies. Also you already have a couple of
flake.nixfloating around you can just copy and adjust and direnv does the rest.
I use debian, I’m happy and definitely have no idea what you are talking about :)
Debian is one of the distros where flatpaks are most appropriate lol, it’s the best way to not have programs that are really old
Adding weird third party repositories that can cause all kinds of issues probably isn’t the best idea
tbf, flatpaks are problematic removed noobs tend to appreciate because reasons. That said, beside the fact steam ships its own chroot, I’m a happy sid user and I don’t even have this imaginary problem of things being ‘very old’ sooo … but I can confirm you shouldn’t add weird third party repos or removedty flatpaks :)
It’s not just noobs that appreciate flatpak. Flatpak is good all-round.
And the problem of Debian packages being old is very much not imaginary lol. Debian has only just moved beyond Gnome 3.38/Plasma 5.20/kernel version 5.10.
That’s ancient. And that’s not to mention the other software repos, which are often updated at an even slower pace.
Don’t assume that just because you want extremely outdated packages, everyone else must want the same.
I don’t mind the old packages (I’m typing from Debian Stable right now). If that’s a bother for other people Debian Stable isn’t the way to go. Even I wouldn’t recommend Stable on a desktop/laptop unless that person knew what they were getting themselves into. I used to run Sid a while back, but didn’t want to have to deal with the mild breakage from time to time. Generally speaking it’s “stable enough” for most people, especially on a daily driver.
That being said, I have a few flatpaks running, but that’s mostly because they’re apps that aren’t packaged for Debian.
you normally skip reading half of the comments you reply to, eh? :) ciao ciao from my debian system which does everything, including paying my rent and a bit more, w/o this removed ;)
It’s actually a massive issue on Debian
mmh, what? :)
?
👍🏾
Good. Snap is an abomination.
The problem is that 3rd parties are doing the packaging both on Snap and Flatpak whereas if they had followed proper security practice ONLY THE REAL DEV should ever be allowed to package their app as a Flatpak or Snap.
This would ensure security, as well as a proper functioning flatpak/snap and also all feedback would be directed to the Dev.
I’ve never liked the fact that Canonical and whoever can make Snaps and Flatpaks of other people’s software. There is zero security guarantee, zero guarantee they’ll update it and zero guarantee it will work.
Just because Snap and Flatpak exist doesn’t mean just anyone should be able to just make them.
If Valve only chooses to make a deb then so be it! It’s their product!
Wait until you find out how distro packaging works
The problem is that 3rd parties are doing the packaging both on Snap and Flatpak whereas if they had followed proper security practice ONLY THE REAL DEV should ever be allowed to package their app as a Flatpak or Snap.
Says who? If it were the case, Linux would either be a nightmare of fragmentation or become centralised on one distribution. Distros need to be able to package their own software, and these are kind of like distributions. Also since we’re talking about proprietary software here, is it really any better security practice if the “real dev” packages it or somebody else, they both could contain malicious code.
Valve are not going to put malicious code on their app. Neither is VLC or any other FOSS developer.
The distros should stick to packaging their repo apps and leave the Snap/FlatPak tech as an alternative to the original dev if they decide they want to use that.
We can’t have Bob from nowhere packaging Valve, then not updating it or patching it because he doesn’t have time. Or 5 Bob’s all doing the same thing with 5 copies of Valve on the Store.
It’s crazy. This is what causes fragmentation. Flathub should vet every app and if you are not the dev of the app, you may not host it on Flathub. You’re still welcome to make a Flatpak for home use on your own pc but not for wide distribution.
Valve are not going to put malicious code on their app. Neither is VLC or any other FOSS developer.
How would you know that? It’s not like it’s something that doesn’t happen.
Or 5 Bob’s all doing the same thing with 5 copies of Valve on the Store.
It’s crazy. This is what causes fragmentation.
I don’t know what snaps are like but that’s clearly a non-existent problem on Flathub.
Flathub should vet every app and if you are not the dev of the app, you may not host it on Flathub. You’re still welcome to make a Flatpak for home use on your own pc but not for wide distribution.
I don’t know why you feel like there’s permission involved. You don’t have to use Flathub, therefore Flathub can have what ever policies it likes. Users can set up a different flatpak repo if there’s a need.
That’s not my point. I use Flathub but I try to only use verified apps which were packaged by the actual dev.
I’d rather get a deb from the official dev than a flatpak from flathub packaged by someone who is essentially anonymous and could easily inject malicious code.
If you think the dev himself could inject malicious code in the official app, then you should be super aware that an anonymous Joe can too, and is far more likely to.
Anyway flatpak ideally was supposed to save Devs the work of packaging for every distro so it makes sense that the real actual verified dev of the app would package the flatpak/snap himself
isn’t that kind of what AUR is, and exactly what people love about arch ?
Yes but if you use an Arch distro like Endeavour, they won’t support you with issues caused by AUR apps. Because of these reasons I mentioned.
How is “the dev of the app” defined, exaxtly?
The official Developer of the app. E.g. the official dev of Blender is blender.org. The flatpak people give them a line of code to embed in their website and they use that to verify that the dev really is blender.org and not a malicious actor.
Ah, that makes sense. Inwas hung up on the word, interpreting it as a single guy, not an entity. Thank you.
This is impossible to enforce and would ruin Linux adoption on desktop
How so? How does ensuring they only the real dev of the app is also the only one allowed to package it hurt desktop adoption.
It’s very easy to enforce. Flathub need to verify the identity of the person submitting the Flatpak to make sure it’s the app’s dev uploading it and not Joe Smith or nsa.gov…
For security reasons the packaging of flatpaks in flathub is done by flathub, whether they are devs or third parties they just write the manifest. Although I seem to remember there are some exceptions, such as firefox.
Ah, I was not aware of that. Ok, that’s good to hear because it potentially adds a layer of security.
Any idea whether they vet the code as well?
Not that I know of. But you may be interested that it requires prior authorization to modify manifests.
Excellent. Thank you
