Guix is gathering feedback from users and contributors on their experiences; what they love and what they've found challenging. Whether you're new or a veteran we'd love to have your opinion and comments!
As the projects never done this before it should be super interesting. So submitted this for anyone that's a current user, or tried it in the past.
For those that don't know Guix is like Nix, but uses a single language (Guile Scheme) to define and configure the system. It's has four elements:
- a package manager that can runs on top of any Linux distribution (e.g. like homebrew)
- a dotfiles and home environment manager
- a complete GNU/Linux distribution
- a way to create isolated development environments
"Modern" seems to be used a loose adjective these days for "I rewrote $thing [in Rust]". Minecraft was created in 2011, and is Wikipedia says the last version of the 'classic' edition was released in 2017. So anything after 2017 is now defunct.
I don't mind people rewriting things in <insert-name-of-tech-I-like> but "modern" as a value seems pretty loose, and it's often at least arguable whether it's objectively better!
“Modern” more usually means some new JavaScript thing. In JS land, they consider anything that hasn’t had a commit on main branch in over 3 days to be a dead old project in need of being replaced with something new and “modern” that is up to date with the latest trends and breaking changes from the previous 24 hours of their world.
Usually the hyperbolic superlative for Rust projects is “blazing fast”. Of course, any kind of benchmarks or comparisons with other implementations are completely optional. It is simply enough to “cargo init” and start hammering out code. You don’t even need to consider the characteristics of the algorithms you choose to use! If it’s Rust, it’s “blazing fast”.
Your most starred repo is inferior to a shell one-liner lol. Talk about pot calling the kettle black. Just use the system dict, shuf, grep, and head.
It’s bad form to badmouth someone’s earnest work for sure. I wouldn’t do it normally since I think it’s nice that you actually did something. But if you’re going to sit in a glass house and throw stones you should expect some back.
Fortunately, my house is an underground burrow so I can throw stones with impunity. As ugly as it is to do.
Sorry, I may should not used the term Modern, Lets say the foundation is newer and more optimized than from the Original Minecraft server. Mojang developers have strict deadlines and do not care about performance (like basicly any big Studio today). This results in bad ugly code which only purpose it is to work nothing more. Minecraft was created 2009 btw
I'd argue they care about performance, but they also care about a whole slew of other things that also require prioritization to maintain the game and its cottage industry. Not a huge fan of the constant dogging on mojang everyone loves to engage in...
> vulnerabilities decay exponentially. They have a half-life. [...] A large-scale study of vulnerability lifetimes² published in 2022 in Usenix Security confirmed this phenomenon. Researchers found that the vast majority of vulnerabilities reside in new or recently modified code
A study limitation is that they looked only at security-relevant bugs (vulnerabilities). As someone who writes code, I would tend to think that this also goes for bugs without a direct security impact, but I don't have the data to back that notion up
For bugs, perhaps, but for vulnerabilities, new attacks and techniques are being found. Or just nobody is looking at most things most of the time and it's not really correlated with age that clearly. Imo it's good to have the data of what actually happens
Guix can create reproducible development environments that are "sealed off" from the rest of the distribution. It's called Guix shell and it's very flexible:
I did two specific posts about using it for 'development' environments. You can also 'fix' the environment (think a git hash) and use the declarative configuration to share it with others:
"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!
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.
To nitpick, you mean similar to NixOS. Nix is the package manager, Nix language is the config language that manages the package manager, and NixOS is the operating system created from those two.
I'm pretty sure all of these are like nix, right? I've used nix on top of other distros, the development environment thing is like nix-shell, nix is happy to build container images, and of course there's nixos.
Yes, I wasn't throwing shade on Nix, I was drawing a specific comparison about Linux distributions.
My opinion is that Guix/Nix move the state of the art for Linux distributions forward. So Guix<->Nix are both similar Linux distributions, and different from previous approaches (e.g. Debian, Ubuntu, Redhat etc).
Transactional package management and declarative system configuration solve a whole host of problems. Guix (and Nix?) directly integrates configuration management into the OS, rather than as some adjunct piece of tooling (Ansible, Terraform etc). We define the packages, the system, the configuration using the same DSL. Transactions and a declarative approach improve maintainability, reproduciblity and might limit the amount of time I spend messing with different tooling ;-)
Sure? I'm pointing out that the listed features are more or less identical AFAICT. I grant that being a GNU project affects some of its goals and how it goes about things.
Guix is more similar to Debian, with only 'Free Software' applications in the main archive.
For proprietary codecs, firmware and so forth there is the Nonguix channel. Again, this is fairly similar to how distributions like Ubuntu have handled this line in the past.
I need Chrome and also have some games loaded using 'channels' - heh heh - another post:
No. While the core repository (we call that a "channel") only includes free software, there are no restrictions whatsoever on what you can or cannot install with Guix.
Guix makes it trivial to add third-party channels (such as nonguix, guix-science-nonfree, or other free software channels like guix-cran or guix-science) or extend Guix in an ad-hoc fashion.
You can also build an entirely private collection of packages if you want; from a file, from a git repository, from a Guile expression, etc.
> * a package manager on top of an existing Linux distribution (think apt or rpm)
Just to add to this: don't just think apt or rpm, also think conda/mamba, homebrew or pipx. Nix, and I am sure guix as well, unify this "traditional" distinction between system and user package managers.
We're a small group 5-10 people, so it's very informal and friendly. I'm sure Fabio (https://fabionatali.com/) who organised it would have good advice! I'll say that from my perspective the fact that it's also virtual is really great as otherwise I couldn't attend!
One thing to bear in mind is that at Weaveworks we made massive contributions and did our best to be part of the community in the right way:
* Flux
* Flagger
* Cortex
* Ignite
* Weave Net
* and a whole host more
Oh and there's a load of people without jobs tonight - wondering about their futures - hopefully people will see the talent and the contributions and find roles for them.
And that's a huge bummer since I know people who rely on those products and they're getting value out of them. However, I don't think the company failed because it didn't use more aggressive advertising.
Thank-you - really appreciate this comment - acknowledging the work that great people did and the efforts they put in. I wish the outcome was different - but we really tried to do good things, and play well in the open source community.
Experience building and operating large systems using public cloud services and design patterns without falling into the traps such as ludicrously overpriced SKUs, API limits, low quota, data transfer fees, and all the boring stuff in the fine print that will rack up a 7 digit bill.
I'm very interested to get connected to the DevRel and marketing folks. I'm one of the founders of Heroic Labs - we build OSS game server (Nakama). My email is mo at heroiclabs dot com - please ping me!
And you should too since k8s, while an 800lb gorilla on the side of the implementer, gives your dev teams the cloud experience without having to build the APIs yourself. Which is pretty nice honestly, making infra self-service isn't on offer most places hosting on-prem.
> I am so freaking sick of companies lying and exploiting open source. This is Embrace, Extend, Extinguish at it's finest.
I don't see how this is 'Embrace, Extend, Extinguish'? This license guarantees that the code becomes Free Software at a maximum of 4 years - and in this case they've specified a shorter time period.
I'll give you that there are lots of games played in open source, so I understand that feeling of cynicism. But, this actually seems like an attempt to add some nuance to the commercial<-->free divide.
The reality is that many 'commercial' OSS companies have to take the open core route because understandably investors expect a return on their money. There are exceptions to this, but they are pretty rare. In fact, there are probably a whole set of SaaS companies that could be open source, but don't do so out of the fear of someone taking their code and 'free riding' them.
Finding a way to prefer the entity that sponsors/incubates the code base, while also genuinely allowing a community of contribution around it (not free riding) would be very beneficial in lots of situations. Maybe a better critique would be that this has some similarities to the Trolltech QT approach - but that's a different argument.
I think you know this as you mention "olden way" - it's definitely the thread of history where most UNIX servers were multi-user systems: that's how I was first exposed to Unix, even though by late 80's/early 90's most of them were Linux or a *BSD. In those - presumably University mostly - environments, we mostly sent email to each other and that was often between servers on a campus or environment. It made sense then that each server sent email because you were specifically user@host.someplace.
When the distros started to expand, being a smarthost was the most common configuration. Today, I agree with you the only reason for any sort of SMTP daemon is for programs to send email - all the users are on Google/Slack.
I've been using Guix on top of Ubuntu so that I can have the latest versions of some applications I care about, while keeping the core Ubuntu which works well with my hardare.
Similar to your comment the ability to see exactly what is installed, with repeatability is fantastic. For my personal use-case the ability to install an application in parallel to Ubuntu's is really useful.
As the projects never done this before it should be super interesting. So submitted this for anyone that's a current user, or tried it in the past.
For those that don't know Guix is like Nix, but uses a single language (Guile Scheme) to define and configure the system. It's has four elements:
- a package manager that can runs on top of any Linux distribution (e.g. like homebrew)
- a dotfiles and home environment manager
- a complete GNU/Linux distribution
- a way to create isolated development environments