Slashdot Mirror

Jon Katz, Slashdot Columnist:

"There is absolutely nothing in Steve Case's background that suggests he is particularly well-equipped to lead a new kind of unimaginably complex media conglomerate into the 21st century, and Wall Street analysts who are so blinded by the hype surrounding this deal that they fail to consider it carefully are likely to be sorry. Along with some of the other arrogant lynchpins of the digital economy, AOL would rank tops among companies that have routinely exploited and mis-handled their dependent customer bases. Could there be anybody alive in America who hasn't personally experienced or known many people who have personally experienced the interminable cut-offs, waits and disconnections that have, from the first, been a staple of the way American Online has done business? How many times has Steve Case had to go on his own online service to apologize for delays and problems brought about by a company that prized growth well ahead of honesty and service?

"Are consumers really well served when one company controls more content and access than any other company in the world? Is individualism, free expression, diverse opinion advanced when the information economy breaks down into two or three "old and new" media conglomerates that control virtually all of the archived news and entertainment information online, and increasingly, the means to deliver it?"

- Wayne A. Martin, News Manager, Amiga.org:

"Smaller niche websites could be pushed further into the shadows by mega-media companies like AOL/Time Warner that have almost unlimited Internet and television promotion resources they can use to boost their own websites. But on the good side, the merger between AOL and Time Warner seems to go hand-in-hand with AOLs recent deal with Gateway to use Gateway's new Information Appliances based on Amiga technology. This could open the doorway to Information Appliances in the market place a lot quicker than many might have expected. With Gateway, Amino [now Amiga Coporation] and probably others able to produce this type of machine, this could possibly be the fatal blow to MS that many have been waiting for."

Brock Meeks, MSNBC correspondent:

"The bottom line of this proposed deal is nothing more than crass commercialism. What a huge advertising coup this is for Bob Pittman of AOL, he must be drooling at the thought of how to put AOL's nefarious 'pop-up' ads on CNN and print via Time magazine. From a public policy perspective, this venture is D.O.A. as well: no company should be allowed to own the content as well as the conduit. Despite the rosey promises from AOL's Steve Case that 'all comers' will be welcomed to compete on the new venture's cable Internet access system, it remains to be seen just how stalwart Case remains in backing up that promise. Remember, this is the same Steve Case that, under oath during his deposition in the Microsoft antitrust case, swore with a straight face that 'We are not a competitor to Microsoft.'"

David Cassel, Editor, AolWatch Newsletter:

"Here's a reason to fear AOL's control. AOL blocked delivery for the last edition of the AOL Watch newsletter. Did the newsletter's 25,000 AOL subscribers trigger an overzealous spam filter? Or was it that this edition was the first to remind users of the phone number for discontinuing service. (AOL had kicked the ACLU off the service after six years, and there was discussion about cancelling accounts en masse...) Either way, remember: Whoever controls the wires can control the content."

Marty Bass, Morning Edition co-host, WJZ TV (Baltimore):

"I can't imagine that this merger will in any way affect local news gathering or viewing. To duplicate the job we do would require setting up a newsroom. I mean, let's face it; with streaming audio and video you could do a 6 PM News, but this would require a ton of cash, and the local stations already have the major headstart, not only in style but in established viewing. This would be an expensive proposition that would not bear fruit for longer than the 'bean counters' could stand.

"Also lets just say that my station which is a CBS O&O, (CBS already provides news to AOL) put our newscast on-line. Would this change the way our competition does news? No, the primary audience is still watching over breakfast or dinner or in bed at 11. The smaller on-line audience would essentially be getting a big promo for the big shows."

Chris Johnson of airwindows.com:

"What with AOL consuming Time Warner and threatening the stability of the world and all, it seemed to me that it would be good and proper to seek the lighter side of the matter. Here is a short quiz. Identify the proper AOL Spokesmen for the following phrases...

'You've, I say, you've got mail, boy!'

'We are going to buy ICQ because it obstructs our view of Venus!'

'Nnnnyou've got mail, Doc!'

"These are of course restricted to classic WB cartoons. But the fun of it is, AOL now owns most of Western Media! :P - so the field of potential spokesmen is almost infinite!"

Alice Hill, Editor, CNET Online:

"We don't really view either company as a competitor. We did a major deal with AOL in 1999 to provide our content for the computing channels on AOL.com, netcenter.com, compuserve.com and the computing and Internet channels on the subscriber services AOL and CompuServe. Over the past year we have enjoyed the relationship, and the audience. At this point, the notion of adding Time Warner to the mix makes it even better."

Carl Steadman, columnist, The Industry Standard:

"The lesson is clear: send out enough pieces of direct mail and you, too, can own the world."

For links to many more opinions on the AOL/Time-Warner merger, please see this excellent page put together by long-time online writer amd media critic Steve Rhodes.

There's a huge amount of effort being made to stretch computers in this manner. In the Linux field alone, there are lots of window managers and entire competing desktop environments. Looking at the commercial OSes, it turns out that the latest fad (starting with IBM's RealThings such as RealPhone, continued through Apple's Quicktime 4, and now taken up by Microsoft Media Player) is for simulated object interfaces- trading off access to consistent interface behavior for access to interfaces that are closely modelled on real physical objects. This includes the conscious decision to model a volume control (for instance) after a thumbwheel, despite the fact that the control is not used with your thumb and is suboptimal for GUI use compared to controls like sliders and scrollbars. The idea is that people are so accustomed to altering volume on the thumbwheel controls of radios and Walkmen that this overrides the need to optimise controls for the computer screen environment... and for better or worse, the commercial mainstream is diving in this direction.

My personal suspicion is that this may have been a 'Tar Baby'-like strategy on the part of Steve Jobs, who had to know that Microsoft Media Player would follow Quicktime down that road. That's as may be. The more interesting concern for Slashdot readers is this: should this industry trend prove a mistake, how can Linux and alternative operating systems seize an advantage?

It's interesting that the assumptions about user interface always seem to mean the computers will do all the 'stretching' toward the humans. For instance, on the one hand, J. Random Grandmother is the last person you'd expect to be wearing Borg implants, yet the direction of wearables seems always to be GUI displays so the person needn't hack with weird commands, voice recognition so the person needn't _type_, etc etc. and so on. This is an incongruous combination, designing these uber-geeky things for the NON geeks.

What would an alternative approach be like? Well, first of all, a very obvious move would be to keep the heads-up display but redefine it from a GUI screen to an Xterm. This could be cheaper to implement and would be better for the context (a tiny little screen). The OS could be Linux, certainly: but rather than asking whether it would be running KDE or Gnome, one would ask whether it's running bash or csh or tcsh or ksh. The device would store really large amounts of text information, for instance a Mac repair person such as myself might have in the gigs of disk space the entire Apple Tech Info Library and Archive, the body text of utilities such as Extensions Overload, and the total content of several mailing lists. Using such a device, I'd be working on something and would pause to type queries on my arm (presumably as grep searches or something). The HUD would return the entries I searched for, and might also occasionally produce notes I left for myself using cron to echo text to the screen or to kick off little scripts that would evaluate how I wanted things prioritized. Anyone who's dug into the classic Unix approach enough to become fascinated with the possibilities will appreciate what's being suggested here. Significantly, removing the GUI load from such a device and expecting entirely console-based interaction would simplify the design, allowing it to run very fast and efficiently on little embedded processors and not some desktop powermonger.

Naturally, when you talk about using stripped-down Linux implementations on wearables instead of using some sort of Windows, or a Linux desktop, the immediate assumption is that this is all about available computer resources, and that the future is about having enough resources that you can run KDE on a watch, or Windows on your garbage disposal. The only question seems to be if you have enough CPU and RAM. However, this distracts from the really interesting possibility- that the ideal geek wearable situation is not to have the computer stretch all the way towards the user, but to have each assimilate each other to some extent :) This is somewhat unobvious in the current marketing climate of the computer industry, but there's a lot of evidence to suggest that people can and do stretch the other way to 'jack in' to their computers more effectively.

A brief example to illustrate this: I was trying to make lists of syllables from different languages. This is maybe a weird thing to do, but it was what I was trying to do- ultimate goal was to make a naming system for my open source game project, but the important thing was this: I was presented with a problem for which there was no prebuilt solution. I found ways to translate writing of mine into other languages. I found ways (abstract) to break a text into 'trigrams'- So far so good. I ended up with some big text files in different languages, and a list of each one's 'trigrams', but I also needed/wanted to grab the most common first three letters and last three letters from the original words, as I meant to make additional lists of word starts and endings.

Enter grep. Interestingly, the grep I used was built into 'BBEdit Lite', not a Linux application- however, what I was using was not any specific application, but regexps, which I've not had lots of experience with. After giving each word its own line with a nongrep search and replace, and after some experimenting around with having the program just select the resulting patterns, I settled on ([a-z][a-z][a-z]).* replaced with \1, editing the pattern to be .*([a-z][a-z][a-z]) for the end-of-word cases. For the latter, I didn't need to experiment. Why? That gets back to the concept of rules.

