On Mon, Dec 01, 2003 at 10:55:36AM +0100, Enrico Zini wrote:
> Could you please define precisely "flavours" and "derivative distros"?
Damn, I thought I'd already done that.
Since I evidently didn't, I'm going to spell things out in as much
boring detail as I can. If I don't end up insulting your intelligence,
my apologies. :)
> I see no problems in documenting that the name "Custom Debian" includes
> "Flavours" and "Derivative Distros", and then define what they are.
Okay, IMO there are two techniques worth distinguishing that both aim
to achieve the same goal. That goal is to put a CD (or DVD, or mirror)
in the hands of a user, who can use that CD to get a running, dpkg-based
system that does a particular thing s/he wants, and nothing else. If s/he
wants to setup a multimedia box that records TV programs and acts as an
mp3/ogg jukebox, that's the only sort of software s/he sees -- no web
proxies, no intrusion detection tools, no compilers, no documentation
on setting up RAID arrays and hot-failover. If s/he wants to setup a
fileserver for a small business, s/he might see Samba and Appletalk and
NFS, but there won't be any games or scientific analysis tools available.
The issue isn't so much one of removing those tools entirely -- ideally,
they'll just be an apt-get away anyway -- but of putting the things that
are actually wanted on the first CD (or at least the first few CDs),
and making the installation and configuration process as quick and easy
as possible.
I think "Customized Debian" is a good name for that sort of thing --
it's Debian, but it's customised for particular usage scenarios. If the
usage scenario is common enough, then that's a real win: one person can
do the customisation, and hundreds or thousands can reap the benefits.
> On the other end, I feel that if you see Flavours and Derivative Distros
> as subsets of Custom Debians, then we might have different concepts in
> mind.
Now, there are different possible approaches to this. The most flexible
is to create a "Debian derivative" -- that is, to take Debian, pull
out the bits you like from it, upgrade some things, downgrade others,
recompile some of the stuff that doesn't work quite right, improve a
few things, and add some completely new stuff. That's great, and it's
been demonstrated to work quite well.
The problems are straightforward: if you're writing your own stuff, you
have to manage your own security updates. If you're forked from Debian,
then Debian might make some changes that break compatability with your
stuff, and you might have to think a bit to integrate the changes. You'll
need to find someone to host your images. You can't leverage most of the
Debian infrastructure (BTS, autobuilders in particular, probably).
But there are plenty of benefits too: you don't have to worry about
non-i386 if you don't want. You can set your own policies and not have
to answer to anyone, or convince anyone they're good. You can set your
own schedule. If you've got software that Debian can't distribute (it
costs money per copy or it's internal-use-only, eg), you have to go this
way, to some extent.
So that's what I call a Debian derivative. It's obviously a customised
Debian, but it's customised by taking Debian and adding stuff to it.
While that's by far the most effective way of customising Debian, it's
not the only conceivable way. The other conceivable way to customise
Debian is just to look at all the packages, and rm the ones you don't
care about. If that gives you want you want, you overcome a bunch of
the more annoying shortcomings above: you don't have to do your own
security updates, you don't have to arrange your own hosting, new upstream
releases will be packaged for you without you having to lift a finger,
it'll normally work on all supported architectures without any effort,
and you can file bugs in the BTS without anyone caring that you didn't
install from an *official* Debian CD.
That's what I'm calling a "flavour" of Debian. A different analogy
which makes a little more pedagogical sense is to consider it a "shade"
of Debian -- making the analogy with colours and prisms instead of
taste. Debian, the universal operating system, beams white light at you
all day long, and you put a prism or a filter in its way to get just the
"shade" of Debian that you want. We do this already by choosing which
packages we want on individual systems and setting them up, which is fine;
but what we really want is to be able get a pre-fab filter from the store,
and just plonk it in, so we don't have to bother ourselves all the time.
We can do that to some extent at the moment -- with sections and tasks
and fai classes eg. Which is okay, but it's *far* beneath the level of
coolness provided by Knoppix. And as well, if we get flavours to work
almost as well as Knoppix (creating a livecd that autodetects hardware
and sets you up in a Linux environment with KDE and Gnome and whatever
else, by telling it nothing more than which bits of Debian you want on
that livecd), then that makes maintaining Knoppix a lot easier, since
half the work is already done.
> With my ideas of Flavours and Derivative Distros, Flavours are Custom
> Debians, but Derivative Distros are things like Knoppix which are
> derived from Debian but are not policy compliant, and so they can't be
> called Custom Debians.
I'm not seeing any difference between "flavour" and "custom Debian" in
the above then. I think it's a waste to have words that mean /exactly/
the same thing.
So, using my definitions, the following conclusions are (IMO) true:
* all flavours are policy compliant
* some derived distros might be policy compliant
* you can't always create a flavour to do what you want
* you can always create a derived distro to do what you want
* improving our mechanisms for supporting "flavours" helps derived
distros and their users
* we can improve our support for "flavours" by co-opting many of the
techniques pioneered by derived distros
* a derived distro can be an internal Debian project, but won't ever
be /as/ internal as a flavour
* distributing customised Debian distros is not only the way of the
future, it's the way of the present!
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
Linux.conf.au 2004 -- Because we can.
http://conf.linux.org.au/ -- Jan 12-17, 2004
Attachment:
pgpNjl8JRd5Vk.pgp
Description: PGP signature