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

141–150 of 198 posts

Re: Guix on the Framework 13 AMD

#141

Post by nrp »

Decabytes wrote: post #93

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…

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

Re: Guix on the Framework 13 AMD

#142

Post by pyrox »

b3n wrote: post #128
KingMob wrote: post #111

Earlier quoted context omitted.

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.

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

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

Re: Guix on the Framework 13 AMD

#143

Post by Modified3019 »

ducktective wrote: post #27
kdtsh wrote: post #13

Earlier quoted context omitted.

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.

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.

Re: Guix on the Framework 13 AMD

#144

Post by marwis »

alwayslikethis wrote: post #139
stebalien wrote: post #135

Earlier quoted context omitted.

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

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?

It's definitely better than bilinear and bicubic. Looks like Lanczos but with some optimization for ClearType.

Re: Guix on the Framework 13 AMD

#145

Post by rekado »

Modified3019 wrote: post #143
ducktective wrote: post #27

Earlier quoted context omitted.

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

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

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.

Re: Guix on the Framework 13 AMD

#146

Post by CyberDildonics »

Phrodo_00 wrote: post #133
CyberDildonics wrote: post #52

Earlier quoted context omitted.

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

> 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

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.

Re: Guix on the Framework 13 AMD

#147

Post by marwis »

alwayslikethis wrote: post #75
phkahler wrote: post #53

Earlier quoted context omitted.

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

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

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

Re: Guix on the Framework 13 AMD

#148

Post by bandrami »

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.

Re: Guix on the Framework 13 AMD

#149

Post by mappu »

alwayslikethis wrote: post #75
phkahler wrote: post #53

Earlier quoted context omitted.

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

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

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.

Re: Guix on the Framework 13 AMD

#150

Post by School-Cotton »

tombert wrote: post #122

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

You can add the nonguix channel to Guix which gives you normal linux kernel, nvidia drivers, etc.

Check out the system-crafters distribution, IIRC it includes nonguix by default.

Post reply on HN