Hacker News Reader

Comment by claytonjy | Hacker News Reader

As a framework owner, this is nice to see. I have yet to take the plunge on Nix (been happy with PopOS on mine), and wouldn't without Bluetooth support, but it's good to know it's possible and relatively painless.

I'm hoping to start with nix+home-manager at some point, maybe on top of PopOS; anyone have experience with that setup?

View on HN

Nix + home-manager is how I started on arch. After moving about 80% of my Pacman-installed packages over to nix-configured packages bit by bit over weeks and after that all of my dotfiles I plunged into nixos. Transition was super smooth, can only recommend!

Can I install packages not present in the official NixOS repositories without learning the Nix DSL?

You can, if your repository of choice provides a Nix channel[1]. However, the community effort is currently concentrated in the official Nixpkgs repository. So while there are numerous projects based on Nix run outside of the NixOS organization, there aren't any "major" unofficial package repository that I'm aware of. For packaging work, people just tend to contribute directly to the official repository. In fact, the volume of PRs in the official repository is so high I'm surprised at how they manage to keep going in spite of that.

It's also worth noting that many of the benefits of Nix are directly driven from being able to write custom Nix expressions. So if you want to reap all of its benefits, it's definitely worth learning. The core language is small and the experience is not so far off from writing JSON, so that part is relatively easy to pick up. The actual work lies in learning how packaging is done in Nixpkgs. This is best done by grepping around the Nixpkgs repository for examples. Nixpkgs' policy of having all packages in a single repository really shines here.

[1]: https://nixos.wiki/wiki/Nix_channels

I tried using NixOS a few years ago but found it too esoteric. Learning the Nix DSL and the NixOS way of doing things might be rewarding but it has a significant threshold that I'd need to cross before I'm comfortable using it.

One of the things I really appreciate about Arch is the flexibility it offers. I'm not forced to use GRUB if I don't want to, unlike Fedora and Debian. I'm also not forced to see dm-crypt UUIDs on mounted disks like Dracut does. I can choose what I want. This latter issue was present in NixOS as well the last time I tried it.

Oh, I'm also not a fan of how unbearably slow the nix package manager is compared to pacman.

I do recognize the advantages of declarative configuration of your entire operating system though.

> Oh, I'm also not a fan of how unbearably slow the nix package manager is compared to pacman.

Building a declared environment takes quite a while and switching a NixOS or home-manager generation takes even longer. It was my main complaint about NixOS when I was starting out.

The thing I realised though is that the main scenario where you actually need the speed is when you want to try things out and for that, Nix' ad-hoc environments are much better suited.

When I want to try a new program (btop for example), I simply run `nix-shell -p btop` rather than adding it to my declared environment and sitting through a `nixos-rebuild test`. That's usually faster and, more importantly, cleaner than installing the package to a global environment with a regular package manager.

Not exactly the same but my journey started with nix home-manager on MacOS. Spent time getting it working how I wanted. I enjoyed it so much I replaced my Mac with nixos soon after

MacOS has second tier support to Linux. I'm sure PopOS will work well

https://github.com/NelsonJeppesen/nix-lifestyle/tree/main/ni...

I started out just using Nix for development on Fedora and macOS, with home-manager coming later. Was a good way to get into Nix without taking the full NixOS plunge.

Somewhat random question: What kind of run time do you get out of a battery charge with PopOS on the framework laptop? I've seen some comments from people who were unhappy with theirs, but maybe PopOS has some better tuning?

I’ve only had mine for a day, but following the official PopOS guide[0] on the framework forums they advise manually setting mem_sleep_default to DeepSleep to override the default S2Idle, which was “burning through the battery” like crazy.” I’ve seen 5-6 hour runtimes with full brightness using with this option enabled (anecdata from a post on the framework or PopOS subreddit), which appears to be somewhat accurate with my setup (docker, Postgres, vs code, many Firefox tabs, slack, some other miscellaneous services running in the background).

[0] https://community.frame.work/t/framework-and-popos/2898

I'm seeing similar, maybe closer to 8 if it's mostly browsing and light IDE work, and I never run full brightness.

I should probably chime in on the forum, but per that thread I tried Wayland but it didn't go so well, particularly with an external monitor plugged in. Too many misbehaving and misscaled apps, I remember having issues with vscode (scaling) and either kitty or alacrity (can't move or adjust window).

Interesting, that is very good to know. I have yet to try external monitors (will be plugged in tomorrow morning for work), but have been waiting on switching to Wayland to see if it’s necessary or not.

Great to hear about the 8 hour duration as well, I’m absolutely loving this new toy!

I should point out Wayland isn't all-or-nothing; if you enable the config from that post, it's an option you can select when logging in. I never had to "go back" from Wayland, I just stopped selecting it, and can try it out again whenever.

My understanding is that the options for tuning battery life on Linux are pretty much the same across Linux distros. You either have TLP, Laptop Mode Tools, Powertop, or Gnome Power Manager, all of which tunes kernel settings in a similar fashion. Thermald might possibly help too, but I'm not sure if it has positive effects on battery life.

The only factor that I could think of that might make a difference across distros is the availability of hardware video acceleration in browsers. But that gap is likely to close soon, if there are any right now.

Reply on news.ycombinator.com