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

11–20 of 198 posts

Re: Guix on the Framework 13 AMD

#11

Post by pasc1878 »

goosedragons wrote: post #9
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…

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.

Another big thing is Guix only works on GNU/Linux and not on macOS and other Unixes like FreeBSD which Nix does run on.

Re: Guix on the Framework 13 AMD

#12

Post by throwaway11205 »

enriquto wrote: post #8
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.

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.

Re: Guix on the Framework 13 AMD

#13

Post by kdtsh »

goosedragons wrote: post #9
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…

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.

Re: Guix on the Framework 13 AMD

#14

Post by jackdaniel »

enriquto wrote: post #8
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.

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…

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

Re: Guix on the Framework 13 AMD

#16

Post by operator-name »

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…

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

Re: Guix on the Framework 13 AMD

#17

Post by jsheard »

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.

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.

Re: Guix on the Framework 13 AMD

#18

Post by throwaway11205 »

jsheard wrote: post #17
throwaway11205 wrote: post #12

Earlier quoted context omitted.

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.

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.

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?

Re: Guix on the Framework 13 AMD

#19

Post by davexunit »

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

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.

Re: Guix on the Framework 13 AMD

#20

Post by mahkoh »

enriquto wrote: post #8
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.

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

Post reply on HN