Marketing. People expect to see different things on a website vs Twitter/X so the same content won't perform the same on each. So for a business it makes sense to post different things on your website vs Twitter/X.

The person who uses the shitty tool is a moron. The person who makes the shitty tool is an asshole. At least in this case where the shitty tool is actively promoting shitty PRs.

Their rules have stopped me from being able to do my job. Like the time the AV software quarantined executables as I was creating them so I literally could not run my code. When security enforcement prevents me from working, something needs to change.

AppArmor is part of the kernel. Why does it require patches?

I'm interpreting that as clickbait - just something they added to the title to drive traffic.

If I designed the schema it is most certainly going to be structured. Unstructured databases are awful.

Fuck that, I don't trust executables unless they're signed, downloaded securely (e.g. HTTPS), and I trust the source I downloaded them from. Anything else might as well be a virus. If I can't find a signed binary from a trustworthy source, I'm either not using it or I'm going to build it myself (after skimming through the code).

I find it very hard to believe that AI will ever get to the point of being able to solve novel problems without a fundamental change to the nature of "AI". LLMs are powerful, but ultimately they (and every other kind of "AI") are advanced pattern matching systems. Pattern matching is not capable of solving problems that haven't been solved before.

I prefer the first method because it reduces the number of empty lines I have to scroll past and visually filter out

Degrees are meaningless, excepting places like CalTech. I’ve known too many ‘programmers’ who had a CS degree yet were damn near useless to think otherwise. Not to mention my own CS degree taught me almost nothing.

Makes sense. The most programming I've ever done for a GPU was a few simple shaders for a toy project.

I am all aboard the code readability train. The more readable code is, the more understandable and therefore debuggable and maintainable it is. I will absolutely advocate for any change that increases readability unless it hurts performance in a way that actually matters. I generally try to avoid nesting ifs and loops since deeply nested expressions tend to be awful to debug.

This article has had a significant influence on my programming style since I read it (many years ago). Specifically this part:

Don't indent and indent and indent for the main flow of the method. This is huge. Most people learn the exact opposite way from what's really proper — they test for a correct condition, and if it's true, they continue with the real code inside the "if".

What you should really do is write "if" statements that check for improper conditions, and if you find them, bail. This cleans your code immensely, in two important ways: (a) the main, normal execution path is all at the top level, so if the programmer is just trying to get a feel for the routine, all she needs to read is the top level statements, instead of trying to trace through indention levels figuring out what the "normal" case is, and (b) it puts the "bail" code right next to the correctness check, which is good because the "bail" code is usually very short and belongs with the correctness check.

When you plan out a method in your head, you're thinking, "I should do blank, and if blank fails I bail, but if not I go on to do foo, and if foo fails I should bail, but if not i should do bar, and if that fails I should bail, otherwise I succeed," but the way most people write it is, "I should do blank, and if that's good I should do foo, and if that's good I should do do bar, but if blank was bad I should bail, and if foo was bad I should bail, and if bar was bad I should bail, otherwise I succeed." You've spread your thinking out: why are we mentioning blank again after we went on to foo and bar? We're SO DONE with blank. It's SO two statements ago.