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 themselves.) 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 too. 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 resources. 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. ok > 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part