Saturday, December 15, 2012

Do, or do not.

Over time I've come to terms with the fact that I kind of don't look at the world the same way most people do. Back in grade school, there was a question on a test that asked "What do you need to bake a cake?", and I answered "A Birthday". The answer was sadly marked incorrect.

People make strange remarks towards me, from time to time. They're not strange in the sense that they're remarks normal people wouldn't ordinarily make, but more in the sense that they don't make any particular sense given the way my brain works.

Like, someone might say "You biked up a 4000 foot climb? That must have been very difficult." or "I don't get how you can understand all that math, it's really hard".

The fundamental problem is that I let go of the whole concept of "hard" or "difficult" a long time ago. When people say something is hard, all they're really doing is giving themselves an excuse to fail without feeling too bad about it. "It's OK if I give up, because it's hard".

That shit doesn't fly with me.

I don't put tasks into buckets labeled "hard" and "easy". For me, there is only "things I've already demonstrated, either directly or indirectly, that I'm capable of" and "things I have not yet successfully managed to do".

Much like what the title of this post alludes to, when Yoda told Luke "do, or do not, there is no try", he wasn't trying to be deep and metaphorical. He was trying to tell Luke that he was being a whiny shit and just making excuses for not wanting to succeed at doing what he was fully capable of doing.

I think it probably makes the most sense in hindsight. When you look back on a "hard" task, after having completed it, what are you left with? You are still intact as a person, essentially the same as before you started, and you have gained a completed task. What sense does it then make to categorize it as "hard"?

In short: stop giving yourself excuses to fail.

Monday, June 4, 2012

Life with a German, Turbocharged Two-Seater

So, let's start clearing out a backlog of news.

My beloved Jellybean, the green 1997 Hyundai Elantra wagon that has been passed around the family got passed around again. It didn't really make sense for me to import it with me to the US given it was starting to get a bit on the rusty side, so I needed to come up with a plan.

At first I had considered having all my crap shipped down by movers, and then renting a sports car to barrel across the US with, but there were logistical considerations with that plan that didn't really work out well, like what the hell I'd do to get around once I got to California and returned the rental car.

I also considered driving the Elantra down and having my sister fly down to pick it up (seeing as I was passing it on to her for free), but I wasn't completely thrilled with that idea either.

Finally I came on the idea of just buying myself a van. I'd be able to pack it full to the gills with all my crap, thus eliminating the need to hire movers; plus I'd be able to use it once I got down here for carting furniture and misc large items to my new apartment, since I'd be going on a bit of a buying spree so I'd have something to actually sit on. (this part has yet to happen, but the van will come in handy when the time comes)

The Mercedes(/Dodge/Freightliner) Sprinter was the first choice on my list. While it's much more expensive up-front than a Ford E-series or Chevy Express, it's got much more cargo space for a given footprint, is full standing height inside, comes standard with a sliding side door, and the diesel engine is much more efficient than the gas engines you're limited to with the lighter duty Ford/Chevys. It's really just generally a much nicer vehicle, and I like nice things.

I had a bit of a tough time tracking one down, given that the Fords and Chevys are much more popular due to their lower price, but eventually found one in Steinbach. I honestly wasn't very impressed with how the dealership treated me, so if you're ever in the market I'd suggest avoiding Steinbach Dodge, but in the end I managed to get my shiny white 2007 Dodge-branded Sprinter 2500 144 high-roof cargo, so all's well that ends well I guess.

The best part about driving a Sprinter, I think, is that when people ask me what I drive, I can just say "Well, I don't want to brag, but let's just say it's German, turbocharged two-seater".

In related news, I'm thinking of sticking this on the rear door.

So, that happened

I've officially moved to California. I actually got here almost a month ago, but was keeping things secret so I could surprise some of my friends here when I randomly appeared out of nowhere. The surprise happened, bricks were shat, and much fun was had by all.

Friday, May 18, 2012

Thanks, Windows. Thindows.

So the main drive in my wintendo decided to puke on me. I managed to catch it pretty quickly, so data recovery thankfully wasn't much of an issue.

