The map is open and connectable in all of its dimensions; it is detachable, reversible, susceptible to constant modification. … The map has to do with performance, whereas the tracing always involves an alleged “competence”.
My worlds and systems, a nutrient-rich collection of typos feeding the hungry heads of a talking planet, “oriented toward an experimentation in contact with the real”.
These are my personal configurations and are not intended for use as a template, but you are welcome to do so if you like! I hope visitors manage to find something helpful/inspiring/interesting, but please keep in mind that I have no idea what I’m doing.
Dotfield does not embody “best practices” or “the right way to Nix”. The project exists as an evolving and unstable result of one amateur’s take on identifying and implementing flexible and understandishable patterns or novelties across other sources this amateur has encountered.
If you have questions or feedback, feel free to reach out in the issues or discussions!
This section is incomplete, fragmented, and I don’t remember writing it. However, it seems to contain important reference notes for stuff I always forget.
nix-env -f '<nixpkgs>' -iA nixos-install-tools git bat fd ripgrep tealdeer vim
alias nix="nix --extra-experimental-features 'nix-command flakes'"
export NEW_HOSTNAME=<your-hostname>
export GIT_BRANCH="add-${NEW_HOSTNAME}"
curl "https://raw.githubusercontent.com/montchr/dotfield/${GIT_BRANCH}/machines/${NEW_HOSTNAME}/disk-config.nix" -o /tmp/disk-config.nix
nix run github:nix-community/disko -- --mode disko /tmp/disk-config.nix
# to verify:
mount | grep /mnt
git clone https://github.com/montchr/dotfield.git -b "${GIT_BRANCH}" /mnt/etc/nixos
# absolute paths from `/mnt` would break once booted into the system
cd /mnt/etc && ln -s nixos dotfield && cd nixos
nixos-generate-config --no-filesystems --root /mnt
Integrate any missing configuration from the generator locally, push to remote, and pull on the host.
nixos-install --flake ".#${NEW_HOSTNAME}"
After rebooting, edit ~/.ssh/known_hosts
on your local machine to
remove the initial entries since the host keys have been reset after
installation.
export KEYS_DIR="$PRJ_ROOT/ops/keys"
export NEW_HOSTNAME=<...>
export NEW_HOSTIP=<...>
ssh root@$NEW_HOSTIP -t 'cat /etc/ssh/ssh_host_ed25519_key.pub' \
> "$KEYS_DIR/ssh/$NEW_HOSTNAME.pub"
ssh root@$NEW_HOSTIP -t 'cat /etc/ssh/ssh_host_rsa_key.pub' \
> "$KEYS_DIR/ssh/$NEW_HOSTNAME-rsa.pub"
nix run nixpkgs#ssh-to-age -- -i "$KEYS_DIR/ssh/$NEW_HOSTNAME.pub" \
| tr --delete '\n' \
> "$KEYS_DIR/age/$NEW_HOSTNAME.txt"
git add $KEYS_DIR
Add the host to //.sops.yaml
, then:
direnv reload
grep "$NEW_HOSTNAME" $PRJ_ROOT/.sops.yaml --before-context=10
sops updatekeys secrets/global.secrets.yaml
After the initial generation with secrets disabled (due to a catch-22/bootstrapping problem), you should then be able to do the following with a smartcard attached.
export KEYID="0x135EEDD0F71934F3"
gpg --recv $KEYID
gpg --list-secret-keys
gpg-agent-restart
mkdir -p $XDG_CONFIG_HOME/sops/age
# Required for editing sops files
pass show age--secret-key >> $XDG_CONFIG_HOME/sops/age/keys
I still don’t know what I’m doing. Maybe one day I will have enough of an idea that I can write it down with any amount of coherence. Or maybe I’m doing it all backwards…?
- Note taken on [2024-04-10 Wed 20:39]
I began the process of converting some of these items to Org headings with tags.
Generally in order of frecency, along with an optional description of reasons for inclusion.
More recently, I’ve aimed to reference sources with comments and SPDX headings in relevant files.
- https://github.com/lovesegfault/nix-config
- nixos
- https://github.com/srid/nixos-config
- nixos, nix-darwin, vms, simple, nixos-shell
- https://github.com/viperML/dotfiles
- nixos, flake-parts, structure
- https://github.com/TLATER/dotfiles
- home-manager, structure
- https://github.com/d12frosted/environment
- nixos, nix-darwin, world-building, emacs, docs
- https://github.com/colemickens/nixcfg
- nixos, extensive, fun
- https://github.com/cole-h/nixos-config/
- nixos, media server
- https://github.com/kclejeune/system
- nixos, home-manager
- https://github.com/Xe/nixos-configs
- networking, extensive
- https://github.com/hlissner/dotfiles
- nixos, libs, original, structure, homes w/o home-manager
- https://github.com/malob/nixpkgs
- nix-darwin, docs
- https://github.com/cmacrae/config
- nix-darwin, nixos, emacs
Work laptop running NixOS via github:tpwrules/nixos-apple-silicon via Asahi Linux kernel. It’s amazing. 10/10 would recommend. Daily driver.
I would give it 11/10 but I have issues with audio input/output on video calls, and I had to get a DisplayLink hub to use an external display monitor. Those aren’t dealbreaking issues because I know that the Asahi Linux people are working on improving those things and I have workarounds for the time being.
Ryosuke is a “ghost of the circuit”, a denizen of Kairo, LoBE.
The Ryzen 9 5900X processor and mini-ITX Teenage Engineering Computer-1 case are the stars here.
As of <2024-01-22>, Ryosuke is serving as a living room HTPC. I’ve also brough it to the office as a “laptop”.
A towering fiend.
Originally built in 2015, recently revamped.
Workstation desk has the following devices:
Audio in/out | Focusrite Scarlett 18i20 [Gen 1] Audio Interface/Mixer | |
Video in, Audio (mic) in | Logitech Brio 501 Webcam |
seadoom@boschic ~ % dmesg | grep -i -B 3 focusrite
[ 1.567008] usb 5-1: New USB device found, idVendor=1235, idProduct=800c, bcdDevice= 4.4c
[ 1.567011] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1.567012] usb 5-1: Product: Scarlett 18i20 USB
[ 1.567013] usb 5-1: Manufacturer: Focusrite
seadoom@boschic ~ % pw-dump | grep node.name | grep alsa
"node.name": "alsa_input.usb-046d_Brio_501_2235LZ52HK58-02.analog-stereo",
"node.name": "alsa_output.pci-0000_0c_00.4.iec958-stereo",
"node.name": "alsa_input.pci-0000_0c_00.4.analog-stereo",
"node.name": "alsa_output.pci-0000_0a_00.1.hdmi-stereo",
"node.name": "alsa_output.usb-Focusrite_Scarlett_18i20_USB-00.multichannel-output",
"node.name": "alsa_input.usb-Focusrite_Scarlett_18i20_USB-00.multichannel-input",
seadoom@boschic ~ % lspci | grep -i audio
0a:00.1 Audio device: NVIDIA Corporation GA102 High Definition Audio Controller (rev a1)
0c:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller
seadoom@boschic ~ % lsusb | grep -i scarlett
Bus 005 Device 008: ID 1235:800c Focusrite-Novation Scarlett 18i20
The 18i20 is connected to KRK Rokit 5 studio monitors via the interface’s L/R monitor output channels. Unfortunately, ALSA resets the monitor output level to muted status each time the device is reconnected.
See /var/lib/alsa/asound.state
for the state of ALSA settings as of
last boot. According to
https://wiki.archlinux.org/title/Advanced_Linux_Sound_Architecture#ALSA_and_systemd,
updated values will be written on shutdown.
Possible culprits for the mute status:
(note that this one is not the 18i20, which is USB):
State.Generic { ... control.18 { iface MIXER name 'Auto-Mute Mode' value Enabled comment { access 'read write' type ENUMERATED count 1 item.0 Disabled item.1 Enabled } } ... }
And for the 18i20 itself:
State.USB { ... control.9 { iface MIXER name 'Master 1 (Monitor) Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } ... }
Source should be PCM 1
An early-2014 15-inch MacBook Pro who has seen quite the life. ~Mostly unused for the past several years due to the availability of more portable work laptops. It is now living out its life in a declarative retirement home.~
Update [2024-04-10]: This laptop was my primary computer for a couple months
until switching to tuvok
since aarch64-linux
support has improved since
tuvok
’s initial provisioning.
nixos-rebuild
is very slow, even with the binary cache and ryosuke
as
build host.
MacBookPro11,3 (Late 2013) (Dual-Graphics Retina Display)
Type | Item |
---|---|
CPU | Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz (4-core) |
Network Controller | Broadcom BCM4360 802.11ac Dual Band Wireless Network Adapter (rev 03) |
Video | NVIDIA Corporation GK107M [GeForce GT 750M Mac Edition] (rev a1) |
Camera | Broadcom 720p FaceTime HD Camera |
Audio | Intel 8 Series / C220 Series HDAC |
Audio | NVIDIA GK107 HDMI Audio Controller |
SATA | Samsung S4LN053X01 AHCI SSD Controller (Apple slot) |
Tip: to determine Apple model within Linux, run
grep -h . /sys/devices/virtual/dmi/id/board_v*
.
Technically, there is also an integrated Intel graphics card in addition to the discrete NVIDIA card. However, Apple decided to force the integrated Intel GPU to be disabled unless running macOS. There are ways around that (apparently rEFInd can help), but I don’t think it’s worth the extra effort.
This issue was originally reported on the grub-devel mailing list, but it doesn’t look like the patch was ever merged (but I don’t yet understand how these mailing list workflows operate so it’s pretty unclear to me what the actual “status” is).
https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00442.html
For more info:
- https://gist.github.com/stefanocoding/c6dbf4489f330021bd9335d655c9fbbf
- https://github.com/0xbb/apple_set_os.efi
Start the machine with the power adapter unplugged (either boot or wake).
Whenever I’ve had the flicker today I’ve fixed it by: Unplug power cable, shut the lid, allow it to suspend (wait for the apple logo light to go out), open the lid, re-plug power cable. This process has removed the flicker the two times I’ve had it today.
Note that this is not specific to GNOME, but affects KDE Plasma and SDDM too (according to one user’s report).
The discussion resulted in a chain of bug reports leading here:
https://gitlab.freedesktop.org/drm/amd/-/issues/759
The discussion and bug report also pertain to AMD graphics, which doesn’t apply to the MacBookPro11,3 model. And yet the power adapter workaround still seems to help resolve the issue with this machine’s NVIDIA graphics…
Dead but dreaming.
Laid to indefinite rest when one of the cats, seeking human attention, chewed through the LCD screen. We did not speak for a week.
Still works, but unusable without external display. Suffers from congenital Butterfly Keyboard Syndrome.
Mostly opinions and rants, some of which will likely be removed in time.
It’s been the default desktop environment for my graphical NixOS configurations, but only because it “just works”. In actuality, while it “works”, it just works. Its primary method of configuration is based on the state of user-selected options in GUIs, hiding the configuration behind opaque UX
There is, I’m sure, a specific term for this particular application design fallacy, perhaps best summarized by WordPress’ infamous “decisions not options” aphorism and embodied in Apple software and hardware. While it looks pretty and looks like it has “good UX”, like macOS (and Apple software in general), it has so much useless clutter and ends up breaking in weird ways.
gsettings
is a command-line interface for dconf
schema
introspection. It’s useful for getting/setting the current value of a
setting and for scripting necessarily-stateful settings like theme
appearance variants.
dconf
is the underlying backend, a database store.
“dconf Editor” is a GUI application for quick and direct interaction
with available settings, similar to Firefox’s about:config
page.
Use gvolpe/dconf2nix: 🐾 Convert Dconf files (e.g. Gnome Shell) to Nix, as expected by Home Manager in combination with home-manager/modules/misc/dconf.nix at master · nix-community/home-manager
Unreliable and clunky.
On multiple occasions, I’ve gotten locked out of the default keyring, which is supposed to be the same as the login password. Deleting a couple files resets it:
rm ~/.local/share/keyrings/{login.keyring,user.keystore}
When I first activated the Nextcloud Client application on boschic, I
was prompted to unlock the default
keyring. But because I was locked
out, I needed to dismiss the prompt. The prompt immediately reappeared.
Because the GNOME prompts are “accessible”, there is no way to escape focus other than pressing cancel. That means that a process can spam request a prompt indefinitely, with no way to kill the process from within the GNOME session. I had to resort to C-M-F1 to switch to the virtual console / getty.
On that note, considering that I’ve disabled getty@tty1 when autologin is enabled (due to a NixOS issue), switching tty might not work in those scenarios…
I really do want a browser to “just work”, but with the option to configure frustrating things like… keyboard shortcuts… which Firefox does not support. The question is: do any browsers? I am not yet sure.
TL;DR Nope, forget it.
https://support.mozilla.org/bm/questions/1381773
there is no way to customize internal keyboard shortcuts. this should be considered a bug, not a feature request. but it’s considered an “idea” in a community feedback forum, with no indication as to whether it matters to Mozilla or not.
i wonder whether the community forum is intended to act as a buffer zone / feedback echo chamber to keep users out of the internal bug trackers. Mozilla has to actually consider and prioritize user feedback from this forum, otherwise why does it exist? Is there any evidence of such a process?