This section is intended to hold features which should be desired or required in an OperatingSystem. We're exploring possibilities here: if one possibility is quite feasible, and would render obsolete several other possibilities, we delete the other possibilities. Please contribute to this wish list, especially if you don't know anything about system design.
General Features
Under normal operation, users should always have access to a control panel from which they can almost immediately abandon any program, process, task or thread, given appropriate privileges. BUT in RealTime and EmbeddedSystems, this facility could be dangerous.
Users should be able to abandon/terminate processes that they started. More specifically, when some process (including a user's shell) starts another process, it should get a capability [ObjectCapabilityModel] to terminate it. This handles the case of embedded systems correctly, since then no general-purpose user shell will be running.
All programs, processes, tasks or threads should have appropriate descriptions - which could be wordy, associated with them. Windows OS type task descriptions - which may be meaningful (e.g. MSWorks.exe) or not (e.g. LSASS.EXE) to the end user should be outlawed. Even a naive user should always be able to identify a task, thread etc. by a meaningful name, linked to a description, and linking back to any program which is running it.
This becomes difficult, in that you can't force a good name any more than you can force a good variable name. Therefore, you should provide access to enough context to figure it out; right back to the shortcut link name used to launch the program which spawned the process (assuming that we have 'shortcuts')
I think you can enforce it by certifying programs to follow the OS GUI standards with sticker (like Intel Inside), and encourage it via marketing and corporate-pressure
Therefore, processes and tasks should be accessible in the same namespace as files and directories. You don't need to "provide" any context if the context is right there for anyone to see.
Even if some programmer uses an inscrutable name for the executable file, and refuses to provide any description, the OS can still provide information on who started the process, when it started, what files it reads, what files this process writes, whether or not it accesses the internet, ... a link to where the executable file came from (did it come with the OS? Did I install it by downloading from some website, and if so, which one?). Having a dozen mentions of "svchost.exe" in the task manager, without any way to distinguish them, doesn't seem particularly useful.
If any program, process, thread, task crashes, the OS should not crash, nor should the user running the object.
In a multi-user system, users should be assigned different capabilities
Users should be able to present authorization to do one-off activities without needing to logout
The operating system should have the standard UserInterface displayed and functional within milliseconds of startup, lazy loading services and drivers in the background as necessary. Within startup of the OS, or startup of the computer? In many computers lots of things happen that take lots of time, before the first line of OS code executes.
Don't most OS's already do this? Windows XP, for example, usually boots up within 60000 milliseconds of startup. :-) You should give a specific number on these things. I'd be happy to have a complete boot (BIOS and OS) within about 1500 milliseconds. If what it takes is storing the exact memory layout and signals it needs to send to get the hardware into working condition, so be it.
It should be able to boot completely from ROM or CMOS, or USB Memory within 5 seconds.
All objects, including processes and users, should be owned and controlled by users in any combination of users and powers they desire. For example, two arbitrary users can create a process for which they are equally responsible, the process providing services to the public. All of this automatically with no need for consulting higher powers.
The identity of objects, including users and processes, should be non-spoofable to the theoretical limits of a web of trust.
All objects everywhere in the system, whether processes, tasks, threads, files, network connections, framebuffers, and users, should be accessible to any user or process using the exact same set of primitive operations. For example, using cp to fork a thread.
I think I would qualify this to "... using the appropriate set of primitive operations." It isn't obvious that there should be a single God-given set of primitives that apply to every object; some objects are just not like others. Or perhaps you can clarify what these primitives should be?
PlanNineFromBellLabs uses a command-oriented language to manipulate primitive objects. Myself, I'm going OO. The appropriate set of primitives manipulates nodes and links (capabilities). You can ask a link to create a link from here to there, to delete itself, to pass a message over there, to pass a message to its node, to manipulate its permissions. You can ask a node to read, insert, or cut its contents. You can ask either for their metadata. Et cetera. As long as everything can be expressed as a combination of nodes and links, any higher-level functions that make no additional assumptions (like cp, ln, ls) will work everywhere.
This is the important part: it is illegal for an OS component, which includes everything the OS runs, to visibly break this model. So when they do, they must do so invisibly or, as a last resort, silently.
All references to objects should be bidirectional so you can always tell who or what is using an object, and remove an object without leaving dangling references.
Write an operating system that can host itself.
What does that mean precisely? If you have a program stack (network stack, storage stack, et cetera) then does this mean you must be able to run the lowest level component on top of the highest level component?
The operating system should be able to run a copy of its kernel, and provide any abstractions necessary to do so... in other words, I'm still trying to figure out exactly what I mean by that :)
Define "kernel".
Some background is called for. The OS is composed of many independent and interdependent stacks of abstractions. One is the network stack; MAC, Ethernet, IP, TCP, (FTP), HTTP. Another is the storage stack; HD, Partition, RAID, Log, (Cleaner), persistent store, crypto. Yet another is the processing stack, with machine language at the bottom and something much higher level at the top.
Let's assume that our OS isn't made by a throwback to the 70s and so has well-differentiated layers. I may be totally wrong but it seems that you can't run the lower-level abstractions on top of the higher-level abstractions without simulating the lower-level machinery. Simulation is not what we're aiming for. So what are we aiming for?
One possibility is something like the ExoKernel crowd is aiming for. An example is rio, PlanNineFromBellLabs's window manager. That is, components which do nothing more than securely multiplex the lower-level abstractions. When you're doing nothing more than multiplexing, then you can always host yourself. Which brings up the question; should our OS do nothing but securely multiplex resources? And if we did limit ourselves to this then what's to prevent libraries which provide higher level abstractions from becoming de facto parts of the OS?
Well, the crucial difference is that underneath a library or other such abstraction, there exists a layer which (ideally) does nothing but securely multiplex. So we can formulate a criterion: every abstraction layer in the OS must have beneath it a layer which does nothing more than securely multiplex. Is this criterion sufficient?
So as long as we're smart enough to distinguish between providing abstractions and securely multiplexing, then everything's gold. (Just don't count on system programmers being that smart, I know of one revolting piece of dreck that fuses three separate abstraction layers together.)
The common-tongue language should specifically not be C. Must be quickly compilable to byte or machine code, and fully extensible: One can rewrite basic control constructs, or write new ones, etc.
The common-tongue language should allow the embedding of arbitrary literals, not just numbers, strings and arrays. If one wanted to embed the entire OS as a literal in one's program text, the language should provide functionality to do just that.
In other words, you want a language where code is data. You want Lisp.
Only if Lisp provides the other desirable features... like proof of correctness. Any language with first-class procedures would work. But, yeah, Lisp would be a fine decision.
Wherever possible, a new function generated with the appropriate data hardcoded should be returned from system functions (see SynthesisOs)
Meaning it's a functional paradigm instead of an OO paradigm. Despite the fact that users understand OO easiest and that hardly any normal person understands functional programming!
Hardly. An OO system can be written on top of a functional language with little difficulty. And a FactoryMethod is nearly equivalent to this, which is an OO pattern. The generated function has the same interface as the generic default function; it just has code optimized for its particular use.
If the operating system is subject to recompilation at runtime (perhaps by being bytecode run by a JIT), and the compiler is sufficiently sophisticated (which we will assume it is!), then this feature comes ForFree as a side-effect of incremental specialization etc. This model of execution brings many performance benefits, including the ability to inline system calls and so on. Of course, you have to pay cycles to run the compiler, so YMMV, but experience teaches us that we can do this when cycles are cheap (the user is pondering what to do next, so the machine is idle) and reap the benefit when they are expensive (the user wants to see a 3D thumbnail gallery of his photo library).
What if there is no static OS, only user modules? What if there are no system calls to specialize or inline, only "pass a message to the link in the user component I'm nested in"? What if every message weaves in and out of a half dozen different modules, yet its path length is already optimized? What if FactoryMethod is just plain illegal due to security reasons? Can you optimize the message passing between a system of objects as complex as, say, a Smalltalk image? The problem with the proposed feature it that it's too specialized; it's only even meaningful within a particular OS architecture. There's plenty of room for adaptive optimization in the system I have in mind but I have difficulty figuring out whether the feature mentioned is even meaningful.
A system-provided "unexec" that is reliable and easy to use. Every running application can be frozen back to a file, which can then be transported to other computers, if need be. (Yes I know this is difficult.)
I challenge this assertion. There are far more conditions required to make this easy. For example, the ability to deal with network failures, time being non-continuous and (potentially) non-monotonic, connectivity changing immediately, data being received by a tcp stack but not passed up to the application, resource quantities (memory, tmp space) arbitrarily reducing, etc... None of these independently are unsolvable, but to call unexec 'easy' is just silly. --AdamBerger
Non sequitur. Unexec requires NONE of the things you listed. And in fact, it doesn't even require versioning. What it requires is an OS designer to design flexible processes that don't need to reside in any particular component of the OS (ie, the memory subsystem). Having to stick to the ExoKernel principle, and inventing NestedProcesses as a result, provides you with unexec for free. -- RichardKulisz
OpenVms is an example of a relatively widespread OS that supports this.
There will always be a cost in freezing a 'process' due, at the very least, to ongoing interactions. Processes are active things. A simplistic approach would be to simply cut all ongoing interactions off and save the state, but any internal state tracking ongoing interactions would be saved, too. What users really want is to be able to stop arbitrary processes, then bring them back up into relatively working order... despite the likelihood of zombified connections. This requires reconnecting with other, remote processes and bringing the interaction back to the state one left it in upon unexec. This is not free.
The system maintains the illusion that directories are just ordinary files with a certain file format. Therefore I can e.g. simply attach a complete directory structure as a file to an e-mail.
Why is the former desirable in view that it isn't necessary for the latter?
If files maintain a listing of directories they belong in, a GoodThing, then this makes files a subclass of directories instead of directories being a subclass of files. So why is the illusion desirable?
There shouldn't be any difference between files and directories, period. For instance, a game should be able to have its saved files and resources attached directly to it, without having to worry about where it has been installed and without denying the user access to them. This should follow from some of the other points here, but in light of the above it may be worth making explicit.
Complete network transparency. Crossing a boundary between computers should be no more difficult or different than crossing a boundary between user domains or between system components.
Every component would be dynamically replaceable in real time. One could upgrade everything, including drivers, memory manager and scheduler, without any system interruption. Even if a reboot wouldn't last more than a minute.
The system should look identical both to a user and a system programmer. Every function in the OS should be available and manipulable using ln, ls and the crudest possible text editor. Assuming you have sufficient privilege. The system should have ProgressiveDisclosure in that all its innards are immediately exposed to anyone who doesn't actively ignore them. (It might be necessary to create a new basic utility to expose monitors.)
Every object in the system is a monitor that can block threads anywhere on just about any condition imaginable. Example 1: a directory can be set to block a certain thread across the network until a file named 'X' is created. Example 2: it will also unblock when some other process blocks on that file. Example 3: it will also unblock when a message (such as a blocking request) traverses any of the 27 directories to which file X belongs to.
Resource allocation has derivatives. So you can not only buy a quantum of CPU time, but you can also buy the opportunity to buy a quantum of CPU time at any time of your choosing in the future, or a contiguous block of 1000 quanta. (So you can implement RealTime constraints ... if you choose.)
Processes and threads "live" anywhere you want. The process doesn't live in volatile memory at all; that's only a shadow copy the scheduler uses to speed up operation. A process can "live" on the hard drive of a machine only accessible through IPX over TCP/IP over pigeon-carrier.
Administration of user accounts is a user function. Since the system is recursive, it's possible for a user to run a background process which logs in other users. The system uses CapabilitySecurityModel to ensure these other users can't muck around the self-appointed sysadmin's private files.
The system doesn't use trees but lattices. It doesn't have hierarchies but logical multiple containment. Any object (file, directory, user) can 'belong to' any number of other objects.
Searching for all objects belonging to directories named X and Y which contain the string "blah blah blah" should be as simple as googling. Invoking this function should be as simple as hitting Ctrl-f, not Start>>Control Panel>>Search!
Every imaginable political system can be implemented. For example, one can implement democracy by requiring a majority vote before the superuser robot accepts a proposed modification to the OS.
Every imaginable economic system can be implemented.
You can inspect and revert any part of the system to any point backwards in time. For example, you can look at how your game of Quake was 5 minutes ago and revert to it. The OS does this by default unless a process puts data into non-pageable volatile memory, assuming it has privilege sufficient to do this. The rate at which the system snapshots itself can be controlled by the user. This is preferably implemented using a LoggingFileSystem.
A crypto layer exists to encrypt/decrypt into lower-level storage. Unlike a cryptoFS, you don't have to use this layer, since it's strictly user-level. Unlike PGP or other schemes, it automatically encrypts all contents of files and also all filenames, leaving the directory structure intact.
You can mix and match processes any way you like. For example, create a process with the text of that one, the data of that other one, and the environment of that third one. This is dynamic so a process can import a shared component at any time it wants. Naturally, this is secure so that if a process doesn't want to share, and no one can override it, then it doesn't have to.
All objects are versioned. An object's past versions is integrated into its identity, you don't need to fetch it from a different module (like in PlanNineFromBellLabs).
All objects have immutable IDs which are used to fetch them. This is necessary because:
Any number of objects in the same location can have identical names. Names are intrinsically meaningless, they're just cues for users. In fact, objects can have no name at all. Just because a user can't think of a name for a document doesn't mean it goes unsaved, or that the software assigns it a dumb name.
"This was actually implemented on Apple's LisaOs?"
The file should have its mime-type, or any document info, stored along with its file content. we would no longer need to register file by extension. Application can have its own file extension. Yet, if it's all of the same type (may be the content is really xml), then any application interesting in opening xml file should get a chance to offer the its function to the user.
(Given the above, especially "every imaginable political/economic system) When the user clicks on the "Give me a pony" button, a pony should be delivered to the user within five minutes.
Note that the Macintosh has done this in its filesystem since 1984, so if you want to explore this idea, there's decades of analysis of this approach available. And of course Unix has never had more than a weak reliance on file extensions (any given tool can insist on a filename of any format it chooses to insist on, but the OS doesn't care about extensions at all - there is no such thing as a "file extension" from the point of view of the kernel; there are just filenames, period). The whole thing about file extensions being a hard and fast encoding of file contents is pretty much unique to the DOS/Windows world (and a part of that world that fans of other OSes have always detested).
May be if I found the reference about MAc file system I would discuss this better. But this wasn't trying to get rid of the file extension. Instead, it is trying to push file extension into first class file property, not just part of file name. And it will not be stored in the same place as file content (you will not see it when open the file with notepad). However the file you created by notepad may have its mimtype property of "text/plain-text" (and maybe sub-mime-type, if one needed). This should be unique like Interface in COM technology, but using uri over some standard should be enough.
Similar to how MacOsClassic used a "resource fork" and a "data fork" for every file. The ResourceFork held all the file attributes, while the DataFork? held, well, data. One neat thing about this was being able to open the data fork separately and look at it, since anything text based was ascii. Made for easier manipulation sometimes.
See FilePermissions? for why storing names and types separately is a really bad idea. And for myself, I've always loved extensions in filenames. The thing I hate is it being limited to 3 letters in DOS, and the type system not being a hierarchy or DAG but instead a retarded table.
The user should be able to register an object as type .movie dynamically and easily. Then they can declare that .movie as a subtype of .image and have any image-handling program of their choice try to process the movie. Going in the other direction, a user should be able to register a handler for type .movie that delegates back to each subtype (codec) to see which one works, but so that an object of type XviD wouldn't need to try any codecs because it would KNOW which one to use.
If you loved file extension, and love to have hierarchy of extension, then that's what I think the type as file property is the need. All right, physically, the information may be stored in the same place as file content (just like magic number in first 10-20 bytes in any binary file today). But when using iostream or any read API to read, the first data byte should be data behind that signature. Yes, when importing file from Windows or Unix, we can have some utility tool to fill in the information or mark it as unknown. The benefit is user see more about information of file type.
Storing File type information then takes another step to storing file flavor. I borrowed the word flavor from java's clipboard flavor term. I mean, File information can stored its type information. And User can then register for 'view' to view one filetype as another filetype. Then if you store file as html, you can use notepad to view file as txt (with no <> markup shown). The application can choose to see every file as its compatible high level data instead of binary stream. This concept is like OLE document to me. but I think there should be a better way.
I agree that metadata may be stored anywhere physically and that it cannot be stored along with contents. This is because type information is the same thing as the user name if you have dynamic typing, whereas metadata is radically different from content in both its semantics (what it means) and its syntax (who should and can access it). But again, I don't see a need to store or access it in a different way from the name of the object.
The file-system should not be hierarchical because trees become unmanageable when the grow too high. Instead of directories having files, files will have a set of tags. One finds files by these tags. For backward compatibility there wil be a standaard map:-tag which maps the files to directories, files wil be put in the hierarchy based on this value (eg: map:/home/meta/.bashrc). If this map-tag is not on the list the file will not be visible from this view. Files don't have names, the set-of-tags is the name. There is a special filename-tag which can be used as filename.
There should be no backwards-compatibility with existing operating systems in terms of user interfaces, libraries, binary compatibility, etc. The operating system must not compromise its quality to be more familiar to users of current operating systems.
What do you mean by 'user interfaces' here? I agree with avoiding compromise for binary compatibility, though I'd probably aim to support virtualization software (both running atop it and running other operating systems within it).
REPLACE THE HIERARCHICAL FILE SYSTEM WITH WHATEVER YOU CALL THE NEXT GENERATION VERSION
Hierarchical file systems naturally suffer from the LimitsOfHeirarchies?. A "tag file system" or "database file system" (KillerFileSystem as TaggedDatabase) (or sometimes a "metadata file system", if you're being excessivly technical, excessively meta, and a prick) is the way to go. I personally would settle for being able to make full-rights links to directories, symlinking directories on the same disk is for the birds. But I am not afraid of the command line.
MAKE SURE EXISTING FILE SPECIFIACTIONS STILL WORK, THOUGH
'/home/toafan/music/The Beatles' still needs to point to my Beatles collection, even though I could use '/music/The Beatles/toafan' or '/The Beatles/toafan/music' or others instead.
FIGURE OUT HOW TO MAKE THE COMMAND LINE WAY LESS SCARY
My thought, what we really need is to come up with a way to combine the searching/do-everything -ness of things like Gnome-Do, Launchy, Synapse or Krunner with the relative persistance of a terminal emulator's command line. Running Linux's 'cal' command in Krunner isn't much use -- there's no persistance, no display. But the command line is widely-regarded as intimidating, and the 1.5 shells I've seen can't do as much as krunner/synapse/etc as easily anyways.
A COMPLETELY DIFFERENT KEYBOARD DESIGN WOULD BE NICE, BUT I THINK WE'RE SUPPOSED TO BE TALKING SOFTWARE HERE
What I really want is a freestyle (a la Kinessis Freestyle Keyboard, http://www.kinesis-ergo.com/freestyle2_link.htm not KinesisKeyboard) two-hand keyboard, with space, enter, backspace, tab, and the modifier keys (control, alt, shift, etc) on the thumb (the mod-keys need to be on BOTH thumbs!), the keys themselves in a grid-based layout (probably enhanced by being curved to help fit the hand, with 'fit the hand' taking priority over 'grid'), and arrowkeys numpad etc 'embedded' over the regular keys with another modkey. While I'm at it, I want it in Dvorak, and I want to be able to use this device to control the mouse, too -- whether on the table or with my thumbs.
STOP FUCKING PUSHING LAPTOP KEYBOARDS OFF-CENTER
Did I mention I really hate laptops with the keyboard off-center, especially when the touchpad isn't centered to the keyboard? Laptop keyboards with number pads are the worst.
MAKE BACKUP EVEN MORE PAINLESS THAN APPLE'S TIME MACHINE
More painless? Less painless? Whatever.
Plan 9 may have had the right idea, with time-based backups available for everything just by being on the filesystem.
SERIOUSLY CONSIDER AMIGAOS'S APPROACH TO 'FILE-SYSTEM LABELS'
You could put a bunch of different folders, from multiple physical/logical disks, under one 'label' (as I understand it). For example, 'music:' could include my iPod, the 'music' folder on my flash drive, and the 'music' folder on my hard drive.If you manage to implement TagFileSystem? and something like Linux's "one tree", you get this^w the equivalent for free.
ACCESS CONTROL LISTS ARE NOTHING TO SNEEZE AT
You can do the same thing with Linux/Unix groups, in theory... but only if you have the authority to create them. And that's generally just for root.
IN FACT, PUT THAT RIGHT IN THE FILE TAGS/METADATA
Any user who matches 'read:$USERNAME' for a given file can read it, anyone who matches 'append:$USERNAME' can append to it, etc. The owner, of course, can add and remove those tags.
AUTO-SAVE FOR EVERYTHING SOUNDS LIKE A GREAT IDEA
I forget what talked about this... it sounds awesome, though.
THE SYSTEM SHOULD LOOK IDENTICAL TO BOTH A USER AND A SYSTEMS PROGRAMER (22)
The operating system's GUI should use the same cues humans employ to navigate cities (landmarks, districts, gates, etc), presenting a concrete reality which any human can model and use. These cues have evolved over millennia of city-building experiments all over the planet because they work. Let's not reinvent the wheel as a cube!
The operating system's GUI should be 3D and radial, not 2D and rectilinear. Because you can fit more objects in a 3D environment, as well as their interrelationships, and humans remember angles better than distances.
Should use ZoomableUserInterfaces (to prevent clutter), GestureRecognition, DirectManipulation and the very latest in HumanComputerInteraction. The gestural language should be well-designed, not error-prone, and complete so that a user can use the language to specify new gestures and assign them new functions (much like you can specify new words in English).
DontModeMeIn, NoApplication, inputs processed and translated and passed to objects based on inferred semantic context.
The GUI uses ContinuousTransitions everywhere. No windows instantly materializing at the touch of an icon. Navigating the directory structure is continuous, like the physical world, not multiple acts of teleportation. Et cetera. Some recent research indicates that abrupt transitions impair modeling and navigation, especially by women.
I happen to like windows instantly materializing - when it's in response to my command. I find animations annoying, and I hate waiting for them to complete before I can do something else.
Seconded, I also find ContinuousTransitions annoying (even if they're quite short). Windows allows me to turn off some of them, but the options to do that seem to be in 100 different places.
Windows doesn't have continuous transitions. What are you talking about, you fools?
The issue of responsiveness is independent of continuity. In general, the system's response should be as fast as the user's input. So if a user issues only a single discrete command, then the transition (which should still be continuous) ought to be blazingly fast. However, discrete commands are far less often appropriate than most people suppose and wherever possible, there must be a continuous version of a discrete command. For example, if you can pan one screenful to the right using CTRL-<right arrow> then it must also be possible to pan continuously to the right using the pointer.
Should use high quality sound and video to signify success. Failure is the lack of success so deserves no mention.
Windows should be transparent and tinted: if I open a process window behind my editor, I should be able to see through the editor to the process window, although there should be enough contrast to clearly see the editor text.
This is completely arbitrary and over-specific to the point of absurdity. If this point is meant seriously, it should be replaced with "windows should have any dimension, geometry, colour and configuration the user chooses".
UserInterface should be completely replaceable. Guiding point for available functionality should be that the interface should be able to host any other user interface.
What do you mean by UserInterface? The graphical representation of the system's contents? Or the relationships of low-level objects as determined by the primitive operation language's semantics?
Every useful feature of a modern programmable shell (scripting, piping, event history, set operations, gesture completion) should be available natively in the GUI. Powerful features that are horrible to use in a CLI (parallel piping) should be found and implemented to entrench the GUI's superiority. For example, linguistic commands uttered in a well-defined environment (working directory and such) can be ported into a GUI by making them available as a function. Like hitting ctrl-f to invoke a search function, you would invoke ctrl-p to invoke a one-off command prompt. Unlike a CLI, this command prompt invocation wouldn't be a standalone application but merely a plug-in to the GUI.
The GUI should make full use of rich input devices, like the 3D RingMouse?.
All aspects of the GUI should be configurable and extensible.
users should be able to add sorting modes to the list of system-provided ones by specifying SortBlocks? instead of being limited to "by name" and "by size". A SortBlock? takes an OrderedCollection as argument and returns another OrderedCollection. The SortBlocks? could be dynamical so they respond to what the user does. For example, a sorting method where the user manually specifies where each icon goes on the screen and the SortBlock? remembers that; and if the user moves an icon in another mode then the "manual sorting" SortBlock? folds in that particular icon's new position for future use (although "new position" is ill-defined; is it relative or absolute?).
I don't believe that a GUI should let you specify an arbitrary position for objects in 3-space. Directories are sets and structure is provided by the directory structure, not positioning. However, if such arbitrary positioning were allowed then the position of an object in 3-space is part of its metadata and belongs together with its name and classname. That's because this must be globally visible info, per-reference not per-object, and has the same access semantics as names and classes (the person who owns the reference owns its position, its name, and its targets' class).
I should be able to specify for all applications things like:
scrollbars appear never, always, or only when necessary
scrollbars appear on the right and bottom of what they scroll
There should be no scrollbars or other interface artifacts. All of an object should be there even if it's off-screen, with the user able to pan to whatever part they're interested in. For example, a novel would be displayed in its entirety and when the user zooms in to a distance where they can read it, the rest should simply be off-screen but available using simple panning. Of course, the document handler of the ObjectBrowser might have to be smart enough to preserve a position in each document so you can zoom out and zoom back in without restarting at the beginning.
What if the user wishes to pan several pages at a time? 2? 10?
And the problem with that would be? Panning doesn't have to be constant speed you know. It can be linear, steadily increasing speed the longer it happens, or even polynomial. Further, there's nothing stopping you from mapping the pageUp/pageDown keys to pan a predetermined distance; exactly one screenful.
But more fundamentally, a "page" is an arbitrary (bad) abstraction that simply doesn't belong in documents. Rather, documents have chapters and segments. And you certainly don't represent a structure by flattening it! So for example, the easiest way that you'd represent a novel would be to have each chapter as a separate document in a directory. That way, a user can switch between them by panning to the left or right. And if you want to represent segments then it's just as easy; make them subdirectories of the chapters.
Avatars. If a user so wishes, they should be able to see any other user 'present in' (looking at?) the same directory they are looking at. This must be done without polling either other users or a database of users. Preferred implementation: the GUI creates a non-traversable link called 'user MyNameHere?' in the directory they're looking at back towards their own user domain. A GUI seeing links starting with 'user ' would interpret them as avatars. The link would point to a directory containing the avatar's image, and a file that can be used for chatting. The GUI would merely be graphically presenting things that can be seen and used in a CLI.
Bookmarks. User should be able to create and recall bookmarks to locations. Like in BlackAndWhite.
Multiple foci. If the user so wishes, they can have multiple mouse pointers and switch between them. Each is independent so can go to any location. There is no disjointed boundary between the locations the different foci are at. Either only one is represented on screen, or the space between them is compressed (but not edited out) so both are visible on screen. How many foci to display should be user configurable.
All objects have a position in 3D within their location. This position is global. Best implementation is that the position of an object is integrated with its name, just like an object's class usually is. For example "EnterpriseB.140x80.jpeg". Multiple objects can be in the same position since they can have identical names, though the GUI might avoid that as a convention.
The system has intelligent defaults everywhere. It doesn't whine just because an object has no position (e.g., if it has no name), no class (e.g., if it has no name), or the class handler thinks the object is gibberish (e.g., if the class is misspelt, undefined, or just plain wrong).
If we stick with WIMP, the GUI should be in control of the windows, not the application. I should be able to manipulate the geometry of a window regardless of what the application is doing.
There should be NoApplications. Just objects represented by an ObjectBrowser. The representation of particular object types is given over to the OB's plug-ins which are typically daemons. The windows aren't under the control of "applications" because there is no such entity. At best, an Object Browser could enter a space handled by another object browser in a recursive fashion. But this would be the exception, not the rule.
Simple operations should be simple to reverse, at any point (i.e. not just through an undo stack). And this includes things like hitting the "close window" button. I don't want "are you sure you want to quit" messages; the ability to say "undo 'kill'" is far superior. Usually, I know within +/- milliseconds of hitting the "close" button that I didn't want to hit it, so the undo-ability (i.e. not trashing resources) doesn't need to survive for very long. Actually, I don't think this is necessarily a GUI-only thing: a CLI undo command would also be useful
All operations should be local and predictable. Counter-example: Windows undo stack. (You choose "undo move", yeah well which move was that? Where the hell did the file go? WHICH file's move was undone?)
The reverse of an operation should not be much more involved than the operation itself (this may be too obvious to mention, but few OSes follow it)
Searches are first-class objects. You can create a search, store it, move it around, and publish it, just like you could any other object.
The ObjectBrowser does automatic collapsing of sparse object graphs. Meaning, if you've got a directory with only a subdirectory with only a subdirectory with only a single file in it, then the OB shows a single file at the top level and hides the intermediate structure.
Search results aren't lists but graphs with the same structure as the graphs they operate on. They'll usually be sparse graphs so you need automatic collapsing to make sense of them.
For real, gang: let everyone have 3D objects just by using our thing. With full 3D, and full transparency/compositing. This has some seriously awesome potential. (1 and 2)
I WANT TO USE THE MOUSE AND THE TOUCH-SCREEN INDEPENDENTLY
A mouse pointer has the advantage that you can leave it in one place and be sure of hitting anything that shows up there. (EG, pause button on youtube videos in different^w adjacent tabs.) Touchscreens have the advantage of, well, being touchscreens -- If I have to explain the user-perceived advantages of a touchscreen to you than you loose. I want both. (see also 15)
OMG, 3D WIDGET THINGYS FOR THE 3D DESK-SPACE
For example, the music player widget could be a jukebox-shaped thing. Just imagine the possibilities.
IMPLEMENT 'TABBED' WINDOWS AND 'STACKING' WINDOWS, A LA BEOS/HAIKU
I've got a video I need to add here to really explain what I'm after. I'll be right back.
ALL GUI ELEMENTS SHOULD USE libGUI. libGUI IS A WRAPPER/POINTER TO WHATEVER libGUI PROVIDER THE USER WANTS.
"Solves" 7, 8, some of 11 and 12, relevant parts of 'GUI Discussion'
TILILNG WINDOW MANAGERS ARE THE BOMB
I know this contradicts the 3D thing, but even still.
MANAGE WINDOWS WITH TAGS, LIKE AWESOME-WM
That is freaking briliant, and I'm still wraping my head around how best to use it.
WHILE WE'RE AT IT, JUST USE TAGS EVERYWHERE POSSIBLE
I mean, this is pretty much how humans think. Hierarchies are usefull, but they're really just a system for sorting tags --atributes --whatever.
Most of the "features" listed above that related to UserInterface issues seem utterly arbitrary to me. In particular, these are all things that I think ought to be up to the user, not the OS designer, to decide.
Well, they're not. The "WindowManagers don't belong in the OS" and "we can create a value-neutral UI" arguments are stupid, so quit it.
That's strange. One of the "features" mentioned above (not by me) is: "User interface should be completely replaceable" and "should be able to host any other user interface". That sounds a lot like a "value-neutral UI" to me.
I'm not a huge fan of windows, really, all the apps need to have is a place, or several places to write their own idea of an interface. I think this application-level overriding of window decorations is an antipattern: what if I exclusively use full screen modes? What if these windows are mapped onto high resolution 3d surfaces? -- WilliamUnderwood
What if you don't want persistence? Why force TransparentPersistence on an application when you can just force 99.999% of applications to have to handle file i/o instead?
What if you don't want graphics? Why force a GUI on an application when you can just force 99.999% of applications to handle raw framebuffers instead?
Your argument is nuts. Not least because the WimpInterface model is far more in tune with what you say you want than you realize. In particular, the WIMP model forces 99.999% of applications to deal with interface issues like scroll bars, menus and other shit that no self-respecting application writer wants to deal with.
If the OS really freed applications from interface issues, every application would deal with a single framebuffer of any size or dimension, with no menus, no borders and no scrollbars. All of those UI issues would be dealt with in the OS where they belong. Instead of a user "opening" an application and then "choosing" a file, each file would be presented by the OS as "open". So if you have an image file, the OS presents it as a miniature image which you can zoom into. If you have a text file, the same thing. If you have a sound file, you start hearing it the moment it's a certain distance away (or it's in the dock where it's zero distance away from the user). There would be no more standalone "applications", just plugins to the OS.
This would enforce a common standard under the control of the user, not millions of different application writers. It would also put all those extra computer cycles to good use. It would naturally require ZoomableUserInterfaces, 3D and other techniques to reduce clutter. This would be a good thing since when a system's components all require each other to exist, this proves the choice of components is not arbitrary.
Proposed categorization schemes
It wouldn't make any sense to artificially limit entries. We don't have any idea what ordinary people want from an OS, and we should find out before we start excluding their input. We want to encourage growth, breadth, diversity and coverage of the page, not elitism, competition and hegemonization.
For the same reason, analysis and categorization of the features (unless in the crudest possible terms) is also premature. This page works as a raw collection of user stories. Trying to rarefy it will cause it to die. See OperatingSystemsDesign as an example.
New Os Features