Python Programming, news on the Voidspace Python Projects and all things techie.
The Python Magazine
There is a new Python publication that has just been announced: PyMag.
This is a monthly hardcopy (!) magazine dedicated to Python. The editor is Brian K. Jones (you can read more about the mag on his blog) and it is from a publisher in Toronto called Marco Tabini & Associates.
The first issue will arrive in October and I know they have some good articles planned. Of course if you're interested in writing for them, they want to hear from you.
More good news in the Python world.
Apple's Super Secret iPod Compression Algorithm
Ok, so a while back I finally succumbed and bought an iPod. I was dubious as to whether I would actually use it, or would it become just another toy amongst my collection of expensive but unneeded gadgets. As it happens it drastically lightens my daily commute and I wouldn't be without it.
Another thing I was doubtful of, was whether the 30gigabytes capacity would be sufficient to contain my massive music collection.
Fortunately Apple must have been working on their super-secret compression algorithms. My iPod stores my 937,756,027.61 GB of music, with over 20gigabytes to spare...
Viruses: a Thing of the Past...
Unfortunately also a thing of the present, but whilst randomly browsing Voidspace I stumbled across this blog entry of mine from 2003. It is an interesting blast from the past about an interesting blast from the past, and still relevant. The BBC article it talks about is also still available:
This article 'celebrates' the twentieth birthday of computer viruses... As usual for a mainstream news article it's partly right... It misses out the entire spectrum of boot sector viruses - particularly the ones that plagued machine like the Amiga, long before the advent of the internet.
Before harddrives were common (at least for your average user) a small piece of code called the 'boot sector' used to be executed whenever you booted up from a floppy disk. The virus writers used to hide viruses here (often malicious ones). The Amiga scene particularly was rife with pirate software so disks used to get swapped around all the time - and if you didn't have a good virus killer it was inevitable you would have live examples of several viruses in your collection. There was also a thriving freeware/shareware scene (well before the term Open Source had been dreamed up) - so there were plenty of virus killers too.
The most disturbing thing now is that the virus and trojan writers have teamed up with the spam merchants and the viagra peddlers to make money from viruses. They use the infected machines as proxy servers - either for the e-mail they force upon thousands of us - or to obscure the location of their fraudulent websites. Particularly the software that obscures the real location of websites is impressive - but none the less unpleasant and a nuisance for its innovation. The trouble is that the extra strain that spam puts on the infrastructure of the net threatens to make life more difficult for those of us who just use it for less morally repugnant uses. Mind you... we could get into another debate about the morals of file sharing (a subject dear to my heart - but at best morally dubious unless you embrace some kind of philosophical software communism... 'information wants to be free')...
Even more of a thorny issue are the kind of networks (like freenet ?) that allow people to store and share files across a distributed, encrypted network. If you open up part of your hard drive to a network like this it's impossible to tell what files are actually being stored there, or who uploaded them. For political dissidents in China - or under other oppressive regimes - this is a boon. They can safely distribute material which would otherwise be banned and traceable to them. It's also a boon to the distributors of such vile material of child pornography, which unfortunately the internet is rife with...
As usual there are plenty of 'grey' areas, and everyone draws the boundaries differently. As soon as a method to circumvent oppressive laws is discovered - it's abused by criminals. As soon as methods of restricting abuse are found - they're used to infringe upon the 'fair use' of people with no criminal intent. It's probably another of those issues to which there are no right or straightforward answers, and it has to be a constant striving to pick out a middle path between competing and irreconcilable needs.
So this article has stood the test of three years, which is probably more than can be said for plenty of my recent blog entries. In fact if you search the web, you can still find references to my earliest contributions to the computer scene, in the form of Amiga Compilations for use with AMOS. AMOS was a version of BASIC that could make Operating System calls, and my second programming language (immediately after BBC Basic and before 68000 assembly language).
That all reminds me that although floppy disks were always a pain, they seemed so much more reliable then than they are today. I had boxes of hundreds of them, and failures were only occasional. Of the last few times I've had to resort to floppies, it has almost inevitably resulted in failure. My boss thinks that they the drives and disks are just manufactured so much more cheaply these days. He is probably right.
It also gets me thinking about programming and posterity. For those of us who devote our time to programming, we are pouring our substance into an activity that will inevitably be obsoleted in a few years. How many programs from ten years ago are still in use? Some but not many, how many from twenty years ago, thirty...
Perhaps this doesn't matter though. What proportion of all the writing and text from thirty years ago is still relevant. Sure there is plenty, but as a proportion of everything our society churns out it is a tiny amount that endures in any meaningful way. Key concepts and algorithms from programming are likely to remain just as relevant (and 'timeless') as the key concepts from any other area of human endeavour.
C was one of the earliest programming languages and is still strong today, but will we even recognise programming in twenty years and what about Python? Well, even though programming languages come and go I don't think it is going to change fundamentally. Even though the means of interacting with computers will change (projectors, holograms, virtual reality), the written word (text) remains the most efficient way of conveying precise information - something vital to working with computers - and I don't think that is about to change.
I explored this subject a bit in my article An Object Shaped Future?. I think Object Oriented programming is effective because it is a good analogy for the way we think. Even if the hardware platform changes out of all recognition, Python provides a readable and flexible way of working with objects at a high level.
As processor performance becomes ever less relevant to programming, and code readability becomes more important to program maintenance, Python has a rosy future - so long as it finds its way in a multi-processor world. (Losing the GIL isn't necessarily the only way, fast interprocess communication could also work so long as it is easy and readable.)
Incidentally, I think this business of analogies is one reason why Python could be more enduring than Ruby. A good analogy makes it easier to 'think' in a system, because it corresponds well to your understanding of life the universe and everything. Python inherits its object model from the C++ strain of programming languages. Objects have attributes and methods.
Ruby inherits its object model from Smalltalk, where all interaction is 'sending messages'. You can't access an attribute of an object, you can only send a message to the object. I think that the Python model, although less 'pure' in object orientation terms (although Ruby is not as pure as Smalltalk in this sense), is easier to understand and closer to the way we view the world - it is a better analogy. We can interact with objects by causing them to do things (calling methods), or interact with their attributes where the object itself is much more passively involved (I can look at the colour of a tomato without sending a message to the tomato itself).
Hardware and Software and Stuff
Whilst I'm on the subject of hardware, it's easy to forget that modern hardware is just software (except software that you usually can't fix). Take a look at this email from an OpenBSD mailing list:
It discusses the issue of serious (and in some cases unfixable) bugs in the Intel Core 2 Duo line of processors. There is a nice (but scary) visual summary of some of these bugs... Ouch I'm glad I don't program at this level...
Amidst all the iPhone excitement, there is also some news on the OpenMoko Project. OpenMoko is a mobile phone device, with an open hardware and software platform.
My phone contract runs out in September, and although an iPhone without 3G isn't very tempting there are rumours of a 3G version for Europe. By then the OpenMoko will also available for sale, with pretty tempting specs (and a similar price point but without the noose of a contract):
Neo Advanced -- everything the mobile device hacker wants to get down and dirty with the first freed phone, the Neo 1973:
- Neo 1973 (GTA01B_v4)
- Battery (2x)
- AC Charger
- Phone Pouch
- SanDisk 512MB MicroSD Card (2x)
- Mini USB Connectivity Cable (2x)
- USB Host Mode Cable
- Debug Flex Cable
- Debug Board v2 (JTAG and serial console)
- Ruggedized Toolbox with shoulder strap
- Guitar Pick (for opening case)
- Torx T6 screwdriver
GTA02 (AKA: The Mass Market Neo 1973) is on schedule to go on sale in October. It will have the following new hardware components:
- 802.11 b/g WiFi
- Samsung 2442 SoC
- SMedia 3362 Graphics Accelerator
- 2 3D Accelerometers
- 256MB Flash
You can see a spec comparison of OpenMoko and the iPhone: OpenMoko/iPhone.
Enough of the hardware news. Hot on the heels of CarbonPython (a Python compiler for .NET) comes an update to ShedSkin. ShedSkin can also compile a static subset of Python (using type-inferencing) - to C++. The latest version can compile extension modules for Python. It looks very easy to use. When compiled as an extension module you can pass the basic Python data-types in and out (they are copied 'across the border'), and potentially offers a massive speed boost for CPython. It would be very interesting to see some benchmarks.
Oh, and another thing. I had a USB harddrive in ext3 format (a Linux filesystem) that I wanted to copy everything off and reformat. I tried various things, but the program that finally worked for me was explore2fs.
Last but not least, Resolver is close to a launch. In two weeks time two of the directors will be talking at a conference about Resolver, the website will go live and I will be allowed to tell you what it is I've been working on for the last year or so! I even have a website ready for the moment, but after all this waiting it turns out that I will be away on the day that it happens. You might have to wait a couple of extra days.
At some point after that (hopefully not too long), we will extend our private beta and you will have a chance to play with Resolver yourself. It is still in beta, but already capable of some interesting stuff.
There is also various stuff I'm not supposed to talk about: an exciting new Mozilla project, a new Python publication and I have a couple of speaking engagements that I'm waiting for confirmation on. All exciting stuff.
Back in January I reported a problem I had with a Western Digital SATA WD3200KS 320gig Hard Drive. My Windows box would report an I/O Device Error (followed by the dreaded 'Delayed Write Failure') after a few minutes of use, and shut the drive down. One of my readers thought that it was the Nvidia SATA drivers that were to blame, but by then I had switched the drive into an external (USB) box where it worked fine.
This week I bought an additional drive, and didn't have the right power connectors to fit it inside my puter - so I decided to try swapping the 320gig back into the computer. Same problem again, and this time I did a bit more digging.
Just for the record, it turns out that the problem is caused by XP mistakenly enabling 'NCQ' (queueing commands) . (See post #13 on this nvidia forum). The fix is:
My Computer -> Properties -> Hardware -> Device Manager Expand +IDE ATA/ATAPI controllers Select NVIDIA MCP55 Serial ATA Controller Right click and select properties
In my case I have two NVIDIA MCP55 SATA Controllers, so you need to find the one with the offending drive.
Under the Primary Channel or Secondary Channel you will see 'Master Drive' listed with Transfer Mode (Serial ATA Generation 2-3G) and 4 checkboxes:
X - Let BIOS select transfer mode X - Enable read caching X - Enable write caching X - Enable command queuing
Uncheck the command queuing option and reboot, and all will be well...
This work is licensed under a Creative Commons Attribution-Share Alike 2.0 License.