The significant rules here are not strictly a list of the regexp commands- they are 'chunked' pieces of learning that can be extended and built upon. (parentheses) isolate bits of the matched pattern and save them for playback. This implies that if I had separate sets of parentheses, I could isolate separate bits of the pattern. [Brackets] match a range of characters, and the dash in the brackets means 'match from a to z'. This matches a character- so it's possible to place several of them in a row, matching a series of a-to-z characters. Lastly, I saw that .* matches everything else in the line, so if I put it outside the parentheses, it would select the whole line but would then replace it with only the parts I marked for 'yanking'. Putting this together, it becomes obvious that I could, for instance, do ([a-z])([a-z])([a-z]).* and replace each line with the argument \3\2\1 which would result in the first three letters of all lines being retained- only reversed!

Which, granted, is not the sort of thing consumers ache and pine for ;) however, discounting this too readily is a serious mistake, because what we're looking at is not a 'replace lines with the first three characters reversed' app- instead, it's a regular expression that is emergent from the rules of regexps. The only bits of regexps which entered into it were the ability to yank bits of text from a matched pattern, and to replace the yanked bits in whatever order I chose- yet, from these simple pieces, a more complicated result was reached. It required some looking up initially to be able to produce the regexp that I used for cropping all the words to three letters- but, interestingly, the idea of reversing the letters took no looking up at all. It was absolutely self-evident, and added itself to the possibilities of what could be done with such a grammar. The thought of 'And what else could you do?' was immediately answered- the underlying rules of how regexps work, including details such as 'the regexp is read from left to right', became instinctive and a novel result came out, a result that was structurally different from any of the experiments, but still obvious.

When you look at Linux as a whole, particularly if you have spent time doing little abbreviated installs on old 486es and seen the sort of programs you end up with, this one area (regexps) becomes just one of countless examples of this nature. The whole classic Unix approach of shell scripting and little programs that can be piped into each other, the sea of weird incantations, is deeply founded in this concept. There is no chance that such things can be made user friendly, because 'user' is not a concept that applies here. Approaching a computer this way is more like melding yourself with it, like the Borg metaphor we started with. Your brain becomes the amazingly powerful top level of the kernel- the whole Unix system becomes elaborate device drivers for your brain, completely dependent on your better human judgement for how to proceed. People sense this without being able to fully articulate it, and that's when you see them starting to claim that virtual teletype interfaces are far more powerful than OOP graphically-inherited widget collections.

Of course, the actual code of the virtual teletype interfaces is indeed more crude and primitive- but this misses the point entirely. A person who is willing to actually merge with the machine, go some way towards letting it focus on the things it's good at, is plainly going to gain an advantage over a person who refuses to meet the machine on its own territory. Imagine my example in the consumer sphere- how long would I have been waiting if I chose to simply bug commercial software developers for a program that read a file and put out only the first three letters of each line? Such a thing would never be done, so my project would have been stopped unless I was willing to do all that manually- but my willingness to deal with the computer on its level with regexps made it possible. Imagine similar situations around personal finances, or keeping lists of things to do, which are more typical consumer activities. The ability of a person to move and adapt and interact with life can be enhanced by not staying limited to predefined options, but at a cost: you never lose the requirement to put some effort into the process, to keep learning. There isn't a point at which you get to sit back with your elaborate information systems and passively consume, because the pressure of novelty doesn't stop.

When you add unrestricted access to programming tools such as C compilers, the possibilities for adding to your computer 'vocabulary' become just about limitless- still with that assumption that you're going to geek out, run your computer in a very active and involved manner. The benefit you get from this directly correlates to your ability to identify things for the computer to do. Some are incomprehensible to ordinary people, but in other cases you're evaluating information, making decisions, producing results with a speed and deftness that the commercial software users (by which I mean those who take a 'consumer' approach to computers) can't even begin to touch. It might be data analysis, or it might be something as simple as converting DEM height-elevation files to a normal picture format by opening them as raw data in Photoshop. It's about the approach to problems, and it tends to awe and disconcert people, who tend not to understand why they can't do likewise if only they had 'Product X', and don't see why you bother with the 'hard way' of doing things. It's like the difference between chopping down a tree with an axe, and chopping down a tree with an electric toothbrush :)

Of course, most people would find more use for an electric toothbrush. Indeed, an electric toothbrush is easier to use than an axe no matter who you are- it's less tiring, more convenient, and extremely approachable without training or lessons in how to use it properly- but its purpose is very tightly defined. In a way, that is the inevitable consequence of making it that approachable. By comparison, when you look at the classic Unix approach, you're basically looking at an axe: a super-sharp but basically crude tool for use on problems. Many uses of the tool take practice and effort to learn. You could cut down trees with a chainsaw, but an axe can do that and split wood and be used as a hammer or anvil or doorstop or bookmark or dirty-pan-scraper: many of the individual uses are awkward, but it's the ability to adapt the tool that deserves attention. Linux may end up repeatedly adapted to work in a purely passive, consumer mode, and it may be very effective in doing so, but this is likely to be a sideshow to the real potential of Linux, as a computer system more suitable to 'Borging' with than anything else out there.

The people who learn to solve problems in this way might end up the most powerful players in an information economy, the ones people turn to for advice and help and guidance. Power like that is never free- but the outsider rarely understands where it comes from. In the case of classic Unix approaches, it isn't the crude Teletype-like interfaces and programs- it's the state of mind, the need for new solutions and the willingness to do much of the work right alongside the computer that fosters those crude interfaces and odd little programs. The people who seek complete technical solutions will get them, but such a pursuit is a defining trait itself, slowing and limiting further growth and progress. New situations will arise, and the people who embrace the chaos and DIY-ness in computing will be quicker to identify the situations and adapt to them. In an era where the headlong rush of progress is thought to be almost intolerable anyhow, an advantage in this area could be vitally important.

There's one more use for an axe: you can carve furniture out of it. You have to have a good axe, and even then it's more difficult than using knives and planes and hammers, but it's still possible to do. And there's a name for doing this, of course. It's called 'hacking'.

- by Chris Johnson

There's a huge amount of effort being made to stretch computers in this manner. In the Linux field alone, there are lots of window managers and entire competing desktop environments. Looking at the commercial OSes, it turns out that the latest fad (starting with IBM's RealThings such as RealPhone, continued through Apple's Quicktime 4, and now taken up by Microsoft Media Player) is for simulated object interfaces- trading off access to consistent interface behavior for access to interfaces that are closely modelled on real physical objects. This includes the conscious decision to model a volume control (for instance) after a thumbwheel, despite the fact that the control is not used with your thumb and is suboptimal for GUI use compared to controls like sliders and scrollbars. The idea is that people are so accustomed to altering volume on the thumbwheel controls of radios and Walkmen that this overrides the need to optimise controls for the computer screen environment... and for better or worse, the commercial mainstream is diving in this direction.

My personal suspicion is that this may have been a 'Tar Baby'-like strategy on the part of Steve Jobs, who had to know that Microsoft Media Player would follow Quicktime down that road. That's as may be. The more interesting concern for Slashdot readers is this: should this industry trend prove a mistake, how can Linux and alternative operating systems seize an advantage?

It's interesting that the assumptions about user interface always seem to mean the computers will do all the 'stretching' toward the humans. For instance, on the one hand, J. Random Grandmother is the last person you'd expect to be wearing Borg implants, yet the direction of wearables seems always to be GUI displays so the person needn't hack with weird commands, voice recognition so the person needn't _type_, etc etc. and so on. This is an incongruous combination, designing these uber-geeky things for the NON geeks.

What would an alternative approach be like? Well, first of all, a very obvious move would be to keep the heads-up display but redefine it from a GUI screen to an Xterm. This could be cheaper to implement and would be better for the context (a tiny little screen). The OS could be Linux, certainly: but rather than asking whether it would be running KDE or Gnome, one would ask whether it's running bash or csh or tcsh or ksh. The device would store really large amounts of text information, for instance a Mac repair person such as myself might have in the gigs of disk space the entire Apple Tech Info Library and Archive, the body text of utilities such as Extensions Overload, and the total content of several mailing lists. Using such a device, I'd be working on something and would pause to type queries on my arm (presumably as grep searches or something). The HUD would return the entries I searched for, and might also occasionally produce notes I left for myself using cron to echo text to the screen or to kick off little scripts that would evaluate how I wanted things prioritized. Anyone who's dug into the classic Unix approach enough to become fascinated with the possibilities will appreciate what's being suggested here. Significantly, removing the GUI load from such a device and expecting entirely console-based interaction would simplify the design, allowing it to run very fast and efficiently on little embedded processors and not some desktop powermonger.

