Live data from Hacker News

Guix on the Framework 13 AMD

wingolog.org

111–120 of 198 posts

Re: Guix on the Framework 13 AMD

#111
post #80

Earlier quoted context omitted.

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

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.

Re: Guix on the Framework 13 AMD

#112

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…

> a bit like mixing pkg and ports in BSD

There is no mixing ports and pkgs in FreeBSD (I assume you mean that one). When you build a port, it builds a package and installs that. You run into big rebuilds/reinstalls when versions mismatch between your ports tree and pkgs repo.

Guix/nix can't be mixed with existing package managers, but can exist on the same machine. You're (most likely) going to have duplicates and different versions of the same thing.

Re: Guix on the Framework 13 AMD

#113

Earlier quoted context omitted.

New packages and updates to packages come into the archive continuously. For example, in roughly the last 24 hours 40 packages were added or updated - https://git.savannah.gnu.org/cgit/guix.git/log/ . Advantage of this is that you can use new packages immediately and there's no big 'upgrade'. Challenges are that if you were an enterprise and wanted to stick on an 'old' version this wouldn't the right distribution. Gu…

I do like rolling release distros. I currently use Manjaro and the ARM version of Arch. However, what I really want something like this for is clients servers - not exactly "enterprise" as these are SMEs (not tiny, but not enterprise either). I did find CVE-2024-0985 was not fixed in Guix, but overall so far other things seem to be up to date than when I last looked at it. What is your usage? I suppose the other thin…

I use it for additional packages on top of another Linux distribution (Ubuntu). This gets me rolling release packages and guix shell which is great for development as each project I'm working on can be completely separated.

For 'servers' the nice part is being able to prepare a declarative operating system configuration and play with it locally (VM), then it can be deployed to the remote node and you know it's going to be the same. If something goes wrong it's easily to declaratively roll-back. Here's a nice starter post (https://stumbles.id.au/getting-started-with-guix-deploy.html). The deploy capability definitely needs more hoops to jump through and it's not without rough edges - but I think it's really cool. There's active ARM and RISC-V work - I don't know how rough that would be compared to the well-known ARM ports - ask on #guix if you're interested.

Re: Guix on the Framework 13 AMD

#114

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 package manager on top of an existing Linux distribution (think apt or rpm)

Just to add to this: don't just think apt or rpm, also think conda/mamba, homebrew or pipx. Nix, and I am sure guix as well, unify this "traditional" distinction between system and user package managers.

Re: Guix on the Framework 13 AMD

#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 channel does not endorse any non-free application. We believe it is non-ethical, harmful to software development and restricts the users freedom. See the GNU philosophy for a more thorough discussion.

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

Re: Guix on the Framework 13 AMD

#116

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)

To nitpick, you mean similar to NixOS. Nix is the package manager, Nix language is the config language that manages the package manager, and NixOS is the operating system created from those two.

Re: Guix on the Framework 13 AMD

#117

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…

I’m not sure they have the resources but shipping with Linux installed would be awesome.

I’m always surprised at the lack of choice hardware with pre installed Linux.

But the framework seems to have a lot of users running Linux so it’s probably a great choice.

Re: Guix on the Framework 13 AMD

#119
post #34

Earlier quoted context omitted.

It works in chromium without anything I'd call blur. Here it is at 175% scale: https://i.ibb.co/DtKm69d/image.png

Does the scaling change the kerning of the letters? This looks horrific! (and, yes, blurry, or "antialiased" as is custom to name it).

yeah the kerning is bad when using that thing. It's bad on my laptop too.

Re: Guix on the Framework 13 AMD

#120
post #112

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…

> a bit like mixing pkg and ports in BSD There is no mixing ports and pkgs in FreeBSD (I assume you mean that one). When you build a port, it builds a package and installs that. You run into big rebuilds/reinstalls when versions mismatch between your ports tree and pkgs repo. Guix/nix can't be mixed with existing package managers, but can exist on the same machine. You're (most likely) going to have duplicates and di…

Yes my previous is mainly with FreeBSD. Your response highlights my mistake. As a Guix noob (but with decades of apt/yum/rpm/pkg kinda experience) I misunderstood how these things interact, and failing to manage Guix was most definitely my fault.

Don't get me wrong, I love Guix and the philosophy, but my heart cries out for some Grand Unified Manager of Packages (GUMP), something that can track whether things need building from source, or can be brought in as binary from an apt or rpm, or build those packages as intermediate stages. I kinda thought that's what Guix was going to do. Now I see that a unified package manager is probably unreasonable and that we are headed more toward containerised "Snap/flatpck" way of things - which I don't like.

Post reply on HN