I made a stopwatch crate for Rust. This exists because I added an existing stopwatch crate to a project and my cargo.lock had a bunch of unnecessary new entries due to dependencies so I wrote one in pure Rust.

I will not be posting it on crates.io for several reasons:

• Name collision with stopwatch
• Supply chain attacks are a thing and people need to stop relying on centralised distribution
• Git is always up-to-date, and you can choose a version from a commit hash

Usage is simple

let mut stopwatch = Stopwatch::new();

stopwatch.start();

// Do a long running task
std::thread::sleep(Duration::from_secs(5));

stopwatch.stop();

println!("Operation complete in: {}", stopwatch);

Source and complete instructions are available in the git repository

Surprisingly enough (even to me), the license is CC0.

Email me with any bugs. :)

Wrapping up 2023, I'm taking a look at the projects I've done or worked on and things that I've learned this year.

LiveJrnl

LiveJrnl was the original iteration of this blog. It started out as a journal written with jrnl.sh. I found this project that would display the journal as a website and was absolutely in love with the idea, with one caveat. The javascript. Those who know me know that I have no love for javascript. I don't even want it in my desktop applications if I can help it. Using that was off the table, so that brings me to LiveJrnl.

The first version of LiveJrnl was written in Python. It was published on my former GitHub account, under my dead-username. For a fleeting moment, it served its purpose. All of my posts, on one page. Easily indexed, easily searched. Have I achieved perfection? It sure felt like it.

Being in the middle of a move, I wanted to be able to write on my tablet or laptop, so I eventually moved towards using Obsidian for writing. I know, I know, its not open source, and its javascript backed... more on that later in another post... From there, LiveJrnl kind of outgrew itself. Before long, I was stitching together journal entries written in Obsidian to append to the jrnl journal. That worked for a while, then I wanted to be able to edit new articles from Obsidian. That led to writing a one-off Python script to chop up the jrnl journal into individual entries, and I would just use jrnl to search my posts offline. After a certain number of posts, the posts page became a bit long and it started to take a while to render the website.

Of course, I was also learning Rust at the time (still am, really), and what better way to learn a language than to re-implement something you've already done before? Enter, livejrnl-rs. I learned a good amount of Rust with that project. It was eye-opening how simple the language can be, even though it is ugly as fuck. I finished that, and still had the same limitations as the Python version. There was no pagination, and the posts page was long. I couldn't figure out how I wanted to export the pages, and eventually landed on using Zola for a static site generator. One quick one-off Python script later, and I had my LiveJrnl posts imported.

With that said, LiveJrnl and livejrnl-rs (and their respective template repos) are both considered abandoned. If you, my dear reader, find a bug, let me know and I will fix it for you if its serious enough.

Bitwarden SSH Agent

Sometime in July I started writing a Rust port of bitwarden-ssh-agent. The link to the Rust version can be found here. At the time of writing, commit ce3b075b9b195ee5ee5a1ec8c9784cf076592e84 is the latest version. It is at 1:1 feature parity with the original, with some personal changes.

As is, the project is functional and complete. There is one unresolvable bug, such as getting stuck in a login loop if BW_SESSION is invalid. I may revisit this in the future to fix that if I can ever figure it out. At the moment I would rather re-write the thing from scratch, using the Bitwarden API itself.

Unnamed First Person Shooter

Between January and August I would work on-and-off on an unnamed FPS in Godot. The graphics were a bit primitive, and were originally made in both MagicaVoxel and Blockbench. I eventually learned how to model in Blender to make better assets. I have not yet published that, as I don't exactly know how to license the assets in way that prevents certain people (see also: evil commercial interests) from downloading, compiling, and selling the game without any modifications. From my understanding, AGPL doesn't cover media. I also don't have any sort of git history, as bouts of working on it came from intense hyperfocus sessions.

What works:

• Day/night cycle
• Lifts/moving platforms
• Sliding doors
• Door keys
• Quake 3 style movement
• Aiming
• Shooting
• Reloading
• Weapon pickups
• Jump pads
• TrenchBroom map loading
• Menu system
• Dialogue system
• Themed GUI elements

What needs refactoring:

• See all of the above

What's missing:

• Enemies
• Vendors
• Swimming
• Portals
• Mirrors
• A story
• Level design of any kind
• Speed boost pads
• An actual art direction

