Monday, May 30, 2005

New OS

To implement some of my ideas properly, you'd have to start with another OS from scratch. But this is not always bad anyway. Linux is still gathering a following. From my personal experience, it seems that it has mostly gathered followers from two camps, the anti-Microsoft league for one, and the "techie" that finds the positives outweigh the negatives when it comes to system administration for another. Something to bear in mind is that really good operating systems can be ignored by the public. BeOS (at least when it first came out) was an ultra realtime OS, really good, and cross platform... yet still didn't take off. AmigaOS (the new one) probably won't take off either. I think this is because they don't offer enough difference to existing OSs, and they don't let you carry on using the old OS at the same time (at least not simply), and even if they do (AmigaDEV), they just don't give anything back for being involved... no killer apps. nor any killer ability.
So, if you haven't got any killer apps, and you aren't 100% compatible with existing apps of some sort, then you've got a great big steep hill to climb. You aren't gonna be able to catch up with the leaders that without a boost, as the leaders are still climbing. This problem is insurmountable (heh), so don't try.

Ok, given these theories, why has Linux been reasonably successful? Two reasons, it has killer apps, and it was born of the original operating system, so there were thousands of people already trained for the OS.
Killer apps? what killer apps?
Linux is based on server code, so you can say that Linux's killer apps are things like SMTP hosting daemons, generally better http servers, and remember at the beginning, who was it hosting all the web content? unix machines, not windows machines. Unix machine users (typically the geeky and the admins of websites and ISPs), were very quick to adopt the ludicrously cheap Linux, because they knew what they were getting. Other people who had started to hate Microsoft started to move away from Windows, towards Linux, but the difference was normally to great, so they sprang back after initially dipping their toes in the *nix waters. I'm afraid I'm one of these cowards. I stick with windows because its what i know, not because its good. I know myself that if anything goes wrong with a windows machine, i can usually fix it. Its easy to fix because its a simple system. *nix is more complex in appearance to me, so i don't trust myself to be able to fix my machine in times of trouble. That's why i don't move. There two apps I love that are entrenched in Windows (or Mac): Microsoft Visual Studio .NET, and Adobe Photoshop. Obviously, games on Linux are also a little limited in comparison, but I am a software developer, so .NET is actually more important to me.
Anyway, basically, Linux is creeping in because it can't be got rid of, not without losing quite a considerable amount of productivity amongst network "people".

So, as long as "Some" people can't live without your OS, you can get enough of a foothold to start creeping in. If you have overlapping killer apps, then there shouldn't be a problem with migration, and if you actually have some killer features, you should be able to "clean up", even if you're incompatible with other OSs.

So, can my ideas "clean up"? I shall run down the list of things that make up my OS.
Are my ideas windows or Linux compatible? No for windows, they could be for Linux. I haven't the foggiest how long it would take to write a windows compatible version of my OS, but i know it would take a very long time. To make my OS Linux compatible would be a lot simpler, and for most of the ideas, the OS would be possible to implement IN Linux. A mate told me that it might be possible to rewrite the filesystem, the kernel, and a window manager of Linux, so it behaved exactly the way I want it to. I hope it is true.
Are my feature ideas "killer"? They may be killer in fact, but i don't think they appear to be killer, the idea for a user interface i have might be killer though, and that might also be enough to interest a migration ready crowd. The database filesystem idea is bandied about too much to be taken seriously, and file instance applications sounds strange, not brilliant. Document centric editing could be a good start, but that is not the OS, but the way the Apps are written.
Does my OS deliver a necessity? No, obvious really, but unless the apps are built to complement my OS, even the basic needs will not be met. If some basic applications are built, Text editor, Image viewer, Compiler, and a Media station (WMP/WinAMP), then it could build from that, from them. Maybe given some time we could develop the killer apps necessary. These killer apps would probably be impossible to build outside the OS, and all the better for it.

Applications Rethought

Previously, i mentioned that filesystems and applications could be mixed to create a general search system. One that encompassed all things a computer could do. This was lead by a desire to bring together applications and files into one element, and make them equally addressable under normal search criteria.
This need to bring things together to save the user from having to think has already been addressed by memory managers. Virtual memory was seamlessly integrated into real ram meaning the computer user never had to wonder about how much ram they had left. Does anyone remember trying to make DOS boot disks to play games?
So, applications are instanced in ram. Right? Why?

If applications were instanced in files (just like they would be in a system with very limited ram ;) ), then any operating system crashes would be more survivable. Consider if you will the possibiltiy of having lots of important documents open... unsaved. Then, the system hangs, hangs bad... Have you lost all your work? on a normal system, yeah. But if all applications were literally instanced as files, then only the crashed application(s) would not revive with restart. There is a problem with crashing programs running after restart, but that is a seperate but not incredibly difficult problem to solve (just check for app death by running virtual machines? maybe).
To do this with win32, the operating system has to explicitly allocate a file for each application instance, has to guarantee that DLLs (windows dynamic libraries) arrive in the same location every boot, that the kernel has the same open file handles etc...etc...etc... This is quite a large task (the number of different things to look out for), and only gets more complicated when applications start working outside the box (apps that "investigate" other apps, or apps that twiddle things in the OS so things can happen / not happen).
So basically windows is incompatible with a proper file based application instance mechanism.
Oh well.
Maybe adding that will make the next OS worth having though eh?

