HN user

keitmo

225 karma

[ my public key: https://keybase.io/keithmo; my proof: https://keybase.io/keithmo/sigs/m99sDky3GkxQBN3yiDqXlrRWl8PqBFrZw9S4zLxx5-8 ]

Posts4
Comments49
View on HN

I'm right-handed, but I snowboard goofy. Coincidence (or not?) my left leg is dominant. I can kick a ball just fine with my left foot, but when I try to kick with my right foot I feel like I'm going to capsize. When I'm riding a bike and I have to stop, my right foot goes down. When I start again I use my left leg to muscle the crank through the first revolution or two.

It seems to me that Backblaze does NOT exclude ".git". It's not shown by default in the restore UI -- you must enable "show hidden files" to see it -- but it's there. I just did a test restore of my top-level Project directory (container for all of my personal Git projects) and all .git directories are included in the produced .zip file.

Touching the circuit board on the back of the CRT tube by mistake trying to troubleshoot image issues, “fortunately” it was a “low” voltage as it was a B&W monitor….

My father ran his own TV repair shop for many years. When I was a teen he helped me make a Tesla coil out of a simple oscillator and the flyback transformer from a scrapped TV. It would make a spark 2 or 3 inches long and could illuminate a florescent light from several feet away. It definitely produced higher voltage than normally exists in a TV, but not orders of magnitude more. The high voltage circuits in CRTs are dangerous as hell.

Linux from Scratch 2 years ago

I went through the LFS process back in 2003 or 2004. I didn't have a Linux system handy, so I built it with Fedora 3 running under VMWare on a Windows XP laptop. It was not speedy.

I tried to automate the process as much as possible. There's a separate Automated Linux From Scratch project, but I choose to roll my own. This was my first experience with Bash scripts -- I developed skills (and bad habits) that I continue to use this day.

4B If Statements 3 years ago

I'd like to see a fully distributed version. All you need is 4B hosts (IPV6 FTW) named N.domain.com (where N varies from 0 to 4B-1). The driver app sends N to the first host (0.domain.com). Each host compares the incoming N with their N.domain.com name; if they match, return the host's true/false value. If they don't match, forward the request to (N+1).domain.com and return the result.

Othello Is Solved? 3 years ago

I read an article many years ago on programing Othello. I think it was BYTE Magazine, circa early 1980s. It mentioned pitting an app using a simple heuristic technique similar to the one you describe against an app using an equally simple (but devastatingly horrible) "flip the most squares" approach.

The heuristic algorithm won by a landslide -- 60 to 4 or worse (I don't remember exactly).

Here's one that bit us a few years ago:

SEQUENCEs, used to implement SERIAL and BIGSERIAL primary keys, are not transacted. "BEGIN; {insert 1,000,000 rows}; ROLLBACK" always adds 1,000,000 to the table's primary key SEQUENCE, despite the ROLLBACK. Likewise for upsert (via INSERT ON CONFLICT).

The end result: A table's SERIAL (32-bit signed integer) primary key can overflow even when it contains far fewer than 2^31 rows.

For years I've said "any clothing manufacturer that promises something is both 'waterproof' and 'breathable' is lying to you".

Shakedry actually delivers on this promise.

FWIW I do endurance cycling in the Seattle area, a.k.a. "The Pacific NorthWET". We tend to stress the hell out of waterproof clothing.

I often tell people to assume the TCP stack's buffering is arbitrary & capricious and will do the most inconvenient thing for your code. That can mean ether a) dribbling data in one byte at a time per recv() call, or b) buffering multiple megabytes and returning it all in a single recv() call.

A few years ago we had a nightmarish resource leak in our server. The code in question was reading and parsing HTML, looking for a handful of specific tags (title, description, etc). Under heavy load the server would be stable for a few hours, then memory would suddenly explode and kill the NodeJS process.

The problem was caused by the HTML parser we were using. The parsing results appeared to be a POJO but apparently there was much lurking under the surface.

The fix: `parseResults = JSON.parse(JSON.stringify(parsedResults))`