I’d even settle for Apple opening up the Music app so I can upload music to my iPhone from Linux. But once again, that doesn’t make the spreadsheet sparkle.

MiSTerFin is written in C and I'm much savvier with Go these days, so I (and my helpful Codex prompt) forked it and ported it to Go (where appropriate). I've since been obsessed, making improvements, smoothing out rought edges, and adding features, all get a great Jellyfin player on my CRT.

And I have to say, watching Robotech episodes on my 4:3 CRT from Jellyfin is a shot of nostalgia directly into my veins.

I'll add a bit more polish and get it published this week for others that might be interested.

Omarchy looks like a simple way for a developer like me to test drive hyprland and write code. It also looks like a great way for my kids to get into computers as there's an agent harness ready to help them manage their machine and use free software, even the stuff that's a bit obtuse.

I'm bewildered that people are mad about any of this, but then I remember I don't care what the gatekeepers think anymore.

For too many, building and celebrating things just because they are cool isn't enough.

In some organizations, maintainability may be the biggest risk being mitigated in a code review. But for me, that's selling code reviews short.

In my experience, code reviews are the single most important quality control process in the entire development life cycle. Engineers often don't have a lot of influence over the quality of requirements. Engineers often don't have a lot of influence over the competence and thoroughness of the QA process (and it often doesn't exist at all). But engineers frequently have total control over code reviews.

If I can't depend on the rest of the organization for QC, code reviews are the first place I look to mitigate that risk. That means code reviews find bugs. That means code reviews identify code smells. That means code reviews pressure test requirements and whether the implementation matches the assignment. That means code reviews transfer knowledge and serve as a teacher for both the PR author and the reviewer. And so on.

Thorough and pedantic code reviews are challenging and tedious, at least at first, but the team adapts and both the code and the review process gets better.

Then the Lord God formed a man from the dust of the ground and breathed into his nostrils the breath of life, and the man became a living being.

- Louis de Bonald

Yep. A lot of cyberpunk fiction from that time that demonized corporate influence and power was inspired by the rise and perceptions of Japanese technology companies.

I can remember one of the American news magazine shows, maybe 20/20, showing a Japanese school with long hours and intense discipline and contrasting it with fat, illiterate American kids (the same stereotypes were made about the Soviet Union).

A lot of the perception of Japan, especially among Gen X and younger, is influenced from exports of Japanese culture. Nintendo, JRPGs, Manga, Anime, and even the quirky stuff reflects well on the Japanese though American eyes. No propaganda is needed.

- Luke 4:24

It's why people often trust consultants over the people inside the organization. It's why people often want to elect new leaders even if the current leaders are doing a decent job.

The baby almost always gets thrown out with the bath water.

https://en.wikipedia.org/wiki/Don't_throw_the_baby_out_with_...

When I see "interesting" people doing "interesting" things they look fake, exhausting, or both.

What type of latency-sensitive applications are appropriate for a small-model, high-throughput solution like this? I presume this type of specialization is necessary for robotics, drones, or industrial automation. What else?

If you can't write requirements an engineering team can use, you won't be able to write requirements for the robots either.

It's a racket never ends.