[TriLUG] Flowe Desktop Questions

[Tan T. Phan]

 >Subject: Re: [TriLUG] Flowe Desktop Demo - Thank you
 >From: John Matthews <jvmatthe at math.duke.edu>
 >To: trilug at trilug.org
 >Date: 11 Jan 2002 16:43:46 -0500
 >
 >On Fri, 2002-01-11 at 16:32, Tan T. Phan wrote:
 >
 >> As for the actual work on Flowe Desktop and its foundation 
technology, I
 >> did all of the work -- nights and weekends from 1988 to 2000, and
 >> full-time in 2001. There are only about 500K lines of C++ code for the
 >> product -- quite slim compared to many Linux projects.
 >
First correction: Flowe got started from 1998, not 1988 -- My typo!

 >
 >I had some questions I didn't ask last night. On the assumption that
 >you're hanging around here enough to answer them for the list...
 >
 >1) While I can agree that Flowe seems to match in many ways the Win9x
 >experience, do you have plans to mimic WinXP? I recently had some
 >run-ins with WinXP and the guts of the OS are even *MORE* hidden from
 >the user by default. Since many users won't change from the default, it
 >seems to me to be a gargantuan task to get Linux up to that level of
 >abstraction. Have you thought about this at all? If so, could you share
 >those thoughts with us?
 >
Flowe will strive to match what XP offers.  It will take a year or
so before XP become more widespread and I hope to have Codeflex's
infrastructure ready for such task by then.  If not I just have to
do it myself.  :) I really want Linux to succeed in the office
desktop and home markets.  I strongly believe that Linux will
eventually be in the hands of everyday computer users, not just
professionals like ourselves.

 >2) What kinds of feelings do *you* have personally about the code and
 >the license it will have? I realize that if someone buys it from you,
 >then it could very well be GPLed or locked up or something inbetween.
 >How would you want it to go, if you could decide and still get paid what
 >you want to get paid?
 >
I personally like the GPL model.  But you know that saying about
"who has the most money has the last say" (or something similar to
that)...  That will be true in my case for I have the vision, the
drive, and the technology, but not the money.  :( Whatever it takes,
as long as it helps Linux penetrate the desktop markets and
Codeflex's family members can support their families, I am game.

 >3) You touched briefly on porting last night. How much have you
 >investigated porting to other UNIX-ish systems? I'm curious, by asking
 >this, about whether there are any Linux idiosyncrasies built into Flowe
 >that would be problematic when going to another system, like one of the
 >BSDs.
 >
I've been in the porting business for years -- from Windows to
Unices to OS/390 mainframe (not Linux on VM, but real USS on MVS
with accesses to data sets, JES queues, and all other old but good
stuffs...) Some Unices are closed to Linux than others.  As I code,
I pay attention to a few things, listed below in order of
importance:

1. Documentation
2. Performance
3. Accuracy
4. Modularity for code re-use
5. Layering to simplify possible ports (because I never say "never")

Since I have some experience in porting, I just know by heart that
certain operations/functionalities are not portable and I simply
layer around it for OS-specific implementations as I come across
them.  In a desktop environment like Flowe, porting issues exist at
all levels -- system calls all the way up to user-level
applications.

A simple example would be directory traversal where the code is
different for threaded and non-threaded OS.  Another example would
be avoiding the use of hardcoded literal character ranges like 'A'
to 'Z' because such code will not work on EBCDIC OS like OS/390.
Little/Big endian is another.  I simply code differently to avoid
these.

In another example, at a higher level, some porting problem areas
exist in the System Monitor application because the application
makes heavy use of the /proc file system whose elements are
different from OS to OS or that the /proc file system may not even
exist on some OS.  Not much I can do here but to layer the code.

Further up as another example is the accesses to the printer and
time tools which are different from one Linux distro to the next,
and sometimes, even between versions of the same Linux distro.  Not
much I can do here but to layer the code.

But because my goal is the expansion of Linux into the office and
home desktops, and not the expansion of Solaris, AIX, HPUX..., I pay
less attention to these porting issues -- as compared to my port of
Visual SlickEdit since it exists cross-platform.  Nevertheless,
because deep down inside me where I never say "never", the code is
written in such a way to make porting easier if and when that day
comes.

 >That's it, for now. :^) Hope you can take a second to post some
 >responses, even if it's just "no comment".
 >
 >Regards,
 >matt
Please let me know if I can answer other questions.

Sincerely,
-Tan