I ordered up a new drive (twice the size, no less) on newegg and it arrived this afternoon. I popped the drive in and booted up the existing linux install, using ntfsclone to copy the windows data from old to new, and xfsdump/xfsrestore for the linux side of things.

A few blocks on the windows side didn't copy, so hopefully they weren't anything critical.

Next up was fixing the booting. Unlike MacOS X, PC operating systems can't find their own ass with both hands and a GPS.

On linux, updating things is relatively straightforward: install grub, mess around with the config a bit, rebuild the initrd, fix the fstab and you're good to go. A few manual steps, but sensible ones all the same.

On windows... Well, we try to boot windows and all we get is a black screen of ambiguity. This is as unfortunate as it is unhelpful. A little googling reveals these instructions for helping windows unfuck itself. Now, I know you're not all as tech-minded as I am, so I'll try to break things down fairly simply:

Basically, if the position of the windows partition on the disk changes at all, Windows won't be able to find the partition to boot from it. Even though the partition's new location is clearly listed in the partition table.

To solve this issue, you must hex edit the partition and tell windows where it starts. Think about this carefully a moment: you have to tell windows where the start of the partition is, and this information is recorded a fixed number of bytes away from... the start of the partition.

Sweet mother of christmas, if I were a windows OS programmer I would have had to seppuku myself 12 times over to try to erase the shame of my own blinding stupidity.

Sunday, March 25, 2012

Fun with spam bots

I had a spam-bot IM me this afternoon, and figured I'd have fun with it to kill some time.

AIM IM with [DELETED] Today 4:29 PM
Bot: heya.
Me: hello spam bot. are you here to sell me herbal viagra?
Bot: Im not a freaking bot
Me: sure you aren't
Bot: Hey whats up. 23 female here. You?
Me: 350 years old, clockwork
Bot: Hmmm. Have we talked before?
Me: my punch cards do not have any record of a previous conversation
Bot: Oh ok. Sorry I wasnt sure. Anyways... Whats up?
Me: sorry if I'm a bit slow to respond, my boiler is a bit low on coal
Bot: Im like sooo bored. There is nothing to do.
Bot: Ohhh wait! I have GREAT idea. Have you ever watched a sexy girl like me strip live on a cam before?
Me: I'm sorry, my mechanism was not engineered with a visual input device
Bot: Well.... Would you like to watch me strip?
Me: I would only be able to record a textual description thereof. do you have a live teletype feed?
Bot: Ok well my cam is linked through this website so I cant be recorded so you will have to sign up there
Bot: But dont worry it only takes a minute and it is free. kk?
Me: I would like to know more about you first. are you a brass-cogged mechanism or are you a more modern steel design?
Bot: [URL removed] Mmk go there then click on the gold Join Free button at the top
Me: I wouldn't like to look at a steel design. I'm not a pedophile, they're too young for me
Bot: Also it will ask for a credit card when you sign up but its just to keep the kids out. It dosent charge the card.
Me: I only have punch cards, not credit cards. do you accept paper tape perhaps?
Bot: I do have some toys i can play with but you will have to tip me some gold or join me in private to see those
Bot: Lets talk on that site babe my messenger is messing up. Ok?
Me: I'm afraid gold is too soft for my mechanism, it fouls my geartrain

And that's pretty much when I got bored and closed the chat.

Sunday, February 19, 2012

It was just a matter of time

So it's a long weekend in the US and Canada this weekend, and as such it's easy to let your mind go a bit soft while you're away from work. I know nothing of this, of course, as I'm still unemployed. All the same, I thought I might present you, my dear readers, with a little puzzle to think over to keep your mind fresh and active.

One of the upsides about doing job interviews is occasionally being presented with a very interesting logic puzzle. Of course, most of the puzzles are really rather mundane, and even the best ones tend to be quite contrived, so I thought I might pose a puzzle to you that is in fact drawn from my daily life.

You see, I have a digital clock in my kitchen that doesn't always tell the right time. Usually it's quite accurate, but often it's mysteriously a few minutes off. If you were to observe this clock for some time, you might notice that the rightmost digit for the minutes counts quite oddly. The sequence is: 0, 1, 2, 3, 4, 9, 8, 7, 8, 9, and then back around to 0 again to do it all over.