Do I have plans for this project? Yes and no. My Obsidian notebook has several ideas written down, nothing concrete. I may turn this into an RPG instead. A boomer shooter RPG sounds pretty good, to be honest. It would give the speedrunners and minmaxers something to do.

From this project, I've learned that I'm capable of writing modular code. Most of the components in the game can be reused in other games after a slight refactoring. I'd say that went fairly well and is worth a revisit.

sparkle-git

This is probably my favourite project of the year. sparkle-git is my soft-fork of rgit where I'm adding features, and will eventually migrate towards a fully self-hosted git solution.

Throughout this project I have learned how:

• git can be manipulated
• git http-backend works
• to document rust code with proper docstrings
• to write my own dockerfiles with multistage build and caching (IN PROGRESS)
• to write man pages
• to work with pandoc
• to work with axum
• to use git format-patch
• to write a PKGBUILD
• to determine if a rust crate is the real deal or a typosquat
• to work with Pipelight

Link to the repository

Final Thoughts

All in all, it was a productive year for code. I wonder what 2024 will bring. 💖

This post is inspired by a Fediverse post I read a while back about someone deleting a patch that they wrote and wanted to publish but couldn't because of a real name policy. I understand the desire for real name policies. I don't agree with the reasoning. Privacy is a big concern, especially in this ever-growing dystopian hellscape that we (developers) have helped Big Tech create. I unfortunately lost the link, as Blahaj Zone doesn't seem to have a way for me to search only things that I starred. When I come across it again, I will edit this post.

Git is decentralised and semi-private by design. Anyone can create PATCH files and contribute to a repository without an account. Anyone can create a git repository and share it with the world. Real names should not matter, as long as your GPG key is intact and your commits are signed. Ideally, your key will also be registered with various keyservers and published on your own website in order to establish a chain of trust. Your key is your identity, as well as your reputation.

In addition to real name policies, git users are seemingly migrating towards a centralised approach. Long gone are the days of public mailing lists that anyone could (un)subscribe to at any time with an email address and nothing else. Everything today is seemingly on GitHub (and derivatives) where one must make an account and accept a privacy policy on top of a license agreement on a centralised server. Repositories are also subject to content moderation policies set by the server operator(s). There's also the issue of DMCA takedowns that shouldn't even impact open-source code to begin with. This does not look like decentralisation, openness, or freedom to me.

Sure, there are alternative providers, and even self-hosted GitHub-like solutions such as Gitea and Forgejo (which Codeberg uses), or even SourceHut for those who want a more classical design. Those solutions still have the same fundamental issue - to contribute to a repository, one must make an account. Forgejo is in the process of implementing federation, which is a huge step in the right direction. I'm not sure how transferring servers would work. It is worth keeping an eye on.

With that said, as part of my continued commitment to decentralisation, I'm returning to the days of yore and using plain bare git repositories on a server and a soft fork of rgit to serve them to the public. You can see that in action here. It isn't perfect, but it works for me. I've already submitted a patch to upstream to fix a Docker container issue and it was a rather pleasant process.

There are a few things I'm missing as a whole, like HTTPS cloning, an issue tracker, the ability to download a tarball of the active branch, and custom themes. The frontend does have support for showing release tags, but the download links do not generate. Those are things I will be attempting to fix and submit to upstream as I become more comfortable with the codebase.

In my research, I found this helpful post by Simon Willison, which may lead me in the right direction to produce the tarballs. This gitweb-theme by kogakure has helped me to produce a CSS-only theme for rgit. There are several things that need to be adjusted at the template level before I am ready to publish that.

In the end, I'm hoping to have a setup that is a simple and modern take on an older system that can be deployed as a single container.

I'm thinking about how to implement a search engine for this website. Since I rent the server from Hetzner and manage the OS and all software packages, I have a bit of freedom when it comes to my tech stack.

My requirements:

• Server side
• Fast
• No javascript whatsoever

What about tinysearch? It ticks all of the boxes except for javascript.

So how am I going to do this? Here are the technical specs for this site:

Static Site Generator: Zola
Web Server: Static Web Server
Git Web: rgit / GitHub mirror
Reverse Proxy: Caddy Docker Proxy

With that in said, almost my entire software stack is Rust-based. I almost think that I can create a server application that can utilize Zola's search index and render the results in realtime using Tide and Tera, without javascript. I really hate javascript... If I can do that, I can then create a /search slug and use the reverse proxy to forward traffic to the application.

I need to think about this.

A while back, I found a neat little tool called broot which is a TUI file manager written in Rust. It claims to be a better way to navigate directories, and I find that claim to be quite the understatement.

When I had the data loss scenario, I copied everything that I could to a directory on the host drive. What I didn't do was copy everything to the data volumes, as I suspended my use of several services. I sort of left the directory intact and forgot about it until Pi-Hole started complaining about insufficient space for log files. On my desktop, I use Disk Usage Analyzer, however that is a GUI application. There is the du for terminal use, and that is just... No.

Since I had started to learn Rust, I figured I could write something. I searched for "rust sort directory by size" and my life changed forever when broot came across my radar. After poking around a bit, I found a launch argument and so...

broot --sort-by-size ~/recovery

...gave me everything I wanted. I went up and down the tree, pressing space bar to enter verb mode, and then rm to remove directories I had already copied. After a few minutes, I recovered over 450 GB of drive space.

I probably could have done that with ranger, but c'mon its 2023. It's haute-coture to use Rust for everything. What does that have to do with Docker you may ask? Well, I just mentioned a "verb". A verb is, aptly put, a command. broot lets me add custom verbs.

Since that server is only used as a Docker host, and I'm constantly messing around with the containers, I decided to do a bit of automation in regards to Docker and the containers. My frequent tasks are:

• Updating containers
• (Re)starting and stopping containers
• Testing new containers

I came up with a few commands to speed up the process, so that I can browse up and down the tree in broot, not having to worry about entering directories, getting paths right, and all of that.

{
    name: Bring up Docker container
    invocation: compose
    execution: "docker compose -f {file} up -d"
    apply_to: file
    leave_broot: false
}
{
    name: Test Docker container
    invocation: test
    execution: "docker compose -f {file} up"
    apply_to: file
    leave_broot: false
}
{
    name: Start Docker container
    invocation: start
    execution: "docker compose -f {file} start"
    apply_to: file
    leave_broot: false
}
{
    name: Stop Docker container
    invocation: stop
    execution: "docker compose -f {file} stop"
    apply_to: file
    leave_broot: false
}
{
    name: Restart Docker container
    invocation: restart
    execution: "docker compose -f {file} restart"
    apply_to: file
    leave_broot: false
}

You will notice that a verb for docker compose -f {file} down is not present, nor is there a verb to update the container images. I simply don't trust myself. I prefer to remove the containers, volumes, images, and networks manually, with their respective commands. As for the updating containers? if you use :latest, FOR SHAME.

I've come to realise that while Zola is almost exactly what I am looking for in a site generator, some things are slightly too hard-coded. Such as Taxonomy pages. I would love for the slugs to be at /blog/tags/tag but it can never be. 😢 As a result, my template needs quite a bit of refactoring, which I'm happy to do after I check this whole thing into git.

I really don't want to have to move my blog outside of the /blog/ directory. Since I have the tags on the blog and individual tag pages in the header, I will redirect the /tags/ slug to a 404 template, or maybe 403. I think 404 is a bit cleaner.

I've been feeling like I'm hitting limitations on berrygen's capabilities. For example, I was unable to generate a feed of posts without manually making the links in a Markdown document. Since the requirements are so rigid, I think that my only way forward was to use a batch script to pipe the output file back into itself repeatedly. At the time of writing, there are 48 (now 49!) entries on this site. That would mean I need to process the same file 49 times, appending a shortcode at the end for the next post to render.

Once that was done, there was still the case of pagination. I had no access to the collection of objects without first generating a page with a collection of objects, and then using that as a source for the next pass, which eventually brought my project out of scope. That means only one thing. My implementation was far too inefficient and unwieldy.

In my search for a decent static-site generator using only Rust, I found Zola, which is powered by Tera. Some initial tests using my existing template were rather successful since Tera is inspired by Jinja2, and I was using minijinja in berrygen. There were some errors related to shortcodes, and the output was almost identical, with mine being cleanly formatted. The frontmatter (or grey-matter, in my case) needed adjusting, and I had to import the entries from jrnl and process those as individual files. Zola also allows me to use extra frontmatter that isn't serialized to a struct. I couldn't figure out how to implement that in my own implementation without crashes or forcing the user into an extremely tight box, even when parsing the extra frontmatter as a HashMap.

