.comment: Something for Everybody
The Resurrection and the Light
It's entirely unplanned but a kind of neat coincidence that it's Easter week and here I am talking about an operating system back from the dead and what Linux can learn from it.
The operating system is IBM's perennially crippled OS/2. It's back in the form of a very good system with a very bad name: eCommerceStation. I have a beta here, and it works very well. It's an updated OS/2 Warp4 with lots of good applications, some very interesting network-centric stuff, and the letters "eCS" everyplace older versions had "OS/2." It's published not by IBM but by a company called Serenity Systems.
The name suggests that eCommerceStation is designed to run Web sites or something like that, but it's actually a really good LAN operating system. It comes with Lotus SmartSuite (1.5 in the beta; 1.6 in the release version due in the next month or so), StarOffice 5.1 for OS/2, Netscape 4.61 for OS/2 (the release version will have Warpzilla, a Mozilla port apparently done by IBM; the version I downloaded yesterday works very well), and a world of network administration stuff, as well as VoiceType, the speech recognition system. Technically exciting are the addition of IBM's Journaling File System and a Logical Volume Manager. It's an interesting update, and if you have an OS/2 license it is a lot cheaper than the sum of its parts at $139 from Indelible Blue.
But what really appealed to me is a program called "Wise Machine," published by an outfit called TouchVoice Corp. This program is not so attractive for what it does (it's beta-ness is evident) but what it suggests. It is, based on what I could figure out about it in that it is utterly undocumented best I can tell, a kind of supreme package manager. Unlike the Wise and UnWise stuff found in Windows, which appears on an application-by-application basis, this thing is installed once and handles tasks for all the apps on the machine. Use it to install your applications and it will keep track of what it has done. This makes keeping an accurate inventory easy. It also eases removal of applications. And moving an application from one place to another is a drag-and-drop operation with this application. (This is what I've gathered from playing with it a little; again, the documentation isn't there.)
What struck me is that this is exactly the kind of thing that Linux very much needs.
Not a Package Manager -- a Super Package Manager
We have package managers. Distributions have their own varied flavors of packages and applications to ride herd on them, all of which are easily broken. Attempts to admit compilation from source, such as SRPMs and Debian rules, are kludgy and weird.
Now imagine: Let's think of an app that when you open it displays a listing of all packages you have installed, be they RPMs, DEBs, whatever YaST packages are called, binary tarballs from the Slackware realm, or stuff you compiled locally. That in and of itself would be pretty cool. But let's take it a step further. Let's give it the ability to actually manipulate these packages and to do so entirely transparently, without regard to the form in which they arrived.
That would, actually, be pretty simple to do. All you'd have to do is trap the output of the various packages as they tried to report to their respective package managers and fold that output into a grand master database. Enhancements might involve the ability to redirect a package, so that those possessed of sanity who don't want their desktop flung into /usr would be able to put it in /opt, where it belongs, and put associated stuff there, too. (As a sop to those who still think there's money somehow in delivering updates, yeah, you could send it out on the Web to seek dependent packages or updates; I know that Debian already does this, but there are a couple of companies who plan to prettify it and do it for money.)
The real trick would be to include things built locally. But it could be done.
The method that comes to mind and that seems the most elegant would be an integrated console in which applications could be compiled; it would then trap the output of "make install" and add it to the database of which package put what where. I've thought for awhile that a little X or console application would go far in making compilation easier for newbies, and this might be the place to put it. Still, XFree86 sops up a lot of memory and processor, so it would make good sense to have an application that would simply be started in a pure console session before one did ./configure -- it could even be an alias named ./configure that started itself and then started configure -- inside of which one would build the application at hand and which would trap, again, the output of "make install."
Maybe there's a reason why this wouldn't work, but I can't think of it.
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.