The cause of this bizarre acalculial malfunction is deceptively simple. Can you figure out what it is?

Tuesday, January 3, 2012

Help, uploading makes my internet slow!

Consumer broadband connections aren't designed right. They sound good on paper, of course "The majority of users download far more than they upload, so giving them higher download speeds and only a tiny amount of upload speed makes sense". In truth, it usually sort of kind of works... so long as all you ever do is download.

I don't only ever download, though. I create content now and then, and some of it is quite large. Large enough to take well over 10 hours to upload through the wee tiny upload pipe my provider gives me.

On the face of it this isn't really a problem. The material I'm uploading isn't remarkably time sensitive, and I don't produce it at a rate that exceeds my connection's ability to upload it. The problem is what happens to the download side of the pipe while this upload is going on.

Communication is a two-way street, you see. We need to be able to send out a request before we can get any data back, and we need to send out an acknowledgement before we get the next chunk and so on. Unfortunately our ability to send out these requests and acknowledgements is essentially cut off when the upload pipe is saturated, and we end up with packets backing up to the point where having any sort of interactive online experience is impossible, as is achieving anything close to a reasonable download rate for the few requests that do manage to make it through.

The solution to this, of course, is actually remarkably simple: We just have to keep the pipe from backing up by limiting the rate that we send data out. Of course, to avoid just moving the logjam further upstream, we also want to make sure that we throw out stale packets so they don't take up as much space, and thus time, in the queue.

Now I use a linux box for my main internet gateway, sitting between my connection to the world at large, and the legion devices on the warm, cozy side of the LAN. This means that setting up this rate limiting is a simple and straightforward task.

Or it would be, if the documentation weren't utter shit.

I actually spent quite a few hours paging through man pages and google looking for the magic incantation that would allow me to set up a sane rate limit queue on my linux box before coming up with the solution. To save you the trouble, here it is:

tc qdisc add dev shaw root tbf rate 60kbps burst 1540 latency 100ms

The command we're executing is "tc". The "qdisc" part means were issuing a queueing discipline command. The "add" means we're adding a new queueing discipline. All fine and dandy so far.

Now we specify the device we want to operate on. I've used "ifrename" to name my external interface "shaw", because that's who my provider is. Yours will probably be something uncreative like "eth0", but that aside the "dev shaw" part specifies the correct ethernet interface on my particular system.

The "root" part is the simple part of a complex puzzle. You can actually create a whole tree full of queues that feed into each other, each with different limits, algorithms, and a whole lot of other overcomplicated and unnecessary junk. We just want one queue, so we want it to be the root.

The "tbf" part is where we've specified the type of queue, in our case it's a "token bucket filter". Without going into too much detail, data is only sent downstream when there's enough "tokens" in the "bucket" to "pay" for them, and the tokens are replenished in wall-time thus achieving the rate limiting.

We specify this rate limit explicitly with the next part, "rate 60kbps". My upload bandwidth is actually 0.5mbit which translates to roughly 64kbps, but we want to make sure that we don't run too close to that limit or the logjam might form again at the cable modem.

The next part, "burst 1540" is where things start going off into the weeds. The documentation regarding this part of the command goes on about some technical details of how this needs to be set very large for things to work properly on fast connections because of kernel tick resolution limits. Of course, this is at least 5 years out of date since the kernel went tickless back in 2007 or so. In either case, this specifies the maximum size of the bucket (after which no more tokens can be added to it) and we want it to be at least big enough to pay for a full ethernet frame.

Finally, perhaps the most important part for keeping the logjam from forming, is the "latency 100ms" part. This defines how long a packet can linger in the queue before it's thrown out to make way for newer packets. Now one might think that throwing packets out would tend to make a complete mess of things, but in fact this is exactly what we want to do as reliable stream protocols like TCP will throttle back in the face of packet loss, reducing the logjam, and isochronous protocols will of course benefit more from having packets dropped rather than delivered late.

By deploying this rate limiting queue on my linux box I was able to ensure interactive internet performance while at the same time sacrificing little to no upload speed performance. This makes me happy, and I hope if you come into a similar situation that it'll make you happy too.