James Y Knight

msktutil -- Linux/Active Directory keytab management

2010-03-22T21:18:09Z

At work, I've been working on a little side project for a while: getting my Linux (Debian Lenny) box to play nicely with our Windows Active Domain controller. I did get it working, with login, ssh, firefox doing kerberos against AD, and with user info, groups, and automount data coming from AD's LDAP. I plan to post a writeup of what I did soon. It's all done using the standard tools and libraries, but there's many irritating nits.

But in the meantime, I'd like to announce version 0.4 of a tool called msktutil. It allows you to conveniently create and manage computer objects (that is: kerberos accounts for your computer) in Active Directory, while also writing out and managing the keytab. This allows much easier provisioning of machines, including a keytab suitable for kerberized ssh.

I use it like this (holding valid kerberos tickets that can add hosts to AD):

for hostname in $hostnames; do
  msktutil --precreate -h $hostname -s host
done

to create a bunch of accounts. Then, on each machine, there's a daily cron job which runs

msktutil --auto-update

which checks if the keytab needs to be updated, either because it's missing or because the password needs to be rotated (when it's 30 days old). I also run that at install time. And that doesn't need any credentials besides the keytab itself.

See the man page for more usage info.

Also, a shout-out: this tool was not written by me; I am simply continuing the work of those who came before me. It was originally written by Dan Perry, and over the years since, updated by Brian Elliott Finley and Doug Engert. Many thanks to each of them.

BTW: if anyone knows anything about debian packaging, it would be nice if you could fix it up for me. I'm no expert, but I'm pretty sure the packaging scripts in there now show their age, and are sorely due for an update. Have a Git repository if you like. Patches welcome. :)

The Hunger Games

2010-01-17T02:50:11Z

I just finished reading the book "The Hunger Games" by Suzanne Collins, for the second time in as many weeks. The first time through, I read the entire book almost straight through in about 8 hours, so I figured I ought to read it again a little slower. It was just as good the second time.

The book takes place in a future North America, where due to some prior disaster (not really mentioned), there are only a few remaining cities: the Capital, and twelve surrounding "districts". At some point, the districts attempted to rebel against the powerful capital, and in punishment, they are forced to participate in the "Hunger Games". Every year, each district must send two teenagers to participate in a televised multi-week fight to the death "game": 24 enter, one survives. (think Survivor, except with killing instead of voting.) The story is told from the point of view of the girl tribute from District 12 -- what remains of "Appalachia", now with a population of 8000. But my description doesn't really do it justice: it's quite a gripping tale, filled with action and emotion.

It's certainly one of my all time favorite books...on to the sequel!

Apple mail no longer uses format=flowed???

2009-12-12T20:57:08Z

It seems to always send mail with quoted-printable encoding now...sigh.

I sent this feedback to Apple with their "Provide Mail Feedback" menu option, but I have no idea if anyone reads that...so I'll post it here too, which I know at least some people from Apple read. :)

Mail.app used to encode long lines with format=flowed, which caused it to be nicely wrapped in mailing list archives, and for people using old mail readers that can't handle long lines.

Now, as of 10.6.2 (I think?), it's started sending all mail with quoted-printable encoding instead. This is terrible! Now my emails are nigh-unreadable in many online archives. For example, a bug report I submitted to Debian via email:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560781

That would not have happened with format=flowed encoding.

Please please pretty please with sugar on top put it back? Hopefully by default, but, if not, at least make it an option?

Anyone have a copy of Mail.app from 10.6.1 they'd like to send me?

Puzzle

2009-11-01T21:44:10Z

I was cleaning up some old junk from boxes in my house, and came across this puzzle I was given in 1993.

Once upon a time, there lived 800 green-eyed people and 200 blue-eyed people on an island. No one on the island knew their own eye color, nor did they know the exact number of blue and green eyed people on the island. There was a local taboo against talking about eye color (which the citizens never violated), and there were no reflective surfaces on the island. There were absolutely no physical means for a person to determine his or her own eye color. The citizens on this island were all firmly committed to the belief, however, that if a person could figure out that he or she had blue eyes by using logic, the person had to commit suicide at midnight of that day.

Every day at noon, the citizens met in the town square to stare lovingly into each other's eyes. All was happy and gay. Then one day, day 0 to be exact, an oracle descended upon the island from the heavens and announced during the noontime meeting, "There are blue-eyed people on this island." The citizens promptly stoned and killed the oracle.

What happened after that day, and why? (Notice that the oracle said something all the citizens already knew.)

Enjoy. :)

On contracts

2009-07-14T18:51:57Z

Amitha recently was looking at some contract writing work, and one of the potential contracts (from IC Romance, in case you're interested...) was quite odd. It contained 8 pages worth of entirely reasonable terms, but in the middle of the "Termination by Notice" section, contained this gem:

This Agreement can be modified by the Contracting Party [note: that's them] at any moment and can be terminated by either party in writing with 14 days notice.

Is that for real? What is the point of a contract that can be modified at any moment, unilaterally, by one party? (I'd take that to mean without any notice or ability to opt out, as well...) When called out on that sentence, they claimed that it's a generic contract, and they will not agree to any change in the terms whatsoever.

I do hope they aren't actually taking advantage of less acute readers of their contracts, but it seems very sleazy to put that kind of wording in a contract, even if you aren't planning to use it for immediately evil purposes. I'm certain they would never agree to a contract that she could modify unilaterally at any moment! I really can't imagine doing business under those terms, and it does somewhat make me wonder whether they're even a legitimate company.

PS: A Star Wars quote seems somewhat apropos: "I am altering the deal. Pray I don't alter it any further."

Killing emacs22 annoying splash screen

2009-07-08T00:46:51Z

(But leaving it available when it's not annoying)

I recently upgraded from emacs 21 to emacs 22 on my desktop, and was irritated to note that "emacs filename" now splits the screen in two with one split showing a useless splash screen.

Emacs has always shown a splash-screen when invoked with no arguments, but the new behavior is to show it when your'e trying to edit files! This is, needless to say, stupid. In their defense, the splash-screen it shows has a checkbox on it "don't show this in the future", which will disable it forever by setting "inhibit-startup-screen" to t.

You might wonder why they even added a new annoying behavior that clearly will cause everyone to permanently disable the splashscreen? If you're really interested, check out this long thread (and I'm sure there's many others besides). Basically: it has to do that because RMS says so. It seems that the original implementation of the new splashscreen was much much more annoying than the current one, so I guess be glad that saner voices managed to have some sway.

Anyhow, this was sufficiently irritating to me that I'd like to disable it site-wide, so nobody I work with needs to be annoyed by it. I'd really rather not set inhibit-startup-screen to t by default, because I have nothing against the previous behavior of showing the startup screen when emacs is invoked with no arguments.

I fixed it, by adding the following to /etc/emacs22/site-start.d/01nosplash.el:

;; This hack removes the really annoying splash screen that emacs22
;; now displays by default, even when you're trying to edit a buffer.
;;
;; While there is the variable inhibit-splash-screen, that only lets
;; you inhibit it *always*, which I don't really want to do in site
;; configuration. This patch causes it to still be shown when no
;; buffers were specified on the command-line, like emacs used to do,
;; before RMS forced it to be made annoying.
;;
;; This works because this function is called whenever a filename is
;; specified on the command line, which is almost exactly when I want
;; to inhibit the splashscreen. (it also catches a couple other cases
;; like -script, -load, and -L, but that doesn't really matter).
;; --jknight

(defadvice command-line-normalize-file-name
      (before kill-stupid-startup-screen activate)
  (setq inhibit-startup-screen t))

Hope it helps you too. :)

Commit message formatting

2009-05-20T02:21:46Z

(or: GNU coding standards considered harmful)

I've recently been watching GCC and GDB development, and every time I have reason to go looking through their commits, the total lack of useful information in the commit messages really strikes me.

Take this commit message for example, reproduced below for your convenience:

Log message:
	* fork-child.c: Don't include frame.h.  Include terminal.h.
	(fork_inferior): Call new_tty_postfork after forking adn adding
	the child to the inferior list.
	* inferior.h (new_tty_prefork, gdb_has_a_terminal): Don't declare
	here.
	* inflow.c (struct terminal_info): Remove const qualifier from
	`run_terminal' field.
	(inferior_thisrun_terminal): Tweak comment.
	(inflow_inferior_exit): Release the `run_terminal' field.
	(copy_terminal_info): New function.
	(new_tty_postfork): New function.
	* terminal.h (new_tty_prefork, new_tty, new_tty_postfork,
	(copy_terminal_info, gdb_has_a_terminal, gdb_setpgid): Declare.
	* inf-ptrace.c: Include terminal.h.
	(inf_ptrace_follow_fork): Copy the parent's terminal info to the
	child.
	* linux-nat.c: Include terminal.h.
	(linux_child_follow_fork): Copy the parent's terminal info to the
	child.
	* inf-ttrace.c: Include terminal.h.
	(inf_ttrace_follow_fork): Copy the parent's terminal info to the
	child.

Okay, so quick quiz: what does this change do? Does it fix a bug? Add a feature? Can you tell from this message? If you get lost in the useless meaningless text, well, me too.

What if instead of showing you that, I showed you this email and this email about an earlier part of the same change. Isn't that much better? Wouldn't it be nice if I'd shown you that to begin with?

Before you think I'm just picking on the maintainers of gdb, let me now point you to the GNU coding standards changelog guidelines, which they're faithfully following.

There's no need to describe the full purpose of the changes or how they work together. If you think that a change calls for explanation, you're probably right. Please do explain it—but please put the explanation in comments in the code, where people will see it whenever they see the code. For example, “New function” is enough for the change log when you add a function, because there should be a comment before the function definition to explain what it does.

Let's think about this...gdb (and all the rest of the GNU projects) are using a version control system. Even one as poor as CVS can tell me that a function is new, when it was added, and who did it. So exactly what value is putting "(new_tty_postfork): New function." in the changelog? Absolutely none. Did I really need the author to tell me that a new .h file was being included now? No, of course not, even if that might be interesting for some reason, it's utterly obvious from the diff.

The GNU coding standard is being actively harmful here, by recommending that people put useless junk in the change message, instead of an explanation of the change. It's really rather unfortunate.

What do I want to see in a commit message? Well, it seems to me that basically everyone except the GNU project has this well figured out already, but:

At a high level: what does the change do (implementation), and what is it for (reason). Include both a one-line summary of the change, and then some prose describing it in more detail. Try to keep it high level: in most cases, the details about each individual thing you touched in your change isn't necessary. I should be able to get that from the diff directly.

India - airlines

2009-01-11T05:19:41Z

Thirdly: airports and airlines. I've now travelled on four different airlines in this journey so far. From Boston to Delhi, we took British Airways. It was nice, as expected, although the knee room left something to be desired.

Next up was Delhi to Udaipur on Jet Airways. We had a five-hour delay in the Delhi airport due to fog, And the Delhi airport is somewhat of a disaster. It's small, and crowded. Fortunately, we spent the time in what they called a "Restaurant" but was actually more like an airline lounge for a cost of Rs 250 per person for unlimited snacks, drinks, and comfortable uncrowded seating. Totally worth it.

One interesting difference in security procedures is that you are not allowed to leave the airport. There's actually two layers of not-allowed-to-leaveness. First, only ticketed passengers can enter the check-in area. And you can't leave. Second, only checked in passengers can enter the gate area. And you can't leave.

The next flight was on Indian Airlines, which seems to be the intra-India portion of Air India. We got stuck in the airport in Udaipur for six hours, again due to fog in Delhi. The Udaipur airport was rather interesting. It's a giant building (3 tall stories), absolutely brand new. The first story is departures and arrivals. The second story seems to be unused departure lounges (departures were all leaving from the first story). The third story is a viewing lounge: you can pay Rs 25 to watch the runway from the viewing lounge. Why? I don't know.

Indian Airlines took good care of us during the delay: they gave everyone on the flight complimentary breakfast, and then took everyone out to eat complementary lunch at a restaurant nearby to the airport, since the airport has too little traffic to actually have a real restaurant itself. But wow, is their equipment ghetto. The bus they used to take us to the restaurant had a faded barely visible warning on the back of the seats: "WARNING: CHECK FOR BOMB UNDER SEAT. IF FOUND CONTACT AUTHORITIES IMMEDIATELY." It makes me rather curious what this bus's previous life had been. The airplane was little better. It was a prop plane with an interior cabin that looked like it hadn't been touched since the 80s.

We're now on to South India, having just arrived at the Delhi airport again to depart for Cochin. And again we're delayed due to fog. This trip is on JetLite, which I assume is the low-cost carrier devision of Jet Airlines.

India - cellphones

2009-01-11T05:11:46Z

Next up: cellphones. They are ubiquitous. Not just the phones themselves, but the advertisements, and the stores selling prepaid cards for them. Every little store will have giant ads on the front for Vodaphone, Idea, and AirTel. Many places have all three giant signs on their store. Then sometimes you'll go past entire blocks painted with repeating ads for one of those three cellphone companies.

On the second day after I arrived in Delhi, I managed to get a SIM card. This was fairly straightforward: I only needed a photocopy of my passport and two passport-sized photos (the store took them for me), and the address where I live (in India). Just in case you didn't know, I don't live in India. So, I had planned to get AirTel, but the owner of the little hole-in-the-wall shop advised me that I'd be better off with iDEA, because AirTel attempts to verify your address a week after you purchase a SIM. Since I'm not staying at any hotel for more than a couple days, that might be a problem. I guess IDEA doesn't do that. Dunno. In any case, I got a SIM card for Rs 99, and paid Rs 500 for Rs 350 worth of "talk time".

I was advised that I could get a Rs 20 / day unlimited data plan if I called customer service, and I left. Later that night I attempted to call customer service. Unfortunately, this was an automated menu system, with prompts only in Hindi.

Now mind you, the packet the SIM card came with is bilingual: English and Hindi. The page telling me what number to dial to reach customer service was in English. Every representative I ended up talking to spoke English to some degree or other. But the menu system was only in Hindi. One of the people I'm traveling with speaks a bit of Hindi, so I wasn't even totally helpless. But even so, we had a lot of trouble figuring out the proper menu choices. So the first representative we spoke to said that it was the wrong department (I think it was the postpaid customer support), and when we enquired how to access the correct people, since the Hindi was somewhat of an issue, he said "oh you just press 1 for English in the menu" and hung up. Which was false. Eventually, I managed 1-1-9 to get to a human who didn't hang up. Success! And it turned out I just had to SMS "ACTNET20" to 12345. What he didn't tell me was that it would take a day and a half to go through. Wasted about Rs150 on non-unlimited data before that actually went through. Oh well.

India

2009-01-11T05:07:40Z

I've been in India now for a week with my whole family and most of my wife's family too. It's my first time visiting, and it's quite exciting. We arrived in Delhi with about 5ft visibility on the ground, had a whirlwind tour of Delhi, Udaipur, Jaipur, Ranthambhore, and Agra. Of course we saw all the staples: Qutub Minar, Humayun's tomb, Udaipur City Palace, Amer Fort, Janthur Manthur (quite an amazing Astronomical Observatory), went on a tiger safari (but didn't see any tigers), and of course saw the Taj Mahal.

They were all really neat and fun to visit, but I'm not going to write about all that standard touristy stuff. Instead, I'll note a few things that intrigued me.

In the following, it may be useful to keep in mind that Rs 50 (INR) is approximately $1 (USD), So, Rs 1000 is $20.

Firstly, the driving. It is crazy. The roads are one-and-a-half lanes wide, and we are in a small bus, barreling down the road honking every few minutes to let vehicles know we are going to pass or to tell oncoming vehicles not to hit us. And I use the term vehicles rather loosely. This covers anything from dogs, donkeys, cows, horses, camels, humans, bicycles, motorcycles, rickshaws, cars, busses, trucks, and in some places, even 18-wheelers. All sharing a narrow road passing eachother frequently.

Depending on the city, traffic lights seem to be entirely advisory. In Delhi, they were followed, but in Agra, I can't say I could figure out how to tell which lights were to be stopped at and which were to be ignored.

TV Antenna

2008-12-08T15:48:37Z

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.

Cilk: multithreaded programming model of the future

2008-09-13T21:38:12Z

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. :)

RCN redeems themselves to me

2008-05-31T22:28:35Z

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

RCN "Crushes" their customers

2008-05-22T19:25:49Z

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

Sucks to be a RCN customer (soon)

2008-03-13T16:19:49Z

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!

Time Machine

2008-02-03T05:47:32Z

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?

Somerville Cares

2008-01-02T17:22:43Z

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))

AppleDoesntCare

2007-12-31T22:44:31Z

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.

OSX Leopard terminal drops bce (back-color-erase)??

2007-10-30T02:54:24Z

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.

Unsafe sleep: Macbook spontaneously rebooting.

2007-10-09T04:03:55Z

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

suid without eating environment?

2007-09-24T21:32:03Z

So I want to write a setuid program. And, I want it to not eat the environment (namely, LD_LIBRARY_PATH). It seems that this is impossible to do in linux.

Now, you might reasonably ask why I would want to do such a thing?

Here's an outline of what I want:

a) User invokes setuid program, giving as arguments another program they want to execute.
b) setuid program does some stuff as root (let's say, for illustrative purposes, setting niceness level to -10)
c) setuid program drops privileges
d) setuid program calls exec, passing the user-specified program.

So, see, I'd really like LD_LIBRARY_PATH to pass through my setuid app, to the exec'd (as the originally invoking user) process.

Here's what I found:

ld.so eats all the linker environment variables before even starting my program. Okay, surely it'd be better to ignore them instead of removing them, but whatever, I'll just link my program statically, that ought to solve the problem, right?

NOPE. I lose. In the name of security, the statically-linked-program startup code also erases the environment variables. Apparently there was a security hole at one point with some statically linked suid program calling exec without passing an explicit sane environment. The program it exec'd, if dynamically linked, would of course use the LD_LIBRARY_PATH in the environment, since it wasn't suid. Oops, instant root vuln. So to fix this, even statically linked programs cleanse their environment.

But one silver lining: in the statically linked case, it's actually glibc startup code which is eating the environment, which theoretically I should be able to override in some fashion. All I have to do is take control of the startup sequence before glibc cleanses the environment, make a copy, and continue the normal startup sequence. I thought perhaps defining _start myself, or something along those lines, but I can't manage to get it to work.

Can anyone help me?

How not to deprecate

2007-09-19T03:02:25Z

I'd like to tell you a story today. (Okay, maybe that's a lie. It's really more of a rant.)

Perhaps you're familiar with the program "find". You can (ahem) find it on pretty much any unix system since the dawn of time. This story is about one particular "find" implementation: GNU find, and in particular, two of the predicates it supports: -path, and -ipath.

Sometime in 1993, GNU find 3.8 was released. This release had a few new interesting command line arguments, including "-path" and "-ipath".

On Dec 30, 1993 NetBSD got -path (with comment: "Merged our bugfixes with the 4.4BSD find from uunet")

On May 27, 1994, the history for find in FreeBSD's cvs repository starts. It had -path, but not -ipath.

On Feb 23, 2001, FreeBSD find added -ipath (amongst others)

Okay, now on to the fun part

On Aug 8, 2004, GNU find deprecates -path and -ipath at the request of Richard Stallman, and at the same time, adds two new names for the same functionality: -wholename and -iwholename. Why? Because he didn't like the names(!). The maintainer of find went along with the request. Furthermore, he states "Use of the predicate -ipath generates a warning about the deprecated status of -ipath. Use of the predicate -path does not, since -path is also implemented by the HP-UX operating system." The deprecation and new predicates make it into GNU find 4.2.0.

Okay...so, let me get this straight: it's considered important, in 2004 to keep compatibility with HP/UX, a dead commercial unix, and thus find doesn't print a warning for the now-deprecated "-path" predicate. But apparently nobody cares about keeping compatibility with 10 years worth of GNU find syntax (and, not coincidentally, 3 years of history in FreeBSD find), so it's okay to print annoying warnings about -ipath? Wow, just Wow. Nice priorities there. Cause, you know, there's nobody who'd ever want to write any script which works on GNU find 4.1 and GNU find 4.2 at the same time.

