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

21–30 of 198 posts

Re: Guix on the Framework 13 AMD

#21

Post by davexunit »

kdtsh wrote: post #13
goosedragons wrote: post #9

Earlier quoted context omitted.

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.

Yeah I second this. I use the nonguix channel for my laptop. Very well supported and easy to use.

Re: Guix on the Framework 13 AMD

#22

Post by bheadmaster »

operator-name wrote: post #16
bheadmaster wrote: post #6

Earlier quoted context omitted.

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…

There's also been a greater focus on reproducibility: https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...

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

Re: Guix on the Framework 13 AMD

#23

Post by viraptor »

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…

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.

Re: Guix on the Framework 13 AMD

#24

Post by bayindirh »

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

Re: Guix on the Framework 13 AMD

#25

Post by einpoklum »

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

Re: Guix on the Framework 13 AMD

#26

Post by rekado »

teekert wrote: post #10
bheadmaster wrote: post #6

Earlier quoted context omitted.

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…

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 ;))

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

Re: Guix on the Framework 13 AMD

#27

Post by ducktective »

kdtsh wrote: post #13
goosedragons wrote: post #9

Earlier quoted context omitted.

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.

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

Re: Guix on the Framework 13 AMD

#28

Post by jorvi »

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.

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.

Re: Guix on the Framework 13 AMD

#29

Post by binkHN »

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.

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.

Re: Guix on the Framework 13 AMD

#30

Post by llm_trw »

mahkoh wrote: post #20
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…

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

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

Post reply on HN