Atemu

WDYM by "add more AV1s to my jellyfin"?

As in have AV1-encoded source files and have jellyfin transcode from AV1 to more compatible formats or to have jellyfin transcode existing videos (no matter what format) to AV1 in real-time?

For the former, you shouldn't need any special GPU whatsoever as a CPU can decode AV1 just fine but a GPU capable of AV1 decode could help. That's Ampere, Navi 2 and tiger lake or later.

The latter isn't very useful right now as a device capable of decoding AV1 must be quite modern and those are usually in a position to just decode the original without any need for any transcoding.

I see nixos and guixos as spending an hour every day, so that you can save minutes every few years.

I see it more like spending an hour every week so that you can save hours to days of annoying and stressful time every few months.

Though there are other benefits rather than just time.

When trying out guixos, I spent like 5 days going through the docs and annoying people on irc, just to accomplish the same thing as copying a file to a non-~ directory in a normal distro

In the beginning when you're not familiar with things yet, it always takes more time to do something.

I didn't have that particular use-case yet and I'd have to consult at least one manual to do it correctly but I'd nowadays be able to solve that particular problem with one line of relatively simple code in NixOS. (On Guix, I don't know how I'd do it though since they don't use systemd.)
When I started out though? No chance, it'd have taken weeks.

I started off by using the language specific PM to install the dependencies I needed for a project.

Yeah, that's like mistake #1 for non-FHS-compliant distros. ;)

• start figuring out how to use guix to emulate FHS inside of a venv

As the person who implemented a variant of this for Nix (buildFHSEnv), it's rather straight-forward. Though if it didn't exist, I'd rather try distrobox or other dev container thingies if there was no reasonable nix support for the thing I'm working on.

I mean just look at a small part from the beginning of both files: nix formatted by nixfmt

I mean, that's just one particular interface. It's actually quite flexible to do it this way though as it allows you to dumb it down if you don't like it with a little refactor:

{
  startup = let
    exec = command: {
      inherit command;
    };
  in [
    #on launch
    (exec "emacsclient -a '' -nc --init-directory=~/.config/emacs" // {
      workspace = "1";
    })
    (exec "nitrogen --restore")
    (exec "~/.screenlayout/shareni.sh")
    (exec "numlockx on")
    (exec "volumeicon")
  ];
}

That's the beauty of IaC (actual code, not that YAML nonsense): Software environment configuration becomes a software engineering problem and we know how to solve those.

In this specific case though, I probably wouldn't bother with doing that stuff in Nix and would rather just keep the plain i3config text file and set the option glue to just use that file; effectively a glorified stow.

This more complex interface is only truly beneficial if there are parts of your config that vary depending on some other conditions. Some users may have the need to only run a set of commands or have certain launch options on one machine but not another. Trivial to do with lib.optionals and the like using this kind of interface but very hard to do if it was just a list of strings or one large string.

it fucking added defaults like the keybindings I've specifically removed from the config so that the only two i3 deals with are opening the terminal and reloading itself

Well, then tell it to not to do that? I don't know the module in question but any well-designed module has an option for precisely that. If it doesn't, I'd consider that a bug. Otherwise, lib.mkForce is usually also an option.

Spending a week to configure something simple is worth it in that scenario because it'll save you from much bigger headaches down the line. The issue is that they solve problems most users simply don't face, and so the added complexity comes with practically no benefits.

I wholeheartedly disagree. Declarative stateless system configuration a la Nix solves a lot of issues that users face all the time.

Whether the time investment is worth it at present is debatable but there's a clear path towards yes IMO because a project focused around proper IaC elevates operating systems onto another level because it abstracts and centralises configuration. It takes one person to figure out how to configure a certain thing in a sensible way and they can publish that work as a NixOS module for everyone's benefit. Most of the work I put into NixOS is upstream because of this.

Right now, it's absolutely catered towards nerds and other technologically able people like us but imagine what a further abstracted GUI could do for mere mortals.

I think it's better to cross post the original post to avoid this monstrosity and also to have some sort of "main" post that all others link to.

Say, was this cross-posted?

They used to use the nix-daemon to realise derivations but that too was replaced original software at some point I believe. Everything else has been guix own tooling for a long time.

They still use the same derivation file format (.drv) and the basic concepts are the same ("conceptual fork"), so you could theoretically be able to realise a derivation produced by guix using nix-daemon/nix-store but that's about it as far as similarities go.

If you don't believe me, go take a look at the source code. I promise you won't find a single line of C++ in it, only a ton of parenthesis ;))))

If it works for you, that's great.

I find it a lot more convenient to treat every change about my system as a nearly complete/clean new installation though and NixOS allows you to do so. An upgrade between major versions becomes a walk in the park due to this; it's the M.O. The last one didn't require any modification of the config on my NAS. I remotely rebuilt the system from my MacBook Pro with the new channel, rebooted to get the newer kernel and everything worked just like before.

it’s the only original distribution that even tries to tackle it instead of just working around it.

Well, apart of GUIX of course ;)

It's sort of a conceptual fork of Nix but the actual implementation is all original.

In this comparison, the devil is in the detail.

With Ansible, you have an initial condition onto which you add additional state through automatically executed steps dictated by you until you (hopefully) arrive at a target state. This all happens through modification of one set of state; each step receives the state of the previous step, modifies it and passes the entire state onto the next step. The end result is not only dependant on your declared steps but also the initial state. A failure in any step means you're left in an inconsistent state which is especially critical for the case of updating an existing state which is the most common thing to do to a Linux system.

In NixOS, you describe the desired target state and the NixOS modules then turn that description into compartmentalised bits of independent state. These are then cheaply and generically combined into a "bundle"; wrapping them into one big "generation" that contains your entire target state.
Your running system state is not modified at any point in this process. It is fully independent, no matter what the desired system is supposed to be. It is so independent in fact that you could do this "realisation" of the NixOS system on any other system of the same platform that has Nix installed without any information about the state of the system it's intended to be deployed on.
This "bundle" then contains a generic script which applies the pre-generated state to your actual system in a step that is as close to atomic as possible.
A good example for this are packages in your PATH. Rather than sequentially placing the binaries into the /usr/bin/ directory as a package manager would when instructed by ansible to install a set of packages, NixOS merely replaces the bin symlink with one that points at an entirely new pre-generated directory which contains the desired packages' binaries (well, symlinks to them for efficiency). There cannot possibly be an in-between state where only some of the binaries exist; it's all or nothing. (This concept applies to all parts that make up a Linux system of course, not just binaries in the PATH. I just chose that as an easy to understand example.)
By this property, your root filesystem no longer contains any operating system configuration state. You could wipe it and NixOS would not care. In fact, many NixOS users do that on every boot or even use a tmpfs for /.

(Immutability is a property that NixOS gains almost by accident; that's not its primary goal.)

It's hosted on AWS' proprietary mail service, soooo...

The simplest solution to following a singular user is probably RSS. No additional software services required; only a generic RSS reader on your client device.

For Mastodon it's instance.tld/@user.rss.

~Jonathan Apelt, Tierarzt

If they weren't comfortable with not getting YT ad revenue, they wouldn't be uploading their content to alternative sites.

Relying on YT as the gatekeeper to your entire livelihood also has a cost. It's not trivial to calculate but I imagine it's greater than the loss of AdSense money. There's a reason many people who rely on video content creation to survive hedge through the likes of Nebula, Floatplane or, indeed, Odyssey.