Oh, but it gets even better, now.

On Aug 17, 2007, a bug is reported against find:

The next revision of POSIX (at least, as of draft 3 of POSIX 200x, freely available to Austin group members), will mandate the addition of the -path expression.

Right now, GNU find has -path == -wholename, and -ipath == -iwholename. Of these four expressions, only -path is (going to be) POSIX-mandated, while only -ipath causes a deprecation warning. Perhaps it is time to reverse this, and make both -path and -ipath be warning-free, and instead make -wholename and -iwholename issue deprecation warnings (-wholename because the same thing can be achieved via a POSIX-mandated alternative, similar to how -d is deprecated in favor of POSIX-mandated -depth; and -iwholename for consistency with -wholename).

The patch was applied on 22 August 2007, to be released in GNU find 4.3.9.

On Sep 18, 2007, I installed Debian etch on a system, which has GNU find 4.2.28 rather than 4.1.20, and it starts printing loads of warnings: "find: warning: the predicate -ipath is deprecated; please use -iwholename instead.". I investigated the reason why the change was made, and get even more irritated. I then find that GNU find 4.3.9 reverses the change and get even more again irritated.

And finally, one last gem: GNU find 4.2 also introduced new extensions: "-warn" and "-nowarn" to "Turn warning messages on or off. The default behaviour corresponds to -warn if standard input is a tty, and to -nowarn otherwise." Wow, that almost sounds sensible. So all I have to do is use find < /dev/null to get rid of the warning in a compatible way. No, of course not, that would be way too easy. I'll give you one guess as to what warning message -nowarn doesn't suppress. Very funny, eh?

