Where's IBM's Linux Desktop?

From consultingtimes...

Have you noticed that the most likely source of technology expertise, IBM has simply refused to provide a Linux Desktop? With all of their Lotus applications neatly running on their own UNIX products, they won't let you have them on Linux. Instead, they suggest you purchase Windows XP Professional.

The internal strife existing at IBM over producing a Linux desktop has the potential to hurt IBM's business model. A powerful internal software organization wants to grab server market share from Microsoft without disturbing Microsoft's desktop. Anyone inside IBM that mentions a Linux desktop has the potential for losing their job. While few people at IBM know what exists outside the company, the powerful software group may have top executives walking the same plank as the rest of us if Microsoft remains the only Intel desktop platform.

While the software people at IBM have their heels dug in, they may find out that their Web Services strategy based on Java has no place to go. Sun may not have put IBM in "Check," as Scott McNealy has put it, but Sun's Java Desktop System definitely places IBM in a Microsoft dilemma. IBM will have to decide if they'll continue to provide Java Web Services and find a desktop to accommodate it, or watch their Java developers transfer their code to Microsoft's Java Language Conversion Assistant.

I used Don Box

It's true, and in the morning I felt kind of bad. But it was for the good. I've done it in the past, but this time it was coldly calculated. Please read on...

Actually when it comes right down to it, I don't care what happens to Visual Studio. I also don't care what happens to Emacs. VS will continue to improve, but moreover it will continue to be hugely popular no matter what. Emacs has the audience it does, and will probably not improve beyond its current state, because it is in itself an axiom. Probably it's appeal and usage characterisitics will remain about where they've been for the last twenty years.

So why did I use Don Box?

More people than I could ever hope to draw on my own have had a chance at least to read the story about Emacs and the secretaries in the 1970s. Was this story really intended to promote Emacs and to benefit VS?

Not really. I saw the opening and ran for it. Here's the message: the Longhorn preview takes over five gigabytes to install. How much of that is for the typical user?

Very good arguments could be made that all of it will eventually trickle down to the non-technical user. There is no way I could or would argue against that.

But in the 1970s a few typical secretaries had a simple tool for helping themselves, the same tool most programmers have intimidated each other from using even as an influence. In the 1980s typical non-technical users were building multimedia applications using Hypercard. Emacs and Hypercard together take a miniscule fraction of the installation space and still a small fraction of the intellectual power required for computing with XML, DOMs, XAML, and WS-xxx. Are the secretaries going to be doing this in Info Path?

In all of these five plus gigabytes of impending computations, what are we doing for the typical user or even the non-technical MBA? Maybe this was an inappropriate way to use blogspace.

On just one difference between Emacs and Visual Studio Dot Net (besides the length of the name)

Don Box wishes he could be disagreeing with James Robertson's observations on Visual Studio Dot Net, but apparently can't. Here's what makes the difference.

I would consider any advice Don brings from Emacs an improvement for VSDN. But the fundamental difference is also the fundamental failing of not just VSDN but practically every IDE I have seen including the vaunted IDE for Java using Eclipse.

The irony is the term "Visual" because VSDN is a visual nightmare. The beauty of *most* uses of Emacs (remember Emacs is a flexible tool-building platform like Eclipse, except simpler and more expressive) is the visual simplicity and just-in-time functionality. Where VSDN gives you panels, panels, everywhere panels of things to do and be concerned about, Emacs gives you an editing buffer. Everything else is a keystroke or menu click away. All the power of VSDN and more is waiting for your call to action, but visually you are "just editing".

