Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)A
Posts
6
Comments
5
Joined
2 yr. ago

  • Yoink! New project logo haha ;P

  • Great question! I considered that, it's what lead me to the idea to use DNS in the first place. The problem I had with that is that the ultimate URL path might change, not just the hostname. What happens if a repo has to move from github.com/org/repo to mycoolforge.net/repo?

    But there's also another reason that I realized as I was working out the details of git-remote-helpers: What happens if your remote needs to change protocols? With doink you can swap from http(s) to ftp with an ip address instead of a hostname, or perhaps even some (future) git-over-whatever-p2p-network.

    So yeah if you're swapping from a github-style forge to another github-style forge and you don't need the flexibility, you definitely could just CNAME it! And that would probably be more robust, but it would also give you less future flexibility :P

  • It is now lol

    I'm bad at naming things, so it was originally GHA (for github archiver, changed to good helpful archiver because trademark), but I kept misspelling it as GAH so it was just easier to change the name.

    But the reference is way better :P

  • Opensource @programming.dev

    GAH - turn your github repos into static sites

    git.sr.ht /~absolutely-vivid/gah
  • Programming @programming.dev

    GAH - turn your github repos into static sites

    git.sr.ht /~absolutely-vivid/gah
  • Rust @programming.dev

    Introducing RPGCPF - A Toolkit for GCPF Compression

    absolutely-vivid.srht.site /blog/introducing-rpgcpf
  • Oh hi, I forgot to reply to this!

    My reasoning was mostly "I read it somewhere when I started coding and then didn't do much with threads" to be honest. Not great reasoning there. But modeling the interactions between a user, UI thread, and work thread made it a lot easier to organize my code and create a good separation of concerns; the UI thread handles interface updates and dispatching events, and the worker thread works. Honestly that code organization was the biggest advantage I got out of doing things this way, and I wish I'd emphasized that more in the blog post.

  • Rust @programming.dev

    Building a Multithreaded TUI With Rust and Cursive

    absolutely-vivid.srht.site /blog/multithreaded-tui-with-rust