Please, if you write fundamental software that I depend on, try not to screw up like this. If you're going to make a change that has negative value to begin with, at least have the decency to do it right.

Python 3 Book Proposal

2007-09-13T16:29:09Z

I'm not sure what to think about this email I received yesterday. Were the messages I wrote to the python-3000 mailing list sufficiently witty as to attract the attention of a book publisher? Or maybe it was my awesome expositional abilities?

Or maybe this was spam, just blindly sent out to random people who had written emails to the list. I'd like to think the first, but the second seems more likely given the content of the message...

I am writing you as an acquisitions editor with
[Omitted]. I came across your name on the
Python 3000 mailing list. I have recently heard about
Python 3, and was wondering if you are very familiar
with the program? Do you expect it to grow in
importance and/or?interest? Do you think it would be a
good book topic to pursue? If so, any potential
authors come to mind? Or perhaps this is a project
that interests you???Your feedback is greatly
appreciated. I look forward to hearing back from
you.??

(Note: extraneous ?s are original, not an artifact, on my side, at least).

MythTV

2007-08-23T20:23:09Z

About four years ago, I put together a small linux box with 512MB of RAM, an Athlon XP 1800+, a Hauppauge TV tuner card, a 120GB hard drive, and MythTV. I connected this to my TV with an S-Video cable from the built-in motherboard video, built myself a IR receiver and had a pretty nice PVR.

