Experimental Software

The thought occurs to me that, when it comes to software licensing issues, there exists an analogue which really should have been explored long ago, but which I do not recall any conversation about. In particular, there is one thing in particular, and that is the idea that software is trusted with all of our data, even data on which lives can depend. And yet somehow, the concept of "Aircraft-grade" doesn't apply to software in these cases at all.

For people who aren't aware, the building of aircraft is a fairly well regulated industry; I hope I don't have to suggest why. Not only are all the parts supposed to be aircraft-grade, but there is a large body of tests that software must go through before it is declared worthy of FAA certification. If the aircraft is NOT certified safe by the FAA, then you know before you get it in it that what you have is unregulated and it may be no safer than the worst mechanic or part in it. Certified aircraft, such as airliners, are tested for reliability, and as long as they are kept up in accordance with FAA rules, you can be fairly sure that they are worthy of your trust. (They do have a pretty good record with this, too, in spite of the occasional story of airliners crashing--which is made louder and more noteworthy in fact because it happens so rarely.)

I cannot think of a single good reason why software that covers critical sections of computing should not be required by law to be tested by an independent agency for its stability. This would ideally replace the EULA's indemnifying clauses entirely, as the company would in fact be required to account for the faults in its software. In contrast, if a piece of software does not have the testing, because it is an amateur effort or work in progress, it should be clearly marked EXPERIMENTAL--with the understanding that if you use it, you are not allowed to blame the maker.

Ideally, there would be other classifications as well, some with stability testing, some without. Anything where user data is being used MUST have some kind of classification, whether certified or experimental; the user themselves will come to believe in the difference between certified and experimental software, making certification desirable for companies, while at the same time, the fact of testing and the requirement for legal responsibility will dissuade con artists from abusing it.

Would Microsoft or Apple approve of such a scheme? Maybe, but not easily. Microsoft in particular is probably not set up in such a way that any part of its OS, much less the whole thing in total, can be completely certified. However, if a top-notch OS was "certified" and especially if the other OSes were not, then I'm sure they would be more than happy to hold that over everyone's heads with glee.

What should be certified? A quick list.

• Kernel (sans drivers, but including driver architecture)
• Registry (for Windows)
• User Interface (sans plugins)
  
• File system
• Network stack
• OS initialization daemon (The process which starts applications at boot-time)
• Password/Identity managers
• Network security
• Any server process (ssh, ftp, http, samba, filesharing, remote file storage, remote desktop, etc)
• Commercial file editors
• File compression tools (zip, rar, tar/tgz, 7z, etc)

Possible useful certifications:

• Certified User Application (will not lose user data)
• Experimental User Application (registered but not guaranteed)
• Not Classified: User Application (Not registered; use caution)
  
• Certified OS component (will not crash and lose data or damage hardware)
• Experimental OS Component (registered but not guaranteed)
• Not Classified: OS Component (If you aren't a developer, you just shouldn't)
• Certified Isolated Application (Does not use user data; games and graphics programs)
• Experimental Isolated Application (...)
• NC: Isolated Application (...)
  
• Certified Secure User/Network Application (Data is securely stored or transmitted)
• Experimental User/Network Application (...)
• NC: User/Network (...)
  

The mythical wrist-computer

What ever happened to the forearm-mounted computer?

Now, I'm not as big a sci-fi buff as many, so I can't say that it's a staple, but the idea of a computer scarcely more cumbersome than an armored bracer isn't something that yet needs introduction to the genre. There are many sizes and flavors with many kinds of I/O, but the tech behind it, for it to be practical, has always been kind of brushed over.

