devin's blog

i like Fish

Tue, 24 Jun 2025 00:00:00 GMT

fish (friendly interactive shell) is a "smart and user-friendly command line shell for Linux, macOS, and the rest of the family". It contains so many useful features built-in, which you usually have to configure to add to other shells, and is overall much easier to work with than others.

I discovered it from a couple of my friends and it has made using the command line a lot easier and more attractive for me. It's pretty easy to install and use.

features

autosuggestions

Start typing any command and fish will try its best to complete the command for you. It also gets auto suggestions from your history. For example, lets say you had a long command that you ran a month ago and you wanna run it again:

❯ git log --au
    fish autocompletes for you based on history
❯ git log --author "intergrav" --since "1 year"
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                         (suggested completion)

Then, you can just press right arrow to accept the suggested completion, saving much more time than rewriting the entire command.

syntax highlighting

Fish will automatically highlight valid commands in one color and invalid ones in another. You'll know if you made a typo in a command before you press enter.

(good) tab completion

Fish can complete a ton of things. Some examples include file paths, commands and flags, git branches, environment variables, scripts from your package.json, and more. The completions for commands and flags are generated automatically based on man pages.

An example showing the tab completion for git commit -:

❯ git commit - # press tab here
-a  --all                     (Automatically stage modified and deleted files)
-C  --reuse-message   (Reuse log message and authorship of an existing commit)
-c  --reedit-message  (Like --reuse-message, but allow editing commit message)
-e  --edit                 (Further edit the message taken from -m, -C, or -F)
-h  --help                                   (Display manual of a Git command)
-m  --message                    (Use the given message as the commit message)
-p  --patch                        (Use interactive patch selection interface)
…and 14 more rows

An example showing the tab completion for $ (environment variable):

❯ echo $ # press tab here
$COLORTERM                                               (Variable: truecolor)
$COLUMNS                                                        (Variable: 78)
$EDITOR                                                       (Variable: nano)
$EUID                                                          (Variable: 501)
…and 114 more rows

better scripting syntax

The scripting syntax in fish is a lot more understandable and easier to read than the syntax in bash. Here's an example, taken from their website:

function detect_os
    switch (uname)
        case Linux
            echo "You're on Linux!"
        case Darwin
            echo "You're on macOS!"
        case '*'
            echo "Unknown OS: "(uname)
    end
end

compared to bash:

detect_os() {
    case "$(uname)" in
        "Linux")
            echo "You're on Linux!"
            ;;
        "Darwin")
            echo "You're on macOS!"
            ;;
        *)
            echo "Unknown OS: $(uname)"
            ;;
    esac
}

configuration through web browser

Run fish_config and it opens a web interface where you can customize colors and prompt. You can still configure it without a web browser if you want though.

installation

You can easily install fish on Linux, MacOS and BSD. See their home page for installation info. The documentation also has much more information about what it can do, how to use it, and how to set it as your default shell.

starship

After installing fish, you can use starship with it, which is a prompt thats very fast, customizable, and intelligent. It shows various things to you such as git status (current branch, changes, ahead/behind), language/package versions, ssh status, and a bunch of other information, all in a concise way.

Starship is not a shell, it's a prompt for any shell. I got confused about that when I heard of these two being used together, as I thought they were both shells. You can also use it with bash, zsh, powershell, etc.

For example, here I'm connected to my server (coolbox) with ssh, currently in a git repository (nixflake) on the main branch, and starship lists all of that information:

devin in 🌐 coolbox in nixflake on 🪾 main
❯ echo "hi"

To use it with fish after installing starship, just add this to your ~/.config/fish/config.fish so it runs:

starship init fish | source

Hopefully this helps!! :) This is my first blog post so if there's anything I need to correct then please lmk

goodbye GitHub, hello Tangled (pt 1)

Thu, 29 Jan 2026 00:00:00 GMT

For a very long time now, I've been contemplating switching away from GitHub and finding a better alternative. I have felt this for various reasons, which I feel I shouldn't need to explain, but here's a little summary of issues that I've seen from my own experiences and a couple of my friends:

