NixOS is making me less afraid
Posted by ibobev 2 days ago
Comments
Comment by s08148692 1 day ago
Not because it's suddenly got better, but because the learning curve has collapsed to a flat line. My problem with linux has always been how un-user friendly it is. Constant tinkering around with config files and googling how to fix problems. Now I just install claude code and tell it what I want my OS to be and how I want it to look.
Comment by andrewla 1 day ago
There was a point where I was working heavily with Nix and increasingly frustrated with its arcane syntax and way of doing things that made a conceptually extremely simple system into one of almost nightmarish complexity; juggling strange default and environment variables and seemingly random command line tooling. Inscrutable documentation that absolutely refused to define very basic concepts but went into insane detail on irrelevant details.
I had numerous ideas around fixing this and contributing to the project, and made some small contributions.
But now... Claude lets me just work around this by figuring out how to make it work. So now I don't understand and don't have to understand. I still look at the generated flakes, etc., when I'm dealing with it, but I'm rapidly losing the motivation to do that if things are just working.
I think this is bad but for reasons I can't quite put my finger on. Except to say that having complex tools with simple interfaces (Claude) is risky.
Comment by iamnothere 1 day ago
That said: the main fear here probably comes from the enormous size of nixpkgs and the overall cost of the infrastructure. Most individual package definitions should be relatively easy to maintain. So perhaps it isn’t such a big deal, if Nix infra built packages more slowly and reduced the scope of the repo then it could probably cope with having fewer maintainer hours available and less funding.
Still, something about it feels like a Tower of Babel situation. It goes just far enough beyond most people’s understanding to feel like it has fractal complexity. (Although it really isn’t that bad once you’ve spent enough time with it.)
These days I am more interested in simple, self-contained systems like OpenBSD than impressive feats of engineering. I still prefer Nix for most “work stuff”.
Comment by WillAdams 1 day ago
https://news.ycombinator.com/item?id=47300747
c.f.,
http://literateprogramming.com/
Last month I bought a flet.dev subscription (and tokens 3 times over --- the recent update seems to be far more efficient in terms of what one gets for a given token spend?) and have been using it to try to make some small apps for CNC work and I am currently dismantling one based on converting the generated .md documentation and re-writing it with the source code inserted at appropriate places and with added commentary and documentation and links --- I'm confident that when I'm done I'll have a tool which I understand and which if need be, could be re-created w/o AI help, or ported to some different UI toolkit/build system.
Comment by amelius 1 day ago
Comment by rafterydj 1 day ago
Comment by danslo 1 day ago
Comment by ibobev 1 day ago
Comment by tom_alexander 1 day ago
Comment by ibobev 1 day ago
Comment by routelastresort 17 hours ago
I can confirm all of your comments, and someone will come up with something similar that's easier on the eyes.
Comment by embedding-shape 1 day ago
Comment by ibobev 1 day ago
Comment by brendyn 1 day ago
That being said, having worked on guix packages. Automated conversation is not so simple. The bottleneck for me is compilation time and cost. even with superdooper intelligence, you have to trial and error builds, fix mysterious test race conditions and match versions.
A powerful $5000 build server plus another several thousand per year for The electricity cost would go a long way to speeding up this process. Old second hand computers are not viable because the electricity cost for constantly building software on them is not cost effective.
It makes me kinda buthurt when some racist rich people can raise millions for some crappy arch skin distro soft fork, but serious, novel, from the ground up projects have to scratch around in the dirt for pennies. The project may not have truly demonstrated it's worth to justify replacing nix, but I feel it's unique and special enough that it is deserving of some money falling from the sky. It's 1 of only 2 of this style of functional packaging distribution.
Comment by chuckadams 1 day ago
Comment by clhodapp 1 day ago
Comment by graemep 1 day ago
i realised long ago this is usually a self-inflicted problem. Some of us (myself included) cannot resist tinkering with something that works reasonably well. When we use Windows its hard to tinker so we leave well along. Linux lets you tinker so we keep trying to reach perfection, and that breaks stuff.
Comment by mft_ 1 day ago
Claude has definitely helped to reduce this negative!
Comment by yoyohello13 1 day ago
Comment by ibobev 1 day ago
Comment by newsoftheday 1 day ago
Comment by graemep 1 day ago
The worst my family have had was an MS surface running a rolling release distro because it was the only way to get the touchscreen working which failed at a bad time. Now switched to a more stable distro and looks OK.
On the other hand most laptops and all desktops have been trouble free. Even running a rolling release distro (Manjaro) has been fine on a laptop that was designed for Linux (and sold with Linux preinstalled).
Comment by graemep 1 day ago
Comment by wolvoleo 1 day ago
I think that tinkering serves a purpose. If you don't fully understand your tooling, you won't be able to fix it when something breaks. Tinkering teaches you that.
Also, you might miss out on improved workflow by leaving things alone.
The whole reason I use FOSS is that I don't some big tech architect to decide for me how my computer should work.
Comment by graemep 21 hours ago
I also find the people developing FOSS give me more choices and my computer works closer to what I want by default.
Comment by 0x457 1 day ago
If I have issue with nixos, its 99 out of 100 times going to be package I pulled either from nixpkgs-unstable or 3d party flake.
NixOS make it less of a problem because I can alwasy switch to previous generation and build all of my hosts before switching any of them.
Some distros are worse then others though. Ubuntu (used to?) for some reasons loved switching nvidia drivers OSS version that does not work every update or break keyboard layout switcher. I never had such issues with NixOS, but with NixOS I have "kernel updated, reboot required" issue that I had setup alert for[1].
[1]: Only issue on a host that has nvidia card because nvidia being nvidia.
Comment by onefiftymike 1 day ago
Some of it is real pain points, and those are annoying that they aren't baked into the distro from the beginning.
Comment by M95D 1 day ago
For example, in 1996 I tweaked the buttons on Total Commander's main button bar (was called Windows Commander back then). I still use that same button bar today, 30 years later. Only some icons had to be replaced. I try to do the same in Linux, but...
There are some programs where this just doesn't work. Firefox for example has a bad habit of deprecating settings and adding new ones (with wrong defaults, because... money probably). It needs tinkering all the time.
Comment by graemep 21 hours ago
Comment by sigbottle 1 day ago
Comment by graemep 1 day ago
I tinker with one ARM based tablet, which never works quite right but because its a secondary device with limited use anyway its not a problem. My work laptop does not get messed around with unless necessary.
Comment by ferroman 1 day ago
Comment by perrygeo 1 day ago
Comment by DanielHB 1 day ago
Comment by Aurornis 1 day ago
What does this have to do with Nix, though? If you’re using an LLM to run everything, you don’t even need as many layers of abstractions or tools.
Comment by 1una 1 day ago
Comment by JamesSwift 1 day ago
And likewise if theres an issue then its much more straightforward for it to unwind what it did in nixos vs a traditional software install and not accidentally mess with other users/services on the system.
Comment by ViewTrick1002 1 day ago
Compared to poking at a mungy ball of accidental state where every change introduces complexity for the future which every downstream agent needs to correctly find.
Comment by TheJCDenton 1 day ago
Comment by vondur 1 day ago
Comment by raffraffraff 1 day ago
MiniPC network device doesn't have a Linux driver. At all. Had to get a vibe-coded, reverse engineered one. This was a first for me.
NAS (ugreen) was a pain in the ass to install my own OS on (I didn't trust theirs, wanted OpenSUSE, and had to get a reverse engineered LED controller driver so I could display hard drive health)
ASUS Laptop will not sleep properly, and would drain the battery flat in a day or do. Myself & Claude gave up after days of trying various tricks workarounds (up to BIOS hacks). The best I can do is hibernate (after about 5 minutes of sleep) but man, the hacky bullshit required to get there was incredible.
Different laptop sleeps fine but will not, under any circumstances, hibernate. Even though I have all the crazy tricks up my sleeve from the ASUS that won't sleep properly and needs to hibernate. Different hardware, totally different bullshit problems.
And then I recently got an Macbook M1 Max for local LLM hacking and everything just fucking works. I don't like MacOS but the hardware is amazing and the OS just fucking works with it (and I like that).
Comment by cromka 1 day ago
Almost 10 months on Fedora Asahi, so somewhat experimental platform, and had very little issues, nearly none.
Comment by cassianoleal 1 day ago
It can be clunky at times but I have no regrets. I’m now toying with the idea of multi-booting with Silverblue or a derivative, and guess what? I actually can do that if I want.
Comment by unicornporn 1 day ago
Comment by ThePowerOfFuet 1 day ago
What could possibly go wrong.
Comment by Markoff 1 day ago
I remember trying to remap keys in Linux Mint and install Chinese language keyboard were both major PITA requiring Claude/ChatGPT, while on Windows I could do it without any help in few minutes (the keyboard in seconds)
Comment by hibikir 1 day ago
Comment by ndriscoll 1 day ago
I wouldn't be surprised if it could better deal with Linux issues than Linus.
Comment by exitb 1 day ago
Comment by haolez 1 day ago
I'm interested in NixOS, but I'm at an age where I just want things to stay stable and change only when they really have to. I already have a lot of big mandatory changes from life itself, I don't need more :)
I'm writing this in good faith. I'm genuinely curious and interested in trying it again.
Comment by georgyo 1 day ago
It's a thriving open source ecosystem. There are forks, there are differing opinions, and in-depth discussions.
But, universally, everyone agrees that nixpkgs, independent from any implementation, is the real value of nix.
That said, things change. OpenSSL 4, glibc 2.44, gcc 16, etc which then requires a bit of tweaking every now and then.
Comment by eddieroger 1 day ago
Comment by georgyo 1 day ago
They are defacto stable in that everyone is using them and the interface is not really going to change at this point.
But they are still marked as an experimental feature.
To get them out of experimental, the requirements are
normalizing the CLI. Currently some options are global and some are local to a command. The plan as I understand it is to make them all local. This would make it clear which options any particular command actually take instead of guess work. They are not going to break usage, but make the usage more clear.
And fetchTree needs to be stabilized. A big criticism of flakes is that they had a nonstandard method of fetching data and repos. fetchTree is a new nix built-in that behaves the same way. This makes flakes a lot less special.
So, nix flakes are a stable experimental feature, slowly getting to the state that it won't be experimental any more.
Comment by wojtek1942 1 day ago
I know not everyone is a fan of DS, but this post has a nice, concise explanation of how to think about the state of flakes.
Comment by JamesSwift 1 day ago
Comment by iamnothere 1 day ago
Comment by usumgallu 1 day ago
Comment by scronkfinkle 1 day ago
Comment by techjamie 1 day ago
I just go into the directory with the software and tell Claude Code to make me a Nix shell or a Nix flake that can run the software. Then usually within a couple minutes it'll work out what it needs to run and build it.
I recently did the same thing with ComfyUI which I was running through Conda. I had Claude code go through and figure out how to make it run just in a plain nix shell with a venv. (I always struggled getting it to recognize my NVIDIA GPU without Conda)
Comment by clircle 1 day ago
(oci-container-configuration
(environment
'("CRON_MIN=2,32"
"LISTEN=0.0.0.0:80"
"OIDC_ENABLED=0"))
(image "freshrss/freshrss:edge")
(log-file (container-log "freshrss"))
(extra-arguments
'("--pod=freshrss"))
(provision "freshrss")
(respawn? #t)
(volumes
'("...")))Comment by Cyph0n 1 day ago
But it’s just really hard to articulate. NixOS is such a step above any other distro that it becomes hard to convey exactly why this is the case. It is also because so many pieces work together in tandem - both above and below the covers so to speak - to make this the case.
There is really only one talk I have found that somewhat captures this, What Nix Can Do (and Can’t) by Matthew Croughan: https://youtu.be/6Le0IbPRzOE. Keep in mind that it’s a rapid fire-style talk with a ton of breadth, so it is natural to feel overwhelmed while watching if new to Nix :)
Also, here is a random dump of features that I have found both valuable and very difficult to achieve on other distros:
* Config rollback in bootloader to undo mistakes without needing to boot from recovery media
* Flake lockfiles to pin all config and packages
* Config layering: base config that applies to all machines, per-machine overrides, etc
* NixOS module system, very useful to conditionally enable functionality (e.g. subset of machines run Syncthing)
* Rebuild a host over SSH by copying over packages via nixos-rebuild
* Image builders i.e. Packer-lite (now in nixpkgs)
* Build a live CD/USB custom installer to quickly boot from with your own packages, user, dotfiles, etc
* NixOS integration testing framework (extremely powerful), makes package and config stability better under the hood in nixpkgs
* Build and run your config as a QEMU VM
* nixos-anywhere to convert a running Linux machine into NixOS, very useful for VPS/cloud machines
* Out of the box support for cross compilation and static linking via pkgsCross and pkgsStatic
* Stylix for centralized theming config across apps
* Natively build a Docker image from your package using dockerTools
Comment by gnarula94 1 day ago
+1! This is immensely useful when running on hardware where builds can take a long time due to limited resources, like a Raspberry Pi.
I recently came across https://github.com/halfwhey/nix-apple-container which allowed me to configure nix to build for Pi using containers on MacOS.
Comment by eleventen 1 day ago
Miniflux homepage really undersells it.
Comment by Chiron1991 1 day ago
If the web interface is too minimalist/archaic for you, there's plenty of alternative frontends available you can deploy along. Personally, I'm using reminiflux (inspired by Google Reader).
Comment by SmashDan 1 day ago
Comment by ronef 1 day ago
Comment by mikl 1 day ago
Comment by edukite 1 day ago
Also everything is running in kubernetes isolation so my OS is immutable and consume much less disk space than NixOS (I don't have too much of it and future is looking bleak in this department)
Comment by clhodapp 1 day ago
> I prefer to bootstrap them from I laptop with a single command
Nix is great at that kind of stuff
Comment by edukite 1 day ago
Comment by wrxd 1 day ago
Form that configuration I can build everything on one of my machines and push the builds to the others. Or each machine can do its own builds.
Have a look at projects like NixOps or Colmena to see some more automation on top of standard builds targeting other machines.
Comment by edukite 22 hours ago
Comment by clhodapp 19 hours ago
Comment by clhodapp 1 day ago
There are several ways to do this. For one, see: https://github.com/nix-community/colmena
Comment by orbital-decay 1 day ago
Comment by 63stack 1 day ago
Comment by zahrevsky 1 day ago
I've struggled with the same problem, and Coolify helped me with it. It supports auto-deployment from GitHub via a bot integration, so you don't have to manage Github Actions. It can also deploy from a Docker Compose file, which is good for self-hosting other people's projects.
Of course you still have to have a list of instructions on how to set up your server with Coolify. But at least it's a finite set of instructions, meaning you don't have to update it every time you host a new project.
Comment by ChaseRensberger 1 day ago
Comment by gagik_co 1 day ago
Comment by poulpy123 1 day ago
Comment by rgoulter 1 day ago
You pay a higher upfront cost, but you end up with declarative code which has advantages for maintenance.
With NixOS, rollbacks from changes to system state are trivial; and the whole system is configured from a single starting point, which makes it easy to track down why things are a certain way.
For a personal workstation, it's not necessarily a practical trade-off.
Comment by bigyabai 1 day ago
It's even better with flakes. I can keep dozens of projects on-disk, and their dev environment is always versioned + synced with my workstation. I've torched entire weekends trying to get the same workflow out of direnv and pamac/homebrew. On Nix systems, it all lives in one or two git-synced files.
Comment by NelsonMinar 1 day ago
Comment by actinium226 1 day ago
This is true, and the same is true of shell scripts, but isn't it true of nix as well? If you update nixpkgs and then install something, you have the same chance of getting a new version of it as you do with the `sudo apt-get install` in the Dockerfile, no? I had once looked into using nix to intentionally install older versions of software and it was not as easy as I had hoped.
Comment by ndriscoll 1 day ago
I imagine people do this somewhat regularly at least to e.g. occasionally pull in a package or two from unstable when they normally run a stable system.
Comment by actinium226 1 day ago
Comment by ndriscoll 1 day ago
If you have a CI system that's building containers (e.g. using flakes), you can have the nixpkgs version you're using pinned in your own config, so you can just look at your own (smaller) history.
This should all be way easier than trying to do it on any other distribution.
Comment by wrxd 1 day ago
Comment by YoshiRulz 1 day ago
Comment by Cyph0n 1 day ago
Comment by dlivingston 1 day ago
Comment by lrvick 1 day ago
If you want high supply chain security appropriate for production use, it is a lot more work that a lot fewer people are willing to do, which means far fewer packages. Though probably the packages you need for a server or build system or minimalist workstation.
See https://stagex.tools for contrast.
Comment by rgoulter 1 day ago
This is somewhat inaccurate, and loosely written.
It would be more meaningful to talk about the nixpkgs repository. If you wanted to, you could use Nix with your own vetted nixpkgs codebase.
Whether there are any contributors who can merge without review I'm not sure, but the typical path for contributions is to go through review.
Comment by lrvick 19 hours ago
Review is entirely honor system in the nix ecosystem.
This is a hard truth I really need those promoting it for high security use cases to understand.
Comment by cromka 1 day ago
Wonder how they'll manage the supply chain risk.
Comment by cobertos 1 day ago
Comment by drdexebtjl 1 day ago
services.restic.backups.my_repo.paths = [ config.services.freshrss.dataDir ];
The point is that you write the general part of the restic config (like the schedule and the S3 endpoint) once, in one place (i.e restic.nix). Then each service-specific part of the restic config, like the line above, lives next to other configs for the freshrss service (i.e. freshrss.nix, not restic.nix). Then a build step generates scripts and systemd units for restic from the merged config. This makes it very easy to remove any service and all traces of it, even when it has “cross-cutting” configs.Comment by neobrain 1 day ago
You can assign a value to `services.restic.backups.my_repo.paths = [ ... ]` in multiple places throughout your system configuration. When applying the config, all the values will be merged into a single list.
This is important because other standard tasks besides backup (e.g. firewall, monitoring, ...) also require per-service configuration. If every one of these tasks had only a single place where you needed to put a megalist of services (which is basically how `/etc` works on typical Linux distros!), this would quickly scatter the configuration that pertains to FreshRSS over N different files, making it hard to track where everything lives.
Comment by drdexebtjl 1 day ago
Aside from services, this pattern is everywhere once you start recognizing it. For example, my Claude Code config in Nix adds CLAUDE.local.md to the global gitignore, my Git config adds aliases to my shell, and my terminal config adds a monospace font to the system fonts.
Comment by cinaboniver 1 day ago
https://github.com/NixOS/nixpkgs/blob/nixos-26.05/nixos/modu...
Comment by awithrow 1 day ago
Given the flake for freshrss doesn't have any sort of explicit "backup" option, my hunch is the author is doing something similar. Point the data dir to a location that gets automatically sync'd elsewhere.
Comment by Xophmeister 1 day ago
https://github.com/Xophmeister/backer-upper/
I believe there are NixOS options to do this periodically -- which is even easier -- but I specifically wanted on-shutdown backups.
Comment by lp92 1 day ago
I have a container running on GGoogle Cloud Run within the free tier. It runs runs twice weekly as well as once a month (for monthly news summary) to parse through specifically setup Google News RSS feeds and then trigger an email with key news items I'm specifically interested.
Gemini is used for determining which articles to include and exclude from the email summary based on my predefined criteria. It works really well in being able to keep on top of specific industry/tech news I'm interested in.
Comment by throwaway888666 1 day ago
Comment by dlivingston 1 day ago
But of course you could customize it to look like any distro or even something totally new; I use hyprland with a pretty unique setup.
Comment by nefariousoctopi 1 day ago
Comment by dalben 1 day ago
Comment by opengrass 1 day ago
Comment by rubiquity 10 hours ago
Comment by ChaseRensberger 1 day ago
Comment by tosser811 1 day ago
Comment by Chiron1991 1 day ago
Comment by tosser811 1 day ago
Comment by Cyph0n 1 day ago
Comment by atrus 1 day ago
Comment by ChaseRensberger 1 day ago
Comment by neobrain 1 day ago
That said, cool if pacman and AUR work for you, no need to change just for the sake of it!
Comment by tosser811 1 day ago
I'd say Nix is even easier than pacman/AUR from a maintenance perspective because you can create overlays for whatever you'd like to change and not worry about the mechanics of building your own packages. The overrides are just maintained in the flake or nix config. Also there are already a huge amount of packages in the nixpkgs repo (probably more than base Arch + AUR.)
Comment by yoavm 1 day ago
Arch is really great, but using the system now for ~5 years I cannot remember where every configuration is, which packages are installed and why, and things just get messy. I'm sure that some issues the system has are do to things I screwed up along the way, and these will be solved if I just reinstall. But with NixOS it feels so easy to find what changes you've done to the system, to leave a comment saying why etc. It feels to me much more maintainable.
Comment by ChaseRensberger 1 day ago
i agree things get a bit messy but i try to keep the OS in a state where I can reinstall at any time without any trouble.
config files on github, pacman -S any tools i need, important docs all in the cloud already, couldnt get much simpler than that imo
i do get the desire to have a reproducible OS, just dont know that its something i need
Comment by miladyincontrol 1 day ago
Comment by boredatoms 1 day ago
Comment by Nerdrotic 1 day ago
Using unstable will result in breaking changes giving you a headache. Trying to run a bleeding edge modern laptop with some of the absolute latest software versions is only going to blow up on you and you'll be stuck trying to work around upstream breaking changes that are not even the fault of NixOS.
Lately, I use NixOS on servers mostly without flakes and use flakes and Home Manager on Win11 WSL & macOS Darwin. However, NixOS on my laptop and workstation blew up on me with a blank black screen on every boot. There were no code changes just updating stable / unstable nixpkgs and it refused to boot. A.I. couldn't figure out what the problem was. It wasn't the video drivers; it was some kind of kernel bug with the latest kernel that bit me. I ended up with a bricked system even after burning a new ISO and wiping it out, the new installation failed in the exact same way. Trying an older kernel didn't fix it either. It would boot from flash ISO install everything, but first boot resulted in the black screen. It was eventually fixed 2-3 days later but I had a need to fix that laptop urgently.
I decided to give Omarchy a spin and was impressed; I replaced NixOS on my laptop and primary desktop workstation with Omarchy. Servers are still NixOS. While I built most things myself in NixOS, having that out of box experience with Omarchy and the fact that I can just tell the A.I. to fix and configure stuff was a game changer.
In the last year or so, A.I. has gotten much better with configuring NixOS. Omarchy provides skills.md files to train Omarchy on how to configure and fix things. This improves the overall A.I. experience on Omarchy. Without any A.I. skills the frontier A.I. agents have gotten much better at working with NixOS.
If the NixOS Community writes some skills for A.I. agents, it should vastly improve the quality of using A.I. agents to configure NixOS.
Where NixOS really shines is in solving software development problems. Writing a flake.nix file and dropping it into your repo then any users with Nix installed will execute that flake.nix via direnv when changing directories into the cloned project directory. Thus, installing all the of the project's dependencies including the language. Therefore, Node.js / Python / Ruby can be installed per project instead of per user or globally on the system. Imagine you have an old Python project that won't run with the latest Python. This is no longer a problem because when you change directories into project1 and it installs the versions you need then when you exit the project folder all the dependencies are de-referenced from the /nix/store and the environment destroyed. Change to project2 and it spins up an entirely different set of dependencies. This instantly solves many problems from a newbie developer joining the team and being immediately able to clone and build a project to ensure all the devs have the same flake.nix so they all immediately reproduce the project perfectly ensuring all the proper dependencies are working. You can also put the flake.nix in your CI / CD pipeline to ensure nightly builds are working same as the developers. Spread this across Production, QA / Test, & Development environments. You can create a custom ISO installer including your configuration in the ISO and you can PXE network boot it too. You can have a variety of computer configurations in the same Nix set of configuration files.
Nix the package manager can be installed on any Linux distribution. I am likely going to install Nix on Omarchy so I can use it for development purposes. I find Nix more robust over MISE which Omarchy depends upon for most of their development tooling.
Comment by keybored 1 day ago
Can never tell with these submissions.
Comment by inahga 1 day ago
Comment by max-privatevoid 1 day ago
Comment by keybored 6 hours ago
Comment by cromka 1 day ago
Comment by dlivingston 1 day ago
Comment by aussieguy1234 1 day ago
I'm also less afraid to make promising but risky changes. I have "broken" my machines multiple times, but each time this happens, I just boot back into the previous working iteration, with no real interruption to my work (or fun, depending on what that machine was for).
I can do things like try out new bleeding edge kernels and GPU drivers, important system libraries etc... getting the benefit of these things basically risk free.
There is also one server running NixOS serving up part of what runs Tunnelmole in production.
Initially LLMs were not good at writing Nix, but now they're much better and a good coding agent can do a write/build loop until their config works.
Comment by nautilus12 1 day ago
Comment by arbor-group 1 day ago
Comment by RadiozRadioz 1 day ago
Then you should write down the exact image you downloaded. Images are tagged and hashed, you're guaranteed to download the same thing again if you ask for it.
I always explicitly request a version tag for every container image I configure in my system. If I want to upgrade, it's obvious what I'm going from and to, so I can check the changelog for breaking changes.
Are people seriously running :latest everywhere? No wonder the author thinks it's not stable.
Comment by wrxd 1 day ago
Comment by RadiozRadioz 1 day ago
Typically I am installing images from large, established projects whose release practices I can trust to not re-use an old version tag and slip in a breaking change. It's technically possible, but why would they do that? Unless they've been hijacked, then it becomes about security posture which I see as a separate discussion to this one about breaking changes.
Someone like the author, or maybe yourself, may not trust their software repository and want a hash like Nix's lockfile, which is totally fine. My point is that you can do that just fine with container images, so the author's statement is not the complete picture.