[HN Gopher] Guix on the Framework 13 AMD
___________________________________________________________________
Guix on the Framework 13 AMD
Author : ingve
Score : 212 points
Date : 2024-02-16 11:05 UTC (11 hours ago)
(HTM) web link (wingolog.org)
(TXT) w3m dump (wingolog.org)
| teekert wrote:
| Is this Guix Nix but with a different language? How is it
| different? So far I only knew Nix, now I see more and more Guix
| popping up...
| bheadmaster wrote:
| 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.
| goosedragons wrote:
| 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.
| pasc1878 wrote:
| Another big thing is Guix only works on GNU/Linux and not
| on macOS and other Unixes like FreeBSD which Nix does run
| on.
| kdtsh wrote:
| 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.
| davexunit wrote:
| Yeah I second this. I use the nonguix channel for my
| laptop. Very well supported and easy to use.
| ducktective wrote:
| >you just use the nonguix channel
|
| 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.
| davexunit wrote:
| I agree this policy should change but I and many others
| get stuff done just fine.
| bheadmaster wrote:
| It makes sense to me.
|
| 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 :)
| Modified3019 wrote:
| 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.
| rekado wrote:
| 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.
| Filligree wrote:
| 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.
| teekert wrote:
| So is it like "Nix isn't free (as in RMS) enough?"
|
| Is it like Devuan to Debian?
|
| Is it like GNU Herd to Linux? (Surely not since it's Linux
| ;))
| davexunit wrote:
| 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.
| rekado wrote:
| > 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.
| operator-name wrote:
| There's also been a greater focus on reproducibility:
| https://guix.gnu.org/en/blog/2023/the-full-source-
| bootstrap-...
| bheadmaster wrote:
| 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.
|
| [0] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_198
| 4_Ref...
| viraptor wrote:
| 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.
| hardwaresofton wrote:
| > - it uses GNU Shepherd as the service manager instead of
| systemd
|
| 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.
| rekado wrote:
| 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?
| hardwaresofton wrote:
| 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.
| amszmidt wrote:
| 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.
| rekado wrote:
| 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.
| rendaw wrote:
| - 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.
| jckahn wrote:
| My kingdom for Wayland fractional scaling that doesn't make my
| apps blurry. It makes the feature a complete nonstarter for me.
| enriquto wrote:
| 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.
| throwaway11205 wrote:
| 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.
| jsheard wrote:
| Doesn't macOS do it the other way, rendering at the next
| highest integer scale factor and then downscaling to fit
| the display?
|
| If you can't render fractional factors natively for tech
| debt reasons then that's the least bad way to do it.
| throwaway11205 wrote:
| 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?
| DiabloD3 wrote:
| 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.
| jorvi wrote:
| 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.
| darthrupert wrote:
| I have the exact opposite experience: fonts are crisp on
| Wayland and blurry crap on xorg.
| jackdaniel wrote:
| 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).
| mahkoh wrote:
| 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.
| llm_trw wrote:
| > 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.
|
| This is a very odd definition of "no blur".
| mahkoh wrote:
| It works in chromium without anything I'd call blur. Here
| it is at 175% scale: https://i.ibb.co/DtKm69d/image.png
| enriquto wrote:
| Does the scaling change the kerning of the letters? This
| looks horrific! (and, yes, blurry, or "antialiased" as is
| custom to name it).
| mahkoh wrote:
| No, that's just the font I'm using. It's the same if I
| keep the scale at 1 and then zoom in the browser.
| darkwater wrote:
| It doesn't look horrific at all to me
| CyberDildonics wrote:
| This looks fantastic to me. Also antialiasing is not the
| same as 'blurry', it is factional values in pixels that
| have fractional coverage.
| Phrodo_00 wrote:
| > factional values in pixels that have fractional
| coverage.
|
| 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
| CyberDildonics wrote:
| _This is also the definition of 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.
| M911T wrote:
| yeah the kerning is bad when using that thing. It's bad
| on my laptop too.
| DiabloD3 wrote:
| Chrome natively scales; however, any bitmap image shown
| it will be blurry.
| dpkirchner wrote:
| 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).
| DiabloD3 wrote:
| 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.
| jwells89 wrote:
| > 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.
| goosedragons wrote:
| 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).
| binkHN wrote:
| 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.
| jacek wrote:
| 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).
|
| See the screenshot of my settings: https://imgur.com/a/VQHD5vT
| phkahler wrote:
| >> 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?
| alwayslikethis wrote:
| 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.
| marwis wrote:
| > 1. XWayland apps (...) The Wayland compositor has no way
| of detecting whether it actually scales
|
| Can't X apps just set a window property (XChangeProperty)
| with their scale factor and have compositor read that?
| kevincox wrote:
| 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.
| pxc wrote:
| If you've got a whole kingdom on offer, you can bite the bullet
| and buy monitors that all have the same DPI. It's painful, but
| it's what I've done.
| k8svet wrote:
| I've never ever noticed blurriness from downscaled integer up-
| scaled Wayland apps.
|
| Blurriness is almost always due to use of xwayland.
|
| These are completely unrelated technically.
| yawpitch wrote:
| > Privileging principle over praxis is generally a losing
| strategy.
|
| Unfortunately it's also Stallman's -- and thus sadly by extension
| the FSF's -- entire shtick.
| pasc1878 wrote:
| 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.
| rekado wrote:
| 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.
| yjftsjthsd-h wrote:
| 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.
| ergonaught wrote:
| "Having and living principles is a losing strategy."
|
| There's a life lesson in asserting that, but the vast majority
| of people take the wrong one from it.
| bayindirh wrote:
| > 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.
| einpoklum wrote:
| "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.
| kryptiskt wrote:
| 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.
| davexunit wrote:
| 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.
| einpoklum wrote:
| 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.
| davexunit wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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 [...]
|
| We call that a web browser.
| trelane wrote:
| 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.
| davexunit wrote:
| This is a very bad faith interpretation of what I wrote.
| persnickety wrote:
| How about a less bad-faith formulation:
|
| 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.
| trelane wrote:
| How is
|
| "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."
| Fice wrote:
| 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, e.g. Intel can activate a backdoor in
| specific CPUs when needed by publishing a microcode update.
| davexunit wrote:
| 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?
| fsflover wrote:
| 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.)
| nonrandomstring wrote:
| 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.
| Cu3PO42 wrote:
| > via its own nix build system
|
| 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.
| ingenieroariel wrote:
| 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.
| davexunit wrote:
| 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.
| rekado wrote:
| 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.)
| janneke wrote:
| It can get even funnier when Chris Baines replaces the
| Nix daemon with a new implementation in Guile. Then, the
| NIH argument can be reused instead.
| rendaw wrote:
| What criticism are you referencing? FWIW I'm a moderately
| pro-NIH person.
| Filligree wrote:
| > Unfortunately I needed a couple of things that were available
| only through apt.
|
| NixOS has approximately the same advantages, but a many times
| larger package repository. Take a look at that, it might
| already have your packages.
| rekado wrote:
| 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.
| KingMob wrote:
| 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.
| b3n wrote:
| Guix even comes with a Nix service[0] which is easy to
| enable if you would like to also use Nix packages.
|
| [0]
| https://guix.gnu.org/manual/en/html_node/Miscellaneous-
| Servi...
| pyrox wrote:
| Nix also has a Guix service itself[^1], if you want to do
| the same in reverse ;)
|
| [^1]:
| https://search.nixos.org/options?query=services.guix
| Guthur wrote:
| But it didn't have lisp :)
| 0x457 wrote:
| > a bit like mixing pkg and ports in BSD
|
| 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.
| nonrandomstring wrote:
| 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.
| Arelius wrote:
| > 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)
| cmrdporcupine wrote:
| 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?
| rekado wrote:
| Yes, see `guix pack` with its various backends.
| davexunit wrote:
| You can use Guix as a package manager on top of another Linux
| distro. I used Guix on Ubuntu for several years.
| cmrdporcupine wrote:
| Ok I'll give it a try. I like Lispy things.
|
| 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.
| slgeorge wrote:
| 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:
|
| * 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.
| Slackwise wrote:
| > 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.
| tombert wrote:
| 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.
| Havoc wrote:
| >then it is kosher, otherwise it is haram
|
| Big fan of mixing & matching not just on hardware I see
| Gormo wrote:
| That mixed metaphor popped out to me as well. What if what
| you're doing is analogous to a glass of wine? It's kosher and
| haram at the same time!
|
| Kosher is to _treif_ as halal is to haram.
| Havoc wrote:
| TIL. Didn't know trief
| slgeorge wrote:
| For those that don't know Guix can be used as:
|
| * 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/
|
| Next meetup is Monday next week - please come along!
|
| 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...
| jcul wrote:
| I used to attend a C++ meetup in my previous city, but since
| have moved.
|
| 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).
| slgeorge wrote:
| 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!
| graemep wrote:
| "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).
| slgeorge wrote:
| 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!
| bmicraft wrote:
| > For example, in roughly the last 24 hours 40 packages
| were added or updated
|
| That's really doesn't feel like a lot. 40 is oughly equal
| to the amount I get daily for just the stuff that's
| installed on my arch system.
| graemep wrote:
| 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?
| slgeorge wrote:
| 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.
| graemep wrote:
| 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.
| gigatexal wrote:
| With nix i can install free, non-free apps -- the amount of
| nix-able stuff is a ton. Is Guix only set to install FSF
| blessed proprietary free stuff?
| rekado wrote:
| 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.
| slgeorge wrote:
| No.
|
| 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.
| b5n wrote:
| https://guix.gnu.org/manual/en/html_node/Channels.html
|
| https://gitlab.com/nonguix/nonguix
| gigatexal wrote:
| Thanks for addressing my ignorance.
| yjftsjthsd-h wrote:
| > a Linux distribution (similar to Nix)
|
| 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.
| colordrops wrote:
| Guix was originally derived from Nix. Guix has different
| goals.
| yjftsjthsd-h wrote:
| 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.
| slgeorge wrote:
| 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 ;-)
| yjftsjthsd-h wrote:
| Ah, yes, in that case we're in full agreement:) There are
| pain points yet, but I already find it slightly painful to
| use a non-declarative system...
| matrss wrote:
| > * 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.
| SkyMarshal wrote:
| _> * a Linux distribution (similar to Nix)_
|
| 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.
| danecek912 wrote:
| Fly
| eecc wrote:
| 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.
|
| Sorry but my eyesight is already bad as it is.
| alwayslikethis wrote:
| 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.
| zilti wrote:
| 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.
| Filligree wrote:
| You don't run Discord, I take it...
|
| Meanwhile, it's apparently going to change soon, but Steam
| games generally use Xwayland.
| Decabytes wrote:
| 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
| acomjean wrote:
| I'm not sure they have the resources but shipping with Linux
| installed would be awesome.
|
| 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.
| nrp wrote:
| 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
| e12e wrote:
| > ... good compilation speed ...
|
| 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?
| bsimpson wrote:
| 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?
| tombert wrote:
| 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?
| mmcnl wrote:
| > 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!).
| stebalien wrote:
| 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.
| alwayslikethis wrote:
| 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?
| marwis wrote:
| It's definitely better than bilinear and bicubic. Looks
| like Lanczos but with some optimization for ClearType.
| alwayslikethis wrote:
| 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.
| bandrami wrote:
| 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.
___________________________________________________________________
(page generated 2024-02-16 23:00 UTC)