Chasing down a PowerBook lockup

This seems to describe it: Even like the May 21 comment, it only happens for me when iTunes is running. It'll play music for 4-8 seconds, then pause for 10-20 seconds. If I wait long enough, usually until the end of a song, the system comes back to life.

This is a TiBook 800, running 10.3.4, with nothing plugged into any port but power, and running no non-apple kernel extensions (as reported by kextstat | grep -v apple).

More detail here: where the problem is discussed in some detail. At least I'm not the only one.

My ominous theory: a failing hard drive is timing out IO requests, which is jamming up the event queue. How can I test this theory? -m

A long weekend

Extended-weekend vacation starting here, but not until the DENG chat, on, #codeazur, 9a Pacific time, Noon eastern. Special guest Steven Pemberton. -m

Gabriel framwork

I need to look into this more for my security research. "It's like EJB security without the EJB". Not in Python, but other Java projects have been ported successfully to Py-land. Link: -m

The great GMail invite crash of '04

Well, three days ago I posted an open offer here for free GMail invitations. Not a single bite. In the era of, well, Google, nobody has latched on to this offer. In contrast, the last time I did this, I got two immediate requests from people I didn't know, and one more from a friend. This time, zilch, nada. They might as well open the floodgates at this point. -m

More GMail invites

If you need an invite to GMail, I have a limited number of invitations. Send me email, explaining why you need to be on GMail. -m

Eleven things urgently needed from XForms

Some specific comments on the approach and direction of W3C XForms, in no particular order:

Number formatting, like XSLT's format-number()

A description of interaction with DOM Level 0

Fewer namespaces

An email datatype

Rich text entry

Ability to define calculations in script

Ability to easily control Model Item Properties from script

Ability to use GET urls like ...

An even smaller conformance level

To be locked in a room with browser vendors, nobody let out until agreement is reached

Added: better support for suspend/resume (this means capturing all UI state information somewhere)


Eleven things WHAT should do

The Web HyperText Applications Technology group is a loose association of minority browser vendors. Here's some useful things they could do, in no particular order:

Document and uniformly implement the 'autocomplete' attribute as a markup module

Document and uniformly implement contentEditable

Document and uniformly implement XMLHTTP

Uniformly implement SVG and provide authoring guidance on graceful fallback

Document and uniformly implement innerHTML

Agree on how to program the context menu

Provide needed feedback for related W3C specifications

Document and uniformly implement HTML modal/modeless dialogs

Eliminate minor differences in how absolute positioning works between browsers

Lobby the W3C to do something about the namespaces problem

Added: develop and implement a common plugin framework, including discovery, so thinks like SVG can be added on-the-fly. This pretty much works today for <object> plugins, which can redirect you to, say, the Flash download site. It needs to work for inline markup as well.


One Time Pad

The combining of local and remote access techniques, like I wrote about a few days ago, has a rich history as far as security is concerned--it's how a one time pad works.

The general idea is that two copies of a bunch of strongly-random bits are generated locally, then one of the copies goes remote. Data encoded thusly is literally unbreakable without access to the pad.

This would be trickly to directly implement in a browser/local server scenario. Generating random bits locally is straightforward enough, though care needs to be taken to ensure sufficient randomness. One tricky part is syncronization, so that local and remote are using the same offset into the same block of random bits. Also, just getting the random bits securely into the browser is difficult, without something like a custom plugin.

Even without using the one time pad technique directly, however, I still think the local/remote split contains avenues worth exploring and pondering the security implications thereof. -m

Another comparison: iTunes

Another way to think about my local data project is to compare it to iTunes.

