Saturday 16 January 2016

GET OVER IT

Dick Pountain/ Idealog 254/11 September 2015 11:39

If you reach my advanced age you'll discover that there are some irritants it's best to learn to live with because they're too much trouble to fix. For me two such irritants are Facebook and Microsoft Windows. What high hopes we had for Facebook when it first launched in the UK: we hoped it would replace the increasingly cranky Cix as the place where we Real Worlders could meet and exchange copy, but it hasn't worked out that way. (To be sure we do maintain a group on FB, but it's mostly confined to simple announcements and no copy gets posted there).

Facebook turned out to be less like a senior common room and more like a bustling, screeching market-square that drowns out all serious intent. It has the almost magical property of instantly turning everyone who enters into a moraliser or preener rather than an information provider: "look how well I'm doing", "I defy you not to weep over this baby dolphin/kitten/meerkat", "how dare you <blah> this <blah>", "how many <blahs> have *you* <blahed>?"). A conduit for outrage and opinion rather than fact, as you can see for yourself by contrasting the tone of FB comments with those on any proper tech forum: the Greek philosophers would have said it's all about doxa (belief) rather than episteme (knowledge).

Many's the time over the past years that my finger hovered over the "Delete account" button, but that impulse passed once I discovered how to switch people's feeds off without offending them by defriending (despite FB constantly changing the way you do it, as a deterrent). I now have friends running into three figures but see only two figures-worth of posts. And recently I realised that FB makes a great "doxometer": post some nascent column idea and see how much flak it attracts (the more the better). When I recently mentioned that my Windows 8.1 indexing service had run wild and filled up my entire 500GB hard disk, I received mostly Harry Enfield style "that's not how you do it" point-scoring (having already fixed the problem using real advice gleaned from tech forums). Ditto when I posted, ironically, that what I'm hearing about the Windows 10 upgrade process is turning me into an IT "anti-vaxer". And so on to the second irritant I've learned to live with, Windows 8.1.

To look at my desktop now you'd never even guess I'm running it. The tiles are gone along with all those hooky apps. My desktop is plastered with (highly-deprecated) icons, some pointing to folders full of vital utilities, while the tools I use most are all on the taskbar, Mac style. Neither you nor I would ever know this isn't Windows 7, and it works well enough to forget about (until a minor hiccup like that full disk). Automatic updates are turned off and I pick which ones to install manually from time to time, so haven't yet had 10 stuffed onto me. Will I eventually upgrade to 10? Haven't decided. Anti-vaxer jokes aside, I worry my Lenovo is old enough (2013) to be in the danger-zone for driver SNAFUs, but also a recent article on The Register (http://www.theregister.co.uk/2015/07/31/rising_and_ongoing_cost_of_windows/) makes me wonder whether Windows 10 is intended to tie us into an Adobe-style monthly subscription, software-as-service model whereby I lose control over future upgrades.

If that does prove to be the case I'll definitely defect, not to a Mac as so often recommended by kind friends on Facebook, but to some variety of Linux. You see, I've also come to understand that I actually *enjoy* wrestling with operating systems: it's a far more fun way to keep my mental muscles exercised than solving word puzzles on a Nintendo Gameboy, in a Pringle cardigan, on the sofa. I don't object to paying for software per se - I paid for Windows 8.1 in the original cost of my Lenovo - but what I do oppose is the ongoing campaign by big software vendors to extend their monopoly status by extracting a rental, rather than sale, price from their customers. This tendency toward rent-seeking runs a counter to an opposite tendency of networked digital technologies to make software ever cheaper, even free, and thereby reduce profits (which are needed to pay for R&D, not only to distribute to shareholders). We're getting into quite profound questions here, recently the subject of Paul Mason's intriguing book "Postcapitalism" which I'm currently reading. Mason believes, as do I, that the fact that digital products can be copied effectively for free tends to undermine the ability to set rational prices which lies at the heart of current market economics. But that, illuminated by the madness that is MadBid, are a subject for next month's column...


TEN COMMANDMENTS OF SAFETY

