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

91–100 of 198 posts

Re: Guix on the Framework 13 AMD

#91

Post by janneke »

rekado wrote: post #85
ingenieroariel wrote: post #68

Earlier quoted context omitted.

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.

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.

Re: Guix on the Framework 13 AMD

#92

Post by slgeorge »

jcul wrote: post #76
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).

We're a small group 5-10 people, so it's very informal and friendly. I'm sure Fabio (https://fabionatali.com/) who organised it would have good advice! I'll say that from my perspective the fact that it's also virtual is really great as otherwise I couldn't attend!

Re: Guix on the Framework 13 AMD

#93

Post by Decabytes »

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 need for a laptop now, but maybe a Framework will be in my future if this happens

Re: Guix on the Framework 13 AMD

#94

Post by rekado »

pasc1878 wrote: post #44
yawpitch wrote: post #15

> Privileging principle over praxis is generally a losing strategy. Unfortunately it’s also Stallman’s — and thus sadly by extension the FSF’s — entire shtick.

Although if you look at FSFs major projects Emacs and gcc they do run on many OSs including non-free (e.g. Solaris, macOS, Windows, VMS and virtually anything that exists) and other free Unixes. GUIX is much much more restricted.

If you mean the Microsoft project called "GUIX": sure, it's rather restricted.

Guix, however, goes out of its way to support extensions at different levels of its architecture. Not only can you extend it with channels, local files, and with Guile expressions, you can also rewrite the dependency graph of your environment with package transformations, e.g. to swap out any instance of Tensorflow with a CUDA-tainted variant of Tensorflow from the Guix Science Nonfree channel, recursively.

Re: Guix on the Framework 13 AMD

#95

Post by rekado »

amszmidt wrote: post #69
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.

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.

One thing that hasn't changed, though, is that compatibility with the Hurd is still a major goal. Sadly (but understandably) development pushes forward for Shepherd on Linux and then we aim to make it work on the Hurd, instead of letting Hurd-native facilities guide development. But this might change as there is considerable overlap between Guix contributors and Hurd enthusiasts.

Re: Guix on the Framework 13 AMD

#96

Post by yjftsjthsd-h »

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…

> a Linux distribution (similar to Nix)

I'm pretty sure all of these are like nix, right? I've used nix on top of other distros, the development environment thing is like nix-shell, nix is happy to build container images, and of course there's nixos.

Re: Guix on the Framework 13 AMD

#97

Post by colordrops »

yjftsjthsd-h wrote: post #96
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…

> a Linux distribution (similar to Nix) I'm pretty sure all of these are like nix, right? I've used nix on top of other distros, the development environment thing is like nix-shell, nix is happy to build container images, and of course there's nixos.

Guix was originally derived from Nix. Guix has different goals.

Re: Guix on the Framework 13 AMD

#98

Post by alwayslikethis »

eecc wrote: post #89

HOWEVER, and I hope this is a transient situation, there is a problem: in GNOME, applications that aren’t native Wayland apps don’t scale nicely. It’s like the app gets rendered to a texture at the original resolution, which then gets scaled up in a blurry way. Unfortunately that's how it works on all Linux distros since "this will be the year of Wayland". Last time I tried it was 2020, and I gave up when it turned o…

This is largely a GNOME issue. KDE and Hyprland supports not scaling XWayland and a lot of X11 apps can scale themselves. VSCode and Chromium scales perfectly in Wayland now and IntelliJ can scale in X11.

Re: Guix on the Framework 13 AMD

#99

Post by yjftsjthsd-h »

einpoklum wrote: post #51
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…

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. About the CPU microcode updates... why do you believe they are important? I mean, if your system runs arbitrary code off the Int…

> 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 is effectively not working on such systems. And yes, of course it's possible to enable it, but you have to find out yourself because telling people about nonguix in any official docs or communication channels is disallowed.

> About the CPU microcode updates... why do you believe they are important? I mean, if your system runs arbitrary code off the Internet [...]

We call that a web browser.

Re: Guix on the Framework 13 AMD

#100

Post by yjftsjthsd-h »

colordrops wrote: post #97
yjftsjthsd-h wrote: post #96

Earlier quoted context omitted.

> a Linux distribution (similar to Nix) I'm pretty sure all of these are like nix, right? I've used nix on top of other distros, the development environment thing is like nix-shell, nix is happy to build container images, and of course there's nixos.

Guix was originally derived from Nix. Guix has different goals.

Sure? I'm pointing out that the listed features are more or less identical AFAICT. I grant that being a GNU project affects some of its goals and how it goes about things.
Post reply on HN