ElectronicThoughtWeb

Too hard

noreply@blogger.com (Temporal Stillness) — Wed, 28 Nov 2007 10:32:00 +0000

I have gone around the houses a little with my psion. Building a distribution isn't the easiest thing in the world and here were the approaches I tried and have now rejected. First tho' a quick note to say that I looked at just using the excellent stuff on OpenPsion.org. The trouble is that it uses the unsupported wookie release of Debian. This is a 2.4 kernel, an initrd and a pre-built filesystem using the deb packages with some serious cleaning up. I really could do with a 'supported' distribution because I want to install some packages that the original author didn't think of.

First I tried to create an arm-architecture environment under qemu, and use this to compile a 2.6 kernel, uclibc, busybox, etc. There were a few problems with this, the biggest was the Mac compatibility. I never managed to compile qemu on the Mac properly - possbily a bug, possibly my fault - but it was taking me too long to solve. Then I downloaded the Q binary. This was better, but there were issues with the scsi device and again it was taking too long. On Windows it was better - I installed the binary qemu and created a debian basic install, but given I don't use windows at home it would detract too much from my work to do the whole thing at work. Also, I touched on the problem that setting up networking at work would have somehow been too hard. This confused me because the debian installer worked fine, however I was disallowed from enabling network bridging (work policy) when I tried post-install. So it should never have worked.. weird.

So I tried (at work again - naughty) to use the buildroot product from the uclibc/busybox guys under cygwin. Seems this is broken in a number of ways. There is some patchs that are required to fix an undefined reference to _libintl_gettext. I downloaded the patchs from the mailing list but they wouldn't patch properly - patch rejected them. I did a bit more digging and found that cygwin has some case insensitivity that will silently break an include somewhere in buildroot - I think there are two '.s' files with the same name other than capitalisation. Solution that was suggested was to compile on a linux box for comparison purposes. Not a solution I can really work with.

I then revisited the idea of just using the Debian etch install. The vanilla install is HUGE! Far too many megs for me to use. However, I could follow the method used by the OpenPsion guys. I could use ar to unzip the deb archives and manually (with scripts similar to those on OpenPsion) remove the stuff I don't need. The downside is that I will have to use glibc (bigger than I need really) but other than that, everything is binary and ready to go. I just need to cross-compile a kernel (perhaps re-use the config from OpenPsion's 2.4 kernel) and think about the initrd. Perhaps if I compile-in all the hardware support I won't need an initrd and can just boot into the root fs.

So cross-compile time

What I did last night

noreply@blogger.com (Temporal Stillness) — Tue, 06 Nov 2007 08:43:00 +0000

