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

181–190 of 198 posts

Re: Guix on the Framework 13 AMD

#181

Post by [deleted] »

janneke wrote: post #91
rekado wrote: post #85

Earlier quoted context omitted.

Guix includes a copy of the nix-daemon. It's a relatively small C++ program that manages the store. We reuse it because there was no point in writing a replacement for something as low-level as the daemon. Guix compiles its package definitions down to the same kind of file format that the old Nix daemon understands. (It's a bit funny to me that GNU has a reputation for NIH-ing projects, but when a GNU project doesn't…

It can get even funnier when Chris Baines replaces the Nix daemon with a new implementation in Guile. Then, the NIH argument can be reused instead.

[deleted]

Re: Guix on the Framework 13 AMD

#182

Post by johnisgood »

janneke wrote: post #91
rekado wrote: post #85

Earlier quoted context omitted.

Guix includes a copy of the nix-daemon. It's a relatively small C++ program that manages the store. We reuse it because there was no point in writing a replacement for something as low-level as the daemon. Guix compiles its package definitions down to the same kind of file format that the old Nix daemon understands. (It's a bit funny to me that GNU has a reputation for NIH-ing projects, but when a GNU project doesn't…

It can get even funnier when Chris Baines replaces the Nix daemon with a new implementation in Guile. Then, the NIH argument can be reused instead.

Any news on that front?

> The daemon also is a key part of the history of Guix. The Guix project started mixing Guile with ideas from the Nix project, and the guix-daemon is a fork of the nix-daemon with some tweaks made over the years. Rather than being implemented in Guile though, the daemon is implemented in C++ with some helpers written in Guile.[1]

[1] https://guix.gnu.org/en/blog/2023/a-build-daemon-in-guile/

---

Found https://github.com/alezost/guile-daemon (https://packages.guix.gnu.org/packages/guile-daemon/), too, which is just as old. Is it "finished"?

I suppose nothing has happened out of https://summerofcode.withgoogle.com/archive/2017/projects/59...?

Is https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/... even relevant today?

Re: Guix on the Framework 13 AMD

#183

Post by marwis »

p_l wrote: post #173
marwis wrote: post #147

Earlier quoted context omitted.

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

The toolkits would need to add that, and some of them had engineering direction incompatible with such an idea. Especially GTK 3, which was incompatible (by default) with anything that didn't resemble the imagined wayland future, including non RGBA8888 displays or systems with different GL and X11 visuals.

I don't see how any toolkit design could be incompatible with this and not sure how color spaces play into that?

Every X11 app is already composited and scaled by compositor and has top-level X window where it could set any property it wishes.

Re: Guix on the Framework 13 AMD

#184

Post by rekado »

bsimpson wrote: post #115

Wow, the Free Software people can be insufferable. From the README on the attached Nonguix escape hatch: > Please do NOT promote this repository on any official Guix communication channels, such as their mailing lists or IRC channel, even in response to support requests! This is to show respect for the Guix project’s strict policy against recommending nonfree software, and to avoid any unnecessary hostility. > This c…

I'm used to being called "insufferable" for working on free software. Still a bit harsh judgment of people who at the end of the day still produce software that you are free to use for any purpose or ignore, no?

> So it's Nix, but on extra-hard mode because of some impractical restrictions outlined by the author?

It's not Nix, and no, there are no impractical restrictions, nor is it hard to extend Guix with a wealth of third-party channels.

See other comments here that attempt to address this and other misconceptions surrounding Guix.

Re: Guix on the Framework 13 AMD

#185

Post by rekado »

johnisgood wrote: post #182
janneke wrote: post #91

Earlier quoted context omitted.

It can get even funnier when Chris Baines replaces the Nix daemon with a new implementation in Guile. Then, the NIH argument can be reused instead.

Any news on that front? > The daemon also is a key part of the history of Guix. The Guix project started mixing Guile with ideas from the Nix project, and the guix-daemon is a fork of the nix-daemon with some tweaks made over the years. Rather than being implemented in Guile though, the daemon is implemented in C++ with some helpers written in Guile.[1] [1] https://guix.gnu.org/en/blog/2023/a-build-daemon-in-guile/ -…

The Summer of Code project was unsuccessful for personal reasons. The project was also never even close to high priority, because the daemon just isn't all that interesting beyond performing its one job of implementing the functional package management paradigm. That is to say, for a long time there was very little to be gained from a rewrite.

The most recent project has only just started and is spearheaded by Chris Baines, who has extensive experience with the build side due to his work on a (Guile-based) build coordinator used by one of the two major independent build farms.

