That's a good point. Though I'd still expect more effort from the developer to convince people that they will actively maintain the project after the first 3 months.
There are 3 new commits, and the only actually fixes are: Go update and revert to earlier version of console.
But there are a bunch of changes to docs, CI workflows and issue templates. Which is what is the easy part of managing a fork, and I've seen a bunch of forks that ended up only updating readme-s, CI, etc.
I'll have more faith in the fork when the maintainers do actual fixes.
This does seem like a person getting hooked on idle games, or mobile/online games with artificially limited progress (that you can pay to lift). It's a type of delayed gratification that makes you anxious to get next one.
Not everyone gets hooked on those, but I do. I've played a bunch of those long-winded idle games, and it looks like a slight addiction. I would get impatient that it takes so long to progress, and it would add anxiety to e.g. run this during breaks at work, or just before going to sleep. "Just one more click".
And to be perfectly honest, it seems like the artificial limits of Anthropic (5 hour session limits) dig into similar mechanism. I do less non-programming hobbies since I've got myself a subscription.
One option is to do multi-stage rollout of your database schema and code, over some time windows. I recall a blog post here (I think) lately from some Big Company (tm) that would run one step from the below plan every week:
1. Create new fields in the DB.
2. Make the code fill in the old fields and the new fields.
3. Make the code read from new fields.
4. Stop the code from filling old fields.
5. Remove the old fields.
Personally, I wouldn't use it until I really need it. But a simpler form is good: do the required schema changes (additive) iteratively, 1 iteration earlier than code changes. Do the destructive changes 1 iteration after your code stops using parts of the schema. There's opposite handling of things like "make non-nullable field nullable" and "make nullable field non-nullable", but that's part of the price of smooth operations.
I had a strange problem with Dell P2720DC (27'' 2560x1440) - the whole outer edge of the screen would flicker if I used dark background with a lot of dim colours (like dark mode in IDE, or default Grafana theme). It wouldn't happen all the time, but it would happen on a weekly basis (I most often seen that on Sunday). I've RMA'd it, got another monitor, which also started showing the same problem. I gave it to someone who doesn't use dark mode - no issues.
So, I'm not getting another Dell until I'd be sure this issue won't happen again :)
NX NPM attack (at least the previous wave which targetted tinycolor) relied on running post-install scripts. Go tooling does not give you ways to run post-install scripts, which is much more reasonable approach.
Yeah, you need root or sudo to view iotop. But some information is (at least on some fresh ubuntu) available without elevation, like the per-disk output from iostat.
It's either on Performance tab (per disk) - the big chart is "active time", either per process on Processes tab as a column "Disk" - color is related to time usage, while the bandwidth is as text.
I regret neither Top neither Htop show you estimates of "IO Activity time" like in Windows 10 task manager - I need to use separate iostat to observe that.
I found the "IO Activity time", percentage of time when IO is used, to be a really good indicator of IO load on machine level - neither io-op per second, neither bandwith tell much if you're already using up all available IO. Load does not help here, as number of processes doing IO influences "load" more.