Sunday, May 15, 2005

Documents rethought.

Documents are what we work with all the time while working on computers. We even work on documents in games (the save files). So why are we switching applications all the time... Why are we not switching documents?

Imagine if you can, a blank document (a blank word document is a good start). Instead of modifying the document in word though, you add word elements to the document and use those elements to create normal word document content. Applications work on these documents by either adding elements to the document, or just working on the atoms already in the document (bitmap docs). Add a Quark xPress element to the document, and gain the ability to make really good image boxes and stuff. At the very least make layout easier.

In this system, there are only a few types of file, so any application should be designed to work with at least one of them. The types i can think of are: finite page (A4 / web), 2D infinite page (line art), 3D infinite page (normal 3D package), 2D bitmap (obvious), 3D bitmap (voxels). Other pages might be looping pages (auto tiling), cell based (spreadsheets 2d/3d, even 4d), and database (tables).

So all applications are designed to work with these data formats. All designed to work as tools upon this clay.

Sounds good to me. (and i think i sounded good to Steve Jobs (or whatever that Apple guy was called) too... i think there was something called OpenDoc that was similar, but more like OLE.

Saturday, May 14, 2005

Correcting Operating Systems

Assumption: files are at the centre of the hard problem of operating systems in modern computing.

All operating systems still operate via root/directory*/file hierarchical, apart from add-on systems that interface with the old system to provide a database front end. There is one at least that i know of that can override KDE? file dialogs.
Database filesystems seem to be a great idea, but thats not all that is wrong with computer operating systems.

Programs are either running, or not running... sometimes when i am debugging 2 or more apps at the same time, i want to seperate my tasks off into different sessions (like user logins under *nix), but that is quite a cumbersome technique that dissallows any crossover / moving of one app to another schema.

So the initial assumption may need to be bent a little to encompass applications as well. What is similar between these two problems?

both consist of human interface representing all the things of one type a computer has... (all files versus all open applications).
most of the time the user is looking for one of the items (looking for a file, or looking for an application)

the assumption that you might look for more than one file (e.g. find a picture collection), probably wont apply to applications (looking for internet apps? nah, rather look for internet app executables to run (which are files)). But is a multiple file selection any different than a single file selection? Lets look at what normally makes up a multiple file selection.

People normally look for multiple files as part of collections. Collections are collections for a reason, and therefore have something in common. This commonality is rather well defined in database operating systems (and we are assuming here that a "better" OS will be running a database filesystem), and searches can be quit before a singular result is found (e.g. the result of the file finding operation was a set rather than a singular).

Does this mean that all file searches may as well be multiple file searches? I think so, because even a singular result is normally selected from a refined set.

So, both running applications and files are sets of items that the use wants to work with. With this assumption, can we then join the two? *nix has a process directory in its /dev directory, (/dev/proc i think), and because of this, a non databased hierarchical filesystem already has access to applications (in a wierd way)... how useful would it be to search for apps by the same system as searching for files? This is more of a selection system than a search system, so what have we assumed here? Users want to be able to quickly "select" things? I think so, therefore a new operating system (and associated applications) should be designed to work on the idea of selecting and reselecting any resources the computer has available.

how about some ideas of selection searches?

i copied some files from my camera recently, and i want one of the pictures, i know its a big one... so here goes:

select all (root select)
refine by action: was copied to local harddisk.
refine action by time: after last tuesday
refine selection by filetype: is an image (drops all non images from selection)
refine by action: was copied from camera (drops ones loaded from CD)

selection should be rather small now...

refine by file attribute: size larger than 640x480
refine by file attribute: colordepth higher than 16bit

now quite a refined selection, the viewable list should be small enough to select by hand. (tab through? or use arrowkeys :) )

how about getting an app, a currently running calculator

select all (root again)
refine by type: is running
refine by attrib: is utilty
refine by attrib: is maths

at which point we have a short list of apps, one calculus app, and two simple calculator apps, use arrow keys to select them.

At this stage, an idea comes to mind that the calculators will be exaclty the same as each other at this stage, so how can we tell any difference? The simple answer would be to add the same kind of labels to running applications as there are to files.
This leads to thinking about how to label applications. In my opinion, applications should be able to label themselves (such as an art package labelling itself with sizes of all its current open documents (but maybe not, i shall speak more on my ideas regarding documents later). Applications should also be able to labelled by the user (calculator one might be labelled as "simple maths", whereas the second would be labelled as "current account", and maybe a third as "coder debug helper". With these labels, the different applications could be quickly differentiated from each other.

I think this same system is good enough to help search for anything...

But thats just my opinion.

Maybe, just maybe, application instances ARE files... but again, more on that another time...

Rant over...

(next installment, documents / files rethought)

Tuesday, May 03, 2005

Graphics APIs

All of them can get the fuck off my lawn. I hate having so many different APIs (especially as i am doing conversion work).