Smalltalk Tidbits, Industry Rants

Here's an interesting story on open source and the likely impact on industry. From the Economist:

The main loser (so far) as Linux advances is Sun Microsystems, one of the largest server vendors. Its Solaris software is generally deemed to be the most capable flavour of Unix, the family of powerful operating systems used in servers. But for many applications, Solaris is overkill, and Linux, a less capable flavour of Unix, is good enough. Many people who would once have bought expensive Sun boxes running Solaris are now running Linux on cheap, PC-like machines instead.

This has forced Sun to embrace the technology that threatens its existence. Last year, Sun launched its first Linux-based server. After several zigzags, it has now decided on its Linux strategy. As well as offering cheap boxes running Linux alongside its more powerful Solaris-based ones, Sun will include its server software with both Linux and Solaris, to make its Linux boxes more attractive and to allow users to "trade up" to Solaris. Even so, many in the industry believe that, thanks to Linux, Sun is doomed.

The clearest winner is IBM, closely followed by Hewlett-Packard (HP) and Dell, each of which has done well selling Linux servers. IBM embraced Linux in 1999, and now offers it across its entire range, from lowly PCs to mighty mainframes. Linux has also boosted IBM's mainframe business, since a single mainframe can be set up to behave like dozens of small Linux servers. Firms with mainframes have thus been able to scrap entire rooms full of Unix servers, such as those made by Sun.

This is pretty much what I've been thinking for awhile now - Linux is a nice alternative to expensive Sun hardware, and is "good enough" for many situations. This is going to be the next big shock that runs through the IT industry, in my opinion - when Sun starts to crumble, the shockwaves will affect the server space (Solaris) and the developer space (Java). All the folks who are operating under the delusion that Java is "open" could be in for a few surprises...

Then check this site, which covers the bases.

So we tried out Settlers of the Stone Age last Friday night. I got my butt handed to me, in pieces. It played well - I'd be more than happy to try it again, now that I have a better idea of what the winning strategies for that variant are. It would likely play differently as a 4 player game as well - we only had three on Friday. One thing's for sure - the starting position would be a lot more crowded.

Now I know why our street got plowed early last winter, and seems to always get plowed early. It seems that someone who was very high up in the last governor's staff lives on my street. Since the local (county) government is of the same party as the last governor, he still has some pull. I spent awhile last winter puzzling over this, since there didn't seem to be a good reason for our (non-through) street to get plowed early.

Same thing happened while I was growing up - we had a county legislator who lived on our dead end street, and we always got plowed early. It's obviously an independent of party sort of thing - it was one party in my old home town, and the other one here. Some things never change, I guess. On the plus side, it means that we can always get out to the local supermarket.

It looks like spring has finally found its way to Maryland. The sun is shining, the bulbs are up, and the temperature has finally escaped the 40's and 50's. And just in time as well - one of the neighbors is having their annual Easter Egg hunt this morning. It's a huge thing - separate hunts for toddlers and older kids. A huge spread of bagels, donuts, and coffee. Just a neighborhood event, but very nifty - something everyone looks forward to.

The people who throw it remind me of a personality type discussed in "The Tipping Point". Most of us have a circle of friends and business associates. Then there are the people who seem to know everyone, and be involved in everything - school activities, boy scouts/girl scouts, neighborhood activities, the works. If you start talking to them about something, they will likely have a recommendation for the person you should be talking to about it. In short, they are some of the glue that make a neighborhood a community.

So I'll be off to this year's bash soon, with my daughter. The local cache of chocolate will certainly be renewed.

"Tremors the Series"????

This is what we get instead? Bleah. The first movie was funny, the second was too much of a weak concept. The series is just a waste of airtime. How far the mighty have fallen....

I spotted an explanation of the pitfalls of XHTML over on Don Box's Blog. He actually went to XHTML, and backed off. In the technical blog-verse, there's been an awful lot of hullabaloo about XHTML, but this document convinces me that not yet is the correct answer:

There are few advantages to using XHTML if you are sending the content as text/html, and many disadvantages.

In addition, currently, the majority (over 90% by most counts) of the UA market is unable to correctly render real XHTML content sent as text/xml. For example, point your browser at:

http://www.mozillaquestquest.com/

Only Mozilla, Mozilla-based browsers such as Netscape 6 and 7, and very recent versions of Opera such as Opera 6 are able to correctly render that site. (IE6 shows a DOM tree!)

