Lately, much of my off time has been pre-occupied with a great experiment. A few weeks ago, I decided to finally pull the trigger on a Switch 2, my first time owning a Nintendo system since the SNES and GameBoy Color, and my first time playing on one since the N64 was still a smash hit at parties.

For the most part, it’s been a positive experience. I love that it’s a much larger screen and less hefty device than my original SteamDeck, not that the battery life is significantly different. I’ve found it remarkably nice for playing handheld on the couch, and has actually caused me to use my SteamDeck in handheld much more frequently. Unlike my laptop and ‘Deck it can actually be docked in the TV console upstairs without making me grumble about the tight spaces, which is also a plus.

In terms of graphics and power, it’s kinda of a “Meh” factor. Many of the games already out on the platform encompass things that have had Steam and Xbox One / PlayStation 4 releases. Often ones that also run on SteamDeck either perfectly or with a little fiddling. The difference of course is the Switch 2 is more apt to target 1080p, which makes me happier because I often play docked to a large 4K screen. I consider the main advantage there that it’s now “Good enough” hardware rather than as limited as the Switch and its revisions. Plus, nVidia’s DLSS tech and stuff is definitely better.

Hardware has been pretty solid, but I have to preface that with “Depends on what you play.” The Joy Cons 2 seem to be pretty decent controllers for handheld mode, but not as good as Steam Deck’s superb (but integrated) controller. For more FPS oriented games like Resident Evil, frankly, the Joy Cons 2 sucked so bad that I turned right around and ordered the Pro 2 controller. That’s closer in quality to an Xbox One or Series X/S controller. I honestly don’t care about the detachable controller aspect, but if you’re more prone to playing games like Pokemon and Mario than games that require fast, precise aiming (basically any first person and most third person shooter), they’re great for the former and crap for the latter. On the flip side, gyro aiming support is actually native for many Switch/Switch 2 titles.

One of the things I’ve been happy for, is that the eShop has a much larger variety than I expected. Quite a few games I’d play are available through the Switch back catalog, except I already have them on other platforms. I was a bit concerned that options would be smaller beyond Nintendo’s own first party releases.

Game Cards, I remain somewhat on the wall about. For games that actually use them, I don’t really mind. The downside of course is that many third party games are either digital (shop / code-in-a-box) or Game-Key Cards. For those, the only real value IMHO is the second hand market. You can trade in the card, but unless you’re frequently trading 3-5 games whenever you buy 1, it’s probably a bigger deal when for you cash out. I.e., if you migrate to an incompatible platform like PlayStation, it makes sense to dump the games with the console. That said, my childhood is proof that trade-ins and pre-owned are a perk when money is tight. In which case, you probably should get anything other than a Nintendo Switch–the games are frakking expensive.

Conceptually, I like the idea of Game Cards. They’re a similar size to full SD cards, making them practical in ways that a MicroSD is too damned tiny. Likewise, that avoids the problem that earlier Game Pak / Game Card are too bulky when you’ve got a lot of them to carry. Honestly, I’ve never been a fan of the install to hard drive model for game consoles: may as well use a PC and pure digital distribution if that’s how it is.

Of course the reality is the inverse. For first party games, the benefit is much smaller updates. For a game that’s around DVD/DVD DL scale, the update might be closer to 500 MB stored to internal storage. That’s been the case for Mario/Zelda/Pokemon games that I’ve tried so far. IMHO, that’s a fair compromise for saving 4-8 GBs per game.

For third party games, the reality is you may as well be digital and expect to have to download the entire thing. On the flip side, I’ve found that games are often smaller. Many are in the HD DVD to Blu-ray SL scale as opposed to Blu-ray DL and up, meaning they’re well suited to a 16G or 32G Game Card if they actually used the card for storage. It seems many publishers have dropped unnecessary assets when baking games for the Switch platforms.

For example, Resident Evil 9 is a Big Freaking Game™️ on Steam if your storage is measured in GB, but basically a standard size for modern games. If you like PC gaming, you measure your storage in TB, not GB. It’s about 80 GB on PC, and I had expected it to be over 120 GB when I pre-ordered. On Switch 2, it’s under 30 GB! There’s some irony in that as well. On Switch 2, we’re basically running a DLSS upscale to 720/1080p from about half that resolution. Docked, it’s no where near as nice as my laptop’s 4K output. I wouldn’t be surprised if SteamDeck offered equally limited graphics at best, but you’re still stuck downloading the entire shebang because the game’s assets have to cover everything from the lowest supported potato to the beefiest they’ve got.

