The "I discovered a new software architecture" syndrome

I've started to notice a trend in software architecture articles.

The article generally goes something like this: "I redesigned my software system using architecture X, and my software is sooooo much better, therefore architecture X is the way forward".

X is normally some variation on an object-orientated design pattern.

Now, I have nothing against this - X is generally a decent design pattern and I'm sure the engineer in question improved his/her software.

But something nags at me......

If you have a large crufty codebase, and you make small incremental changes, things may improve, but lots of cruft is left behind.

However, if you make a fairly large re-organisation to your codebase __and__ you understand your codebase very well, you will __inevitably__ improve your code.

This is because once you have achieved a deep understanding of your own code, once you start a re-organisation, all sorts of things tend to fall into place, and you generally manage to clean up lots and lots of dank, musty corners in the process.

This, I submit, accounts for a large chunk of the improvement in the code. Which is not a bad thing.

It just means that we need to be careful not ascribe too much of the benefit to the architecture and become zealots for that cause.

The next generation of operating system security

It should be obvious by now that users are not going to stop clicking on random links to things and/or downloading stuff to run on their PCs.

Anybody pretending that "user education" will prevent the explosion in compromised PCs is just living in a dream world.

Automated testing tools will help with the software produced by some of the bigger players, but the spammers are learning to target less well-known software - witness the recent trojan that hid inside a mod file for a game.

And yet, there is a well-known mitigation technique that is employed by most of the major server programs today, and it's time that technique made its way into the average users' desktop world.

That technique is sandboxing and privilege de-escalation. Server programs do this either by deliberately dropping certain system privileges as soon as they start up, or by creating limited-rights user accounts.

This means that even a successful attack can achieve only a limited amount of damage.

Internet Explorer 6 on Vista uses this technique and calls it "Protected Mode".

I hope this is part of a larger plan to extend this protection to all application programs.

Most application programs do not need very much privilege. It should be possible to mark programs as running in a sandbox, and then applying a privilege filter to program's running process.
This could take the form of additional ACLs stored as extended file attributes with the executable.

For older programs, a look-up database could provide ACLs to extend the initial range of protection.

Improving the quality of Apple/Microsoft Windows Programs

After another frustrating experience installing a laptop for a friend
(a clean, up-to-date laptop which managed to freeze itself within a day of purchase),
I thought to myself "why are these programs so lousy?"

It's not like the core OS is that bad. It's not wonderful, but it's pretty decent most of the time.

But so many of the surrounding programs that have to be installed are of very dubious quality.

So here's my big idea:


Apple/Microsoft should create an automated test facility for windows software


(*) Create a website where an application developer can create an account, and upload his software to the website for automated testing

(*) the automated testing should run the the software on various platforms, with as much debugging and sanity-checking as possible turned on. i.e. use debugging versions of windows, with seriously anal checking of all system calls

(*) the tester should verify that the application follows best practices i.e. not installing junk in the wrong places, uninstalling cleanly, etc, etc.

(*) the tester should allow the developer to upload "test sequence files" from popular automated GUI testing tools. It should verify that at least 80% code coverage is achieved.

(*) the tester should fuzz files and GUI inputs and verify that the application fails cleanly

(*) the tester should randomly fail the various system calls that can fail and verify that the application handles it cleanly e.g. closing sockets unexpectedly, file system full, etc.

(*) Microsoft/Apple should mandate that in order for an OEM machine to achieve the "seal of approval", all software installed on that machine should have passed the tester.

In this going to cost them money? Of course. But if it leads to a better quality of software installed on the machine, it leads to a better user experience in general, and hence contributes to the success of that operating system.

Is this going to need some serious hardware and time to run? Of course, but if the website charges some small fees, and lets the developers choose how extensive the testing should be, it should easily possible to achieve < 24 hours turnaround time.

In these days of multi-core, multi-CPU machines, with vast amounts of memory, and nice handy virtual machines to run testing under, this kind of thing is not difficult to implement, it just requires a significant investment (which, compared to how much money Microsoft/Apple spends dealing with customer complaints is probably not that big a deal.)

Java Threads Rule!

OK, maybe they have a few hassles. But compared to the various high-falutin' alternatives (co-routines, continuations, etc) they are reasonably easy to think about and reasonably easy to use.
I don't see that most of the alternatives get around the really fundamental problems anyhow - race conditions, lock-ordering, etc.

The hassles with java threads are primarily:

(1) objects should not have been synchronizable by default - there should have been an explicit "lock" primitive datatype.
That would have reduced object overhead and make locking a much more explicit thing, which can only be good, given how hard it is to get right.

(2) methods should not have been synchronizable - it effectively exposes part of the internal workings of the class in the interface.

The rest of the java threading model, especially with the 1.5 memory model and java.util.concurrent package, is actually pretty sane and easy to use.

When it comes to scaling programs to multi-core machines, projects like Fortress and X10 are on to a much better idea - libraries that make coding highly data parallel algorithms easily.

The fundamental problem with a lot of the so-called solutions is the same as the myth of distributed objects - that you can make the use of parallelism "invisible".

Unfortunately, this just isn't so - good parallelism coding requires that you do some intelligent partitioning of your code and data, and the very explicitness of threads makes those choices obvious.