Of course, over the years, I've upgraded various pieces of the system. I added a DVD drive, and threw out my set-top DVD player. It turns out, mythtv not only makes a better PVR than is available commercially, it also makes a better DVD player than many on the market. Partly because of two "features" it doesn't have: "user-operation prohibited" (aka: You Will Watch These Previews) and Region Coding. But also, it has a good output scaler, the drive doesn't often have trouble reading DVDs, and it doesn't crash as often as my old player did. (yes, that's right, my hardware DVD player crashed more often.)

I've also done some upgrades in support of High Definition TV. I now have a PCHDTV 3000 digital tuner to record the MPEG-2 digital streams (some HD, some SD), a GeForce FX 5200 video card to be able to output the 1920x1080 resolution, and a Infrant ReadyNAS with 500GB (soon to become 750GB) of storage.

Cost is certainly not an advantage this system has over renting a PVR from your cable company. It's been a while, but as I recall, the original system cost me about $600 to put together. All told, the upgrades since then probably cost another $800.

I won't go through the many advantages it has over a cable company PVR or a tivo, but, two of the most obvious are automatic commercial skip and that you can schedule programs via a web server, rather than having to use a remote control. But the most important to me, really, is control. I can make it do whatever I want. I don't have to be limited by the functionality the cable company wants to let me have. I'm no "open source or die" zealot either. But when they're putting the majority of their work into features expressly designed to inconvenience me, it just makes sense to use an open platform.

However, there are two ways I'm quite dependent upon the whims of an external company for it to keep working. The first is the actual cable signal. I'm lucky enough to live in an area in which both RCN and Comcast provide cable service. I'm very happy about that, because RCN provides unencrypted MPEG-2 streams for all the "basic cable" channels, plus a few extras. And that's a pretty good list. I'm told Comcast does not; they encrypt everything except the channels available over-the-air. Now, RCN doesn't broadcast unencrypted by mistake, it is their explicit policy. However, there's always the concern that they might decide to change that policy once CableCards become more ubiquitous. If they did, I'd be in trouble, as it's currently impossible to use a CableCard with linux. This is of course by design (as I'm an evil hacker trying to pay for and watch their content, don't'cha know, can't have that).

Oh, and while in the middle of writing this, I just ran across an article discussing how users of the HD TiVo are also going to be screwed soon, because the HD TiVo doesn't support bidirectional CableCard communication. Why doesn't it? Because the cable company wants to control the entire user interface of any device connected to their network. So much for innovation...

Anyhow...

Another important part of a PVR is the tv listings. If it doesn't know what programs are showing, it's not really usable. While you might think that obviously the TV stations want to disseminate the program listings as far and wide as possible, it turns out, the TV listings aren't actually provided by the stations. They often have no idea what they're playing, other than the absolute basic timeslot data. So, no episode info, descriptions, etc. In the USA, much of that is determined and distributed by one of two companies: Tribune Media Services or GemStar. Of course, my cable company pays one of them for a subscription to the listings, so they can show it to me on the TV Guide channel and the set-top-box TV guide. But do they make the data available to me? Of course not. Luckily TMS has been directly providing a data feed in XML format free for non-commercial use for a few years now. Unluckily, they decided to shut it down, effective September 1st.

Fortunately for me, a number of tv-related OSS developers got together and started a non-profit organization, Schedules Direct, to fill this void. Unfortunately for me, they now charge a subscription fee, to cover the fee that TMS is in turn charging them.

So, now, I'm going to have to pay a subscription fee to get the same guide data that I'm already paying for as part of my cable subscription. The cost is pretty small, but still, irritating.

Why do content companies try to make it so damn hard to pay them for content? I'd be in the market to upgrade to an HD-DVD or Blu-Ray drive to replace the DVD drive, except, of course, I couldn't use it, because it's currently impossible to play such a disk on an open platform. I'd be willing to pay the cable company for some premium movie channels, except, of course, I couldn't use them, because it's impossible to decrypt them on an open platform. It really boggles my mind.

Adventures with bzr (part 3)

2007-08-16T04:29:09Z

My bzr adventures are unfortunately not going as well as they seemed to be initially.

Here's the scenario that more closely models the actual workflow I wish to have with bzr.

The players:
1) Official "trunk" SVN repository
2) Automatically updated BZR repository mirroring SVN repository. Not writable by anyone other than SVN server.
3) A bunch of users.

