I pushed my http[s] RESTy client and server to github yesterday.  It’s almost there.  Today, working on favicon.ico support.  Cmon!

Persistent notes will go on the wiki.

emerge -DavuN mariadb

Yep.  That’s it.  Portage will remove mysql and perform a drop-in replacement of mariadb.  Everything just works.  Between mariadb’s API decisions and the gentoo team’s work on portage, that was impossibly collaborative and well-thought-out.  THANKS ALL!

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.

Visual Studio started CLOSING on me as I was editing due to my apparent change in status at some far-flung location for which I have no control. If Microsoft thinks that’s a feature I want in my primary development tool… well, all I have to say is, never again will I rely on it. Eclipse is a decent IDE and I’ll be converting my muscle memory to its ways after a couple decades of baking Visual Studio into my hands. It may be painful but it is also long overdue.

1. Install Eclipse
   1. I went for the PHP version (“PDT”) since it seemed to have a few bells and whistles (eg git)
   2. The C++ support in Eclipse is called “CDT” and  you can install it by adding this “Work with” repo: http://download.eclipse.org/tools/cdt/releases/kepler
   3. I installed “CDT Main Features”, plus optional Memory View Enhancements, Misc Utils, Multicore Visualizer, Qt support, (ironically) Visual C++ support, and Visualizer Framework.  Not sure about these, time will tell.
2. Configure Eclipse
   1. The biggest startup challenge is setting up key shortcuts.  The default ones are pretty stupid if you’ve used Microsoft products.  The main thing to remember is that you have to search for existing shortcut keys and manually remove them before you can add a new one, otherwise you will just get conflicts and nothing will work.  This sucks shit but not too bad once you realize what is going on.
   2. Set UTF-8 encoding:

      Windows > Preferences > General > Content Types, set UTF-8 as the default encoding for all content types.
      Windows > Preferences > General > Workspace, set "Text file encoding" to "Other : UTF-8".

3. Set up projects
   1. Open C++ perspective
   2. Right-click project pane, New…, Blank Makefile, Other toolchain, use existing codebase location for workspace
   3. Search…, Working set, Choose, New, Resource, Name = codebase, click on existing codebase location, OK

More to come as I work with it. I’m moving the notes to the wiki.

I’m a cross-platform developer, with about 17 different development environments. Most projects have a remote central team repository. git lets me cast my code out to all my local locations and effortlessly remained synced with the team repo. In addition, I can work exclusively in my local repos, as long as I need to, without touching the team repo until I’m ready to push my stuff to it. I’ve refined my process down to just the right number of branches to accomplish this. Here’s my git bliss:

First, set up a local centralized repo:

ssh me@my-central-repo-server
git clone ssh://me@the-team-repo/big-project
cd big-project
git branch daily_grind # create working branch but do NOT check it out

Next, set up a [git merge-to] command (huge THANKS to this gist):

emacs .git/config
  [alias]
    merge-to = "!gitmergeto() { export tmp_branch=`git branch | grep '* ' | tr -d '* '` && git checkout $1 && git merge $tmp_branch && git checkout $tmp_branch; unset tmp_branch; }; gitmergeto"

Now we can set up a clone in many new locations – repeat this on each dev box:

ssh me@my-laptop
git clone ssh://me@my-central-repo-server/big-project
cd big-project
git checkout -b daily_grind origin/daily_grind

This location is now a work site. Work in the daily_grind branch. Always pull before you get started working, and push when done:

ssh me@my-laptop
git pull
# work work work!
git commit -a
git push

When you are ready to share with the team, all your commits from all your dev locations will be in your central repo, in the daily_grind branch. Just merge your work with the team’s:

ssh me@my-central-repo-server
git pull # to get the team's latest
git merge daily_grind # to merge in your latest
# resolve any conflicts
git push # to push your changes to the team
git merge-to daily_grind # to push team changes to your work repo

If there were any team changes, you’ll get them in your local repos the next time you pull.

And away we go.