Table of Contents
The core of an operating system is a piece of software that interacts with the hardware of the computer, and provides basic functionality for several applications. On Linux based systems, the so-called kernel provides this functionality, and the term Linux just means this core without those applications that provide the functionality for users. Other examples are the Hurd, or the flavours of the BSD kernel.
Many applications around UNIX-like kernels are provided by the GNU system. That is why Linux based operating systems are described as GNU/Linux systems. The GNU tools around the Linux kernel build a complete operating system.
Users do not need only an operating system. They also need certain applications like web servers, or office suites. A distribution is a collection of software packages around the GNU/Linux operating system that satisfies the needs of the target user group. There are general distributions, which try to support all users, and there are several specialised distributions, which each target a special group of users.
Distributors are those companies that are building these collections of software around the GNU/Linux operating system. Because it is Free Software, the user who buys a distribution pays for the service that the distributor is providing. These services might be:
Preparing a useful collection of software around GNU/Linux.
Caring for smooth installation that the target user is able to manage.
Providing software updates and security fixes.
Writing documentation and translations to enable the user to use the distribution with maximum effect.
Selling Boxes with ready to install CDs and printed documentation.
Offering training and qualification.
Most distributors ship their distribution in binary packages. Two package formats are widely used:
which is supported by RedHat, SuSE and others.
used by Debian and derived distributions.
All GNU/Linux distributions have a certain amount of common ground, and the Linux Standard Base (LSB) is attempting to develop and promote a set of standards that will increase compatibility among Linux distributions, and enable software applications to run on any compliant system.
The very essence of any distribution, (whether delivered as RPMs, DEBs, Source tarballs or ports) is the choice of policy statements made (or not made, as the case may be) by the creators of the distribution.
Policy statements in this sense are things like
"configuration files live in
/etc/$package/$package.conf, logfiles go to
/var/log/$package/$package.log and the documentation
files can be found in /usr/share/doc/$package."
The policy statements are followed by the tool-chains and libraries used to build the software, and the lists of dependencies, which dictate the prerequisites and order in which the software has to be built and installed. (It's easier to ride a bicycle if you put the wheels on first. ;-) )
It is this adherence to policy that causes a distribution
to remain consistent within its own bounds. At the same time, this is
the reason why packages can not always be safely installed across
distribution boundaries. A SuSE package.rpm might not
play well with a RedHat package.rpm, although the
packages work perfectly well within their own distributions. A
similar compatibility problem could also apply to packages from the
same distributor, but from a different version or generation of the
distribution.
AT: The context is somehow missing here. As you will see later in more detail, Debian Pure Blends are just a modified ruleset for producing a modified (specialised) version of Debian GNU/Linux.
A package management system is a very strong tool to manage software packages on your computer. A large amount of the work of a distributor is building these software packages.
Distributors you might know are RedHat, SuSE, Ubuntu and others.
Debian is just one of them.
Well, at least this is what people who do not know Debian well might think about it. But, in fact, Debian is a different kind of distribution ...
The Debian Project is an association of individuals who have made common cause to create a free operating system. This operating system that we have created is called Debian GNU/Linux, or simply Debian for short.
Moreover, work is in progress to provide Debian of kernels other than Linux, primarily for the Hurd. Other possible kernels are the flavours of BSD, and there are even people who think about ports to MS Windows.
All members of the Debian project are connected in a web of trust, which is woven by signing GPG keys. One requirement to become a member of the Debian project is to have a GPG key signed by a Debian developer. Every time one Debian developer meets another developer for the first time, they sign each other's keys. In this way, the web of trust is woven.
Debian is not a company, but an organisation.
It does not sell anything.
Debian members are volunteers.
Maintainers are working on the common goal: to build the best operating system they can achieve.
Debian maintains the largest collection of ready-to-install Free Software on the Internet.
There are two ways to obtain Debian GNU/Linux:
Buy it from some other distributor on CD. Perhaps the correct term would be redistributor. Because Debian is free, anybody can build his own distribution based on it, sell CDs, and even add new features, such as printed documentation, more software, support for different installers and more.
Download Debian from the web for free.
The latter is the common way, and there are really great tools to do it this way. Certainly it is always possible to copy Debian from a friend.
Debian contains nearly 22.000 binary packages, and this number is constantly increasing. There is no single user who needs all these packages (even if conflicting packages are not considered).
The normal user is interested in a subset of these packages. But how does the user find out which packages are really interesting?
One solution is provided by the tasksel package. It provides a reasonable selection of quite general tasks that can be accomplished using a set of packages installed on a Debian GNU/Linux system. But this is not really fine grained, and does not address all of the needs of user groups with special interests.
Debian Pure Blends - in short Blends if used clearly in the Debian internal context which makes "Pure" and "Debian" obvious - which were formerly known as Custom Debian Distributions (this name was confusing because it left to much room for speculation that this might be something else than Debian) try to provide a solution for special groups of target users with different skills and interests. Not only do they provide handy collections of specific program packages, but they also ease installation and configuration for the intended purpose.
Debian Pure Blends are not forks from Debian. As the new name says clearly they are pure Debian and just provide a specific flavour. So if you obtain the complete Debian GNU/Linux distribution, you have all available Debian Pure Blends included.
The concept of what is called Blend in Debian is also known in other distributions. For instance in Fedora there are Special Interest Groups (SIGs) even if some SIGs in Fedora are what in Debian is known as internal project because it is focused on technical implementations and not on user-oriented applications.
Not necessarily all currently existing Blends are actually providing installation media (live media or installer). The reason for this is that such installation media are not always necessary / wanted. You can just install plain Debian and install some metapackages on top of it. However, the metapackage approach makes the creation of installation media quite simple by using Debian Live. Here are some reasons for this approach compared to a remastering strategy.
The process for creation of a blend involves starting with a Debian or derivative repository and creating an image directly from that (live, install or otherwise) that contains a selection of material from that repository delivered in such a way that it is usable by a particular target user for a particular purpose with a minimum of effort.
By contrast, the process of remastering generally involves first downloading an image produced by the parent distro (live, install or otherwise,) then tearing it apart and reassembling it with your customizations applied.
The blends philosophy is to work as closely with the parent distro as possible. If possible, the project should be done entirely within the distro as a subproject, containing only material supplied by the parent distro. We call this a "Pure Blend".
The remastering philosophy (if it can be called that) seems to be "whatever works" and involves little or no interaction with the parent distro. It's a lazy approach used by people who have newly discovered that they can hack images to make them into custom images to make something uniquely theirs. Probably fine for quick-and-dirty results, but hard to support in the long run.
The users of a blend are served better than the users of a remaster because of the following advantages:
A new version of a well-crafted blend ought to be able to be produced at any time directly from the repository simply by building it; the user has some assurance that the resulting system remains 'untainted' by hacking it up with scripts that 'damage' the original system by removing files from packages, changing files in packages, etc. something that hurts maintainability / support for such a system.
A blend project aims to leverage support resources from the existing community to serve some sub-community within it. They accomplish this by not violating Debian packaging policy, producing something that is either pure Debian (a "pure blend") or Debian + additional packages, rather than some frankendistro artlessly stitched together from someone else's distro with scripts that change things everywhere with no regard to policy. Thus, normal support channels can be used with a pure blend since what you end up with is not a derivative at all, but just Debian, set up and ready to go for whatever you wanted to use it for.