I made first steps into creating an emulation environment for compiling stuff for my psion. I have a PC and a Mac available, but I will probably use my mac most for this. So I downloaded this rather nifty UI called Q for Qeum. I have a psion ready to go, now I just need a linux distro so I can start compiling stuff for the machine. This link should be useful I think (alongside the one int he previous post.

In other news, chapter 1 of my kids book is well under way. Content is probably halfway through. Just remains to write a couple more illustrative examples and some explanitory text for them.

Linux on my Psion 5MX

noreply@blogger.com (Temporal Stillness) — Mon, 29 Oct 2007 10:22:00 +0000

I have seen openpsion but this is all debian based and I want to be meaner with the resources I allocate.

So, I'll cross compile myself a kernel, uclibc with toolchain and busybox. This should form a basic system (I think). Anything I've forgotten I'll work out as I go.

Then I want to try to get a graphical environment going. X seems like overkill (even if I just use a DirectFB driver), so I'm currently thinking that GTK on DirectFB might do the job.

GTK on DirectFB has several advantages, for example WxWidgets runs on GTK directly, so I can do some ruby GUI work (using WxRuby, possibly). AbiWord might be useful for word processing (tho' I'm not holding my breath here). So this has my book covered.

I believe there are also GTK based PIM's around, although this is more to do with confidence in the community than actual research!

The final thing I want to do with my psion is work on a parallel language. I think I would choose ANTLR to produce a parser/lexer in C and access this through Objective C (I have a religion that forbids me from touching C++ - call me a 'born again OO coder').

Obviously resources are massively constrained - 256Meg HD, 16Meg memory, 36Mhz processor. But, and let's get real here, I used to code on a 486SX33 (slower) with less memory and less HD (at university). Linux was perfectly happy and X11 was just fine. I'm going to be more stingy than before so I should gain some extra space and possibly a little bit extra processor resource. Here's hoping!

Baby book

noreply@blogger.com (Temporal Stillness) — Mon, 29 Oct 2007 10:22:00 +0000

As I said earlier, I am writing a book for kids to entice some of them into the world of coding. I think I can get quite far quite quickly - kids have no pre-concieved ideas about what is hard and so won't be put off when I start talking about objects, double buffering, threading and network communications.

What language to choose?
I'm not going to write it in Java, C (or derivatives), etc - it takes too much work to do small things: lots of code, creating files, compilation, shared lib mgt, etc. Java, et al are fine for enterprise level, heavyweight or just professional coding, but not for kids to scratch together little scripty examples. I think I'm saying I want a scripting language, so what other ones are out there?

I first thought javascript (ECMAScript really) would be a nice language, but the commandline versions of javascript I have found (on the JVM so I can re-use AWT, etc) have broken scoping rules (Rhino and FESI).

Groovy appears to have intentionally broken scoping rules, but that's a conversation for me and a Groovy friend of mine. It's worth noting here that this is as 'far out' of the mainstream as I'm willing to go. I want a recognisably 'real' language. Groovy is right on that boundary for me.

Lisp of some form might be nice, but I just feel some of the OO implementations are a bit of a cludge. My experience of lisp (scheme, ELisp and CLisp) was that you start from a long way back (by modern standards).

Perl? Just no, ok?

Python I just don't like - the whitespace thing just stops me every time. This, I know, is my fault. However, I'm aware that it offers nothing over ruby so ruby wins here.

Smalltalk was designed to be a OO, scripty, teaching language. Here is where I think I reject it. I am not after a teaching language, I want a 'real' language that can be used for teaching, one where it is a happy accident that it is suitable for learning to code. Have you opened an smalltalk environment ever? Squeak was the one I tried. Holey moley, was it offputtingly busy?! What I objected to was the mental leap reaquired to 'see' the code behind the pretty UI. Perhaps I'm too oldschool in this respect, but I see code as a distinct artifact. Mixing it into the graphical system is interesting, but I think this confuses the issue too much.

I have a friend willing to do the artwork. I think making it visually appealing will be practically as important at the content. Or in other words, I don't think it would work if either are wrong.

What other issues will I meet? It's always good to look to another's experiences. I found this excellent introduction from Chris Pine, so I an awaiting a copy of his book from Amazon.

Projects

noreply@blogger.com (Temporal Stillness) — Mon, 29 Oct 2007 09:57:00 +0000

My book is running first in my mind - a book for baby geeks. Age group will probably be 10 to 12ish, give or take. I'm hoping a precosious 7yr old might enjoy it too. I probably picked up my first coding book at about 11, but there seems to be very few, if any options available today. I am choosing Ruby I think. More in a later blog.

Second project is to make my psion into a useable linux machine. I do need to get the flexi fixed first, but then off we go. I want this machine for bacis PIM stuff, writing my book and doing the next thing on the list:

Last: write a computer language and VM for a massiavely parallel system. I've blogged before that I believe this is the way things will be and I want a playground where I can test my thoughts (before the hardware catches up). I should spend some time to identify the issues with the other options (like ERLang, Occam (pi) and more traditional threading models an POSIX threads, java, etc.).

Parallelisation

noreply@blogger.com (Temporal Stillness) — Thu, 04 Oct 2007 22:02:00 +0000

From the SICP book, I took the cue to go write a processor.

Ok, I wrote a piece of code that has discreet modules for executing a machine-code of sorts. As I have written before, coders will need to think differently in the not too distant future, so I thought I'd write a little language that could support massive parallelization. The more I thought and experimented (with ANTLR mostly) I found that writing just the language with no real execution environment was hard, and really weird!

I was trying to create just the programmer's mental model with no real silicon support (I'm talking 100 processors, not just "quad core bibble inside" dung ding dung ding). So, the answer is a virtual machine! This way I have as much silicon support as I want (it's virtual silicon after all) and I have something to execute my code. One day, maybe there will be a real mega processor machine, but until that I can play with the ideas without the encumbrance of contemporary languages and libraries. I can also (to varying degrees I suspect) exploit the hard work that went into the libraries of that language I am writing my VM in.

I'm using Java for a number of reasons. I will just deal with performance first. I DON'T CARE! This is my playground. I'll deal with performance when it's an issue. I even reserve the right to re-write everything, because this incarnation is only to allow me to explore some ideas!

I'm using Java because I know it quite well. It's higher level than C, allowing me to think in bigger terms than malloc, pointers etc. It's supported on everything. It's not a crusty old lisp machine where everyone argues about continuation passing and nods sagely about first class functions but no-one ever acknowledges that the libs suck and the non-existent syntax (or sugar as some would call it) makes life just tedious. It's not C++ (thank god). It's not tied to a certain OS manufacturer. It doesn't have the syntax (half ton of aspratame I think) that Perl does. It's not experimental like Ruby, Python or [insert name-on-rails here]. It's not dead like Pascal (or Delphi - who was Borland trying to fool?), Smalltalk, Ada, Eiffel, ML (and random derivatives - Ocaml, anyone). The only thing not to like about Java is that it is the business solution of the day. That is to say, it solves many management issues (politics, time/cost, etc) but goes halfway to solving the technical ones (concise definition of 'what I mean').

Enough about Java - I'm writing the next erlang, so step 4 turned out to be "write a virtual machine". I think steps 1-3 were all "go round in circles until you're dizzy reading well regarded texts and coding totally insufficient things". (For those in the know, view manger was my first step). I think step 5 will be to revisit step 3 with the benefit of a VM (syntax and semantic definitions).

Code is data is code (yet again!)

noreply@blogger.com (Temporal Stillness) — Mon, 17 Sep 2007 10:11:00 +0000

Right, I have previously described the distinction between code and data as purely convenience. In reality, there isn't a difference. However, we can get much more convenient than simply code/data, and most rigorously specified software solutions do. I have held up configuration data and reference data as more obvious examples of the crossover between data and code. However, these convenience names are also excellent examples of why the course-grained data/code split is fundamentally useless.

Let me also here, bring in several strands of computer systems development. Firstly, the user's mental model vs the system model. Logical model vs data model. Ref data, Config and business information.

I'll deal with this over the next few weeks.. first:

Config: the stuff in the code that needs to be changed for each deployment or machine.
Ref data: the libraries of the language that users use, but these libs will grow and change from time to time during the system's lifetime.
Logical model: the raw structure of the language of the user.
Physical model: how the computer implements the logical model.

Documentation is a whole 'nother can of worms here - layers of proof that the models above are accurately generated. Variously these are artifacts to show that that the user's language is understood and interpreted correctly such that the physical model cn always support the user.

How much easier if we always generated systems on the basis of writing a computer language.. Because a computer language is someone's implementation of a programmer's mental model (by a programmer) there is a necessity of rigor that often lacks in lesser systems.

Love/Hate - Mgt/Tech

noreply@blogger.com (Temporal Stillness) — Thu, 28 Jun 2007 10:57:00 +0000

This is an insight from a while ago. First, tho', to all my manager friends (who, coincidentally, are all excellent managers): please don't be indignant until you've read this.

Historically techies and managers have always been opposed to each other. See Dilbert for an example of this meme's entrance into pop-culture. I think the two views are a little like this:

Managers see techies waste money by doing things in a roundabaout way. The solution to most problems can be solved in some much simpler way.

Techies see managers as demanding corners be cut to deliver to a timetable which sould never have been rigidly set in the first place.

Techies think managers don't have enough technical knowledge (little knowledge is dangerous, etc).

Managers think techies live in some other-world where time/money don't matter.

Now, I've worked in a company with (practically) no management, by design. The idea being that techies don't like management, so we won't have any. The, 'freedom of freefall', was often referred to. I didn't get on with it at all, and with a little distance between me and it now, I can think of reasons why.

I'm a techie, so I make a crap manager. I think about the perfect solution, and the best technical answers. I don't like administration or politics - too floppy, no real answers. I think managers see things completely diametrically opposite from this. Admin and politics are the 'game' and there is no such thing as a perfect solution - only one that is on time, within budget (or close enough given the 'game').

So, managers need techies to answer their problems - obviously. Techies also need managers to keep the admin and politics flowing while they formulate the answer. Techies need to be reigned in to budget and time constraints, but managers need to be reigned into the realities of answering the question.

Managers need techies as much as techies need managers..

I just thank god there are people willing to be management for me.

OO Typing

noreply@blogger.com (Temporal Stillness) — Mon, 25 Jun 2007 11:45:00 +0000

What is typing? Other than being a fundamental part of OO methods, it feels quite badly understood. I have two intentions here: to analyse the existing definitions and to define my interpretation.

Typing can be static, dynamic, strong or weak..

Ok, this was as far as I got.. I started in June and it's now October..

I don't think this is a lack of understanding on my part - simply that typing is so very fundamental to human thought. This basic-ness means we are trying to grasp the very core of human thought. Take one well oiled eel!..

A type is a pattern (by human standards). This is the nugget which links humans to typing in computing. Strong typing is boldly saying that one particular thesis is correct. It is a strong limitation of the field of possibilities, which is not a necessarily negative thing.

On the positive side there are a number of pre-judgements we can make (or a compiler might make) about some code. This can lead to efficiencies in code production and execution. However it generally tightly binds pieces of code together.

On the negative side, it strongly limits the ability of a piece of code to react in unfamiliar environments. This is the same as saying, "it generally tightly binds pieces of code together".

The reason I prefer stronger typing is that a piece of code can know what it is dealing with. The execution environment can know quickly if a call is incompatible or some coercion is necessary. Hmm, I need more thought because coding for the silicon is letting the tail wag the dog (these days).

Parallelisation

noreply@blogger.com (Temporal Stillness) — Thu, 24 May 2007 13:10:00 +0000

I recently posted that massively parallel processor are on the way and that we (as programmers) will have to think differently to write code for these environments. I posted that we will need to think in terms of tiny nuggets of program that interact in some simple way.

This in itself is not hugely clever - expose a simple message-passing system, perhaps make a nod towards PI-calculus, maybe make compile-time restrictions on code size and message complexity. Hmm, a kinda SOA at the machine-code level.. grid computing anyone?

I think that moving away from the separation between 'data' and 'code' might help somewhat, and this bit is clever! It would mean that, once suitably transformed, a users data can be expressed in terms of it's interpretive ability. A new service can be created because we know that the user has recorded the position of a telelphone port, or changed the value of the price of a share in some company. Now our 'real' coders are really writing interpreters. They are writing programs that interpret the data into machine-executable processes. Of course, the implication is that we are creating a program that is writing itself at execution time... oh boy!

What happened?

noreply@blogger.com (Temporal Stillness) — Thu, 24 May 2007 12:30:00 +0000

I'm not happy! What happened to good code? What happened to efficient programs? What happened to squeezing the last dribble of performance out of that computer?

Why is my PC is starting to creak even though it has 2G memory, a superfast HT P4, SATA, a mega gfx card, etc. I remember (whistful reminiscence ensues, cue scratchy violin music and sepia, soft focus imagery) a P166 with 16Meg and a 1G IDE HD playing Quake and Duke Nukem. I remember programming image manipulation programs and virtual reality services that barely tickled it. I remember... when I was a lad, you had to solder your own processor to the motherboard and blow an EEPROM with a basic BIOS. Actually, that last bit is true - I feel like I'm one of the last of a dying breed!

So, what about this? Here's some possibilities:

The Von Neumann bottleneck is probably biting our butts. Not just memory though, as more use is made of the HD in modern OS's. More generally, the data comes out of the processor at a huge rate on knots. The first thing it hits is a thing which we shall call a north-bridge. This generally does AGP (where applicable), PCI and the memory bus. The data-transfer across this piece of silicon would have to be huge - an error, or sub-optimal bit of this would certainly have a big effect. Peripheral devices, such as USB, HD control, serial and parallel interfaces are then bundled into a south-bridge. More often than not, this sits on the PCI bus. So, paged memory in the OS has to pass through the north-bridge, across the PCI bus and through the south-bridge on it's way to the HD. Plenty of scope here for bottlenecks.

Onboard gfx with shared memory is, imho, the biggest pile of pap on the planet! Every screen refresh, the card has to request all it's memory from main memory. Now, dear reader, re-read the previous paragraph! Not only is the memory bus being used for normal processor operations (remember that a processor can easily fill this bus) but you're whapping a screenful of information across the bus 60times per second. Nuts!

Bloatware screws things too. When a simple web-browser can hog 100megs of memory, we have to think to ourselves that something is wrong. Pushing this amount of data around cannot be necessary and would certainly have an effect on performance. But more fundamentally, when the OS has a lot in memory it will generally page more and hence have to traverse between the memory and the HD more.

So... an answer? Hmm, difficult!

Certainly the next big thing on the horizon is big, multi-processor machines. IBM's recent T-FLOP 80-core processor was an early example of what is to come. In order to utilise this, programs will have to be written differently. parallelisation will become the watch-word. We will have to think in terms of tiny, interacting nuggets that can run in parallel, rather than monolithic, synchronous programs. I think will then help with the memory bottleneck, but I'll investigate this later.

Is Java so bad?

noreply@blogger.com (Temporal Stillness) — Tue, 17 Apr 2007 16:34:00 +0000

I'm back on the old java trail now, although it regularly feels more like a trial. Now, why is this? I used to really like this language. It was my weapon of choice!

Java is C on acid. C was ok, in it's day. It needed the Java treatment (although I understand that Objective C was already there long before). So there's that funny C-syntax. I'm not sure what might be better as a syntax, but I'm not alone thinking that Java often feels laboured.

Java has grown HUGE. Good god, has it grown!? Oak was it's original name, perhaps Ivy has become a more apt name? It's large and twisty with big hard API's born out of committies and focus groups. All pushed about by entities with hidden agendas (but we'll come to that).

