Re: Neurodebian tasks (and Debian Science)
On Wed, Apr 06, 2016 at 10:05:56AM +0200, Ole Streicher wrote:
>
> I think that both is useful. Sure, there are many users who want to have
> a detailed list of choices and do an educated selection.
>
> However, there are also reasons for a "simple" way: if one has no glue
> where to start with, for example. Or if one has no time (or doesn't
> spend it on a carefule package selection). Since today disk space is
> cheap, I also tend to just install everything I *could* need -- as long
> as there are not conflicts to expect (and Debian is pretty good with
> this).
ACK. An additional point is: If you install everything quickly users
could start working quite quickly. Removing afterwards what is not used
(may be there is a tool that detects this or if not the popcon data of
the local machine will answer the question what is not used) can be done
while users are just working.
> > Are you aiming to provide that level of granularity within debian
> > installer? if so -- that would be cool.
>
> Sure, I am also unstatisfied with the current state. There is currently
> no way to select individual packages during the installation and also
> not with tasksel, and I would guess that this will stay so for Debian
> Stretch. However, once we have our "foot in the door" (that's probably a
> "False Friend" in english), we have a good reason and pressure to get
> something. We just need volunteers ;-)
>
> But let's be pragmatic here. The proposed solution is not ideal, but it
> is a step forward, and something realistic.
+1
> >> Wouldn't it make sense to move out the specific tasks (...) into
> >> the "neurodebian" package (and remove it from debian-science)?
> >
> > Do you consider neuroscience not a science? ;)
To follow Yaroslav's logic Ole also does not consider astronomy a
science since the astronomy tasks are basically removed. :-P
> > Or is debian-science
> > blend is solely to collect all other sciences which haven't
> > found/established their own blends? and as soon as they do, new
> > naming/packages arrive etc...
>
> I see Debian Science as a kind of "umbrella" for
>
> * blends that are connected to science.
> * science tasks that still didn't find an own blend
... or maintainers who are brave enought to create an own Blend. This
reminds me to my talk at DebConf 13 where I was asked by Asheesh if I do
not want to run around and ask people: "Did you created your own Blend
today?" :-)
> So, my ideal structure of Debian science would be:
>
> Debian Science
> +-- Debian Astro
> | +-- Astrononomy Catalogs
> | +-- Data Viewers
> | : ... packges specific to astronomy
> |
> +-- Debian Med
> | : ... packages specific to medicine
> |
> : ... other science blends
> |
> +-- Biology
> +-- Physics
> : ... other science tasks that are not in a specific blend
Nitpicking: Debian Med has way more in the field of Biology than what
most people would clearly address as Medicine. :-)
> > that somewhat points to our "concern" with current approach on blends
> > -- pretty much attempt to impose separate hierarchies wherever
> > structure is more of a tag cloud (single software/task could be a
> > part of multiple blends).
>
> In theory this is true; however in the moment we don't have so many
> blends that a hierarchy would be unsuitable. There already was some work
> by Andreas Tille to cross-link between tasks (@Andreas: could you tell
> the state here?),
We need to migrate to tasks_udd.py and than this feature could probably
easily implemented. We also should migrate to the UDD based blends-dev
which allows similarly easy implementation.
> > I am not sure what such a default blend should carry really... how
> > could I decide for a lab to use e.g. AFNI vs FSL vs [...]
>
> Neurodebian already offers a bootable image, and a default virtual
> machine -- so you already *have* some idea of a default installation.
>
> Why not just take this?
+1
And by the way: We should develop bootable images and default virtual
machines based on the Blends tasks. If Neurodebian would finally agree
to this we might get more manpower to implement this. (I wonder how
often I mentioned that we should join forces amongst people who are
doing in principle the same thing just for different fields ...)
> I see two arguments for the solution with "default" installations:
>
> 1. Provide a simple, low-threshold installation that "just works" for
> those who like or need this
>
> 2. Promote the blend(s). Everyone who installs Debian will see that
> there is NeuroDebian (and Debian Astro etc.), and will think whether
> this is something he could be interested in.
+1
> >> A "neurodebian-tasks" package would be useful as well so that
> >> people could use tasksel to install additonal NeuroDebian tasks (or
> >> to remove them if not needed).
>
> Sure. And, once there is some need, maybe we find a solution how a user
> can nicely select individual packages for his blend. But we should not
> wait until this happens.
+1
> > I see pretty much tasks which would be nearly a single package tasks
> > pointing to most common neuro- toolkits so a new user could
> > immediately recognize familiar/necessary tools to be installed. [...]
>
> Sure, it is your structure :-) I would however not start with the
> perfect solution, but with the structure that is already there, and
> improve it.
+1
> > Sorry if it is all non-constructive and more of a whining ;)
>
> As long as we move forward, that's fine for me ;-)
I'm so happy that Ole somehow is expressing what I always tried to
express in several discussions - hopefully with more convincing words.
:-)
Kind regards
Andreas.
[1] http://saimei.acc.umu.se/pub/debian-meetings/2013/debconf13/low/987_How_to_attract_new_developers_for_your_team.ogv
--
http://fam-tille.de
Reply to: