|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
I was reading the Gone but not forgotten: 10 operating systems the world left behind article today, and this quote about DOS hit me:
DOS was dealt a death blow when Windows 95 came out in 1995, but many of us old keyboard jockeys still drop out to the command line from Windows to flex our old DOS muscles occasionally. It just feels more efficient to type a quick command than to monkey around with the mouse and menus. We may be fooling ourselves -- like the people who wait in line for self-checkout at the supermarket when the Express checkout clerk is twiddling her thumbs -- but it's all about perception, right?
Crap, so, I love the CLI (not nessarily a DOS CLI) and almost exclusively use self-checkout at the grocery when it's available. Is the GUI actually faster? Should I stop using self-checkout? Am I stuck in the stone age?
Well, I do drive an automatic. Somebody once told me that didn't jive with the rest of my habits and preferences.
IS-IS and OSPF are certainly different animals, but they have enough similarities that it makes sense to put some of the different protocol terms back-to-back. I stumbled across this list, today:
IS-IS - OSPF
End System - Host
Intermediate System - Router
Circuit - An adjacency on one link
SNPA Address - Data link Address
Protocol Data Unit (PDU) - Packet
Designated Intermediate System (DIS) - Designated Router (DR)
IS to IS Hello PDU (IIH) - Hello Packet
Not Applicable - Backup Designated Router (BDR)
Link State Packet(LSP) - Link State Advertisement (LSA)
Link State Packet - Link State Update
Complete Sequence Number Packet(CSNP) - Database Description packet
Partial Sequence Number Packet(PSNP) - Link state ACK or Request Packet
Routing Domain - AS
Level 2 Subdomain - Backbone Area
Level 1 Area - Non Backbone Area
Level 1/2 IIH PDU - Simple Hello Packet
Level 1/2 LSP - No Distinction
L1L2 router - ABR
System ID - Router ID
Link State Packet ID(LSPID) - Link State ID
Pseudonode LSP - Network LSA
The above was shamlessly reproduced from IS-IS and OSPF Difference Discussions.
So, I noticed festival wasn't working, the other day:
% echo hi | festival -tts Linux: can't open /dev/dsp
Turns out the solution is rather simple:
# apt-get install alsa-oss oss-compat
I was missing oss-compat. Go figure! I wonder when festival will start using ALSA natively?
I have one or two of those a year. They are really disturbing, for some reason. I guess I'm not the only one, though!
Which is the fastest? aterm or wterm, so far. Too bad they don't support unicode. GNOME Terminal never finished the test after 60 minutes, so I didn't bother listing it.
% lspci|grep VGA 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) xterm 235-2 % time dd if=/dev/zero bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 41.0486 s, 26.2 MB/s dd if=/dev/zero bs=1M count=1024 0.01s user 6.81s system 16% cpu 41.050 total aterm 1.0.1-4 % time dd if=/dev/zero bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 16.9774 s, 63.2 MB/s dd if=/dev/zero bs=1M count=1024 0.00s user 6.63s system 39% cpu 16.979 total wterm 6.2.9-8 % time dd if=/dev/zero bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 17.058 s, 62.9 MB/s dd if=/dev/zero bs=1M count=1024 0.00s user 6.61s system 38% cpu 17.059 total rxvt 1:2.6.4-14 % time dd if=/dev/zero bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 18.4532 s, 58.2 MB/s dd if=/dev/zero bs=1M count=1024 0.00s user 7.12s system 38% cpu 18.455 total rxvt-unicode 9.05-1+lenny1 % time dd if=/dev/zero bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 18.9052 s, 56.8 MB/s dd if=/dev/zero bs=1M count=1024 0.01s user 6.63s system 35% cpu 18.907 total
I need something that supports unicode, and is just as fast as aterm.
So, last week Apple came out with a new Mac mini. I picked one up, took some photos, and ran a benchmark:
PowerPC G4 1.42: (chronos:18:33)% wget http://dax.prolixium.com/32MiB.bin --2009-03-09 18:33:13-- http://dax.prolixium.com/32MiB.bin Resolving dax.prolixium.com... 10.3.4.6, 2001:470:8ad6:4::a Connecting to dax.prolixium.com|10.3.4.6|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 33554432 (32M) [application/octet-stream] Saving to: `32MiB.bin' 100%[=======================================>] 33,554,432 608K/s in 41s 2009-03-09 18:33:54 (792 KB/s) - `32MiB.bin' saved [33554432/33554432] (chronos:18:35)% time bzip2 -9 32MiB.bin bzip2 -9 32MiB.bin 38.28s user 0.68s system 97% cpu 39.772 total Intel Core 2 Duo P8400 (2.26GHz): (odyssey:23:24)% wget http://dax.prolixium.com/32MiB.bin --2009-03-09 23:25:05-- http://dax.prolixium.com/32MiB.bin Resolving dax.prolixium.com... 10.3.4.6, 2001:470:8ad6:4::a Connecting to dax.prolixium.com|10.3.4.6|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 33554432 (32M) [application/octet-stream] Saving to: `32MiB.bin' 100%[======================================>] 33,554,432 915K/s in 36s 2009-03-09 23:25:41 (904 KB/s) - `32MiB.bin' saved [33554432/33554432] (odyssey:23:25)% time bzip2 -9 32MiB.bin bzip2 -9 32MiB.bin 10.13s user 0.23s system 95% cpu 10.879 total
Not-a-bad. Specs on the new box are:
It plays H.264 at 720p and 1080p, finally :-)
So, I get asked every once and awhile why I think it might not be a great idea to add AAAA records to popular websites, to spread IPv6 adoption. The reason I always give: there's still lots of proxy and DNS servers out there that go belly-up when confronted with AAAA records.
Here's another reason why:
So, fed up with the myriad of bugs on the Nokia E71, I decided to upgrade to the latest latest version of the firmware for my phone: 200.21.118. Unfortunately, it didn't fix the Bluetooth and disconnect issues, and only addressed the Flickr photo-sharing application. It also (or so I thought) introduced a DNS resolver issue with AAAA and A records, but this turned out to be coincidental, and due to AT&T adding broken IPv6 support to their DNS servers! Read on for my explanation…
I first realized this issue when I started having some strange DNS resolution issues when connecting to mail, web, SSH, etc. on my servers. This only happened over the WAN interface (it's AT&T's UMTS network), not over Wi-Fi. Resolution only succeeded 10% of the time, which was fairly painful. At first, I thought it was a fluke, but now I've come to realize it was only having issues on domains that have NS records with IPv6 glue. Connecting to stuff at the office worked just fine, and browsing the web seemed ok for most sites.
I used IfInfo to determine what DNS servers AT&T was providing, and it turned out to be 172.18.145.103 (which translates to 209.183.35.23, alpinetdns.mycingular.net, apparently). Now, here's what confused me at first, still thinking that the new Nokia E71 version had tweaked their resolver to support AAAA records: I ran tcpdumps, both IPv4 and IPv6, on my DNS servers when trying to load a prolixium.com URL, and saw /nothing/ when the queries failed. When they succeeded, I only saw an A record lookup. I went into the advanced access point settings and pointed the AT&T connection to 4.2.2.1 and 4.2.2.2, Level3's anycasted DNS servers, and then tried again:
16:39:02.155276 IP ics2.Atlanta1.Level3.net.39513 > ns3.antiderivative.net.domain: 57546 [1au] A? start.prolixium.com. (48)
Works perfectly! But.. only an A record?
I switched back to automatic DNS (the 172 stuff) and tried to pull up a page created by one of my friends: http://mathemagi.ca/math/. Now, mathemagi.ca only has an A record, but my DNS servers that have IPv6 glue are authoritative for it. Bingo - page didn't load, and the DNS lookup timed-out. Switch back to Level3's servers, and it works.
Here's what I figure happened: AT&T is deploying IPv6 on their wireless network, but are breaking things along the way. I suspect that the 172.18.145.103 DNS server is sitting on a network segment where stateless autoconfiguration has been enabled by accident, before there is actually IPv6 transit available. The DNS server probably had an IPv6-enabled networking stack with autoconfiguration enabled. It autoconfigured an IPv6 address that doesn't work, and is trying to send ns2.antiderivative.net and ns3.antiderivative.net (my DNS servers) queries via IPv6, that are being blackholed somewhere else in the network. Eventually this should time out and fall back to IPv4, but I suspect the DNS timeout on the phone is lower than the timeout on the DNS server - so stuff just breaks.
The root servers and GTLD servers are both online with IPv6, so this could potentially make that DNS server fail for every query. My guess is that the DNS server either has them all cached, or is a slave of some sorts, so it doesn't have to time out sending DNS queries via IPv6 to the root and GTLDs.
I'm going to stick with Level3's DNS servers, for now, until IPv6 gets correctly deployed on AT&T's wireless network, or they remove stateless autoconfiguration from the DNS server (or segment).
Bah, way to spread IPv6 adoption :-(
Thanks to some private replies I received from this news posting, AT&T has since resolved the DNS issue. It seems that 172.18.145.103 is a virtual IP on some load balancer, distributing load between 209.183.35.23 and 209.183.33.23. The latter server seems to have been the one with issues, and has since been taken out of rotation.
I still believe it has something to do with an IPv6 messup as described above, as every site I tried that failed has AAAA glue. Perhaps only 209.183.33.23 has autoconfiguration enabled. However, some other sites were affected two, so this is inconclusive.
It snowed again.
I took some more photos of it. The office opens today at 10:00, but I got in early - man am I productive, so far! Erm, except for the whole blogging part.
Displaying page 26 of 121 of 965 results
     |
This HTML for this page was generated in 0.005 seconds. |