Guix on the Framework 13 AMD
wingolog.org
wingolog.org
The sell is that it's very recoverable - in theory you can rebuild from a single file. That's very appealing for VMs that need to be moved about.
Unfortunately I needed a couple of things that were available only through apt. Now, Guix said it was perfectly happy to mix package management, (a bit like mixing pkg and ports in BSD) - but don't do that. It all went horribly wrong with confusion over which binaries were running at any time and when I did try to port it, it broke.
I like lispy things so will give Guix another try one day, but it needs you to fully embrace its philosophy and no half measures.
Nix is conceptually extremely similar to Guix, but a different implementation! It uses its own programming language, also called Nix, and has a less strict stance on free software.
(It's a bit funny to me that GNU has a reputation for NIH-ing projects, but when a GNU project doesn't reinvent the spokes on a wheel it also attracts various forms of criticism.)
> The daemon also is a key part of the history of Guix. The Guix project started mixing Guile with ideas from the Nix project, and the guix-daemon is a fork of the nix-daemon with some tweaks made over the years. Rather than being implemented in Guile though, the daemon is implemented in C++ with some helpers written in Guile.[1]
[1] https://guix.gnu.org/en/blog/2023/a-build-daemon-in-guile/
---
Found https://github.com/alezost/guile-daemon (https://packages.guix.gnu.org/packages/guile-daemon/), too, which is just as old. Is it "finished"?
I suppose nothing has happened out of https://summerofcode.withgoogle.com/archive/2017/projects/59...?
Is https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/... even relevant today?
The most recent project has only just started and is spearheaded by Chris Baines, who has extensive experience with the build side due to his work on a (Guile-based) build coordinator used by one of the two major independent build farms.
I don't think the older branches contain much that needs to be ported; most of the work from past projects has in fact made it into Guix already and is used for other features --- just not in the daemon. If the Guile daemon project is successful, the daemon will incorporate many of these existing features for build isolation and coordination.
NixOS has approximately the same advantages, but a many times larger package repository. Take a look at that, it might already have your packages.
Just a few minutes ago, I decided to put off trying guix until later because it had fewer packages than nix, and was missing several that I need, that nix has.
[0] https://guix.gnu.org/manual/en/html_node/Miscellaneous-Servi...
It's a cute little testament to the fundamental strengths of the functional package management paradigm, as well as helping users on either side of the fence fill some gaps in a pinch and providing more/easier opportunities to compare notes and inspire improvements.
There is no mixing ports and pkgs in FreeBSD (I assume you mean that one). When you build a port, it builds a package and installs that. You run into big rebuilds/reinstalls when versions mismatch between your ports tree and pkgs repo.
Guix/nix can't be mixed with existing package managers, but can exist on the same machine. You're (most likely) going to have duplicates and different versions of the same thing.
Don't get me wrong, I love Guix and the philosophy, but my heart cries out for some Grand Unified Manager of Packages (GUMP), something that can track whether things need building from source, or can be brought in as binary from an apt or rpm, or build those packages as intermediate stages. I kinda thought that's what Guix was going to do. Now I see that a unified package manager is probably unreasonable and that we are headed more toward containerised "Snap/flatpck" way of things - which I don't like.
I mean, that sortof what nix (and I assume guix) is though, right? As long as your ok with the binary cache for a replacement for apt/rpm (with the caveat that sometimes pkgs can be built on .deb or .rpm)
Transient situations are almost permanent in Linux land. This has been a problem for a long time and I don't see a solution coming in the near future. But maybe I'm wrong (I hope so!).
- Many years worth of different control panels.
- Little consistency with respect to toolkits in general.
- Fractional scaling issues in applications using older toolkits (e.g., open up the policy editor and notice the blurry fonts). Microsoft is actually giving up here and has been experimenting with ML-based scaling for old applications (an approach I expect we'll eventually see in Linux as well).
Apple handles this by breaking compatibility every so often, forcing old software out of the picture.
Example: all the redshift applications and extensions for lowering the screen brightness.
It's probably because of the hybrid structure of modern devices. Bare minimum hardware is implemented in solid state, to be able to detected by the OS, for the higher level of functionality (read: packet crafting and I/O), you need the firmware.
This "hybridness" varies between device tiers though. Higher end Ethernet adapters generally work well without the firmware, but offloading and acceleration features are not enabled without the firmware. Better Realtek and Intel (IIRC) devices fall into that class, and some server class Broadcoms too.
It may not be the convenient thing for novice users, but it is an important strategy to "dogfood" fully-free systems, i.e. obtain them, run them, and make efforts to get them to work as seamlessly as possible. This was done with OS-level-and-up software - for the most part - and we have been reaping great rewards all around from those efforts. If it can be done for the full stack of hardware and software, this will be very beneficial and in some aspects even liberating.
Again, joe user is probably better off with a more pragmatic approach at the moment. But joe user can still choose a FOSS operating system, which a few decades ago was not realistic.
There is precedent for not taking a hard line. Nearly all GNU software works on Windows, for entirely pragmatic reasons.
About the CPU microcode updates... why do you believe they are important? I mean, if your system runs arbitrary code off the Internet, or has thousands of people log in and work on it, then sure, but otherwise, I don't know.
Are you saying that the security updates in CPU microcode aren't important because you can't think of an attack vector? Feels like a weak reason to justify not shipping updates.
And if what's in the install image results in the OS not bringing up important hardware like network cards, then the software is effectively not working on such systems. And yes, of course it's possible to enable it, but you have to find out yourself because telling people about nonguix in any official docs or communication channels is disallowed.
> About the CPU microcode updates... why do you believe they are important? I mean, if your system runs arbitrary code off the Internet [...]
We call that a web browser.
That's pretty bad. I'm definitely against that.
> We call that a web browser.
Are there known exploits based on web browser use, which are foiled by CPU microcode changes? Or, are these speculated to be possible?
The exploit certainly was possible: https://security.googleblog.com/2021/03/a-spectre-proof-of-c...
To what degree it's mitigated by CPU microcode patches or browser changes, I couldn't say off the top of my head. I suspect the situation has improved on both fronts.
the world got more dependent on secret, proprietary software, and therefore the pragmatic way is to concede a little territory to them, so that people can use Free Software at all.
Except it's a lose-lose situation: there will never be an end to those concessions, as long as secret software expands under the guise of firmware. And a hardline stance will alienate new generations and starve the movement. The endgame is no Free Software in either scenario.
"the world got more dependent on secret, proprietary software, and that therefore those who wish to have freer systems should just give up."
a "bad faith interpretation" of
"10 years ago it was not too hard to run a distro without firmware blobs on a laptop if you were cool with just getting a thinkpad, but modern intel hardware requires a blob for graphics so even that path is closed now. My 2022 thinkpad x1 needs blobs for graphics, wifi, bluetooth, and sound and I tried to find something modern that didn't need them and gave up eventually."
Also consider that if a manufacturer can distribute opaque firmware updates to your system, it practically has remote control over it, е.g. Intel can activate a backdoor in specific CPUs when needed by publishing a microcode update.
One thing I liked about Nix was that it was possible to use its packaging and tools without actually using the NixOS. An old employer used this instead of Docker for managing build distribution. Can the Guix stuff be used the same way?
One thing I liked about nix in this capacity was the "nix-shell" facility, which could be used to create a whole hermetic dev environment with all the right versions of things and all the right environment variables set up, etc. Similar to similar uses of docker but more integrated with the rest of the system -- not as "sealed off" from the rest of the distribution, e.g. I could still use my emacs config inside it, etc.
* Guix Shell https://www.futurile.net/2023/04/29/guix-shell-virtual-envir...
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:
* https://www.futurile.net/2023/04/30/guix-reproducible-dev-en...
* https://www.futurile.net/2023/10/17/guix-time-travel-dev-env...
Hope they help - if you have a play and get stuck the mailing list is really good and I posted about the Meetup further up.
Yes, and, Guix is actually a "meta" package manager that understands other packages like Python PIPs and Node NPM packages, so you can define all of that in one build config file.
One thing that has become a persistent headache for me with Nix is trying to get reproducible builds with Julia, due to the fact that the package manager doesn't have direct integration with Nix, and `nix build` purposefully restricts network access. I'd happily move to Guix if they have an elegant way to deal with this.
Also, I really doubt Guix moves the needle much here. It can't make Julia magically more reproducible without effectively doing the same techniques you'd have to use in Nix.
Proof: consider a pattern of alternating black and white pixels: 0, 255, 0, 255, 0, 255, etc. This pattern cannot be scaled to a non-integer factor without introducing gray colors (i.e., by blurring-out the pattern). If your app produces this pattern, then fractional scaling will blur your app.
And it's not just text, but UI controls too. It looks like Wayland just renders the lower integer scale factor and then stretches the resulting bitmap image. That's bullshit.
If you can't render fractional factors natively for tech debt reasons then that's the least bad way to do it.
But there apparently is another way that Xorg and Windows uses. I have perfectly crisp (as far as my eyes can tell) UI and text on both systems at 150% scale (27" 4K display).
> for tech debt reasons
I thought Wayland was supposed to fix the tech debt - so now it introduced some that makes bare basic features impossible?
However, Wayland does not prescribe any method for non-integer scaling. Any Wayland WM could choose to do the same thing, and it would be hardware accelerated essentially for free.
Both X11 and Wayland WMs typically don't use this trick, and neither does Windows.
In other words vectors may be scaled with little precision loss, or they may be scaled naively (render to bitmap and then scale the bitmap).
When people complain about desktop apps not scaling they aren't complaining about the odd icon, it's the whole app looking like a smeary mess because it's not using vector based graphics. Fronts, grid lines etc. become blurry.
Also, don't you get the same effect (readable large fonts but alignment changes a bit) when you increase the size of your UI fonts, even without changing overall UI scaling?
Why are people (apparently) so attached to pixel alignments for OS-native GUIs?
This is because the protocol negotiates the size of the underlying buffer. If the client and the compositor agree on the scale, then no scaling of the buffer will happen in the compositor because the client has attached a buffer that is the exact pixel size size of the window on the physical display.
It is up to the client how it implements the case you described. E.g. it could alternate between 1 black and 1 white pixel in the physical buffer or it could sometimes make two adjacent pixels the same color.
Source: I was involved in the design of this protocol and we had example clients that used this exact pattern. Chromium also supports this protocol without any blur.
This is a very odd definition of "no blur".
Having people with no understanding of, or worse no interest in, beautiful UIs making decisions for the display server is a worry.
This is also the definition of blurriness.
I think the screenshot looks fine (other than the weird kerning), but I can see how one person's antialiasing could be other people's blurriness
This is not true in any sense, but it is what some people think when they don't know much about the underlying principles and just see fractional pixels.
A blur would be lowering the frequency of an input signal, anti-aliasing is representing that signal more accurately when quantizing it into discreet values.
Do some animated aliased 3D renders then try to blur it to get the same result as an anti-aliased version.
Look at a checkerboard pattern as it goes into the distance. The pattern eventually converges into grey if it is antialiased because the integral of everything under the pixel is grey as the squares end up smaller than a pixel. Blurring the entire frame gives a much different result.
You cannot scale things to non-integer amounts without incurring some damage.
Blurry/fuzzyness, ringing, screen door effect, etc, you cannot avoid these no matter how smart your scaling algorithm is as long as you're upscaling it to something inbetween 100% and 200%. Nyquist-Shannon is a bitch.
Wayland made a decision way back that non-scaling apps can only be integer scaled to avoid this defect. This was the correct decision, objectively. Unfortunately, people still choose to own monitors that have weird resolutions that do not approximate 96dpi after integer scaling.
Thankfully, 200% dpi screens (ex: 3840x2160 in 24", where 24" are normally 1080p) are starting to become the norm, so someday this problem will go away: you will always be scaling at least 200%, making non-integer scaling artifacts a lot less visible.
Also, I think the parent comment that enriquto replied to might be confused and is merely asking for nearest neighbor scaling. This is not part of Wayland (which is just a protocol), and is managed entirely by the WM being used. Given Wayland is trying to enforce integer scaling, WMs allowing choosing nearest neighbor when integer scaling would be preferable in many cases.
It’s not always a choice unfortunately. I buy displays that are capable of a clean 1x or 2x when I can, but there’s a ton of laptops that still need fractional scaling.
Take my Thinkpad X1 Nano. Great laptop in a lot of ways, including the screen (~500 nits brightness, excellent backlight consistency, color, and contrast, no glare) except that it runs at a resolution that requires 1.5x scaling to be usable.
Looking at replacement candidate laptops, the only ones that have 2x screens that aren’t a downgrade somehow destroy battery life (e.g. 3000x2000 OLED panel in Dragonfly Elite G4, which docks 3-4h of battery). 1x screens in this category for some reason are all kinda crappy with e.g. dim 350 nit backlights that start to struggle in a moderately naturally well-lit room, which is just goofy in a portable machine that’s likely to get usage in a bright environment.
This is one thing that MacBooks objectively do consistently better.
See the screenshot of my settings: https://imgur.com/a/VQHD5vT
In fact, none of them were blurry 3 years ago.
I'm convinced I don't understand this thing. I feel like it's NOT the compositors job to scale the pixels of an application. That might be a good hack for super high resolution screens with applications that don't know how to handle high DPI but it's an inferior solution. Scaling text at the pixel level is going to be inferior to rendering it at higher resolution to start with.
So how does it work? Do we have per-monitor setting for scale factor, and both the DE and the apps need to follow it for idea behavior? And the compositor scaling the apps is a stopgap? Is that it, or is there more to this?
Under a Wayland compositor, there are basically three types of apps.
1. XWayland apps which cannot use Wayland's scaling protocols, but may be able to use Xft.dpi to scale themselves. Examples include Electron apps when not running on Wayland and later versions of Qt5. These will work without blurriness but they cannot support proper multi-dpi support. The Wayland compositor has no way of detecting whether it actually scales. Some compositors (KDE, Hyprland) let you not scale them, but others (GNOME) will make them super blurry because they are rendered at 96 DPI and stretched to the needed scale. GTK3 notably never supported fractional scaling on X11.
2. Wayland apps which supports integer scaling only. Examples include GTK3, GTK4, Qt5 apps, Mozilla Firefox (minus the experimental fractional scaling feature, which is very buggy). When compositor wants to render at a fractional resolution, the app will render at the nearest integer scale, and the compositor will downsample it. These don't look ideal, but aren't super blurry either, and will work properly with multi-dpi monitors.
3. Wayland apps which properly support fractional scaling via wp-fractional-scale-v1. This is a recent addition to the protocol, so not widely supported yet. The only toolkit that supports it is Qt6, but Chromium (incl. recent Electron apps in Wayland mode) also supports it. Some terminal emulators do too. This results in pixel perfect rendering and looks ideal and works properly with multi-dpi monitors.
Downsampling works well on Macs which have high resolution screens such that you mostly use at least 175% scaling. At lower scales such as 125% (e.g. 1080p 13-14 inch laptops) and 150% (e.g. 1440p 14-16 inch devices), the degradation is fairly obvious if you use smaller fonts. This also breaks subpixel rendering (Macs haven't had it for a long time), which is important for making fonts look good on lower DPI screens. In some ways, Wayland scaling is a regression for KDE because Qt5 had proper fractional scaling for some time under X11, which was not implemented in Wayland as the protocol came out after Qt5 lost support.
Can't X apps just set a window property (XChangeProperty) with their scale factor and have compositor read that?
Especially GTK 3, which was incompatible (by default) with anything that didn't resemble the imagined wayland future, including non RGBA8888 displays or systems with different GL and X11 visuals.
Every X11 app is already composited and scaled by compositor and has top-level X window where it could set any property it wishes.
Also, unless you're running Xsgi, it's not a given that every app is scaled by compositor.
Honestly, the right way was always to not assume any given DPI, and instead have every top-level window be DPI-aware and have the toolkit update that information dynamically.[1] Or optionally go all-in on vector dpi-independent approach.
[1] The only correct way to handle hi-dpi on Win32 GDI, where scaling is broken partly by old GDI assumption that DPI didn't change, and by applications that hardcoded 96 dpi
Yes, you can have a per-monitor scale factor and apps should render at the right scale based on where they are positioned.
Blurriness is almost always due to use of xwayland.
These are completely unrelated technically.
- it is developed under the flag of the GNU Project, so you can expect the same standards of quality of both code and documentation as the rest of the GNU Project
- it uses GNU Guile as the main language of the system instead of Nix, which (allegedly) allows you to extend or modify the behavior of the whole system
- it uses GNU Shepherd as the service manager instead of systemd
All the main goals of the projects are pretty much the same.
Opened up https://gitlab.com/nonguix/nonguix. Literally the second sentence in the project information section, top of the page:
"Please do NOT promote or refer to this repository on any official Guix communication channels."
Weird thing to say something like this there. Too ideological for someone who wants to get stuff done.
They don't want to compromize their mission - which is to provide a fully-free operating system. But they recognize that, at the current moment, non-free software is required for many users. So they maintain an unofficial repository for non-free software, and avoid endorsing or promoting it on the official channels.
> Too ideological for someone who wants to get stuff done.
The maintainers of Nonguix are mostly the same people working on Guix, so you can expect the same amount of ideology :)
Which is a shame, because I think there are some technical things which guix does better, but I find it’s more important to not have to worry about saying the wrong things in the wrong places when troubleshooting basic issues like what I get with the nix community.
Personally, I avoid proprietary software where I can, but I've found myself in many situations where I'm made to use it. But that's really the point: the free software movement's goal is to create a world in which people are no longer compelled or coerced or forced into being mistreated by proprietary software. You don't need to subscribe to these values, of course, but it is unfortunate if you experience this goal as a personal judgment. Keep in mind that one of the four software freedoms is the freedom to use software for any purpose you want --- judgement of users would be a completely misdirected emotion.
Having said that, the Guix project's communication channels simply aren't for proprietary software. The Nonguix communication channels are. The HPC channels are. You will likely get redirected to those communication channels if you ask about proprietary software on Guix project channels.
Directions for using Guix in practice (i.e. with some non-free software) could definitely be easier to find, especially if you start green and don’t know what you’re meant to be looking for. But the system won’t get in your way.
Now, seemingly there are channels that would deal with this. But when I asked through the official channels, I was told not to do that -- that is, "don't use nvidia dummy", which really isn't an option. I was never pointed to the non-free channel.
Is it like Devuan to Debian?
Is it like GNU Herd to Linux? (Surely not since it’s Linux ;))
You actually can use the Hurd as a kernel with Guix System. Or run a Hurd VM on your Linux-based Guix System with the childhurd.
For any readers unfamiliar with the importance of reproducible full-source boostrapping, please consider reading the paper "Reflections on Trusting Trust" by Ken Thompson [0], the creator of Unix.
[0] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
I wish they didn't do this part. Despite the furor that was around systemd, it's actually quite nice to use day-to-day.
But also, I realize that the FSF has to do what the FSF has to do, glad they're around.
A common misconception is that we somehow don't like systemd. It just so happens that having a thing that's written in Guile (like the rest of Guix) allows for some code sharing. Hey, we've got the initrd in Guile, too. Might as well go all the way, eh?
> A common misconception is that we somehow don't like systemd. It just so happens that having a thing that's written in Guile (like the rest of Guix) allows for some code sharing. Hey, we've got the initrd in Guile, too. Might as well go all the way, eh?
I didn't have this misconception, but let me correct my statement:
But also, I realize that guix devs have to do what guix devs have to do, glad they're around.
It also had different goals when Wolfgang and I designed it, one might say even incompatible since we were targeting the GNU/Hurd specifically and wanted easy ways to manage translators there on a per user basis.
Also IIRC Shepherd was a simple 1-level service manager like runit. Is that correct? I played around with it for a while and came to the conclusion that it couldn't represent a service graph.
* a package manager on top of an existing Linux distribution (think apt or rpm)
* a development environment (think Python venv but for any language)
* a VM system (like Docker but declarative)
* a Linux distribution (similar to Nix)
It's a small and friendly community - we recently started an English-speaking online user-group:
https://www.meetup.com/guix-london/
I also did an Intro post to some of the advantages and challenges a couple of years ago:
https://www.futurile.net/2021/09/26/guix-alternative-to-snap...
I sometimes think about setting something up in my new city.
Do you have any advice for getting a meetup off the ground? I guess meetup is still the best thing to use (it was what my old C++ user group used).
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).
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!
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 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?
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.
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.
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.
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:
https://www.futurile.net/2022/12/04/proprietary-apps-on-guix...
A lot of Guix users use Flatpaks.
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.
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 ;-)
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.
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.
Anyway, good choice on the new laptop. My next device will likely be a FrameWork or similar (who knows how the landscape will be then).
As it is if you want wifi you have to find an older Atheros (pre ath10k) or older realtek (pre 88XX) device, and these are decidedly thin on the ground; I just spent two days crawling through stacks of laptops at Sim Lim in Singapore before I found one.
HOWEVER, and I hope this is a transient situation, there is a problem: in GNOME, applications that aren’t native Wayland apps don’t scale nicely. It’s like the app gets rendered to a texture at the original resolution, which then gets scaled up in a blurry way.
Sorry but my eyesight is already bad as it is.
Meanwhile, it's apparently going to change soon, but Steam games generally use Xwayland.
I’m always surprised at the lack of choice hardware with pre installed Linux.
But the framework seems to have a lot of users running Linux so it’s probably a great choice.
Thank you for focusing on the mainstream distributions. If our company ever transitioned to Linux on laptops (it would be a stretch because of Office365… probably the best we could do is macOS), we would be targeting Fedora.
This is because only the mainstream distros have MDM features.
And earlier:
> open /etc/config.scm, add the needed lines as described in the operating-system part of the nonguix README, reconfigure, and reboot. Building Linux takes a little less than an hour on this machine.
This is for a system bootstrap of guix/Linux - not just the kernel and modules, surely?
From the README on the attached Nonguix escape hatch:
> Please do NOT promote this repository on any official Guix communication channels, such as their mailing lists or IRC channel, even in response to support requests! This is to show respect for the Guix project’s strict policy against recommending nonfree software, and to avoid any unnecessary hostility.
> This channel does not endorse any non-free application. We believe it is non-ethical, harmful to software development and restricts the users freedom. See the GNU philosophy for a more thorough discussion.
So it's Nix, but on extra-hard mode because of some impractical restrictions outlined by the author?
> So it's Nix, but on extra-hard mode because of some impractical restrictions outlined by the author?
It's not Nix, and no, there are no impractical restrictions, nor is it hard to extend Guix with a wealth of third-party channels.
See other comments here that attempt to address this and other misconceptions surrounding Guix.
If you're talking not stable as in it's rolling release, then yes that's true although it isn't unique to Guix.
But if you mean leaves your system vulnerable to breakages, large unwanted changes, system entropy, or inconsistencies, then surely Guix (and Nix) are more stable than virtually every other distro (and maybe even MacOS or Windows)?
I'm also not sure I would say Guix is particularly unpolished compared to other distros. The project is 10 years old at this point, has a very active (albeit not huge) community, and has some of the clearest/most extensive documentation I've read for a distro. Perhaps 5-ish years ago it had some rough edges, but I'd say now they're quite comparable to other mainstream distros.
As someone who has been using Guix as my primary OS for the past ~2 years on a <5 year old laptop (with a proprietary wifi card) for programming, media, web stuff, and light games, I'd say it's a great experience. Not that the learning curve is not large or that community resources couldn't be better, but if you're already using GNU/Linux I don't think it will feel any less stable/polished.
To anyone that has used both Guix and NixOS, how do they compare? Do you feel like Guix is a better experience if you get past the driver problems?
Check out the system-crafters distribution, IIRC it includes nonguix by default.
Big fan of mixing & matching not just on hardware I see
Kosher is to treif as halal is to haram.
Unfortunately it’s also Stallman’s — and thus sadly by extension the FSF’s — entire shtick.
GUIX is much much more restricted.
Guix, however, goes out of its way to support extensions at different levels of its architecture. Not only can you extend it with channels, local files, and with Guile expressions, you can also rewrite the dependency graph of your environment with package transformations, e.g. to swap out any instance of Tensorflow with a CUDA-tainted variant of Tensorflow from the Guix Science Nonfree channel, recursively.
>> Although if you look at FSFs major projects Emacs and gcc they do run on many OSs including non-free (e.g. Solaris, macOS, Windows, VMS and virtually anything that exists) and other free Unixes.
>> GUIX is much much more restricted.
appears to hold up; https://guix.gnu.org/en/download/ says "Alternately, GNU Guix can be installed as an additional package manager on top of an installed Linux-based system." (emphasis mine) and although there's no explicit statement, https://guix.gnu.org/manual/en/html_node/Installation.html implicitly reiterates that guix is only targeting Linux. Forget running on Solaris, Darwin, or NT; as far as I can tell guix doesn't even care about being usable on any open source unix other than Linux.
Edit: Although now that I think about it, they also target HURD... which is no less niche, but does at least imply that it could work on non-Linux unixen.
There's a life lesson in asserting that, but the vast majority of people take the wrong one from it.