Browsers are here to own our desktops. But they will never deliver the absolute horsepower of a natively-coded world-class desktop app or game.

These days, when you try to run one, you will find it is crippled by the browser’s 100 open tabs (admit it, you have that many open…). And lord knows you don’t want to close them all.

I am the user. I am the king. Not the last 20 sites I happened to browse, each of which is allowed to take a huge chunk of our system resources for whatever task they deem important. Once you’ve rabbit-holed down a few holes, you have given your entire system resources to them.

Don’t put up with this. OWN YOUR OWN SYSTEM.

To really take it back when you need to play a game, work in your DAW, or play a 4k video at high frame rate, you need that browser to give up ALL its resources. And in linux, that is super easy.

  • Find the parent browser process pid:
ps ax --forest| grep "[0-9][\_ ]*/usr/lib/firefox/firefox$"
  • “STOP” it. This is the magic that tells linux to just stop serving the parent process and all its children, stripping all CPU allocation from the tasks, without actually closing anything (especially your precious tabs scattered across all your virtual desktops). It’s amazing, it will freeze your browser in its tracks in an instant:
kill -STOP #pid-from-previous-step#
  • Start your powerhouse desktop app and do your thing.
  • When you’re done, you can “CONTINUE” the stopped process, kicking off the CPU to immediately start servicing all that javascript again:
kill -CONT #pid-from-previous-step#

I’ve scripted this up so I can press a media key to “stop” firefox and start up Kodi with beautiful performance. Here’s my javascript “continue” script, which uses my rad-scripts tooling:

#!/usr/bin/env node
import * as rs from 'rad-scripts';
const ffPs = rs.run_command_sync('ps ax --forest| grep "[0-9][\_ ]*/usr/lib/firefox/firefox$"');
const ffProcId = +( ffPs.trim().split(' ')[ 0 ] );
console.log( `Parent firefox pid = ${ffProcId}` );
rs.run_command_sync_to_console(`kill -CONT ${ffProcId}`);

Once you get into gentoo python dependency issues, it can be a long ugly haul out.  For this one, I had to clean out hundreds of lines in packages.keywords that portage had added over the years, rerun it to let it add a bunch more lines, run dispatch-conf to accept them, and only then get past my blockers.

I believe I have lived and loved and learned and I’m ready to let someone else manage my linux package dependencies.  For now and foreverer more.

I love you gentoo but I fear I must break up with you.  For my sake, not yours.  So long and thanks for all the compiles.

I landed a nice gig writing a cross-platform C++ server to perform outage analysis for a smartgrid software package, using web services to communicate with the other components.  It started out completely cross-platform, and had me at leveraging all the goodies of the latest boost libraries to do a lot of the cross-platform sweatshop work.  But like many other projects, the idealism of the clean-slate design soon gave way to focusing on getting it done, and the project became dependent on Windows-only components.  Bleh.

Unfortunately, this left me using primarily a Windows development environment on my desktop during that push of the project.  Now I’m focusing on a mobile stock-trading app, with the first two components being an Android app and a corresponding cross-platform C++ server.  Bottom line: it’s time to bump up my desktop gentoo installation and get it humming again! (continued…)

Technology in the early 21st century is here to kill us. It stresses us out and shortens our lives and makes us feel like failed Neanderthals every single day of our lives.

We are drowning in data yet no one controls theirs at all. At best it happens to be properly backed up at someone else’s cloud location for a short period of time before that fails or the company goes bankrupt or inevitably tries to extort money from you.

The solution to taking control of your own data must involve massive local redundant backed-up storage (MALREBS). There is no other alternative. And this is a technically impossible task for 99.99% of the human race. In this day and age, everything precious to you is stored either by someone else who really doesn’t give a shit about your data, on ridiculously flaky steel platters that randomly fail while you are sleeping, or solid state drives that wear out from the second you start using them. But here we are so let’s struggle on to get it done.

One required component of MALREBS is raid. This turns those flaky hard drives from 100% chance of total failure to perhaps something less than 90%. This is very very important.

There is only one raid solution to rely on. Linux software raid is the only solution that is both free (in all senses) and reliable, in that you can take your hard drive data with you from a very old (possibly non-existent) system to a brand new system and have a reasonable expectation that the data will still be accessible.

But here’s the rub: mdraid has not received the polish it needs to Just Work. It has serious flaws that after hours of learning, still leave you unsure and hanging and most likely bailing out of the entire process. But it is the best thing we have on the planet, so let’s distill it down to the essentials.

  1. check S.M.A.R.T. data of drives – run tests and make sure they are completely healthy!
  2. clean raid drives of superblock and partition data
    mdadm --misc --zero-superblock /dev/sdd && dd if=/dev/zero of=/dev/sdd bs=1M count=100 && mdadm --examine /dev/sdd
     mdadm: No md superblock detected on /dev/sdd.
  3. use whole drives (not drive partitions) in a newly created raid
    mdadm --create --verbose /dev/md0 --level=mirror --raid-devices=2 /dev/sdd /dev/sde
     mdadm: size set to 3906887488K
     mdadm: automatically enabling write-intent bitmap on large array
     Continue creating array? yes
     mdadm: Defaulting to version 1.2 metadata
     mdadm: array /dev/md0 started.
    watch -n 1 cat /proc/mdstat
    # wait 400 FUCKING MINUTES for a GODDAMNED EMPTY 4TB DRIVE to sync with ANOTHER empty 4TB drive, FUCKSAKE
    # IF YOU REBOOT BEFORE THAT, IT WILL BE AS IF YOU NEVER SET UP A RAID
  4. save and reboot and make sure the mdraid service restores the raid
    mdadm --detail --scan >>/etc/mdadm.conf
     rc-update add mdraid boot
     # start then stop then start the /etc/init.d/mdraid service, make sure this works to restore your raid (check /proc/mdstat)
     # format /dev/md0 as ext4 and set up an auto mount point in /etc/fstab
     # reboot and pray
  5. hopefully much later, upon failure, to restore a single drive, set it up as a raid:
    madadm -A /dev/sdd # I THINK! it's all very iffy. Which SUCKS.

I reguarly beat the everliving crap out of samba. It was not happy with me after my last upgrade until I moved up to soft-masked versions. These were borked:

  • samba 3.6.16
  • cifs 5.9-r1

These are working at the moment:

  • samba 3.6.19
  • cifs 6.1-r1

I’m still getting random errors like this but I have read they are OK to ignore?? wtf…

Oct  5 09:19:22 thedigitalmachine kernel: [ 2323.197507] CIFS VFS: strtoUTF16: char2uni of 0xffffffb0 returned -22