Playing music is the least interesting thing iTunes does. (I'm pretty sure you can even play music from the command line, not that I have a need to do so) It's true value is allowing you to visualize, organize, manipulate, and expand your collection of music files. The net effect enhances the enjoyment of your music.

Same goes for ITDS (or should I say iTDS??) Slapping text on the screen is the least interesting part. The true value is in making it so easy to visualize, organize, manipulate, or expand your data, that when you stumble across a juicy quote, or a factoid you might need later, or some bit of correspondence you write, or a million other things, you tuck the data away. Soon you've built up a formidable, and terribly useful archive. The net effect enhances the value of your personal data. -m

Locally Permissioned REST

My thoughts and a request for comments on an approach for applying REST principles, combined with security measures, to local data.

Background: So, I keep all my data in an organized tree of UTF-8 textfiles, which works great. To facilitate access, especially to make searching and updating easier, I wrote a minimal web server in Python.

In technical terms, this provides a 1:1 mapping to URL-space from my data, specifically to http URLs dereferenced via GET. One the public web, Cool URIs don't change, but for your private web, it's advantageous to be able to move stuff around freely. In fact, the difficulty doing this with Wiki systems is the reason I'm not just using one of them. Updates are accomplished through a POST verb, which really ought to be PUT, but today's browser forms just aren't there.

There are a few security issues with this as it stands. For one, anybody on my side of the firewall can read all my data. Worse, anyone on my side of the firewall can modify my data. For now, I won't be firing up this server while at web conferences and the like. Still, it's useful to have http access, because often you need your data when you are at a different (but often physically nearby) machine.

The standard answer to these problems is to include name/password logins, usually via HTTP authentication, and to use https to prevent wire sniffing. This works great on the Wider Web, but is a hassle for a local-ish system, especially if you want it to work without root certificate warnings in the browser. So, with authentication+SSL as a fallback position, I am free to experiment with other solutions that take advantage of the local/private nature of this project.

Here's a simple example: a local data item could have a permission setting such that when a http request comes in, it pops up on the local machine only a click-to-confirm dialog. If 'Yes' is hit, the request goes through; if 'No' a standard HTTP error code. In the conference scenario, where a stranger could stumble across the server, they would be effectivly locked out. On the other hand, as long as I have physical (or even VNC) access to the machine, the data would still be accessible to me. (And if someone can compromise your system enough to get physical or VNC access, all your data is 0wn3d anyway.)

Another variation for data updates: when a PUT request (er, POST, grr) comes in, the new data could be written to disk, but tracked in a 'pending' state. Available only to the local machine, have an interface to review/accept/reject pending updates.

In summary, the combination of remote-only and local-only access methods can provide relatively reliable and definately simple security that even your Aunt Tillie can configure and work with, but only for the subset of data that's maintained on your local network. Best of all, it maintains the RESTy feel that makes the Web work. If you have any thoughts on this, or know of any existing work in this area, or if you just want to tell me I'm an idiot, send me email. I'll post any worthwhile comments here.

UPDATES: Sean McGrath, who has an upcoming ITWorld article on this subject, writes here: -m

Tragic decline of a hero

Kudos to Brian Dear for calling it like it is: Ray Bradbury protests the film title Farenheit 9/11 despite 1) titles not having any copyright protection, and 2) himself freely 'stealing' titles.

And kudos for calling the media on the carpet about it.

Link: -m

U of MN writing resources

From Boing Boing: I grabbed several of these to listen to on long flights or whatever--audio courses from the University of Minnesota.

There's Studies in Narrative: Science Fiction and Fantasy, Intermediate Fiction Writing: The Short Story, and even Shakespeare: Rehearsing the Imagination.

And then there's Dying and Death in Contemporary Society, as an interesting conclusion.

Link: -m

From an email I got today

"It is heartening to see a conference room with a dozen people all asking thoughtful questions and solving problems. Sometimes they say, "But the Raman book says..." or "Look at what the Dubinko book has to say about that" and they bring their books to the meetings!" -m

FireFox 0.9 released

If you're one of those types that wait for the initial reports to roll in, here it is: FireFox 0.9 installed smoothly on OS X and Windows, it looks better, and hasn't crashed or hiccuped once. Go get it. Update: the OS X lockup problem with a large number of tabs open is still there. It's certainly no worse than in 0.8, though, so the upgrade is still worth it. -m

