Smalltalk Tidbits, Industry Rants

Via Dave Buck:

The Ottawa Carleton Smalltalk Users Group is proud to announce a special distinguished speaker to kick off its 2003/2004 year. Visit the OCSTUG web site for more information.

You Can't Do That With Smalltalk! " Can You? Lessons From The Past " Challenges For The Future

Dave Thomas

Date:	Thursday, September 18, 2003
Time:	6:30 PM
Location:	Room 5115, Herzberg Laboratories, Carleton University (see details below)

Abstract

In this talk I provide a personal perspective on the evolution of commercial Smalltalk as it escaped from the Parc to the Street. The papers and dialog I see today in the Smalltalk community, and especially the Squeak communities are very much reminiscent of the excitement we felt as researchers and developers in the early 80s. Our challenge then was to be able to keep using Smalltalk in research or commercial development outside our tiny community.

In the early 80s we had very limited access to the technology and the implementations lacked the features and performance needed for any kind of serious industrial or research use. Indeed many of us lacked the hardware to even use the technology in a serious application.

We examine the technical and business contributions that both enabled and hindered the development of a vibrant commercial and educational Smalltalk industry in the early 90s. We show that by stepping up to and addressing several external challenges the Smalltalk market was created and flourished.

We briefly discuss the Smalltalk commercial inertia, language entropy and developer arrogance that allowed it in part to be eclipsed by other technologies rather than evolve to meet the needs of web and open source communities. We advocate for constantly evolution of Smalltalk, rather than the preservation Smalltalk as an interesting software artifact for every trapped in its own self-image. There are many exciting things happening outside Smalltalk that we need to bring into our world, and some old baggage we need to throw out.

We challenge future Smalltalk advocates to address the needs of the external developer community to enable the wider spread use of Smalltalk. Unless the needs of the broader development community are met Smalltalkers will remain in their cloisters preaching to each other rather than saving developers from middleware hell.

Speaker	Dave Thomas
From	Bedarra Corporation, Carleton University and University Of Queensland

Dave Thomas is a popular keynote speaker and a recognized international expert in: software engineering; virtual machines; object technology; embedded systems and end-user programming. Dave is best known to the Smalltalk community as the founder of Object Technology International (OTI) developers of Envy/Developer a unique CM environment for object oriented development; virtual machines (Smalltalk/Vmac and Envy/Smalltalk) and IDEs for IBM VisualAge for Smalltalk; for Java; Micro Edition for Embedded Systems and Eclipse. In recognition of his contributions to object technology Dave was elected to the IBM Academy

He is currently CEO of Bedarra Corporation, which he founded in 1998. Bedarra provides assistance to new ventures both in new and existing companies as well as R&D and competitive analysis. Bedarra focuses on the transfer of research from the lab to commercial success. Bedarra has assisted more than 30 companies in Australia, Canada, the US and Europe. Bedarra is currently focused on: eLearning; Next Generation Application Development; Agile Software Development and Pervasive Computing.

Dave was recently appointed a founding Director in Agile Alliance, which promotes fast user, focused software development. He is on the editorial board of the new online Journal of Object Technology (JOT) and a columnist in Otland. Dave is an adjunct research professor at Carleton University and the University of Queensland in Brisbane Australia where he works with the DSTC research lab.

Location Details

The meeting will be held in Room 5115, Herzberg Laboratories (building 13 on the map ). Pay-parking is available in Lot 1, 2, and parking meters can be found along University Drive. Free parking is available across Bronson Avenue opposite Lot 5.

Please RSVP to david@simberon.com if you plan to attend

Ted Leung has a post on product liability, and how it's going to impact the software industry. He sums it up thusly:

The software industry as a whole needs to find ways to improve software reliability. If we don't find a way to do it, the legal system is going to find way to do it for us.

I'm a whole lot less hopeful than that. Product liability cases often help one set of people, and one set of people only - the lawyers. Look at the Tobacco suits, and who got most of the money, for instance. And it's not necessarily the case that suits help - look at the stupid Stella Liebeck coffee case - the upshot of which is that I can't get a decent cup of coffee at McDonald's anymore. Liability suits are a very coarse grained way to fix a problem - and in some cases, the fix may well be worse than the original problem. Another example - go look at a ladder. Notice all the nasty warning labels on it? Those exist because of liability suits. Now imagine software with that kind of thing ....

