
If you have serious projects on GitHub, it's a good idea to set up mirrors of your repos on other forges. Very easy to do with Gitea/Forgejo.
Self-hosting Forgejo is also super easy, if you have a NixOS server you can just add it as a service and put it behind nginx like this
banning someone from github without a warning is fucked up @github @Microsoft
i need to copy my repos damn
Here's what a full server configuration can look like gist.github.com/stancl/589c4…
Samuel Stancl retweeted
Thank you @vonderleyen, very cool!
AirPods Live Translation Blocked for EU Users With EU Apple Accounts macrumors.com/2025/09/11/air…
This is what my entire server config looks like.
On NixOS, this configures:
- nginx
- php-fpm
- SSL certificates (including renewals)
- cron for Laravel schedule
- users and groups
- queue worker
- firewall
- ssh keys, and more
For as many sites as I want.
Article link below
New article about a system for organizing TODOs in code that I use in pretty much every project
Came up with it a few years ago while working on some brutal refactors and stuck with it since. It has worked exceptionally well in every project I've worked on
The system is meant to be fully editor-based (as in an editor that can search is all you *need*) but for convenience I've also written a simple CLI tool in Rust for getting a quick look at all the TODOs within a project in a nicely structured way
github.com/archtechx/todo-sy…
As much as I love SQLite one thing that's annoying about using it with PHP in production is that it doesn't handle concurrent locks well. This really is more of a PHP limitation and one that should be imo addressed
The issue is basically that there's no way to tell PDO to begin immediate transactions which gives you "database is locked" errors whenever there are 2+ concurrent transactions, at least one of which *first reads* and only later tries to upgrade to an exclusive lock.
If you begin the transaction with "BEGIN IMMEDIATE TRANSACTION" the problem disappears. You can hack around this by creating a wrapper around DB::transaction() in Laravel which writes to a dummy table before executing the callback (that may or may not first read before writing).
However this doesn't solve cases where the framework itself is using pure DB::transaction(), so you still get some of those errors.
You can see a simple demo here github.com/php/php-src/issue…
One thing I like to do in custom CLI utils is separate the "real output" from any additional informative output into stdout and stderr. That way I can pipe either one into a file or even the clipboard (`| pbcopy` on macOS)