Java is ill defined. Partly because of it's size, but also a couple of omissions and mistakes. Inner classes and anonymous classes are generally bad news. Threading became a nightmare (when half the API got depricated). Dates.. oh lord, don't get me started. There are all kinds of holes in J2EE, and then we get onto 3rd party libs.

Java is clearly a corporate technology. A large corporate owns it (whatever their protestations). Large corporates have the largest voices inside the JCP. The JCP itself seems to have the image of design-by-committie.

Java has a lot of 'frameworks'. J2EE is an easy target because it is a big network of frameworks. But also look at the 3rd party offerings. Mostly they're frameworks, often big, complex ones!

Java seems to breed spaghetti. I have no clue why this might be. I was recently on the sidelines of a large project that was a huge tight network of about a Gig of source. The current one is at risk of going the same way (evolution without strong refactoring exercises).

Don't get me wrong. Java is a useful tool that earns me my daily crust. It's not the worst and certainly better than most. It's relatively productive and generally easy to be expressive whilst using it. I guess I'm interested in how it might be improved upon. Thoughts?

4 P's

noreply@blogger.com (Temporal Stillness) — Mon, 08 Jan 2007 20:11:00 +0000

It occurred to me last night to characterise mechanical/electrical computer systems by 4 P's:
Purpose,
People,
Place,
Processes,
and an extra one: Processors although this is more of an implementational detail than a part of the character of a computer system.

