trevor

I've packaged a CLI that I made as a flatpak. It works just fine. Nothing weird was required to make it work.

The only thing is that if you want to use a CLI flatpak, you probably want to set an alias in your shell to make running it easier.

I'm not sure why more CLIs aren't offered as flatpaks. Maybe because static linking them is so easy? I know people focus on flatpak sandboxing as a primary benefit, but I can't help but think of static linking was easier for bigger applications, it wouldn't be needed as much.

I'm not quite sure why you think pointing out someone's confidently incorrect claim that containers do give you reproducible environments means that I fetishsize anything?

But if you genuinely want to know why reproducibility is valuable, take a look at https://reproducible-builds.org/.

I was quite happy to see that Debian and Arch have both made great strides into making tooling that enables reproducible packages in recent times. It's probable that, because of efforts like this, creating reproducible builds will become easier/possible on most Linux environments, including traditional container workflows.

For now though, Nix Flakes are much better at enabling reproducible builds of your software than traditional containers, if you can suffer through Nix not being documented very well. This article covers some more details on different build systems and compares them with Nix Flakes if you want more concrete examples.

FWIW, I think that containers are awesome, and using them for dev environments and CI tooling solves a lot of very real problems ("it works on my machine", cheap and easy cross-compilation for Linux systems, basic sandboxing, etc.) for people. I use containers for a lot of those reasons. But if I need to make something reproducible, there are better tools for the job.

🤡

So, containers do not get you reproducibility.

For dev environments, repeatable is okay. If you want actually reproducible binaries that you can ship, Nix is better fit for that purpose.

Care to elaborate? Containers give you repeatable environments, which are not the same thing as reproducible environments.

Okay, so this definitely feels like bad practice to not change the version number or URL, even in something trivial like example texts here. But what real-world significance does this have?

It almost seems equivalent to just changing a variable name based on how it's being used, which -- to be clear -- should come with a version bump, but I can't imagine this having any meaningful impact anywhere.

The biggest downside to containers vs. Nix for me is that Nix can produce binaries for Linux and macOS, whereas docker only helps with Linux unless you can perform literal magic to cross-compile your project on Linux for macOS.

Containers also don't give you reproducible environments, and Nix does.

That said, Nix documentation is ass, so I usually end up going with containers because they require far less suffering to get working because writing a containerfile is much easier than guessing how to hobble together a Nix flake with a mostly undocumented language.

Yeah. I was annoyed by this, but wouldn't assume bad faith on the part of the Fennec devs.

The owning class is the only minority group that does you any harm.

All those packages, but terrible/lacking documentation and LSP support 😭 And, yes, I've tried nixd and nil, and they're not even close.

I've tried to learn Nix multiple times, and even got by okay running NixOS for a year or so, but doing almost anything that isn't just adding a package to a list in a nix file or flake was like pulling teeth because everything is documented so poorly (or not at all). It would take me hours to do what I could have done in seconds with any other package management tool or configuration management because I'd have to scour hundreds of search results to find someone that did the thing I'm trying to do because there was little-to-no documentation for it.

Nix is a tool with amazing promise that could solve so many problems if they could get their documentation and LSP support up to the standard of something like Rust.

I would say that development is the one thing that can get very annoying on immutable distros.

Flatpaks can only get you so far (as seen by the VS Code Flatpak's limitations that have to be worked around). I don't even use VS Code, so I can get around that pretty comfortably, but I have to use Distrobox for a lot of miscellaneous developer tools, and even then, I still run into problems and I can't install container tools inside of the containers that I'm already working in.

Not to discourage you from trying. I can still get by with some dev work on Bazzite, but it's waaay easier to do the same dev work on CachyOS (Arch-derivative) because I can just install shit normally and it will work.

Same. If most of my games stopped working, I would be very annoyed, especially because it was entirely preventable.

Thankfully, the Fedora project and community agree.