Let's recall this story from the 1970s about secretaries (as they were called then) using Emacs, essentially the same Emacs you're using today. (You *are* using Emacs, aren't you? For shame!)

...programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.

Would we ever read a similar story about VSDN? For want! Not by the 2070s.

One ring to bind them all. Emacs Semper Virens.

Game Programming with Python and PyUI

I just picked up Game Programming with Python by Sean Riley. Sean is also the author of the PyUI user interface framework. He explains and uses PyUI in the book as well.

Just thumbing through the book, I would give it a thumbs up. It looks good and I hope it pans out. No pun intended.

Are we moral relativists?

Before we get too caught up in the capture of a dictator we (the U.S.) supported for decades, let's take a tally of the others still in our (the U.S.) favor.

In two fine speeches recently, President Bush made it clear that autocratic regimes in the Middle East, including U.S. allies Egypt and Saudi Arabia, need internal reforms to stop churning out terrorists. Somehow, though, he forgot to mention Azerbaijan and Uzbekistan.

If the president's ratings go up based on the recent capture of a former ally now out of favor, should that be considered a mandate to terminate relations with these others? Or does the administration itself suffer from "moral relativism"?

Peer-to-Peer Sockets

From Brad Neuberg, OnJava, an insightful abstraction of sockets on p2p on sockets...

P2P Sockets effectively hides JXTA by creating a thin illusion that the peer-to-peer network is actually a standard TCP/IP network. If peers wish to become servers, they simply create a P2P server socket with the domain name they want, and the port other peers should use to contact them. P2P clients open socket connections to hosts that are running services on given ports. Hosts can be resolved either by domain name, such as www.nike.laborpolicy, or by IP address, such as 44.22.33.22. Behind the scenes, these resolve to JXTA primitives, rather than being resolved through DNS or TCP/IP....

The P2P Sockets project already includes a large amount of software ported to use the peer-to-peer network, including a web server (Jetty) that can receive requests and serve content over the peer-to-peer network; a servlet and JSP engine (Jetty and Jasper) that allows existing servlets and JSPs to serve P2P clients; an XML-RPC client and server (Apache XML-RPC) for accessing and exposing P2P XML-RPC endpoints; an HTTP/1.1 client (Apache Commons HTTP-Client) that can access P2P web servers; a gateway (Smart Cache) to make it possible for existing browsers to access P2P web sites; and a WikiWiki (JSPWiki) that can be used to host WikiWikis on your local machine that other peers can access and edit through the P2P network. Even better, all of this software works and looks exactly as it did before being ported. The P2P Sockets abstraction is so strong that porting each of these pieces of software took as little as 30 minutes...

The SOA Antidote

Russell Levine writes in the Business Integration Journal about the Myth of the Disappearing Interfaces. If you work in IT, have been involved in some EAI projects, and are a relatively critical thinker, then there probably is not a lot of new information for you. However the piece serves nicely as an antidote to the run-of-the-mill "Service Oriented Architecture", well, pablum.

More good information can be found at Doug Barry's site. Almost too much at once without a trail guide. Better than run-of-the-mill, without a doubt.

From Russell:

• n^2 vs. n comparisons should be considered harmful.
• A clue that there might be a problem with this argument is that these pictures often have applications with names such as A, B, and C.
• Applications along a value chain often have many different connections.
• Ultimately you need to understand data flows to assess the complexity of the integration challenge.
• Data mapping requires intimate knowledge of the data and how it's used.
• You must understand every data relationship. That hard work is unavoidable.
• Any benefit must be balanced against the effort of creating an intermediate, or "canonical", model.
• Portfolios with the critical mass to justify such efforts don't emerge overnight.
• Focus on business benefits.
• Estimate costs with and without the integration technology.
• Be conservative!

There you go.

So what's all this got to do with XML?

Jon Udell...

So what's all this got to do with XML? If you buy the notion that we are projecting ourselves into networked information systems, then we can't only focus on how processes and data interact in these increasingly XML-based systems. The quality and transparency of our direct interaction with XML processes and data -- and with one another as mediated by those processes and data -- has to be a central concern too.

When I think of XML, two things come to mind. First, I think of the movie Brazil, because XML is still this grab bag of stuff that happens to share one thing in common, angle brackets.

Second, I think of David Letterman's bit he calls "Is this anything?"* --- We expect XML to be something, anything, more than a grab bag of stuff that shares something in common beyond angle brackets.

A third thing comes to mind: the black knight in the Holy Grail, after all his limbs have been cut off. XML is utterly helpless in and of itself. It's everything *around* XML that has value, most of which are hindered by XML per se, not aided.

---

*(David Letterman's latest zany recurring bit is something he calls "Is this anything?" It consists of a setup of the bit followed by the pulling open of a curtain where a performer or, sometimes, a nonperformer, is doing something that may or may not be worth seeing or even worth "anything." David and his band-leader cohort, Paul Schaeffer, then discuss what they've just seen and decide whether it amounts to "anything," They don't always agree, but if the action behind the curtain exhibits creativity and talent it's usually declared "something" and if it's showy but pointless it will garner a "not anything." When Letterman and Schaeffer disagree, it's because they have different perceptions of what constitutes "anything.")

OpenAugment

One of the more interesting projects I have come across in a while, OpenAugment...

The OpenAugment Consortium is a not-for-profit open source corporation dedicated to the preservation of the Augment legacy. Founded in 2002, the consortium is comprised of a small dedicated staff and a number of research partners and associates.

Created in the 1960's by Dr. Douglas Engelbart and his imaginative team at Stanford Research Labs (SRI), Augment is one of the most groundbreaking and important historical artifacts of the software industry. Many of today's desktop and network computing innovations can be traced back to the original Augment system.

Today, the OpenAugment Consortium is taking steps to ensure that future generations will have access to the Augment legacy through this open source initiative. Please explore the rest of this site to find out more about Augment, the OpenAugment Consortium and how you can play a part in preserving this vital piece of computing history.

Answer me this

Today I am listening to one of the local "classic rock" stations. The DJ announces it's "Two for Tuesday". He also announces "We're in the middle of a 25 song classic song salute."

So does that mean for the 13th artist "two-fer" they're gonna play a classic and then a flop?

I'm just thinkin'.

Why Unix?

Better Living's take on software the doesn't stink is fine, but this is a controversial paragraph that caught my attention...

For what its's worth, I think that open-source is no panacea, and in fact is one of the biggest black-holes sucking away human talent needlessly these days. How many man-hours have been spent building a clone of the 30 year-old Unix operating system? There are many better areas for us to be applying talent. And I don't mean to diminish the professionalism of Microsoft developers. The product teams here are some of the most well-tuned machines I have ever seen, but "best" is not the same as "perfect" or even "as good as possible".

(BTW --- What's the difference between "perfect" and "as good as possible"? Nevermind.)

I agree open source is no panacea, but I think it's a better Cambrian Explosion than the Procrustean Bed that is the Microsoft platform.

And why should one develop an open source Unix clone? For one thing, because one can! The ideas are well known and successful, which makes for the best patterns and lowest risk. That's what's known and now accepted as pattern-oriented software development, and so most software development in general should be like this. See Eric Raymond's book, The Art of Unix Programming.

There are many better areas for us to be applying talent.

But going all the way back to Stallman's instantiation of GNU, clearly (in hindsight!), there is a need for a platform for innovation. The platform should be well known and successful, but also unencumbered by proprietariness or the unspoken requirement to abide the vendor's cash cows.

Why try to innovate on a platform vendor whose not-so-implicit intention is ultimately to own any and every idea that succeeds? Enough said there, even so, "Why Unix?" should be *obvious* to a software developer for many reasons. None of which are, or need to be, "Because it rocks!"

Why PythonNet?

Gordon says Python is complete, so why PythonNet? I agree that Python 2.3 has a lot to offer out of the box. But I'm using PythonNet for the same reason I'm using Jython, as Gordon suspects, to get to the libraries in dotnet and the JVM, respectively.

In particular, in this moment, I want to get to SWT, Java2D, and GDI+ for drawing. I could just use the GDI+ DLL without dotnet, but the dotnet API is better. I also want to use other C# code from Python and vice versa.

By the way, I am also starting to use Cocoa via PyObjC for the Macintosh. Other than a thin layer of low level GUI and graphics, I have a growing capability to do "fully native" write once, run anywhere, from Python. Of course with Jython in the mix you have to be careful, since it is not up to the 2.3 definition of C Python. That's OK for now.

Why not just use WxPython? Because I want to use the native APIs and integrate with other native code and I don't want a layer as big as WxWindows in between. It's really not that hard. When you structure your system like this...

1. Domain Model
2. UI and Drawing Model
3. Native UI and Drawing

...you can make the drawing model fairly rich because all the brushes, pens, clipping regions, and graphics contexts are at roughly the same level of detail and capability. But for the UI model I'm finding it's better to keep the abstract UI model very simple, essentially just a set of Commands, Tools, and basic Layouts that map to many more detailed UI objects at the lowest native layer.

That is, don't try to create a WxPython. That's too much work with little payoff. Who wants to program at that level of detail even if it is cross-platform? Let the high level UI objects *generate* all the low level GUI objects in a platform-specific way. Details to come, when I have more of it figured out!

Not on the Up and Up: Oil in the Caspian region

Also from Fresh Air on the 12th, listen to journalist Lutz Kleveman talk about his new book, The New Great Game. Pay attention to which side we're (the USA) on in the "game" for Caspian oil, then tell me we're in Iraq to liberate the people from an evil dictator.

Worse is to come: disgusted with the US's cynical alliances with their corrupt and despotic rulers, the region's impoverished populaces increasingly embrace virulent anti-Americanism and militant Islam. As in Iraq, America's brazen energy imperialism in Central Asia jeopardizes the few successes in the war on terror because the resentment it causes makes it ever easier for terrorist groups to recruit angry young men. It is all very well to pursue oil interests, but is it worth mortgaging our security to do so?

On the Up and Up: More evidence against the Semantic Web

Listen to the segment on this page with the linguist Geoff Nunberg. He addresses misunderstanding in conversations (the human-human kind). This is interesting unto itself, but throw in a machine and see what happpens.

640k: This memory needs error correction

Update: Jon Udell addresses this today from another angle, i.e. the query language instead of the data model. Here's his conclusion: It's about smooth interop between the next-gen Windows filesystem and the larger ecosystem it will play in. If Microsoft will be getting into the role of "schema provider" they'll have to do better than their recent Office XML provisions. The rest of us want multiple platforms and an unencumbered standard.

Ray Ozzie writes glowingly about the officially years-away WinFS file system. ...

Microsoft will obviously drive the initial schemas required by the core system - such as Contact - but where will it go from there?

Nothing two years away in the computer industry is obvious to me. One thing that is not obvious at all to me is why wait two years?

For one thing, Macromedia has a pretty good story with Central, which is based on Flash, is in beta already, and already includes a growing list of initial schemas, such as Contact. A second example is Chandler, which will also have a repository of arbitrary types of Items, including an initial set for the functionality that will come out of the box. Both Central and Chandler are attempts at a multi-application framework for "rich clients" bases on semi-structured information.

I could guess how such a set of schemas could be aided by WinFS, but is Microsoft making this point themselves? How do we know they'll get it right? Is there a convincing reason to wait for WinFS to begin?

Consider instead Google, Google Sets, and Syncato. These are all ways of structuring, searching, and organizing information in various bits and pieces. None of them require a new kind of file system.

I think we have what we need for the back end and front end of a new ecosystem of semi-structured information. I don't see how waiting two years or so for Microsoft is going to help. The key will be evolving these multiple attempts to be more aware of each other, not to wait for Microsoft to eventually get around to duplicating these ideas in some singular vision.

From James Robertson's Smalltalk blog...

Java mostly lives on the server - it's been a roaring success there, but it's failed on the client for the same reason that our product, VisualWorks didn't get that much traction on the desktop - end users really, really want apps to look and feel the same. We are addressing this by moving towards Pollock

The irony in this is that with Longhorn, the GUI is becoming more variable in appearance and layout, as well as lighter weight. The Longhorn GUI is going to be *more* like the emulated (i.e. "drawn") widgets of Visual Works, but with a more sophisticated drawing model.

By and large people have been successful with the variety offered by DHTML user interfaces and game interfaces. One of the most appealing user interfaces that I am aware of (Hypercard) is also notorious for breaking the user interface guidelines established by the same vendor.

Still, Pollock is a good thing for Smalltalk, hopefully providing the flexibility to access all of Avalon when or if Longhorn finally arrives.

My day just got a little brighter: Write Once, Run Anywhere!

The rain has let up and I can see the sun is out over the coastal range, but that's not the real source of sunshine in my day. I had been working on translating a little bit of Java into C#. I gave the automatic translator a quick try, but a strange error was not motivating enough to push through. Hand translation soon gave way last weekend to another project.

I had started to doubt the value of my time vs. the effort of getting up to speed at all. I installed NUnit (not nearly as much documentation as with jUnit) and NAnt (ditto vs. Ant). I managed to piece together enough of a .build file to compile a partially translated .DLL and run a few tests. (Using the unobvious NUnit2 task as opposed to the NUnit task!)

Then the light came from above. What's the state of C Python for .Net scripting? Production ready. Great news! What does it take to run it? Download and click on python.exe. Greater news! I can program using the simple, interactive, (and familiar to me) Python environment.

In just a couple of minutes my whole day, and project, turned from dread to desire. Rather than translating from Java to C# and maintaining two source paths, I'm translating from Java to Python and maintianing one source path that has a little glue into the Java library via Jython and a little glue into the dotnet library via CPython.Net.

Every indication is the CLR will eventually support Python and other dynamic languages much better as first class members of the CLR the way Jython works in the JVM. Meanwhile CPython.Net will do fine, consider this example of handling events...

          def handler(source, args):
              print 'my_handler called!'

          # register event handler
          object.SomeEvent += handler

          # unregister event handler
          object.SomeEvent -= handler

          # fire the event
          result = object.SomeEvent(...)

C Python is the best way to program in dotnet, and Jython is (one of) the best ways to program the JVM. (The JVM still rules on my personal list of interesting languages.)

Even on the desktop, what's changed?

I would expect that Microsoft will be finding ways to move out from under IIS. I believe Indigo is a path for that, but I am not thoroughly versed in this stuff yet. I am less certain they even see a need out from under SQL Server. I am less certain of that myself. It's getting better, it's competitive, and I expect it makes some money. I don't know much about that either. I'd expect some people somewhere inside that large company are finding alternate paths, though.

But even on the desktop, what's changed?

I have a friend who developed some significant client/server software ten years ago, that had a long fruitful life. He's been considering a rewrite, and lately wondered if much of Longhorn obviated the basis for that rewrite. Was there any value in this software above Longhorn, or would it be trivialized?

We discussed Avalon primarily, but considered most of what was presented at the PDC. And we looked at a picture of what his software does. Clearly Longhorn is not a step backward for his kind of application. But just as clearly it was not a giant leap forward.

A few of the grungiest bits would be easier with Longhorn. The bulk of the application would still require good engineering, and with that would be not significantly more difficult to build, nor less functional to run, on any other major OS platform.

So even on the desktop, what has changed? Not as much as might first appear if you're already building significantly sized applications in a "managed runtime", i.e Java, Smalltalk, or Python.

This one is a bit of a ramble...

We need to find a way to lead, not just follow.

Yeah. I am not convinced that what Linux needs is a WinFS-like file system.

But one of the open source world's strengths is the number of programmers who are free to pursue many ideas. A large corporation with a significant cash cow like Windows or SQL Server will always make decisions that leverage those legacies.

I am convinced the hardware, wireless, and Internet platforms are slowly entering their own new level. And there are already object models that run on the most significant platforms. One is Java, which is as good as it needs to be. The innovation needed for the future is above the basic object model.

The next most significant object models are Python and Smalltalk. I don't think we need one object model. And above a narrow band of componentry, the future is almost certainly not to be based in an object model. A simple message passing model will do fine.

I don't think the competition or the worldwide customer base will capitulate completely to the news out of Redmond. But to be sure the dominant platform is finally taking a few significant steps forward.

A Heap O'Wha?

Reading about Reaps reminds me just a little about this cool thing unfortunately called Stalin...

Stalin also does global static life-time analysis for all allocated data. This allows much temporary allocated storage to be reclaimed without garbage collection.

Stalin does "whole program optimization". One of the results is that complete lifetimes of allocated objects very often are known ahead of time. Rather than force manual allocation, and rather than use a general garbage collector for all objects, Stalin can explicitly free objects at the point where it can prove the object is no longer referenced.

Because this is "whole program optimization" the software become inflexible to updates without re-analyzing the whole program. That's not too bad in many cases, especially considering the "whole program" may just be one or a set of components but not everything.

Stalin can also do interesting representation analyses, "unbox" values like numbers, and generally eliminate run-time type checking and dispatching. Perhaps the GNU Java Compiler can move toward these optimizations, and perhaps researchers will continue to look at ideas beyond the currently popular virtual machines; ideas that balance the need for dynamic programming and updates with transparent optimizations that get the most out of the hardware.