I considered these aspects with reference to whether the system has one or many of each. So let's dig into the history a little as I remember it.

Computer systems started out as glorified calculators, code crackers. This was a single purpose. They were used by one person at a time who had to be present at the computer. They did only one task at a time and were in fact only a single processor (with little in the way of peripheral I/O). I think this is the simplest form of computer: each of the P's is singular.

Moving forward in history, there have been systems that have made some of these P's plural with varying levels of success. Mainframes allowed many purposes in many processes and many people. Desktop PC's seem to be a backwards step in many ways: they started off as general purpose, but limited to one process for one person. Then something changed. Desktop computing added multiple processes - badly at first, but slowly becoming much better. Multiple people has yet to be adopted in a complete way, but systems such as desktop Unix installations have done better than most. Also, the place factor has become much better supported. I find myself able to log into a limited set of computers that give me *basically* the same experience. I can even take my usual laptop to another location and have nearly the same experience. Infact, I can log into almost any computer and have access to some of my usual experience if I keep my pen-drive with me (having said that, I am more experienced than most users and know how to use a range of different environments relatively effectively).

So what's next? Well, as I see it, someone somewhere will make good on Sun's promise that, 'the network is the computer', but also support times when the network is unavailable. This should make all of these P's plural in all cases. General purpose computing can be supported better with the introduction of byte-code compiled, interpreted environments. This could help make multiple processes safer too with strong sandboxing of processes against eachother. The operation of the system within the context of multiple people needs to be strongly addressed, especially when the system deals with multiple places, multiple processes and multiple processors. I have talked about security before, Unix systems appear to be the closest to what I have in mind.