I've seen my share a wiki skeptics, as detailed in this post. Clay Shirky hits the nail on the head when he points out why they are resilient - it takes more effort to despoil a wiki than it takes to restore the original content. I saw this first hand a few years ago when a complete idiot decided that it was his god given right to deface pages here. He carried on for about a week and a half, gettting increasingly angry after each rollback of his graffiti - but he eventually gave up - because his bad behavior was more work than my restorations.

There are a few other really good points in the post that go beyond wikis - the introductory points about process, for instance. Ted Leung points out this followup. Ben Hyde clearly doesn't agree with Clay's process arguments - both points of view are worth reading.

I've been telling people this for years - but most people have to use a dynamic language first before they really get it. Now he should try out Smalltalk, and see what productivity is really like

I've never been a big fan of manual labor (meaning, I've never liked it when it was my hands that had to the actual labor). I never cared for it as a kid, when I got drafted into the varrious home improvement projects my Dad undertook, and I still don't like them. On the other hand, I like crafting software - it's been a lot of fun building this blog and BottomFeeder.

So the sense of satisfaction I get after finishing a home project always comes as something of a surprise to me. Recently, we had to address a drainage issue. We put in a patio, steps, and a sidewalk (garage back to the patio) 2 years ago. That was a huge job, and involved a lot of moving of earth - nearly 10 tons of gravel and sand, plus all the dirt and sod we dug up. I still stand back and admire that work. Unfortunately, we caused a water problem when we put the sidewalk in - it was too high, and dammed the water coming from the sump pump outlet next to the foundation - after every rain storm, the pump would run for days, and we ended up getting a minor leak into the basement

Clearly, we had to fix that. We got to it this summer. We had to tear up most of the sidewalk, and about a fourth of the patio. We then dug over 100 feet of drainage trench. Into those trenches went four inch perforated pipe. That's hard work on two levels:

• First, you have to dig the blasted trench
• Second, you have to make darn sure that the trenches run downhill - otherwise, the whole project is a waste.

Every time it rained (which has happened a lot this summer), the trenches had to be re-leveled. We finally got the pipe in, and the trenches filled back in. Then there was rebuilding the sidewalk and patio - and let me tell you, the briicks never want to fit back in the way they should. Still, we got that done, and waited for the first rainstorm (which perversely now that we were done held off for days). It worked - the water drained down and away from the house. No more lake on the patio, no more leak in the basement, no more constant ruunning of the sump pump. Success!

There's still some cleanup to do - we don't have all the blocks near the steps back in yet, for instance. The major work is done though, and in looking at it, I find that I have a higher level of satisfaction than I ever get from software. Which amazes me. Perhaps it's the sense of "permanence" - those bricks and pipe will be there, long after I've moved from this house (which itself is 20+ years away, at least). BottomFeeder likely won't last as long as those bricks, which is probably why I take more satisfaction away from that job. Doesn't mean I want to go to work as a bricklayer though :)

The Register has some reader feedback on preventing email viruses - interesting selection of comments....

Point your browser here for more ESUG 2003 notes!

Gordon Weakliem wonders how he missed the passage of the 27th amendment a couple of years ago. This site explains why (see dates) - the Congress passed that amendment - without a time limit for ratification - back in 1789. There it lay forgotten for more than 2 centuries before 3/4 of the states actually ratified it. In recent history, amendments passed by Congress typically have a time limit for ratification - typically 7-10 years, if I recall. The ERA amendment, for instance - stalled out 3 states short of passage when time ran out on it.

If you are using BottomFeeder 3.0 or the in dev stream, use the update tool and update. An alert user spotted a bug in the http code that was causing a lot of cpu usage - and a generally slow update loop. With the fix, the update loop is a lot faster - and plugins like TypeLess are not bogged down during updates. Tip of the hat to Martin Kobetic for his help on this!

Patrick Logan explains why you really want a dynamic language:

Lists, maps, arrays, even self-referencing structures can all be entered end edited in a command loop or workspace using a very simple (i.e. few characters) syntax. There are also the mundane (now that Java brought them to the masses) aspects of these languages like garbage collection and array bounds checking

Productivity is greatly enhanced when you can explore the bounds of a problem easily. Most of the static language crowd still doesn't get this

Steven Denbeste explains the difference between user friendly and user hostile - in short, it's usually a mistake to assume you know what the user needs:

Your job as a tool designer is to give your customer what he wants, not to give him what you think he needs. Your job is to let him do what he wants, not to force him to do what you think he should do. If a customer comes up with a hacky solution which works, let him use it. In that case, it means he's still concentrating on his problem. Once your tool gets in the way and tries to force him into some stylistic channel or other, then he not only has to concentrate on his problem but also on trying to figure out what way your tool is willing to allow him to solve it. Whether or not the result is "better", you've made the problem harder to solve, and that means it's going to take longer and require more effort. That's the opposite of what tools are supposed to do: they're supposed to enable fast solutions, not prevent them.

Something to consider next time you get ready to deliver....

Dave Buck explains the problems inherent in trying to express blocks in a statically typed language.

Wired News points to some research on trains and fuel cells. The idea would be to get subways onto fuel cells - and off the grid. There's a basic problem with this, to my mind - cost/benefits. How often do the subways lose power? Not terribly often. What would be the cost of putting in a fuel cell based infrastructure? Pretty high, I'd guess. The question is, how would you prioritize that over other needs and problems - when the problem fixed by fuel cells is rare?

This is one of the sorts of problems that - to my mind - IT shops understand very badly. Over the last 7 years or so, there have been tons and tons of projects launched to replace the entire infrstructure of a business - from whatever it was to J2EE (and possibly .NET now). It's as if no one ever looked at the opportunity cost of that - how many other things could have been done - and probably a lot more quickly and cheaply - by simply adapting what they had instead? How many expensive consultants would never have been hired (only to be fired later when things went badly)?

Web Services has the potential to make such mistakes obsolete - instead of rewriting (with a high risk of failure) - simply add web services api's to what you have. It's a virtual certainty that such API's can be added to your existting applications, and the liklihood of success is far, far higher than in a full rewrite scenario. To my mind, the shops that pay attention to opportunity costs are helping their businesses. The ones that don't are creating a business drag

The Washington Post reports that the FBI has found the loser who unleashed one of the MSBlaster variants - some 18 year old kid in the Seattle area, apparently. The worst part is, he's traded the transient high of pulling this prank for the long term pain of the big house - I seriously doubt that the authorities will cut him any slack. I wonder if he'll reappear years from now - like Mitnick did - older and wiser...

CNET News.com surmises that Sobig may be a funded effort - on the part of spammers. Think about it - Sobig sets up an anonymous SMTP server on multiple clients, and has the ability to call back to some kind of central server (for content). What we could be seeing is either:

• a Job audition by some ambitious virus writer
• an actual test of the concept

As CNet puts it:

Security researchers believe that the creator of the Sobig mass-mailing computer virus won't stop with Sobig.F--the money may be too good. The Sobig viruses, the first of which started spreading in January, are designed to load special software that can make spam anonymous on people's PCs. The tens of thousands of computers infected by the virus can then be used by bulk e-mailers to send unsolicited messages that can't be tracked.

"It is very well planned, very well designed and very well executed," said Mikko Hypponen, director of antivirus research for security company F-Secure. Hypponen believes that the virus' author likely sells the list of compromised PCs to spammers. "For once we have a virus with a very good motive: money."

If this is the case, get ready for more of the same. One more reason to transition your mailing lists to RSS feeds with comment capability....

Chris Double points to some continuation based web servers - and misses Seaside - there are implementations for Squueak and for VisualWorks

Update - spoke to soon - Chris updated the page....

Danny Ayers doesn't think much of the barefoot post (on developing w/o static types) which I linked to yesterday. He says:

Let's say I come across a method like this :

def do_upload(pagename, request):
...

Here I can guess from the context that it's a http request, so let's say I want to get the date header and print it in W3CDTF format. If it was typed, then I'd simply look in the documentation for that type (class). But how do I find out what methods 'request' supports?

hmm. We don't have that problem in Smalltalk. We have tools that can find implementors and senders of methods for us instantly - so it's an utter non-issue. The type information adds nothing of value in that regard. I'd suggest downloading a Smalltalk implementation and taking a look - you'll see why it's not a problem.

Martin Kobetic kelped me out with another interesting bug - and the fix does three things:

• Speeds up the update loop
• Stops BottomFeeder from getting slower as it runs
• Gets rid of an ongoing memory growth issue

When I added module support, one of the methods that looks for an appropriate handler for a module had a nasty little bug - it did this:

