Hacker News new | ask | show | jobs
by mehrzad 2036 days ago
Not completely related but I decided on my latest GNU/Linux distro install that I much prefer the macOS model with slow updates for the major stuff with optional use of Homebrew and other updating mechanisms for the add-ons. One of the things that I got tired of was having to run updates on Fedora, Ubuntu, etc. So I decided to install Debian Stable with the Nix package manager as a sort of Homebrew replacement. This way I don't have to worry about my distro breaking, while I can get new stuff that is atomic and easy to remove when I want. I am curious if any Guix users do something similar.
9 comments

Might as well try out NixOS.

I've been using it on all my personal devices for ~6 months and also for some bare metal sever deployments.

A (mostly) immutable system configured with a single config file is an absolute killer feature.

The ability to roll back to a previous config in the bootloader or the terminal is brilliant.

And home-manager [1] provides the same experience for your user environment.

I also looked into Guix, but the community and package repository seem much smaller.

They also don't accept proprietary software in the official package repo. Which is a respectable ideological choice, but really reduces usability a lot compared to nixpkgs.

[1] https://github.com/nix-community/home-manager

Like the other replier, I also found NixOS very difficult to install and my hardware wasn't supported as well as Debian was.
I’m on NixOS and had the same feeling when first debated which to use.

If I was running some security sensitive app or scientific computing I would probably choose guix and they tend to be pretty rigid about reproducible building from source and signing changes to to the OS. But my day to day OS I use NixOS as I get tons of packages and basically all the same features with the trade-off of expecting some weird behavior on edge-cases and reproducibility (which I have yet to run into but know I will eventually)

I tried to install NIX, but the graphical installer wouldn't boot. I'd have the option to choose it in GRUB, but it went to a command-line.

Then when I tried the text-based install, it couldn't see my NVME disk.

> I tried to install NIX, but the graphical installer wouldn't boot.

I've had the same issue. Nix uses KDE Plasma by default, which uses a compositor that struggles with some video drivers.

Fortunately, installing from command line is practically the same, especially if you do your partitioning beforehand.

> Then when I tried the text-based install, it couldn't see my NVME disk.

That's a more unique problem. I'm not sure what to do about it either. Did /dev/nvme0n1 just never populate? My best guess is that you booted emulated BIOS instead of UEFI.

Weird, i stumbled through NixOS, a dual boot grub setup, and backed by NVME with no issues and very little Linux information to start with.

Currently on NixOS btw, been a great experience from it so far.

My SSD is an Intel 660P, if that helps debugging in any way. Installing using nixos-gnome-20.09.1889.58f9c4c7d3a-x86_64-linux.iso.
I also have an Intel 660P, works fine with NixOS. It shows up as /dev/nvme0n1 .
I gave NixOS a serious try... the reason I gave it up was that pretty much all build systems for my own projects were broken and it was a pain to "nixify" them.
I definitely do. It takes some reading the docs and perhaps asking people how to do it, but you can have some environment defining files a folder of any project and use GNU Guix to enter a reproducible environment. I cannot yet do that for all the things, where I would like to do it, because I often miss a package or get an error when trying to import it from other package repositories like PyPI and am not able to solve these without help from the mailing list. People on the mailing list are very helpful though.

Sometimes a good way to do something on the command line is missing, but the stuff that is there has a great CLI interface, in my opinion. One of my favorites is the time machine.

I have several machines running NixOS and one running Guix.

In Nix you have several channels that push package updates. The stable one moves very slowly, and because Hydra tests packages, it's really rare to experience broken things.

You can also mix them and e.g. install some packages from unstable, and keep others from stable.

Additionally Nix and Guix provide easy total and partial rollbacks, so you should not be afraid of breaking anything.

Have you preferred Nix or Guix (specifically in writing the configuration/managing the system)?
They are both quite different as its an internal DSL vs an external one. Just give them a try.

A major difference at the minute might be package availability. Nix has more packages but some are broken, e.g. Julia. Guix has very clean and reproducible packages, and a slightly better CLI interface.

While reading this discussion, I was thinking exactly the same thing. Normally I use /testing/ distribution of Debian GNU/Linux. But with Guix, I can just install bare-minimum Debian /stable/ and work with Guix for the rest.

This way we'll also get security updates. Debian is committed to providing security updates for the /stable/ distribution. Not sure about /testing/ and /sid/.

When a Guix system upgrade breaks something important, you can simply boot up the previous "generation" of the system and get back to work until the blocker bug you encountered has been fixed, at which point you can attempt the upgrade again.
I'm running Guix on Void, but I think Guix on Debian (experimental) is better supported [1] and what I plan to switch to eventually.

[1] https://lists.gnu.org/archive/html/guix-devel/2020-11/msg002...

Where are the pain points using guix on void? Asking because I may be switching my desktop over to using guix on a foreign distro
Guix works exactly the same no matter which distro you run it on.
I run Guix on Void.

Guix doesn't care what distro you run it atop of.

Yep, Debian/Guix is my setup for my main laptop.

I actually ended up using testing rather than stable for ... reasons but I think if I did it again, I’d stick with stable. Of course, I always think that.

