Windows

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.

First impression of Edge 80, based on Chromium:

“Holy fuck that’s fast”
“Is this powered by nitromethane or something?”

The main reason that I had converted my games machine back to Chrome was thanks to Edge being flaky release to release about my tab change / load habits, which could vary from smoother to an effect like watching the GUI thread block for background tab loads or something. Moving it back to Chrome was mostly to get performance that was consistent.

In the time that I used Edge on that machine, I was otherwise very happy with it as a browser. In fact if they had been more consistent, I probably would not have bothered to change things around.

With the move to a Chromium base, I doubt that there’s much reason to care anymore. The only reason that I’m actually left to care about is the bookmark and history syncs with my Debian machine, and I don’t really do that much with bookmarks anymore. Most interesting history bits can probably be solved by Google’s activity page, since doing anything in Chrome’s history usually rolls as “Gah, crap, I’ll just type a search term”, lol.

Windows 10X: Everything you need to know about the foldable PC OS
https://flip.it/tk_HYE

I for one, am more interested in foldable devices like these than ones we see harped on in phone space.

For me, there’s only two points of interest in a foldable phone. Either one that “Pops” open into a tablet, around the size of a Nexus 7 or iPad Mini; or something very compact ala the old Motorola Razrs. That’s about it. I don’t really want or care about most of the other things that have come up in phones, nor about a seamless display.

Now when we move into the size of a tablet or laptop: my tune changes! A device that can be the size of one, or two iPads; a device that can be a massive tablet or a dual screen book, that’s something I could use. I’m less interested in a seamlessly folded one piece screen than I am a layout more like a notebook with a thin bezel at the spine. See, PC operating systems like NT have better handling of multiple displays than contemporaries like Android and iOS. It’s a faster leap to abusing two screens if your starting point is something like Windows 10 than Android.

I want to see productivity gains from having two related, but not unified displays. It’s less about having a 14” tablet that can fold in half, and more about how two monitors that can interact—touch screen monitors, running mature software.

Microsoft is updating one of Windows 10’s oldest apps – but you won’t like the change

When you consider that Office is one of Microsoft’s big money makers for client side, and the main competition in browser space is an advertising company (Google), I’m not inclined to hold it against them very much. You can always install Libre Office or  Abiword if you really want free.

Rather: I’m just glad that Notepad gained support for Unix style end line markers. Most use I’ve had for Word Pad since the fall of 32-bit Windows has been to view text files that aren’t in DOS format, on machines that aren’t mine, or are in the process of setup. Prior to 64-bit Windows becoming the norm for NT based systems, I’d usually use edit.com for that purpose: but support for 16-bit DOS applications aren’t included in Windows x64.

For the most part, I’ve found it very hard to care about PowerShell. But as time goes on, I mostly look at it with the thought, “Wish I had more use for that”.

Things that I do that require some scripting, and that run on more than unix systems, usually resort to creating .cmd or .bat files to handle the Windows systems. There’s mostly two reasons for that: execution policies and portability.

I don’t really like scripting cmd.exe. As an interactive shell, it’s barely livable but gets the job done. The focus on interactive mode, and the nature of DOS, show through in what can be done in cmd.exe. NT’s modern extensions and so on make it a lot better than COMMAND.COM but cmd.exe is not a good scripting environment, nor a great interactive shell: it just sucks less than its predecessors.

PowerShell on the other hand took some good ideas and largely addressed much of the suck. Exposing .NET even offers the opportunity to solve problems that would call for writing a solution in something beyond bash/ksh, or finding dedicated utilities for. It is really neat the amount of shit you can do in a PowerShell script.

But in the end, the default execution policy is what really keeps me away. Open sourcing and cross platformyness stuff in Core 6.x resolved most of my negative feelings for PowerShell, but it doesn’t suit my scripting needs.

By default: client systems reject running PowerShell scripts, and so monkeying with execution policy is needed. Either to unrestrict it for the current  session or my user. Which makes using it for projects less useful than using the older comspec. Because while cmd.exe is very meh, it doesn’t require any extra monkeying after I’ve git cloned my repo. Yet another thing to do when setting up a system, or document about a code base, that I don’t need.