Passing thought: we’ve increasingly lived in a world of long file names since the 1990s, yet out of convenience: we still tend to create three character file extensions whenever we pull new ones out of thin air.

One almost has to wonder if three is especially magical, or if humanity is that lazy. I would like to think it’s just enough bytes to convey the majority of information, and still appease every lazy git alive. Because no one likes file names, or file extensions the length of a sentence 😣.

How to Customize the Look of Your Cursor in iPadOS 13.4.

This was something I had hoped would be possible after messing with the new mouse support. The default cursor is rather too damned tiny for my tastes, which I assume is an artifact of designers with 20/10 eyesight or a Mac thing. But it’s waaay smaller than I’d expect, coming from Linux and NT machines.

A little bit of tweaking later, and it’s quite nice 🙂.

Step one: phone hijacks SMS sending to Android Messages, and disables function in Hangouts.
Step two: tablet can only sync my sent messages. Not getting incoming at all.
Step three: re-enable SMS / set default on my phone.
Step four: archive threads because now they’re two on my phone , and the other only gets a copy of mine.
Step five: send a new message from tablet.

Step six: remember that over the past decade, Google has gone from being one of my favorite tech companies to quite possibly the one that pisses me off the absolute most often. I really miss the days when their betas were more reliable than what the rest of us called release quality. Sigh.

Cursors on the iPad – MacStories

This transform ability has been a large part of why tablets became my primary computing platform. Android since Honeycomb, and iOS since iPadOS increasingly so, handle the whole mouse / monitor / keyboard thing pretty well.

Whether I’ve wanted a device docked that can be my work terminal, or to lean back on the couch, tablets have served me well. Aptly these are both environments where I’ll probably yell at you if you take away my keyboard, or force me to use a conventional laptop, lol.

Much of my advanced computer use revolves around an X-Terminal, so it’s been pretty easy to delegate other tasks like email and notes taking. Where as at home, I’m more likely to be focused on reading and messaging. Tasks that tend to benefit from either a keyboard centric use case with a big assed screen, or from a portable touch screen device.

Over the course of my life, I’ve mostly determined that a few things are relatively true about e-mail:

  1. Email is either the best or worst invention, probably both if you grew up with paper.
  2. All mail user agents pretty much suck.
  3. All standard protocols for dealing with mail are ancient.
Point one is something that I’ve concluded since the ‘90s. Point two is mostly internal bias. Point three should probably be considered fact at this point.

My Decade with the iPad: Upping the Ante
https://flip.it/-_vnWx

For me it was the Asus Eee PAD Transformer, the original model TF101. My Linux powered netbook had fairly limited battery life compared to the bottomless battery life of a docked TF101, and the desktop struggled under loads that Android breezed through on even less powerful hardware. On the flip side even the lowly netbook could compile code far faster, but couldn’t handle the rising UI load of modern web pages and desktop applications.

Or as I like to remember those days, if all I did was type notes into a vtty, my netbook would often be dead during one flight, and was mostly dead weight on longer trips. That experience traveling lead me to consider a rooted Android just for the battery life. The TF101 was kind of special in that it had a good battery life, and that it had a slightly smaller one in its clamshell keyboard.

The tablet with the keyboard dock had enough juice to take three planes, and fall asleep watching Netflix before needing to charge. After that travel experience, I went on to using Android pretty extensively as laptop and desktop replacements until last year.

Beefy endurance compared to Intel brought me into the platform for getting stuff done. Having an excellent lean back on the couch experience kept me using it.

An update to my previous post, but dropping priority to “Normal” mode.

General system responsiveness is normal. Handbrake’s average frames per second county thingy now goes to ~8.1 on average with extremes being more like 7.7~9.3, but it pretty well hovers at 8.1.

By contrast, applications like writing this post in a browser are now normal performance. It’s even possible to watch previous encode without glitches and artifacts in the decode. But things like writing this post cause more dips in Handbrake’s frame rate.

Overall, it seems fair to say “High” -> “Above Normal” priority loses 5% if you want a nice round number instead of a range for the average. “High” -> “Normal” priority loses 15% by the same method.

Where “High” = cripples the desktop session, “Above Normal” = makes the desktop session feel a few hardware generations behind, and “Normal” = makes it just another process.

I guess that solves that, lol.

A while back, I remember tuning the default priority in HandBrake’s preferences, back when I made the leap over to HEVC. Mainly because the encode times are so long on my old Core i5-3570K, and because I tend to leave such jobs running overnight.

Well, for curiosity sake I’ve decided to see how monkeying with this changes things a bit.

In my experience, nicing processes on my unix systems is rarely worth the bother. That is to say, a nice system like Linux this side of multi-core processors tends to remain pretty responsive, and most people I encounter screwing with niceness tend to be pissing down the wrong problems to start with. But NT is not unix, nor Linux, so who knows.

Looks like the default priority I had configured was “High”. Task Manager also shows a “Real Time” but that isn’t in the GUI.

Net result is Handbrake proceeds at a pace of roughly 8.9 ~ 9.5 frames per second. Which works out to being closer to 9 than 10. Set to high priority also means that while the encode is running my desktop session is virtually useless, as things like updating UI state takes a back seat to next Tuesday.

After the first item in my queue finished, and the next began: I lowered the priority to “Above Normal”. Impact on encode is roughly 8.9 ~ 8.3 frames per second on the average county thingy. So that’s a performance loss of about 3 ~ 6 percent, but my desktop session is actually usable. UI updates like the process table in task manager now update in something closer to real time than melting an Titanic sized iceberg with a zippo lighter, and general productivity is passable. Typing this post is about on par with running a web browser on an older computer. Small price to pay.

That roughly equates to the encode takes less than five minutes less, if I render my desktop useless until the task finishes. Provided current pace keeps. When the entire encode takes a bit more than an hour per episode, it’s kinda a meh perspective. Also a little nicer seeing my processor bouncing between ~70% and 99% in task manager instead of 97 ~ 99 %, lol.

I’m kind of reminded of XP, and my opinion that it could be very stable if you didn’t do nasty things (or need shit drivers) to it, but being user responsive when under heavy loads it was not. As beautifully as the NT desktop has evolved since then, I still don’t think melting a Windows box is as smart an idea as melting a Linux box, if you’ve really got to melt your system’s load.

When the third file starts encoding, I’ll probably try dropping the priority to normal and see what happens.