[...] Lets drop web browser and KDE
for a while and say this: there are cool, interactive scientific
visualisation tools I would like to use along with fossil+venti
infrastructure and Plan 9 tools and I would like to see them
integrated with each other really well. As I said, it is absolutely
impossible to reinvent everything again, so the question is how to
integrate the already existing applications for UNIX and Plan 9. I
vote for emulation.
I beg to differ. And I will take a real, named example: Public domain
CERL G.R.A.S.S. (GIS software), transformed in GPL G.R.A.S.S., and,
since 2004, KerGIS, with the core under a BSD like license.
This is a huge beast. The original CERL version did not compile anymore
(it was dropped in 1992). It had a new Motif interface that was more
than 7 MBytes of code---did not compile; was a mess I did even not tried
to fix.
When the software was running, what it does was terrific. Altogether,
the ``conservative'' approach you express has led to GPL GRASS. More and
more, since the code base is huge and since the original worked, and
since it is not admissible to reinvent the wheel, but too difficult to
maintain, they drop part of the system, ``externalize'' parts, relying
on third parties software.
The motto is: precious but too huge to maintain, so let change the
minimum and drop what is not understood anymore.
My motto is: reorganize and redevelop it so that it is maintenable
(french origin: able to be held in hand).
On the one hand, the bazaar: so-called tens or hundreds of people
belonging to a ``community'' (really a handful of people really working;
many more discussing).
On the other hand, a single person: myself.
The result is that redoing, thinking about what makes sense and in
particular the split between terminals and CPUs (more and more today,
since a real, heavy computing system is a specialized beast, out of
reach of small entities, unless they can share it, i.e. buy some "shared
time" on some remote computing center), I have remade a lot of things
(not finished yet).
The last in time result is the split between computing and accessing,
with the generation of a 2D interface to _represent_ data and commands
(push a button instead of typing line code) independent of computing,
allowing to use KerGIS not only on Unix, but on any other type of system
(my goal is to allow KerGIS to run natively on Plan 9 or derived systems
or any other system with a C compiler with the minimum of system
dependent stuff).
So KerGIS is now _less code_ than CERL GRASS or GPL GRASS, but with more
features than the original, more than GPL GRASS 5.x (comparison is more
difficult with 6.x that I don't know), more maintainability, more future
potential.
And for the example of the Motif interface, that was
everything melt in CERL GRASS, and just a backend in KerGIS for the GiG
(Graphical interface Generation) numbers are:
CERL GRASS (in Kbytes):
7470 cerl/src/xgrass
KerGIS (in Kbytes):
316 kergis/bin2/monitor
being under KerGIS 4 CWEB files (Donald E. Knuth and Silvio Levy
litterate programming, C for code and TeX for explanations), that is a
great part of documentation: the library, handling geometrical elements
(representations in graphic coordinates and keeping identity of
individual elements---redrawing, changing color etc is local to the
terminal since the informations are kept), a X11 low level back-end,
a Motif implementation of the toolkit for GiG, and GiG.
One has not to reinvent the wheel if it is a wheel: the best simple
thing. But if this is a wheel, it can be ported easily to other system.
If portability is difficult, this is because what ``works'', nolens
volens, is not a wheel. This is time to engineer the thing to invent a
wheel doing the stuff.
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C