| Reviving OS/2's best in the Linux desktop |
Feb. 08, 2008
Analysis -- Get over it. We're never going to see OS/2 open-sourced. If you want to run OS/2 today, the closest you're going to get is Serenity System's eComStation 2.0 RC4. But, it just might be possible for Linux desktop users to get one of OS/2's best features: SOM (System Object Model).
IBM, I'm told by developers who should know, still has all of SOM's source code and it all belongs to IBM. It's because IBM doesn't have all the code for OS/2 and some of it belongs to Microsoft that IBM open-sourcing OS/2 has proven to be a futile hope.
Of course, many of you are asking, "SOM, What's the heck is SOM?" I'll tell you. It's a CORBA object-oriented shared library. Those of you who aren't programmers are doubtlessly staring cross-eyed at the screen right about now. For you: SOM is an easy-to-use universal programming library that both KDE and GNOME developers could use to create programs that would work in any Linux desktop environment.
The closest many users ever got to SOM was OS/2's Workplace Shell, its desktop interface. What made SOM so powerful in the Workplace Shell was that it made it so easy to customize the desktop and its applications. With SOM, getting an application to look and act like a KDE, GNOME or what-have-you desktop program is almost trivial. Instead of delicately playing with APIs to move an application from, say, Ubuntu GNOME to OpenSUSE KDE, an SOM-aware application simply needs to call on the WinReplaceObjectClass API to use the KDE set of classes instead of GNOME's.
If this were adopted, it would be much easier for developers to create, if I may borrow Java developers' pet phrase, "Write once, run everywhere" applications. However, unlike Java applets, which are often slowed down by the need to be run in a Java interpreter, SOM-enabled applications and desktop environments wouldn't face such delays.
Technically, it would work by GNOME and KDE using gtk and qt bindings to one common SOM library. Thus, today's desktop developers really wouldn't need to learn anything new about how to program for this new desktop environment. They would need to learn enough about OOP (object-oriented programming) to use SOM effectively, but that's nothing compared to the kind of hoop-jumping needed currently to move an application from one desktop interface to another.
SOM wouldn't be good just for hooking applications to the desktop. You can also use it with other programming languages. For example, SOM-aware Java, PHP, Python, Ruby or what have you would give Mono and Microsoft .Net some interesting competition on both the Linux and Windows platforms.
The other advantage of course is that OOP tends to create more stable and flexible applications from the very first version. The best example of that today is Apple's Mac OS X's Cocoa and Carbon. Now, while the debates over which of these is better than the other continue to rage in the same way that old-school Unix and Linux users still argue over vi vs. EMACS, one thing is certain. Mac OS X applications are stable and they always work in the same way.
Linux, while it uses OO languages like C++, really doesn't have a universally accepted OO library. If Linux were to adopt SOM for that purpose, it could avoid the Carbon versus Cocoa arguments, and become -- dare I say it? -- the best desktop programming environment of all.
Another plus for SOM is that IBM designed it to work on any architecture, from mainframes to PCs. It's also already been ported to AIX, IBM's Unix. Put this together and it means that porting SOM to Linux should be simple.
If this is such a great idea, why hasn't Linux already had its own OO system? Well, actually, there have been such attempts. The best known of them was probably GNOME's Bonobo. It didn't really go much of anywhere.
Bonobo ran out of steam not because the idea was wrong. The idea was fine. Indeed, like SOM, Bonobo was based on CORBA. The problem was that creating an OO framework is enormously time-consuming and difficult. Once an OO framework and its libraries are built, it's easy to use, but the upfront costs can be a killer. With SOM, of course, that's not a problem. That work has already been done.
Of course, for any of that to make a difference for Linux, SOM would need to be open-sourced. That shouldn't be a problem. IBM hasn't used SOM in a product in ages. Since SOM is just collecting virtual dust, why shouldn't IBM open-source the code?
Heck, IBM doesn't even need to release or clean up the development tools. Linux is loaded with developer tools. Just open-sourcing SOM alone, with perhaps some demonstration widgets, would be all that it would take.
Would the result look anything like OS/2? No, not at all. But what it would do is give Linux an outstanding OO framework that would go a long way toward making desktop Linux much more attractive to ISVs, and those applications would help make Linux even more interesting to desktop users.
Oh, and, IBM, since SOM can also be run in a network-aware DSOM (distributed mode), it would make integrating Linux desktop and IBM middleware running on IBM servers, especially the AIX and z/OS hardware, very easy for enterprise customers. Need I say more?
-- Steven J. Vaughan-Nichols
Do you have comments on this story?
Talkback here NOTE: Please post your comments regarding our articles using the above link. Be sure to use this article's title as the "Subject" in your posts. Before you create a new thread, please check to see if a discussion thread is already running on the article you plan to comment on. Thanks!
Related Stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|