[Neurodebian-upstream] (Neuro)Debian and Electrophysiology -- Directions? Was: poster copy request

[Yaroslav Halchenko]

Hi Yury, Jan, and all all all,

N.B. Uff... friday... I have managed to discard prepared reply instead
     of sending it out -- thus here is 2nd attempt ;-)

Thanks a lot for chiming in.  Since our primary research modality is
(f)MRI, please pardon my possible ignorance on various aspects of the
research in your domain.  Thus thank you for joining NeuroDebian
discussions.  With your help we hope to organize our workflow and place
proper accents on what needs to be done first for the best benefit to
the community.  Only recently we have started to formalize the
directions we would like NeuroDebian project to follow:

         http://neuro.debian.net/projects.html

Comments, suggestions, fixes (everything is under GIT:
git://git.debian.org/pkg-exppsy/neurodebian.git) are more than welcome
(here or in Disqus comments online).

[Yury]
> It depends on what do you mean by realtime. I think a rough
> classification would include "soft" realtime which can be achieved with
> non-RT kernels and "hard" realtime which you can only achieve by using
> the RT patchset and what follows.
[Jan]
> one should really distinguish between real-time and online electrophysiology.

Indeed my original phrasing was possibly misleading -- we are interested
in various approaches (be it hard real-time or not,  online analysis or
post-processing) which you guys find adequate, fruitful and
popular nowadays in your field.  That is why your comments are so
valuable since we are getting better sense now...

[Yury]
> The main goal of the meeting was to mitigate the NIH syndrome and
> concentrate on developing common standardized components instead of keep
> on re-inventing wheels of different calibers. 

It is indeed a worthwhile goal! Kudos for it.  But judging from our
interaction with random researchers stopping by Debian booth at SfN,  it
is not only "the variety" which hinders the adoption of FOSS setups
(quite often people simply have no clue if there is anything out there
what they could use).  There is a generic problem of domination of
proprietary software systems accompanying the hardware.  Many
researchers get limited in methodologies and suffer for software lock-in
into their proprietary systems/setups.  They simply cannot spare effort
to explore available FOSS alternatives since, despite being out
there, even installation often is not that simple.

> What would really need packaging in my opinion are libraries. Having all
> dependencies and pre-requisites packaged would definitively help a lot. 

and that is indeed part of the problem -- that many systems depend on
3rd party components which might require their manual building as well.
And unless build systems are thoroughly tested across all platforms --
problems might arise at any step.  


As a summary of my blurb above, weak adoption of existing FOSS
projects in electrophysiology seems to be due to the absence of a stable
and popular operating platform providing interesting software
out-of-the-box -- not even talking about deployment across
lab/university infrastructure but just to give things a try, since
'apt-get install' is more comforting than 'get, configure, build' if you
are to try something new or to get fresh updates.

> I am not sure if the packages as such are going to be
> of huge help, since it's generally easier for users to install to /opt
> instead of learning how to rebuild the packages.
> ...
> Often, the hardware is working somehow differently depending on the
> platform and you often need to re-compile after you figure out what the
> differences are etc.

Indeed, tricky cases would be where configuration / tune-up must be
performed at compile time, but with adequate flow of reports back from
users to Debian (us) and upstream (you), we hope that things could
be ironed out so that in the long run build-time customization would not
be necessary.  And if necessary -- it would be simple and robust (that
is why there is a Debian pride of reliable package building)

A side-strategy also could be to converge on a set of hardware setups
which are known to work fine with a specific (i.e. Debian of
cause) software platform.  And SfN experience proved us that
Debian (and its derivatives) is already the primary Linux platform
people use in many pro-FOSS labs.  So the platform choice seems have
been made without our direct advocation.

In the long run benefits for the software from integration into Debian
would be numerous.  As one of them, often disregarded, is that software
included in Debian becomes its "1st class citizen" (unlike in some
derivatives with separate tiers of support for different subsets of the
software archive).  Such status would help to assure that Debian
progress forward (i.e.  library transitions) with consideration to that
included software, so products could be corresponding adjusted before
(not after) transition happens.  This should help to eliminate "build
from source" situations when software evolved independently.

> I can mention at least three systems without doing any prior research:
> 1) NeurOnline (developed at my institution)
> 2) RELACS [1] appears to be the oldest out there
> 3) MEABench [2] more geared towards MEAs

Thanks!  I have added meabench to the relevant task page:
http://blends.alioth.debian.org/science/tasks/electrophysiology#meabench
and placed it on Debian radar:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611363

> I will forward the link to this thread to some of the attendants. Maybe
> if they are interested they can join the discussion or otherwise just
> have a look at it.
Thanks!

Getting back to:

> What would really need packaging in my opinion are libraries. Having all
> dependencies and pre-requisites packaged would definitively help a lot. 

What particular components are still missing/need work?  Comedi library
packaging is getting some face-lifting by its maintainer... RTAI -- does
need some work, but should/will be accomplished since there is need.
Xenomai -- should be considered as a possible alternative...

-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic