yesterday I thought, wouldn't it be the absolute perfect solution to track my dotfiles with hardlinks? (that is, you hardlink the dotfiles into a git repo and track them from there)
so today I did a bit of research and found that there are many people who have tried this method, and there are caveats:
^that article suggests you to just track your ~ with git, which I have mentioned with other dotfiles managers on Apr 6th (below), it said that the problem with doing the hardlinks way is that "Git never modifies files in the working tree – instead, it unlinks them and then recreates them from scratch. This inherently breaks any hardlinks that might have been present". which AFAI can tell, you can't use git commands to modify files from your repo and wish that those changes will reflect in your ~ (?)
so then I thought, what if, instead of having files in your dotfiles git repo be hardlinks /of/ your dotfiles at ~, why not have the dotfiles at your ~ be hardlinks /to/ files in your git repo?
in that case, though I haven't tried it yet, will probably be similar to the symlink solution which when you want to `vim .gitconfig` for example, it opens `~/dotfiles/.gitconfig` and breaks the syntax highlighting. But now with symlink replaced with hardlinks, you are probably still editing your `~/.gitconfig` and since `~/dotfiles/.gitconfig` points to the same contents you can track the changes as needed. sounds too good to be true, kinda?
so why am I trying out these different, almost crazy, methods when I said I was going to stick to yadm? well, so here is what I still need which yadm doesn't provide (AFAIK):
for some machines, only track some files and directories and remove the others.
- if on one machine I don't have nvim installed for some reasons, I don't want to have .config/nvim exist. it can do what ever it want in my remote dotfiles repo but I just don't want to see that in my $HOME
- another scenario: in my dotfiles repo, it makes sense to have a README.md since it's hosted publicly, but on one or more particular hosts the readme serves a different purpose, whatever that may be -- I'd like to modify README.md however I like and not have `yadm status` tell me the file is modified. in this case, I /could/ possibly stash the change, commit other changes, and apply (?) but... nah, I'd probably forget and end up stashing unwanted changes and be left in a git mess.
anyways, the problem I described above can probably be solved with chezmoi, but like what I've written on 6th, there are downside(s) with it and I don't like it. I'd rather stick with yadm for now, and try out the hardlink strategy. In any case, once I've figured out an almost-perfect solution that (hopefully) solves all my problems I'll write a gemlog post about it. It may be that there is no such solution that can do so but we'll see.
new journal heading layout. # for each month, ## for each day, and ### for each event
also made the stuff reverse-chronological order
found several cool more things on gemini:
paste.gemigrep.com - paste and archive text and gemini urls
gmisub - I normally just use Spacewalk or gemreader for feeds in gemini, but this is cool too
Amazing post on SCGI in gemini
discovery.geminiprotocol.com - more cool stuff on gemini
review.treeblue.space - similar to above
gelim - my new wip line mode Gemini client in go (sr.ht)
(will write a detailed gemlog post for this)
here's my general dotfile setup/manager timeline:
2. symlink + plain git
4. copy-paste files to repo (with scripts to make it easier)
6. homedir git (with * in .gitignore, and track with `git add -f`)
the last 3 from the above are my top 3 preferred options, here are the pros and cons for each:
〈 ~ git 〉
Drew's blog post on this setup
I’ve tried a few solutions over the years, but I settled on a very simple system several years ago which has served me very well in the time since: my $HOME is a git repository
- you control everything
- simple and lightweight
- no additional tooling setup, just git
- alternate files
- template files
〈 yadm 〉
basically, your $HOME is a git repository, but wrapped. nothing is tracked until you `add` it, so I think of it as the above method but with more features.
- commands passed to git
- alternate files
- no password manager integration (but i don't need it)
- in bash (honestly I'm fine with that, but go could be easier lol?)
〈 chezmoi 〉
it copies your dotfiles to a separate dir and you can optionally setup git in that dir.
- everything is good, except...
- the repo you end up having will have files that are like "dot_bashrc" "dot_vimrc", "private_config/" etc. and not only does it NOT LOOK NICE, it also DESTROYS THE SYNTAX HIGHLIGHTING (yes I'm shouting this). but sure, the fact that chezmoi's pros are pros and has so many features others don't, sometimes we do have to let this slide. but nah some of the features it has I don't really need, and I will stick to yadm for now.
read more about this ("complaint"?) and their reasons for it
full comparison table between various dotfile managers (chezmoi docs)
seen it across the geminispace as well as mentioned in IRC many times, but I didn't give it a go since it was desktop-based... but today I saw some people on #gemini tilde.chat IRC mentioning Lagrange for iOS, immediately I went to skyjake.fi's gemlog and joined the testflight. the only iPad gemini client I've used so far was Elaho, which has similar UI/UX to firefox, it feels smooth and comfortable to use, despite have it lack some features such as subscriptions, importing certs (AFAIK), and sharing identities across different capsules. (I mentioned Elaho when I first tried it out in the 2021-04-01 entry above). here are my first impressions
- if looks quite modern, but the first thing I noticed was the "glitchy" scrolling, it doesn't feel smooth even after toggling the "Smooth Scrolling" setting
- it assigns capsules its own favicons and they look quite weird... using favicon.txt might be better even if the proposal isn't officially accepted (yet?)
- it can import and manage certificates, great!
- it has lots of settings, including adjusting the fonts and margins of the page's display (and proxy!)
- it has subscriptions, great! (although I wasn't able to get it working and couldn't find the place for feed management... amfora's subscriptions feature is better atm, or I could keep using Drew's gemreader[*], or a feed aggregator.
public instance of gemreader ^ (needs cert)
started getting into go in january, but at the time I only did some stuff on the Go Tour, and since then I hadn't touched go at all... Today looking at some gemini clients and other software, sometimes urged me to learn go (like, immediately). started looking at simple Gemini server/clients source code and I decided to fork solderpunk's "≈100 lines bare-bones but usable client in Go"[*], refactor it, implement some features like more commands, less(1)-like output, etc, basically a simpler, dumber version of AV-98 in Go. This is also to basically help me learn go with "learning by doing", really excited for this. Will probably start tomorrow
wow! did mozz just add support for spartan:// to his HTTP-gemini portal? dang this is amazing, no need to use my terminal with `| less` anymore :P
Gemini Proxy (also spartan now)
read the specs[*] for spartan a bit more carefully today... the way it specifies how inputs are requested is quite interesting. AND guess what... there's inline inputs! (AFAIK) spartan uses text/gemini for its document format, and adds a new input syntax "=:" to replace gemini's 10 INPUT status code. here's an example .gmi served over spartan:// with input:
# normal heading * normal list item * second item here goes an input =: /input-handler friendly text for the input more normal text
try out here
spartan://mozz.us on proxy
there's a guestbook and also an "echo service" where anything you input will be echoed back to you
problem is, atm, the server.py file[*] doesn't handle inputs (at least not from looking at the code and trying it out), and I would really love to see how spartan://mozz.us do the echo and the guestbook thing, but I don't think it's open sourced
anyways I think this feels more like a gemlog post, will link to it here when I'm done writing it
Knowledge and resources are really scattered. I was looking into gemini, gopher, irc bots, etc to be specific. One day, when I have the money, time, and energy, I will buy a domain, get a host and sit down and organized all of these things into a single public wiki/notebook...
I saw mozz's post[*] on his shiny new protocol a few days ago, but only decided to have a look today. looking at the client/server .py files I was like "wow! this seems really lightweight", also, this was the perfect opportunity to install a curl-like program for gemini:// so I decided to use makeworld's gemget[*] and downloaded the two scripts for spartan://.
mozz's post on spartan://
gemget - CLI downloaded for gemini (like curl/wget) - by makeworld (github)
My first stop on the spartanspace is spartan://mozz.us, I also had a play with its cool input "system", then immediately went on to trying out the server. So far everything feels just like gemini, except that this protocol is newer, lighter, and I guess easier to implement. Can't wait to get more into it and create my own server/clients for it!
super cool gemini
registered on Astrobotany[*] a week ago, and been only using it with amfora[*] on tilde.cafe[*], but today I tried out a gemini from the iPad - Elaho! (will link to it once I find its github repo, forgot atm).
Astrobotany - community garden over gemini://
amfora client on github
tilde.cafe, a "newly" launched, debian tilde
so far browsing the geminispace from Elaho is a super cool and relaxing experience, it seems to be based off firebox. But from what I can see, Elaho doesn't allow you to import certificates, so I created one, logged into Astrobotany and added my current certificate to my account.
all this "gemini apps" and auth with client certs and so cool! can't wait to make my own game or app over gemini
A week or two ago I started taking a serious look at gopher, reading through every single post on gopher.zone
gopher.zone - Gopher guides - "Highway to the gopher zone"