110 points ibobev 3 hours ago 69 comments
mikl 2 hours ago | parent
s08148692 2 hours ago | parent
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.
danslo 2 hours ago | parent
embedding-shape 1 hour ago | parent
ibobev 1 hour ago | parent
ibobev 1 hour ago | parent
DanielHB 1 hour ago | parent
perrygeo 1 hour ago | parent
graemep 1 hour ago | parent
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.
mft_ 1 hour ago | parent
Claude has definitely helped to reduce this negative!
yoyohello13 1 hour ago | parent
graemep 1 hour ago | parent
ibobev 1 hour ago | parent
newsoftheday 1 hour ago | parent
graemep 52 minutes ago | parent
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).
sigbottle 1 hour ago | parent
graemep 50 minutes ago | parent
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.
onefiftymike 1 hour ago | parent
Some of it is real pain points, and those are annoying that they aren't baked into the distro from the beginning.
wolvoleo 1 hour ago | parent
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.
M95D 7 minutes ago | parent
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 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.
Markoff 1 hour ago | parent
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)
exitb 1 hour ago | parent
hibikir 1 hour ago | parent
andrewla 1 hour ago | parent
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.
rafterydj 1 hour ago | parent
iamnothere 58 minutes ago | parent
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”.
Aurornis 50 minutes ago | parent
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.
ViewTrick1002 44 minutes ago | parent
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.
1una 43 minutes ago | parent
TheJCDenton 10 minutes ago | parent
edukite 2 hours ago | parent
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)
clhodapp 10 minutes ago | parent
dalben 2 hours ago | parent
eleventen 2 hours ago | parent
Miniflux homepage really undersells it.
SmashDan 2 hours ago | parent
Chiron1991 1 hour ago | parent
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).
scronkfinkle 2 hours ago | parent
haolez 2 hours ago | parent
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.
georgyo 1 hour ago | parent
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.
eddieroger 1 hour ago | parent
georgyo 39 minutes ago | parent
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.
iamnothere 55 minutes ago | parent
cobertos 1 hour ago | parent
drdexebtjl 1 hour ago | parent
services.restic.backups.my_repo.paths = [ config.services.freshrss.dataDir ];
The point is that you write your backup config once, and then you co-locate the service-specific part of the backup config with the configuration for the service, and a build deterministically generates systemd units and scripts that back things up.neobrain 52 minutes ago | parent
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.
cinaboniver 1 hour ago | parent
https://github.com/NixOS/nixpkgs/blob/nixos-26.05/nixos/modu...
Xophmeister 1 hour ago | parent
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.
awithrow 21 minutes ago | parent
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.
zahrevsky 1 hour ago | parent
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.
ChaseRensberger 1 hour ago | parent
gagik_co 17 minutes ago | parent
ChaseRensberger 1 hour ago | parent
tosser811 1 hour ago | parent
ChaseRensberger 1 hour ago | parent
neobrain 42 minutes ago | parent
That said, cool if pacman and AUR work for you, no need to change just for the sake of it!
Chiron1991 59 minutes ago | parent
atrus 10 minutes ago | parent
boredatoms 1 hour ago | parent
lp92 1 hour ago | parent
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.
actinium226 1 hour ago | parent
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.
ndriscoll 1 hour ago | parent
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.
actinium226 25 minutes ago | parent
poulpy123 1 hour ago | parent
keybored 1 hour ago | parent
Can never tell with these submissions.
clircle 1 hour ago | parent
(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
'("...")))nautilus12 1 hour ago | parent
NelsonMinar 57 minutes ago | parent
ronef 33 minutes ago | parent
Nerdrotic 9 minutes ago | parent
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.