Here's the plan:
a) User 1 makes a branch off BZR repository.
b) User 1 works on some code.
c) User 2 makes a branch off BZR repository.
d) User 2 merges User 1's branch into his own
e) User 2 modifies some stuff User 1 was working on.
f) User 1 makes some final commits to his branch and then pushes his branch to SVN.
g) BZR mirror of SVN gets auto-updated.
h) User 2 pulls new revisions from BZR mirror of SVN. bzr should know that the commits he merged directly from User 1 have already been applied and not try to re-merge them.
i) User 2 commits to SVN.

And now, the problems...

Problem 1
--------
bzr-svn has a time-consuming step of pulling down all the revision mapping info from the svn repository, and then analzying the repository to figure out the branching scheme, before it can do anything. This data isn't stored with the branch, it's instead stored in ~/.bazaar. This means that every user has to repeat this, the first time they want to get started with bzr. Unfortunate.

Problem 2
--------
Remember bug 131692 I ran into before? Well, that is killing me again, but this time I don't know how to work around it easily. Step (h) works (bzr does indeed know which commits were merged, as it stores that info in file properties in the svn repository, yippie!). However, User 2 cannot commit back into SVN, because of that bug.

Problem 3
--------
My actual repository is laid out like this:
trunk/project1
trunk/project2
branches/project1/mytestbranch/project1
branches/project1/mytestbranch/project2
branches/project1/releases/1.0/project1
branches/project1/releases/1.0/project2
branches/project2/whateverbranch/project1
branches/project2/whateverbranch/project2

When I first used bzr-svn, I told it to pull from $SVNREPOS/trunk/project1. Now, when I did this, it chose a branching scheme of "single-trunk/project1" (as shown in ~/.bazaar/subversion.conf). So, now it refuses to pull down any other projects or even other branches of the same project. It recommended that I type "bzr help svn-branching-schemes" and choose a different branching scheme, but this didn't help me, as there are only two options listed there: "trunk", for the /trunk/* layout, and "none" for no branches, just one branch at the root.

AND! This is a per-user configuration variable. So, even if I do find out that there is a branching-scheme I could manually change to in the configuration file, every user would also have to make this same modification to their configuration file. That's not really usable.

Problem 4
--------
bzr is currently *damn* slow. My repository has about 60k revisions in it. This seems to be more than bzr is currently able to really handle. Making a branch from shared repository to other outside the shared repository (on a local disk) takes about 15m, and making one within a shared repository takes 1m30s. The first number is important, because bzr will take at least that long for a remote user to get the repository. The second number is important, because this is something that people are supposed to be doing often. And both are simply way too long.

The end
------
I think this'll probably conclude my experimentation with bzr for now. It's looking nice, but it's just not usable quite yet. There seems to be quite a lot of activity going on trying to fix issues (most especially I know the speed issues are being worked on), so I hope that when I try again another release or two from now, bzr will be blazing fast, and the bugs and usability problems in bzr-svn will have been fixed.