This is why you’re meant to comment your code.

Your code tells you “what”, your comments tell you “why”.

Here’s a good review of comments in the redis codebase: https://antirez.com/news/124

The more windows falls down the enshittification spiral, the more likely the EU will get pissed at Microsoft and fund Linux environments where it’s needed.

Does everyone who’s following the old account automatically refollow you when you do that?

It doesn’t port over any old comments/posts, but I’m pretty sure that when anyone @'s you, it’s forwarded to the new account.

IMO it’d still be useful to be able to use an identity you control, like a domain name.

Mastodon already does this

It’s worth pointing out that while ActivityPub doesn’t currently support account migration (although there are proposals in the works for how to do this), Mastodon does have a weak form of support right now.

You can create a new account on another mastodon instance, then you’re able to point your old account to your new account.

Why not reformat and use a more open filesystem?

You’d get less issues too!

Shouldn’t you have an adblocker to block those scripts?

Nah, sourcetree has annoying bugs that never get fixed.

Use Fork, it’s a better sourcetree.

It’s free the same way that Sublime Text is: They’ll ask for a payment once a month, but you can say you’re “evaluating it” and use it for free. If you like it enough, you can pay for it. I have.

Another way of reading it is: “GitUI is unfinished, but the parts that are done are amazing”

I have yet to be given an example of something a “general” intelligence would be able to do that an LLM can’t do.

Presenting…

Something a general intelligence can do that an LLM can’t do:

Play chess: https://www.youtube.com/watch?v=kvTs_nbc8Eg

Why can’t it play it? Because LLM’s don’t have memory, so they can’t work with logic. They are the same as the little “next word predictor” in your phone’s keyboard. It just says what it thinks is the most probable next word based on previous words, it’s not actually thinking or understanding anything. So instead, we get moves that don’t make sense or are completely invalid.

Did you purge and update your filters?

Note: I’m not talking about turning filters off then back on, I’m talking about updating the version of each filter itself.

Wallpaper: https://github.com/IogaMaster/dotfiles/blob/main/modules/desktop/themes/catppuccin-mocha/wallpapers/cat_Japanese_Neon.png

• 50% of web developers: Chaotic Neutral
• Salespeople: Lawful Neutral
• Programmers (and the other 50% of web developers): Unaligned, we know how to use shortcuts.

What about OkLCH?

I can’t see your comment about heavy dev and testing.

I’m curious about what exactly is chewing up that much RAM. Do you have a ridiculous amount of containers running? Or a big ram disk or something?

What are you doing that makes having 64gb ram useful?

It wasn’t the profits or ads that got in the way.

It was the security that got in the way. (remember the whole TPM module thing?)

Iterating the version number was just a convenient excuse to throw more ads, and tracking in.

Good news, X is now down.

Modern PHP shits all over the PHP v3, v4, v5 days of yore.

Anyone making new projects from scratch is living in a land of bliss while those working in projects/frameworks that started in the days of yore are having experiences across the whole spectrum of, “Wow, I sure am glad we migrated to modern php” to “please kill me, I’m in so much pain”.

No competitor?

What about VRChat?

Yes it has a tenth the users, but it’s also designed around an expensive peripheral you strap to your face which prices out a lot of users.

It’s not rebase vs merge, it’s rebase AND merge.

Commit your changes into logical commits as you go.

Then just before submitting a pull request, review your own code. That includes reviewing your own commits too, not just the code diff.

Use rebase to:

• Swap commits so that related changes are together
• Edit your commit messages if you find a mistake or now have a better idea of what to put in your messages
• Drop any useless commits that you just end up reverting later
• Squash any two commits together where the first was the meat of desired change and the second was the one thing that you forgot to add to that commit so you immediately followed it up with another commit for that one missing thing.

Then, and only then, after you have reviewed your own code and used rebase to make the git history easier to read (and thus make it easier to review), then you can submit a pull request.