[Gllug] Thoughts on the breadth of Free Software

[salsaman]

Tethys wrote:

>Tom Schutzer-Weissmann writes:
>
>  
>
>>How about
>>
>>- A multi-user, multi-cursor X server.
>>
>>- Handwriting recognition.
>>    
>>
>
>Or:
>
>- A web browser that doesn't suck
>  
>
Dillo ?


>- A rapid application development environment sitting on top of one of
>  the free databases (c.f., DataEase, Access, etc.) What in times gone
>  by might have been called a 4GL.
>
>Or for something a bit less ambitious:
>
>- Add pivot tables to gnumeric
>- Help out with DaveJ/Arjen's crusade to slim down userland
>- Sort of the packaging dependency hell prevalent in most distributions
>
>To expand on the last one, specifically, remove unnecessary
>dependencies. Should I need to install a CD burning GUI just to view
>a PostScript file? Not really, no. But because the evince package
>doesn't split out its optional features into separate packages, that's
>how it is under Fedora[1]. Similarly, I tried to install Konqueror the
>other day to verify how some of my web pages looked in an alternative
>browser. I really shouldn't need over 30 additional dependencies and
>over 100MB of downloads just to do that. It's not a Fedora specific
>problem, either. Much GNOME and KDE software (to pick the low hanging
>fruit) has unreasonable dependencies in most distributions. Fixing this
>is mostly a case of splitting the package into multiple packages --
>instead of a "foo" that includes the kitchen sink, you'd have "foo-base",
>and "foo-blah-extension", "foo-gronk-extension", and "foo-kitchen-sink".
>
>  
>
Not so easy. I know from experience as a developer. To do so would 
require an install of each distro, you'd need several machines - or at 
least a machine with all the main distros: suse, redhat, fc, gentoo, 
mandriva, debian, ubuntu, etc.
Then you would need to know the compile options for each package. For 
example, for LiVES, you can compile it with or without libjack. But then 
it's not obvious without looking at the compile options, ./configure 
--disable-jack

Then add to this that there are probably 4 different things that can be 
disabled or enabled, e.g. --disable-mjpegtools, --disable-jack, 
--disable-libvisual, etc. You would end up with about 16 different 
combinations, e.g. LiVES-with-mjpegtools-without-jack.rpm. Believe me, 
if you think it's confusing now, it would be worse with what you suggest !

You would have to then compile all those 16 different versions, and 
upload them somewhere

To make things less confusing for the user, you would have to update the 
packaging system for each distro. E.g. for mandriva:

urpmi LiVES

- do you want libjack support ? (Y/n/help)
- do you want mjpegtools support ? (Y/n/help)

If you type help (or h), it would say, e.g:

libjack support : jack is an audio connection framework. In LiVES it 
allows for better audio/video synch, and to connect LiVES to various 
audio instruments.
It would require the following additional packages: libjack, ... (10Mb)

Given that debian has about (I think) 50,000 packages, you would have to 
look at the configure.in script for each package, look at the options, 
and work out which dependant packages each option affects. Then from 
this you build 16 builds (assuming just 4 switches). 16 X 50,000 = 
800,000 compilations (i.e. 750,000 new packages, which would all need 
testing). Then you need to update the .deb packages for each of the 
50,000 packages and add the explanation as per my example above.



A simpler way would be this:
update the package system for each distro to take options as mentioned 
above. Grab the user's options, and build the package on-the-fly, 
tailored to their architecture/CPU. Then download the package. But still 
there is a problem. If I then install a second package, I can tell that 
the first package is installed, but I don't know with which options.


Perhaps this gives you an insight as to why it hasn't been done before.


-----------------------------------------------------------------------------------------------------------------------------------------------------


What would be more useful:

- speech recognition (at least basic) - AFAIK there are no such open 
source projects.

- function and variable name auto-completion in EMACS

- provide a nice GUI frontend to gdb

- autoheader : look at some C/C++ code, and work out which header files 
should be included where, to produce the minimum amount of includes:

e.g.

A.c includes A.h and X.h
B.c includes A.h, X.h, and B.h

(5 includes)

clearly this can be simplified: if X.h includes A.h, then we get:

X.h includes A.h
A.c includes X.h
B.c includes X.h and B.h

(4 includes) - this makes the code easier to read.



Gabriel.
http://lives.sourceforge.net



-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug