initial commit

comp/capslock.gmi

@@ -0,0 +1,78 @@
+# Making the CapsLock Key More Useful
+The CapsLock key is one of the most useless keys on the keyboard for me, yet placed in the single best place a non-letter key could be placed. It's an obvious candidate for people looking to improve their keyboard layout.
+
+I often heard people saying they rebound it to control or escape, which both sounded equally good to me, so I was never sure which to use. Then I heard someone mention that they use the key for BOTH at once. You press it and get the escape key, and hold it to get the control key. This sounded perfect, and is now in fact my single most-used key rebinding, to the point where I feel helpless when on a system without it.
+
+Originally, I used some odd X11-specific software to achieve the rebind, but it was really flaky, and, of course, didn't work in a TTY or on Wayland. I then switched to interception-tools with the dual-function-keys plugin, but it's Linux-specific, and I couldn't even get it working on Gentoo, but it worked flawlessly on Arch.
+
+## Keyd
+Nowadays I use a piece of software called keyd. Its super simple, works on X11, TTY, and Wayland, and works* on FreeBSD.
+=> https://github.com/rvaiya/keyd Keyd Github
+
+> *On FreeBSD, it currently locks your input in a TTY, so it really only works on X11 and Wayland.
+
+### Configuration
+The configuration file goes in /etc/keyd/default.conf. Its capable of a lot of things, which you can find in its documentation, but this particular rebind is incredibly simple:
+```
+[ids]
+*
+
+[main]
+capslock = overload(control, esc)
+```
+
+### Starting the Daemon
+Now you just need to start the daemon. It comes with a systemd service file out of the box, so nothing special is needed there.
+
+On systems running OpenRC, such as Gentoo, I recommend using the service file written in this blog post:
+=> https://technex.us/2024/07/keyd-on-gentoo-with-openrc-and-kde-plasma/ Keyd on Gentoo with OpenRC and KDE Plasma
+
+For convenience, I'll paste the script here. It should be put into /etc/init.d/keyd:
+```
+#!/sbin/openrc-run
+
+# Description of the service
+description="keyd key remapping daemon"
+
+# The location of the keyd binary
+command="/usr/local/bin/keyd"
+#command_args="-d"
+pidfile="/run/keyd.pid"
+
+depend() {
+    need localmount
+    after bootmisc
+}
+
+start() {
+    ebegin "Starting keyd"
+    start-stop-daemon --start --exec $command --background --user root  --make-pidfile --pidfile $pidfile --
+    eend $?
+}
+
+stop() {
+    ebegin "Stopping keyd"
+    start-stop-daemon --stop --pidfile $pidfile
+    eend $?
+}
+
+restart() {
+    ebegin "Restarting keyd"
+    start
+    eend $?
+}
+```
+
+Once you have that, you can start and enable the daemon like any other.
+
+FreeBSD has a service script built-in, but, as mentioned earlier, keyd on FreeBSD doesn't work in a TTY, so I actually just recommend starting keyd with your window manager. Note that you have to run it as root, though. I put the following into my /etc/doas.conf to let me run it without a password:
+```
+permit nopass :wheel cmd keyd
+```
+
+## Caveats
+I find keyd to work great for my use-case, but I have noticed some caveats. Of course, there's the big one with FreeBSD, which does suck, but I don't use a TTY often enough to be too annoyed.
+
+Another caveat is that it isn't particularly good at Unicode. It seems to emit Unicode characters as macros, using a really hacky solution, and I never actually managed to get it working. Github issues suggest that even when it does work, Wayland users still can't do it in Electron apps. Not that I use Electron anymore, but it's still something to look out for.
+
+These caveats are fine with me, but I could see them being deal-breakers for others, so do be aware of them. There're plenty of alternatives, like interception-tools/dual-function-keys, or kmodmap, which can achieve the same thing.

comp/dotfiles-rob-pike.gmi

@@ -0,0 +1,31 @@
+# Rob Pike on Dotfiles
+Rob Pike, 2012-08-02
+=> https://plus.google.com/101960720994009339267/posts/R58WgWwN9jp Original post
+=> https://web.archive.org/web/20190317000040/https://plus.google.com/101960720994009339267/posts/R58WgWwN9jp Original post (Wayback Machine archive)
+
+## Post Text
+A lesson in shortcuts.
+
+Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. I'm not sure but I believe .. went in during the Version 2 rewrite, when the file system became hierarchical (it had a very different structure early on).  When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to the program. It was in assembler then, but the code in question was equivalent to something like this:
+```
+    if (name[0] == '.') continue;
+```
+This statement was a little shorter than what it should have been, which is
+```
+    if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;
+```
+but hey, it was easy.
+
+Two things resulted.
+
+First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted.
+
+Second, and much worse, the idea of a "hidden" or "dot" file was created. As a consequence, more lazy programmers started dropping files into everyone's home directory. I don't have all that much stuff installed on the machine I'm using to type this, but my home directory has about a hundred dot files and I don't even know what most of them are or whether they're still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge.
+
+I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.
+
+How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design) have resulted from that one small shortcut about  40 years ago?
+
+Keep that in mind next time you want to cut a corner in your code.
+
+(For those who object that dot files serve a purpose, I don't dispute that but counter that it's the files that serve the purpose, not the convention for their names. They could just as easily be in $HOME/cfg or $HOME/lib, which is what we did in Plan 9, which had no dot files. Lessons can be learned.)

comp/hier7.gmi