I'm holding my iPod touch in my hand. Including processor, battery, and hard disk, it's hardly half an inch thick. Assuming that half of that was the touchscreen display would be generous--so, if you had two matching clamshells (probably slightly curved), one or both a touchscreen, and with the rest of the hardware on the other half of the arm, it would be barely if at all thicker than one iTouch. Scale up the dimensions of the screen just a smidge and you have something almost large enough for an actual keyboard, plus a second screen for data--or, like the iTouch and iPhone, turn it on its head, or any-which-way, in order to get the computing experience you desire. (You'd have to make the processor and battery marginally better to accomodate its needs, but the iTouch runs off a 500MHz processor--it's not like we don't have the means to make better)

I'm sure the position would be awkward--having a weight on a round-ish surface like your forearm is something that would cause torque to be a big issue, as I (as others) notice with our watches every day (although, for a well-fitting watch, it isn't a problem--and I'm sure that a properly-fitted watch band up front, and a support strap in back, might deal with the torque well enough). Also, the forearm display probably isn't ideal for either typing or watching--but you'd get used to it, and even if you didn't, it's mobile computing--there aren't many solutions that get it right throughout ALL of digital history.

Still, the geek in me feels that the body-mounted computer industry has been severely lacking for far too long. And let's face it--if you can mount a display like that on your forearm, you can make it JUST the display--and carry a laptop in a backpack with a flexible cable running down your arm. There aren't many, or any, really, solutions that would let you do computing like that, while standing or walking, especially in a way that doesn't threaten imminent and trivially-executed device theft. I wouldn't walk down many dark alleys with it, but short of being ordered to take it off at knifepoint, it remains personally attached.

The Real Thing

I think I know what bothers me about... a lot of things. People who aren't professional; liars; and in general, the entire culture of people who simply seem to not take the world seriously.

Not surprisingly, the problem is in fact that they don't take the world seriously.

By not taking the world seriously, I mean that they seem to view it as a cheap toy--something for which there is a trick, a funny little thing that makes it do what you want, and that's it. The people aren't real people; the problems aren't real problems. It's just a lot of pretty lights, exciting times to be had, and a bunch of squares that are looking to screw up your daily contact high.

Similarly, when it comes to getting out of miserable times, the same people--and I am one at times--view the world like a puzzle, and a cheap one, where whatever the answer is, there is one, and it's something fairly simple. Play with things, and don't worry about doing things you don't want to--the world is only a toy, after all, and it can't make you do unhappy things. And people who accept that you "have to do unhappy things" still seem to want to relapse into this view that the world isn't really complicated--just cruel.

The world is something to take seriously. It can kick your butt while you're looking for the off switch. It will look at you funny when you twist it left and right looking for the "trick". The world will never be a $5 game at Wal-Mart. It's a real thing, and the only way to face it successfully is to be a real thing in response--alive, looking, learning, not becoming a cheap mockery of mankind by settling into patterns that end up leading nowhere.

Where the idea that we can be fake comes from, I don't know. But wherever it's found, it should be unceremoniously smacked upside the head.

Multiple monitors as display devices

As near as I can tell (without having done any research in particular, which bias I readily admit), current trends in single-computer multiple-video output come in four general trends: Multiple terminals, Extended desktop, Display clones, and Custom solutions (the last being reserved for, for example, usb devices such as the Pertelian display). I think most people who have a second monitor get the same itchy feeling at least once--what else can we do with it? There's no good language to describe, or tool implementing, a properly flexible solution (IHNRTS*).

The idea has been itching in my mind for a while that the same windowing system should be able to run different display managers on different displays (where "the desktop" is an example of a display manager, as is any full-screen application, in particular ones that change the display resolution, such as full-screen games or video, or presentations). This effect can be mimicked with the extended desktop to a limited degree, but the extended desktop is limited for one very important reason: there is exactly one meaningful way of switching input focus from one monitor to the next, which is limited by the metaphor of the extended desktop which is broken when an application other than the desktop takes exclusive control of the input.

It's been technically possible to connect two or more keyboards or mice to the same computer for ages, but there has never been a good reason--unless you want to run a mainframe with multiple sessions running, the clutter is meaningless and adds to frustration and confusion more than anything else. There is little reason not to have only one full-sized keyboard--you will only be doing one thing that needs full access to it at once, unless you're a mythical prodigy typing on four keyboards with your hands and feet and mousing with your knees and elbows, or are doing independent work in more than one context, in which case it is likely that more than one computer is a viable solution.

Imagine, however, that you have a second--or third--monitor which doesn't have the capabilities of a full desktop, and is merely a display to which you send tool windows and other informative applications so that they do not clutter your workspace. When running in an extended desktop situation, it is fine to use your primary mouse between the monitors to click options and rearrange the windows a bit--however, run a full-screen game on your primary monitor and you'll see, among other things, that your primary input is now captured and you have no feasable way to interact with it without the dreaded resolution switch back to the desktop, wasting precious seconds and interrupting whatever internal context the game may have. Surely a second mouse could have a use here, but as it stands the primary display manager captures all input, and the tertiary display manager on your other monitor has no independent ability to strip the primary display of the input focus of even redundant input devices.

Thus we get to the proposed solution: a meta-display manager behind the desktop, which is reponsible for determining which display managers have control over what output devices, and which manages input devices configurably--including switching the primary input devices between contexts, and assigning a secondary input device to the nonprimary display, and changing input and output mappings when a new program gains or loses control of one or more resources.

Unfortunately, it may require new APIs as well. Imagine, for example, that you wanted your instant messaging program to have a tool window on a tertiary display while its main window remains on the desktop. Even assuming that the same window-drawing capabilties are granted to the display manager on the tertiary display, how do you programmatically determine or specify which output device you want the new tool to be displayed on? If the tool-window display manager is not part of the operating system, or otherwise not part of the basic windowing library, then any windowing operations will have to be done through its own set of libraries instead of directly through the windowing system. Although this will create increased overhead, most likely these tool windows will not be graphically taxing or real-time, so it is not likely that a slight performance hit will be problematic.

As it is currently envisioned, the only principle problem that this solves is maintaining user interactivity across multiple contexts when one context takes full control of normal user I/O, although it also offers an API which unifies control of non-primary display devices in a way that is not fundamentally different from the APIs used to manipulate primary displays. Whether more can come of this solution is a question that might best be answered in the process of its implementation.

Irrespective, it is an idea to be taken seriously, and a potential that could be fascinatingly useful.

(* I Have Not Researched This Statement)