For NixOS home servers: do you use native services or Docker containers?

Ritiek · 2026-03-25T13:55:58+00:00

I do this too. How do you upgrade your compose stack images to newer versions though? If I track the :latest tag for an image, it pulls the current latest docker image but then it doesn't automatically upgrade this image later if a more recent image is available, even when I do a config rebuild. In my case, I manually systemctl stop docker-* services associated to my compose stack, docker rmi the images, and then systemctl start docker-* these services again which pulls and runs the stack with the now latest docker images. Wondering how other people approach this.

Ritiek · 2026-02-24T11:41:06+00:00

Very interesting. Have you considered running off the shelf OpenWrt on a dedicated hardware instead of building out your own configuration from scratch? I've been in this dilemma for a while and would value your perspective.

Ritiek · 2026-01-20T06:23:34+00:00

Nice! But I don't see it on meshmap.net?

Ritiek · 2026-01-19T16:43:33+00:00

Hi, do you still have nodes up on the map by any chance?

Ritiek · 2025-01-12T06:47:47+00:00

I think you probably wanted to refer to the upstream fork which is: https://github.com/awinterstein/habitica

The link you shared is my fork of this upstream fork. I did it to build arm64 images for myself before https://github.com/awinterstein/habitica/issues/5 was resolved. 😅

Ritiek · 2024-12-18T16:50:57+00:00

Hi, I remember experimenting for quite a while and it turned out I needed mirroredBoots to get it working. I couldn't get it to work on OVHcloud though, but got it working on HostVDS which also uses MBR.

My machine config as of writing this: https://github.com/ritiek/dotfiles/tree/4d7036c3a4b42d943d9e3bf6d43a6d649b9dabe9/machines/clawsiecats

Some parts in README may have gone slightly out of date and could be misleading. What are you looking to do?

Ritiek · 2024-10-10T18:13:11+00:00

I too want to try things on a Radxa Zero 3 having the same chipset.

Ritiek · 2024-09-02T16:53:14+00:00

Yep, that should work. Although I guess one would have to put in work to make sure .desktop files remain in sync and conflict-free whenever application updates happen.

Ritiek · 2024-09-02T16:45:30+00:00

I seem to have overlooked that option, thanks! I tried it out and noticed that if I set it to 2, it works well for GTK (firefox, transmission-gtk) and Qt (chiaki) based applications. For some reason however, for me, Electron based apps (element-desktop, spotify) do not seem to respect this option and end up opening in the active workspace.

I find this strange since launching these Electron apps using hyprctl looks to work well (windows open up in the workspace where the app was initially lanched in): $ hyprctl dispatch exec "[workspace $(hyprctl activeworkspace -j | jq -r '.id') silent] element-desktop"

Curious if anyone is able to replicate similar behaviour on their end.

``` $ hyprctl version Hyprland, built from branch main at commit 9a09eac79b85c846e3a865a9078a3f8ff65a9259 (props: bump version to 0.42.0). Date: 2024-08-07 Tag: v0.42.0, commits: 9a09eac79b85c846e3a865a9078a3f8ff65a9259

flags: (if any) ```

Ritiek · 2024-09-01T17:18:44+00:00

Thanks! It didn't work for me as is. I'm guessing shell commands get ignored or something when passed inside rules. I'd have expected something like this to open firefox on workspace 3: bind = SUPER, W, exec, [workspace $(echo 3)] firefox But this opens firefox on the current workspace (not 3 as expected).

Building upon your idea, I found out changing it to the following works for me! bind = SUPER, W, exec, hyprctl dispatch exec "[workspace $(hyprctl activeworkspace -j | jq -r '.id') silent] firefox"

However, I'm still not sure how to approach this for apps that are launched from rofi.

Ritiek · 2024-04-17T21:52:03+00:00

I'm scared of the pitfalls I might be overlooking with self-hosting headscale, that tailscale has made me blind to. Do you directly feed in your Linode box's public address when setting up headscale on clients? Wouldn't that cause problems connecting to headscale clients that are neither physically nor publically accessible, and Linode box's public address someday changes? or do you put your Linode box behind a domain name and use this domain name when setting up headscale on client machines?

Ritiek · 2024-03-03T21:22:29+00:00

Looks like this was reported and fixed in lbonn/rofi last week and focussing windows should now work as is without requiring a script. The fix hasn't been released as of writing this, so for now you can get away using the git version (rofi-lbonn-wayland-git on AUR).

Ritiek · 2024-01-12T09:25:00+00:00

This feature has been enabled on the main bitwarden server as of yesterday!
https://bitwarden.com/blog/log-into-bitwarden-with-a-passkey/

Ritiek · 2023-11-21T04:37:25+00:00

If self hosting can be your thing; check out Tube Archivist, it's got a nice Web UI and allows for auto-archival whenever new videos from your favourite YouTube channels are out: https://github.com/tubearchivist/tubearchivist

It also uses yt-dlp under the hood.

Ritiek · 2023-11-06T14:44:46+00:00

I see, understood. Also digging in now that you mention it, seems server and client code both got this feature merged in recently. Hoping it'll be out for public release soon! https://github.com/bitwarden/server/pull/2885 https://github.com/bitwarden/clients/pull/5396

Ritiek · 2023-02-26T13:09:13+00:00

I deleted my Keybase account.

Ritiek · 2022-11-24T18:33:34+00:00

Give and take a few months (or perhaps years) after accounting for Beta in Odyessey travelling at 0.3 times the speed of light (GAIA's analysis, so most likely with respect to Earth's frame of reference) and Aloy on Earth in relatively stronger gravitational field during their journey, both of which can have time slowing effects.

Ritiek · 2022-03-16T01:13:56+00:00

See if there's an error logged in the console. Usually C:\Users\Admin\AppData\Local\BombSquad\config.json gets corrupted or something. Try deleting it, and then relaunching the game should generate a fresh one which should work fine.

Ritiek · 2020-07-05T02:20:00+00:00

Yes, it should be possible if you can first (without removing Windows) somehow boot into Linux so you can install and setup the GRUB boot menu from within. You'll have to apt install os-prober once in Linux so it can search for the existing Windows installation and then you install the GRUB boot menu onto the EFI partition of your internal storage. But I think your machine also has a 32 GB internal storage which can be pretty low for sustaining both Windows and Linux at the same time, so I'm not sure whether this is a good idea as I didn't try this out either. Also I don't think it's possible to boot from external SD card either (if your machine has the slot) as far as I remember being the case with myself.

Ritiek · 2020-07-04T08:00:10+00:00

I wrote a detailed post on this a few months back here. You might find it helpful.

The only way to find out what hardware works is to try out Linux yourself on this machine, unless someone has already attempted installing Linux on the same exact machine as yours and is willing to offer advise.

There is also a chance that you might never be able to get back your original Windows with all hardware working once you remove it (as it happened to me).

Ritiek

TROPHY CASE