Naturally, when you talk about using stripped-down Linux implementations on wearables instead of using some sort of Windows, or a Linux desktop, the immediate assumption is that this is all about available computer resources, and that the future is about having enough resources that you can run KDE on a watch, or Windows on your garbage disposal. The only question seems to be if you have enough CPU and RAM. However, this distracts from the really interesting possibility- that the ideal geek wearable situation is not to have the computer stretch all the way towards the user, but to have each assimilate each other to some extent :) This is somewhat unobvious in the current marketing climate of the computer industry, but there's a lot of evidence to suggest that people can and do stretch the other way to 'jack in' to their computers more effectively.

A brief example to illustrate this: I was trying to make lists of syllables from different languages. This is maybe a weird thing to do, but it was what I was trying to do- ultimate goal was to make a naming system for my open source game project, but the important thing was this: I was presented with a problem for which there was no prebuilt solution. I found ways to translate writing of mine into other languages. I found ways (abstract) to break a text into 'trigrams'- So far so good. I ended up with some big text files in different languages, and a list of each one's 'trigrams', but I also needed/wanted to grab the most common first three letters and last three letters from the original words, as I meant to make additional lists of word starts and endings.

Enter grep. Interestingly, the grep I used was built into 'BBEdit Lite', not a Linux application- however, what I was using was not any specific application, but regexps, which I've not had lots of experience with. After giving each word its own line with a nongrep search and replace, and after some experimenting around with having the program just select the resulting patterns, I settled on ([a-z][a-z][a-z]).* replaced with \1, editing the pattern to be .*([a-z][a-z][a-z]) for the end-of-word cases. For the latter, I didn't need to experiment. Why? That gets back to the concept of rules.

The significant rules here are not strictly a list of the regexp commands- they are 'chunked' pieces of learning that can be extended and built upon. (parentheses) isolate bits of the matched pattern and save them for playback. This implies that if I had separate sets of parentheses, I could isolate separate bits of the pattern. [Brackets] match a range of characters, and the dash in the brackets means 'match from a to z'. This matches a character- so it's possible to place several of them in a row, matching a series of a-to-z characters. Lastly, I saw that .* matches everything else in the line, so if I put it outside the parentheses, it would select the whole line but would then replace it with only the parts I marked for 'yanking'. Putting this together, it becomes obvious that I could, for instance, do ([a-z])([a-z])([a-z]).* and replace each line with the argument \3\2\1 which would result in the first three letters of all lines being retained- only reversed!

Which, granted, is not the sort of thing consumers ache and pine for ;) however, discounting this too readily is a serious mistake, because what we're looking at is not a 'replace lines with the first three characters reversed' app- instead, it's a regular expression that is emergent from the rules of regexps. The only bits of regexps which entered into it were the ability to yank bits of text from a matched pattern, and to replace the yanked bits in whatever order I chose- yet, from these simple pieces, a more complicated result was reached. It required some looking up initially to be able to produce the regexp that I used for cropping all the words to three letters- but, interestingly, the idea of reversing the letters took no looking up at all. It was absolutely self-evident, and added itself to the possibilities of what could be done with such a grammar. The thought of 'And what else could you do?' was immediately answered- the underlying rules of how regexps work, including details such as 'the regexp is read from left to right', became instinctive and a novel result came out, a result that was structurally different from any of the experiments, but still obvious.

When you look at Linux as a whole, particularly if you have spent time doing little abbreviated installs on old 486es and seen the sort of programs you end up with, this one area (regexps) becomes just one of countless examples of this nature. The whole classic Unix approach of shell scripting and little programs that can be piped into each other, the sea of weird incantations, is deeply founded in this concept. There is no chance that such things can be made user friendly, because 'user' is not a concept that applies here. Approaching a computer this way is more like melding yourself with it, like the Borg metaphor we started with. Your brain becomes the amazingly powerful top level of the kernel- the whole Unix system becomes elaborate device drivers for your brain, completely dependent on your better human judgement for how to proceed. People sense this without being able to fully articulate it, and that's when you see them starting to claim that virtual teletype interfaces are far more powerful than OOP graphically-inherited widget collections.

Of course, the actual code of the virtual teletype interfaces is indeed more crude and primitive- but this misses the point entirely. A person who is willing to actually merge with the machine, go some way towards letting it focus on the things it's good at, is plainly going to gain an advantage over a person who refuses to meet the machine on its own territory. Imagine my example in the consumer sphere- how long would I have been waiting if I chose to simply bug commercial software developers for a program that read a file and put out only the first three letters of each line? Such a thing would never be done, so my project would have been stopped unless I was willing to do all that manually- but my willingness to deal with the computer on its level with regexps made it possible. Imagine similar situations around personal finances, or keeping lists of things to do, which are more typical consumer activities. The ability of a person to move and adapt and interact with life can be enhanced by not staying limited to predefined options, but at a cost: you never lose the requirement to put some effort into the process, to keep learning. There isn't a point at which you get to sit back with your elaborate information systems and passively consume, because the pressure of novelty doesn't stop.

