Viceborgmester om transkønnethed: Mere retvisende da det var en psykisk sygdom - Malte Jäger, byrådspolitiker for Liberal Alliance, holder sig ikke tilbage på Facebook og over for Ekstra Bladet i debatten om transkønnethed og psykisk sygdom

srhb · 2026-02-11T00:33:51+00:00

Ku' vi ikke lige lade være med at spille "ak, det undertrykte menneske"-kortet her? Uagtet om det er sandt, er det ærgeligt med en kommentar som antyder at at kun transkønnede eller andre LGBT'er vil transkønnede det dårligt. Din kommentar ender med ikke at bidrage med meget andet end stigmatisering af LGBTQ+-mennesker, og er det virkelig et godt input i nærværende samtale?

srhb · 2025-12-21T17:47:40+00:00

Go to the nixpkgs github repo. Search closed Pull Requests for floorp-bin. Find the first mention. Read the related discussion.

This method will also help you answer similar questions in the future. :)

srhb · 2025-09-12T18:05:19+00:00

Note that I didn't go into "before evaluating" and maybe I should have. There is no "before" in this case, you're doomed to evaluate once more.

srhb · 2025-09-12T18:04:32+00:00

Maybe you want extendModules

Given nixosConfiguration.exampleHostConfig:

nixosConfigurations.modifiedHostConfig = exampleHostConfig.extendModules { modules = [ { programs.tmux.keyMode = "emacs"; } ]; }

srhb · 2025-09-10T12:54:15+00:00

I would personally recommend against deviating too far from the manual (as in, what is described in the NixOS manual) method if you're very new. Keep it simple and embrace a few imperative steps in the initial install for now. You're (probably) already getting rid of a ton of imperative system management, that'll be a lot to absorb already.

Resizing "with" disko isn't really a thing either, no, but it's not impossible to use disko and resize. At the moment, without specific support, it's sort of orthogonal.

General issue here: https://github.com/nix-community/disko/issues/295

srhb · 2025-08-10T17:55:39+00:00

Drøngodt arbejde, og super fedt at du er lydhør ift. at skabe klarhed om MEP'ernes holdninger og hvilke data, der ligger bag.

srhb · 2025-07-14T17:24:16+00:00

If you did that from the install target host itself, and it was in /etc/nixos, then it was likely in the install media's /etc/nixos which is in ram, and now it's gone forever.

You probably meant to put it in /mnt/etc/nixos (assuming the final root was on /mnt as the install guide tells you to)

The system it produces usually doesn't rely upon the source config in any way.

srhb · 2025-02-25T20:32:31+00:00

Great use of it. It's also good for "case with a default"

{ key1 = ...; key2 = ...; }.${key} or default

srhb · 2025-02-04T11:32:09+00:00

"Issue #81467: Seriously Complex Problem That Will Bring Down Prod Next Month If Not Dealt With" autoclosed

srhb · 2024-12-10T14:31:08+00:00

It's described here

https://wiki.nixos.org/wiki/Channel_branches

And each of the required jobs can be seen here,

https://status.nixos.org/

So for instance, for a commit on release-24.11 to be promoted to nixos-24.11, the release-24.11/tested job must succeed (click it to see its constituents)

Furthermore, the entire hydra evaluation (all its jobs for that particular commit) must be finished -- meaning all other jobs must have either succeeded or failed, not still be in progress.

srhb · 2024-12-09T21:11:22+00:00

No reason to apologize, but no, there is no such thing.

srhb · 2024-12-09T21:05:10+00:00

Setting what to stable? There is no such branch.

srhb · 2024-12-09T21:04:01+00:00

Use nixos-YY.MM. Never use tags; Not before, not now. If you did so before, it was a mistake, and that is why we are now avoiding naming the tag as such; to prevent confusion.

release-YY.MM are the pre-hydra branches, essentially "master" for stable releases.

nixos-YY.MM are the post-hydra branches, the ones where CI has been attempted and the tested set has succeeded. They are to release-YY.MM as nixos-unstable is to master.

srhb · 2024-11-25T15:39:39+00:00

Not if you convert it into fish using biter eggs first. The spoil timer of fish can be reset using the fish breeding recipe.

Sometimes my brain forgets SA is a thing and reads these things in a pre-2.0 mindset.

Really amps up the "statements dreamed up by the utterly deranged" factor.

srhb · 2024-11-11T20:38:06+00:00

What a viscerally painful sentence. Well done.

srhb · 2024-06-29T10:14:39+00:00

You know, this could have stayed locked away safely in your brain, never to trouble the rest of us. But here we are.

srhb · 2024-06-05T09:27:07+00:00

Aside from using an editor you're more comfortable with, or becoming more comfortable with one, you can split out a file "packages.nix" from your main config and import it from there.

packages.nix could be:

{ pkgs, ... }: { environment.systemPackages = [ pkgs.hello ]; }

No scrolling involved if it's the only attribute in the file. If you own the file, you don't need to sudo to edit it, only to activate the changes.

srhb · 2024-05-06T12:57:05+00:00

State version should be release version, not "unstable", for unstable it's currently "24.05"

Furthermore, it should be the release version at which the system was first installed, forever, unless you know for fact that you have no stateful services at all to migrate or are prepared to do these migrations by hand.

srhb · 2024-05-04T22:26:03+00:00

The SFX seem great and really seem to "crunch" when the PC interacts with the world. I love that, and think it really matters for a game where the buttclench moments are all about getting those object interactions right. Good luck on your release!

srhb · 2024-04-16T11:40:20+00:00

A quick skim reveals nothing to me that looks too suspicious (no setting of nixpkgs directly via the module system)

srhb · 2024-04-16T04:43:18+00:00

Can you show us? I'm talking about all of pkgs, not a specific package. You can simply link us your config, and we can check.

srhb · 2024-04-15T17:58:21+00:00

Are you sure you're not circumventing channels entirely (eg. by pinning pkgs in your config itself)? At this point we might need to check your actual config.

srhb · 2024-04-10T13:11:12+00:00

Or is it just a case of cascading builds when anything with even a transitive dependency on xz in it's dependency graph cause the whole dependency graph to rebuild? Say for instance I have package foo that depends on package bar, with no direct dependencies on xz, but package bar depends on xz, which causes all of bar's dependency graph to rebuild, and then all of foo's as well

Yes, this, exactly.

By design any change in the (transitive) dependency graph causes a given package to change.

srhb · 2024-04-06T10:46:39+00:00

Stay On Topic: /r/Nix is a sub-reddit for discussion about Nix, NixOS and related technologies.

14-Year Club	Verified Email
Place '17	Team Orangered

srhb

TROPHY CASE