Once I had my posts formatted and exported from jrnl, Zola just worked. I don't mean it just worked, it worked even after deviating from the "Getting Started" guide and immediately jumping into making my own template, unlike Hugo, which had a gosh-darn stroke out of the box without any sort of helpful error messages. I discovered that sometime in June when I was helping a good friend setup his art portfolio.

All in all, this whole thing was a learning experience. Not every project will be a success, nor will every project get finished or published "because it needs to be".

Good morning! I'm working on something called berrygen. It is a Rust application that generates static websites, utilising most of the code from livejrnl-rs. It is yet again powered by minijinja under the hood.

In its current form, this website is being generated from Markdown files in a directory. Each file is passed to berrygen using a shell script to loop through the files in the directory. There is no support for jrnl and there will not be. I am dropping jrnl support because I write most of my entries in Obsidian. When the time comes, I will be writing an exporter to export the jrnl files to be used with berrygen.

Any posts before this one will be from the import. I will publish the source when it is in a state to be shared.

No one writes good man¹ pages anymore, myself included.

What is a man page? For the young and uninitiated, it is short for manual page. They are The Sacred Texts of the digital world. They can tell you exactly how to use a program and it works anytime, anywhere, even offline, in your terminal.

To get started, type man man and enjoy your new adventure.

Welcome back. I was looking at cargo --help today and was thinking about how much cleaner it would be if man cargo had this information instead of it all being in the command-line help.

~ ❯ cargo --help
Rust's package manager

Usage: cargo [+toolchain] [OPTIONS] [COMMAND]

Options:
  -V, --version             Print version info and exit
      --list                List installed commands
      --explain <CODE>      Run `rustc --explain CODE`
  -v, --verbose...          Use verbose output (-vv very verbose/build.rs output)
  -q, --quiet               Do not print cargo log messages
      --color <WHEN>        Coloring: auto, always, never
  -C <DIRECTORY>            Change to DIRECTORY before doing anything (nightly-only)
      --frozen              Require Cargo.lock and cache are up to date
      --locked              Require Cargo.lock is up to date
      --offline             Run without accessing the network
      --config <KEY=VALUE>  Override a configuration value
  -Z <FLAG>                 Unstable (nightly-only) flags to Cargo, see 'cargo -Z help' for details
  -h, --help                Print help

Some common cargo commands are (see all commands with --list):
    build, b    Compile the current package
    check, c    Analyze the current package and report errors, but don't build object files
    clean       Remove the target directory
    doc, d      Build this package's and its dependencies' documentation
    new         Create a new cargo package
    init        Create a new cargo package in an existing directory
    add         Add dependencies to a manifest file
    remove      Remove dependencies from a manifest file
    run, r      Run a binary or example of the local package
    test, t     Run the tests
    bench       Run the benchmarks
    update      Update dependencies listed in Cargo.lock
    search      Search registry for crates
    publish     Package and upload this package to the registry
    install     Install a Rust binary. Default location is $HOME/.cargo/bin
    uninstall   Uninstall a Rust binary

See 'cargo help <command>' for more information on a specific command.

A well-written man page would present this without needing extra command line flags (--list or cargo <command> --help), and also without the user needing to scroll up to read the available options. A well-written man page would allow for far greater flexibility in documenting the individual switches and commands, with the ability to provide usage examples, a more in-depth description of each option, and provide recommended defaults (if any).

Since my favourite markup language is Markdown, I did some searching to see how I could create man pages with Markdown and stumbled upon a blog article by Brandon Rozek that utilises Pandoc and also this article by Lars Wirzenius on how to write them by hand without Markdown.

Armed with this knowledge, I'm going to create man pages for my existing projects. I think I will go the Pandoc route. I can't wait! 💖

footnotes

Since it has been a while since my last post, and I effectively moved my old identity into "dead name" territory, I will re-introduce myself. My name is Holly Sparkles. For the most part, I go by hollyberries. My username is 25% a homage to a friend (navyberries, rest in peace), 50% because of Holly in Red Dwarf, and 25% because like a holly bush, I'm sometimes prickly and also have berries.