I really agree with this in concept. It's frustrating to me that in practice, Homebrew wants to own /usr/local: https://docs.brew.sh/FAQ#why-does-homebrew-prefer-i-install-...
I know the "cool thing" these days is homebrew, but there's also MacPorts [1] which I would say it and aligns better with the "use a stable base + compile the latest things" approach.

MacPorts does not use the base system to compile the latest things on top. Instead, it creates a "parallel system" where everything is installed from MacPorts (and hence you all dependencies are continuously updated) for the "latest stuff" you install through MacPorts, while not touching the system stuff at all.

[1] https://www.macports.org/

What do you think of using pkgsrc on the MacIntosh?

https://www.pkgsrc.org

I haven't tried it so I don't have an informed opinion.

All I can say in is that MacPorts has served me well for over 10 years at this point, with remarkably few issues (even after updating to newer MacOS releases).

A couple years ago I wanted to install restic, which had homebrew instructions but not a MacPorts package. I don't remember the details, but the installation through Homebrew failed. In the end, I got rid of Homebrew entirely and created a MacPorts package, which took me around 2 hours with no previous knowledge on MacPorts packaging. It was accepted upstream too :)

Since then it just hasn't seemed necessary to try out other package managers. MacPorts fills that need for me and I prefer to spend my time elsewhere.

I like Gentoo for this reason. I can leave core elements and stuff I don't care about on "stable" while selectively choosing "unstable" for things I use every day. Unstable is pretty stable for the most part. The nice thing is the stable core is still rolling so no major updates.
I used Gentoo exclusively for 5+ years (around 2002-2007) and after the umpteenth update which broke printing, I switched to Debian stable, and will probably use it for the rest of my life. Being able to get stuff done without having to worry about random stuff breaking was a very positive life change. Back then most Gentoo ebuild authors updated versions of all dependencies of a package, as well as the package itself, which
Things are so much better now. I used to use Arch Linux around that time while I was at university. During my coursework I was procrastinating and decided to upgrade my entire system. It broke. With only hours left until the deadline I chucked in one of those free Ubuntu CDs I have lying around and was back up and running within an hour.

I stayed on Ubuntu for years after that. But now I've gone back to Gentoo and it's very impressive. Everything just works. I'm sure it's partly due to my extra experience but I really don't have a problem with stuff breaking. Things are so much better now.

Gentoo was too hard for me to install (command-line partitioning is just too risky) so I ended up using Redcore, which has a nice GUI installer, and is Gentoo-based.
You can always boot any Linux rescue system (Knoppix) and use gparted to figure out the partitioning, then continue their cli install. I do agree that partitioning by commandline is scary biz. A good TUI (think weechat, htop, tmux quality) would do great for this purpose. That is, if the machine is a pet and not cattle.
Repartitioning from another distro (Elementary in my case, due to WiFi and trackpad support) is what I did for most of the installs. I still wasn't fully sure how to run the CLI commands for a particular partition, rather than a full disk. In the end, Redcore just gave a better installation process for the same backend kernel.

Speaking of Knoppix, though, it worked great for USB boot, but I couldn't for the life of me manage to get Knoppix booting from an internal partition. Flashing the ISO makes 3 partitions from USB, and if I copy those to internal partitions with cp -Lr, and set the boot flags, they're still not detected. Eventually I just used Kanotix.

> command-line partitioning is just too risky

So partitioning a device is less risky with a GUI? That doesn't make sense.

EDIT: I should be more constructive:

I know that the command line scares some people, but that's just like computers in general scare most people, it's just something you have to get over with.

Another "scary" thing is the choice that exists between multiple available partitioning tools, I know it took me some time before I decided that the good old fdisk was my choice, but really, it probably doesn't matter, any should be OK. You probably won't actually do it directly from the command line anyway, e.g. fdisk is dialog driven instead.

Lastly, I doubt that it isn't possible to fire up Xorg from the Gentoo install media and then partition from a GUI tool, if that's what you want.

I personally find it easier to see the gui layout of my disk before I press play. Gparted can queue and execute a lot of changes to get to your desired state. Very intuitive for people like myself who doesn't deal with partition layouts and filesystems on a daily basis.
Don't get me wrong, seeing the layout is great if you don't mind the requirement for a GUI, but the fdisk UI is actually pretty good, too. It also queues and executes a lot of changes to get to your desired state, and it can show all the sizes and offsets that define the partition layout. It's not actually a command line tool, but dialog-driven (you give it commands on-line, get built-in help, etc.).
To reiterate the point you are replying to:

Using a command-line partitioning utility like parted or fdisk is more risky to interface with, at least for the layman.

Am I using GPT tables? How many blocks for this partition again? What partition type am I marking this? Am I using a capital G to denote gigabyte? A plus sign before or after the number? What is the current state? What is the planned state?

These aren't particularly difficult questions, but they are more easily answered when using a GUI tool like GParted than they are when using fdisk or parted.

GParted is an excellent GUI. I personally haven't seen a more reliable and usable partition utility. It's my first and last recommendation, no matter what the user's background, and it will likely continue to be for a very long time.

Cfdisk. Much better and still terminal based.
Better than fdisk? Yes. Better than GParted? I don't think so.
I did try to run startx from the Gentoo installer, but it isn't available.

Command-line partitioning isn't the problem, per se, it's the lack of manual config options. Zenwalk (Slackware) has a command-line installer, and that detected my existing partitions correctly and let me install.