3 Tools for 2025 |
||
| Author: Samuel Hierholzer | Date: 31 Jan 2025 | 9 minutes |
TLDR; I really wish these tools gain more traction:
I love new tools. Whenever I learn about a new tool there is that excitement of new that kicks my ADHD and makes me wanna drop everything immediately, just to spend the next 10 minutes to 5 days learning about the tool. That’s not just wishful thinking - it’s my actual behavior more often than I’d like to admit. The time range varies so much because usually it takes at least 10 minutes to know the basic concept. And up to 5 days to get started.
For most tools the basic concept is where my excitement ends. Because I’m really hard to satisfy. I’m attracted to purism. I need innovation plus an application to keep reading. I need something that’s thoroughly thought through to really like it.
And there’s not too much that actually passes all requirements.
For an example Pijul satisfies almost all. But git is kinda “good enough” (for me at least). The benefits don’t seem to really justify replacing a whole ecosystem of how we manage code.
So there isn’t really an application for me to start using it. I’d definitely use it if others did, but I wouldn’t push it.
But now, here are three tools that do meet my standards — enough that I genuinely believe we should start using them!
Oils is a reimplementation of the Bash Shell. But with an incremental upgrade path. And I reeeaally believe this is the only way out of the legacy shells dead end we’re currently in. The default shell on every major Unix, Linux, BDS and even MacOS hasn’t had a single meaningful new feature for over 25 years! KornShell is probably the “most advanced” shell (but it was unfree for a long time and apparently also buggy, thus nowhere the default except OpenBSD). It has possibilities to do OOP programming, but it doesn’t solve any of the foodguns the POSIX standard enforces (e.g. implicit globbing, broken arithmetics, etc).
Oils fixes them.
Not like Nushell by creating a new language with similar syntax. Oils takes the long road. By implementing bash to really understand it and only fix what’s really broken. With a way of upgrading your scripts instead of restarting. Oils is even POSIX compliant!
It’s currently unstable, but the Bash-compat part is considered ‘late beta’ and the target is a 1.0 Release in this year.
Luckily my merge request to add Oils to Alpine Linux just came through a few days ago, so if you have docker, you can easily give the new shell a go (replace ysh with osh for the bash compatible shell):
docker run -ti --rm alpine:edge
# in the container
echo https://dl-cdn.alpinelinux.org/alpine/edge/testing >> /etc/apk/repositories
apk add oils-for-unix
ysh
# download a json of my blog posts and print the titles
ysh-0.26.0# wget -q yosemitesam.ch/data.json -O - | json read (&blog)
ysh-0.26.0# = blog=>keys()
Radicle is a decentralized git hosting/sharing solution. And it feels extremely thought through. It’s superior to Gitlab or Github because it’s fully decentralized and federated. And I have the feeling it’s technically also superior to ForgeFed as it works more like torrenting. IMO this makes more sense for source code than using a federation protocol like ActivityPub, as availability of information is more critical for source code than consumer data like microblogging, etc. In the end you typically want to have the source code local for editing and/or using anyway. Being able to just start seeding that local data makes total sense!
They made the UX extremely intuitive. Even when the “hosting” is local it feels like the already known server-client interaction. This means it’s very easy to switch from other hosters to radicle. And they invested a lot to make the new concepts easily learnable;
The docs are a masterpiece! |
I’ve reread it just as inspiration before doing a quickstart documentation in a completely unrelated topic! This is not very relevant, but helps a lot with the not completely (but still very) straight forward setup compared to any http/ssh based git hosting. Especially given that the PR workflow is a bit more involved.
They are at the third iteration of the federation protocol and I think it’s noticable, as it seems to be “just the necessary” to make a usable p2p network on top of git without loosing anything feature wise compared to the typical git server (Issues, PRs, CI, …).
I believe (or rather, hope!) once they figure out discovery it will blow up as Github replacement. Chances are still very high that it’ll stand in the shadow of the much more “approachable” ForgeFed which benefits from the already used & trusted ActivityPub protocol.
I created a radicle node on my server and published the source to this blog. I recommend you to follow the amazing user guide, but you can also just clone my blog via peering:
curl -sSf https://radicle.xyz/install | sh
rad auth
rad node start
rad clone rad:zgsq23FVnsr6agpAZ5Pc5abiibdv
# optionally stop the node again
rad node stop
cd yosemitesam.ch
# List the changes I made to this blog
git log --oneline _posts/2025-01-31-3-tools-for-2025.md
# if you want to seed my blog (needs a running node)
rad seed rad:zgsq23FVnsr6agpAZ5Pc5abiibdv
rad ls --seeded
Simplex Chat seems like “just another chat app” at first. But that’s wrong!
It’s approach to Addresses is fundamentally different.
On a high level it’s quite simple. You create a profile. And then you can generate one or more addresses (which are just https://simplex.chat/#NOISE urls, where NOISE is some crypto “magic”) for that profile. But here’s the first catch:
Addresses are either one-time-only or reusable until you delete it |
So I can share a reusable address publicly on Mastodon/Bluesky/my homepage… Until I get a Spam message. At that point I can just delete the address, generate a new one and use that until I get noise again (or stop sharing any address). Because here comes the second catch:
Every connection between 2 profiles uses unique “one-connection” addresses |
A reusable address is just used for the communication of such a “one-connection” address and can be thrown away afterwards!
That means 2 things:
It’s not very complex, just one abstraction to addresses and decoupling of addresses and profiles (which can already be the case with mailboxes). But it’s a big change in terms of UX!
It’s like you could move your mail address in an instant - and automatically notify your contacts of the change. Or have 10 mail addresses leading to 1 inbox. and just remove/add new ones as you wish. Plus of course E-to-E encryption, full privacy, etc.
I believe it’s a protocol that should replace (or at least inspire) mail!
I haven’t played around with it enough to know how well thought through the app actually is. But the concept blew my mind so much that I was very disappointed when the reaction to it was almost zero. It seems like people turn away thinking “I don’t need yet another chat app” before even understanding the innovation before their eyes.
I’ve created a Feedback group which you can join to tell me what you think of my blog article. You can create your profile with your real name but join the group in “incognito mode” to stay anonymous.
Industry standards and best practices are just the observation of what we, as an industry, use and do. And I believe these 3 tools are (going to be) better than their current industry standards and “best practices” alternatives. Let’s start using them. Let’s set new standards. Let’s make bester practices!