My opinion : far too many distros are « pet distros »

I think those are actually great. Personally wouldn’t use them for a prolonged time or anything critical. But I love the spirit, even if the distribution is of no use to me.

Thanks, so yes.

Is this relevant when using a login manager?

Billionaire Peter Thiel has even funded a woman’s magazine, meant to compete with Vogue or Cosmopolitan, that positions extremely conservative marriage as the only true path for women’s lives.

Wonder if his wife traditional wife will read it? Oh nvm

You can also track the progress at https://nixpk.gs/pr-tracker.html?pr=367042, is already part of nixos-unstable-small at the time of writing, though this is probably not what a lot of people use. I’ll see when it hits nixos-unstable and let you know, but don’t know when I used my machine the coming days

I have opened a pull request at https://github.com/NixOS/nixpkgs/pull/367042, there might be more changes needed as I had an error in the meta section of the package which I rectified according to the reviewers proposed changes. Not sure this is the end of it, but the request is open

Fish is a surprisingly good shell.

It’s not POSIX compatible, but I don’t really care, it only executes its own scripts / functions. It’s not as innovative as elvish or nu, but it kind of does everything very conveniently and shell-y for lack of a better word – and it always seems so simple. It seems conservative in design, but the old concepts have been evolved in a very usable way. Something I can’t say for all the other shells I’ve tried – at some point, it always gets awkward where fish is just elegant.

No, Cargo.lock is the only relevant optional one for Rust packages and that is already there, so we should be good. I’ll request it tomorrow if someone else doesn’t beat me to it ;)

No, but I will try to incorporate the nixpkgs update script into it now that the metadata is fixed for the release. I’m not a nixpkgs maintainer (yet) though but usually this is close to automatic.

If you want, you can also submit and maintain the package, or I can put us both as maintainers

It’s rather simple in good cases, here’s my version:

{
  lib,
  fetchFromGitHub,
  rustPlatform,
  perl,
}:

let
  pname = "managarr";
  version = "0.4.1";
in

rustPlatform.buildRustPackage {
  inherit pname version;
  src = fetchFromGitHub {
    owner = "Dark-Alex-17";
    repo = pname;
    rev = "df9bba32cb1628fe0bdf33c71089d7ae085066d4";
    hash = "sha256-2KWuqv0nxMc+H+lmuNQ0lbEm5yE2akuZTa7PT5JcvBs=";
  };

  cargoHash = "sha256-hB4uRgVUp6YngMoXqd03U/n+HdlcYdL5bwvTxI4xCLE=";

  nativeBuildInputs = [ perl ];

  meta = {
    description = "A TUI and CLI to manage your Servarrs";
    homepage = "https://github.com/Dark-Alex-17/managarr";
    license = lib.licenses.mit;
    maintainers = [ ];
  };
}

No worries, I look forward to using this in the future :) (though probably rarely, I don’t use my *arr stack often)

Once you have pushed your next release, I’ll submit the package definition I wrote to nixpkgs, currently worked around the ordering by checking out two commits after the tag, but since there’s no rush to push this, I’ll wait for the next release.

So I’m currently building the package, and there’s one thing that irks me a bit about it, which is that you first tagged your release as 0.4.1 and then changed your Cargo.toml… which means that if you check out that tag on GitHub, the information is always one release behind. This also seemed to be the case with other releases (0.4.0 shows as 0.3.7, 0.3.7 as 0.3.6…). From the commit history, this also seems to affect Cargo.lock, so we’re always getting the lock file for the previous release when checking out the tag. Not ideal

An issue with the program itself: it will always show servers for both radarr and sonarr, regardless if you have them configured or not. Switching to an unconfigured one will yield an error for missing configuration. The program itself looks nice, though I’d prefer if there was the option to respect my shell’s color theme.

Cool stuff, thanks.

Now if Sonarr didn’t depend on a .NET version that is EOL… recently deactivated it for that reason

There absolutely are minor versions, but no patch releases. E.g. https://github.com/systemd/systemd/releases/tag/v256.9 which includes no new functionalities, as these are limited to major releases

Unfortunately, from my testing back when I used Arch, a lot of packages in the AUR didn’t meet packaging guidelines, so while quickly writing a PKGBUILD is easy, writing it correctly requires a bit more effort, especially regarding the dependencies. IIRC namcap is often enough, but ideally packages should be built in clean chroots as well to make sure they build everywhere

It’s a bit of a problem that there’s no serious contender to NixOS. Especially Guix is in a good position to become an alternative.

But it will never happen, because of GNU. And before I continue, I want to make clear that this is not to shit on them.

But realistically, only a fork could make it relevant. NixOS, despite its issues (documentation, flakes, whatever), has a massive mindshare: it’s a huge repository with very up-to-date packages, a lot of modules, and devshells are just a very handy thing for developers. You often find flakes in random GitHub repositories for that reason. There are sponsored efforts around the distribution (like lanzaboote). There are (semi-)commercial entities set up around it (numtide, determinate systems, tweag…)

The difference between NixOS and Guix is probably so large that no commercial provider would want to put in the required work to bring Guix up to speed, and GNU is committed to other values. As such, I think only a very big volunteer effort could make a difference.

Yes, nix complements your system’s package manager, but doesn’t replace it

Or am I incorrect. Is this just standardising the API in Vulkan and it gets forwarded to the same video encoding driver? Could we not have Mesa doing a better job? 😒

This is how I would read it. But if you have Mesa do it, it’s in software, and you might just be using a software coded directly then, it’s much easier.

From my understanding, it’s the hardware that produces bad results. There’s no encoding logic in the drivers itself. That’s why the encoding is accelerated in the first place.

E.g. if the hardware doesn’t support b-frames – which for long it didn’t – a new driver won’t do jack. This is just about how video data gets into and out of the card, any encoding logic is handled by the hardware.

What made the release exciting for you?

I just roll along on NixOS-unstable, so for me changes just trickle in over time.