When you add unrestricted access to programming tools such as C compilers, the possibilities for adding to your computer 'vocabulary' become just about limitless- still with that assumption that you're going to geek out, run your computer in a very active and involved manner. The benefit you get from this directly correlates to your ability to identify things for the computer to do. Some are incomprehensible to ordinary people, but in other cases you're evaluating information, making decisions, producing results with a speed and deftness that the commercial software users (by which I mean those who take a 'consumer' approach to computers) can't even begin to touch. It might be data analysis, or it might be something as simple as converting DEM height-elevation files to a normal picture format by opening them as raw data in Photoshop. It's about the approach to problems, and it tends to awe and disconcert people, who tend not to understand why they can't do likewise if only they had 'Product X', and don't see why you bother with the 'hard way' of doing things. It's like the difference between chopping down a tree with an axe, and chopping down a tree with an electric toothbrush :)

Of course, most people would find more use for an electric toothbrush. Indeed, an electric toothbrush is easier to use than an axe no matter who you are- it's less tiring, more convenient, and extremely approachable without training or lessons in how to use it properly- but its purpose is very tightly defined. In a way, that is the inevitable consequence of making it that approachable. By comparison, when you look at the classic Unix approach, you're basically looking at an axe: a super-sharp but basically crude tool for use on problems. Many uses of the tool take practice and effort to learn. You could cut down trees with a chainsaw, but an axe can do that and split wood and be used as a hammer or anvil or doorstop or bookmark or dirty-pan-scraper: many of the individual uses are awkward, but it's the ability to adapt the tool that deserves attention. Linux may end up repeatedly adapted to work in a purely passive, consumer mode, and it may be very effective in doing so, but this is likely to be a sideshow to the real potential of Linux, as a computer system more suitable to 'Borging' with than anything else out there.

The people who learn to solve problems in this way might end up the most powerful players in an information economy, the ones people turn to for advice and help and guidance. Power like that is never free- but the outsider rarely understands where it comes from. In the case of classic Unix approaches, it isn't the crude Teletype-like interfaces and programs- it's the state of mind, the need for new solutions and the willingness to do much of the work right alongside the computer that fosters those crude interfaces and odd little programs. The people who seek complete technical solutions will get them, but such a pursuit is a defining trait itself, slowing and limiting further growth and progress. New situations will arise, and the people who embrace the chaos and DIY-ness in computing will be quicker to identify the situations and adapt to them. In an era where the headlong rush of progress is thought to be almost intolerable anyhow, an advantage in this area could be vitally important.

There's one more use for an axe: you can carve furniture out of it. You have to have a good axe, and even then it's more difficult than using knives and planes and hammers, but it's still possible to do. And there's a name for doing this, of course. It's called 'hacking'.

- by Chris Johnson

There's a huge amount of effort being made to stretch computers in this manner. In the Linux field alone, there are lots of window managers and entire competing desktop environments. Looking at the commercial OSes, it turns out that the latest fad (starting with IBM's RealThings such as RealPhone, continued through Apple's Quicktime 4, and now taken up by Microsoft Media Player) is for simulated object interfaces- trading off access to consistent interface behavior for access to interfaces that are closely modelled on real physical objects. This includes the conscious decision to model a volume control (for instance) after a thumbwheel, despite the fact that the control is not used with your thumb and is suboptimal for GUI use compared to controls like sliders and scrollbars. The idea is that people are so accustomed to altering volume on the thumbwheel controls of radios and Walkmen that this overrides the need to optimise controls for the computer screen environment... and for better or worse, the commercial mainstream is diving in this direction.

My personal suspicion is that this may have been a 'Tar Baby'-like strategy on the part of Steve Jobs, who had to know that Microsoft Media Player would follow Quicktime down that road. That's as may be. The more interesting concern for Slashdot readers is this: should this industry trend prove a mistake, how can Linux and alternative operating systems seize an advantage?

It's interesting that the assumptions about user interface always seem to mean the computers will do all the 'stretching' toward the humans. For instance, on the one hand, J. Random Grandmother is the last person you'd expect to be wearing Borg implants, yet the direction of wearables seems always to be GUI displays so the person needn't hack with weird commands, voice recognition so the person needn't _type_, etc etc. and so on. This is an incongruous combination, designing these uber-geeky things for the NON geeks.

What would an alternative approach be like? Well, first of all, a very obvious move would be to keep the heads-up display but redefine it from a GUI screen to an Xterm. This could be cheaper to implement and would be better for the context (a tiny little screen). The OS could be Linux, certainly: but rather than asking whether it would be running KDE or Gnome, one would ask whether it's running bash or csh or tcsh or ksh. The device would store really large amounts of text information, for instance a Mac repair person such as myself might have in the gigs of disk space the entire Apple Tech Info Library and Archive, the body text of utilities such as Extensions Overload, and the total content of several mailing lists. Using such a device, I'd be working on something and would pause to type queries on my arm (presumably as grep searches or something). The HUD would return the entries I searched for, and might also occasionally produce notes I left for myself using cron to echo text to the screen or to kick off little scripts that would evaluate how I wanted things prioritized. Anyone who's dug into the classic Unix approach enough to become fascinated with the possibilities will appreciate what's being suggested here. Significantly, removing the GUI load from such a device and expecting entirely console-based interaction would simplify the design, allowing it to run very fast and efficiently on little embedded processors and not some desktop powermonger.

Naturally, when you talk about using stripped-down Linux implementations on wearables instead of using some sort of Windows, or a Linux desktop, the immediate assumption is that this is all about available computer resources, and that the future is about having enough resources that you can run KDE on a watch, or Windows on your garbage disposal. The only question seems to be if you have enough CPU and RAM. However, this distracts from the really interesting possibility- that the ideal geek wearable situation is not to have the computer stretch all the way towards the user, but to have each assimilate each other to some extent :) This is somewhat unobvious in the current marketing climate of the computer industry, but there's a lot of evidence to suggest that people can and do stretch the other way to 'jack in' to their computers more effectively.

A brief example to illustrate this: I was trying to make lists of syllables from different languages. This is maybe a weird thing to do, but it was what I was trying to do- ultimate goal was to make a naming system for my open source game project, but the important thing was this: I was presented with a problem for which there was no prebuilt solution. I found ways to translate writing of mine into other languages. I found ways (abstract) to break a text into 'trigrams'- So far so good. I ended up with some big text files in different languages, and a list of each one's 'trigrams', but I also needed/wanted to grab the most common first three letters and last three letters from the original words, as I meant to make additional lists of word starts and endings.

Enter grep. Interestingly, the grep I used was built into 'BBEdit Lite', not a Linux application- however, what I was using was not any specific application, but regexps, which I've not had lots of experience with. After giving each word its own line with a nongrep search and replace, and after some experimenting around with having the program just select the resulting patterns, I settled on ([a-z][a-z][a-z]).* replaced with \1, editing the pattern to be .*([a-z][a-z][a-z]) for the end-of-word cases. For the latter, I didn't need to experiment. Why? That gets back to the concept of rules.

The significant rules here are not strictly a list of the regexp commands- they are 'chunked' pieces of learning that can be extended and built upon. (parentheses) isolate bits of the matched pattern and save them for playback. This implies that if I had separate sets of parentheses, I could isolate separate bits of the pattern. [Brackets] match a range of characters, and the dash in the brackets means 'match from a to z'. This matches a character- so it's possible to place several of them in a row, matching a series of a-to-z characters. Lastly, I saw that .* matches everything else in the line, so if I put it outside the parentheses, it would select the whole line but would then replace it with only the parts I marked for 'yanking'. Putting this together, it becomes obvious that I could, for instance, do ([a-z])([a-z])([a-z]).* and replace each line with the argument \3\2\1 which would result in the first three letters of all lines being retained- only reversed!

Which, granted, is not the sort of thing consumers ache and pine for ;) however, discounting this too readily is a serious mistake, because what we're looking at is not a 'replace lines with the first three characters reversed' app- instead, it's a regular expression that is emergent from the rules of regexps. The only bits of regexps which entered into it were the ability to yank bits of text from a matched pattern, and to replace the yanked bits in whatever order I chose- yet, from these simple pieces, a more complicated result was reached. It required some looking up initially to be able to produce the regexp that I used for cropping all the words to three letters- but, interestingly, the idea of reversing the letters took no looking up at all. It was absolutely self-evident, and added itself to the possibilities of what could be done with such a grammar. The thought of 'And what else could you do?' was immediately answered- the underlying rules of how regexps work, including details such as 'the regexp is read from left to right', became instinctive and a novel result came out, a result that was structurally different from any of the experiments, but still obvious.