In conclusion, I think it is possible to specify a system that could start along the path of pluralising these 4 or 5 P's. I think this would be a sensible next step in the evolution of computing history. Moreover, a focus on pluralising these P's should fix problems with current systems and add flexibility to the whole computing experience.

Kids Coding

noreply@blogger.com (Temporal Stillness) — Sun, 24 Sep 2006 09:36:00 +0000

I thought I'd blogged on this before, but it seems not (at least not here!)..

When I were a nipper, I had a book on BASIC for the Acorn (BBC). Actually I had 2 books. Both very similar books, both started with something like:

10 print "hello world"
20 goto 10

But both by page 20 had started relatively advanced data-types and had all the cool programming structures of the day (gosub, etc). Both introduced peeking and poking and had simplified schematics for the 6502 and the Z80. One went off into more complex data-driven programming and the other into creating a simpl robot driven through an RS232 port. These were books for 10yr olds. I have yet to see anything similar today.

Smalltalk is kinda close, but there's something I don't like about it. Too simplified, too direct, too scripty, too much like a toy. The literature I've seen was either too condescending or too adult... in all it's designed for the classroom, not for exploration alone.

So what next? If one was to write a book, what technology? Something real, so Java or .Net based. Something with either a framework (yuck) or set of libraries to make things easier. Something accessible to kids but also something very techie. Games programming? This would be very hard to get the balance right.

