Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"Guix is a rolling release distribution, the versions of each application are updated continuously. The benefit of rolling releases is that enhancements are available immediately"

The last time I looked at Guix a lot of packages were not up to date, and this included security updates for internet facing things (IIRC, one of the major web servers).



New packages and updates to packages come into the archive continuously. For example, in roughly the last 24 hours 40 packages were added or updated - https://git.savannah.gnu.org/cgit/guix.git/log/ . Advantage of this is that you can use new packages immediately and there's no big 'upgrade'. Challenges are that if you were an enterprise and wanted to stick on an 'old' version this wouldn't the right distribution.

Guix does receive security updates, and those are added to the archive immediately. I haven't had any problems myself. It's definitely a 'community' project, so you have to enjoy doing a bit of hacking!


> For example, in roughly the last 24 hours 40 packages were added or updated

That's really doesn't feel like a lot. 40 is oughly equal to the amount I get daily for just the stuff that's installed on my arch system.


I do like rolling release distros. I currently use Manjaro and the ARM version of Arch. However, what I really want something like this for is clients servers - not exactly "enterprise" as these are SMEs (not tiny, but not enterprise either).

I did find CVE-2024-0985 was not fixed in Guix, but overall so far other things seem to be up to date than when I last looked at it.

What is your usage? I suppose the other thing it might really good for is a developer desktop?


I use it for additional packages on top of another Linux distribution (Ubuntu). This gets me rolling release packages and guix shell which is great for development as each project I'm working on can be completely separated.

For 'servers' the nice part is being able to prepare a declarative operating system configuration and play with it locally (VM), then it can be deployed to the remote node and you know it's going to be the same. If something goes wrong it's easily to declaratively roll-back. Here's a nice starter post (https://stumbles.id.au/getting-started-with-guix-deploy.html). The deploy capability definitely needs more hoops to jump through and it's not without rough edges - but I think it's really cool. There's active ARM and RISC-V work - I don't know how rough that would be compared to the well-known ARM ports - ask on #guix if you're interested.


Thanks that getting started post looks really useful.

i have recently started running development stuff in VMs (shared folder so I can use my usual editors etc) and this might be a nice alternative - but the biggest draw is that it is declarative and looks easier to get to grips with than Nix.

ARM support is not important to me at the moment - those are just personal things (a tablet, a Raspberry PI) that have limited use anyway.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: