I think it is very interesting in terms of the easy deployment of specific environments, and in terms of writing recipes for new packages.
Having said that, outside of these two rather niche areas for home use, I think it is rather unintuitive and offers no real advantages over more established players that offer a more polished experience, like Fedora for workstation and gaming use.
Dev work is not specific enough. Pip is a nightmare because it just wanted to modify folders that were read only and you never know what it wants to do to your system. Your experience may vary depending on how much the language package manager assumes about your system. If you’re in a container, it will work perfectly, though
Firefox just works, and I installed Steam from nixpkgs and it worked after enabling a few settings. Then I just enabled Proton on every game and it works okay, with a few weird bugs sometimes (although I blame Gnome for messing up alt tabbing sometimes)
Also, can I “normally”/traditionally install software on NixOS, e.g. through Steam?
Depends on what you mean by traditionally. Steam works without needing any special setup by enabling it in your configuration, just programs.steam.enable = true. There’s also imperative package management with nix profile (don’t use nix-env -i which you will probably come across, it’s broken by design). Personally though I recommend sticking with the declarative configuration and nix-shell which temporarily brings packages in scope for the current shell only.
There’s two different ways of identifying a nix package: its attribute path in the package set, and the name it self-identifies as. Here’s an example where those differ, firefox-esr. Its attribute path is firefox-esr while the package name it reports is firefox.
It’s very fast to find a package by its attribute path since that’s essentially one or more map lookups. In contrary, the package name isn’t unique (for example, firefox and firefox-esr both have a package name of “firefox” because they are built from the same package file just with different sources) and also doesn’t have an index, so to find a package with a matching name you have to search through the entire package set and evaluate every package to get its name and check if it matches.
nix-env -i searches packages by their package name, which as a consequence makes it slow and also unreliable since you might not get the package you were looking for, but instead another with the same name. nix-env -iA somewhat fixes this by installing packages by their attribute path, but even if you use that you get the same issues with nix-env --upgrade since that always searches for packages to update by the installed packages’ names (it might even replace one package with a completely unrelated one which coincidentally has the same name!).
The new nix profile however stores the attribute paths a package was installed from so doesn’t have any of these problems.
Listen to the “Linux User Space” podcast, episode 404. They explain every immutability model af of now. Ubuntu Core is missing.
Ubuntu is creating something new, looks really great but based on snaps, which are not bad packages but rely on a nonfree store that cant be replaced. So meh.
I’ve made the opposite experience. There were loads of snap-specific issues when I used ubuntu. So many that I now recommend not using ubuntu just because of snaps.
VanillaOS and BlendOS also use containers to install apps, just like Fedora Silverblue. In fact, it’s easier to install native packages on Silverblue than it is on VanillaOS. Just set your terminal to start a container by default.
I think it depends on the user :P. NixOS is pretty hard to get into because the documentation isn’t great… but I’d argue it’s one of the most user friendly ways to configure a system, and it can be really nice to copy configurations from other people.
Do you get any output from # virsh list --all and # docker info?
I have a feeling it’s an SELinux issue, and i’m not familiar with how that works at all (yet 😳). May be a good call to purge virt-manager, libvirtd, docker, containerd, and reinstall them…
Edit: Fedora got an upgrade today and vm-manager works again without any issue. Docker remains broken, maybe its matter of time. Thank you for your response!!!
My approach has been to slowly learn how to play to the strengths of Linux and not pine after anything on Windows because ultimately I’ve gained a lot more than I’ve lost.
The one piece of software I haven’t been able to avoid keeping around is Sigma Studio, so I have a 10 year old shit top for running it, but it also runs in a VM if I need it. Thankfully I only need to use it once or twice a year.
If you rely on multiple pieces of software for important everyday activities and they aren’t usable in wine or a VM, you probably have no choice but to use the operating system that is the best vehicle for those tools. Doesn’t stop you from also using linux for other stuff, but I can understand how that’s not the same as going all in.
This new entrant in the immutable space is not a replacement for ordinary Ubuntu
Not yet the replacement. It will be and I bet Canonical is targeting 26.04 LTS to do that. This is just the next step of trying to force all their users into Snap, just like when Flatpak was banned from being in by default of community-supported but official Ubuntu variants such as Xubuntu.
to answer to question in the title, on top of what was already said: i just code them myself. of course, it doesn’t work for everything, but for simple programs, i can write a script or a proper thing that does the specific task i need!
It’s a thing that’s built on top of wine (Windows application compatibility thingy). Its purpose is to create environments for Windows applications in a very user-friendly manner with a GUI. I think whatever you can do in Bottles, someone could do with the terminal using wine but that’s difficult.
Haven’t used Bottles in a while but you just get the .exe file like you would when using Windows OS, then you put it in the Bottles, and it should run. I have no clue about the details, but if you click enough buttons, it should work properly.
I’m having issues too. I’d just use a VM at that point xD. With Bottles it’s usually hit or miss but with a VM, almost anything works. Sorry friend🤧
Edit: my virtual machine manager of choice is GNOME Boxes because it’s very easy to use. If it doesn’t work it usually means KVM or SVM (one of them) is disabled in your BIOS.
As much as I have issues with the snap implementation, I really want to live in a world where my base os is solid and everything else is easily updatable. LTS, with the latest apps.
Snap and flatpak achieve this, and I want more of that. Just less… frustrating. And less not-invented-here like.
Flatpak cannot do what’s discussed in the article. Snap can and it was started prior to Flatpak. If Flatpak was able to do what Snap can, you’d have half a point.
Flatpak cannot do what’s discussed in the article.
Nobody claimed 100% feature overlap. For regular GUI applications both work relatively similar, to the point that Snap now happily uses technologies developed for Flatpak, such as Portals.
it was started prior to Flatpak.
That’s irrelevant. One could just as well argue that Flatpak evolved from developments (OSTree, etc.) that are even older but that beside the point. Fact is that OSTree and Flatpak are vendor neutral and Snap isn’t. Attempts at vendor lock-in caused Valve leave Ubuntu and later choose Flatpak on SteamOS.
Snap has the ability to do the base system in a much more modular way and could be really cool for an immutable system. Forcing them on desktop users with their transitional deb packages and making it heavily integrated with only one repository really screwed it up.
Also I’m not sure about slow startup times. Are those still an issue? If so, then I would be sure to considet Ubuntu dead and not only not recommend it but actively recommend switching away from it.
Yes, they are still an issue. It is irritating enough that I have currently zero snaps and would rather build from source if snap is the only binary option.
That’s basically THE dealbreaker for snaps. Loop devices on lsblk? Most people don’t care and wouldn’t see it. Proprietary backend? Again, most regular people (Ubuntu’s target audience) do not care. So the slow startup time is THE dealbreaker.
I know this thread is likely to quickly descend into 50 variants of “ew, snap”, but it’s a good write up of what is really a pretty interesting novel approach to the immutable desktop world.
As the article says, it could well be the thing that actually justifies Canonical’s dogged perseverance with snaps in the first place.
I actually don’t understand the issue people have with Snaps. The main gripe seems to be “It’s controlled by Canonical”.
But why is it an issue that Canonical controls a source of software for their own OS? Isn’t that the same with every distro’s repository?
But why is it an issue that Canonical controls a source of software for their own OS? Isn’t that the same with every distro’s repository?
No. You can add any other repository to apt, rpm, Flatpak, etc. You cannot do the same with Snap and that’s by design. Canonical wants to be the sole gatekeeper of Linux software, hoping that all developers have no alternative but to publish software on the Snap store (ideally only there) which works best on Ubuntu.
Exactly. I feel they want to sell it to a big player, but no big player will touch it unless they can fully control it. Hence snap as part of that plan. Ubuntu is a hell no for me.
How would they trap everyone in the ecosystem?
This isn’t Apple, there’s a gajillon other ways of getting software you can use on every single linux distro.
Then I guess it’s a good thing they don’t control all other Linux distros.
But they would to a degree if the Snap Store would actually succeed becoming the Linux app store (like Steam is for games but that’s more because all other vendors don’t care to make a Linux client).
From reading this that’s not the whole story. Someone working at canonical successfully made a version of snap that could use alternative stores, but the default version does not allow it
And honestly at the point of installing that modified version you may as well just install a different package manager anyway
You can; the issue is that you can’t add two snap repositories at once.
This is functionally pretty much the same thing, as nobody is likely to want to use snap while locking themselves out of the main snap repository, but it’s still important to make the distinction.
In theory I guess there’s nothing stopping you setting up a mirror of the main snap repo with automatic package scraping, but nobody’s really bothered exploring it seeing as no distro other than Ubuntu has taken any interest in running snap.
It’s all open source so there’s no reason you couldn’t fork it and add that functionality. Although it’d probably be a fairly involved piece of work; it wouldn’t be a simple one-line change.
It’s not all open source. Canonical merely made available a super simple reference implementation of the Snap server but the actual Snap Store is proprietary.
I was referring to snapd, which is the thing that actually has the hard limit on a single repository. That’s fully open source (and there’s one major fork of it out in the wild, in the form of Ubuntu Touch’s click). The tooling for creating snap packages is also all open source.
The APIs which snapd uses to interact with its repo are also open source. While there’s no turnkey Snap Store code for cloning the existing website, it’s pretty trivial to slap those APIs on a bog standard file server if you just want to host a repo.
Not open-sourcing the website code is a dick move, but there’s nothing about the current set up that would act as an obstacle for anyone wanting to fork snap if that’s what they wanted to do. It’s just with flatpak existing, there’s not a lot of point in doing so right now.
I’m pretty excited about it. It’s a much cleaner solution to the problem immutable OSes are trying to solve. Dare I say it’s better even than the Android model because it covers the whole stack with a single system.
I appreciate that they try, and as much as I dislike some of snap’s design choices I think it has a place. Flatpak appears to be the winner in this race however, and I feel like this is Unity all over. Just as the project gets good they abandon it for the prevailing winds. I’ve been told the snap server isn’t open source, which is a big concern?
Unlike desktop environments where there were equivalent alternatives to Unity, Flatpak isn’t an alternative to Snap that can deliver an equivalent solution. You can’t build an OS on top of Flatpak. This is why I think that if Snap makes the lives of Canonical developers easier, they’ll keep maintaining it. We’ll know if Ubuntu Core Desktop becomes a mainstream flavor or the default one. I think there is a commercial value of it in the enterprise world where tight control of the OS and upgrade robustness are needed. In this kind of a future Snap will have a long and productive life. If it ends up being used only for desktop apps which Flatpak covers, it may fall by the wayside as you suggested.
Absolutely, and I think that’s why snap has a future at all. Immutability is the future, as well as self-contained apps. We saw the explosive growth of Docker as indication that this was the way. If they can make their tooling as easy as a Dockerfile they will win just by reducing the work needed to support it.
I don’t like Canonical pushing snaps as universal apps for all distros, because of issues like sandboxing not working on mainline kernels.
But it’s pretty interesting to see how a fully snap based desktop OS could look like. It might have less limitations than rpm-ostree. Easy access to recent mesa and similar would be awesome.
Snap makes a lot of sense for desktop apps in my opinion. There’s a conceptual difference between system level packages that you install using something like APT, and applications. Applications should be managed at the user layer while the base system should provide all the common libraries and APIs.
It’s also worth noting that this is a similar approach to what MacOS has been doing for ages with .app bundles where any shared libraries and assets are packaged together in the app folder. The approach addresses a lot of the issues you see with shared libraries such as having two different apps that want different versions of a particular library.
The trade off is that you end up using a bit more disk space and memory, but it’s so negligible that the benefits of having apps being self-contained far outweigh these downsides.
The problem here is that for that purpose, Flatpak is better in nearly every way and is far more universal
I think Snap makes the most sense for something like Ubuntu Core, where it has the unique benefit of being able to provide lower level system components (as opposed to Flatpak which is more or less just for desktop GUI apps), but it doesn’t make sense for much else over other existing solutions
The same thing I’ve always done - booted another OS that works with that software. No need to artificially limit yourself.
Once upon a time I remember running Dos, windows, os2 warp, and linux on one hard drive. Those were the days…. Ya ya, I’m going back to my retirement home bedroom…
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.