|
 |
Turbo Screen Sharing
Adobe Acrobat Connect Professional offers users the ability to have a more productive and engaging web conferencing experience while providing the IT department with a program that efficiently utilizes bandwidth and minimally impacts the infrastructure. Learn More!
»
Informal Learning: Extending the Impact of Enterprise Ideas and Information
Forward-thinking organizations are turning to enterprise learning in their quest to be better informed, better skilled, better supported at the point of need, and more competitive in their respective marketplaces. Learn More! »
Rapid E-Learning: Maturing Technology Brings Balance and Possibilities
Rapid e-learning addresses both time and cost issues by using technology tools to shift the dynamics of e-learning development. Learn why more skilled learning professionals use these tools and how you can get a solution to keep pace with your business demands. »
Delivering on the Promise of ELearning
This white paper defines the framework to launch e-learning as a set of teaching, training, and learning practices not bound by a specific technology platform or learning management system. It offers practical suggestions for creating digital learning experiences that engage learners by building interest and motivation and providing opportunities for active participation. »
|
 | |
.comment: Something for Everybody
The Resurrection and the Light

Dennis E. Powell
Wednesday, April 18, 2001 07:46:29 AM
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.
Next: Why This Would Help Everybody »