Go away. The funny thing? I'd use IMolatr.
If you can read this (and in some parts of the 'net, you probably can't), then you're reading it through our new network connection via Comcast. After a pretty nasty false start over the weekend, and the cutoff date for Dataflo coming up this weekend, I bit the bullet and cut things over this morning. DNS was set up such that NS records were available for both address assignments for a while now, as well as MX records pointing at both address pools, so the only thing that's really off the air right now in some places is the webserver, and that'll just have to wait. I also managed to break my backup MX along the way, so I'll need to poke at that a bit more and see what I fat-fingered.
Bah. I like renumbering about as much as I like moving.
So, some initial observations: latency is a touch higher than it was with Dataflo, surprisingly enough. First hop averages went from 2-3 ms on the old wireless link to 8-10 ms (with occasional spikes) on Comcast. On the other hand, I'm now seeing download rates around 6Mbps (vs. 1.5Mbps), which is a nice change of pace. Downstream speed is 768kbps now (vs. 1.5Mbps through Dataflo), which may prove to be a problem, but we'll see how it goes for now.
The biggest negative observation I've made so far is Comcast's complete lack of business-oriented customer service; they're obviously incredibly used to dealing with residential customers, and they've used that same contracted-out infrastructure to deal with their commercial customers as well. Phone support is excellent (when you finally get to them; getting a rep on the phone requires navigating about 10 levels of phone menus), but getting physical on-site service is a multi-day waiting game, with the typical "we'll be there sometime between 8:00 AM and 8:00 PM" kind of scheduling that you've come to expect from their residential service. There is no email interface to the helpdesk whatsoever; any kind of technical support inquiry MUST be made by phone, which is incredibly annoying when wanting to do something complicated with DNS. So far, I'm not impressed, but if I never have to deal with their customer service (much like when I was with Speakeasy, who rarely saw an unannounced service outage), then it won't matter to me. We'll see.
Dataflo or Datanoflo?
So, the day after I post a blog entry about being forced to switch to Comcast because of the lackluster service I've received with Dataflo, I have another rather significant service outage. There appeared to be problems last night, although I was having a hard time pinning the issue on Dataflo then. However, they definitely made a mid-day routing change today; at 12:34, all of a sudden, my backup MX starts receiving email for everything (the backup MX, in this case, is my router, which usually sees nothing but spam all day), and traceroutes to the static IP block they've assigned me are dropped on the floor the moment Cogent hands off to Dataflo.
It's not like I'm asking for a lot here. I need a service that stays up, and I'm paying a premium for that. That premium ought to include at least a bit of special attention to making sure the services provided to me are working when a major change is made, and perhaps major changes shouldn't be done in the middle of the workday, in the middle of the week, without any prior notification to the customer base of a potential outage. Screw the SLA; I shouldn't need an SLA to hold over their heads. What I really need is a service that stays up, with planned maintenance windows and some degree of customer notification.
I have no idea why I think Comcast will be any better, but at least they're half the price (actually, a third of the price, if you consider what my renewal contract pricing stated). In the event I get lousy service, at least I won't be crying about the money I'm wasting.
Ugh. I finally bit the bullet, and had Comcast "Workplace" service installed to replace the flakey fixed-point wireless service I've been fighting with for the past two years. To be fair, I should qualify that: my "last mile" link (between my rooftop transmitter and the tower) has been rock solid. The problem has always been mid-day routing and configuration changes on the part of the provider, which have knocked me offline anywhere from a few minutes now and then, to one incident that had me offline for the better part of a day. At this price and service level, that's completely unacceptable. So, since I can't get service from my preferred vendor here due to a complete lack of DSL availability in my area, I'm stuck with the local cable company: Comcast.
So, first impressions (note that I haven't moved ANY services to this yet, until I get a feel for how this will work): 6Mbps download speeds are unbelievably fun. The 768kbps upload speed may end up being a bit of a hindrance; most of my traffic is SMTP, but I do receive a fair bit of HTTP traffic too, and that's where that upload bottleneck is going to suck (specifically, both I and Erica maintain pretty large photo galleries that seem to get a bit of traffic, and I'll often host larger items for people for limited times). But, we'll have no idea how that'll go until I bite the bullet and cut stuff over; I'm hoping I can run fairly well off of both links for a while, with plenty of time for DNS updates to propagate.
Ugh. I remember how much I hate renumbering now.
Fedora Core 5
My initial impressions: more solid than I thought this release was going to be, given how much has changed. My biggest complaint so far: they upgraded OpenSSL to a new major version without providing a compat release for those of us upgrading. All we needed was an equivilent to the already-existing openssl097a package, which does nothing but package up libssl.so.5 and libcrypto.so.5, and upgrading would have been smooth as silk for me on one machine. Instead, I'm stuck rebuilding packages that I should have been able to leave alone until later. Bah.
More later when I've had a little more time to play with it. Playing with it on a desktop machine is proving difficult, as the only "play" machine I have right now running Fedora Core hangs the console whenever I fire up X. (Not too surprising, that machine is a bit of a hodgepodge of hardware.)
The action with the WRX was captured beautifully with my new toy: a Treo 650. It's a combination PDA and cellular phone that runs PalmOS, and with the data service I picked up with the package, the built-in web browser and email client are actually proving to be fairly handy. Definitely a big step up from the BlackBerry I had while I was at my previous job; the screen and form factor are a huge leap forward, and having a camera built-in (albeit pretty crappy) is a cute gimmicky toy. Battery life is at least as good too (actually, it looks like it's going to be quite a bit better; I should get two or three days out of a charge with my normal usage, which is pretty excessive compared to an average user). Phone and data service coverage with Sprint seems to be pretty good so far, and the data service is a LOT faster than the Nextel service I had the BlackBerry connected to. The SD media slot means this thing can also serve as a portable MP3/OGG/media player too; 2G of audio storage ain't bad. I can bolt the thing up to my desktop via bluetooth and infrared as well, which means one less cable to muck with. I'm pretty happy with it so far.
So, in my new role, I'll be responsible for the shared administration of a rather large Gentoo deployment. So, in the spirit of eating your own dogfood, I'm loading my new company-issued laptop with Gentoo Linux.
First impression: I feel like I'm back in 1994. Really. Oh, the package management is generally pretty cooked; in fact, I'm really quite impressed with how they're handling a generally nebulous thing (from-source package generation) in a pretty consistant manner. I'm trying to imagine building Fedora from source RPMs, and the idea gives me the willies; they have the build dependancies handled pretty well. No, my problem is the same problem I have with Debian: choice is good, but too much choice is a PITA. You can infer from this that I disagree with the Perl axiom of "more than one way to do it"; all that means is that the language (or in this case, distribution) maintainer didn't have the intestinal fortitude to make a decision, and left the problem of bikeshed arguments to the users. It's actually worse than that: on their own, a lot of the little variances don't matter, but get enough of them together, and you have a maintenance nightmare.
This problem is compounded by the community belief that customization at all levels (specifically at the buildchain level) is a good thing. At the end of the day, you have a distribution where you are truly on your own from a support perspective in many cases. Not a big deal for an operating system targetting hackers and tweakers (in fact, I'll probably have a ball with it on my laptop), but when I put my management hat on, the idea of using this in production frightens me; you're essentially locking yourself into using senior-level talent to manage your infrastructure, and hiring junior talent that can grow into the position starts becoming less and less attractive. Not bad for me, but bad for the bottom line.
I expect I'm expounding on arguments that have been had over and over in the Gentoo community over the years, so this is more of a first-impression kind of vent. I'll skip on discussing the apparent lack of development and "stable" tracks for general deployment, and a few other similar things I've noticed missing from the "process" around the distribution, because they're all fundamentally part of the same issue: the Gentoo community appears to strongly appeal to the hacker/tweaker, which defines the community's behavior from a packaging and ongoing maintenance perspective.
So, Slackware for smarter people.
After being so happy about getting the framerate up a bit last night, I decided to finally get around to updating the BIOS to the last version issued by ECS (it's a K7VZA v1.0 motherboard, if anyone's curious). Seeing as it's been out since 2000, I figured, "What could possibly go wrong?"
I ended up with a brick.
Enter the Willem EPROM burner I bought a few months back for flashing ECU chips for Erica's Laser. I finally set up a machine for doing nothing but burner duty, and pulled the image off the chip. As suspected, it was corrupt, so I tried writing the image out again with the burner...no dice, it would fail after a random number of sectors. After a LOT of searching, I turned up a bit of information: first, BIOS chips (in this case, an ASD AE29F2008) seem to have a defence mechanism against just blatting a new image onto them, and you need to disable this before you can write your image (which is the real "magic" of the flash update software that motherboard manufacturers issue you). Second, version 0.97ja of the Willem software (the most recent version available) can't actually disable it; you have to backdate your version to 0.97g. Tried out the older version, clicked the button that magically appeared to disable software protection, and viola: the image burned perfectly.
Shouting triumphantly (and waking Erica up, doh!), I rushed downstairs with my freshly flashed BIOS, plugged it in, powered the machine back up, and...BEEEEEEEEEEEP*crackle*. Same thing, just powered down. Dammit. Okay, back upstairs, downloaded and burned the older version that we were running before, ran back down, plugged it in, powered it up, and all was well again. I have no idea why the new image isn't working, but I'm perfectly happy with the BIOS revision I have now, thankyouverymuch.
I also took a second to slap another 30GB drive I had lying around into it for my ogg collection and various other multimedia goodies for sharing with the rest of the machines here. A quick fdisk and pvcreate /dev/hdd1 (etc), and I think I'm about ready to call it a night.
So, on the upside, I now have a decent station to burn chips at; this eliminates the last of my reasons for waffling on getting a new chip made for the Laser, so I'll probably play with that next.
I never thought I'd be happy to see 114 frames per second out of glxgears, but that's double what I was getting before, so I claim success. I suspect if I cranked the resolution down from 1600x1200 to something a little smaller, or dropped the color depth down to 16bpp, I'd get a little better performance, but frankly, I'm not really willing to sacrifice either. Call me spoiled.
For the curious: lspci identifies my card as a Radeon RV100 QY (Radeon 7000/VE), which is apparently some bastard child of the Radeon 7000 lineup that has a bad time with DRI. It also has the fact that it's a PCI card working against it, but hey, at least it's got 128MB of painfully-slow-to-access video memory onboard. Two initial problems cropped up: first, I had an MTRR conflict which required manual intervention to clear up (I found a thread over at Rage3D.com that put me onto a solution for that), and second, DRI is disabled on the Fedora build of Xorg, and needs to be explicitly re-enabled for the Radeon 7000/VE (add Options "DRI" to the Device section of xorg.conf). Basic desktop behavior is a bit quicker now, and video playback is actually doable now, so it's a good place to stop for the night, but this is truly terrible performance compared to what I was expecting.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!