UI has been getting very buggy and slow over the years. I've noticed significant slowdowns especially when browsing GitHub on my phone, which I do often
Occasional service reliability issues, atleast in my area. There's been cases recently where I haven't been able to download releases for some reason or even visit the site
Their intrusive push for AI, including Copilot, and losing focus on what really matters - the developer experience (see Leah's take on this, I share a lot of the same sentiment)
Owned by Microsoft, and haven't introduced any innovative features since the acquisition (2018!)
Many, many, many other complaints

Anyways. The only realistic options I've had other than GitHub for a while were either using GitLab, Codeberg or self-hosting my own Git forge. And here's a few reasons why I haven't switched to any of those.

I heavily dislike GitLab. It has so many performance issues and such a steep learning curve with it's very complex, cluttered and unintuitive UI. I just really never enjoyed using it, and that could also deter contributors.

Codeberg is not bad by any means, and I love what they do and stand for! However, nearly every time I've tried to switch to it I've had issues with it taking forever to load or not loading at all. Maybe I'm just very unlucky, idk. This seemed to have been a reoccurring issue for me and if I'm using a software forge I need it to be reliable.

And lastly, self-hosting a Git forge, from my perspective, can be a pain to deal with and is just not worth it for me. Because most of the time, from my knowledge, you have to run a mail server, set up your own account system, and setup oauth. I find it overkill, and it also deters collaborators as they have to make new accounts specifically to PR to my projects. And yes, while I am technically "self-hosting" Tangled, I'll get to why that's different.

..so, what is Tangled? and why?

Tangled is a decentralized Git hosting and collaboration platform, and these are reasons why I've been using it:

using Tangled gives you the best of both worlds: the backend (Git storage and CI) that contains the data you actually care about is decentralized and can be self-hosted, as in you can own all of your data. however, Tangled has a centralized frontend (App View) which acts as a consolidated view into the entire network, including those self-hosted instances. It keeps everything connected, and also simplifies self-hosting.
- For future reference, Tangled calls their Git storage servers "Knots" and their CI servers "Spindles".
- As an example, if I wanted to access my friend's repository on Tangled, I just go to https://tangled.org/friend2.org/coolproject, even if they are hosting the data themselves. I don't have to fiddle with accounts or anything, I can stay on Tangled.
- This means that people self-hosting a Tangled Knot don't have to go through the complexities of setting up account management, or a mail server, or anything like that. It only took me about 15 minutes to set up my own personal server.
- And of course, if you don't want to deal with self-hosting, you can just use Tangled's own storage and CI server aswell, which they provide for free. I just prefer to be able to easily back up and manage all my important data at any time, in case something like the GitLab incident happened again.

Tangled is built on ATProto, so you can optionally use a Bluesky account for login. Many people have Bluesky accounts nowadays, so you can just log in with that and you're good to go. No need to deal with manage a separate account, which is what tends to turn most people away.
- If you weren't aware, you can actually self-host your Bluesky account and it's data (they call it a Personal Data Server). The Personal Data Server contains your user and post data on Bluesky, along with user data for other ATProtocol services like Tangled.
- Bluesky operates their own PDS under bsky.social, which is the most popular PDS and is what most people use. Tangled also operates a PDS under tangled.sh. And, you can host your own aswell. You can even painlessly migrate all of your data between PDS's, without losing any followers or data as each person has a unique ID that doesn't change.
  - I recommend checking out the @me website if you want a visual representation of how the PDS works. Try entering in your Bluesky handle after logging in to Tangled with your Bluesky PDS!
Tangled's UI/UX design is amazingly simple, easy to understand, and very lightweight. So much so, that I even spent a day or two redesigning my entire website around this style. That's how much I enjoy it (okay well my website also just looked like total dogshit before, as I was lazy, but whatever...)
Tangled's pull request model is far superior to GitHub's. It follows a round-based pull request flow, with inter-diffing between rounds. You can just paste a git diff/git format-patch if you want to make quick changes! Of course, you can also just compare a fork as usual.
If you self-host your CI server, you can run workflows on your own infrastructure. And, it natively supports Nix, so you have access to pretty much any package you need. Seriously, Nixpkgs has everything.

There's a lot to love about Tangled as a code hosting service. They learned from the mistakes of previous software forges and made something very nice to use and polished. However, it is important to keep in mind that Tangled is very new. It's still in alpha, and is rapidly developing. At this time, it is currently missing a few features you may need which other forges offer:

Private repositories are not a feature yet
You can't run workflows on a cron job yet (to my knowledge)
There is no built-in static site hosting
- However, there are projects such as wisp.place which offer free static site hosting, integrated with ATProtocol. I'm currently using that to host this site right now, and you can find my automatic deploy workflow on my devins.page/devins.page repository on Tangled.
Still a somewhat small userbase at the moment. It may be cumbersome to explain what Tangled is, which is exactly why I wrote this!

As much as I would like to, I won't be fully switching away from GitHub. I'll still be using GitHub for my organization, along with my most popular projects such as devins-badges. I also still need to use it to contribute to most projects. However, I will be migrating my personal projects over. Maybe once Tangled is more mature I'll consider moving the other stuff.

But overall I've been very happy with the service these past couple days and I'm extremely ecstatic for what's to come. At some point I intend on making a "part 2" to this article explaining my experience migrating to Tangled, and possibly making a little guide to hosting your own Knot/Spindle (however I only really have ever done it on NixOS so it might just be better for you to follow the official documentation).

Please keep in mind: I am very new to this as I have only looked into ATProtocol and discovered Tangled pretty recently, so I could be wrong about some of the things I said regarding AT/Tangled in this article. Let me know if I should maybe edit anything. This is also one of my first proper articles I've ever written. I'll be writing more.

restray, a system tray GUI for restic

Thu, 09 Jul 2026 00:00:00 GMT

(This is, for the most part, a copy of the post I wrote on the restic forum with minor edits)

For various reasons[^1] I've been looking to move away from Time Machine. I also needed to help my brother set up backups for his computer as the other backup programs we tried were just not reliable enough and didn't work for our use case.

Looking for solutions, I decided to go with restic as I've already been using it on my servers for years and absolutely love it. But then I realized I needed some sort of wrapper to make it easier to work with on a desktop OS. I've looked at resticprofile and Backrest, and I certainly think they're great projects! But for my use case, I wanted something even simpler. Like Time Machine if it was instead open-source and cross-platform and modern and Actually Good.

here it is

So, I started writing my own wrapper in Go, and called it Restray[^2]. The intent was to make a very simple and intuitive scheduler for restic that can be used on any OS. It sits in the system tray and all of the functionality is accessible through the tray menu. You can configure and set it up through a config file, or optionally use the very barebones web-based editor through your browser.

Other than the browser-based config editor, there is no web tech involved. So, at idle, the app uses just ~30MB memory and little-to-no CPU. That scales when you start a backup of course, since restic does require quite a bit of memory while running. But it's generally very lightweight.

Here's a preview of Restray on MacOS, but it also works great on Linux and Windows:

Screenshot of the web editor, but you can also just configure with a text editor of course[^3]:

some cool features

Simple scheduling, just input a cron expression. To avoid complexity it runs in the background with it's own scheduler, so you don't have to deal with Task Scheduler/launchd/systemd/whatever else is out there[^4]
Restray supports multiple backup profiles, each with their own schedule, environment file, and settings, which can be useful for having both on-site and off-site backups (in my case, rest HTTP server, and OneDrive through rclone)
If restic is not found in your PATH, on Windows and Linux Restray can self-manage it's own restic binary from GitHub and update it daily[^5]. The MacOS .app also has the latest restic binary bundled at build time
If you need to restore something, on MacOS and Linux you can easily run restic mount from the Operations menu, assuming you have FUSE
- I am also working on a cross-platform QT repository browser that will integrate with Restray, however it will be a separate project and program which you can use standalone. As an alternative to the web-based restic-browser. I will post about that later if I ever do end up finishing it.
Offers a "Shell" operation that lets you instantly drop into your default terminal with the selected profile's environment file sourced, and restic binary loaded into your PATH, allowing you to do more advanced CLI things without friction. works on Windows too!
Can be configured to detect whether or not the machine is on battery power, and based on that, pause the schedule.
Pretty icon animations that I spent a lot of time on for no reason because I was bored
Config file hot-reloading
Hooks
Flexible configuration
See the README for even more features and config reference

In the future, I also plan on supporting alternative backends, the one I have in mind being rustic for better resource usage and lock-free operations. Maybe Borg too but I've never used that personally...

a little disclaimer

While me and my brother have been using Restray for a little while now without issues, this is still pretty new stuff and if you experience any bugs please make an issue and I'll happily look into it.

ok but how do I get it

For most releases I compile and upload binaries for Windows, Linux, and Darwin (MacOS) and you can get them on this page. If you're on MacOS, keep in mind that the MacOS app is not signed/notarized so you will need to remove it's quarantine.

But you can also compile it from source if you'd like, all you need is Go. I also have a Nix package and NixOS module available in the repo's flake :^)