I don't think the older branches contain much that needs to be ported; most of the work from past projects has in fact made it into Guix already and is used for other features --- just not in the daemon. If the Guile daemon project is successful, the daemon will incorporate many of these existing features for build isolation and coordination.

Re: Guix on the Framework 13 AMD

#186

Post by yjftsjthsd-h »

einpoklum wrote: post #174
yjftsjthsd-h wrote: post #99

Earlier quoted context omitted.

> Well, it's not like the "line is drawn" in the sense of GNU software not working on such systems. They draw it in what's included in the default repository for guix... so that line does not actually impact many people, and those who are impacted by it can still cross the line pretty easily. And if what's in the install image results in the OS not bringing up important hardware like network cards, then the software…

> because telling people about nonguix in any official docs or communication channels is disallowed. That's pretty bad. I'm definitely against that. > We call that a web browser. Are there known exploits based on web browser use, which are foiled by CPU microcode changes? Or, are these speculated to be possible?

> Are there known exploits based on web browser use, which are foiled by CPU microcode changes? Or, are these speculated to be possible?

The exploit certainly was possible: https://security.googleblog.com/2021/03/a-spectre-proof-of-c...

To what degree it's mitigated by CPU microcode patches or browser changes, I couldn't say off the top of my head. I suspect the situation has improved on both fronts.

Re: Guix on the Framework 13 AMD

#187

Post by p_l »

marwis wrote: post #183
p_l wrote: post #173

Earlier quoted context omitted.

The toolkits would need to add that, and some of them had engineering direction incompatible with such an idea. Especially GTK 3, which was incompatible (by default) with anything that didn't resemble the imagined wayland future, including non RGBA8888 displays or systems with different GL and X11 visuals.

I don't see how any toolkit design could be incompatible with this and not sure how color spaces play into that? Every X11 app is already composited and scaled by compositor and has top-level X window where it could set any property it wishes.

Not design. Engineering direction. People problem, instead of computer problem, to be quite honest. And one of those directions was that there was no other output than blitting RGBA8888 to screen (which was at one point the only format expected to be seen with Wayland, and GTK3 already was driving towards Wayland) - potentially accelerated with OpenGL (which had hilarious results on some chips where GL pipeline was 16bit only while 2D was 24bit).

Also, unless you're running Xsgi, it's not a given that every app is scaled by compositor.

Honestly, the right way was always to not assume any given DPI, and instead have every top-level window be DPI-aware and have the toolkit update that information dynamically.[1] Or optionally go all-in on vector dpi-independent approach.

[1] The only correct way to handle hi-dpi on Win32 GDI, where scaling is broken partly by old GDI assumption that DPI didn't change, and by applications that hardcoded 96 dpi

Re: Guix on the Framework 13 AMD

#188

Post by thelopa »

e12e wrote: post #104

> ... good compilation speed ... And earlier: > open /etc/config.scm, add the needed lines as described in the operating-system part of the nonguix README, reconfigure, and reboot. Building Linux takes a little less than an hour on this machine. This is for a system bootstrap of guix/Linux - not just the kernel and modules, surely?

They needed to compile the kernel because they were using the full kernel. The main package repository (and thus the main binary caches) only include a de-blobbed version of the kernel. To get standard Linux including all the blobs, you need to use the “nonguix” package repository. The nonguix folks do have a binary cache server, but using it during install is slightly annoying. I currently have a guix vm compiling Linux for exactly this reason. Since you likely won’t be installing much else from nonguix during system setup, you only need to compile the kernel and other bloby things you choose to include (e.g. firmware, microcode).

Re: Guix on the Framework 13 AMD

#189

Post by Fice »

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?

Vulnerabilities such as spectre are only relevant if you run untrusted non-free software. Also these vulnerabilities show that sandboxing is not effective on current CPUs, and specific mitigations does not solve the problem in general.

Re: Guix on the Framework 13 AMD

#190

Post by e12e »

thelopa wrote: post #188
e12e wrote: post #104

> ... good compilation speed ... And earlier: > open /etc/config.scm, add the needed lines as described in the operating-system part of the nonguix README, reconfigure, and reboot. Building Linux takes a little less than an hour on this machine. This is for a system bootstrap of guix/Linux - not just the kernel and modules, surely?

They needed to compile the kernel because they were using the full kernel. The main package repository (and thus the main binary caches) only include a de-blobbed version of the kernel. To get standard Linux including all the blobs, you need to use the “nonguix” package repository. The nonguix folks do have a binary cache server, but using it during install is slightly annoying. I currently have a guix vm compiling L…

Isn't an hour a long time for a kernel compile?
Post reply on HN