Had a VM GUIX "system" (really I think its more of package manager
overlay) for a while (18 months ago) but encountered some
problems. The main feature AFAICS is that it maintains the state of
the system and packages all very cleanly via it's own nix build system
which is like a snapshot of everything.
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.
I'd like to point out that Guix is closer to ~52,000 packages than the ~29,000, as we maintain a bunch of things in separate channels that nixpkgs includes in its monorepo (e.g. the 20+k CRAN packages). See https://hpc.guix.info/channels and https://hpc.guix.info/channels/non-free for some popular channels used by HPC folks.
Huh. I think that info should be more prominently displayed.
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.
I love that this goes both ways. What other pair of Linux distros mutually offer first class support for using each other's package managers alongside their own??
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.
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.
Guix uses Nix under the hood (learned this when trying to compile it). Perhaps learning Nix first will let the grandparent be more effective in Guix later.
Guix includes a copy of the nix-daemon. It's a relatively small C++ program that manages the store. We reuse it because there was no point in writing a replacement for something as low-level as the daemon. Guix compiles its package definitions down to the same kind of file format that the old Nix daemon understands.
(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]
The Summer of Code project was unsuccessful for personal reasons. The project was also never even close to high priority, because the daemon just isn't all that interesting beyond performing its one job of implementing the functional package management paradigm. That is to say, for a long time there was very little to be gained from a rewrite.
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.
Guix forked and modified only the Nix build daemon which isn't user visible. Learning the Nix tools and language will not teach you very much about how to use Guix.
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.
Yes my previous is mainly with FreeBSD. Your response highlights my
mistake. As a Guix noob (but with decades of apt/yum/rpm/pkg kinda
experience) I misunderstood how these things interact, and failing to
manage Guix was most definitely my fault.
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.
> 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.
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)
> 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.
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!).
This is an issue with any software that tries to maintain backwards compatibility, not Linux. Windows has:
- 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.
Window's backward compatibility is way better though. There are plenty of GNOME extensions and applications that just don't work anymore under modern GNOME Wayland.
Example: all the redshift applications and extensions for lowering the screen brightness.
It's seemed a little odd to me, particularly given Linus' attitude of "never break userspace", that so many high-profile projects decide to break backwards compatibility almost for the sake of it (particularly GTK/GNOME).
I notice that even the blurry scaling on Windows looks better than what we have on Linux. It seems that they have some special algorithm for that. Anyone who knows how it is implemented can chime in here?
The only part that's not going to be available for a while is fractional scaling in GTK and old Qt5 software needs to update to Qt6. Everything else is rather quickly falling in place. GNOME in its stereotypical fashion doesn't seem to want to support fractional scaling and doesn't want to provide QoL features like not making XWayland apps blurry, but that's not a problem with Wayland per se.
Well, I'm glad to be proven wrong. That still looks to be a downsampling method rather than just not applying the scale and using Xft.dpi though, but that can have advantages in multi-dpi setups I guess.
This. naively it seems to be a real straightforward to fix. Just scale to the next integer and then downscale. It won't be as pretty but it will be much better then what we have now. Hell make the scale factor configurable so you can get real smooth graphics.
> Guix install media was not able to configure the network via the Ethernet expansion card nor an external USB-C ethernet adapter that I had; stuck at the DHCP phase. So my initial installation attempt failed.
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.
"Free Software Foundation position on firmware ... is that if a device has ... firmware ... in a form that users can’t modify, then the system as a whole is not free software. This is technically correct but doesn’t logically imply that the right strategy for advancing free software is to forbid firmware blobs"
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.
The thing is that the FSF's stance is already a pragmatic approach of sorts but the line is drawn in a strange place that doesn't really help advance the cause. The hard line approach of "all firmware must be free, too" would render basically every computer unusable, even RMS can see that's going too far to be practical. So, they make an abstraction boundary where "free" stops: If the kernel doesn't load the firmware then it's as if the chip is implemented completely in hardware. It's a practical decision because you have to stop somewhere otherwise you can't get anything done. I wish the FSF/GNU-aligned folks would just make a slightly different compromise that makes it a lot easier for people to start using free software distros. Not shipping CPU microcode updates is particularly harmful to users. 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.
They can't distribute firmware blobs simply because FSF and GNU do not in principle participate in distribution of any non-free programs.
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.
What is more risky to you: Leaving known vulnerabilities such as spectre unpatched or the possibility of Intel adding a backdoor for some unknown purpose that wasn't present in the shipped hardware?
The former is more risky from the security point of view. The latter is more risky from the freedom point of view. (And, while an FSF supporter, I choose to be more secure.)
Vulnerabilities such as spectre are only relevant if you run untrusted non-free software. Also these vulnerabilities show that sandboxing is not effective on current CPUs, and specific mitigations does not solve the problem in general.
Well, it's not like the "line is drawn" in the sense of GNU software not working on such systems. They draw it in what's included in the default repository for guix... so that line does not actually impact many people, and those who are impacted by it can still cross the line pretty easily.
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.
This story happens all the time: Someone learns about free software, gets excited, downloads an ISO for a free distro and is then disappointed to find that their wifi doesn't work. They get told to buy a USB dongle or something so instead they just use something else that works. It's the most common onboarding problem I'm aware of.
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.
> Well, it's not like the "line is drawn" in the sense of GNU software not working on such systems. They draw it in what's included in the default repository for guix... so that line does not actually impact many people, and those who are impacted by it can still cross the line pretty easily.
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 [...]
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.
Equivalently, what you're saying is that the world got more dependent on secret, proprietary software, and that therefore those who wish to have freer systems should just give up.
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."
Since nearly everybody uses devices that require firmware blobs, the policy has a huge negative impact, it should have a corresponding benefit to motivate its existence. But what can possibly make up repelling all but the hardiest users, who most likely will have to work around it by installing firmware blobs anyway? There are plenty of alternatives that just work. Sure, the users that can run without blobs deserve a reward, so show them a congratulatory message on boot or something.
There is precedent for not taking a hard line. Nearly all GNU software works on Windows, for entirely pragmatic reasons.
I've been intrigued by Guix for a while; mainly because I like the idea of Nix but was very turned off by its language, when I was exposed to it through a job I had.
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?
> An old employer used this instead of Docker for managing build distribution. Can the Guix stuff be used the same way?
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.
Wait, this is a big deal. Will it work with any package manager or only things that it explicitly supports?
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.
Since it's all just Guile Scheme, a full programming language, you can extend it in any way you want, and use the Scheme libraries you want, doing whatever network access you please.
The builder is sandboxed, the whole model goes out the window otherwise.
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.
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 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:
I use KDE Plasma 5.27 (6 with many improvements is around the corner) on Wayland and fractional scaling is handled very well, nothing is blurry, no hacks required. If KDE recognizes an app that is not Wayland compatible (like most Electron apps), it will just run it in X11 mode (there's a setting for that, enabled by default).
I'm using Wayland and Gnome set to a fractional scaling factor to write this, and none of the apps I use regularly are blurry although I have to pass command-line arguments to Chrome and had to compile Emacs from source code to achieve that.
>> My kingdom for Wayland fractional scaling that doesn’t make my apps blurry.
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?
Let me type down what I learned through many hours of research.
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.
The toolkits would need to add that, and some of them had engineering direction incompatible with such an idea.
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.
Not design. Engineering direction. People problem, instead of computer problem, to be quite honest. And one of those directions was that there was no other output than blitting RGBA8888 to screen (which was at one point the only format expected to be seen with Wayland, and GTK3 already was driving towards Wayland) - potentially accelerated with OpenGL (which had hilarious results on some chips where GL pipeline was 16bit only while 2D was 24bit).
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
There must be more categories than this because Qt 5 on Wayland can do fractional scaling since some years, you may need to set QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough.
Since some years? I don't think so. wp-fractional-scale-v1 was merged only like 1 year ago. The only more recent version of Qt5 is 5.15 and on the release notes I don't see any Wayland changes.. Any reference you have for that?
Apps that natively support fractional scaling will not be scaled by the compositor. (Well unless they span multiple monitors with different scales IIUC.) Scaling is just a fallback for apps that don't support fractional scaling or edge cases like you drag a non-responding app onto a monitor with a different scale.
Yes, you can have a per-monitor scale factor and apps should render at the right scale based on where they are positioned.
Fractional scaling, by definition, will make stuff blurry. Clean bitmap graphics and fractional scaling are incompatible requirements.
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.
That is not the case on wayland. Wayland applications with support for the fractional scaling protocol can render without any blur at any fractional scale.
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 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.
IMO, it looks like exactly what you'd see if you took pixel perfect rendered text and applied a small-radius Gaussian blur to it. It might look different on your screen, however (monitor settings can affect rendering quite a lot).
Not everything is a bitmap. Ordinary drawing operations operate on coordinates, so fractional scaling should not lead to any blur (although may miss some pixel-perfect designs).
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).
Yes but the fonts, boxes and lines are all fine. And on the web the image issue is usually resolved by starting hi res to begin with and sampling down not up.
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?
Fractional scaling works perfectly well on Xorg Linux and Windows, but looks blurry on Wayland Linux. Maybe it's not micrometer-scale crisp, but I can't see that. Text on Wayland is very visibly blurred.
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.
MacOS way is better, text is blurry, but much less. I still don't like it though, but can use it in an emergency.
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?
It does for any app that can't scale; all modern OSX apps can scale natively. I've been using that trick for integer-like scaling for years to deal with fractional scaling while preserving the quasi-aliasing ("crispness") of the source image.
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.
It is exactly (some) Xorg apps that render blurry on Wayland. You are blaming the wrong party for “bullshit”. Xorg scaling sucks, whereas Wayland’s is great.
I don't know why this guy is being downvoted, he is correct.
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.
> Unfortunately, people still choose to own monitors that have weird resolutions that do not approximate 96dpi after integer scaling.
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.
It's not really as necessary on PCs because of how Windows does scaling. It's only a problem in programs that just straight up don't support it. And Apple has routinely and still does ship laptops with non-integer scaled resolutions as default (e.g., the 12" MacBook, the 13" Macbook Air).
I think KDE6, which is just around the corner, is going to be your best bet. That said, some older programs still require xwayland and you will not get too far with these.
Not for my Framework 13 laptop. There’s only one screen resolution option. Even when I don’t have it plugged into my 4K external monitor, Wayland’s fractional scaling looks atrocious on Ubuntu 22.04.
It is inspired by Nix, but with a few key differences:
- 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.
Oh yes, I completely forgot to mention that monumental achievement :)
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.
The other big thing is that being a FSF project they are much more committed to free software than Nix. It's harder to get stuff like Chrome, Steam, Nvidia drivers etc. Not impossible but you're definitely swimming against the current in trying.
Important to note that it’s not hard or swimming against the current - you just use the nonguix channel, which has all of those things and is a perfectly acceptable use of the system (it’s what channels are for) - but it’s not in the default installation.
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 :)
This is what ultimately bounced me away, along with seeing some negative interactions others had. Sure I might not end up with problems, but I’m going to choose to believe them when they tell me the official communication channels will be hostile to me if I do have problems that need the unclean fixes.
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.
That's an unfortunate take. "Unclean" is your choice of words, not ours. There is no hostility to people who use proprietary software, nor is any kind of judgement of other people's computing purposes and habits warranted.
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.
I wouldn’t say it’s too ideological for someone who wants to get stuff done. To get stuff done with Guix, you just go do it and it won’t get in your way - the project channel and the nonguix channel won’t interfere with each other, they’re just different 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.
It's (deliberately) difficult to discover. I tried GuixSD once, and bounced off it because of the apparent lack of support for my hardware, CUDA, Pytorch et al, which isn't an uncommon story apparently.
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.
I agree with that - directions for how to use Guix in practice, i.e. for someone who isn’t a GNU warrior using 15 year old hardware because you don’t need non-free blobs, need to be easier to come across.
The FSF is not involved in the project. The FSF had no say in what service manager we use.
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?
Apologies, I assumed that being a GNU project (which is supported by the FSF), the project identified as an FSF project.
> 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.
GNU Shepherd (was aka DMD) predates systemd by many years. And many other “PID 1” efforts.
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.
One thing that hasn't changed, though, is that compatibility with the Hurd is still a major goal. Sadly (but understandably) development pushes forward for Shepherd on Linux and then we aim to make it work on the Hurd, instead of letting Hurd-native facilities guide development. But this might change as there is considerable overlap between Guix contributors and Hurd enthusiasts.
- All issue tracking and discussion happens on a mailing list/with custom tooling
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.
Same... Apart from the extreme view on freedom in guix. Loadable firmware? No. Microcode updates for your CPU? No. Not free enough! There's non-guix and all that, but really... if the main project tells you this is now what they want, you will run into issues one day.
No it's not like that all. Free software is a component of it, but Guix is not a fork. It's a completely separate implementation of the functional package management model with many significant differences and advancements. It uses Scheme, a general purpose and extensible programming language, rather than a custom DSL like Nix. Scheme is used for build scripts as well and a lot of code can be shared between the host and build containers. Nix uses Bash. Having one language unifying all the layers makes it easier to hack on the entire stack. Guix has a stronger focus on reproducible and bootstrappable builds and is making notable advancements on the "software supply chain" security problem. OS service configuration is done through a graph extension system whereas Nix uses something more like a flat hash of config values. I could go on but I hope this makes the point that Guix isn't just taking Nix and removing proprietary stuff. It's its own thing.
"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!
My work laptop just rolled over 3 years which means it’s new laptop time. After spending some time convincing the higher ups at work, I have a new Framework 13 coming my way (and not HP whateverbook). I don’t think I’ve been this excited for a bit of hardware in a long time.
Unless the device is malfunctioning or otherwise damaged in a meaningful way, I don't see why it would be time for new a laptop, after only 3 years. I bought mine with the prospect of it lasting at least 6 years (and it's going strong 2/3 in already), but I don't plan on replacing it unless it breaks down or prevents me from working on my stuff for other reasons.
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).
This is a fair call, and normally I would run my laptop into the ground, but my HP Elite Book has this habit of thinking it’s still charging when it’s not. The only way around this is to let it drain to 0% battery and all would be good for another few weeks. Luckily all I need to do is let PyCharm index a project and it’ll drain to 0% within an hour.
I haven't ever had a laptop USB ports last more then 3 years. In fact my last laptop, an XPS 13, had failing USB-C ports within 1.5 years. I admit I probably connect an USB device 5-10 times per day.
It's the best laptop I've ever owned (I have the 12th gen Intel model). It's fast, has a great keyboard/trackpad with full gesture support (Fedora GNOME), and sleep works reliably! Battery life isn't a huge factor for me, but if it is for you it's worth considering other devices. I get 4hrs tops, though I think 13th gen and AMD models do better.
Linux-libre makes some... odd... choices in deblobbing. The most recent one that bit me was the new rtw driver which includes literal GPL licensed blobs as C files full of binary arrays. Users are absolutely free to modify and reveng these but lin-lib got rid of them because their purpose is opaque. It is, obviously, but that is just poorly documented free software and if we're going to start ripping that out there isn't going to be much at all left.
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.
Unfortunately that's how it works on all Linux distros since "this will be the year of Wayland". Last time I tried it was 2020, and I gave up when it turned out there were no alternatives to the off-screen rendering and scaling hack for Chrome, IntelliJ and VSCode.
This is largely a GNOME issue. KDE and Hyprland supports not scaling XWayland and a lot of X11 apps can scale themselves. VSCode and Chromium scales perfectly in Wayland now and IntelliJ can scale in X11.
It simply does not matter, because all DEs are on Wayland now, everything supports it, and honestly, I haven't seen an application not supporting Wayland for quite some time. Even Chrome is Wayland-native now.
I really hope one day the Framework laptop will work with the major Linux Distributions with no asterisks. It will definitely require work on both Framework and the Distro maintainer's part, but it is getting better every month. Hopefully if Framework becomes more successful, they will have more say in the hardware manufacturing process, and they will be able to devote more resources to Linux compatibility. I have no need for a laptop now, but maybe a Framework will be in my future if this happens
We focus on making sure that the most popular distros work smoothly. Currently, Ubuntu LTS and Fedora are the two that we provide official support for, since they are the most popular choices for folks who are either new to Linux or aren’t especially interested in tinkering with their OS: https://frame.work/linux
We have a couple of them and were quite happy with the exception of a few minor issues. However the lack of shipping (not beta) firmware updates on a regular schedule has given me pause to recommend framework to others, at least until that gets rectified.
Whoops, accidentally downvoted when meaning to upvote. Sorry!
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.
I manage to run OpenSuse with Cinnamon desktop on my AMD Framework 13, with a dell dock and 2 odd monitors, the scaling sometimes gets stupid, but that's the only annoying thing I have noticed so far.
OpenSuse has been more of a learning curve than any hardware issue, mostly due to myself being used to Debian and Manjaro/Arch.
> 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?
They needed to compile the kernel because they were using the full kernel. The main package repository (and thus the main binary caches) only include a de-blobbed version of the kernel. To get standard Linux including all the blobs, you need to use the “nonguix” package repository. The nonguix folks do have a binary cache server, but using it during install is slightly annoying. I currently have a guix vm compiling Linux for exactly this reason. Since you likely won’t be installing much else from nonguix during system setup, you only need to compile the kernel and other bloby things you choose to include (e.g. firmware, microcode).
Wow, the Free Software people can be insufferable.
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?
I'm used to being called "insufferable" for working on free software. Still a bit harsh judgment of people who at the end of the day still produce software that you are free to use for any purpose or ignore, no?
> 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.
I haven't ever used Guix, but I am a huge fan of NixOS, and my understanding is the Guix is trying for a similar experience. The reason that I've never attempted to really use Guix is because I'm a bit worried that I'd have driver trouble because of the LibreLinux kernel and no non-free stuff in the core repos.
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?
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.
If you mean the Microsoft project called "GUIX": sure, it's rather 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.
I won't disagree that guix can be made to use nonfree packages. However, the claim:
>> 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.
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.