ok but how do I use it

It should hopefully be relatively straightforward to use for anyone who's familiar with restic, but I may make a little guide or video in the future on setting it up. Generally all you have to do is run it, configure the repository path and password in the env file, and configure paths, cron schedule, or arguments in the config file.

Releasing this in case someone finds this useful. I've been wanting to get into desktop software development for a while (less web dev...) and I'm pretty new to this, so if you have any suggestions on improving Restray, let me know on the issue tracker.

I'm probably going to refrain from adding new features though, since it appears to be mostly feature-complete in my eyes. I want to focus more on refining the UX and codebase where possible though I think it's in a pretty good state right now.

Here's a cool landing page I made if you want a summary...

[^1]: Time Machine is not cross-platform, which means I can't have one consistent backup manager across all of my devices. And Apple is phasing out AFP in the next version of MacOS which means I'd have to use SMB which tends to be slow. Though Time Machine is also just slow in general... And restic is just awesome.

[^2]: waow. restic + tray. what a revolutionary name...

[^3]: In this particular screenshot it says read-only because my config is managed by Restray's Home Manager module, but if you're not an insane NixOS user you can just edit it

[^4]: But if you want to, you can! Restray can also be executed through CLI/daemon on Linux/MacOS, see restray --help for a list of commands. But at that point you might just wanna use resticprofile

