From mboxrd@z Thu Jan 1 00:00:00 1970 From: tlaronde@polynum.com Date: Thu, 24 Jan 2008 14:38:40 +0100 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Re: Building GCC Message-ID: <20080124133840.GA2385@polynum.com> References: <20080123111516.GB12528@paju.oulu.fi> <8fbf4ceb-5334-4fa0-8b96-1c31cd6225f7@k2g2000hse.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8fbf4ceb-5334-4fa0-8b96-1c31cd6225f7@k2g2000hse.googlegroups.com> User-Agent: Mutt/1.4.2.3i Topicbox-Message-UUID: 35d570c6-ead3-11e9-9d60-3106f5b1d025 On Thu, Jan 24, 2008 at 09:41:02AM +0000, pavlovetsky@gmail.com wrote: > [...] 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) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C