Xalan Dependencies

Hmm, Xalan doesn't support format-number() without pulling in the whole of ICU (Internationalization Components for Unicode).

This means that simple formatting strings, like "#.##" don't work unless you pull in the entire Unicode framework. A hackaround is to multiply, round(), divide, but even this sometimes gives you IEEE lint, with results like 12.340000006. That too can be chopped away, with a bit more hackery.

Maybe it's just easier to Do The Right Thing and pull in the I18N libraries. Maybe that's the point. -m

GMail invite

Of the seven readers of this blog, I'll bet all either already have a Google GMail account, or aren't interested in one. If I'm wrong, I'll give out an invite to the first person to ask me nicely by email. :) Update: if you're reading this, you're too late. -m

XForms 1.1 Requirements out

If you've been putting off looking into XForms this is your call to action.

Read this document. It's quite short, a little over 5 pages, including all the W3C boilerplate stuff. Send feedback.

Link: For background on XForms, read up at: -m


Donald Knuth writes more than computer books. He has a volume titled 3:16, which looks at chapter three, verse sixteen of each book of thie Bible, a useful cross-sectioning technique. This kind of randomization analysis can apply to other areas, like music...

Here's a list of the artists in my collection, for each track that's exactly 3:16 long:

Rush, B B King, Bacon Fat, 10,000 Maniacs, The Mamas and The Papas, Eric Clapton, James Harman Band, Jimi Hendrix, Eddie Floyd, Louis Armstrong, Aretha Franklin, Cryin' Shame w/ Mickey Bauer, Little Charlie and the Nightcats, Aretha Franklin (again), and Rafael Puyana.

How much of that is representative, and how much is an artifact? What does that list tell you about me?

If you find this idea interesting, please post your own 3:16 list, and include a link back to where you read about it. -m

Signed Forms

A news posting indicates implementation progress on XForms plus digital signatures:

Webapps, Conclusion Documents

Hard to say what will happen next, after the W3C workshop. Anyway, for reference, here's what I said, and my impressions of the event.

My comments at the event, like my blog, are all IMHO.

Do we need evoloution or revolution? Yes. :-)

1) XForms is a good foundation. Rich addressing is a requirement for full webapps, so you need either XPath or something equivalently rich. Re-inventing that particular wheel isn't recommended. XForms ran the guantlet of W3C requirements and recommendation track process, so we should work with it.

2) That said, it isn't perfect. In particular, it doesn't work well with scripting. Anyone else who thinks similar heretical thoughts needs to provide feedback, especially towards the 1.1 requirements document, where you can make an immediate difference.

3) Namespaces suck. As an author, I get many questions about why something doesn't work. At least 4 of 5 are namespace problems, mainly either bad delcarations, using XPath incorrectly, or confusion around namespace boundaries. This is causing more pain now. Short term: hire more tech support staff and consultants, and mentally prepare yourself for more kinds of merging/shadowing in W3C specs. Long term: make your pain felt to those who can change things.

End of my short talk (and rant!)

I sure would have liked to see more representation there from XML Core, the fine folks who aren't helping in the compound document problem. The browser vendors seemed to be going to great lengths to defend IE6's turf; I wasn't the only one to think that seemed a bit backwards. I do see light at the end of the tunnel. One thing's sure though: fragmentation is bad--it will leave the door wide open for single-vendor solutions. Watch this space for some brainstorming and bridge-building. -m

Webapps, Compound documents

I hate doing this, but I have a 7am flight today.

To San Jose, for the W3C Workshop on Web Applications and Compound Documents. Anyone following this blog, especially last month's entry, will have a good idea of what I'll say there. -m

Summer Comes Early

Testing month rollover function.

Eventually, I think something that doesn't require specific action on or about the 1st of the month will be the way to go. At least now I have another month to work on it. :) -m


Terms of use

For external use only. I doubt the enforcability of click-through licenses anyway. Copyright 2004 Micah Dubinko. All rights reserved.


Older stuff here