That’s actually one thing I kind of like about consoles, since it’s a stable target, you’re basically locked, cocked, and ready to rock from the beginning. No fiddly. But, it’s also going to be inferior rendering to a beefcake PC that can throw 3 pounds of RTX at the problem. For me, it’s become more about input methods in many cases; e.g., I greatly prefer to play certain games with a mouse and that typically leaves PC as the only platform. Playing Doom 2016 on an Xbox One for example was a painful experience compared to PC, where the controller is optional.l

Well, that’s enough rambling for now.

Meet the new Intel, same as the old Intel

While playing DooM on Xavier, eventually I found my speakers through the dock resetting every few minutes. Of course, I couldn’t help but wonder if this was the system having a problem or because of using Chocolate-Doom as a Flatpak. But nope, just an old familiar pain.

Mar 11 01:51:11 xavier kernel: i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A (start=115216 end=115217) time 161 us, min 1192, max 1199, scanline start 1188, end 1200

Actually, compared to what great fun Skylake’s Gen 9 graphics chips were to fuck with when they first came out, I probably should count myself lucky that this machine’s Xe / Gen 12 based stuff has been relatively stable under KDE/Wayland. Also in retrospect that nothing went worse than the audio getting cut off.

Project Xavier

Recently, I’ve made another shift in my hardware. My Alpine powered X61T (aka Hill, after a certain S.H.I.E.L.D. agent) is now officially retired and my W10 powered E6430S (aka Stark, after guess who) returns to retireee status.

In their place, a new “old” ThinkPad X1 Carbon takes their place. It’s a Gen 9, making it not so terribly obsolete at running modern software as Stark’s 14 year old processor. Compared to my X61 and T61 it also avoids that “Oh god, it’s the world wide web!” impact of using a web browser on a 21? year old processor. Actually, I think its the only time I’ve had a ThinkPad that isn’t considered thrift store vintage.

For lack of better ideas, I’ve named the system Xavier after Professor X. Both because it’s a 5 year old machine and because it’s purpose is to be an experimental secondary machine. Given the relatively modern processor, its initial operating system is Fedora Kinoite–something not to ancient, and theoretically not too easily broken.

On the hardware front, I’m finding it quite nicely. It’s an i7-1185G7 model with mid-level 16G of RAM, meaning that it has the same limitations as a development machine that Stark had, but can at least handle the ungodly heavy load that web browsers have become since Ivy Bridge. More useful to me personally, is it’s equipped with Tigerlake-LP chipset offering Thunderbolt which makes it possible to use my CalDigit TS4 alongside Shion and Ranga. For bonus points, i don’t even need a special charger, haha! Personally, I’m not a fan of ThinkPads, but they’re great machines to buy used especially if you can get a good deal.

Software wise, I find things a wee bit more of a mixed bag. Being an rpm-ostree based distro, system updates are quite stable. The actual user experience is a bit more akin to any problem can be solved, if you’re willing to delete your user account and start from scratch, or spend a few hours debugging which file in your home directory fucks the whole thing. On the flipside, it does actually work quite well most of the time, and it really is meant to be a test bed machine. If I assigned my computers a registry number rather than a hostname, it would probably have a Y or X prefix to it. It remains to be seen if I’ll transition the machine over to FreeBSD/OpenBSD or good old Debian, but we’re see how it goes with the atomic respin.

The great parting between VLC and my TV

A while back, I did a bunch of video tests when ripping one of my favorite movies didn’t yield the usual results. This was actually, so crappy, that it lead me to reverting to x264/AVC encoding for later rips. Yes, it was that disappointing. But, I think I’ve come to conclusion the problem isn’t with x265–it’s somewhere between VLC and its handling of iOS based platforms.

One thing each of these tests shared was its reference view: my TV downstairs streamed via VLC. And lo-and-behold, it would rear its ugly head again. Recently, two projects for home improvement have come up.

First, is looking for a VLC replacement on iPad. The USB related woes I posted about with iPadOS 26.2 boiled over, causing me to both cease using VLC+USB on my iPad. It’s just so fucking bad. I’m inclined to believe this is either Tahoe or its support for APFS externals, anyway, it’s a road block enough to drop VLC. Something that’s been a staple since my Android -> iPad conversion now quite a few years ago. This lead me to adapting Infuse Pro as a viable replacement candidate. It experiences the same USB problems, and testing points the finger at Apple’s biscuit eating operating system in that regard.