[^5]: Configurable with the manage_restic setting, unavailable in CLI/daemon

site changes and other updates

Sat, 20 Sep 2025 00:00:00 GMT

~~Using system colors again, since I didn't like the color scheme I came up with.~~ I made a new beige color scheme that I quite like, so this will probably stick for a while
~~Removed giscus comments since they were never really used and just adds bloat to the page. Maybe in the future I'll make a simpler comments system.~~ I've added it back, and mentioned it in the privacy page
Redesigned the header to be a lot more simple, moved external links to the footer.
Use serif fonts for headings, handwritten font for site title, just because I think it looks more pleasing.
Removed clientrouter which gets rid of site transitions, I felt like it didn't really fit well with this site and some browsers couldn't handle it properly.
Added back link underlines for accessibility

Besides that, I'm planning on maybe working on a few new projects in the coming months.

litedocs

Edit 5/18/26: This has been scrapped for a long time, I forgot I was even working on this

I was working on a documentation theme for Astro, similar to Starlight. The main difference is that it will be far, far more lightweight and minimal (like this current site). I haven't come up with a final name yet but I'll probably just call it "litedocs" or something. Once that's done, I may redesign the SkywardMC site to use that, so I can test it and make sure it works properly. It'll include the necessary stuff such as site-wide search with the pagefind api, a customizable sidebar for nav and external links, and internationalization.

While working on this, I had to make a lot of changes to slight.css to make it work better. So, that may get a new major version aswell. It mainly includes some cleanup and new variables to work with.