Authors who are not willing to use one of the XML MIME types should stick to writing valid HTML 4.01 for the time being. Once user agents that support XML and XHTML sent as one of the XML MIME types are widespread, then authors may reconsider learning and using XHTML.

That's right - like it or not, IE has over 90% market share, so using XHTML at this point is telling over 90% of your potential viewers to kiss off. No thanks. Far, far simpler to just slap HTML out there, and wait for the tools to evolve.

We go once a week or so with friends, I almost always have the B and B Burrito, followed by the (mmmmmmmmmmm) Iron skillet pie. Then I feel like I inhaled a blimp the rest of the evening. Oh well

Looks like we'll be playing a new Settlers variant tonight - Mike wants to try out the stone age variant. Should be interesting - Settlers of Catan is one of our favorite board games, although we did overdose on it some the last few years.

This is hilarious, especially this page. Jason Jones pointed this out to me. It's well worth the time you spend there - just pray you don't visit any shops that use it as their coding standard!

It seems that every time I turn around there's a new aggregator being announced - SharpReader just came out, for instance. A lot of these are using .NET - which is a 20 MB runtime.

BottomFeeder, on the other hand, is a cross platform aggregator. The baseline download (compressed) is a tad over 5 MB, and updates to it are in the 200k to 900k range. I could ship smaller updates - patches - but it seems simpler just to replace the baseline application parcel, and is certainly easier to manage.

Kind of an odd place, having the Smalltalk solution be the smaller, lighter weight implementation - it's not at all what the conventional wisdom on ST is.

Awhile back I posted on Prevlayer, and some of the doubts expressed about it. This morning I was catching up on my feeds, and saw this over at the Fishbowl:

One claim made on PrevaylerIsNotADatabase is that unlike RDBMS's and OODBMS's, Prevayler does not have to worry about RAM limitations. Excuse me? Huh? OODMBS's tend to suffer when your indexes can't fit in main memory any more. Prevayler will go completely to the dogs the moment any of your object model is swapped out. Surely Prevayler has to worry more about RAM than anyone else? I posted a politely-worded query to this effect on the page, and received the following reply from the project lead:

No. Prevayler assumes the Prevalent Hypothesis. Databases do not.

To save you following the link, the Prevalent Hypothesis is (direct quote) "That there is enough RAM to hold all business objects in your system." That's right. Users of Prevayler don't have to worry about there being enough RAM because... we assume there will always be enough RAM!

Whoa. i don't know about you, but that's a pretty ignorant hypothesis IMHO. If anything, objects and data tend to expand to fill all available space and then some. Even when it's true, it doesn't necessarily make for a well behaved system - one client system I'm familiar with cached all the Gemstone objects in the Smalltalk image before releasing the product, allegedly for performance - most of us assumed it was to avoid having to buy client licenses. The application was huge, and end users had problems running other applications on their systems. Ultimately, making assumptions like all the data will fit in RAM are dangerous - like other assumptions, they should be tested, not simply asserted...

I spent most of the evening over-thinking keyboard navigation for BottomFeeder. Finally, I ripped out most of the awful code I had been writing, and it started working correctly.

When in doubt, don't fight against the code framework....

If you have trouble starting BottomFeeder, then download this file and place it in the 'app' directory. There was a pre-requisite set in this component - a pre-requisite that exists in systems with VisualWorks installed, but in in environments without it installed. This was a silly mistake on my part, and grabbing this file will address it.

There were a few annoying glitches in the NC download app that have now been addressed. You may also have noticed that the documentation link is broken; that should be addressed later today

If you live in the Washington DC metro area and would like to learn Smalltalk, Victor Goldberg will be teaching a class at Northern Virginia Community College.

Information on the class:

Instructor	Victor Goldberg
Where	CICS 838-01N 6:00 - 9:00 pm, Thursdays
Dates	May 22 - July 10 (8 sessions)
Cost	$549

Contact number for information: 703 323-3168

No more quick flights across the Atlantic (as if I ever took one) - Matt Croyden spotted this London Times story:

British Airways and Air France today signalled the end of the supersonic era in aviation by announcing that they were retiring their Concorde planes this year.

BA blamed falling passenger levels and rising maintenance costs for the decision to scrap flights. Both BA and Air France said their Concorde operations would stop at the end of October 2003. Air France's last transatlantic flight by Concorde will be on May 31.

