[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Regarding a New Project idea for Debian Med



Dear Prakhar, dear Charles,

let me thank you both for your kind project overview and comments

On 05/21/2010 03:08 AM, Charles Plessy wrote:
> Le Wed, May 19, 2010 at 10:56:52PM +0530, prakhar gaur a écrit :
>   
>> A few suggested methods to Optimize Performance:
>>
>>  1. Remove all the unnecessary packages(drivers) -- to make booting fast, to
>>     reduce size of the OS
>>  2. File System -- like btrfs
>>  3. A more efficient Kernel scheduler
>>  4. Memory Management   eg. Bigmem
>>  5. More aggressive package compilation
>>     
> The Debian Med project is built on the Debian Pure Blends concept, which brings
> together unmodified packages through a set of metapackages, that are generated
> from the same material as some of our web documents (our ‘web sentinels’, see
> http://debian-med.alioth.debian.org/tasks/index).
>   
this is of course correct, and with the advent of our cloud efforts, we
are only slightly extending that towards data management.
> For the moment, the Debian Med blend is installed at a step where things like
> file systems have been already decided: basically, the Debian installer is not
> aware of Debian blends. Such development would be very interesting, but it is a
> major piece of work that requres time and skills that are missing.
>   
and there are other parts of Debian these days discussing/dreaming about
what one could do to speed up boot times. Myself I am less interested
(except for my OpenMoko phone) in boot times, since boot time takes a
small fraction of the time that I use the machine. And with an SSD I am
already at or below 30 seconds until the xterm opens. It is an
interesting topic for clouds, though, to increase the flexibility and
reduce latency.
> All in all, it seems that the route you are taking is to make a Debian
> derivative (at least since you plan to change package compilation options) in
> which you would install the Debian Med metapackages. Do not hesitate to comment
> on the contents of our metapackages. In particular, we are considering
> splitting the med-bio package into two, one with graphical programs that will
> depend on X and the other with command line applications.
>   
I would refrain from calling it a derivative. But maybe it is. With
amd64 binaries, -msse is activated by default, but certainly one can
generate more ideas.  Every help towards rendering packages more easily
to optimise and/or cross-buildable for other architecture is certainly
welcome.
[...]
> Lastly, if you package software that are relevant to Debian, you are most
> welcome to maintain them in Debian itself, in our packaging group when the
> topic of the software is relevant to us. We can guide you on how to make
> packages that conform to Debian's quality standards.
>   
Yes, indeed. My suggestion is to check with the local environment in
Bangalore about packages they find missing or that they find difficult
to install themselves or ... just to identify the gaps that Debian has
(it certainly has, otherwise they would already be using it, hey, maybe
they are) to be used more directly or more easily. This could be for
missing packages (you may be very much into structural computing,
to which there are packages that one may want to add) or it may be
the desktop that does not look biological enough for your taste. Or,
following a first impression that you are very interested in more
technical bits, you are very much into GPU or FPGA computing and
want to help out there at various opportunities.

All the best, indeed

Steffen


Reply to: