?

Log in

No account? Create an account
08 December 2008 @ 10:37 am
After a recommendation from Gavin, I purchased an RCA ANT 1500 antenna. This thing is absolutely amazing! I previously had a Terk Low-Profile Indoor Antenna (TV5), which worked, as long as I rotated it to just the right orientation for that particular channel. But this new one is flat, mounts on the wall, and gets all the "green" (should work with indoor antennas) channels that TVFool's antenna lookup says I should get, without having to fiddle it at all.

Unfortunately, it doesn't replace cable, since many channels are not available over-the-air, but it does let me use my HdHomeRun (with two tuners) to record (in HD) any of the major networks, leaving the single-tuner cable box free for cable-only channels.

The antenna is now much more reliable than the cable box. The box appears to restart in the middle of the night sometimes, even if it's in the middle of recording a show. And occasionally, seemingly with no rhyme or reason, the firewire output for a particular program is encrypted, which makes the recording fail. The antenna has neither of those issues.
 
 
Many years back, I read with great interest about the Cilk project at MIT, headed up by Charles Leiserson (that is: the L in CLR, Corman, Leiserson, and Rivest, authors of "Introduction to Algorithms"). I was a bit saddened when I looked back at that work a year or so ago and saw very little had been done recently. And it seemed that the world seemed to be standardizing on OpenMP, which to me, really seems an obviously inferior solution.

So, I was really excited when I noticed today that Cilk was not standing still, they were just working on starting a spin-off company, Cilk Arts, to further develop and commercialize the technology. Apparently it now is now based on C++ instead of C, and is implemented both for GCC and for MS VC++.

I find it quite interesting, because it could make it possible for mere mortals to write efficient and correct multithreaded algorithms. The genius is the simplicity. There's two new basic keywords added to C: cilk_spawn, and cilk_sync. Spawn spawns a new thread, and sync waits for all threads spawned by the current function to complete. That's basically the whole system. They've also added a cilk_for, which more efficiently implements spawning off each iteration of the loop.

Here's a trivial program from their examples:
int fib (int n) {
      if (n<2) return (n);
      else {
        int x,y;
        x = cilk_spawn fib(n-1);
        y = fib(n-2);
        cilk_sync;
        return (x+y);
        }
   }



You might be thinking right now: okay, so what? I can implement those macros, there's no cleverness there. But, if you just go off and literally implement what I said, you'll quickly find that the overhead of thread spawning and waiting overshadows any possible efficiency gain you might get.

But, not so in Cilk: spawn is incredibly cheap to execute. Why? Because it doesn't actually spawn off another thread. Instead, it marks the current location as a place where another thread can start executing, if it has run out of its own work to do. And, here is the great part: when some other thread is idle, it will steal work from the outer-most stack frame of the current thread at a "spawn" location. Thus ensuring that the other thread can do the most work on its own before having to come back to get more work. They call this the work-stealing scheduler. Think about that one for a while.

It means you can start adding parallelism to almost any part of your program, even fairly small loops or recursive functions, without worrying excessively that the overhead of spawning off threads will erase any gains from parallelism. And as you manage to push your way outwards, adding parallelism to larger parts of your application, as you verify that they don't mutate global state, you don't need to remove the spawning, either. You don't need to know where is most efficient to spawn off worker threads, you can just do it everywhere.

For me, the biggest value here is that it can help solve the problem of converting an existing serial program to a parallel one. Let's say you have an giant program, that mutates global state all over the place, shares state everywhere, and you despair at the prospect of ever having it efficiently use multiple processors. Now, Cilk won't really help you clean up your program. But what does promise to do is, as you incrementally clean up small pieces, it allows you to add the parallelism right there, in that small piece, and have your program actually gain efficiency as you do so. And, if eventually you manage to clean up larger parts of the program, and later add parallelism to an outer-more loop, it won't require you to go back and remove it from the inner loop.

And, that's a Big Deal.

I encourage you to read more on their website. The docs for Cilk++ are public, and there are links to a bunch of papers written over the years. Unfortunately, it seems Cilk++ itself isn't publicly available yet (and I haven't tried it either), but the earlier research project Cilk, upon which Cilk++ is based, is available.

Now, if someone would just port it to Common Lisp. :)
 
 
31 May 2008 @ 05:53 pm
RCN never replied to the email I sent them over a week ago. Seeing little other choice, I called them to cancel my Cable TV service last thursday. I was, after all, not actually receiving any service, and they appeared to be unable to respond to my inquiries.

After recounting all my troubles in response to the "Why do you want to cancel?" question, the rep apologized, put my on hold for a few minutes, and came back to offer to reduce my bill by $10/month to $95/mo, and include in that price an HD Cable Box.

I was completely astounded by the competency of this rep: she a) didn't argue with me and tell me it was actually the FCC's fault, b) knew what Firewire was and that cable boxes have Firewire ports, and c) knew enough to warn me that she was not sure whether the Firewire port would work or not, ("I know it's enabled in the DVR model but I'm not sure about this one").

Despite the uncertainty about whether Firewire would work or not, I agreed, and set an "install" date for them to drop off the box. So, they came yesterday and gave me a DCH-3200 (man...do cable boxes really need to be that big?). And when I hooked up the firewire cable, MythTV basically just worked. The only way it could have been simpler is if MythTV's manual had been updated to say that most of the junk they want you to do is actually completely unnecessary. Just make sure the kernel modules are loaded, the /dev/raw1394 entry has lax enough permissions, and run mythtv-setup. That's it.

So, while I'm now down from 2 tuners to 1, I still can use MythTV, and despite all odds, RCN has actually managed to redeem themselves to me. After my previous interactions with them, I never would have thought it possible. I'm still irritated that they've made these changes, made them without any notice to me (or any other customer as far as I know), and have terrible customer support, but not irritated enough to cancel my service.

At least until such a time as they start encrypting their Firewire output...all I can do is hope that won't happen anytime soon.

I still feel sorry for people with multiple TVs in their house, the loss of analog channels and encryption of digital channels is gonna hurt them a lot more...

BTW, an interesting post was made to the DSLReports' forum:

>>As of today May 6, 2008, we began encrypting some HD channels in the Massachusetts market and we will continue to do so until all channels are encrypted. This includes High Definition channels that weren't previously encrypted such as local stations. Note the schedule below:

On 05/06/08 we encrypted:
A&E HD Ch 184 , History Ch HD Ch 186, Animal Planet HD Ch 187, Travel Channel HD Ch 188 , FX HD Ch 189 , LMN HD Ch 190, TLC HD Ch 191 , CNN HD Ch 192 and Discovery HD Ch 193.

On 05/14/08 we will encrypt:
HGTV HD Ch182, Food Network HD Ch 181, TBS HD Ch 174 ,TNT HD Ch 173, Comcast Sp Net HD Ch 171,ESPN HD Ch 166 , ESPN 2 HD Ch 169 ,
WLVI HD Ch 156 and WSBK HD Ch 159

On 05/20/08 we will encrypt:
NESN HD Ch 170, ABC HD Ch 160, CBS HD Ch 161, NBC HD Ch 162, Fox HD Ch 163 and PBS HD Ch 164

How does this impact our customers?

* Anyone without an RCN cable box or CableCARD will no longer see these channels.

* Most RCN customers will not even notice a difference. If they have a digital converter or a CableCARD, they won't see any change.
* Customers that have QAM tuners that were picking up unencrypted digital channels without paying for them will no longer see the channels.
o QAM tuners allow the free reception of digital programming previously sent "in the clear" by RCN; however, most digital channels were always encoded because they are outside of the "basic cable" package.
o QAM tuners are only available on high-end HDTV's, and the customer had to know how to set up the tuner to receive these stations. Few people know how to do this, so the amount of customers impacted should be negligible.
o For now, this does not affect a cable ready TV receiving ANALOG cable signals. This is just HD channels. Analog channels will soon be eliminated as well, but that is a future phase; we will send out another notification when that occurs.

+ Beginning July 8, 2008 in Massachusetts; all analog channels except for a constant advertisement will be replaced by an all-digital line up enabling us to put together a great new channel lineup.
+ Customers must have a box on each television by their implementation date or they will lose programming.
+ For new customers, the first standard converter box is free. New customers will be charged $2.95 a month for additional standard converter boxes. Current customers with out any converter boxes, will receive the same pricing. The 1st box free and $2.95 for each additional box.
+ If current customers have a box (RDIGCNV), they will receive additional boxes at the price schedule they are on: $2.95/5.95 OR $4.95/7.95
+ Letters and voice-cast phone messages are directing customers to call a local number, 781-xxx-xxxx, for details.
+ Direct customers calling Customer Service to request a new converter or to swap a converter to the Local Office first
Tags:
 
 
22 May 2008 @ 03:14 pm
Well, as foretold by my last posting, RCN has started encrypting all their digital channels in the Boston area now. I called tech support to find out the scoop, and was informed that indeed all channels except 2-22 and 93-98 would be encrypted. (those ranges include only the non-HD broadcast channels).