subclasses := self subclasses

Well, that was in a class method, and it turns out that 'subclasses' is an inherited class instance variable. Dohh! On each run through, the subclasses of class Module got more and more massive - and searching through them got slower, and there were multiple matches of appropriate handlers - all manner of badness. That's fixed now, and the application is much more well behaved now.

I posted earlier on an interesting - and nansty bug I had introduced into BottomFeeder. As it turns out, the problem I created can manifest itself in other ways. Here's what I did, each time I checked modules (and I have 151 feeds here):

subclasses := self allSubclasses.

That looks inocuous enough. Trouble was, I did it in a class method. Recall that classes are instances of their Metaclass, and descend from Class (up to Behavior). Look at the instance variables for Behavior:

Smalltalk.Core defineClass: #Behavior
	superclass: #{Core.Object}
	indexedType: #none
	private: false
	instanceVariableNames: 'superclass methodDict format subclasses '
	classInstanceVariableNames: ''
	imports: ''
	category: 'Kernel-Classes'

One of them is 'subclasses'. So look again at what I did - each time through that loop, I made subclasses into a bigger collection, all filled with duplicates! When I looked at it in my development image, I had over 10,000 subclasses of the class in question! No wonder I was chewing memory, and no wonder iterating over the subclasses (that's what the code in question did) was taking a long time, and getting slower each time through!

Fixing it was a simple matter of changing the code to use a temp variable - problem solved. There's a larger lesson here though - look at Behaviior abd the subclasses down to Class. You don't want to use a variable that matches the name of any of those instance variables on the class side - referencing them in tools is ok, but assigning new values to them is a very bad idea. The only real hint you'll get is that you won't be prompted to declare a temp variable - but that's very, very easy to miss.

I'm looking at adding a code critic rule to flag these issues - if I get that working, I'll post an update. In the meantime, watch out for this sort of thing if you start seeing oddball behavior in an image.

Slashdot notes that AOL is blocking Live Journal links - so a live journal blogger who tries to link to an AOL blog gets a 404. That's just fascinating. Is this image vampire blocking gone wrong, or something stupider?

Brian Marick has some thoughts on reading code - his main point is that even with well written code using intention revealing names, there's still an assumed expected reader. So his point seems to be to bear in mind that the end reader may not be the expected reader - and that you consider that when writing code. That's probably a good idea, but I have a follow on thought - if you have to look at code and you don't get what it's doing, that likely means that you don't know the language it's written in very well (or if you do, you don't understand the business domain very well). Too many outfits have the idea that coders are interchangable parts, and that one is just as good as another. This leads to problems, because the team leading the charge to replace the (poorly documented) legacy system with a shiny new one in some fashionable language/system probably lacks

• knowledge of the legacy system's implementation language
• knowledge of the business domain

Which explains a lot of failures, IMHO. What management needs to understand is that developers are no more interchangable (and no less, for that matter) than marketing teams. Just as a marketing team that knows the business has far more value than one that doesn't, a development team with domain knowledge has far more value. Consider that next time you see a project outsourced to a bunch of remote people with no domain knowledge, or the next time you see one of the hordes of consultants from one of the big consulting shops. It will likely work every bit as well as the equivalent change done in marketing or sales would.

Point your browser here for pictures from ESUG 2003, and over here for notes and slides. Looks like it was a good conference!

Richard Demers - who has contributed the BottomFeeder documentation and many user interface improvements, now has a blog. His RSS Feed is here.

Charles Miller is not amused by CSS incompatibilities:

CSS is great so long as you stick to a small number of heavily tested recipes. Stick with those and you're fine. Try to do something stupid like, say, build your own layout from first principles, and even if you spend the requisite day testing in multiple browsers and tweaking around the minor bugs, you'll still probably end up completely screwed because you've ended up relying on some property that one of the major browsers just doesn't support. Bastards.

The thing that was supposed to save us from tables is succombing to the forces of entropy....

Avi Bryant has started a blog - the RSS feed is here. Avi is the driving force behind Seaside, so expect to see a lot about the benefits of continuation based web applications.

Avi Bryant gives a really cool example of what kinds of things are possible with the way Smalltalk handles exceptions. Read that, and ask yourself if you can do that in the toolset you use....

I last posted about the Yankees and Red Sox here. Well, thiis weekend the Yankees ttook 2 out of three - and, true to form, there were some crucial Red Sox errors in the 5tth inning. This is how it goes in August and September - first, the Sox get close, then they choke. The Globe sports section should be fun to read tomorrow :)

Georg Heeg gave a talk on VW and .NET at ESUG last week. Here's a link to the description, and here's a link to his slides. That latter link is a PowerPoint presentation, and is 10MB.

The Register points out that last month was just about the worst month ever for Viruses and worms. I was one of the many that got hit. I went to a roundtable discussion lastt week, and the hotel it took place at has wireless. So I connected up and started taking notes. About 5 minutes in my machine crashed - no blue screen, just a shutdown. I thought it was odd, and one of the participants said I might have a worm - I went and loaded patches and stopped thinking about it. Well, that was shutting the barn door after the fact...

I had been noticing really bad network connectivity, and my ISP was assuring me that the signal strength was ok the last couple of days. So I took a close look - and there was the worm that 'fiixes' blaster. What it was doing was sucking down my bandwidth. Removing it fixed the problem immediately. The simple moral of the story - I now have firewall software for Windows, mostly for the times I go mobile. Should have known better, but there's complacency for you....

Avi's post on exceptions came right up in my face this morning with an error report on BottomFeeder. When the app is reading a feed, there's a wide variety of potential exceptions - many of them should just be ignored, and handled as nothing new now - for instance, getting a 500 or a 404 on a feed is typically a transient issue. On the other hand, there are also xml parsing errors - many of these I silently pass over and just handle - but I found one this morning that needed better handling

Say you try to add an RSS feed - and the site owners are getting hit with too many hits from your tool (either yours specifically, or someone else using Bf). The query for the feed answers back an html error document instead of an RSS doc - and the parsing fails. Well, the error handling for that case was all the way up in the UI, well after the query, and after the point where anything useful could be done. By moving the handling down a level, I was able to preserve the information so that a more useful error could be reported.

The way Smalltalk exceptions work is just too cool

I posted earlier on exception handling in BottomFeeder. Later on, Rich chimed in with the uses and abuses of exception handling. Certainly you can go overboard, and many people starting with Smalltalk do - it's veryeasy to just grab all exceptions and swallow them - and then have no frelling idea why things aren't working right.

In fact, that was a problem I had early on in BottomFeeder - the code that grabbed the feeds was swallowing exceptions so far down in the network code layer, that all errors came back to the UI as basically "no response". That was no good - it made it impossible to separate recoverable errors (like, say, a redirect that could be followed to the new location) from the non-recoverable ones (a 404, document not found).

What I ended up doing over time was moving the right handlers to the right place - things like a redirect are now silently - and properly - handled, while an inability to read a site that we can normally read is simply ignored. One of the lessons I learned early on in Bf was that there are scads of network errors for which the appropriate client response is to mostly treat it as no update at this time - on the assumption that it would likely work fine next time. For instance, say you left the application running overnight, and storms knocked out your network service (but not your power). Every http query will result in an error until the network comes back up - but these are all transient

Email dead? For publishers of newsletters, it's getting to be. People don't want to sign up for fear of more spam - and many of the ones who have signed up are filtering them out - with overly aggressive spam filters. Listen to Chris Pirillo:

"E-mail is dead, period," declares Chris Pirillo, the Internet entrepreneur who distributes about 400,000 e-mail newsletters weekly. "I don't care what kind of legislation goes through, people aren't signing up for newsletters anymore. People are assuming that every e-mail publisher is a spammer."

Pirillo's Lockergnome has begun actively directing subscribers away from e-mail subscriptions, touting RSS (Rich Site Summary or Really Simple Syndication) instead as a foolproof way to avoid the spam bottleneck.

I've seen this personally - my sister is doing side work as a website developer now, and one of her recent jobs involved generating an email to site subscribers. It took her awhile to figure out that mails going to AOL subscribers were being blocked - even though they had opted in - due to the hrefs in part of the message. It's now at the point where you simply cannot guarantee that any email will reach its destination. Marketing simply has to find an alternate route in

Ted Leung found something interesting - the MS PDC is going to provide live blogs for the show. I agree with Ted; this is soon going to be an expected thing

I had just about the worst 24 hour bug yesterday that I can ever recall havinig. I went to bed at 7, and gott up at 9. I felt awful last night - fever, upset stomach - the whole 9 yards. But whatever it was, it passed. Weird.

CNet News has a story on SCO's latest move - an attempt to get Linux users to cough up license fees by sending out invoices. Linux analysts are recommending a go slow approach:

Stacey Quandt, an independent Linux analyst, said companies should wait to see how the current SCO lawsuits end before acting.

"I can't see why a company would pay this, since it is all based on allegations and hasn't been proven in court," she said.

The companies to which SCO sends invoices are likely high on its list of candidates for lawsuits, according to Quandt.

"SCO continues to use tactics of brinkmanship, and it is certainly possible that the companies that get invoices could become future defendants," she said.

The circus begins....

There's been quite a lot of posting on continuations recently - especially by Avi. This morning, I see that Chris Double is talking about how to preserve continuations via seriialization.

Since I was sick last night, I didn't even try to make my early morning flight to Cincinnati. When I finally did get up, I felt a lot better, and decided to make the trip - off to the airport. Things started well - they gave me a standby ticket for no charge, and it looked like I'd get they by late afternoon. But Whoa there - not so fast! The flight was delayed. And delayed. And delayed. They started announcing that connections would be blown. The follow on flight got cancelled - so my standby started looking dicier. Off they sentt me and 3 others, by cab, to DCA. So I get here, check in, and find out that the flight I'm standing by for is oversold. Whee. There's another one - 15 minutes later - that I can probably make if I run from the one gate to the next, if I don't get on. This just gets better and better.....

Taegan Goddard's Political Wire has an interesting quote from Dave Winer -

Dave Winer says it's "not surprising to me" that weblogs "have become such an important part of the early 2004 presidential campaign. I expect this campaign will take place more on the Web than it does on TV networks."

I don't think so. While blogs and RSS are reaching the mainstream, I bet you would still get a huh from most people if you asked them about a blog. One key to knowing when this has changed - when you see blogs finding their way into TV character conversations. I knew Google had reached a wider audience as soon as the phrase "I'll google him" started showing up on TV....

CNET News.com warns that recent versions of Office (MS) have a few vulnerabilities - including a buffer overflow issue in VBA. This affects every version from Office 97 up. Want to take bets on those all gettiing the appropriate patches? I'm still gettting inundated with Sobig.F emails - proof that, even after a virus storm, plenty of systems stay unpatched.

Remind me again why IT groups don't look at OS X?

InfoWorld has a column flogging security products in order to protect your company from vpn carried worms and virii picked up at home. I'm all in favor of having people take more precautions; I just got an object lesson on that, for instance. What I expect a lot of clue free IT managers to push for - no remote connections....

Off to the gate again, to see if I finally get to Cincinnati....

Wired News reports on software issues associated with the recent blackout:

"We have no clue. Our computer is giving us fits, too," replied a FirstEnergy technician identified as Jerry Snickey. "We don't even know the status of some of the stuff (power fluctuations) around us."

A short time later, a technician at the Midwest Independent Transmission System Operators, the group that monitors the Midwest power grid, expressed frustration with FirstEnergy's failure to diagnose the problems erupting in their power system.

"I called you guys like 10 minutes ago, and I thought you were figuring out what was gong on there," the MISO technician, identified as Don Hunter, complained, according to the transcripts.

"Well, we're trying to," replied Snickey. "Our computer is not happy. It's not cooperating either."

Leaves me wondering - was First Energy one of the outfits that jumped headfirst iinto J2EE land back in the late 90's, re-writing all their systems? Were they one of the places where lots of consultants with no domain knowledge at all did large parts of the system? It would be interesting to find out....

This trip to Corporate has already been a success. First, I got one our marketing people set up with a blog - he wanted to try it out locally (just on his machine) for awhile. That got done this morning. This afternoon, I got my laptop's keyboard replaced. The following keys were double typing - e, t, o, i, a, s, u. Imagine trying to get anything done with a keyboard that did that. The guys in IS tell me that the keyboards on these dells - the Latitude 500's - have been a real problem. I hope this keyboard holds up better than the last one did...

Ben Hammersley reports that cyberwar is real:

Via the Taipai Times: China has launched a systematic information warfare campaign against Taiwan, spreading Trojan-horse programs into private companies' computers as a means to break into government databases, the Cabinet said yesterday.

Pretty soon we'll need to keep a scorecard to tell the teenage misfit hackers from the cyberwarriors....