98 lines
4.8 KiB
HTML
98 lines
4.8 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<title>The Linux User LG #36</title>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#A000A0"
|
|
ALINK="#FF0000">
|
|
<!--endcut ============================================================-->
|
|
|
|
<H4>
|
|
"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<H1><font color="maroon">The Linux User</font></H1>
|
|
<H4>By <a href="mailto:bpcolema@uncg.edu">Bryan Patrick Coleman</a></H4>
|
|
</center>
|
|
<P> <HR> <P>
|
|
|
|
Who uses Linux? This question has changed as Linux evolves. Originally
|
|
none but the ultra hacker or the core developers of the OS were the ones
|
|
to use it. As different functionality got added, more and more less
|
|
technically oriented people began to use Linux.
|
|
<P>
|
|
Now the question is how far will Linux go toward being an OS for
|
|
the end user. The response that is the healthiest for continued growth
|
|
would be as far as one can go. What you say would you turn Linux into a
|
|
next generation Windows. No, but there is more to it than that.
|
|
nifty To effectively become an end user product and keep the hackable
|
|
quality of Linux should be the new focus. That means when developing open
|
|
source software you are developing for everyone from the ultimate power
|
|
user / hacker to the less than average user that may have never used
|
|
a computer before. Yes some people have never used computers before
|
|
still in this day and age.
|
|
<P>
|
|
What does this mean for development? First and foremost make everything
|
|
you possible can configurable. Not just different makes for different needs
|
|
but truly extendable interfaces using guile or python for example. But also
|
|
there need to be defaults. So after your application is installed a user
|
|
can simply start your program and it look polished. As long as your source
|
|
code is available the hard core hacker is happy. But for hacker wouldi-be's
|
|
it is very important that source code is internally documented.
|
|
<P>
|
|
But wait we can go a step beyond simply creating fully configurable
|
|
applications that are extendable and come with default settings. How about
|
|
"smart" applications. Maybe you have installed application A on your system
|
|
and application B comes along from the same people that brought you A. Wow
|
|
you would love to have it so you install it and low and behold all of the
|
|
little tweaks that you have made to A are already configured for application
|
|
B. Since A and B are smart applications they have communicated and B now
|
|
knows what you like. Of course not everyone likes there applications deciding
|
|
what they like so all smart applications should be lobotomyzable.
|
|
<P>
|
|
Now for the real fire. How about all this plus the application is ready
|
|
for immediately distributed computing, not only distributed but PVM aware so
|
|
if you connect to a Beowulf cluster your application is ready to do some
|
|
super computing. Groups can be formed across the web i.e. ready made
|
|
intranet. Security is of course built in so you company or organization
|
|
can just set up there own key and away they go.
|
|
<P>
|
|
Why stop at just X or the console or even Linux. I your application is
|
|
completely system aware no matter where you are or what computer your using
|
|
a person just has to start up there application and it does the rest going
|
|
so far as trying to figure out which way you like your application and if
|
|
your going to be doing distributed work.
|
|
<P>
|
|
In short the new wave of computing will be all things for all people.
|
|
This new approach needs a new name I think. I prefer liquid or fluid UI or
|
|
interfacing framework. Some might think of Java. Java however is slow, slow
|
|
and in the end it is only one library. What I have in mind would be more
|
|
of a set of wrapper classes one for each library used. And one wrapper
|
|
that would handle all of the calls to the widget sets and do all of the
|
|
AI work. This double wrapper approach would cut a lot of the time and
|
|
effort of emulating multiple classes.
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<center><H5>Copyright © 1999, Bryan Patrick Coleman <BR>
|
|
Published in Issue 36 of <i>Linux Gazette</i>, January 1999</H5></center>
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<A HREF="./index.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
|
|
ALT="[ TABLE OF CONTENTS ]"></A>
|
|
<A HREF="../index.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
|
|
ALT="[ FRONT PAGE ]"></A>
|
|
<A HREF="./haldar.html"><IMG SRC="../gx/back2.gif"
|
|
ALT=" Back "></A>
|
|
<A HREF="./ayers.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
|
|
<P> <hr> <P>
|
|
<!--startcut ==========================================================-->
|
|
</BODY>
|
|
</HTML>
|
|
<!--endcut ============================================================-->
|