If/when this project is released, I'll make a post about it here. Maybe I'll also work on similar projects, like a blog theme. Slight.css, this project, and other stuff like that will probably be in under it's own organization.

tricks to make web apps feel native

Mon, 18 May 2026 00:00:00 GMT

For a few months I've been working on a music player for OpenSubsonic servers (Navidrome, Gonic, etc) called tinysub. Rather than a Qt or SwiftUI app, I went with a web app so that this could run on any device easily.

One of the biggest things I focused on while developing this app was performance, which Svelte and Vite mostly solved for me. But another thing I focused on was making it look and feel like a native application, atleast on MacOS.[^1] So I wanted to write down some notes about my experience, in case it might help someone in the future.

Here's examples of how it turned out:

I'm using Tauri to build tinysub, however I'm sure you could probably achieve all the same things with Electron.

tricks

1. use system font size and family

On MacOS (seemingly Windows too), most native applications typically use 13px (0.8125rem) font size by default for most elements. Browsers typically use 16px (1rem) font size by default. Changing the default font size can make a huge difference in how your application looks and feels compared to native, and having a smaller font size also lets you fit much more on the screen!

html {
	font-size: 0.8125rem;
}

Unless you are choosing a specific font for your brand, I recommend using the system font (San Francisco on MacOS, Segoe UI on Windows). Not only does this make your app bundle lighter, since you're not bundling any fonts, it also looks more consistent with the rest of the operating system. This is what I typically use, leaving sans-serif as a fallback for compatibility:

html {
	font-family: ui-sans-serif, system-ui, sans-serif;
}

2. some CSS properties to change

In the HTML element, you should probably disable user-select (and -webkit-user-select for Safari) so that your user can't select text, which stays consistent with native apps. You may want to re-enable this for body copy.

html {
	-webkit-user-select: none;
	user-select: none;
}

I recommend disabling overscroll so that you don't get that "elastic scroll" effect on the main window, which is seen when scrolling on trackpads or mobile devices:

html {
	overscroll-behavior: none;
}

I recommend hiding the tap highlight on iOS devices, which usually causes a blue tint when you press a button:

html {
	-webkit-tap-highlight-color: transparent;
}

3. use proper viewport sizing

Mobile browsers dynamically shift and resize their search and action elements to make more space for the page. The typical vh and vw units do not dynamically change with those elements, often causing the viewport to exceed the browser view area. To mitigate this, use dvh and dvw, which do dynamically change. (for more details, check out this article by Anthony Frehner)

body {
	height: 100dvh;
	width: 100dvw;
}

4. adjust whitespace for safe-area

Another thing you should consider is adjusting whitespace for safe-area. For example, on an edge-to-edge phone where rounded corners are part of the screen, buttons in a footer/action bar could be impossible to reach if they are located behind those rounded corners, or otherwise uncomfortable to reach if they are too close to the bottom edge of the display.

Luckily, this is very easy to solve, thanks to the CSS env(safe-area-inset-*) variables which dynamically change based on the device you're viewing on. In this case I went with borders instead of padding so that I could customize the color of the whitespace for each side, such as matching the bottom whitespace with the footer color of my app:

body {
	border-top: env(safe-area-inset-top) solid transparent;
	border-right: env(safe-area-inset-right) solid transparent;
	border-left: env(safe-area-inset-left) solid var(--bg-sidebar);
	border-bottom: env(safe-area-inset-bottom) solid var(--bg-footer);
}

On desktop these will typically have no effect but you will notice it on mobile devices:

5. use native context menus

In Tauri/Electron apps, I recommend using native context menus, which tend to be more accessible, more consistent, and gives you less code to deal with than making your own custom context menu. In tinysub specifically, I use a custom context menu in the web builds, and native context menus in the Tauri builds.

Here's the Tauri and Electron documentation to get started, and here's what it can look like:

6. consider a custom titlebar