However, that lead towards project number 2: I recently finished watching Picard seasons 2 and 3. Also, one of the few times I’ve used an actual Blu-ray player. After enjoying that, I opted to splurge on Star Trek: The Next Generation while The Complete Series edition Blu-ray set was near its 90 day low price. It’s one of those really-wants but never-gets. Because it’s expensive. Even on a great sale, we’re still talking like $100. I’ve only waited like a decade or so!

Well, watching the first disc or two on Blu-ray player wasn’t so bad. But of course, me being me, the longer term goal remains file server -> stream all the things. Honestly, the box set is a pain to jockey discs around. We’re talking about 6 BDs per season, packed line sardines, and with two or more discs per spindle. Yeah, screw that. It’s also a enough of a slog to rip though, that I created a new HandBrake preset with a modified audio selection scheme to expedite the processing.

So, imagine my surprise when I start to notice artifacting issues–using the same x264 reference. We’re talking wtf is this kind of artifacts. I nearly switched Hide and Q over to disc by the time the Enterprise-D reaches Q’s barrier. That’s circa the first 5 minutes. I wasn’t happy.

This lead to some further testing comparing video playback on my laptop (perfectly fine) and streaming to the Android version of VLC on the younger TV upstairs, perfectly fine. I’d consider choking up the latter to how modern TVs post-process video, but the same can’t be said for my PC monitor, which like many PC monitors doesn’t have those goodies. That testing was also dominated with IINA, basically a Mac version of MPV that isn’t annoying to install. My PC based laptop also had no issues. The only problem was the Apple TV, in VLC.

Deciding to try things a bit more scientifically, I made a reference conversion with x265 (HEVC) and a few encodings with Apple’s Video Toolbox in various H.265 and H.264 mode, to compare to the original x264 reference. I also uploaded the original MakeMKV rip, i.e., the full unadulterated Blu-ray video quality. It too sucked ass and artifiacted when played in the tvOS version of VLC!

Now, that’s where both home improvement projects intersect. Deciding to try Infuse on the Apple TV was going to be an experiment, and the Plex like TMDB integration made it worth installing for later testing. Faced with the issue with my ST: TNG rips, I decided to test this again. It’s there, why not try another data point? I really wanted to try another video player for comparison at this point.

This was followed by shouting and cursing, because it played fine. All fucking versions. As long as I didn’t use VLC to do it!

The outcome of this experiment has also lead to an unexpected shift. Since eliminating VLC from the picture solved the artifacts, I took a closer look at the hardware encoded files. The winner of which was made with one of HandBrake’s built in presets on Mac, which configures a 10-bit H.265 encode at CQ60 in quality mode. Not as high as the Video ToolBox tests I did with Pacific Rim in speed mode, but sufficient that ST: TNG looked good enough across data points to consider worthy of adoption. So, I’ve integrated a variant of the same profile I was using with this in place of x264. I was always a little miffed about the HEVC thing, but I now am pretty sure it just amounts to never use VLC on anything iOS-derived. Sorry, good ol’ x265. But on the flip side, I’ve also changed gears.

Results? Encoding time dropped to an average of about 4¼ minutes from around 20+ minutes per episode, while presenting similar quality and file sizes curtesy of the newer codec. This is a fairly drastic shift, delivering the joys that are +200 fps to encoding times but not having to tank file sizes to maintain the quality. Based on the results for my ST: TNG tests, sans VLC, I’m considering adapting this as my new ‘standard’ for video encoding instead of returning to my x265 reference point or sticking with my older x264 reference point.

Coming across “I transcribed hours of interviews offline using this open-source tool” in my news feeds, I can’t help but wish this approach to applied AI was more common in this era of ChatGPT.

There’s plenty of reason to run models in a cloud context, particularly if you want to have truly large or complex models. The more computationally invasive the task, the more a data center starts looking smart—ditto if handling many users. But that doesn’t mean it’s not possible to do useful things with LLMs on commodity hardware.

The catch of course, tends to be the need for a powerful computer by modern standards. PrivateLLM’s quantified models for example, range from models that probably fit on several year old iPhone (15/14 series) to a pimped out Mac Studio.

Considering that many Intel/AMD chipsets over the past decade max out in the 16-64 GB of RAM range, and that you basically need 16 GB in a modern laptop, I think people underestimate the possibilities for squeezing smaller models onto PCs for specialized tasks. Especially when given modern computer hardware. I mostly feel that the drive towards NPUs is marketing snake oil, but to be fair, it’s pretty unlikely that we’re going to start seeing beefier GPUs in the typical computer. As impressive as modern integrated graphics have been compared to when I was young, common designs still fall far short of even laptop dedicated graphics, never mind six pounds of RTX!

