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

71–80 of 198 posts

Re: Guix on the Framework 13 AMD

#71

Post by [deleted] »

davexunit wrote: post #67
Fice wrote: post #63

Earlier quoted context omitted.

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, е.g. Intel can activate a backdoor in specific CPUs when needed by publishing a microcode update.

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?

[deleted]

Re: Guix on the Framework 13 AMD

#72

Post by fsflover »

davexunit wrote: post #67
Fice wrote: post #63

Earlier quoted context omitted.

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, е.g. Intel can activate a backdoor in specific CPUs when needed by publishing a microcode update.

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?

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

Re: Guix on the Framework 13 AMD

#73

Post by Filligree »

nonrandomstring wrote: post #33

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…

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

Re: Guix on the Framework 13 AMD

#74

Post by persnickety »

davexunit wrote: post #66
trelane wrote: post #58

Earlier quoted context omitted.

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.

This is a very bad faith interpretation of what I 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.

Re: Guix on the Framework 13 AMD

#75

Post by alwayslikethis »

phkahler wrote: post #53
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…

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.

Re: Guix on the Framework 13 AMD

#76

Post by jcul »

slgeorge wrote: post #60

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

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

Re: Guix on the Framework 13 AMD

#77

Post by Slackwise »

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?

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

Re: Guix on the Framework 13 AMD

#78

Post by graemep »

slgeorge wrote: post #60

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

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

Re: Guix on the Framework 13 AMD

#80

Post by rekado »

Filligree wrote: post #73
nonrandomstring wrote: post #33

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…

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

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.
Post reply on HN