Monetization seems to be quite neglected in this wave of self-published content. I am with you that writers who want to monetize their work absolutely should be in power to do so.

I think a big part of why monetization is neglected is because it’s tricky do right. No one likes being subjected to tons of tracking scripts or hitting a paywall for the content they’re browsing. On the other hand, how do you make money from people if your content is completely free to browse.

Of course anyone can slap Google-ads on their website to generate some money from their traffic. However, for the indieweb to grow I believe there needs to be a healthy discussion on how to ethically monetize your content.

Yeah, I get those all the time. Fortunately changing to a private browser window usually gets around it.

It really makes me despise Medium though, especially since a lot of developers have chosen to publish their write ups on software there. Hitting that blocker while researching or debugging something is the worst.

I agree that this isn’t really the most groundbreaking take, especially on here.

But I thought this post might be interesting for someone who’s just started breaking free from big social media and getting to know the indieweb.

And possibly associate yourself with icky non-STEM subjects? Noo, thank you!

Hopefully changing away from riot will make it easier to google certain things specifically related to their matrix client. I get results for Riot Games (and league of legends) way to often when searching for Riot combined with keywords like chat or voice.

Personally I read blogs on my phone about 7 out of 10 times, so I’ve focused a lot on making sure it’s readable on a range of device sizes.

Hugo makes it quite easy for me to connect my phone to the running development server, and I’ve been testing the layout a lot on both my laptop and phone.

My workflow is basically that instead of installing all dependencies for a project, I run a container with what I need that is usually removed immediately after execution.

As an example I recently wanted to compile minikube from source. To compile the project I would need to have go installed as well as make, and since I don’t have any of those tools installed to my base system I used the official golang container from dockerhub.

Compilation is then run with podman run --rm -it -v $(pwd):/usr/src/minikube:Z -w /usr/src/minikube golang:latest make which simply mounts the project and compiles it using make, and since the entire project folder was mounted in the container any binaries and other output can be found in the configured output directories on the host.

If I have any project I have to run or compile often inside of a container I can easily create an alias or function in my shell to run the podman run command for that project.

I like this workflow a lot since it keeps my host system clean, and it makes it easy for me to build projects with different dependencies with little to no conflicts. I much prefer this over toolbox since I don’t have to consider the state of my toolbox container and images are always updated to their latest version without any need to manually keep packages inside the toolbox up to date.

I might do a more thorough write up of my workflow on my blog in the future and if I’m satisfied with it I’ll probably post it here as well.

I agree with you on toolbox being weird. I’ve pretty much stopped using it and instead opt for specific containers for tools I don’t want to layer or can’t find a good flatpak for.

Not sure if it counts, but I’ve really been enjoying using rpm-ostree on fedora silverblue