Dick Pountain/Idealog 253/06 August 2015 14:58

Perhaps you were as disturbed as I was by that report, back in May, that a US hacker travelling on a Boeing airliner claimed to have penetrate its flight control system via the entertainment system's Wi-Fi, and made the plane climb and turn from his laptop. Aviation experts have since rubbished his claim (but then Mandy Rice Davies would definitely apply). It did however concentrate my mind, in a most unwelcome fashion, on the fact that all the planes we fly in nowadays employ fly-by-wire under software-control, and that my confidence in software engineers falls some way short of my confidence in mechanical engineers.

This nagging anxiety was rubbed in further by the fatal crash of a military Airbus A400M in July, after its engine control software shut down three of its four engines just after take-off. It appears that accidental erasure of some config files during installation had deprived the software of certain torque calibration parameters that it needed to monitor engine power. These (literally) vital numbers were being loaded from an external file, so in other words the safety of this aircraft was being governed by a programming practice on a par with installing Windows updates. Nice.

To me safety-critical software is about more than just fear for my own ass: it's been of concern for many years. I started out as a Forth programmer, at a time when that language was widely used in embedded control systems, and attended conferences on the subject of safety in both software and hardware architecture. Then I graduated, via Pascal and Modula-2, to becoming an admirer of Nikolaus Wirth's ideas on good programming practice, and finally on to object-oriented programming as the way to wrest control over the structure of really large programs. Object-orientation is now of course the rule, supported by every language from Javascript to Scratch, but I sometimes wonder whether it still means anything very much, or has it become a mere style to which lip-service is paid. Loading critical data from unreliable external files violates the principles of encapsulation in more ways than I can count.

I did a bit of Googling and found lots of papers about safety-critical architectures and redundant hardware systems. Redundancy is a key safety concept: you build three separate computers, with CPUs from different manufacturers running different software written by different teams - which have been demonstrated to produce the same outputs from the same inputs - then go with the majority verdict, the idea being that the *same* software or hardware bug is very, very unlikely to arise in all three. Interestingly enough, the latest of these papers seemed to be dated around 2008.

Surely it can't be that, as in so many other spheres (like, say, banking) the optimists have taken over the farm and started trusting too much? Then I stumbled across NASA's 10 rules for developing safety critical code. Now NASA tends to work with computer hardware that's several decades behind state-of-the-art but - give or take a Hubble or two - it's had fairly few disasters that were down to software. Here are its rules, severely abbreviated by me:

1: All code to have simple control flow constructs: no GOTO, direct or indirect recursion.
2: All loops to have a fixed upper bound, which can be statically proved never to be exceeded.
3: No dynamic memory allocation after initialization.
4: No function longer than 60 lines of code.
5: The assertion density of the code to average a minimum of two assertions per function.
6: Data objects must be declared at the smallest possible level of scope.
7: Calling functions must check non-void function return values and the validity of all parameters.
8: Preprocessor to be restricted to headers and simple macros. Token pasting, variable argument lists (ellipses) and recursive macro calls all forbidden.
9: Pointers to be restricted to one level of dereferencing, which mustn't be hidden inside macros or typedefs. Function pointers forbidden.
10: All code must be compiled with all warnings enabled at their most pedantic setting. All code must compile at these settings without any warnings. All code to be checked daily with at least one — preferably several — state-of-the-art static source code analyzer, and pass with zero warnings.

These rules are, realistically enough, aimed at plain old C programmers, not at trendy new languages, but they impose a degree of rigour comparable to most object-oriented languages. Their recommended heavy use of Assertions is interesting. Assertions are supported directly in Eiffel, Ada and some other languages, and can be added to C via the header "assert.h". They can specify the desired value range of some variable at some point in program execution and raise a runtime error when not met: an example might be "assert( TorqueCalibrationParameter > 0)".

SOCIAL UNEASE

Dick Pountain /Idealog 350/ 07 Sep 2023 10:58 Ten years ago this column might have listed a handful of online apps that assist my everyday...