Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The world's first mobile phone virus "in the wild," dubbed Cabir, has migrated to the U.S. from its point of origin in the Philippines eight months ago, infecting phones in a dozen countries along the way. Experts say the mobile-phone virus threat will increase as virus-writers become more sophisticated and phones standardize technologies that will make it easier to for viruses to spread not just across devices, but the whole industry. Up until now, disparate technical standards have worked against fast-moving virus infiltration, but Cabir has now been found in countries ranging from the China to the U.K., spread via Bluetooth wireless technology. The biggest impact of the relatively innocuous virus is that it's designed to drain mobile phone batteries, says Finnish computer security expert Mikko Hypponnen. Last November, another virus known as "Skulls" was distributed to security firms as a so-called "proof-of-concept alert, but was not targeted at consumers. [Reuters/New York Times 21 Feb 2005; NewsScan Daily, 22 Feb 2005] http://www.nytimes.com/reuters/technology/tech-tech-security.html
Excellent points. Made elegantly by Doug McIlroy at the 1968 NATO Conference on Software Engineering and published in its proceedings (http://homepages.cs.ncl.ac.uk/brian.randell/NATO/) under the title "'Mass Produced' Software Components." Nothing new under the sun, as the prophet said. Jim H. http://virtualbumperstickers.blogspot.com/ Software components (routines), to be widely applicable to different machines and users, should be available in families arranged according to precision, robustness, generality and timespace performance. Existing sources of components - manufacturers, software houses, users' groups and algorithm collections - lack the breadth of interest or coherence of purpose to assemble more than one or two members of such families, yet software production in the large would be enormously helped by the availability of spectra of high quality routines, quite as mechanical design is abetted by the existence of families of structural shapes, screws or resistors. The talk will examine the kinds of variability necessary in software components, ways of producing useful inventories, types of components that are ripe for such standardization, and methods of instituting pilot production. The Software Industry is Not Industrialized. We undoubtedly produce software by backward techniques. We undoubtedly get the short end of the stick in confrontations with hardware people because they are the industrialists and we are the crofters. Software production today appears in the scale of industrialization somewhere below the more backward construction industries. I think its proper place is considerably higher, and would like to investigate the prospects for mass-production techniques in software. In the phrase 'mass production techniques,' my emphasis is on 'techniques' and not on mass production plain. Of course mass production, in the sense of limitless replication of a prototype, is trivial for software. But certain ideas from industrial technique I claim are relevant. The idea of subassemblies carries over directly and is well exploited. The idea of interchangeable parts corresponds roughly to our term 'modularity,' and is fitfully respected. The idea of machine tools has an analogue in assembly programs and compilers. Yet this fragile analogy is belied when we seek for analogues of other tangible symbols of mass production. There do not exist manufacturers of standard parts, much less catalogues of standard parts. One may not order parts to individual specifications of size, ruggedness, speed, capacity, precision or character set... [MDM] [We received a plethora comments on this, many of which follow. Although there is some repetitiveness, it perhaps amplifies points that need to be made, REPEATEDLY. PGN]
Although there are many benefits to software components, there are many risks as well. Many exploitable failures result from using the same component in many different applications. Consider the buffer overflow in the commonly-used JPEG decoding algorithm, for example. Or the innumerable different operating systems that are compromised because of a bug in a popular off-the-shelf component like SSH, SAMBA, or JPEG decoding. The problem — and the place where Dr. Robinson's analogy falls down, I think — is that software is a lot more complicated, in an algorithmic sense, than a pine board or a copper pipe or a steel spring. Even a widely-used software component that is believed to be reliable can have unidentified problems, and when you expand the definition of software components to large-scale systems with tens of thousands of lines of code (database managers are the most glaring example), you end up with lots of otherwise well-written software depending on buggy components.
Paul Robinson points at an interesting phenomena. I was, a long time ago, working for a large corporation. I was member of a working group to establish how we should document software properly. Some background: Every product was assigned a product number in the form "ABC 12345". Every document describing the product was assigned a standardised decimal number, for example "1551" was the description of the product. Thus the description of "ABC 12345" was labeled "1551-ABC 12345" What we discovered for software was, that we never had the product visible. For hardware you could produce X items and put them labelled on a shelf. That was impossible for software as the only visible item was a printout of the code, which had its own decimal number, or the code on paper tape (I told you this was a long time ago) which also had its own decimal number. Thus software was much more intangible than hardware. This makes it hard to describe a software component in a way that makes it easy to find it when you need it. This especially for real-time applications where timing was critical. I also had an interesting discussion with a project manager who wanted to hurry up the introduction of reusable software. I asked him what he meant by reusable code. I wasn't surprised that he couldn't define what he asked for. This was the time when OO started to come into fashion. For a critical real-time application you had to know the response time. The black box philosophy of OO doesn't work here. Paul Robinson mentions the development from machine code, through assembler to higher level languages. He then think that OO were the next step in the development because that is when the hyperbole of reusability became in fashion. If we are to use an engineering approach to reusability, it is called experience. An experienced engineer reuses his/her knowledge to create a new product. What OO has done to the development of software engineering is devastating. Instead of continue to develop more advanced languages we got stuck with half-assembler languages like C and followers. A compiler for a high level language (re-)uses code templates. A compiler for a more advanced language could reuse even larger chunks of code, without any need for a programmer to try to find the code in a catalog. To my disappointment, I have seen very little progress during the last two decades in the field of software development. The ever increasing speed of the processors and the cheap memory prices has more encouraged fast hacking than a systematic development based on sound engineering principles.
PGN and others have been working on this for some time. The problems are
substantial - in particular in specifying interfaces and properties of
components and forming mathematics required for producing properties of
composites from the properties of their components and the topology of their
composition. Unfortunately inadequate funding is behind this work and too
few researchers are persuing it. The few agencies that fund that sort of
thing are also funding few real innovators. But like I said - Peter is
working on it... so there is always hope.
Fred Cohen: http://all.net/ fred.cohen at all.net tel/fax: 925-454-0171
[Fred, Many thanks for the kind words. See
http://www.csl.sri.com/neumann/chats4.pdf
http://www.csl.sri.com/neumann/chats4.html
But that report is just a beginning of an ongoing struggle, seemingly
tilting at the same windmills for a long time. PGN]
Aren't reusable software components great? Why doesn't anyone use them? Well, Paul: they're much more common than you think. I build a lot of open source and otherwise free software programs. *Lots* of them make use of reusable code components, most notably PHP's PEAR repository, and the older code repository from which it is still learning lessons: perl.org's CPAN — the Comprehensive Perl Archive Network. And comprehensive it is: CPAN has modules for damn near everything you might need to to in writing a perl program. And the code is pretty decent, too. But here's the rub: it's not free (as in labor). Even if you depend on code that someone else wrote to do a job, *someone still had to write that code*. And maintain it. And, most importantly, *know how to write reusable modules well*. It's not all that easy. If you choose poorly the modules written by other people upon which you decide to depend, you (or your users) may find yourselves in Dependency Hell, when you either end up on the pointy end of a cyclic dependency graph between 3 or more of your subordinate modules (A and B both depend on C, but A requires C v2.1 or newer, and B won't work if C is newer than v1.9), or (the degenerate case of that) C gets upgraded before A, and A won't work with the new version — because the writer of C wasn't careful enough about reverse compatibility. So, using reusable components doesn't necessarily reduce the amount of work you're going to put into a project — sometimes it merely redistributes that work from coders to librarians and testers. The RISK? Not looking deeply enough to find all the RISKS. As it happens, CPAN, in particular, meets many of the requirements Paul places on reusable components: it has a *very* nice test-harnessing system built into it (though tracking down why tests *break* may be problematic for end-users). And, of course, it's an interpretive language at heart, so it's end-sites that have to *do* that tracking. But still, there are many good lessons learned from looking at where CPAN is and how it got there; I wouldn't want anyone to think I was putting it down. Jay R. Ashworth, Ashworth & Associates, St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 jra@baylink.com
> If you have small components that you know are right, and you then combine > those components to manipulate each other according to their published > interface specifications, the results should be consistently correct. The > results will be predictable, the usage will be consistent every time. This is false. The results will not necessarily be correct at all. "Know are right" is not possible except in very specific and controlled contexts. When components are used in new situations, any existing assumptions cannot be relied on at all, without tedious and careful work to reestablish them. Software components are not physical components. They do not scale the same way. That the software industry does not offer the same reliability and quality as physically engineered products is not because software practitioners are pulling at fast one (although they often are, but for different reasons). They don't offer the same guarantees, not because they don't want to, but because they cannot. Getting software right is hard. Very hard. So hard that even really really smart people are not willing to be on the hook for it. Customers have to tolerate software with mistakes, because that is the only way they can get affordable software at all. If they insisted on the same guarantees, they wouldn't be able to pay for it. Yes, we need to make better software. We need to try. Things can be improved. They must be. The current situation is not acceptable. But it is not easy. Humans don't seem to be good at it.
It's actually worse than you say. Nobody delivers programs without serious defects built in, bugs as we say. All programs come with modes which confuse their users and cause them to commit errors. All operating systems which support applications do so by providing mechanisms to switch between those applications. The applications are separate and again constitute major modes where gestures are interpreted differently. This means that users must learn each application from the beginning. Even text entry, which virtually every application uses, may differ between applications in many ways which cause more confusions and more frustrations. But help is on the way. There is exactly one university level text which addresses these matters in a systematic way. The book is "The Humane Interface" by Jef Raskin. He is, incidentally, the creator of the Macintosh project at Apple. He also led the creation of the Canon Cat almost two decades ago. In 1987, the Cat provided a consistent system which had only two modes: programming and using. Most folks used only the latter. Twenty thousand of these machines were sold and NO USER EVER REPORTED A BUG! Be that as it may, why should anyone care? Because he's doing it again. In a little while, you will be able to download Archy from the Raskin Center for Humane Interfaces. Archy has bugs now and will still have some when the Alpha release occurs, soon. The Raskin Center will try very hard to have none left by the time the general release occurs, many months later. You all are invited to help accomplish that difficult but desirable goal. Archy provides a thorough text handling facility which does not require use of a mouse and does not require documents to be named or filed in folders. Instead of separate applications, Archy accepts collections of commands. Once accepted, every command is available all the time. Such clumsy devices as modal dialog boxes are rigorously avoided in favor of more humane means to accomplish those ends. Archy is the pronunciation of RCHI and you can find more information about the system and its philosophy at RaskinCenter.org at your leisure.
Paul Robinson wrote a lengthy essay asking that we stop building custom
software and start assembling it from components.
This is nothing new, of course. People have been calling for
component-based software for decades. The usual analogy isn't a
peanut-butter sandwich, but rather the electrical components, especially
ICs, used to build the computers themselves.
Of course, the problem with this suggestion is that (as far as I know)
nobody has been able to tell us exactly what components are needed or how we
are going to interconnect them.
Unix made a pretty good start with the pipe model; I have built some very
complex applications by combining these basic utilities. Unfortunately, we
haven't succeeded in moving beyond the model; in fact, I've observed that
many younger Windows-trained programmers have begun to forget the lessons
and have stopped writing "pipeable" utilities.
To be fair, we actually have made quite a bit of progress. I don't write in
assembly language any more, and I use extensive libraries to build my
software. Some of those libraries, though complex, provide very powerful
components (e.g., text-entry windows with scrollbars). But compared to the
complexity of what we are building, even these components are akin to
7400-series TTL. (And if you look at the systems that were built with early
7400 gates, I think you'll find much the same "build everything from
scratch" approach--30 years ago were still creating flip-flops by
cross-connecting two NAND gates.)
The other factor is that the deceptively low materials cost of software
development--anybody with a computer can get into the field--misleads us
into thinking we are qualified to build a large system. Building the first
breadboard of a large electronic system would cost thousands or even tens of
thousands in parts and labor; that encouraged caution and kept costs down.
Building the first prototype of a software system requires only the time of
the coder(s), encouraging much larger designs.
In other words, the problem isn't a lack of components, it's that we're
building much larger systems in relation to the power of those components.
The software equivalent of a PB&J sandwich is easy and much more powerful:
ls -l | grep -v '^d' | awk '{total+=$5}END{print total}'
Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/
The problem with analogies is that they never work. An architect makes a few assumptions: that owner will not move the house and put it down on a bed of quicksand, that surrounding houses will not swell up and lean on his work from all sides. (Some of his assumptions may later prove unwarranted, like that builder won't use substandard materials or that owner won't try to turn the attic into indoor pool, but that's another story.) Software developers cannot even assume that user's Pentium will return 4 for 8/2. Not to mention "unforeseen interactions between components in a complex system" — since they are "unforeseen" we can't foresee them, and if we can't foresee them, all bets are off. There was an article in an earlier RISKS issue that proposed exactly that: "all bets are off", or "fault-oblivious" programming — that's basically what happens if I make the same kind of assumptions in my work as architect does in his. Attractive as it sounds, in real life the result is hordes of angry users demanding that I fix my stuff YESTERDAY! (or else I don't get paid). Did I mention users? People who don't read the fine manuals? A screwdriver is only guaranteed for life if you don't use it as a cold chisel. Otherwise the handle *will* break and they most likely *won't* replace it on warranty. Unfortunately, software is not nearly as simple as a screwdriver and to find out what it can and cannot do you need to read a few dozen pages of (usually) mind-numbingly boring manual. In spite of Apple Microsoft advertisements that's been telling you "all you need to do is just point and click" for decades. > But in general, this is not how we are designing software. Because in real life they aren't. Because in real life partitioning into smaller and smaller components comes with efficiency overhead that nobody wants. Because other people's components will only work for you if those people's domain model is sufficiently close to yours — otherwise they are be too generic to be of any use to anybody, all they are is overhead. And so on and so forth. Sad, but true.
I agree with Paul Robinson that the software industry could do better. You only have to look at recent spectacular failures in computer based systems to confirm this (e.g. Ariane V and the (UK) Child Support Agency). However, I don't think his article tells the whole story. As any reader of RISKS knows, software is very different from any other product - so any comparisons should be treated with extreme caution. Software is not constrained by the laws of nature (until or unless it comes to controlling a real system) - consider the recent Matrix trilogy of films. Thus while traditional manufacture is bounded by well-established physical parameters which lend themselves to repeatable solutions, requirements for software systems are not so bounded. This tends to mean that the requirements for each system are unique. And because of the perception that software can do anything, the requirements tend to be complex too: arguably excessively so. Working this down into the details of implementation, this means that the components needed tend to be unique for each system - thus limiting the possibilities of reuse. The problem is not helped by the perception that software is "easy to change". (I suspect this is because software production does not involve making physical artifacts in the normal way.) As a result, late changes to system requirements tend to get implemented in software, where the far more reliable solution may be to make a small adjustment to the hardware. This usually means "tweaks" throughout the system, bypassing the usual design processes. This can mean that the resulting product is not amenable to reuse - either because the developer did not have time to make the change "properly" or because the associated documentation was not updated in line with the software itself. Reuse is not always a good thing, either - witness Ariane V, for example. However, I don't think it is fair to claim (nearly) zero reuse within the software industry. On several projects which I am aware of (in the safety critical field) the developers have bent over backwards to reuse legacy code in order to reduce development costs - usually with much more success than Ariane V. Another facet of the problem is the requirements: problems with requirements have been cited as the major cause of problems in many software systems. Often, the software will meet its requirements - or, at least, the designers' interpretation of the requirements - the problem often lies in the requirements themselves being inadequate. All in all, I agree that software reuse could be improved. However, it is not fair to level all the criticism at software development. Good software (well designed, and trouble free) has been produced: some of this software even has significant amount of reused code. Where reuse is low, the lack of reuse is partly due to the different nature of software; it is also partly due to lack of appreciation of the software lifecycle. Several disciplines need to work together if software reuse is to be improved successfully. Stephen Bull CEng MBCS MIEE AMIRSE Systems Safety Engineer Westinghouse Rail Systems T: +44 (0)1249 442593 E: stephen.bull@invensys.com
I question Mr. Robinson's take, both as a programmer and sysadmin and as one who has had a kitchen remodeled. For the first case, I think that the depiction on the state of do-it-yourselfness borders on caricature, at least for the business as it has been in the last dozen years. The trucking companies may suffer pain implementing Great Plains or Deltek or an ERP system, but they aren't rolling their own accounts receivables systems. An awful lot of small systems are built in IDEs with lots of dragging & dropping of icons, and little or no hand-coding. Oracle's Jdeveloper, for example, will allow you to generate quite elaborate JSP systems, whether or not you can tell "implements" from "extends" or recall what "private static" adds to "private". And as this use of components has been increasing, has security and stability increased with it? The obvious example of Microsoft's COM suggests: Not always. Security alerts do appear for the Java VM. I'd be curious to know the consensus of the Risks contributors on this one. As for kitchens, on some flat earth, in some perfectly plumb and squared room, the component-based model works perfectly every time. Since 1989 I have lived in two houses of very different look and age, and been through renovations of both. Neither house, the one from the 1980s nor the one from the 1930s, was perfectly plumb or square. Neither had everything--electrical outlets, for example--where it should be. The quality of the renovation depended on the care, experience, and common sense of the renovator. Even the house of prefabricated components relies on the existence of subcontractors who know not to saw through joists to run ducts. Christopher Alexander may be a better guide to this world than Eli Whitney. Finally, building technologies have their lurking flaws. For a simple example, all rowhouses built in the Eastern US from about 1975 to about 1990 used fire-retardant plywood to obviate the need for firewalls protruding beyond the roof. Then it was found that this plywood crumbled away not just at fire temperatures but, more slowly, at normal summer attic temperatures. If you think that the house owners were made whole by the courts, you don't know enough about accountants and lawyers. Years ago I quoted to an architect Weinberg's line that "If architects built buildings as programmers build programs, the first woodpecker to come along would destroy civilization." "Oh," she said, "but that's just how they do build them."
Please report problems with the web pages to the maintainer