Wednesday, May 31
Let's say you have a MySQL backup made using mysqldump -A, which dumps all the databases on the system into a single file. But you only want to restore one of the databases, which consists of about 300KB in the middle of a 1.7GB SQL dump. And you're not sure if you want today's file or yesterday's or the day before's. How do you find the right one? How do you restore it easily?
import sys bakfile=sys.argv outfile='header.dat' f=open(bakfile,'r') g=open(outfile,'w') while 1: t=f.readline() if t[0:20]=='-- Current Database:': db=t[22:-2] print db g=open(db+'.dat','w') g.write(t)Use: python dbsplit.py <filename>
Monday, May 29
Via The Commissar, Ambient Irony as a graph:
The Java applet that generates this is still chugging away, so I'll let it run overnight and see what it looks like in the morning.
Thursday, May 25
What's the lifespan of a notebook battery these days?
I got my notebook last September, and at the time I could watch 3 hours of anime on a battery charge. I was editing the subtitles for Dirty Pair episode 4 on my way home yesterday, and the battery was dead by the time I got to Waitara; that's about 40 minutes. And that's less intensive than just watching anime, because I keep pausing the video while I edit the script.
Also, the power meter went from 10% to 3% in two seconds, which seems to be just a tiny bit abrupt.
I'm doing a test right now: 100% CPU, screen on, no disk activity; so far it's gone from 98% (which is where it is once you've booted from standby on battery) to 57% in 14 minutes. The 3% per minute seems to be pretty steady. Also crappy. Particularly since the last 10% is basically gone anyway.
16 minutes: 51%
20 minutes: 40%
22 minutes: 33%
24 minutes: 27%
26 minutes: 22%
28 minutes: 16%
30 minutes: 9%
32 minutes: 3%
34 minutes: 0%
36 minutes: 0%
38 minutes: 0%
40 minutes: 0%
41 minutes: URK
10 minutes: 72%
22 minutes: 38%
30 minutes: 14%
32 minutes: 9%
34 minutes: 1%
36 minutes: 0%
38 minutes: 0%
40 minutes: 0%
41 minutes: URK
Well, the full discharge and recharge didn't help a whole lot.
Tuesday, May 23
To expand on the theme still further:
Our office network is currently 100mbit, switched. There are two main 24-port switches, and a couple of 8-port switches for specific subnets, such as my desk. The exact topology doesn't matter, although a GbE uplink between the two main switches would be nice.
Anyway, the advantage of ATM over fast ethernet (as has been explained to us) is that it can guarantee the delivery of our critical voice traffic at the same time as it maintains a best-effort attempt at delivering data. Which is nice... But I have 100mbits available, unshared, to every desktop. If you are on two phone calls at once, at ISDN quality, that's a little more than one tenth of one percent of your bandwidth. You have to chew through most of the remaining 99.9% before you will start to affect the sound quality of those calls. And your PC (thanks to Microsoft's IP stack) isn't nearly powerful enough to do that. A full-size fast ethernet frame takes, what, 0.12ms to transmit, so the jitter will barely be measurable, much less noticeable.
Essentially, if you have the bandwidth, ATM isn't necessary, and if you don't have the bandwidth, you're going to lose something anyway. So where do we need it at all?
If you're a typical home user, you want to do stuff like downloading the latest episode of 24 over BitTorrent while making a VoIP call on your videophone. You've got what, a megabit upstream? Problem.
It guarantees the bandwidth for your videophone. Good.
To do so, it has to throw out some BitTorrent packets. Who cares? BitTorrent is completely self-healing at three different protocol levels. Anyway, it's your data it's throwing out, not anyone else's.
And the kicker: High-speed ATM is expensive, because you need high-speed processors to do all the fancy quality-of-service stuff. But we're talking about a megabit or so in an ADSL modem. We don't even need end-to-end QoS, since downstream bandwidth isn't in short supply, only upstream. So, finally, a win for ATM.
Unless you live in Japan, Korea, or Canberra, where ADSL has already been supplanted by something better.
As late as 1998, you could find papers extolling the virtues of ATM to the desktop. (Warning: Illegible in browsers other than IE6.) ATM could handle voice and video at the same time! Sure, fast ethernet looked sexy, but you only really achieved 40% of that 100mbits, and a single CSMA domain could only extend 200 metres at its furthest extremes. ATM could plug straight into the corporate backbone, and the 53-byte ATM cells meant a worst-case response time 7 times better than fast ethernet.
ATM to the desktop was the way of the future.
No-one rolled out ATM to the desktop. Everyone rolled out fast ethernet.
One: They already had ethernet. If you have ethernet, and it's slow, then the obvious solution is fast ethernet, right? Which is a large part of why 100BaseVG-AnyLAN died in the market. You can buy fast ethernet or... What was it again? 100BasicVB something? Let's just get some of that fast ethernet that everyone else is buying.
Two: Speed wins. Fast ethernet is 100mbits. ATM was being pushed for the desktop at 25mbits. 100 is more than 25. End of story.
Three: Price wins. Fast ethernet was cheaper.
Four: The price for ethernet switches fell through the floor. Suddenly, no-one in their right mind was using hubs. That 40% ceiling? Erased, utterly. Now you could not only safely hit 100%, you could safely exceed 100%, because different parts of your network were effectively on different circuits - all handled automatically.
That wiped out ATM's former big advantage - quality of service.
Let's say you had a network that was carrying both phone calls and data, such as terminal sessions to your accounting system. If your network gets full, you can't slow down the traffic on the phone calls, because then people won't be able to understand each other. But you can slow down the terminal sessions. It's annoying, but it still works. ATM looks after this for you.
On old-style ethernet, with a single network segment, once you started pushing too much traffic (and "too much" wasn't actually very much at all), everything would stop working. Both the phone calls and the terminal sessions would fail. (There was actually something called isochronous ethernet that ran 96 ISDN B-channels alongside standard 10mbit ethernet, so as to carry voice and data at the same time. It died.)
On new, switched, fast ethernet, it simply wasn't a problem. The phone calls and the terminal sessions weren't competing for scarce bandwidth anymore, because (a) they were put on different circuits, and (b) bandwidth wasn't scarce.
And ATM dropped dead, as far as computer networks go. The phone companies still haven't worked this out.
Right now, I can buy a 48-port gigabit stackable layer 3 managed network switch and 48 gigabit ethernet cards for the same price as one 155mbit ATM module from Cisco. Which way would you go?
And when you come to upgrade your gigabit ethernet, would you choose 10-gigabit ethernet, or... That other thing?
Friday, May 19
Brian Tiemann explains in excruciating detail.
mu.nu has moved servers three times over the past three years, from the original baby Celeron box, to a nice Athlon, to a dual Xeon, to the current pair of dual-core Pentium D's.
What probably nobody remembers is that the server itself moved once, as well.
Back in the early days, our hosting company, whose name is lost in the mists of time, was bought out by another hosting company. And lo, they decided to transfer all their servers to the new owner's data centre. Unlike Managed.com, though, they actually got it right: They chartered a 737, called in every vaguely technical person they knew, hoiked all the (carefully labelled) servers out of the racks and into a truck, zoomed off to the airport, flew them down to Florida, and had them all plugged in and running again in less than 12 hours. Well, at least my server was up and running in less than 12 hours, which is what counts.
Managed.com pulled the drives out of the old servers and stuck them in new machines. As recipes for disaster go, that's a simmer for three hours, feeds 24 starving grizzlies, gold-plate special.
Sunday, May 14
Hooray, hooray, the 14th of May, my download limit resets today!
(Cues up 20GB of miscellaneous anime in Azureus. Or queues up; works either way.)
DOAX2? Well, OK, but I still want to see DOA vs RR: XBW. And if you want to throw in a Girls of FF expansion, I wouldn't say no.
Thursday, May 11
One of the girls at work is a final-year Civil Engineering student.
She's never played with Meccano.
I don't have my notebook with me today, because I didn't want to carry it all over CeBIT. If I'd realised how close the convention centre was to my office, I could have dropped it off there and just walked down.
So ever since I got back to work, I've been thinking I'll just copy that onto my notebook so I can read it later... Aargh.
Also, I have episode six (that is, episode 9) of The Melancholy of Haruhi Suzumiya waiting at home. If I'd brought my notebook, I could have watched it already. Twice, in fact.
55 queries taking 0.8651 seconds, 314 records returned.
Powered by Minx 1.1.6c-pink.