Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Guix on the Framework 13 AMD

wingolog.org

Post reply on HN
Print view View original

51–60 of 198 posts

Re: Guix on the Framework 13 AMD

#51

Post by einpoklum »

davexunit wrote: post #43
einpoklum wrote: post #25

"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-fre…

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…

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.

Re: Guix on the Framework 13 AMD

#52

Post by CyberDildonics »

enriquto wrote: post #37
mahkoh wrote: post #34

Earlier quoted context omitted.

It works in chromium without anything I'd call blur. Here it is at 175% scale: https://i.ibb.co/DtKm69d/image.png

Does the scaling change the kerning of the letters? This looks horrific! (and, yes, blurry, or "antialiased" as is custom to name it).

This looks fantastic to me. Also antialiasing is not the same as 'blurry', it is factional values in pixels that have fractional coverage.

Re: Guix on the Framework 13 AMD

#53

Post by phkahler »

jckahn wrote: post #5

My kingdom for Wayland fractional scaling that doesn’t make my apps blurry. It makes the feature a complete nonstarter for me.

>> 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?

Re: Guix on the Framework 13 AMD

#54

Post by ergonaught »

yawpitch wrote: post #15

> 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.

"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.

Re: Guix on the Framework 13 AMD

#55

Post by darthrupert »

throwaway11205 wrote: post #12
enriquto wrote: post #8

Earlier quoted context omitted.

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…

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.

I have the exact opposite experience: fonts are crisp on Wayland and blurry crap on xorg.

Re: Guix on the Framework 13 AMD

#56

Post by davexunit »

einpoklum wrote: post #51
davexunit wrote: post #43

Earlier quoted context omitted.

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…

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 Int…

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.

Re: Guix on the Framework 13 AMD

#57

Post by cmrdporcupine »

davexunit wrote: post #46
cmrdporcupine wrote: post #40

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?

You can use Guix as a package manager on top of another Linux distro. I used Guix on Ubuntu for several years.

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.

Re: Guix on the Framework 13 AMD

#58

Post by trelane »

davexunit wrote: post #43
einpoklum wrote: post #25

"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-fre…

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…

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.

Re: Guix on the Framework 13 AMD

#59

Post by hardwaresofton »

bheadmaster wrote: post #6
teekert wrote: post #3

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…

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 ins…

> - 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.

Re: Guix on the Framework 13 AMD

#60

Post by slgeorge »

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...

Post reply on HN