When you look at Linux as a whole, particularly if you have spent time doing little abbreviated installs on old 486es and seen the sort of programs you end up with, this one area (regexps) becomes just one of countless examples of this nature. The whole classic Unix approach of shell scripting and little programs that can be piped into each other, the sea of weird incantations, is deeply founded in this concept. There is no chance that such things can be made user friendly, because 'user' is not a concept that applies here. Approaching a computer this way is more like melding yourself with it, like the Borg metaphor we started with. Your brain becomes the amazingly powerful top level of the kernel- the whole Unix system becomes elaborate device drivers for your brain, completely dependent on your better human judgement for how to proceed. People sense this without being able to fully articulate it, and that's when you see them starting to claim that virtual teletype interfaces are far more powerful than OOP graphically-inherited widget collections.

Of course, the actual code of the virtual teletype interfaces is indeed more crude and primitive- but this misses the point entirely. A person who is willing to actually merge with the machine, go some way towards letting it focus on the things it's good at, is plainly going to gain an advantage over a person who refuses to meet the machine on its own territory. Imagine my example in the consumer sphere- how long would I have been waiting if I chose to simply bug commercial software developers for a program that read a file and put out only the first three letters of each line? Such a thing would never be done, so my project would have been stopped unless I was willing to do all that manually- but my willingness to deal with the computer on its level with regexps made it possible. Imagine similar situations around personal finances, or keeping lists of things to do, which are more typical consumer activities. The ability of a person to move and adapt and interact with life can be enhanced by not staying limited to predefined options, but at a cost: you never lose the requirement to put some effort into the process, to keep learning. There isn't a point at which you get to sit back with your elaborate information systems and passively consume, because the pressure of novelty doesn't stop.

When you add unrestricted access to programming tools such as C compilers, the possibilities for adding to your computer 'vocabulary' become just about limitless- still with that assumption that you're going to geek out, run your computer in a very active and involved manner. The benefit you get from this directly correlates to your ability to identify things for the computer to do. Some are incomprehensible to ordinary people, but in other cases you're evaluating information, making decisions, producing results with a speed and deftness that the commercial software users (by which I mean those who take a 'consumer' approach to computers) can't even begin to touch. It might be data analysis, or it might be something as simple as converting DEM height-elevation files to a normal picture format by opening them as raw data in Photoshop. It's about the approach to problems, and it tends to awe and disconcert people, who tend not to understand why they can't do likewise if only they had 'Product X', and don't see why you bother with the 'hard way' of doing things. It's like the difference between chopping down a tree with an axe, and chopping down a tree with an electric toothbrush :)

Of course, most people would find more use for an electric toothbrush. Indeed, an electric toothbrush is easier to use than an axe no matter who you are- it's less tiring, more convenient, and extremely approachable without training or lessons in how to use it properly- but its purpose is very tightly defined. In a way, that is the inevitable consequence of making it that approachable. By comparison, when you look at the classic Unix approach, you're basically looking at an axe: a super-sharp but basically crude tool for use on problems. Many uses of the tool take practice and effort to learn. You could cut down trees with a chainsaw, but an axe can do that and split wood and be used as a hammer or anvil or doorstop or bookmark or dirty-pan-scraper: many of the individual uses are awkward, but it's the ability to adapt the tool that deserves attention. Linux may end up repeatedly adapted to work in a purely passive, consumer mode, and it may be very effective in doing so, but this is likely to be a sideshow to the real potential of Linux, as a computer system more suitable to 'Borging' with than anything else out there.

The people who learn to solve problems in this way might end up the most powerful players in an information economy, the ones people turn to for advice and help and guidance. Power like that is never free- but the outsider rarely understands where it comes from. In the case of classic Unix approaches, it isn't the crude Teletype-like interfaces and programs- it's the state of mind, the need for new solutions and the willingness to do much of the work right alongside the computer that fosters those crude interfaces and odd little programs. The people who seek complete technical solutions will get them, but such a pursuit is a defining trait itself, slowing and limiting further growth and progress. New situations will arise, and the people who embrace the chaos and DIY-ness in computing will be quicker to identify the situations and adapt to them. In an era where the headlong rush of progress is thought to be almost intolerable anyhow, an advantage in this area could be vitally important.

There's one more use for an axe: you can carve furniture out of it. You have to have a good axe, and even then it's more difficult than using knives and planes and hammers, but it's still possible to do. And there's a name for doing this, of course. It's called 'hacking'.

- by Chris Johnson