My name is also pseudonym, and it will remain that way. I am a huge believer in digital privacy so I will keep identifiable information as vague possible in my posts.

My mission? Privacy, free software and freedom of information for every human being as a fundamental right.

“Information is power. But like all power, there are those who want to keep it for themselves.”
― Aaron Swartz

I entered the fight for digital freedom in 1999 when I was petitioning for Napster and later petitioning my school to adopt Mandrake Linux instead of Windows. Neither endeavour was successful, and yet its been almost 25 years and I haven't stopped fighting. I'm not gonna. 💋

It's been... a while, hasn't it? I didn't die or anything. I've been pretty busy with the move and not really being able to catch my breath and put down my feelings. On one hand, I feel a lot better mentally now that we're starting to get settled in and I'm not being viciously attacked by one pile of mess after another from the very moment I step foot into my home... On the other, I haven't had a chance to truly relax, you know? Like, at the moment I'm sitting in my little computer corner with a box of stuff that needs to be put away and my LED curtain on the floor for some sort of ambient light.

Back to the mental health thing. Things haven't exactly been going to plan as of late, and I've kind of sort of gone with the flow without too much trouble, and that is a feat. I forgot my keyboard, so I'm using a terrible Logitech membrane, the LAN server decided to give me the middle finger (more on that later), I forgot one of my monitor power supplies, and also forgot the power cable to the server, it was a bunch of bumps. That sentence went on for a long time. Whatever. You figure it out.

SOOOOooo... The LAN server kind of bit the dust thanks to NVIDIA fucking up their Linux drivers again. To make a long story short, the kernel was unsupported, I couldn't even upgrade the kernel without uninstalling NVIDIA, and all of that resulted in a server not being able to boot. I decided it was time to grow up and stop using Arch based distros for a server. Back to good ol' Debian that hasn't fucked me in any way other than having a docker-compose package that couldn't do compose v3 files. I liked Manjaro, and daily drive Garuda on my desktop, but JFC having to stay on top of updates like it is my religion is extremely tedious.

It's taken me about a week to get the server back up and running again, and I couldn't have done it without Storj DCS. I wrote a little bit about my server backup system in this post and I'm happy to say that in spite of some hiccups, the restore was largely successful. I identified some flaws in my backup system, and will be fixing them going forward. I'll be talking about those in this post.

One of the major flaws was that I needed to use Duplicati to restore the server configs because I used Duplicati to backup the server configs. Stack overflow yet? It was a bit of an annoyance to download the config archives manually from the bucket using a web browser, and then use a temporary Duplicati instance to extract the backup. From there I was able to restore They're now hosted on a private GitLab repo. It isn't ideal, but it is the best solution I have at the moment. If I had a job, I'd be paying for a VPS. A VPS also wouldn't have gone to sleep in the middle of the restore process. I had to do the whole thing twice to make sure I got everything.

Another one of the major flaws was that Duplicati did not save dotfiles. I was unable to bring back the Minecraft server and the File Browser instance. I kept the Minecraft world files, and may be able to repair them by opening them in single player. I will have to test that theory. As for the File Browser instance, I replaced it with Pure-ftpd which allowed me to mount individual data directories so that I can upload directly rather than upload to File Browser, and then copy the files from within via SSH.

...I'm aware I have a lot of manual stuff going on here. I really don't care. I'm very particular about how I do things, and this is how I'm doing it, so theeeeere. Mwah.

The good news is, my data directories and my host OS are on completely separate drives, so any OS issues going forward will not affect me in any way.

In the non-tech sphere, I've been playing a lot of bit of Disney Dreamlight Valley and just absolutely love it. I love it so much that I've commissioned a profile picture from my dear friend Maru that just... looks like me and I'm in freaking love with it and can't wait to use it on every platform that I'm actually active on.

Anyway, I'm going to cut this short and this sentence serves as a note to myself to continue the post in the morning. 💖

🎵 Music: Nirvana - Something In The Way

Hello there, I'm back from the new apartment for a few days. I brought my laptop but forgot to install and setup the journaling toolchain before leaving. I could have written on my iPad, but I really really hate the iPad keyboard, and typing out posts via touch is just atrocious. Instead, I took the time to relax, take in my new surroundings, and just be.

It didn't really work at first. I had a massive inflammation flare-up in my left foot that left me pretty much crippled for the first two days. That affected my mood big-time. Once I was able to move again, my mood quickly improved.