Their codename for this project is "Analog Crush". They almost got it right, if they just renamed it "Customer CRUSH", that'd be about it...If you want to read more people bitching about this topic, there are discussion forums at: AVSForum and DSLReports.

I had a really poor experience talking to their support people on the phone, and followed up with the following email to cabletv@rcn.com. We'll see what they say in reply.


Hello,

I have been a "triple-play" RCN customer since about 2002, and up until now have been entirely satisfied by the services provided. I receive Cable TV via a QAM tuner: <http://www.silicondust.com/wiki/products/hdhomerun> connected to a computer. Up until last week, I was able to watch your entire "Expanded Basic" lineup, and additionally, the HD versions of the channels available in the Expanded Basic lineup. I was quite happy with this.

However, recently, some of the channels started becoming encrypted. In particular, I seem to have lost FOODHD (181), TBSHD (174), HGTV (182), ESPN2HD (169), NGC (172), WSBKDT (159), WLVIDT (156), LMN (47), and BCTC (85). I am especially surprised that WSBKDT and WLVIDT became encrypted. These are channels that are available free over the air!

When I called up tech support today, they told me that these channels had indeed been intentionally encrypted, and that furthermore, all channels except 2-22 and 83-98 would be encrypted in the near future. He told me I'd need a converter box, for which I naturally expressed my displeasure, and transferred me to Sales to work that out.

When I got transferred to sales, everything went wrong. First of all, the rep was very argumentative, and kept insisting upon untrue statements that displayed a remarkable failure in the training process:
1) That I could not possibly have been watching HDTV channels without an RCN converter box for the last year. He had no idea what a QAM tuner was.
2) That it's all the FCC's fault that RCN is encrypting channels, and that I should not be upset at RCN for making this change.

This was not the start of a good conversation. And even after I tried to express that I wasn't interested in arguing with him, he continued to attempt to convince me I was wrong...Anyways...

As of now, I am a mightily unhappy customer: you want to force me to pay an extra $12/month to rent equipment that I do not want to have, and which will provide me poorer service than what I already had. When I expressed my displeasure to the representative, he essentially brushed me off and told me that I might as well go to another provider.

Additionally, the rep was unable to tell me whether or not your DCT-6200 boxes have firewire output enabled, and if they do have it enabled, whether the output is 5C encrypted or not. (actually, he had no idea that Firewire was even a thing that existed on cable boxes). This is an important point for me in comparison shopping for service. A cable box with a usable firewire output will allow me to connect it to my computer without the purchase of new equipment.

Thanks for any assistance you can provide.

James
Tags:
 
 
Current Mood: aggravatedaggravated
 
 
13 March 2008 @ 11:38 am
It seems like it's the beginning of the end for RCN transmitting in-the-clear digital channels. Starting last month in Chicago, they have turned off all their analog channels (fine with me), and started encrypting all their digital QAM channels (not fine with me). Apparently this wonderful future will be "coming soon" to their other markets as well.

What this means for normal customers: You need to rent a cable box for every TV you own, whether or not it already has a QAM tuner in it.

What it means for me: I will no longer be able to record TV on my custom built Digital Video Recorder (a HDHomeRun attached to a linux box running MythTV) anymore.

(For reference: currently, their entire basic lineup is broadcast in the clear in analog (SD) and digital (HD and SD))

If this change happens in Boston, I'm not sure what I'll do: encrypted QAM is almost totally useless to me. The approved way of decrypting the signal is by putting a CableCard in your tuner. However, not only do I not have any tuners with a CableCard slot, it's literally impossible to buy a tuner with a CableCard slot which will interface with a computer. I don't understand this: in Europe, the equivalent devices are quite readily available (search for a "DVB card with CAM support"). But not so for a CableCard.

That's not to say such a device doesn't exist. ATI makes a USB tuner with a cable card. It's just that you can only use it if you buy a brand new computer with it. And the brand new computer comes with Windows Vista, and (I guess, not really sure here) some mutant extra-DRMy firmware for the motherboard in the computer to make extra sure you can't do anything with the shows you've recorded. Apparently not even Vista's regular DRM is good enough for protecting cable TV. So, that's right out.

I guess I'll do one of the following:

a) I'm led to understand that it may be possible to get a set-top-box with a Firewire output, and that under some circumstances, the encrypted channels might not be encrypted on the Firewire output. If that's the case, that'd work, although not as nicely as just recording directly off the cable.
b) I could just use an antenna for broadcast channels, and cancel my cable subscription. (and download cable-only programs from the internet. TV shows on the internet often don't have any DRM at all, strangely enough.)
c) Or maybe figure out if it's possible to subscribe to a satellite service in the USA which works with a DVB card. (I think the answer is no.)
d) Or...give up and use the crappy cable box the cable company provides, like everyone else.

PS: I'm quite surprised there's no unofficial decryption software for digital cable streams yet. Or for firewire video streams. But as far as I can tell, there is not. I guess the DMCA is working!
Tags:
 
 
 
03 February 2008 @ 12:28 am
Apple's "Time Machine" backup solution is simple. A bit too simple. So simple, in fact, that it doesn't actually work right in a pretty common situation unless you're a clever hacker. So much for being easy for dummies.

Let's say, for example, that you have gotten your computer repaired, and thus have a new motherboard. The next time you try to back up your machine with Time Machine, you'll find that it wants to do a whole new "full" backup, which of course doesn't fit, due to the existing full backup already on the drive.

So, how do you make Time Machine do an incremental backup of the same hard drive you had before, now that it's in a new computer?

After a bit of fiddling around, I figured out that it stores the ethernet address of the machine you backed up, and that's how it figures out which backup directory to use. Where does it store it? A extended attribute of course.

$ cd /Volumes/james\ backup/ 
$ xattr -l Backups.backupdb/James\ Knight’s\ Computer/
com.apple.backupd.BackupMachineAddress: 00:1b:63:1e:77:4c


Looking at ifconfig en0 | grep ether shows that it should be 00:17:f2:f1:42:ad. So, let's just set the attribute...

$ sudo xattr -w com.apple.backupd.BackupMachineAddress \
 00:17:f2:f1:42:ad Backups.backupdb/James\ Knight’s\ Computer/
[Errno 1] Operation not permitted: 'Backups.backupdb/James Knight\xe2\x80\x99s Computer/'


Hmmmm, interesting, can't modify, even as root. I'll save you the random flailing I did next, and get right to what works (and I really have no idea what kind of insane-o permissions scheme does make the following work...)

$ sudo mv Backups.backupdb Backups.backupdb2
$ sudo xattr -w com.apple.backupd.BackupMachineAddress \
 00:17:f2:f1:42:ad Backups.backupdb2/James\ Knight’s\ Computer/
$ sudo mv Backups.backupdb2 Backups.backupdb


All done! Just unmount and remount the backup drive, and time machine will properly recognize it again. Now if only Apple had thought to key backups off of some identifier on the actual volume being backed up, instead of the machine doing the backing-up. Doesn't seem like rocket science, does it?
 
 
02 January 2008 @ 12:05 pm
In order to counterbalance the previous story of terrible customer service, I thought I'd tell a story of awesome customer service.

I live in Somerville, MA, and they have the most amazing service ever: automated calls to tell you about important events.

Are they going to start deconstructing the road to my house? They call and tell me where and when it will be closed! Is a snow emergency being declared so I have to make sure I'm not parked in a no-snow-emergency-parking spot? They call and tell me! Their dialer is even smart enough to be able to leave a message properly on an answering machine. Amazing technology, isn't it?

The whole idea of some entity actually calling me with information I want to receive is almost completely foreign. Based on previous experience, I might've thought that there was a law against large entities making outgoing calls, unless they have no prior relationship with you and want to sell you something.

Wouldn't it be nice if more companies could proactively inform you of important issues?