Here’s at least, hoping that those fancy ASICs see some useful value rather than being today’s equal of the Transistor Wars. If nothing else, I suppose it helps bring the base of installed RAM a little higher in-between price hikes and push faster CPUs and SoCs down people’s throats.

The backup strategy

Since my file server adopted hardware RAID as part of its 2024 refit, and even the mdadm array that preceded it as part of the original 2023 design, one of my concerns has been the need for manual backups. It’s at least a process that’s been tested under fire during the Thinkpad to the face incident. But, I’m never been a great fan of manual for what should be automated.

The process remained largely the same, aside from the drive’s contents exceeding the capacity of one of my spare drives, leaving me with only one external drive sufficient for backing up. How often I actually managed to ensure both drives up to date aside, it’s generally been a bigger priority to take care of things that backup to the file server on a nightly basis.

Well, one of the upside of the transition from Rimuru to Ranga, is it’s effectively seen my Steam Deck decommissioned from /dev/tv to its storage case. As such, the external drive used for augmenting my deck’s internal drive and microSD card, became freshly available for repurposing. A drive that quite conveniently has the same storage capacity as my file server’s RAID array.

An upside of the Christmas break, I was able to find the time to setup the drive alongside the file server. It’s now a backup target, the entire RAID array being rsync’d daily via cron. My largest external SSD (only half the arrays size) remains an additional backup, and my frequency of go plug it in / run the backup script / unmount will still likely average a monthly or bimonthly ad-hoc affair.

The difference that makes me somewhat happier though? This solves one of the annoying problems: location. As an extra incentive, the external SSD has generally been kept nearby Zeta, so that it’s safe as the server. Since its smaller compadre graduated to being too small, no onsite backup has been stored in a separate location. Now that there’s a drive dedicated for daily backups of the array, my external gets promoted to ‘stored across the building’ status.

Because it’s always bugged me when the backups are right next to the machine being backed up. Like that never goes wrong? 😑. That’s exactly why a subset of the data deemed critical is deemed offsite required. But it’s still nice to have the full backup in a physically separate location, because ya never know when that is going to come in handy in a pinch. One of those days, it’ll probably get upgraded to being the offsite backup.

Ahh, here’s hoping I don’t end up buying hard drives next year….

Reminders that Apple hates iPad users

So, for a while now I’ve been pretty pissed off with the iPadOS edition of Tahoe and how it handles files. At this point, I’m pretty sure that it’s just broken and I should hope for iPadOS 27.

The first indication of woe, the canary if you will, was VLC being a steaming pile of bantha poodoo. Now, admiringly, VLC on iPad is pretty crappy compared to how awesome it is on basically every desktop platform, and even a few TV centric ones. But its problems are in terms of usability and features. Also, sometimes getting shafted by the platform.

For a good while, I’ve noticed that VLC would lose access to files on USB. Initially, it would play content, but subsequently picking files would fail to playback when trying to access the files. At first, I actually considered the drive could be going bad, but this was ruled out by using other devices.

Simple solution to that of course is one of my network’s core resources: a file server, ya know, that thing that’s cut down on the amount of removable media that I’ve needed over the past fifteen years. VLC seems to work fine with that.

Then enter the “Why the fuck can’t I actually edit a text file” problem.

Trying to access files in the sense of Files -> app works fine. But the pipeline for saving them back seems to be broken. At first, I didn’t spot it, since the editor I was using falls back to saving to its application folder rather than throwing an error–yeah, that’s stupid. But it’s at least pretty obvious when you go open the file somewhere else (or even on the same iPad) and it’s missing your changes.

So, for sake of sanity, of course I tried a different editor and this was effectively the same. Except that one didn’t fallback to its application folder. At this point, I was pretty sure that it’s either the Files app or iPadOS’s APIs for brokering file access.

The part that removed all doubt, in what I’ve been suspecting since the issues with VLC started. The same thing happens when using my USB drive :).

There’s also the stupidity where attempting to paste another file over to the file server results in Files throwing a permissions error. While connected to a share with the exact same credentials my other systems use and successfully, ya know, edit and create damn files. I consider that double confirmation.

Ahh, sometimes I wish iPadOS was worth a damn. The only thing truly unique versus other tests is that it’s running iPadOS, where my other points of reference are running macOS, Linux, and NT–and just work fine.

Afraid its permanent

When you end up dragged out of bed, half asleep, and you still have the wherewithal to school people on more efficient basic usage of vi, you know that vi is now embedded permanently and deeply in the very fibre of your being.