That's where the fun began.

Every morning from that point on, I started my day with a cup of coffee and an hour of YouTube videos and reading news. I walked S to the train station, at 08:00 and then walked from the station to the river, and around back to the apartment. Afterwards, I cleaned. I dusted, swept the floors, and washed the dishes.

At noon I would workout. It was a combination of yoga and the exercises given to me by my physiotherapist. I felt amazing after each workout. Also tired. My foot would stop hurting halfway into my workout, which felt amazing. I really needed that.

After the workout, I'd have ramen for lunch. It wasn't very healthy, but it was cheap. Money is kind of tight right now (I have an addiction to spending money on stupid shit like makeup and fashion like a dumbass) so I decided to cut back on my food spending. #priorities.

Around late afternoon, S was on her way home. I went to the grocery store to pick up stuff we needed for dinner and the household, and then I met S at the train station.

After we got home, we ate dinner. Over the course of the week we watched Secrets of the Whales, Django Unchained, Extremely Wicked, Shockingly Evil and Vile, and we started to watch The Rings of Power. The LOTR show was alright, but not my cup of tea. I could not help but continue watching, though. I think it was just morbid curiosity of how much more I could tolerate.

Friday came and then it was time to go home.

We came back home last night to finish packing. The official move in date is the first of March, so we've got a little bit over a week to get this stuff done. I really should be packing, but I kind of wanted to write down my thoughts and chronicle my adventures a little bit more. It really is time to get back to work though.

I'll come back in a little bit ta-ta for now, lovelies. ❤️

🎵 Music: Silverchair - Madman

This is my attempt at actually getting images working. I initially planned on base64-encoding the images like I do with the template, except that if I wanted to reuse the images in other posts, it would be kind of ridiculous and not efficient.

The plan is to attach things in Obsidian, and then have the build script copy the images to the output directory. I just have to ensure that I change the image link format from something that Obsidian uses to something that Markdown uses. I could use Markdown style links throughout Obsidian, but seeing as I also write stories and cross reference notes with one another quite often, I prefer to keep the Wiki styled links.

Anyway. Let's try this. This is my current profile picture on Mastodon. I made it myself in Inkscape. 😄

It looks like like it works, but of course I'll need to style it with CSS. I'm excited about this. 😄

Edit: (2023-02-11 12:55) I've decided on a max-width of 95% and have the images centered with a border since I'm mainly going to use them as figure diagrams or to share screenshots in my posts.

Huh! I was about to upload the latest post, and got this when I went to Neocities

Neocities is temporarily unavailable

Neocities is currently undergoing maintenance (or is experiencing an outage), we will be back shortly! Check @neocities for status updates.

Our apologies for the inconvenience.

At the time of writing, the Twitter hasn't been updated. The public version of this journal is still online. I see they have a semi competent backend team. That's refreshing.

Anyway, I'm off to do some stuff until this gets resolved. Until then, these posts remain... IN LIMBO!!!

🎵 Music: Nirvana - Plateau

Today, I had the desire to make my Obsidian a little more accessible to me when I'm not home.

Up until an hour ago, I was only able to sync between my devices if I was at home and connected to my LAN. I used to backup Obsidian using the Remotely Save plugin connected to my Nextcloud server via WebDAV. Since I'm paranoid, this server is inaccessible from outside of the LAN. This is normally a non-issue for me as I don't usually travel a lot and phone home pretty much daily. Now that I'm travelling between where I live now and (staying at) the new apartment quite often, I needed a better sync solution.

I was fully prepared to fork over some money for a VPS just to be able to have WebDAV. Then I remembered: that same Nextcloud server has been backed up monthly for almost a year now using Duplicati connected to a Storj DCS instance. Storj DCS has an Amazon S3 compatibility layer. Remotely Save has support for S3 compatible services. See where I'm going with this?

Switching everything over in Remotely Save was as easy as 1-2-3. There is even an option to export settings as a QR code. On my iPhone and iPad I scanned the QR with the Camera app, and opened the link in Obsidian. Obsidian gave me a notification that settings were imported and I needed to restart. Restart, sync, done. It was that easy.

Now ya girl can write on the go! I just need to figure out a way to build the journal (...and then we will be ready to take over the world!) Muahahahahahah.