0: https://dev.mysql.com/doc/refman/8.4/en/innodb-performance-t...

Claim one: setting up unattended-upgrades, SSH keygen, and automating cert rotation is trivial and easily automated.

Claim two: you should know how to manage a Linux server. Here are docs.

https://tldp.org/

https://www.man7.org/linux/man-pages/dir_all_by_section.html

https://nginx.org/en/docs/

https://www.postgresql.org/docs/current/index.html

What you have stated requires more knowledge (especially Postgres). You’re not going to get it from a blog post, and will need to read actual source docs and man pages.

I will die on this hill: parent is correct - the ability to manage a Linux server should be a requirement to work in the industry, even if it has fuck-all to do with your job. It proves some basic level of competence and knowledge about the thing that is running your code.

Or it means that SQLite is exhibiting some of its "maybe I will, maybe I won't" behavior [0]:

> Note that "monotonically increasing" does not imply that the ROWID always increases by exactly one. One is the usual increment. However, if an insert fails due to (for example) a uniqueness constraint, the ROWID of the failed insertion attempt might not be reused on subsequent inserts, resulting in gaps in the ROWID sequence. AUTOINCREMENT guarantees that automatically chosen ROWIDs will be increasing but not that they will be sequential.

> No ILIKE. PostgreSQL developers reach for WHERE name ILIKE '%term%' instinctively. SQLite throws a syntax error. Use WHERE LOWER(name) LIKE '%term%' instead.

You should not be reaching for ILIKE, functions on predicates, or leading wildcards unless you're aware of the impacts those have on indexing.

> json_extract returns native types. json_extract(data, '$.id') returns an integer if the value was stored as a number. Comparing it to a string silently fails. Always CAST(json_extract(...) AS TEXT) when you need string comparison.

If you're using strings embedded in JSON as predicates, you're going to have a very bad time when you get more than a trivial number of rows in the table.

0: https://sqlite.org/autoinc.html

ffmpeg disagrees.

More broadly, though, it’s a logical step if you want to go from “here’s how PN junctions work” to “let’s run code on a microprocessor.” There was a game up here yesterday about building a GPU, in the same vein of nand2tetris, Turing Complete, etc. I find those quite fun, and if you wanted to do something like Ben Eater’s 8-bit computer, it would probably make sense to continue with assembly before going into C, and then a higher-level language.

There is a vast difference between “never learned the skill,” and “forgot the skill from lack of use.” I learned how to do long division in school, decades ago. I sat down and tried it last year, and found myself struggling, because I hadn’t needed to do it in such a long time.

Re: particular unit, I’m not sure - it was perfectly fine during anything “normal,” and admittedly, asking a laptop to run at 100% for any extended period of time is already a big ask. But it’s possible, I suppose.

I’m waiting for the Studios to get the Max and / or Ultra, and will reconsider if I want one, or if I don’t really need to play with local LLM at this time.

Turns out the heatsink in the 14" isn't nearly enough to handle the Max with all cores pegged. I'd get about 30 seconds of full power before frequency would drop like a rock.

Plus, for any script that’s going to be fetching or posting anything over a network, the LLM will almost certainly want to include requests, so now you either have to deal with dependencies, or make it use urllib.

In contrast, there’s an extremely high likelihood of the environment having a POSIX-compatible interpreter, so as long as you don’t use bash-isms (or zsh-isms, etc.), the script will probably work. For network access, the odds of it having curl are also quite high, moreso (especially in containers) than Python.

Fully agree. I already know the locations of the logs on-disk, and ripgrep - or at worst, grep with LC_ALL=C - is much, much faster than any aggregation tool.

If I need to compare different machines, or do complex projections, then sure, external tooling is probably easier. But for the case of “I know roughly when a problem occurred / a text pattern to match,” reading the local file is faster.

I’m constantly having to fight people to not add new, inactionable alerts as knee-jerk reactions to incidents. I swear the thought process is “an incident happened, we added a new alert - look, we’re proactive!” instead of, you know, fixing the root causes.

It seems to ease the tension a bit, anyway.

The U.S. Nuclear Navy, for all of its many flaws, gets this right. Generally at least once a year, the head of Naval Reactors - a four-star Admiral - tours every vessel, which may include a brief underway period. During this tour, the Admiral will talk to the engine room watchstanders, with all senior leadership removed. They’ll ask how daily life is, what they find challenging or annoying, what they like, etc. There’s obviously a lot of self-filtering (though sometimes not - Navy Nukes are not known for their social graces) that occurs, and also what a junior watchstander finds annoying may just be a required part of the job, but some useful signal is gathered.

Even outside of the nuclear program, one standout example was Admiral Zumwalt, who as Chief of Naval Operations implemented 70 different changes over his tenure as a direct result of talking to sailors, all of which were designed to improve quality of life, efficiency, or communication.