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

121–130 of 198 posts

Re: Guix on the Framework 13 AMD

#121

Post by graemep »

slgeorge wrote: post #113
graemep wrote: post #105

Earlier quoted context omitted.

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…

Thanks that getting started post looks really useful.

i have recently started running development stuff in VMs (shared folder so I can use my usual editors etc) and this might be a nice alternative - but the biggest draw is that it is declarative and looks easier to get to grips with than Nix.

ARM support is not important to me at the moment - those are just personal things (a tablet, a Raspberry PI) that have limited use anyway.

Re: Guix on the Framework 13 AMD

#122

Post by tombert »

I haven't ever used Guix, but I am a huge fan of NixOS, and my understanding is the Guix is trying for a similar experience. The reason that I've never attempted to really use Guix is because I'm a bit worried that I'd have driver trouble because of the LibreLinux kernel and no non-free stuff in the core repos.

To anyone that has used both Guix and NixOS, how do they compare? Do you feel like Guix is a better experience if you get past the driver problems?

Re: Guix on the Framework 13 AMD

#123

Post by tombert »

Slackwise wrote: post #77
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.

Wait, this is a big deal. Will it work with any package manager or only things that it explicitly supports?

One thing that has become a persistent headache for me with Nix is trying to get reproducible builds with Julia, due to the fact that the package manager doesn't have direct integration with Nix, and `nix build` purposefully restricts network access. I'd happily move to Guix if they have an elegant way to deal with this.

Re: Guix on the Framework 13 AMD

#124

Post by Gormo »

Havoc wrote: post #42

>then it is kosher, otherwise it is haram Big fan of mixing & matching not just on hardware I see

That mixed metaphor popped out to me as well. What if what you're doing is analogous to a glass of wine? It's kosher and haram at the same time!

Kosher is to treif as halal is to haram.

Re: Guix on the Framework 13 AMD

#125

Post by rendaw »

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…

What criticism are you referencing? FWIW I'm a moderately pro-NIH person.

Re: Guix on the Framework 13 AMD

#126

Post by rendaw »

bheadmaster wrote: post #6
teekert wrote: post #3

Is this Guix Nix but with a different language? How is it different? So far I only knew Nix, now I see more and more Guix popping up…

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…

- All issue tracking and discussion happens on a mailing list/with custom tooling

Also IIRC Shepherd was a simple 1-level service manager like runit. Is that correct? I played around with it for a while and came to the conclusion that it couldn't represent a service graph.

Re: Guix on the Framework 13 AMD

#127

Post by Arelius »

nonrandomstring wrote: post #120
0x457 wrote: post #112

Earlier quoted context omitted.

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

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

I mean, that sortof what nix (and I assume guix) is though, right? As long as your ok with the binary cache for a replacement for apt/rpm (with the caveat that sometimes pkgs can be built on .deb or .rpm)

Re: Guix on the Framework 13 AMD

#128

Post by b3n »

KingMob wrote: post #111
rekado wrote: post #80

Earlier quoted context omitted.

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.

Guix even comes with a Nix service[0] which is easy to enable if you would like to also use Nix packages.

[0] https://guix.gnu.org/manual/en/html_node/Miscellaneous-Servi...

Re: Guix on the Framework 13 AMD

#129

Post by mmcnl »

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

Transient situations are almost permanent in Linux land. This has been a problem for a long time and I don't see a solution coming in the near future. But maybe I'm wrong (I hope so!).

Re: Guix on the Framework 13 AMD

#130

Post by goosedragons »

jwells89 wrote: post #61
DiabloD3 wrote: post #49

Earlier quoted context omitted.

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

It's not really as necessary on PCs because of how Windows does scaling. It's only a problem in programs that just straight up don't support it. And Apple has routinely and still does ship laptops with non-integer scaled resolutions as default (e.g., the 12" MacBook, the 13" Macbook Air).
Post reply on HN