(BTW, if you live in somerville and don't get these automated calls, you can sign up by calling 311 (617-666-3311 from outside of Somerville))
 
 
31 December 2007 @ 04:45 pm
I've been using Macs all my life, and have been interacting with Apple support to get repairs for just as long. And it's mostly been positive experiences. However, my latest experience with them has been pretty terrible.

Last Thursday (Dec 27), while I was at work, my Macbook stopped working. Dead. Doesn't power on, no signs of life. So, I called AppleCare, around 8:10PM EST (5:10PM PST). The recorded message nicely told me that they closed at 6PM Pacific, and that I should call back another time. Great start.

So I call back Friday, and of course they're extremely busy, it being right after Christmas. I'm told there will be around a 60minute hold time. And of course I'd have to wait for a box before sending it in anyways. So I hung up and made a reservation at the Apple Store Genius Bar nearby, instead, to expedite matters.

So I take my laptop to the Genius Bar. They examine it briefly, determine that it's dead, are want to send it off for repairs. I ask if I can take the hard drive out first. After all, I reason, the machine doesn't boot at all, and the hard drive is trivial to remove on a MacBook, wouldn't it make sense for me to just keep it so I don't have to worry about the data? The Genius hems and haws a bit, and then goes into the back to ask someone else. When he comes back, he says "okay, if you know how to remove it." I do, so I did. And they take away my laptop.

Today, when I proactively check the repair status webpage, I see:

Step 1 - Request Product received by repair center (31-Dec-2007)
Step 2 - Service On hold - Need information (31-Dec-2007)

"Need Information", what kind of information could they possibly need? And why don't they just call me: they took down my phone number!

So I call AppleCare. And wait on hold. Fortunately, this time it's only 15 minutes. The Product Specialist says "it says it requires a re-quote, I don't know what that means." So he calls the repair center. After being on hold for another few minutes, the repair center answers.

"Your machine has an unauthorized hard drive in it." Wow, news to me, because I sent it without a hard drive at all! Did the Apple Store put in an unauthorized hard drive for me? "Oh, no, it has no hard drive. We can't repair it like this." I go on to repeat that I was informed it should be okay. I wonder aloud why they need a hard drive in the machine to fix it so that it can power on. We go back and forth a bit before I get transferred to a "Liaison" (after another 10 minutes on hold). She also informs me that they couldn't *possibly* touch the machine unless it has an apple authorized hard drive present, no way, no how. So I reluctantly agree to have my laptop shipped back to me, unrepaired.

Knowing something about the way these things work, I think to inquire if I can use the same box to ship it back to them again, or if she can also send me an empty box. The Liason answers that of course I'll need a new empty box box, but that she can't do that: I need to talk to a Product Specialist again, to set up a new Dispatch to get a return-shipping box. And Product Specialists have a 15-20 minute hold time. And I've been on the phone with them for 60 minutes already. Sigh.

So, anyhow, I'm now sans-laptop for an extra week or two. Wonderful.
 
 
Current Mood: annoyedannoyed
 
 
So I'm checking out the new features in the OSX Leopard terminal. Tabs, great. Can actually draw Monaco 9 properly without tweaking the FontWidthSpacing to 1.003, check. Wait, what's this? ESC 2J no longer fills the screen with the background color? Who the hell writes a terminal application that doesn't use bce? Especially considering the previous version did. This terminal claims to be xterm. And xterm supports bce. Even the xterm terminfo on osx says it supports bce! (infocmp xterm | grep bce)

For a simple test of your terminal's bce-supportingness, type this:
python -c 'print "\x1b[44m\x1b[2J"'
Your whole screen should end up with a blue background.

Seriously, Apple: what's up? Is there some maximum amount of goodness that's allowed in Terminal.app, so after fixing all the other things, you had to balance it out with some additional sucktitude? Or maybe I'm missing something really obvious here?

PS: I should mention: this isn't just idle concern. It actually does break terminal apps. Most full-screen apps which draw a background color will now look wrong, because the background color will only appear under the actively drawn text. For a good example, try mutt.
 
 
08 October 2007 @ 11:35 pm
Occasionally my MacBook reboots when I close the lid and drop it in my laptop bag, instead of properly going to sleep. I found this a bit odd, because my old Powerbook was absolutely 100% reliable at going to sleep, but I originally just chalked it up to unreliable firmware on the new architecture and thought it would likely just be fixed soon. But it wasn't. I did notice after a while that it only happened when I was putting my laptop in the bag. Hmmm.

Apparently, the "Safe Sleep" feature is interacting poorly with the "Sudden Motion Sensor" feature. On newer macs, instead of just saving state to RAM (which, in my opinion, was perfectly fine...), they also write the state to disk. This takes a minute or so to do. If you jolt your computer during this time enough to cause the SMS to park the drive, it just reboots, discarding all your state. Of course, the sensible thing for it to do would be to wait for the motion to stop, unpark the drive heads, and continue writing. Or even just forget about writing to disk, and just use the already-saved-to-RAM suspend state. But no, it reboots.

In all the time I've owned a laptop, I'm pretty sure I've never left my computer alone for long enough that the battery runs down and loses the RAM. So, I can't see any real use for Safe Sleep to begin with. But I've lost my state quite a few times now due to this bug. So, here's how to turn off "safe sleep" and go back to good ol' reliable RAM sleep mode.

To disable it temporarily (until reboot):
sudo rm /private/var/vm/sleepimage

To disable it permanently, do the above, and:
sudo pmset -a hibernatemode 0

For some more discussion on the topic, see another blog