Ok, so can we at least get power at the seats then?

I found this post on Patrick Logan's blog interesting. Patrick quotes Paul Graham asserting that Java, like Cobol - is an evolutionary dead end in terms of language development:

I think that, like species, languages will form evolutionary trees, with dead-ends branching off all over. We can see this happening already. Cobol, for all its sometime popularity, does not seem to have any intellectual descendants. It is an evolutionary dead-end-- a Neanderthal language.

I predict a similar fate for Java. People sometimes send me mail saying, "How can you say that Java won't turn out to be a successful language? It's already a successful language." And I admit that it is, if you measure success by shelf space taken up by books on it (particularly individual books on it), or by the number of undergrads who believe they have to learn it to get a job. When I say Java won't turn out to be a successful language, I mean something more specific: that Java will turn out to be an evolutionary dead-end, like Cobol.

This is just a guess. I may be wrong. My point here is not to diss Java, but to raise the issue of evolutionary trees and get people asking, where on the tree is language X? The reason to ask this question isn't just so that our ghosts can say, in a hundred years, I told you so. It's because staying close to the main branches is a useful heuristic for finding languages that will be good to program in now.

At any given time, you're probably happiest on the main branches of an evolutionary tree. Even when there were still plenty of Neanderthals, it must have sucked to be one. The Cro-Magnons would have been constantly coming over and beating you up and stealing your food.

The reason I want to know what languages will be like in a hundred years is so that I know what branch of the tree to bet on now.

I think he's right about Java - it's the butt end of the C language family, and - IMHO - goes about as far as you can go in that direction. To me, the emergence of new dynamic languages like Python and Ruby - which owe more to Smalltalk than to Java - shows you where things are going at a grass roots level. Java may be where a lot of the work is, but it does not seem to be where the interesting action is.

We had some kind of server problem over the last hour or so, but it's been dealt with. Seems that the postgres db we use had a brain cramp, and had to be restarted. All is well now - the web apps are responsive again, the public store is responding normally - we apologize for the problem, and now return you to your regularly scheduled Smalltalking...

I got invited to speak at a local company today by a developer (Dave Astels) I ran across at the local XP group. I was there for about 90 minutes, talking about Smalltalk and what's new in Cincom Smalltalk. A lot of the folks there had used Objective-C, so they were more open to the concept than a lot of people might have been. I got a lot of questions, and a good level of back and forth. I expect a few more downloads of the non-commercial product at least, maybe even some skunkworks usage of the product. We'll see; it was fun to just do an evangelical call for a change.

I am visiting a prospect this morning - I'm just printing out the handouts now. It's a lunch meeting in Herndon, VA (which is heck and away from here), so it will take a long time to get there and back. Hoepfully, I'll have interesting news to report when I get back late in the afternoon.

This is priceless - Don Roberts at the C2 wiki:

He is a RedneckSmalltalker. He used to be "The Simplest Consultant That Could Possibly Work", but now he's at the University of Evansville as "The Simplest Professor That Could Possibly Teach." Where he's learned that teaching OOP using C++ is like teaching General Anatomy using only cancer patients.

ROFL

Thanks to one of our doc guys (Mark Roberts), the download page is cleaner and has a better set of explanations as to what you need to download. I also cleaned up the Web Services download link, which still had an invalid file name. It should all be ok now (fingers crossed)

For those interested in looking at the feature set of BottomFeeder before downloading it, have a look at the Users Guide. The 2.9 dev builds have some significant changes:

• Keyboard shortcuts - see here for details
• Ability to import OCS, OPML, and RSS feeds from local files (based on the formats used by syndic8.com
• Ability to export the subscribed feeds to an OPML file. This will be extended to RSS and OCS before the release of 2.9
• A new, cleaner settings tool

BottomFeeder has supported marking feeds, folders of feeds, or all feeds read/unread for a long time now. The downloads are packaged as ready to run applications; the goal of this project is to make the application accessible to smalltalkers and non-smalltalkers alike. If you want to get into the code, the project has a SourceForge page - but the most recent codebase is in the Public Smalltalk Repository. Volunteers are welcome!

If you have been using the Aragon goodies, you may well see a few problems in 7.1 - I was trying to fix the installer, and I think I broke some - possibly all - of the Aragon parcels. Since none of have been changed by the author since the 7 release, just grab the old 7 versions. I apologize for any difficulties....

It turns out that the Mac VM, when installed under Windows or Linux, loses the resource fork information. So I've grabbed the VM files that we ship with vw-dev in a compressed form (.bin), and have them packaged up that way. This means that BottomFeeder Mac users will have to do a little work on their end - decode the .bin files, and also set the type and creator codes for the image to HPS7. If I had a Mac, this would be easier. Alas, not in the budget...

For those of you who missed the WebServices package, it's now been placed on the download site. We apologize for the confusion.

Gordon Weakliem pointed me to this post from Patrick Logan. There's a lot of nice words about Smalltalk there. I've copied the whole thing from Patrick's post below:

Whither Smalltalk?

Instead I think the question should be, "Whether Smalltalk?" And the answer could very well be yes.

VisualWorks 7 is loaded with Internet capabilities: servlets, server pages, SOAP (Open talk). The VM is so much more mature than the CLR and JVM implementations.

The company appears to be solid, and has backed VisualWorks longer than anyone gave them credit for. Cincom rescued Smalltalk from history, after ParcPlace nearly bungled one of the truly great software systems of all time.

S# appears to be close to release for dotNET. Not only could this put some spark back into Smalltalk, but it could pave the way for widespread success of dynamic languages in general on the CLR, through the collaborration with Microsoft and the specific implementation techniques.

Not to mention that Dolphin and MT are still solid Smalltalk implementations for Win32 and on multiple platforms Squeak and GNU Smalltalk are too. The combination of VisualWorks and S# and these others make a cross-platform opportunity for Smalltalk. Systems built for S# or VW to a large degree should run on the other.

VW 7.1 is supposed to provide a more solid (non-beta) native Mac OS X implementation and VW is already solid on Linux and other Unix systems.

Smalltalk is a simple, classic notation for expressing computation. Code written 20 years ago still runs on modern implementations.

Why build important computational assets in notations that are overly complex (i.e. they make you say more than necessary) and are tied to implementation decisions that will soon be outdated (i.e. the "standard" notations are regularly updated with new features that compell adoption by marketing lust and lead to a chronological stratification similar to carbon dating)?

Java and C# books become outdated in a year. They no longer teach the notations the way developers want to use them. On the other hand, a developer can learn 90 percent of Smalltalk by picking up 1983's Smalltalk-80: The Language and Its Implementation!

Far better to build your important computational assets in a notation that is already long-lived, simple, flexible, and efficient, not to mention mostly unchanged for 20-30 years or more. There are a two of these notations that make sense to me: Lisp and Smalltalk.

I could go with either. Smalltalk is easier to explain to developers using other object-oriented languages.

Add Patrick's Weblog to your reading list - there's always stuff worth reading and thinking about there.

if you tried to register for a public store account over the last few days, you got roadblocked by a small bug. Somehow, I managed to ftp up to the server the wrong version of the app, and responses from the db were not being properly read. That's been addressed - tip of the hat to Eric Engstrom for pointing the problem out to me.

By now some of you have noticed that the web services file is missing from the download area for NC. This is an oversight, not us holding anything back. We should have this addressed sometime this morning - I just have to wait for the guy who has sufficient permissions on that box to wake up...

That's what SETI@Home is learning with this report from PC World:

The earlier version of the screen-saver software contains a buffer overrun vulnerability in code that processes responses from the SETI@home server, according to Berend-Jan Wever, the 26-year-old Dutch student who wrote the advisory.

After tricking the client into connecting to a server the attacker controls, an attacker could cause the buffer overrun by sending a long string of data followed by a "newline" character, Wever wrote.

The vulnerability affects all versions of the SETI@home client software, including those for the Microsoft Windows operating system, Apple Computer's Macintosh operating system, and versions of the Unix operating system.

The software running on the main SETI@home server at UC Berkeley contains a similar vulnerability, according to the advisory.

And kind of an "oops" here as well:

A separate problem concerns the SETI@home client's transmission of information back to the SETI@home server. Wever discovered that all information from the SETI@home client is sent out in plain text form. That information includes data on the operating system and processor type used by the machine running the SETI@home client.

Malicious hackers could collect the SETI@home data using any one of a number of common packet-sniffing programs, providing useful information for planning a larger network attack, according to the advisory.

The vulnerability would require attackers to "spoof" a fake SETI@home server and trick the software clients into connecting to it before they could be compromised. The SETI@home team knew of no previous attack on a client that used such a method, the Web site said.

However, clients could easily be tricked using spoofing tools or attacked from HTTP proxy servers or routers used by the SETI@home host machine, according to the advisory.

More than 4 million Internet users have registered with SETI@home. Of those registered users, more than 500,000 are considered "active," having returned data to the main server within the last four weeks, according to the project's Web page.

Buffer overflows. So when are people going to learn that C and C++ are simply unsuitable for most tasks?

Tomorrow will be a phone day. I have a call at noon, another at 1, and a third at 2. That will keep me busy for awhile....

The new NC downloads are ready! If you have not registered before, register here. If you have downloaded, either login here, or follow the link we sent you in email. Kudos to the Cincom Smalltalk engineering team for a great release!

I just finished implementing RSS Auto-Discovery to BottomFeeder. It's only in the dev builds at this point, but it seems to be working well. It was easy enough to implement as well; the hardest part was filtering all the duplicates from syndic8 XML-RPC queries.

What can you do with this now? Well, when adding a feed, if you type something like CNN, BottomFeeder will search the syndic8 site for matches, and then offer to subscribe you to any/all of them. It's pretty cool.

Lots of good historical pointers at Bitworking this morning - including this statistic:

The influenza virus had a profound virulence, with a mortality rate at 2.5% compared to the previous influenza epidemics, which were less than 0.1%

Earlier today, I pointed out that SARS had a death toll (thus far) of 3.5%. Hmm. My own grandmother's twin sister died in the flue pandemic in 1918 - this thing will bear watching....

It's a good thing that the kill rate of SARS is so low (something like 3.5% IIRC). There's something resembling a minor panic starting over it now; can you imagine what the major media would do with a virus that had numbers like Smallpox?

If you want to call it that. It's a geek's Easter breakfast ;)

