Wow… it’s actually illegal to have an indoor bathtub in Virginia. That could explain a lot. 😉
(Disclaimer: I’m allowed to say that because I lived in Virginia for several years, and several of my beloved — and not so beloved — relatives still do.)
Damned clumsy time travelers. 😉
(“Anachronous” is probably a better term for this than the writer realized.)
I’ve confirmed that the article isn’t a hoax, at least — it really was reported, and discussed pretty widely at the time. Whether the watch is or not is an open question. A cursory glance at the Google results doesn’t show any resolution to the mystery.
I’ve been pained for several years by the ads in one of my RSS feeds.
Mozilla Thunderbird (my program of choice for handling e-mail and RSS feeds) waits until it has all of the images for a message before rendering any of the message, including its text. That’s fine, I don’t mind text or non-animated ads — except when I’m trying to quickly skim through several weeks’ worth of messages to find ones that might be useful, and the ad provider’s website is so slow that it takes ten seconds for a particular message’s text to be displayed. That’s about 9.5 seconds more than I’m willing to wait.
Last night, trying to get caught up on my unread messages, I decided that I’d had enough. A quick Control-U to display the HTML source for the message, a few moments of study to identify the URLs of the two ridiculously slow ad providers, and a few seconds to edit the /etc/hosts file to tell my system that those sites were hosted on itself (where there’s no web server, so it gives up immediately), and the ads in that feed were toast. I finished my skimming in record time.
The moral of the story: if you want your ads seen by technical people like me, choose an ad provider that has sufficient capacity that it doesn’t cause us any trouble. Because if it irritates us too much, we can and will block it. You only get one shot at that, because we’re not likely to ever have a reason to unblock it again if that happens.
Looking for something exciting and new to panic about? Look no further!
I especially like this snippet of advice from the “brown bear” page:
Never intentionally feed a bear: Monitor your bird feeders, never put meat scraps or fruit in your compost bin, and put garbage out in a bear-resistant container on pick-up day.
Bear-resistant container?! I can’t find anything strong enough to keep a raccoon out of our trashcans — what’s going to stop a freakin’ bear?! I guess it’s a good thing that bears rarely put in an appearance in the middle of a busy city. 😉
Fortunately, few of these beasties enjoy living in this part of the country, but I doubt that’s very comforting to readers in more southern climes.
As strange as it sounds, the research does have a useful purpose. Other than giving the researchers an excuse to legally (?) keep otherwise-illegal drugs, that is. 😉
I recently spotted this quote on our friend interrobang’s blog:
The results of a multiple regression analysis of 49 metropolitan areas show that the greater the airtime devoted to country music, the greater the white suicide rate. The effect is independent of divorce, southernness, poverty, and gun availability. — Steven Stack and Jim Gundlach, “The Effect of Country Music on Suicide,” Social Forces, September 1992 71(1):211-218
(To which she commented: Yeah, I always said country music made me unsure whether I wanted to kill myself or someone else. — ?! A reaction I can totally sympathize with, at least for the classic “my wife left me, my truck broke down, and my dog died” school of country music that my adoptive father preferred.)
Apparently it’s a real paper, too. There are a few more curious ones here as well.
That’s one heck of a pool table.
This gives me hope, because no matter how stupid people seem to be nowadays, they’re not quite as stupid as they were a century ago. It also saddens me about just how far we still have to go.
Yet another science-fiction technology is now becoming science fact. I wonder how long it will be before this technology, or something based on it, is put to medical use — and how long after that it will be before it’s turned to malicious use as well.
As I’ve mentioned before on this blog, my previous company was purchased by a larger company (I’ll call it BigCo for the rest of this entry) several years ago, and they still keep me on the payroll for consulting and the more intricate development work on Project Badger.
BigCo is not a software company, it’s a web company that just happened to have a need for Project Badger. As such, it doesn’t have very advanced software development tools, or any training for them, something that I’ve griped about before. The specific tool that I’m talking about today is version-control software, which they use CVS for.
CVS was a very decent tool for its time, but its time was a quarter-century ago. More recently, and particularly in the last ten years, much better version-control tools have arisen. And with the introduction of Mercurial and Git, distributed version control tools — which are a much better fit for groups of developers that aren’t all in one building — have finally become mainstream.
The way they have to use CVS isn’t very efficient either. It requires a lot of manual labor to vet and merge changes, for instance. But the biggest pain-point recently has been that I don’t have access to it at all, because I’m not within BigCo’s internal corporate network. There have been several cases recently that required some coding from me, which just exacerbated the problem… I don’t always have the latest source code to work on, and have no way to know about it, or to get it except having it manually sent to me (heavily encrypted, of course) by e-mail or download. It’s too big to pack up the whole thing, so that requires manual intervention by someone inside BigCo too. And then when I’m done, I have to figure out what files I’ve changed, pack them into a zip file, encrypt them, and send them back, where they’re manually merged into the main body and checked into CVS.
There is a better way, and I spent about fourteen hours on Saturday researching it and setting it up.
As I’ve mentioned before, I use Git (a distributed version-control system) for my own development. Git has the wonderful ability to update remote repositories via the secure network protocol SSH. It also has a set of scripts, known as Gitosis, to make it very simple to set up a secure Linux-based Git server. I’ve already got an SSH server set up in my network (so I can get to it when I’m on the road), and setting up a Git server as well didn’t require too much additional work. (Getting it set up securely, and in such a way that the repositories are secure even if the hardware gets stolen, and are still automatically backed up properly… that’s what required the vast majority of the fourteen hours. But I digress.) Now, once we set up his end on Tuesday, the lead developer on Project Badger in BigCo has direct access to my development repository, and can update it or pull changes from it with ease. He still has to deal with CVS on his end, but this should make things a lot easier for both of us.
Now comes the problem.
It’s well known that there are a number of people trawling the Internet for SSH servers and trying to break into them using dictionary attacks on account passwords. One of this blog’s regular readers, who shall remain nameless (cough Ploni cough 😉 ), was hacked that way a few years ago. My existing SSH server doesn’t allow password-based logins at all because of that threat (only public-key authentication), and is on a non-standard port as well. But since I had to put the new SSH server on a different machine, I decided to try an experiment: still set it up for public-key authentication only, but leave it on the standard SSH port, and see what happens.
Normally, with the setup I used, I think this would work just fine. But I’m running the new SSH server on a Linux virtual machine, running under VMware Fusion on a MacBook Pro. What happened was that last night, a couple hours after opening the firewall for it, the system slowed to a crawl. It cleared itself up after about half an hour, with no evidence as to why it had happened, but I had my suspicions. This morning I wasn’t able to contact the system at all, so I visited the office, only to find that I couldn’t even get it to come up — it wasn’t locked up, but it was so slow that after five minutes, it still hadn’t managed to pop up the password prompt. Big Red Switch time.
Circumstantial evidence suggests that Mac OS X doesn’t handle being bombarded with failed SSH logins very well.
So I switched this one to a non-standard port too. I’m rather disappointed that I had to, but hey, whatever works. We’ll see whether it suffers from the same problems. I don’t think it will.