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

61–70 of 198 posts

Re: Guix on the Framework 13 AMD

#61

Post by jwells89 »

DiabloD3 wrote: post #49
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…

I don't know why this guy is being downvoted, he is correct. You cannot scale things to non-integer amounts without incurring some damage . Blurry/fuzzyness, ringing, screen door effect, etc, you cannot avoid these no matter how smart your scaling algorithm is as long as you're upscaling it to something inbetween 100% and 200%. Nyquist-Shannon is a bitch. Wayland made a decision way back that non-scaling apps can onl…

> Unfortunately, people still choose to own monitors that have weird resolutions that do not approximate 96dpi after integer scaling.

It’s not always a choice unfortunately. I buy displays that are capable of a clean 1x or 2x when I can, but there’s a ton of laptops that still need fractional scaling.

Take my Thinkpad X1 Nano. Great laptop in a lot of ways, including the screen (~500 nits brightness, excellent backlight consistency, color, and contrast, no glare) except that it runs at a resolution that requires 1.5x scaling to be usable.

Looking at replacement candidate laptops, the only ones that have 2x screens that aren’t a downgrade somehow destroy battery life (e.g. 3000x2000 OLED panel in Dragonfly Elite G4, which docks 3-4h of battery). 1x screens in this category for some reason are all kinda crappy with e.g. dim 350 nit backlights that start to struggle in a moderately naturally well-lit room, which is just goofy in a portable machine that’s likely to get usage in a bright environment.

This is one thing that MacBooks objectively do consistently better.

Re: Guix on the Framework 13 AMD

#62

Post by rekado »

hardwaresofton wrote: post #59
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…

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

The FSF is not involved in the project. The FSF had no say in what service manager we use.

A common misconception is that we somehow don't like systemd. It just so happens that having a thing that's written in Guile (like the rest of Guix) allows for some code sharing. Hey, we've got the initrd in Guile, too. Might as well go all the way, eh?

Re: Guix on the Framework 13 AMD

#63

Post by Fice »

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…

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.

Re: Guix on the Framework 13 AMD

#64

Post by hardwaresofton »

rekado wrote: post #62
hardwaresofton wrote: post #59

Earlier quoted context omitted.

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

The FSF is not involved in the project. The FSF had no say in what service manager we use. A common misconception is that we somehow don't like systemd. It just so happens that having a thing that's written in Guile (like the rest of Guix) allows for some code sharing. Hey, we've got the initrd in Guile, too. Might as well go all the way, eh?

Apologies, I assumed that being a GNU project (which is supported by the FSF), the project identified as an FSF project.

> A common misconception is that we somehow don't like systemd. It just so happens that having a thing that's written in Guile (like the rest of Guix) allows for some code sharing. Hey, we've got the initrd in Guile, too. Might as well go all the way, eh?

I didn't have this misconception, but let me correct my statement:

But also, I realize that guix devs have to do what guix devs have to do, glad they're around.

Re: Guix on the Framework 13 AMD

#65

Post by slgeorge »

cmrdporcupine wrote: post #57
davexunit wrote: post #46

Earlier quoted context omitted.

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…

Guix can create reproducible development environments that are "sealed off" from the rest of the distribution. It's called Guix shell and it's very flexible:

* Guix Shell https://www.futurile.net/2023/04/29/guix-shell-virtual-envir...

I did two specific posts about using it for 'development' environments. You can also 'fix' the environment (think a git hash) and use the declarative configuration to share it with others:

* https://www.futurile.net/2023/04/30/guix-reproducible-dev-en...

* https://www.futurile.net/2023/10/17/guix-time-travel-dev-env...

Hope they help - if you have a play and get stuck the mailing list is really good and I posted about the Meetup further up.

Re: Guix on the Framework 13 AMD

#66

Post by davexunit »

trelane wrote: post #58
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…

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.

Re: Guix on the Framework 13 AMD

#67

Post by davexunit »

Fice wrote: post #63
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…

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?

Re: Guix on the Framework 13 AMD

#68

Post by ingenieroariel »

Cu3PO42 wrote: post #38
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…

> via its own nix build system Nix is conceptually extremely similar to Guix, but a different implementation! It uses its own programming language, also called Nix, and has a less strict stance on free software.

Guix uses Nix under the hood (learned this when trying to compile it). Perhaps learning Nix first will let the grandparent be more effective in Guix later.

Re: Guix on the Framework 13 AMD

#69

Post by amszmidt »

hardwaresofton wrote: post #59
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…

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

GNU Shepherd (was aka DMD) predates systemd by many years. And many other “PID 1” efforts.

It also had different goals when Wolfgang and I designed it, one might say even incompatible since we were targeting the GNU/Hurd specifically and wanted easy ways to manage translators there on a per user basis.

Re: Guix on the Framework 13 AMD

#70

Post by [deleted] »

ingenieroariel wrote: post #68
Cu3PO42 wrote: post #38

Earlier quoted context omitted.

> via its own nix build system Nix is conceptually extremely similar to Guix, but a different implementation! It uses its own programming language, also called Nix, and has a less strict stance on free software.

Guix uses Nix under the hood (learned this when trying to compile it). Perhaps learning Nix first will let the grandparent be more effective in Guix later.

[deleted]
Post reply on HN