I always think the separation in application vs data storage vs operating system to be a little weird. It get weirder as you consider Ajax blurring the line between client-side application and server-side web-application (not that Ajax is particularly clever, IMO, but that's another story). The thinking goes: you run an application on the operating system. You use the application to open and manipulate data. You save your changes back into the operating system (file system). The operating system manages the file system as well as various library functions and hardware interfaces which the application might make use of. The holy trinity of desktop computing: operating system, application and data.
The thing is that this separation is wholly artificial. I admit that there is some merit in it's simplicity - as Pirsig would have it, the intellectual scalpel cuts cleanly here. The corporate advantage is that it leaves the door open for application-builders to develop their applications and sell them. However it does start to break down towards the edges, and I believe it is now really starting to show it's faults.
The downsides stem from this separation. Take auto-save as an example. The functionality was a god-send to so many who had forgotten to save when a crash had happened. The crash would wipe all data since the last save. At least auto-save would improve the frequency of making those saves. However, the auto-save was a hack to get around the separation between the operating system and the application: instead of integrating more closely with that file system we get something which, in effect, polls quicker. The problem was that the operating system hadn't supplied the libraries to help fix the problem. If the operating system was to maintain the data storage properly it must be responsible for all reads and writes. This security is crude, particularly on Windows, but even on other systems only really serves to demonstrate the separation.
I once asked a programmer friend how many interpreters he'd written - he said, 'none'. I pointed out that all programs which act upon data are interpreting it and are hence interpreters. When I asked again his answer was now, 'loads, but..', he was still unconvinced. I maintain that any data is really a set of instructions to an interpreter, we just choose to think of it the other way round - data vs application. Think about almost all modern operating systems: the programs themselves are held as files, as well as the data. It's not too hard to think of a Word document as a set of instructions which are interpreted by Word to render a document. The editor is just a fancy programming environment, further blurring the holy trinity.
There used to be lisp machines that held the whole shebang in one 'environment'. There was no operating system in any true sense, instead the systems comprised a complex web of function calls. The functions were themselves the data (at least nominally, but that's also another story), which could in turn be operated upon by other functions. Within this, 'saving' wasn't necessary because the system automatically persisted itself to whatever long-term storage medium was available as necessary, effectively the swap-disk was the long-term persistence. These systems were, on an intellectual level, a structure which the user interacted with. The blur here is almost complete - there is no difference between any part of our modern holy trinity.
There are a number of systems here which demonstrate a blurring of the sharp definitions of operating system, data and applications. I think the next step is to contemplate an environment similar to those lisp machines, but updated for today's audience.
The new environment would be a graph of 'objects', linked together and intrinsically persisted to whatever storage medium was necessary - just like the old lisp machines. Further, this environment could be networked into other systems - creating a worldwide, peer-to-peer operating system. Objects can be free to roam around this network thus moving closer to where they're used more.
To stop virii and crackers, the environment would implement security at the level of object-dispatches, passing a priviledged context in which the call is made. In old Lisp machines I'm sure the resources were not available for this, in unix and other operating systems the file system has a complex set of user permissions. This is just a step further on, inside the functionality itself.
Now, to visualise this massive amount of information, I suspect a full 3D environment would be necessary (or at least an interesting and fun idea). This would have to be created to show and hide detail as necessary depending on the level of skill of the operator. Linking environments together now becomes one of spatial geometry.
Finally, the corporate angle? Hardly the point, I know, but worth considering. Firstly, there must be objects to interface to hardware. Secondly there will be objects which can be used as user-interface artifacts (word processor, spread-sheets, etc) but remember that these interface with other objects - hence standardising all 'file formats' (which wouldn't really exist any more).
A brave new world, where there's just you and the environment. What will happen to religion then?
Monday, January 16, 2006
Tuesday, January 10, 2006
Apache Harmony
Apache want to create/obtain a Java VM of their very own. I've always thought about doing something like this, but that's another story. This post is about modularity in a virtual machine.
I suggested somewhere in the mailing lists that the JIT compiler could be used as the basis for writing the VM in Java. It's quite simple: the JIT converts bytecodes to native, so why not use that as the way to convert the bytecodes of a java application (the VM) into native as a one-off compilation stage. The one difficulty is memory management, but let's assume this can be overcome with some basic conventions when writing the VM.
I suggested somewhere in the mailing lists that the JIT compiler could be used as the basis for writing the VM in Java. It's quite simple: the JIT converts bytecodes to native, so why not use that as the way to convert the bytecodes of a java application (the VM) into native as a one-off compilation stage. The one difficulty is memory management, but let's assume this can be overcome with some basic conventions when writing the VM.
VM server-side
Why are virtual machines so very popular on the server-side? Java was invented to be a client-side sandboxed environment. You remember all that applet rubbish that never took off?
It was actually a quite sensible idea: you can never know what hardware your client has, so the standardized interface (bytecodes, etc) made utter sense. It never took off for various reasons I don't pretend to know. I'm guessing it was a bit bulky to install, then the applets weren't exactly tiny (remember we only had 56k modems back then, some of us only had 33.6 or 28.8). Then I guess the nail in the coffin was that the applets weren't easy to visually control, so they generally looked a bit rubbish.. and if another nail were needed, Microsoft did their embrace and extend but got rebuffed.
So why did Java go all server-side? It doesn't make that much sense. The server-side hardware can be completely controlled and a virtual machine is slow compared to a compiled environment. Even JIT can't account for that much speed when compared to well-writted natively compiled code.. can it? Now .Net has arrived: the microsoft alternative to Java. Although there is a fair amount more emphasis for .Net to do GUI's, most of it is server-side and web-delivered. Folks are even doing work to other, older VM's like Lisp, ML, etc, to make them web-enabled.
The only concrete conclusion I can reach about VM's on the server is that they're just nicer languages. Nicer than C and C++ (arguably, Java is what C++ should have been). They're Garbage Collected so you can be a little lazy and not get bitten. Actually, memory leaks in non-GC environments are notoriously difficult to find and fix. You *can* create memory leaks in GC'd environments but I digress. While I'm digressing, there are non-VM based GC environments too.
I think the VM arguement is actually a red herring. I think Java got popular because it was a nicer language at the time and now it's achieved industry standard-ness.
It was actually a quite sensible idea: you can never know what hardware your client has, so the standardized interface (bytecodes, etc) made utter sense. It never took off for various reasons I don't pretend to know. I'm guessing it was a bit bulky to install, then the applets weren't exactly tiny (remember we only had 56k modems back then, some of us only had 33.6 or 28.8). Then I guess the nail in the coffin was that the applets weren't easy to visually control, so they generally looked a bit rubbish.. and if another nail were needed, Microsoft did their embrace and extend but got rebuffed.
So why did Java go all server-side? It doesn't make that much sense. The server-side hardware can be completely controlled and a virtual machine is slow compared to a compiled environment. Even JIT can't account for that much speed when compared to well-writted natively compiled code.. can it? Now .Net has arrived: the microsoft alternative to Java. Although there is a fair amount more emphasis for .Net to do GUI's, most of it is server-side and web-delivered. Folks are even doing work to other, older VM's like Lisp, ML, etc, to make them web-enabled.
The only concrete conclusion I can reach about VM's on the server is that they're just nicer languages. Nicer than C and C++ (arguably, Java is what C++ should have been). They're Garbage Collected so you can be a little lazy and not get bitten. Actually, memory leaks in non-GC environments are notoriously difficult to find and fix. You *can* create memory leaks in GC'd environments but I digress. While I'm digressing, there are non-VM based GC environments too.
I think the VM arguement is actually a red herring. I think Java got popular because it was a nicer language at the time and now it's achieved industry standard-ness.
My world
As an intro, I thought I'd write about the computers I own.
I have an old Athlon 1Ghz with 256M/80G. Basic workhorse with WinXP and Office (for CV-writing, working from home, etc). The monitor's a nice 19" Dell flatscreen. My advice to anyone buying a new computer: forget Ghz, get a great screen.
I have my Powerbook 15" G4 1.25Ghz, 512M/80G. This is my main computer - MacOSX 10.3 is a fine OS.
I have a more recent Mac Mini G4 1.4Ghz, 512M/80G. I'm using this as a home server, running MacOSX 10.3 (not OSX Server).
The mini serves files and I'm currently working on an installation of Plone/Zope to unify my address books and diaries. I could use Open-Groupware.org but it seemed much more limited, even though plone doesn't fully replace a groupware server.
The mini also serves as video-conferencing using AIM and iChat. It's interesting that there are no real cheap webcam options for Mac - I'm using my camcorder instead. This is a little annoying tho' because the Mac doesn't see the mic on this as a proper audio input device, so other VoIP applications won't use it (particularly Skype, as a friend uses this a lot).
All this runs over an 802.11g network. The positioning of my PC (upstairs) and the wireless access point means that with the belkin card I bought, it has to signal through the floor/ceiling and a chimney breast, i.e. no signal. Interesting that these cards come with an aerial in the back, which in a home you then shove up to the wall, probably in a corner. So I had to buy a separate aerial on a wire so I could move it to a better position.
Printing, I have an epson RX600. One minor gripe is that I haven't got a proper network solution for it. The 802.11g print servers are way expensive given that I'd have to walk upstairs to turn it on anyway. Not sure how to deal with this. Wonder if Epson do a plug-in network adapter which will do WoL... For now I just walk upstairs and plug in the USB cable.
I have an old Athlon 1Ghz with 256M/80G. Basic workhorse with WinXP and Office (for CV-writing, working from home, etc). The monitor's a nice 19" Dell flatscreen. My advice to anyone buying a new computer: forget Ghz, get a great screen.
I have my Powerbook 15" G4 1.25Ghz, 512M/80G. This is my main computer - MacOSX 10.3 is a fine OS.
I have a more recent Mac Mini G4 1.4Ghz, 512M/80G. I'm using this as a home server, running MacOSX 10.3 (not OSX Server).
The mini serves files and I'm currently working on an installation of Plone/Zope to unify my address books and diaries. I could use Open-Groupware.org but it seemed much more limited, even though plone doesn't fully replace a groupware server.
The mini also serves as video-conferencing using AIM and iChat. It's interesting that there are no real cheap webcam options for Mac - I'm using my camcorder instead. This is a little annoying tho' because the Mac doesn't see the mic on this as a proper audio input device, so other VoIP applications won't use it (particularly Skype, as a friend uses this a lot).
All this runs over an 802.11g network. The positioning of my PC (upstairs) and the wireless access point means that with the belkin card I bought, it has to signal through the floor/ceiling and a chimney breast, i.e. no signal. Interesting that these cards come with an aerial in the back, which in a home you then shove up to the wall, probably in a corner. So I had to buy a separate aerial on a wire so I could move it to a better position.
Printing, I have an epson RX600. One minor gripe is that I haven't got a proper network solution for it. The 802.11g print servers are way expensive given that I'd have to walk upstairs to turn it on anyway. Not sure how to deal with this. Wonder if Epson do a plug-in network adapter which will do WoL... For now I just walk upstairs and plug in the USB cable.
Subscribe to:
Posts (Atom)