You may want to consider a custom titlebar. Doing so can allow the titlebar to flow better with your content, or allow you to save space by placing actions in the titlebar itself. Personally, I did not make a custom titlebar for tinysub as I felt it wasn't necessary, and custom titlebars can often be a bit annoying on Linux.

Here's the Tauri and Electron documentation to get started on custom titlebars.

7. only show window after page is loaded

I recommend disabling window visibility on startup, and then have your app code show the window only once the page is ready. This prevents any flashing or blank screens while your app is loading.

Here's some snippets from my app:

let window = WebviewWindowBuilder::new((app, "main".to_string(), WebviewUrl::External(url)))
	.title("tinysub")
	.visible(false) // hide window initially, javascript code will unhide later
	//...other window properties

export const init = async () => {
	//...code to execute before showing the window
	if (isTauri) {
		const { getCurrentWindow } = await import("@tauri-apps/api/window");
		const win = getCurrentWindow();
		await win.show();
		await win.setFocus();
	}
	//...code to execute after window is done showing
};

8. window blur/vibrancy

On MacOS and Windows, it's relatively easy to achieve blur behind sidebars in Tauri with the window-vibrancy plugin. Vibrancy is possible on Linux desktops too, though on Linux, the compositor is what applies the effect, not the application itself, and only certain compositors support blur (i.e. kwin).

Here's a snippet from my app, though I'd recommend reading the full documentation:

use window_vibrancy::*;

// macos vibrancy (using sidebar material)
#[cfg(target_os = "macos")]
apply_vibrancy(&window, NSVisualEffectMaterial::Sidebar, None, None)
	.expect("unsupported platform! 'apply_vibrancy' is only supported on macOS");

// windows vibrancy (using mica material)
#[cfg(target_os = "windows")]
apply_mica(&window, None)
	.expect("unsupported platform! 'apply_mica' is only supported on Windows 11");

You will need to enable transparency in the Tauri window builder. After that, make sure to set the body's background-color to transparent so that you can actually see through the app, and then apply opaque colors to the main app section (in this case the song queue), leaving the sidebar transparent.

let window = WebviewWindowBuilder::new((app, "main".to_string(), WebviewUrl::External(url)))
	.title("tinysub")
	.transparent(true) // needed to see window-vibrancy effect
	//...other window properties

body {
	background: transparent;
}

#queue {
	background: Canvas;
}

This effect can really help make your app feel more consistent with the rest of the system, though I'd recommend making transparency configurable for Linux users who don't have a compositor that supports blur. And then that gives you this beautiful transparency effect:

9. styling tips

In tinysub I often used some OS-specific styling, such as a different color for the sidebar/titlebar borders to match native MacOS apps. I also used custom colors for item selection on MacOS. Tiny tweaks like these can make a big difference in how your app feels, even if the user doesn't notice it.

In a lot of cases I actually just avoided hard-coded colors entirely unless where necessary. Instead I opted to utilize the CSS <system-color> type for various colors, and the color-scheme property for light/dark mode. It can be a lot simpler to write this way and also look more consistent with other applications, unless you have specific colors in mind for your brand.

10: other tricks

For even more tricks on making your app feel native, this article by Vadim Demedes is a great resource. I just wrote this article to add on some other ideas too.

ending notes

Apologies if this article is a little sloppy, these were just notes that I personally wrote for myself while developing tinysub. Hopefully it was useful to you or informational in any way. If you have any suggestions, let me know in the comments and I'll edit the article accordingly.

[^1]: When I am referring to "a native look on MacOS", I am specifically referring to pre-Tahoe design. I don't intend on implementing Liquid Glass elements into my app as it's tricky to do in CSS, would be far too heavy, and I am personally not a fan of it regardless. However, the Cupertino theme for Obsidian does an excellent job on emulating the MacOS Tahoe design if you'd like to see an example of that.

the blog is up

Mon, 23 Jun 2025 00:00:00 GMT

I know this website may look very dull - I like it, and I believe that it works fine. I'll probably be implementing a theme switcher at some point for anyone that likes catppuccin or other themes.