MOS/DCA/M4U/VSA

My word, I haven't used this for much. It's a pity, as I'd like to.

There is beyond the slightest shadow of a doubt an enormous potential for revolution in OS design in this world. I won't tell you I have "The Next Thing", as a promise like that can only be made after it has already been accomplished. But I have Pretty Cool Ideas and I know they could do something pretty snazzy as far as OS design goes. I could MAKE them work, and I WOULD, if I had the right people on my side.

The basic principle behind pretty much all of it is that equivalent things are not treated equivalently in different aspects of computing. Two pieces of computing hardware (CPU, GPU, USB, HDD, CD/DVD, etc) in a given coputer don't communicate as equals; two computers with different operating systems don't communicate as equals; a computer does not treat all inputs and outputs in a generic fashion, but as a master plus extras; different applications editing the same data do not share the same session data.

To someone who does not know what I plan, every one of those things is not only true but natural. Indeed I expect that there's no particularly obvious way to do any particular one of those things, and little enough reason why they would all be done under the same banner. However, if we allow ourselves the luxury of daydreaming of what has not yet been built, we see a computer that:

* Has multiple components that are each discrete, all of which have standardized high-speed connectors, are hot-pluggable, and have no exposed internals (either in terms of hardware or in terms of software drivers), while being easy to replace and upgrade.

* Can support an indeterminate number of processors, inputs, outputs, users, etc, configurably and dynamically

* Can store application sessions in a way that they can not only be restored by the same application, but by any application with equivalent functionality, assuming that both parties conform to a session standard

* Can transfer both application sessions and user (GUI) sessions between devices running the same or compatable operating systems, even if those devices have drastically different hardware capabilities (including I/O) and run different software

* Is capable of using the running user session on a mobile device to log on to foreign hardware and use it for display and computation transparently without leaving user settings or data locally, or necessarily exposing the foreign hardware to user software which may be buggy or insecure.

I would love to head into that future by forging a really well-designed specification; I'm just having trouble keeping on track all by myself. That's not to say that having the specifications will naturally guarantee that a finished product will result, but if we have them, and they're good enough, we should be able to find a place for them.

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 (...)
  

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)