Computing Paradigm

noreply@blogger.com (Temporal Stillness) — Mon, 18 Sep 2006 11:16:00 +0000

In the last few entries, I have been inexpertly trying to describe something which could represent a new(ish) paradigm in computer interaction. I kind of symbiosis of personal computing and network computing.

I feel the word 'computing' is wrong here, but I will take it to represent all things related to the layman's interpretation of what 'computing' means. So: wordprocessing is computing, email is computing, blogging is computing, M$ vs Apple is computing, memory-sticks are computing. It's a very broad term to symbolise all the things you do with the box of tricks we call a computer (including laptops, PDA's, printers, broadband, etc etc).

Personal computing is what we do with a computer when we're not on the net. We word process, store documents, edit pictures, listen to MP3's, play games (against the computer), use spreadsheets. Basically, the 1980's view of the IBM PC. It was stand-alone, operated by one person, smaller amounts of processing power, but given over to an individual.

Network computing is email, IM, surfing, blogging, VNC/WTS, SMB/file sharing. It is viewed as the modern multiple-user space where we share stuff with eachother. More than that, we share with ourselves too! It means you can have access to your personal space from anywhere in the world (for example you may keep an inbox with web-mail in it). The last thing is important - it talks about having the same information and interface available to you wherever you log into a computer. Security here is an issue, of course, but there is intrinsic value in having familiarity of interface and data.

Now, to combine the two means that personal computing should become more networky and network computing should become more personal. Some bits of technology are getting there (MySpace, MSN, Yahoo and Google have offerings that start to come close). But what I see is a method by which information and interface associated with an individual is all available from everywhere. Furthermore that information is (where appropriate) accessible regardless of where it resides. So, if I log into my computer at work, I have access to all the relevant stuff for me - personal and work related. I have access using an interface which is associated with me (why should I need to learn a new interface because my new employer decides we will all use M$ Windows 2023 with the Wibble skin and the Blahsoft document mgt system?). The same should be true when I login from home, or in an internet cafe, or wherever. Home servers should connect to intrenet-based servers and work servers seamlessly. Security would have to be cooler than cool, of course, but I'm positive that all of this is fundamentally possible.

What are computers for?

noreply@blogger.com (Temporal Stillness) — Sat, 19 Aug 2006 07:12:00 +0000

What do we use computers for then? I mean, these things are simply tools, so what's their 'thing'? Like, if you want to knock a nail in, you get a hammer. Drill a hole, the clue's in the title. But for computers it seems we focus on the wrong end - we look at the tool and say, 'what job can we do with that?'. Originally they were used, as the name suggests, for computing things - oversized calculators, basically. But now the useage profile of this tool is somewhat more fluffy. So, here are some of my thoughts on the aspects of what job computers are for (so far).

Information is clearly a big thing for computers. Information means any data that has meaning. Computers are the tools we have for manipulating information. Using computers we store it, retrieve it, edit it, perform automatic operations with it and share it around.

Perhaps it's a bit of a stretch to call that list exhaustive - I have two chat windows open right now and they fit, but only very badly into the list above. Video and voice are even more of a stretch.

However, I think this enumeration is useful to me when thinking about a holistic computer system.

Joined nodes

noreply@blogger.com (Temporal Stillness) — Mon, 17 Jul 2006 16:36:00 +0000

Scenario, based on the high level concept of PI calculus:

Nodes are joined by Channels. I contrive my Node to send my Message (a request message, requiring a response) to the target Node via one of it's public Channels. It will reply with some response Message.

Now, if I know what I want, but don't know or care where it's from, I will get my Node to go find a service Node that can answer me.

I can do this as a higher level layer over something like Java, TCP/IP, XML, etc and get something out quicker.

Objects, Types, Messages, Channels and Nodes

noreply@blogger.com (Temporal Stillness) — Fri, 14 Jul 2006 19:07:00 +0000

The thinking is like this:
Object - basic nugget of structure
Type - the introspection into an object (meta-object perhaps) says what Messages an Object recognises.
Message - a 'prod' to an object
Channel - a route for a message to get to an object
Node - martialling for messages and channels, container of objects, security

As a base for a programming language, there's too much stuff here for my liking! Also, what comes first? What's the basis of the language? Objects are the popular choice of course, but you need the other stuff.. I guess we haven't even started with any basic Types yet either, like String, Numbers, etc..

hmm..

Code is Data is Code

noreply@blogger.com (Temporal Stillness) — Sat, 22 Apr 2006 05:58:00 +0000

Last night I had a rather confused and confusing conversation with Bayard (http://blog.generationjava.com/roller/page/bayard/) regarding Code being Data and vice versa. We came to a general conclusion that it was best discussed over a beer. Still, since I opened the discussion I thought I should blog on it.

Code being Data is clear - have a look at your source files. They're structured and have meaning to the programmer.
The converse is slightly more tricky. Data (as input) is invariably interpreted by some computer process. It is a set of instructions to some process about how to proceed. Let's say we have a relational DB table called house. A house might have a number of bedrooms. The program which displays this data will make some decisions on the basis of number of bedrooms, e.g. instead of displaying "bedrooms: 0" it might say "No Bedrooms". Another clear(ish) example is in system parameters - often held in a data structure (DB table again, XML file, CSV, etc) but these clearly influence the operation of the 'interpreter' or the code.

Calling this distinction between code and data can be useful, but I believe it's an artificial boundary that can cause confusion. Where does business knowledge end and coding start?

Intrinsic environmental security

noreply@blogger.com (Temporal Stillness) — Fri, 10 Feb 2006 16:05:00 +0000

In a unix filesystem there is security on access to files and directories. This is based on rights for a user, group and world and there are read, write and execute access control for each. This works well for disk-based operating systems. A rogue process would have to be explicitly run by a particular user to have access to a particular file - for example a system configuration file requires root access.

Windows is generally less secure because file permissions aren't set in the same way (NT and XP have made some concessions to re-implementing this).

My intention is to extend this with reference to my previous post about an environment where data is held within the structure of the program. There is no file system in this situation. Access would need to be checked at runtime within the context of a thread (similar to processes being run by a particular user).

It could be checked on each function call, I don't have to say that this would have a *bit* of an overhead. Either we could accept the processor hit, or loosen the security somehow. We could make some calls unchecked, or grouping security around packages or create an override, for example the thread has been allowed to call function X, function X has stricter security than any functions it calls so no need to check security. The possibility of automating the last one here is clear.

Computer Environment

noreply@blogger.com (Temporal Stillness) — Mon, 16 Jan 2006 19:36:00 +0000

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?

Apache Harmony

noreply@blogger.com (Temporal Stillness) — Tue, 10 Jan 2006 15:35:00 +0000

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.

VM server-side

noreply@blogger.com (Temporal Stillness) — Tue, 10 Jan 2006 13:54:00 +0000

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.

My world

noreply@blogger.com (Temporal Stillness) — Tue, 10 Jan 2006 12:18:00 +0000

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.