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

Re: Announcement: Debian Pure Blends news

On Mon, 2008-11-10 at 13:28 +0100, Andreas Tille wrote:
> On Mon, 10 Nov 2008, Neil Williams wrote:
> > I guess what are talking about here is the mirrors. Do all Blends use
> > unchanged Debian mirrors?
> Yes.  What else would you expect if it says _inside_ Debian?  A Debian
> Pure Blend has no separate mirror - THIS is the basic idea of the concept.

That is where I found "Blends" confusing - it conjures up images of
mixing two different things into one. What you are describing is (to me)
more filtering or remixing, not blending. Maybe it's my professional
bias - I'm used to doing admixtures, blends, compounding and formulation
and the terms have quite specific (pharmaceutical) meanings.

A + B = C (blending A with B to make a new, bigger, C)

(Think blending chocolate into cake mix to get a chocolate cake or
blending a strawberry flavour into a cough mixture. What you get has a
larger volume/mass.)

What Blends is describing is actually something that is not possible
with "real-world" blending - substituting a strawberry flavour for a
raspberry flavour in an existing product - quite possibly reducing the
total volume/mass of the final product.

It works because the "product" (Debian) is itself a mixture that has
both flavours available and the blending happens *before* the real-world
product (the installation) exists:

D = (A + B + C)
M = (A + C)

where D == Debian and M could be Debian Med. Yes, A and C are being
blended together but they are already blended together in the bigger D -
it's just that D comes with B as the default and C as optional. (i.e.
anyone can install normal Debian and then install the Med packages on
top, what Debian Med wants to do is install the Med packages by default,
skipping the bits that are not necessary.)

That's more like deciding whether to make the cake with icing only in
the middle instead of jam in the middle and icing on top. Shuffling
components around and tweaking to make it fit. What Emdebian Grip does
is make a smaller cake, still with the jam and icing, whilst still
allowing you to skip the icing if preferred. (Emdebian Crush makes a
very small gluten-free cake without jam or icing - fundamentally
changing the nature of the result by modifying the ingredients

What M is doing is "raising the priority" of C so that it becomes the
default install, ahead of B. I can see that being useful in Emdebian

Blending is a form of adding and mixing.

Blends appears to be about subtracting, remixing and customising.

In this respect, a Blend that prioritises XFCE ahead of GNOME and/or
ext2 ahead of ext3 would be a useful basis for Emdebian Grip.

There is still a grey area though - someone could easily run the
Emdebian Grip scripts on a Debian Med install after downloading from the
normal Debian mirrors, in order to reduce total installation size
without the benefits of reducing the cache data sizes. Indeed, the
scripts could run as a hook within the download process. Thankfully, I
don't think many people will want to do that (at least not for the
majority of packages) because it is quite wasteful of bandwidth and CPU

The disjuncture here is similar to how colours are blended in printers
versus in images. A printer / painting palette is closer to my
understanding of blending - you can only add, not subtract, so colours
get closer to black the more blending you do. An image palette works the
other way, the more colours you blend, the closer you get to white.

Blends works on RGB (light), blending works on CMYK (ink).

It is this topsy-turvy understanding of "blend" that was confusing me
and may well confuse others.

> > If so, what are Blends blending?
> All mixtures are inside the Debian package pool.  Out of these mixtures
> we want to fit the taste of a certain user group.


> So for you Emdebian was, is and will be a Debian Internal Project which
> is listed at the place where it belongs to.  This is what I wanted to
> say when I asked for having a look at the doc[2] - the name is choosen
> for a concept Emdebian does not really fit into.
> To say it once more: I like your Emdebian effort but it is orthogonal
> to the user specific field scope.  For instance: We might consider
> an Emdebian Med for medical stuff using embedded devices (which is in
> fact very interesting).

I'd never have thought about Emdebian Med - don't know why, but I always
had the impression that Debian Med packages were quite large. There is
certainly scope for such a variant. 

> > I'm hoping that Grip will be seen differently - as a normal Debian
> > install, just smaller. Whatever changes might be necessary to actually
> > deploy Grip, I will be seeking to fold those changes into the relevant
> > Debian packages.
> I hope you do not feel discriminated - but it is just not true that
> every project inside Debian now has to use the name we have choosen
> for a specific internal concept.

I'm just trying to get it straight in my head. :-) Several people asked
me why I wasn't involved in the CDD (as was) discussion at DebConf8 and
I wasn't 100% sure myself, at the time.

I think I have it now though - Emdebian is one or two steps on from what
is now called Blends and Emdebian can use a Blend as a basis for a
flavour of Emdebian Grip.

Debian -> Emdebian Grip -> Emdebian Crush
or for Emdebian Med:
Debian -> Blends -> Emdebian Grip


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: