OSNews

Core:
1. User interrupts rule all. Realtime through and through, but with full NUMA support, where a process can be optionally flagged as preferring bandwidth, instead.

2. UTF8 all the way through. Unicode isn't perfect, no, but UTF8 is a great compromise all around. Just start at the bottom with it.

3. Local and remote resources transparently blended, a la Plan 9.

FS:
1. Unix-like main structure, but beyond setting out devices and such, the structure has pools to be accessed. A pool being not unlike an LVM volume, in terms of relating actual storage with what you see using the system. This is where the hierarchical bit of it ends.

2. Each pool would contain unique files with certain attributes, from which security and file structure could be created (persistent views) or divined (ad-hoc queries). The system would be purely relational, and support versioning of every kind (roll back files, have multiple library/app versions, explicitly view file edits, etc.)--use it or not, your choice. If you wanted a certain version of a certain library, you ask for that, rather than hope it is a path you think it should be. Applications could add their own properties to files, easily viewed by anything else in the system, for near-infinite flexibility. The security system in the kernel would be able to handle who and what has write permissions to the attributes.

3. Fancy features like replication, being able to roll back data, snapshots, what have you, would be able to be turned on and used with such an on-disk FS, or it could remain unused for any reasons you may have (save space, gain speed, etc.). FSes preferred would be 2nd or 3rd gen transaction-based non-journaled FSes, learning from pioneering ones like ZFS.

All this would allow transparent use of user, local system, and distributed system resources without propagating symlinks and whatnot. Persistent views would allow arrangements for backwards-compatibility with apps made for other systems, and to handle cross-platform apps (so, it could make an entire Red Hat file tree, FI, have a WINE-like app, and then go).

Also, you could have your favorite file manager or media browser or whatever else, whose UI could give you radically different views, and allow for radically different workflows, without screwing with the underlying system, without creating its own FS-on-top-of-an-FS, and in a way that other applications could be extended to use with minimal or no added coding. If we start to see good SMP on mobile devices (or generic stream processors in mobiles), this sort of thing could be done efficiently and powerfully with the mobile hardware of 5 years from now, as so much of it is naturally parallel, the raw data would tend to small, and the future of the workstation-like desktop is less interesting than mobile stuff or server stuff .

Data/app management:
1. Applications would have well-defined inputs and outputs, with near direct linking by using the hierarchical side of the FS. Monolithic applications, even for GUI user things, would be eschewed, in favor of using these features to tie multiple apps together. Libraries, instead of proper applications, would likewise be eschewed. Monolithic apps could be literally be front ends that controlled pipe and socket type file interfaces.

2. Files would automatically have persistence, within the limits of the file system implementation. Files would support stream, OO, and relational interfaces, so that applications would be encouraged to work directly on files, rather than using large in-memory buffers, at little to no performance penalty (or to map to those interfaces for incremental persistence of custom data structures). Applications with ownership of a file would get significant control over exact data structures used, to have better control over memory use, speed, etc..

3. The OS would have services to serialize states of these file objects to images for the disk (something more efficient, and friendly to non-hierarchical views than XML, like a compressed UTF8 Lua). Using the OO or relational interfaces, the application could declare the beginning and end of a write, for a proper transaction (otherwise, every write is one, like w/ byte-stream style files, which would remain supported directly).

4. Free RAM and disk resources would determine the aggressiveness of garbage collection (down to an embedded option for immediate freeing, rather than incremental GC). Any app that used OS-specific interfaces for managing its data would automatically get a system-wide GC, so only need to worry about direct memory management of its internal temporary structures (getting rid of such things will just get devs hating your platform, so...).

UI/development:
1. The default terminal would connect to a JIT VM, that then connected to an OS abstraction layer. You'd have a real functional programming language right there, geared towards OO. It would have included direct robust support for working with multidimensional data structures, so you wouldn't have to go through weird machinations to do basic things with objects, or roll-your-own mappings. Native machine compilation of shell scripts would be an option.

2. Included GUI would include applications to do real-time diagramming and tracing of more intricate data structures and events, because that's going to be a n00b hurdle like nobody's business, and be handy for new users of a specific system instance (your workstation or phone, FI), that already know how to use the system in general.

3. The primary GUI (make your own, if you want) would have a zooming interface, made to be menu-driven. Pack a lot on there for a keyboard and mouse, make it 10' for your TV (or tablet), have deterministic scrolling or categorical rearranging for small mobiles (FI, a separator in the WIMP-like UI makes for a submenu in the mobile), etc.. It could scale from big icons and buttons to curses. No toolbars, or anything like that (so, more like a good mobile UI that scales up nicely, than a common desktop UI that can cram itself down). Applications could provide specific presentation rules, should they need to take over sets of, or the whole, screen space. Details would depend on UI research applied to actual application workflows. The less you know there is even a WM there, the better it is working (I am intentionally leaving out managing multiple windows, as that should be a bit different, depending on hardware platform).

4. Programming libraries made for small size, and efficiency, over speed.

Robotics:
A scheduled job would be included, to make a caffe breve every morning for me. If I'm gonna dream...

So, ultimately: good horizontal scaling (including generalized heterogeneous computing), user responsiveness over throughput, and the best data and IO models yet devised, so that the rest of the system can be done the best way possible, with thorough horizontal software integration (FI, what I've laid out would make hot updates and live backups trivial, and a cloud OS UI possible, but not trivial).

Edited 2009-11-06 18:34 UTC