Here’s my new proposed Terms Of Use agreement that such firms can use as a CYA in the future:

TERMS OF USE: You understand and agree that:

• Inevitably, this website will be compromised. I mean, sh** happens.
• We store much more of your confidential information than is really  necessary, so when the inevitable compromise occurs, you’ll be f**ked eight ways from Sunday.  But it won’t be our fault.
• When the media descends on us after a breach, we will loudly protest that we use “the strongest industry-standard security measures” and that we “monitor our site constantly”, all of which won’t matter because you’ll be f**ked eight ways from Sunday.
• We will quickly wring our collective hands and apologize that “this should never have happened”, that we “are investigating the incident vigorously”, and/or that we “will notify customers whose accounts appear to have been accessed improperly” (how we would actually know which ones, given that our site was compromised, will remain unclear).  In any case, though, what it will boil down to is: you’re f**ked eight ways from Sunday.
• If you have half a brain, you are already doing end-to-end encryption on stuff you care about (for example, as 1Password does when backing up your secret passwords database to Dropbox).
• We will encourage you to check the “remember this credit card for Romanian hackers^H^H^H^H^H^H^H^H^H^H^H^H^H^H future purchases” checkbox, but you probably shouldn’t.

I think this is a great idea and another innovation where California should lead the way, in addition to being a cost saving measure (and potentially an ecologically friendly one). But I was confused when NPR interviewed Sheila Jordan, Alameda County Superintendent of Education, on this topic. Superintendent Jordan spent much of the interview expressing concern about how a lot of students don’t have reliable access to computers and the Internet, and how teachers certainly don’t have the resources to print copies of textbooks in class for such students.

Now, I agree wholeheartedly with Dr. Jordan’s concerns, but when I think of “digital textbooks” I don’t think of people reading off a Web browser at home, or taking home pieces of paper printed off a Web browser at school. I think of downloading content onto an ebook reader—no paper waste, easier to read than a screen, can take it with you, etc. Granted, most students don’t have those either, but they are less expensive than computers (especially if purchased in bulk or otherwise subsidized, e.g. by textbook publishers), don’t require Internet connectivity (the Kindle relies on the 3G data network for downloads, or files can be sideloaded via USB), and are ecologically friendly.

I know that current ebook readers are targeted at people buying books online, but I’ve downloaded plenty of public domain content onto my Kindle–academic papers, public domain and no-license-fee books from various sources (textbooks and otherwise), and more. Devices like the large-screen Kindle DX and the iRex iLiad Book Edition are no-brainers for textbooks, at least where black & white is sufficient, and Amazon’s even announced pilot programs where they are seeding colleges with Kindle DX’s.

So one of us—either myself or Supt. Jordan—may have misunderstood what the Gov meant by “digital textbooks”. I hope my interpretation of his words is correct.

More worrisome is the politics of state-level textbook review in California and the sham process that seems to make the review system fundamentally broken (well, at least we don’t have stickers warning students about evolution on biology books!). This may be why the Gov proposed e-textbooks for math and science first, which are least susceptible to these issues, though I agree with Supt. Jordan that because of the way those books are used (students flip pages back and forth as they study) they might not be the best candidates for early adoption. At any rate, one may hope that the profileration of open source textbooks may change the dynamics of the state textbook review situation—authors of open-source aren’t producing them for profit and so are less likely to feel constrained by such guidelines, and the quality of the free books may be just too good to pass up.

PlayPower’s booth at Maker Faire had a couple of these devices on display. The NES, also called the Famicom in Asia, was a 6502-based cartridge game system whose technology was only half a generation or so ahead of the Atari 2600. The device plugs into a TV (they have both composite video out and RF out, and soldering an undocumented pad on the board switches between NTSC and PAL) and come with a starter cartridge that has various game titles on it, and even seems to have programs that “simulate” word processing and Web browsing (kind of like “my first cell phone” toys simulate making phone calls). Presumably, the carts have ROMs that take over part of the address space when plugged in; the more advanced Atari carts had some additional bank-switching logic (triggered by memory-mapped I/O) that allowed multiplexing lots of different game levels into a fixed amount of address space, typically around 4K.

Intriguingly, Bob Brost at CMU taught a class on NES game development and even produced “nBasic”, a BASIC-level (sort of) language that, although it eliminates the need to program in 6502 assembly, it does not seem to eliminate the need to understand the arcane programming approach required by these devices, i.e. you have to time your code around the vertical retrace interval (only “safe” to write GPU registers during vertical retrace to avoid flickering/loss of picture sync), etc. 

So my questions would be: is this level of programming abstraction going to be sufficient to catalyze the development of a lot of “edu-ware” for these devices? Given that the source of this “edu-ware” is ultimately (we hope) going to be programmers in the very countries in which the devices are sold, should we be looking for something that enables a much higher level of abstraction for development—say, something more like Scratch—and port a subset of it to this 8-bit world?

(Update: the Design For Developing Countries wiki has a lot of great information about their progress and preliminary studies.)

(For the curious, the NES has:

• a 1.9MHz 8-bit 6502
• 32K ROM address space for game code & data (typically 16K code, 16K swappable to store different “levels” data)
• 240w x 248h viewable graphics (NTSC or PAL) organized as 8×8 pixel “tiles” for the purposes of color palette assignment, sprite rendering, etc.
• system, background and foreground color palettes (64, 16 and 16 entries respectively)
• up to 64 sprites (8×8 or 8×16 pixels, 3 colors + transparent color, no more than 8 sprites per scanline)
• 4 synthesizer channels (2 square waves, 1 triangle, 1 white noise) with ~6 octave range; one note per channel at a time

I have to admit, the pervasive availability of $10 TV-computers is awfully compelling, as someone who remembers very vividly what remarkable things can be done within the constraints of these old 6502 systems.