I have a MiSTer FPGA connected to a Sony CRT and installed the MiSTerFin project, which is a Jellyfin client for MiSTer. It's got a lot of things that need fixing, so I contributed a few PRs to fix some of the problems I encountered.
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.
The Docker configuration issue was reported and changes were made quickly to address it. Sounds like this is a great example of the system working well.
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.
It's easy to disable rootful Docker support in an ISO, but much harder to fix the vulnerable installations. That is not the system working as intended.
And sadly, this stuff isn't bewildering at all. We saw it happen with LARBS, we saw it happen with Manjaro, then Archlabs, and now Omarchy too. All of them endangered themselves by shipping dotfiles that none of their users understood, and few of their developers would justify. When Manjaro's repos conflicted with AUR pkgbuilds, thousands of their users didn't understand that Manjaro had a special repo override for system packages that lags 2 weeks behind upstream. Omarchy tempts the same fate by stacking custom packaging channels and pacman scripts on-top of a system that gets advertised as "regular" Arch Linux.
Distro variety is always a good thing, but there has always been different levels of commitment to it. If I was putting together a Linux system for a kid or someone elderly, I'd just give them Fedora/GNOME instead of trying to get them into larping r/unixporn.
Personally, I wouldn't recommend any Linux distro other than Manjaro with XFCE, for a non-expert, because it just works and installing software is a breeze with Manjaro's graphical UI (pamac).
I've been running various Linux desktops since the late 90s and every single distro without exception has eaten itself from updates...except for Manjaro which I've been running exclusively now since 2018 without so much as a hiccup.
Two-week old packages is nothing. The most popular Linux distributions aren't even rolling distributions and they'll have you using packages that are years old.
Of course, because prescribing pills is the sole job of a psychiatrist. Go to a phycologist or therapist of you want to try to talk it out. If talking doesn't work, they'll send you to a psychiatrist for medication.
> The primary purpose of code review is to find code that will be _hard to maintain_.
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.
It would have been very easy for older religions to present strong evidence for divinity: just have some explicit, non-trivial facts in the holy book that were unknown to humankind when those books were written, like earth-moon/sun distance, speed of light, etc.
Complete absence of anything like that is a pretty strong indicator by itself...
Written in 1802, before the Jacquard loom. I wonder what machines he had in mind? "Modern administrations, busy trying to provoke the invention of machines that can multiply human labor and make it easier," apparently.
> Now back in the 80s? Back in the 80s, despite being aligned with the West, they were perceived a lot like China is today. Everyone was scared that they were going to start eating the West's lunch and various negative stereotypes and exaggerations started to bubble up: it was a futuristic land, but a futuristic land of suicides, with little drone-like salarymen crammed into little shoebox apartments the size of a Western bathroom, working 20 hour days.
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.
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.
reply