@@ -0,0 +1,156 @@
+# Regarding hier(7) in $HOME
+
+Taking a look at hier(7) is a valuable way to understand how your Unix-like system is structured. It tells you exactly what each directory on your filesystem does, so you always know exactly where to put system files.
+
+## The Hierarchy for System Files
+Taking a look at the overall structure, you may notice that a lot of directory names seem to be repeated, but in different locations. You'll also notice that these directories seem to be structured roughly the same way the / directory is. For example, you have /bin/, /usr/bin/, and /usr/local/bin/.
+
+On my Arch Linux install, according to hier(7):
+* / is for critical utilities required to boot and repair the system
+* /usr/ is the main place system files get installed to, including all of the programs installed by the package manager
+* /usr/local/, to my understanding, is where you'd place system files that you compiled and installed manually, rather than using the package manager
+=> https://man.archlinux.org/man/hier.7 View Arch Linux's hier(7) online
+
+On FreeBSD, according to hier(7), the equivalent directories are as follows:
+* / is essentially the same as on Arch Linux
+* /usr/ seems to be for core operating system files that aren't required for boot or repair
+* /usr/local/ is for system files not part of the core operating system, such as package files or locally-compiled programs
+=> https://man.freebsd.org/cgi/man.cgi?hier(7) View FreeBSD's hier(7) online
+
+As you can see, there seem to be three separate ""root"" directories, each one with a specific purpose. However, these aren't the only three directories that seem to be root directories. The /root/ and /home/$USER/ directories, which act as user home directories, ALSO seem to be root directories, but its nearly impossible to tell at first, because they use an entirely different set of directories.
+
+## The Hierarchy for User Files
+The user's home directory follows its own hierarchy conventions completely unlike any of the aforementioned system tree hierarchies. Even worse, the home directory makes extensive use of dotfiles, which are an unintended bug that's most often leveraged by lazy programmers who don't want to learn how the system they're programming on works.
+=> dotfiles-rob-pike.gmi Rob Pike on Dotfiles
+
+The home directory tree as compared to the system tree:
+* ~/.config/, as opposed to /etc/
+* ~/.cache/, as opposed to /var/cache/
+* ~/.local/bin/, as opposed to /bin/
+* ~/.local/share/, as opposed to /share/
+* ~/.local/state/, as opposed to /var/lib/
+=> https://specifications.freedesktop.org/basedir-spec/latest/ XDG Base Directory Specification
+
+As you can see, the user's home directory has all of the same data as any of the system trees, but with completely different names, all leveraging the dotfile bug. Perhaps I would've been fine if the files made use of the usual names, but were all placed in ~/.local/, because then it'd just mean the tree root isn't at ~/, but at ~/.local/, but this isn't the case.
+
+Even worse, even though all of these directories can be moved using $XDG_*_HOME variables, an incredible number of programs completely ignore the XDG Base Directory Specification, and hardcode the path, or place their files straight into ~/, completely ignoring any standard directories, with no possible way to change it. Some of these programs think they're so special that they even refuse to consider this a bug, like OpenSSH with ~/.ssh/.
+=> https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded Arch Wiki's list of hardcoded dotfiles
+=> https://web.archive.org/web/20190925004614/https://bugzilla.mindrot.org/show_bug.cgi?id=2050 OpenSSH bug report
+
+To finish off talking about the home directory tree, we can't forget to mention the XDG User Directories:
+* ~/Downloads/
+* ~/Desktop/
+* ~/Documents/
+* ~/Music/
+* ~/Pictures/
+* ~/Public
+* ~/Templates/
+* ~/Videos/
+=> https://wiki.archlinux.org/title/XDG_user_directories Arch Wiki's page on XDG User Directories
+
+Honestly, other than the fact that they use capital letters, which is a personal preference thing, I can't really complain about these. I'd prefer them somewhere else, but the xdg-user-dirs tool combined with $XDG_CONFIG_HOME/user-dirs.dirs lets me move and rename them, which most programs do actually seem to respect.
+
+The main point here is that system files have THREE locations that have the exact same directory structure, but user files aren't the same. You can't leverage existing knowledge to know where to put user files, and programs have to handle user files as an entirely separate case from system files. The directory structure CAN be changed, but not all programs respect those changes, and some completely ignore the structure to begin with, which seems to be caused predominantly due to a specific bug allowing lazy programs to shove files wherever they want with the knowledge that those files will be ""hidden"" and thus not a bother.
+
+## My Current Home Directory Setup
+With all this said, I decided to make use of what I could in order to make my home directory mimic the structure of the system trees, as well as to stop making use of dotfiles as hidden directories.
+
+### Unhiding Dotfiles
+This one was pretty simple. All I really had to do is add to my ~/.shrc:
+```
+alias ls="ls -A"
+```
+I also added to my $XDG_CONFIG_HOME/ranger/rc.conf for the ranger file manager:
+```
+set show_hidden true
+```
+
+### Undotting My Dotfiles
+This predominantly involved adding a bunch of variables to my ~/.profile:
+```
+## Add /bin for executables instead of .local/bin
+PATH="${PATH}:${HOME}/bin"
+
+## Should replace .config, .cache, and .local/{share,state} for most programs
+XDG_CACHE_HOME="${HOME}/var/cache"; export XDG_CACHE_HOME
+XDG_CONFIG_HOME="${HOME}/etc"; export XDG_CONFIG_HOME
+XDG_STATE_HOME="${HOME}/var/lib"; export XDG_STATE_HOME
+XDG_DATA_HOME="${HOME}/share"; export XDG_DATA_HOME
+
+## These programs think they're special and should go to hell
+## but they give me an option at all which I appreciate
+### Bash
+HISTFILE="${XDG_STATE_HOME}/bash/history"; export HISTFILE
+
+### Python (>3.12)
+PYTHON_HISTORY="${XDG_STATE_HOME}/python/history"; export PYTHON_HISTORY
+PYTHONPYCACHEPREFIX="${XDG_CACHE_HOME}/python"; export PYTHONPYCACHEPREFIX
+PYTHONUSERBASE="${XDG_DATA_HOME}/python"; export PYTHONUSERBASE
+```
+
+### Moving Desktop Files
+As mentioned earlier, the xdg-user-dirs tool in combination with $XDG_CONFIG_HOME/user-dirs.dirs achieves what I want:
+```
+XDG_DESKTOP_DIR="$HOME/tmp"
+XDG_TEMPLATES_DIR="$HOME/tmp"
+XDG_PUBLICSHARE_DIR="$HOME/tmp"
+XDG_DOWNLOAD_DIR="$HOME/tmp"
+
+XDG_PICTURES_DIR="$HOME/media/img"
+XDG_DOCUMENTS_DIR="$HOME/media/doc"
+XDG_MUSIC_DIR="$HOME/media/audio"
+XDG_VIDEOS_DIR="$HOME/media/video"
+```
+
+This one probably needs some explaining.
+
+To start, the hier(7) manpage says that /media/ is meant for removable media, like CDs or floppy disks, with a subdirectory for each type of media (i.e. /media/floppy[0-9]/), which clearly isn't quite what I'm using it for here. However, to begin with, I normally only use /mnt/ to mount external drives, but I COULD see myself mounting an external drive dedicated specifically to hosting my media files at ~/media/, if I'd been a desktop user. Of course, I'm also forgoing the media type subdirectories, which I do because I can only see myself mounting multiple drives here under the condition that its a single LVM or ZFS pool. Essentially, I'm bending the meaning of ~/media/ here to OPTIONALLY mean "removable media", and more predominantly mean "media files".
+
+It might also seem weird that I listed so many of them at ~/tmp/, but hear me out here. For one, I don't have a desktop, since I use a tiling window manager, and I have zero clue what the templates or public share directories are for, so I combined these all into my downloads directory to act as a large catch-all for any file I'm not immediately sure should go elsewhere. The reason I put these in ~/tmp/ specifically, though, is because I've found that the only files that remain in my downloads directory for a long time tend to be those that I really only needed once for a particular purpose, such as a Linux ISO image to write to a USB drive. Thus, I've actually gone so far as to add the following to my /etc/fstab:
+```
+tmpfs /home/snit/tmp tmpfs rw,relatime 0 0
+```
+Which, of course, means that my ~/tmp/ directory will be cleared every time I reboot; this may seem inconvenient to some, so I don't recommend this part, but, again, I only use this directory for files I'm probably gonna delete soon anyways.
+
+### Issues I've Encountered
+The main issue I have is just with software that doesn't follow the specifications properly. OpenSSH places files in ~/.ssh/, Firefox has ~/.mozilla/ (I'm told this will soon be fixed), and it seems that changing settings in Firefox's filechooser dialogue causes a file to be created at ~/.config/dconf/user, even though dconf claims to support $XDG_CONFIG_HOME.
+
+There's also ~/.profile and ~/.shrc. I can move the latter using ENV, but the former to my knowledge simply can't be moved. However, I've opted to leave both as is and accept them, simply because FreeBSD seems to put similar files straight into /, so it technically has the consistency I'm looking for here, even if its slightly inelegant.
+
+### Directory Structure
+Currently this is what my home directory looks like:
+* ~/bin/ for local scripts and executables (replaces ~/.local/bin/)
+* ~/etc/ for configuration files (replaces ~/.config/)
+* ~/media/ for media files like images or documents
+* ~/media/audio for audio files
+* ~/media/video for video files
+* ~/media/img for images (this actually contains a lot of videos for convenience, but I might change that)
+* ~/media/doc for text-based files like PDF documents and personal notes
+* ~/mnt/ as an alternative to /mnt/ for easier access
+* ~/share/ for architecture-agnostic data (replaces ~/.local/share/); this is actually where I put my desktop wallpapers
+* ~/src/ for program source code
+* ~/src/foreign/ for code I didn't write for organisation purposes (might also add ~/src/local/)
+* ~/tmp/ for the default download directory, mounted as a tmpfs
+* ~/var/cache/ for cache data (replaces ~/.cache/)
+* ~/var/lib/ for state data (replaces ~/.local/state)
+* ~/.mozilla/ for Firefox data (can't move)
+* ~/.ssh/ for OpenSSH data (can't move)
+* ~/.profile for my shell profile
+* ~/.shrc for my interactive shell settings
+
+## Conclusion
+Mainly I just wish user directory trees worked similar to system trees. Why can't we leverage existing knowledge for this? Why do I have to write special cases based on whether its a system or user tree? Why can't programs just follow standards properly?
+
+It'd be cool if, for example, I could actually compile a package and install it to my user directories just the same as if I were installing it to the system itself. In conjunction with Plan 9's bind(1), I could see this being genuinely useful on multi-user systems like pubnixes. After all, I can download, compile, and run that program regardless, so, in my opinion, there's no real point in NOT giving me the option to use the package manager in my own home directory.
+
+Anyways, that's all I've got for now. If you've any questions or feedback on this admittedly incredibly cursed and controversial topic, I'd love to hear it:
+=> mailto:snit@cock.li Email
+=> https://matrix.to/#/@snit:isekai.rocks Matrix
+
+
+## Addendum 1
+Just wanted to add that I no longer mount ~/tmp/ as a tmpfs. It honestly works fine for the most part, but I had transmission set to download incomplete torrents to ~/tmp/ before moving them to ~/media/ when finished, which gave me a lot of out-of-memory errors if I downloaded a large enough torrent, or a lot of torrents at once.
+
+Also, I use trash-cli and have rm aliased to it. When ~/tmp/ is mounted as a tmpfs, it actually gets its own ~/tmp/.Trash/ directory, as its a different filesystem from /home. Its not a big deal but its somewhat annoying having two separate trash directories. And if you haven't figured it out already from uh everything above this, annoyances when it comes to directories are intolerable on my system.
+
+So I don't mount it anymore, and instead just use it as a regular directory that I clear out sometimes. The only real benefit it used to bring was clearing out automatically on shutdown, but I could probably just add an rm line to my .profile for a similar effect.

comp/index.gmi

@@ -0,0 +1,5 @@
+# ~snit/comp/
+This section is for technology-related content. Most of it is probably related to programming or especially just really bad takes on how operating systems should work.
+
+Speaking of bad takes, that's the only thing I have here at the moment:
+=> hier7.gmi Regarding hier(7) in $HOME

index.gmi

@@ -0,0 +1,12 @@
+# ~snit
+Hello, I am ~snit, an avid enjoyer of all things isekai, as well as the administrator of isekai.rocks. This capsule is my own personal space to talk about isekai (or other weeb media), technology, privacy/security, linguistics, and other esoteric topics.
+
+## Topics
+Fair warning that there's not much here at the moment; some of these sections have nothing interesting.
+
+=> comp/index.gmi ~/comp/
+=> lang/index.gmi ~/lang/
+=> meta/index.gmi ~/meta/
+=> rand/index.gmi ~/rand/
+=> weeb/index.gmi ~/weeb/
+=> wips/index.gmi ~/wips/

lang/index.gmi

@@ -0,0 +1,2 @@
+# ~/snit/lang/
+Linguistic-related content. Languages (natural or artificial), linguistics, orthography, etc. is placed here.

meta/index.gmi

@@ -0,0 +1,9 @@
+# ~snit/meta/
+The purpose of this one is threefold; it contains:
+* content about this Gemini capsule (~snit)
+* nonessential information regarding isekai.rocks and its associated services
+* writing about me as a person (as opposed to just my opinions) for whatever reason
+
+There's a good chance those first two will also be found in ~snit/comp/, as well.
+
+=> post-ideas.gmi Post Ideas

meta/post-ideas.gmi

@@ -0,0 +1,47 @@
+# Post Ideas
+A collection of ideas that I'd like to write about if I ever feel like it, sorted by category, but in no particular order.
+
+## /comp/
+* That one time I tried replacing GNU coreutils with uutils on Gentoo
+* My failed attempt to use a pure TTY environment on a spare laptop
+* Language-oriented programming
+* UNIX philosophy extremism
+* Why writing a compiler/interpreter is a good project regardless of skill level
+* More specialised software/services to replace various aspects of the web, in the spirit of UNIX philosphy "do one thing and do it well"
+* My browser setup, or really any other odd aspect of my current setup
+* A list of things I would like to see in my ideal operating system, POSIX-compatibility be damned
+* Tag-based filesystem benefits from a perspective other than media curation (system administration, programming, everyday usage)
+
+## /lang/
+* Holistic conlanging
+* Measuring relative complexity of various languages
+* Lexicalisation in Toki Pona
+* Neopronouns lol
+* Every argument boils down to an argument of semantics in the end, it seems
+* How the medium of writing affects average message lenth
+* Literally anything about phonoaesthetics/phonosemantics/sound symbolism
+* Dialects of English that are unique to specific spaces of the internet (i.e. 4chan)
+* Case study a polysynthetic language to see how various features work together
+* Case study a single (generally polysynthetic) feature across several languages to see different ways it can develop and be used
+* The difference between being polysynthetic and just being really really synthetic
+
+## /weeb/
+* Literally anything I'm consuming now (just monologue into a .gmi instead of Matrix)
+* Isn't it interesting that SAO takes an oddly positive outlook on being trapped in a death game that kills four thousand?
+* Slavery is pretty common in isekai series. What's up with that?
+* Shield Hero vs Ningen Fushin in regards to portrayals of trust (or the lack thereof)
+* Why I like certain objectively bad series and why I hate some objectively good ones
+* Development of isekai as a genre and its associated tropes over time
+* Of course, the question of what even counts as "isekai" (its probably not what you think)
+* Why I like isekai specifically so much
+* Comparison of certain common isekai worldbuilding tropes across series (i.e. magic, races, gods, countries, monsters, adventurers, etc.)
+
+## /meta/
+* Just a list of things I like regardless of what it is
+
+## /rand/
+* Why people should stop defaulting to a blog structure for everythng, and possible alternatives to use instead
+* Old Minecraft versions and Luanti feel very eerie and liminal, but modern Minecraft doesn't. How come? What causes it?
+* Gatekeeping is good, actually (sometimes) (i.e. IRC, 4chan)
+* What makes a good Minecraft (or general in-game) currency?
+* Why Minecraft is a really bad game for (purely in-game) capitalism most of the time

rand/index.gmi

@@ -0,0 +1,2 @@
+# ~/snit/rand/
+Anything that doesn't fit into any of the other categories, and doesn't really deserve the creation of a whole new category.

weeb/index.gmi

@@ -0,0 +1,4 @@
+# ~/snit/weeb/
+Content relating to anime, manga, {light,web,visual} novels, etc. is placed here. As one might expect from the owner of a domain called isekai.rocks, a lot of it is likely isekai-related.
+
+=> julie.gmi An anon on /a/ posted this in every Mushoku Tensei thread and it deserved to be saved 

weeb/julie.gmi

@@ -0,0 +1,3 @@
+Jaegerbombs with Julie! Jaegerbombs with Julie and it isn't even child abuse! Teaching her how to microsolder a motherboard afterwards! Then more Jaegerbombs! With Julie!
+
+=> image/5332e7868258aa47160502a7d88c34a6.jpg Jaegerbombs with Julie JPEG

wips/index.gmi

@@ -0,0 +1,2 @@
+# ~/snit/wips/
+If I ever decide something I'm working on is worth posting despite its incomplete state, I'll post it here.