I had some suspicion that the muscle memory wasn’t the only thing that is etched into me, but any doubts that I had, are now gone. vi is firmly paste the “You can pry it from my cold dead hands” level of integration.

From Rimuru to Ranga

Increasingly, I’ve been turning my mind to what will come after Rimuru; a machine that was originally built in 2021 using the COVID-19 stimulus as its foundation and the same general design of its predecessor, Centauri. Since then, it has undergone 6 refits between Rimuru experiencing a motherboard failure in addition to ordinary tech updates.

Simply put, the status quo for the last few years has been that only one slot on the board is still functional, and the intention was that there would be no third motherboard if it fails. Combined with what is now a 5-year-old Core i7, the single slot of RAM has proven to be the key bottleneck. Ironically, getting Oblivion: Remastered to run was more an exercise in getting the GPU load to a point where the CPU isn’t pegging out.

It’s also been a downside that between the old CPU being well loaded and the Big-Assed-GPU both cranked up practically turn the machine into a space heater. I decided the machine to handle sustained load while keeping system thermals under control. The catch-22 of course, is I can easily find myself sitting in a room that climbs towards +10 degrees after a long spell of gaming, like playing Silent Hill f over the weekend.

Following Maleficent, I considered swapping the GPU and NVMe drive over to Zeta, and converting it from a file and virtual machine server over to Rimuru’s successor. That actually was how Centauri had become my previous desktop. Of course, breaking down and cracking the case revealed roughly what expected to be with that plan: I could fit the PSU and the cooling system, or I could fit the GPU. Zeta’s PSU would be able to handle ‘technically’ fitting and powering Rimuru’s RTX 4070 Ti, but would require removing the liquid cooling system to accommodate the PSU. So, that plan failed.

One of my long-term plans over the past lustrum or so has been that Rimuru would likely be my last conventional “Desktop PC.” I’ve never really been a believer in gaming laptops, but it here we are.

Christened Ranga, since its job is to blow Rimuru away. Amusingly, using Oblivion: Remastered as a point of reference it delivers similar performance but the opposite bottleneck. Rather than being CPU bound, Ranga is GPU bound, but still firmly lands in the realm of pick your frame rate. Closer to 30 at Ultra/4K or closer to 60 at Medium/4K, and a pretty slick 40s-50s at High/4K.

A bit of rewiring all the things, and my dock is now situated underneath the monitor rather than within a passive Thunderbolt 3 cable length of the desktop. Somehow, the part that bothers me about this arrangement is that a 2 meter long active Thunderbolt 5 cable cost about the same as my shorter TB3/TB4 cables did, while being rated for 80 Gbps/240W, far higher than my dock can handle. On the flip side, for cooling purposes a small stand was necessary to ensure proper ventilation.

In tests so far, I’m finding that the Zephyrus G14 is a sufficient match. Its RTX 5070 Ti mobile just can’t match the horsepower of the RTX 4070 Ti desktop, but it comes close enough that no loner being bottlenecked on the Core i7-10700K and single slot resolve that pickle. It’s Ryzen AI 9 HX 370 both represent a major generational leap in performance, and while the RAM remains comparable, it isn’t so limited: so yay for being back to dual channel memory!

As an added benefit, when putting Shion in place to be my primary computer, I no longer have the problem of not being able to see where the fuck the port is, since it’s no longer facing the wall. I kind of liked having my laptop off to the side as previous, but the occasions where I actually use my laptop as a notebook PC make it grumble some to reconnect. More so than swapping between TB cables at the dock. Now? It’s simply swap laptops in the stand, a single cable running to the dock.

Another benefit is proving to be the heating. The Zephyrus G14 is very rapid to crank its fans into high-gear when gaming, to the point that one might want noise canceling headphones rather than speakers for some content. But it doesn’t raise the room’s ambient temperature as drastically as my desktop, and frankly, the late generation MacBook Pro 16s had louder fans :-P.

One of those random backlog of things to write my thoughts about

Bumping into “Apple found clever iPhone Air innovation for a thinner USB-C port” a few weeks ago, made me rather do a double take.

Also, it made me rather try to imagine what the engineers that worked on the F-14 Tomcat must have suffered. Electron beam welding a wing box from titanium, along with the more general “How the hell do we even build that” problem, were among the challenges back in the ’60s. A time frame where these solutions were more revolutionary than antiquated. We mostly remember those planes for the swept wings and cool movies, but I bet the engineers who worked on that wing box remembered it as a challenge of a lifetime 😅.

And then fast forward about sixty years, and we have people talking about 3D printing titanium.