Gordon Mohr's Easter breakfast

I've been leaving the dev builds directories alone, just updating the upgrade directories. Well, I am now updating those as well. That way new downloads should get the latest stuff right off....

Go read Ted Neward's travel thoughts.

Boy, did I ever identify with that.

I've just read Ted Neward's tips for HTML based apps. They are good ideas, and, if used, will result in a more pleasant end user experience. For instance:

What is it, exactly, that takes an otherwise well-built, well-behaved application and turns it into a snail? A large part of it is the HTML being returned. When an HTML page contains dozens of references to images, large and small, scattered all over the page, the page as a whole seems to drag to a crawl as the browser is forced to go back to the server over and over again to download those images. Yes, the images make the page look pretty, but does the website really need mouse-flyover image-switching graphics buttons for a main menu? Or a footer of ivy leaves twined around the copyright statement? Or the company logo in the upper-left corner of every page? I'll be the first to admit that these things make the page look pretty, but after they've been seen once, they just fade into the background in the user's mind. Worse, though, they still need to be displayed, which means that they still need to be downloaded each and every time. (A good browser will sometimes cache some of the images, but there are limits to what can be cached.) Even beyond that, consider the size of the images themselves--if they're any decent size and color depth at all, they can measure well into the hundreds of kilobytes in size, all of which has to move across the network from server to client.

He goes on with some recommendations, all of which are good - but they raise a simple question in my mind. 20 years ago, we started the migration from server (mainframe) based applications to client (PC) based applications due to - well, pretty much exactly these problems. In fact, a web application is a green screen terminal application with (slowly loading) graphics. So why exactly do we want to deliver applications that way?

In some contexts, it makes a lot of sense. Outside the walls of the business, web apps provide a way of getting feedback from, and getting information to, customers and prospects. We have no control over the platforms those people have, so we have to settle for an LCD solution - a web app. Let's look within the business though - once you get beyond the simple applications, what value is being provided by web apps to your corporate users? Sure, IS can update them easily. On the other hand, delivering patches and/or new versions over the intranet for a client application isn't hard either. You have all that desktop power in front of the users - why throw it away? What many IS groups seem to forget is that the time of their users is important. I've seen web "solutions" to reporting from sales staff that force field sales people to spend 3 and 4 times more time on reporting than they did prior to the roll out of the "productive" web application. There was a reason we abandoned terminal screens; IS organizations would do well to recall those lessons.