Friday, January 24, 2003
[Posted by Kevin:]
I was checking my mail this morning and finally realized the irony of the title bar on my screen. I use MS products for most of my computing needs, despite the fact that I strongly dislike the privacy and monetary policies of Microsoft. I have tried numerous OSs and window managers (even replacing the shell of Win2000 several times), as well as ISPs and mail clients. Right now my needs are best served by the products I use, unfortunately, they happen to be mostly MS based. Despite that, I have a healthy suspicion of MS products and can directly appreciate the irony of the below image.
Thursday, January 16, 2003
When the slashdot article
The D Language Progresses appeared last weekend, I didn't expect
anything useful from the article comments ("This language will change
the world!" "We don't need another language!" "Beowulf Cluster!"), but I
took the opportunity to check out the latest language spec.
I'd seen the language before, and I approve of the general goal: create a
statically-typed, compiled, garbage-collected, module-based language which
is as similar to C++ as possible while excising the nastier bits.
If it were complete and well-supported, that's the kind of language
that I'd seriously consider switching to. However, a look through the spec revealed a language feature that's all
too common, and which makes me cranky.
On the list of C++ "features to
drop", D mentions
Creating object instances on the stack. In D, all class objects are by
RRGH! This is true of too many otherwise promising languages. Several
native value types are supported (int, float,
string, etc), but
user-defined value types are prohibited. Instead, all user-defined types
are "by reference", which means every class instance is heap-allocated individually.
For most of the programs I write (graphics, physics, etc),
int, float, and string aren't the only value
types I'm interested in. What about 3-dimensional points? Matrices?
Colors? These value types all simplify programming enormously,
especially when combined with operator overloading
(which D does support, incidentally). I'm not suggesting that D should support these natively; these
are just the sorts of custom types I expect to be able to
create with the class mechanism.
And it's important for these types to be true value types, and not
"by reference". Why? Because I commonly pack thousands of
instances into arrays for transport and manipulation. If all class
instances are "by reference", then arrays of those instances are
actually arrays of pointers, not arrays of the objects themselves.
The objects themselves get heap-allocated willy-nilly, and memory
coherence goes all to hell.
(It doesn't have to be this way, I suppose. You could prohibit instances on the stack but support
tightly packed instances in arrays on the heap. But
I see no evidence that D does this.)
The D documentation justifies its decision thusly.
This eliminates the need for copy constructors, assignment operators,
complex destructor semantics, and interactions with exception handling
stack unwinding. Memory resources get freed by the garbage collector,
other resources are freed by try-finally blocks.
True enough, though I'd much rather have "complex destructor semantics" for some objects if it means I can pack thousands of them into an array.
'Course, I'm really just saying "D doesn't seem appropriate for math-intensive,
very data-heavy applications." And perhaps that's not profound, or even
interesting. After all, garbage-collection is similarly
ill-suited to manipulating enormous datasets since dead
values don't get deleted right away. But I like garbage collection in general. I guess I want a language where some values can be garbage collected,
with other deleted explicitly. Or where large
structures can be tracked differently by the garbage collector, so they get deleted right away.
So my complaint may be irrelevant to D. But it still makes me cranky, because the only language I've found that's good at data-heavy stuff and general-purpose app work is C++. And C++ is, well... C++.
Wednesday, January 15, 2003
I won't hold it against you if you write to your representative, too. If Tuesday's BSA/RIAA/CSPP agreement is any indication,
corporate backing for the Boucher bill may falter, and
so constituent support is more important than ever.
I join thousands of others in thanking Larry for his effort, and for inspiring so many to care about the issue.
Tuesday, January 14, 2003
Today the RIAA, the Business Software Alliance,
and the Computer Systems Policy Project announced an href="http://www.bsa.org/usa/press/newsreleases//2003-01-14.1418.phtml">agreement
on issues of digital copyright and piracy. The agreement is touted as "significant...cross-industry coordination", and is painted as a landmark compromise between former rivals.
However, this agreement--which, notably, did not involve consumer interest groups at all--is bad news.
Some background: The RIAA has generally supported
measures like the proposed
CBDTPA, federal legislation which would mandate
copy-protection hardware in all digital devices. This bill represents an even larger threat to consumer rights than the already-passed DMCA, and has earned ridicule and loathing among consumer groups and computer geeks alike.
The technology industry has, by and large, spoken out against the CBDTPA, arguing that government-mandated technology would stifle innovation and increase production costs. Some have taken this as a stance against digital rights management in general, though
should shed doubt on that interpretation.
Meanwhile, Rep. Rick Boucher (D-VA) has been pushing legislation
that would reverse some of the damage done by the DMCA by making explicit certain consumer rights, including fair use, in the context of digital content.
This bill has met with acclaim in the internet community, but support from the tech industry has been lukewarm.
Today's "truce" makes it clear why. In the announcement, the RIAA agrees to oppose legislative mandates such as the CBTDPA, and in exchange the tech companies agree to pursue DRM technologies and to oppose fair use legislation such as Boucher's bill.
[H]ow companies satisfy consumer expectations is a business decision that should be driven by the dynamics of the marketplace, and should not be legislated or regulated.
Think about what they're saying. They're saying that fair use, the long-established doctrine that protects consumer interests, should not be enforced by government mandate. Instead, market forces should decide what protection, if any, is granted to the public.
As appealing as that may be to our capitalist sensibilities, it's well established that the Market is no panacea.
As much as we hate regulation, market forces are notoriously dysfunctional in industries dominated by several huge players. When entrenched interests may limit innovation according to their designs, market forces offer no protection for consumers--or for other potential
innovators. Does that sound at all familiar in this context?
What's worse, market forces offer no guarantee of balance when the nature of the market changes suddenly. Today, the consuming masses literally don't know what they want. For all its enthusiasm, the public hasn't yet grasped the
significance of the Internet. The possibility of a collaborative culture of information hasn't occured to most people, and so they don't know that it's something worth asking for. (How many broadband customers have even noticed that their uplink speeds are crippled?)
If we want to find out what that culture would be like, we can't leave it up to "market forces". Not when that culture threatens the livelihood of the biggest players in the market.
UPDATE: Interestingly, the BSA has taken down their article on the agreement, mere hours after posting it. An article expressing reservations about Boucher's bill is still there, though. A separate article on today's agreement can be seen here.
UPDATE 2: The PDF file describing the "policy principles" of the agreement is still available.
Monday, January 13, 2003
There's a growing suspicion that the promise of the Internet is to eliminate the need for distributors and publishers entirely. When anybody can publish to everybody for cheap, and when the googles of the world can play matchmaker, what purpose do the weasels in the middle serve? They only drag us down.
Futher, it's oft speculated that the mental inertia and impotent flailing of the content giants will only speed along their timely demise. I'm generally skeptical of this claim, though. These are the brilliant businessmen who built the most powerful industry on the planet. They're bound to catch the cluetrain eventually, right?
- Consolidate the major labels (from five to three) to reduce overhead; and
- Reduce the total number of artists signed, so they can "focus their bets more".
So the problem, as they see it, is that there's too much creativity out there, really, and it's just
holding them back. *cough*
Thursday, January 9, 2003
He also points out that we should measure the effectiveness (and necessity) of copyright extensions by the number of actual works produced, and not by what copyright holders say they want. (Of course they want more power. What else would they say?)
It's amazing that so much of the copyright debate is centered around what makes copyright holders feel good, and not on what actually seems to promote creation. Not that it's easy to measure that sort of thing, but anything would be better than taking their word for it.
Wednesday, January 8, 2003
Via Copyfight: Yesterday Rep. Rick Boucher (D-VA) reintroduced his fair use rights bill for the new Congress. That he introduced it so soon in the new session suggests that he takes this seriously. Here's hoping that more of Congress follows suit.
[F]reedom is kind of a hobby with me, and I have disposable income that I'll spend to find out how to get people more of it.
Sadly, in the
follow-up article he concludes that a noisy lawsuit might do more harm than good. Oh well.
Tuesday, January 7, 2003
In 1972, 7-year-old Steven Stayner was kidnapped by convicted child molester Kenneth Parnell. After being held captive for 7 years, he escaped, and Parnell went to prison--for only five years. Steven's story was told in the 1989 TV movie I Know my First Name is Steven.
In 1999, three Yosemite tourists were found dead, and then a Yosemite nature guide was found beheaded. Several months later the killer
was caught. It was Cary Stayner, Steven's older brother. He offered a confession in exchange for child pornography, claiming that if he had had access to child pornography, he probably wouldn't have committed the crimes.
(He didn't receive the pornography, but confessed anyway.)
Four weeks ago, Stayner was
sentenced to death, though under California law it will be automatically appealed.
Meanwhile, last friday, Kenneth Parnell (now 72 and living in Berkeley) was arrested for allegedly trying to
buy a child.
UPDATE 2003-01-09: He seems to have confessed. Yikes.
However, I'm happy to report that the site brings up a popup ad for, of all things, popup blocking software. (Sometimes it serves a different ad, but if you reload a couple times you'll probably get it.) That means someone, somewhere, felt that popup ads were intrusive enough to be worthy of elimination, but not intrusive enough to keep them from using them themselves.
It's like distributing ads for brick-proof car windows by wrapping them around bricks and chucking them through car windows.
'Course, this only happened because the version of Netscape at work doesn't block popups. Silly Netscape.
Thursday, January 2, 2003
While playing around with Phoenix, enjoying its toolbar-free gesture-driven fullscreen mode, a thought occured to me. Phoenix, like most apps nowadays, is themable: You can choose from many aesthetically different (but functionally identical) appearances. I've had the distinct feeling for a while that themability like this is not just silly and pointless, but that it's a sign of a deeper problem. I've generally dismissed it, though, as "too many programmers with too much time on their hands".
Still, I'm a sucker for eye candy, and so I tried out
several of Phoenix's (quite attractive) themes. Then I moved on. Later, operating happily in Phoenix's fullscreen/gestural mode, I realized that all of the themable interface elements were now hidden, and so the
themability was completely moot.
The deeper problem, I realized, is this: Programmers spend so much time tweaking the appearance of interface elements, it doesn't occur to them that the control could be anywhere other than onscreen. With so much work put into bevels and drop shadows, why wouldn't you show it off?
Well, for one thing, many people (let's call them offscreeners) prefer keyboard controls, popup menus, and other mechanisms that don't take screen real estate away from the actual content. And while it's possible for an app to work both ways, it's rare for it to work well both ways.
If you want to support efficient offscreen controls, it's not just a matter of adding keyboard shortcuts and popup menus. Nobody benefits from obscure, undocumented key shortcuts--not even diehard offscreeners. Common operations should be easily accessible, gestural when possible, and keyed by context. Less common operations should be less simple, but should be accessible through the same simple mechanisms--hierarchically when necessary. As much as possible, all controls should be amenable to "muscle memory": repeated use of a feature should teach your hands--not your eyes--how to access it.
This last point is critical. For offscreeners, the visual system is engaged with the content, while the hands perform operations on the content. The visual system shouldn't be pulled away from the content to perform common discrete tasks: that's what the hands are for. For less common operations, which the hands may not know well, it's sometimes necessary for the visual system to be sidetracked to search for the control. But the result of that search should be something meaningful to the hands, so that soon (after several uses) the visual system doesn't need to be sidetracked any more.
This is the whole point of radial menus, of course. With a traditional menu, you may quickly memorize how to reach some deep, nested menu item. But navigating such a menu still requires you to aim the mouse at specific menu rows, and so still requires the attention of the visual system. Radial menus, on the other hand, allow quick, simple movement with no aiming required. They're visual-system-friendly, but can be operated entirely by the hands as well.
I'll say it one more time: Efficient offscreen control isn't about memorizing obscure sequences and shortcuts; it's about teaching the hands to work without the help of the visual system. The visual system has more important things to do. (And so, for that matter, does the mouse, which is sort of the liaison of the visual system in the computer. The mouse should not be distracted from its spatial work to perform non-spatial tasks.)
Finally, it's critical for all operations in an application to be accessible in the absence of onscreen controls. Too many applications have keyboard shortcuts (or popup menus) for most, but not all, of the app's features.
This is an offscreener's nightmare. Offscreen control can't be an afterthought, or some important aspects will inevitably be missed.
In short, a powerful offscreen interface takes planning and effort. And the incessant themability of modern apps makes it clear that that effort isn't high on anybody's priority list. Enormous toolbars, sidebars, menubars, status bars, floating toolboxes and tear-away menus are the norm. It doesn't bode well for us offscreeners.
Wednesday, January 1, 2003
Why? Fullscreen mode + auto-hide toolbars + context-sensitive radial menus = one virtual desktop with nothing but web page, navigated via gestures. No toolbars, menus, or borders wasting screen real estate. No multiple browser windows (thanks to tabbed browsing, also hidden and navigable via gestures). No popups (thanks to, er, popup suppression.) Beautiful.
I decided long ago that having more than one window onscreen is overrated, and that toolbars are stupid. The screen should be devoted entirely to content, not application infrastructure, and definitely not to windows half-obscured
by other windows. Sadly, most apps--open source apps in particular--are careless with the number of windows they open. The Gimp, for example, is an interface nightmare. A new dialog excreted every few seconds, usually on top of the content you're working with. Blech. (And I say this as a diehard Gimp enthusiast.)
Phoenix is the first app I've seen in a while that's really compatible with my lifestyle. It makes me happy.