trevor (he/they)

I posted this in another thread, but reposting here because a lot of people, including myself up until very recently, were under that impression:

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 that if static linking was easier for bigger applications, it wouldn’t be needed as much.

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.

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.

This is why I hope to see rule zero get shit-canned. It’s a naive vestige from a time long before we hit late-stage capitalism. Corporate interests have slithered their way into every facet of our lives and we should be working to make software that we write hostile to their practices as much as we can.

If that means that the organizations that have a stranglehold on Open Source™️ don’t like it, so be it. We can follow in the spirit of open source without the naivety or captured interests of organizations that define the arbitrary terms by which we categorize software licenses.

Yeah. A lot of the extra nice things about Ghostty come from native macOS features. It’s a very different story on Linux, but still a solid terminal emulator there as well.

Ghostty is amazing on macOS. On Linux, it’s basically another GTK terminal emulator with a lot of nice configuration options, but nothing that special.

I beg of you: try something that isn’t going to shove a broken packaging format like Snaps down your throat.

Try Pop!_OS or Linux Mint if you want something like Ubuntu, only not broken.

If my first experience with Linux involved wasting time trying to figure out why the applications I installed appeared to freeze because they take 30-60 seconds to open after installation or updates, randomly didn’t work because of dogshit sandboxing, etc., I probably would have turned away.

Actually yeah. You’re right. Even better 😌

A lot of incorrect assumptions in this article. If you don’t like the idea of a key exchange over passwords, I hope you use password auth when you SSH into things 😁

The word passwordless is nonsense. In most cases, most passkey implementations, you need a PIN to unlock your private key to authenticate. PIN = password, except it’s numbers only. Nonsense. Passkeys simply obfuscate the problem and move it somewhere else, most often into a PROPRIETARY key management tool. For example, Microsoft wants you to use THEIR authenticator app. Not just any app that adheres to the standard. Nope. This effectively means super-vendor-lock-in. Absolute nonsense.

You can argue that the term “password less” is nonsense, but there is literally nothing about the spec that prevents you from using passkeys as they were designed: with hardware keys that support the open FIDO2 authentication protocol. Yes, you still need a second factor to verify the authentication attempt (via a PIN), but unless you’re mailing that key to hackers, the private key generated by your SoloKey, NitroKey, or another open source hardware key, is more secure than any password ever will be.

Passkeys usually require a phone - this is a single point of failure, and one that gives the big companies extra control over you. Phone, number, SIM, and so forth. A beautiful bevy of data. The whole idea of actually having to use your phone as an identity vector is horrible.

Phones support storing passkeys. Phones also support storing passwords. In no way does this mean you must use them for this. You can either use hardware keys, or you can use your favorite open source password manager to store passkeys where you should already be storing your passwords anyway.

You need “biometrics” to supposedly prove you’re you to unlock your private key. Biometrics are a form of password, except you can’t replace it, and it also gives yet more of your personal data to the big companies. More nonsense.

This is literally a direct contradiction of what the author said in their first bullet point. Use a PIN if you don’t like using biometric auth.

The implementation of passkeys is fragmented, vendor-specific, and complicated. Only diehards who love technology can use this. The same kind of people who were “all in” when IoT/cloud crap came out, and now they see their smart homes slowly go offline as big vendors almost arbitrarily cut support for old gadgets and effectively kill products. Because cloud.

Most of this is actually a fair critique. The FIDO Alliance is still working on the spec, and I think they should require any implementation of passkeys to follow the spec to a tee without adding any kind of nonstandard bullshit to their authentication.

However, most advancements in tech begin with only appealing to enthusiasts and later become adopted by wider audiences. It doesn’t make them bad that they aren’t immediately popular with everyone.

Passkeys only solve one use case - phishing where the user inputs their password and MFA into a fake site.

I’m glad the author can at least recognize that there’s at least one thing that passkeys solve that passwords can’t. But it’s not the only thing. When you enter a password on a site, you’re hoping like hell that the service you’re using hashes it and hashes it properly. When you authenticate with passkeys, you’re sending the site a public key. This key will have way more entropy than any password will, so anyone trying to crack a hashed public key is in for a long, miserable time (obviously not impossible though). But even if they wasted their time doing that, it’s a public key. Who cares?

Any service you use passkeys with instead of passwords won’t put you in another leaked password database. The public key just needs to be invalidated and you can move on with your life.

Gross.

My issue with snaps is also the power that Canonical has to fuck you over one day, because of the centralization that you mentioned, but also that their shitty fucking packaging format sucks ass and breaks everything but the most basic of apps. I’ve wasted hours trying to help people with their broken applications that were hijacked when they typed apt install whatever and “whatever” was actually a fucking broken snap package.

Flatpaks and AppImages actually do the fucking things they’re supposed to. Snaps don’t, and Canonical is pulling a Microsoft by hijacking your package manager.

Also, Snap sandboxing only works with AppArmor, so if you were hoping that all the breakage was worthwhile because you get sandboxing, you don’t if you’re on anything but a handful of distros 🙂

Fuck that. The Linux gate is wide open! Anyone that wants to use Linux, come on in!

And for your own sake: use anything but Ubuntu and their buggy Snaps.

Thanks! That first link is an excellent resource for a security tool I’m working on. Specifically, gVisor, which I hadn’t heard of, but looks like an excellent way to harden containers.

I may rebase to secureblue from Bluefin at some point to give it a try.