James Y Knight

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

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!

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?

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

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."

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

(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.

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.

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.

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.