Debian Enterprise?
Andres Salomon
left by RedHat, and the possibility of working on a
distribution/sub-project aimed at enterprise folks. The plan is to target
those RedHat users and companies who are unwilling (or unable) to pay for
RedHat Enterprise Linux, but need HA features. Our company falls into
this category, but made the RedHat->Debian switch earlier on.
Currently, we're forced to maintain our own kernels, compile apache/php
from source, and use a few backports to woody. What we really need is:
* a kernel that supports things like IPVS (Linux Virtual Server), UML (the
skas host patch), 64-bit smbfs support, and various other things.
RedHat's kernel had a slew of 2.6 backports, as well as HA stuff thrown in
there. We need something like that (only less extreme; RH liked their
experimental kernel features a bit too much).
* Updated server-related packages; for example, we definitely need a php4
package newer than 4.1.2, and preferably built against apache2.
I can think of a few ways to offer the above. The first is a standalone
distribution, based on debian but with various enhancements (not a novel
idea, by any means). We could either base this on testing, doing snapshot
releases every 3-6 months, and offering security fixes, or
on stable w/ various backports. We would probably
have a stripped-down installer based on d-i, w/ the stock kernel being
similar to redhat's kernel.
Another way would be to have a debian sub-project; this would have a
kernel that includes extra (enterprise) features
(kernel-image-2.4.22-enterprise-1-686smp), amongst other things. I'd also
like to see enhancements to d-i, work done to ease things like php into
testing, and (if based around testing) security updates for testing.
If folks are at all interested in this sort of thing, please let me know.
Our long-term goals for this are to hire a developer or two (part or
full time) to help maintain this project, as long as it's something we
(and our clients) can use and support.
Suggestions are most welcome.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Joerg Wendland
Andres Salomon, on 2003-11-17, 01:45, you wrote:
> If folks are at all interested in this sort of thing, please let me know.
I am. We (the company I am employed with) are running Debian
installations in "Enterprise" environments with focus on HA (failover,
replication und such).
> Our long-term goals for this are to hire a developer or two (part or
> full time) to help maintain this project, as long as it's something we
> (and our clients) can use and support.
I would like to participate in a sub-project. And if you like you are
free to buy development services from us, of course ;-)
Joerg
--
Joerg "joergland" Wendland
GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A F318 57A3 7FBD 51CF 8417
Andreas Tille
> Another way would be to have a debian sub-project; this would have a
> kernel that includes extra (enterprise) features
I would strongly recommend this. The keyword ist "Customized Debian
Distribution". Recently I gave a talk at LinuxDays Luxemburg (a slight
update from my talk at DebConf Oslo). I wished I would find the time
to write a complete article about the slides which are available at:
http://people.debian.org/~tille/debian-med/talks/200311_lux_cust/index_en.html
> Suggestions are most welcome.
Feel free to ask about details if something is not clear about the slides
or any other things are missing. IMHO a debian-enterprise is very much
missing and would be a great enhancement.
Kind regards
Andreas.
Matt Zimmerman
> I can think of a few ways to offer the above. The first is a standalone
> distribution, based on debian but with various enhancements (not a novel
> idea, by any means). We could either base this on testing, doing snapshot
> releases every 3-6 months, and offering security fixes, or
> on stable w/ various backports. We would probably
> have a stripped-down installer based on d-i, w/ the stock kernel being
> similar to redhat's kernel.
>
> Another way would be to have a debian sub-project; this would have a
> kernel that includes extra (enterprise) features
> (kernel-image-2.4.22-enterprise-1-686smp), amongst other things. I'd also
> like to see enhancements to d-i, work done to ease things like php into
> testing, and (if based around testing) security updates for testing.
If the sub-project approach would mean that the new packages and
enhancements would be folded into Debian, then I think that is definitely
preferable. I do not think that basing it on testing is the best approach;
in my experience, enterprises prefer a longer (stable) release cycle than
testing's daily churn.
--
- mdz
Andres Salomon
> On Mon, Nov 17, 2003 at 01:45:05AM -0500, Andres Salomon wrote:
>
>> I can think of a few ways to offer the above. The first is a standalone
>> distribution, based on debian but with various enhancements (not a novel
>> idea, by any means). We could either base this on testing, doing snapshot
>> releases every 3-6 months, and offering security fixes, or
>> on stable w/ various backports. We would probably
>> have a stripped-down installer based on d-i, w/ the stock kernel being
>> similar to redhat's kernel.
>>
>> Another way would be to have a debian sub-project; this would have a
>> kernel that includes extra (enterprise) features
>> (kernel-image-2.4.22-enterprise-1-686smp), amongst other things. I'd also
>> like to see enhancements to d-i, work done to ease things like php into
>> testing, and (if based around testing) security updates for testing.
>
> If the sub-project approach would mean that the new packages and
> enhancements would be folded into Debian, then I think that is definitely
> preferable. I do not think that basing it on testing is the best approach;
> in my experience, enterprises prefer a longer (stable) release cycle than
> testing's daily churn.
Normally I'd agree; however, one of the issues I'm trying to resolve is
the need for numerous backports. However, I do believe the
subproject/kernel is a good start. I would prefer to see it based around
testing snapshots, not necessarily testing itself.
Andrew M.A. Cater
> left by RedHat, and the possibility of working on a
> distribution/sub-project aimed at enterprise folks. The plan is to target
> those RedHat users and companies who are unwilling (or unable) to pay for
> RedHat Enterprise Linux, but need HA features. Our company falls into
> this category, but made the RedHat->Debian switch earlier on.
>
October/November where just these sorts of discussions have
been happening. I've been trying to advocate a switch to Debian
from RH for a lot of the high powered folk who run major clusters.
I'm not sure that a separate distribution would fly - Progeny would
have carried on otherwise. Bruce Perens' proposed ??UserLinux??
would possibly be a candidate here. Nor am I sure that a "sub-project"
is ideal. A customised kernel or two and potentially a meta-package
might be enough.
It doesn't make sense to fork unless you _really_ need to fork. A
distribution based on woody + backports would be OK now, with a
distribution based on the new stable once we release :) Pace Knoppix
and Lindows, basing a distribution on testing may be more than a little
difficult. Talking to Libranet and merging your Enterprise stuff
there might be another option. In the longer term, I'm slightly
sceptical about how many Debian-based distributions can survive outside
Debian - but then I've had 9 1/2 years of 20/20 hindsight :)
Just my 0.02 Euro / 0.03 US$
Andy
Andres Salomon
> On Mon, Nov 17, 2003 at 01:45:05AM -0500, Andres Salomon wrote:
>> Over the past week, my boss and I have had discussions about the niche
>> left by RedHat, and the possibility of working on a
>> distribution/sub-project aimed at enterprise folks. The plan is to target
>> those RedHat users and companies who are unwilling (or unable) to pay for
>> RedHat Enterprise Linux, but need HA features. Our company falls into
>> this category, but made the RedHat->Debian switch earlier on.
>>
> Check out the Beowulf list archives @ www.beowulf.org for
> October/November where just these sorts of discussions have
> been happening. I've been trying to advocate a switch to Debian
> from RH for a lot of the high powered folk who run major clusters.
>
> I'm not sure that a separate distribution would fly - Progeny would
> have carried on otherwise. Bruce Perens' proposed ??UserLinux??
> would possibly be a candidate here. Nor am I sure that a "sub-project"
> is ideal. A customised kernel or two and potentially a meta-package
> might be enough.
>
After reading Andreas Tille's link on sub-projects, I'm leaning more
towards that. I have little doubt that a separate distribution (done
correctly) would fly; look at the success of Knoppix, for example.
However, my goals are more in line w/ the goals of a sub-project.
> It doesn't make sense to fork unless you _really_ need to fork. A
> distribution based on woody + backports would be OK now, with a
> distribution based on the new stable once we release :) Pace Knoppix
> and Lindows, basing a distribution on testing may be more than a little
> difficult. Talking to Libranet and merging your Enterprise stuff
> there might be another option. In the longer term, I'm slightly
> sceptical about how many Debian-based distributions can survive outside
> Debian - but then I've had 9 1/2 years of 20/20 hindsight :)
>
Most Debian-based distributions are aimed at desktop users; this market is
fairly crowded, especially when you take into account the distributions
outside of Debian that focus on the same thing. On the enterprise level,
however, there are few distributions that focus on just that segment.
There are even fewer that offer their distribution for free (as in beer).
RedHat was one of the few, and with their exit from that market, a large
opportunity opens up.
I do agree that there's little need to fork, so long as the sub-project
structure is flexible enough. I need to do more research on that.
Andreas Tille
> After reading Andreas Tille's link on sub-projects, I'm leaning more
> towards that. I have little doubt that a separate distribution (done
> correctly) would fly; look at the success of Knoppix, for example.
> However, my goals are more in line w/ the goals of a sub-project.
I do not have doubt that separate dirtibutions could fly. I just wonder
if the effort to make it right is worth doing it instead of spending half
of the effort to make it right inside Debian. Just note that Klaus
Knopper was *very* interested about my idea to integrate Knoppix stuff
into Debian. He recognized that this could save him time even if the
first step of sane inclusion is quite hard.
Kind regards
Andreas.
Zenaan Harkness
> On Mon, 17 Nov 2003, Andres Salomon wrote:
> > Suggestions are most welcome.
> Feel free to ask about details if something is not clear about the slides
> or any other things are missing. IMHO a debian-enterprise is very much
> missing and would be a great enhancement.
Thorough agreement. I believe a debian-enterprise sub-project would
serve very well to gather support from various companies that utilize
Debian. At the software company I used to work at we had various
"local" packages, mostly site-specific, but as manager I would have
readily given approval to make all applicable work available to
debian(-enterprise subproject).
Having a focal point is a great thing. Wishlists, mailing lists,
and like minded people all come together to build small pieces of
the communal puzzle.
Also, definitely debian-enterprise, not debian-user subproject.
Plenty of user stuff already (-multimedia, -jr, -med, etc).
Perhaps, for anyone wondering whether separate or sub project is
the way - check out DeMuDi (external distro) which is now kind
of morphing into debian-multimedia sub project.
Is there enough concensus to start a list - anyone with the resource
access and experience to create a webpage for the subproject?
I will join the list as soon as it's available.
Bruce Perens mentioned in an interview recently (not so recent I
can remember the link though sorry) that he feels the time is
ripe for just such a sub project. My feeling was that there are
potentially some large corporates who would back such a move
(HP?, SUN? - I don't know, but we can guess).
cheers
zen
Zenaan Harkness
Is it possible to create task or meta packages that depend on specific
versions - eg. a bunch of versions as at a specific "snapshot" date of
"testing"??
ta
zen
Sebastian Ley
> Just note that Klaus Knopper was *very* interested about my idea to
> integrate Knoppix stuff into Debian. He recognized that this could
> save him time even if the first step of sane inclusion is quite hard.
The idea to integrate Knoppix stuff back to Debian also occured to me. I
am glad to hear that Klaus likes the idea too. Have you put any further
thought into the question how to accomplish that?
At the d-i debcamp in Oldenburg I met a guy who also does Knoppix
development work. He too seemed to be interested in the idea so I am
CC'ing him.
Sebastian
--
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6
Tim Dijkstra
Zenaan Harkness <z...@aaroncommercial.com> wrote:
> On Tue, 2003-11-18 at 05:17, Andres Salomon wrote:
> > On Mon, 17 Nov 2003 11:51:43 -0500, Matt Zimmerman wrote:
> > > If the sub-project approach would mean that the new packages and
> > > enhancements would be folded into Debian, then I think that is
> > > definitely preferable. I do not think that basing it on testing
> > > is the best approach; in my experience, enterprises prefer a
> > > longer (stable) release cycle than testing's daily churn.
> >
> > Normally I'd agree; however, one of the issues I'm trying to resolve
> > is the need for numerous backports. However, I do believe the
> > subproject/kernel is a good start. I would prefer to see it based
> > around testing snapshots, not necessarily testing itself.
>
> Is it possible to create task or meta packages that depend on specific
> versions - eg. a bunch of versions as at a specific "snapshot" date of
> "testing"??
I think that will give problems. If this package gets into testing then
the packages which it depends on can't get any new versions into
testing. If it's not in testing there's no guaranty that it's
dependencies will be in the archive (precisely because new versions of
package get into testing).
grtjs Tim
Andreas Tille
> Is it possible to create task or meta packages that depend on specific
> versions - eg. a bunch of versions as at a specific "snapshot" date of
> "testing"??
No - except if there are different verisons of one package in Debian (see
recent plans to package different PostgreSQL versions).
BTW, I see no relevance for depending from certain versions *if* you use
just stable as it should be done in an enterprise. Any backports are
out of control of Debian and the meta packages inside Debian.
Kind regards
Andreas.
Andreas Tille
> Is there enough concensus to start a list - anyone with the resource
> access and experience to create a webpage for the subproject?
>
> I will join the list as soon as it's available.
apt-get install subproject-howto
> Bruce Perens mentioned in an interview recently (not so recent I
> can remember the link though sorry) that he feels the time is
> ripe for just such a sub project. My feeling was that there are
> potentially some large corporates who would back such a move
> (HP?, SUN? - I don't know, but we can guess).
I had several talks about Custom Debian Distributions and I'm mentioning
this from the first one ...
Kind regards
Andreas.
Andreas Tille
> The idea to integrate Knoppix stuff back to Debian also occured to me. I
> am glad to hear that Klaus likes the idea too. Have you put any further
> thought into the question how to accomplish that?
The only thing I did besides talking about it was creating a project on Alioth:
http://alioth.debian.org/projects/debian-knoppix/
I hae to admit that I'm overloaded with Debian-Med work and will not be able
to do any real work on this topic. Feel free to join the Alioth project!
> At the d-i debcamp in Oldenburg I met a guy who also does Knoppix
> development work. He too seemed to be interested in the idea so I am
> CC'ing him.
I learned to know Fabian at LinuxTag and in fact hid did much more work on
this field then me after I tried to explain him my ideas. He kind of applied
this idea for PowerPC. Unfortunately I was not able to contact him since
the Alioth project was started.
Turbo Fredriksson
When I started with Debian GNU/Linux in '95 (became developer about a year
later) Debian GNU/Linux was the _only_ distribution that had some class!
It was _stable_ (that was the main 'feature'). It did not break, and upgrade
was quite simple (even though this was WAY before apt!).
So the discussion on 'forking' the project to a separate distribution to
provide 'enterprise' functionality is 'insulting'.
With this I mean that _DEBIAN_ should benefit on (and provide) all of this.
Give DEBIAN all those benefits and enhancements instead of forking...
It have been discussed before, I know, but I still find this a problem.
Debian is _WAY_ to big! We don't NEED 8000 packages!! On my main server
(which is also a 'user server' - imap, pop, mail, shell and what not) I
have 1155 packages installed. On my workstation at home 447...
So anyone talking about 'forks' and 'sub-projects' etc could take all that
crud and make a 'MegaDebian - everything that fits on a (huge) disk' distribution...
And removing all that crap (I call it crap because that's what I think it is!)
will make releases smoother and go quicker...
The idea to make packages (slowly) migrate from unstable to testing and then
to stable is a nice idea, but I think it's proven by now that that didn't
work as intended (and I'm part of that flaw, I know!).
--
spy class struggle cracking quiche assassination Legion of Doom
Khaddafi killed tritium bomb pits arrangements BATF fissionable
ammunition
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Tom
> It have been discussed before, I know, but I still find this a problem.
> Debian is _WAY_ to big! We don't NEED 8000 packages!! On my main server
> (which is also a 'user server' - imap, pop, mail, shell and what not) I
> have 1155 packages installed. On my workstation at home 447...
I like having 3rd rate, outdated, and broken packages in the distro. I
like things that don't work well. People get scary when they "get it
together."
> --
> spy class struggle cracking quiche assassination Legion of Doom
> Khaddafi killed tritium bomb pits arrangements BATF fissionable
> ammunition
> [See http://www.aclu.org/echelonwatch/index.html for more about this]
I had a friend who worked at Bell in the very early 1960s. He told me
before the phone system went digital there was a special code you could
issue which would activate the microphone when the phone was on the
hook. So if the government is going to ruin your life, it's been
happening for at least 40 years.
Have a nice day.
Russell Coker
> It have been discussed before, I know, but I still find this a problem.
> Debian is _WAY_ to big! We don't NEED 8000 packages!! On my main server
> (which is also a 'user server' - imap, pop, mail, shell and what not) I
> have 1155 packages installed. On my workstation at home 447...
The problem of course is which packages to remove. Some of those 1155
packages are probably what I consider dross.
No individual needs 8000 packages, but collectively the Debian users need the
vast majority of them.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Marc Haber
<rus...@coker.com.au> wrote:
>On Thu, 20 Nov 2003 19:49, Turbo Fredriksson <tu...@debian.org> wrote:
>> It have been discussed before, I know, but I still find this a problem.
>> Debian is _WAY_ to big! We don't NEED 8000 packages!! On my main server
>> (which is also a 'user server' - imap, pop, mail, shell and what not) I
>> have 1155 packages installed. On my workstation at home 447...
>
>vast majority of them.
It is, IMO, however, a good idea to split the distribution into
sub-projects that release independently. We have long ago grown beyond
manageable size.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Andreas Tille
> It is, IMO, however, a good idea to split the distribution into
> sub-projects that release independently. We have long ago grown beyond
> manageable size.
I'm not convinced that sub-projects will be able to release independently.
A release is a big effort. IMHO sub-projects serve for the purpose to
concentrate the focus on relevant bits for the intended purpose among the
huge mass of packages.
On the other hand a sub-project centrix Knoppix is always a good idea
if it would be easy to create such a beast without any effort.
Kind regards
Andreas.
Goswin von Brederlow
> On Thu, 20 Nov 2003, Marc Haber wrote:
>
> > It is, IMO, however, a good idea to split the distribution into
> > sub-projects that release independently. We have long ago grown beyond
> > manageable size.
> I'm not convinced that sub-projects will be able to release independently.
> A release is a big effort. IMHO sub-projects serve for the purpose to
> concentrate the focus on relevant bits for the intended purpose among the
> huge mass of packages.
>
> On the other hand a sub-project centrix Knoppix is always a good idea
> if it would be easy to create such a beast without any effort.
>
> Kind regards
>
> Andreas.
Independant subprojects would mean that every combination of versions
has to be tested, e.g. stable base + unstable gnome + testing kde.
The number of tests and versions grows exponentially with the number
of subprojects and some archs are busy keeping up-to-date already with
just one version.
The problem is that version depends/conflicts prevent independance.
MfG
Goswin
John Hasler
> I had a friend who worked at Bell in the very early 1960s. He told me
> before the phone system went digital there was a special code you could
> issue which would activate the microphone when the phone was on the hook.
He was lying. 1960s phones contain only passive components and switches.
The hookswitch disconnects the microphone.
--
John Hasler
jo...@dhh.gt.org (John Hasler)
Dancing Horse Hill
Elmwood, WI
Tom
> Tom writes:
> > I had a friend who worked at Bell in the very early 1960s. He told me
> > before the phone system went digital there was a special code you could
> > issue which would activate the microphone when the phone was on the hook.
>
> He was lying. 1960s phones contain only passive components and switches.
> The hookswitch disconnects the microphone.
Maybe. It was told to me in the context of many other phone phreaker
things he knew, stuff like Captain Krunch and Woz did. Actually he
never said this was in the 1960s, he told me stories about working there
during the dangerous strikes in early 60s, and that "up until the switch
to digitial, you could activate the mic while it was on the hook", so
maybe that was later?
He knew all kinds of tricks about calling information, and entering a
code, to get into the local loop. He told me about the "internet" that
wasn't the internet that you could jack into with a special device (I
think it was IBM's globalnet).
Of course, I didn't verify any of it, he could have been a bullshitter.
Tim Dijkstra
Turbo Fredriksson <tu...@debian.org> wrote:
> It have been discussed before, I know, but I still find this a
> problem. Debian is _WAY_ to big! We don't NEED 8000 packages!! On my
> main server(which is also a 'user server' - imap, pop, mail, shell and
> what not) I have 1155 packages installed. On my workstation at home
> 447...
>
> So anyone talking about 'forks' and 'sub-projects' etc could take all
> that crud and make a 'MegaDebian - everything that fits on a (huge)
> disk' distribution...
>
> And removing all that crap (I call it crap because that's what I think
> it is!) will make releases smoother and go quicker...
I really doubt that; I think the majority of the packages you call crap
don't have huge dependencies or are heavily dependent upon. Unless of
course you call things like glibc, perl, gcc or the base of gnome and
kde crap that is.
grts Tim
Turbo Fredriksson
Tim> On 20 Nov 2003 09:49:16 +0100
Tim> Turbo Fredriksson <tu...@debian.org> wrote:
>> It have been discussed before, I know, but I still find this a
>> problem. Debian is _WAY_ to big! We don't NEED 8000 packages!!
>> On my main server(which is also a 'user server' - imap, pop,
>> mail, shell and what not) I have 1155 packages installed. On my
>> workstation at home 447...
>>
>> So anyone talking about 'forks' and 'sub-projects' etc could
>> take all that crud and make a 'MegaDebian - everything that
>> fits on a (huge) disk' distribution...
>>
>> And removing all that crap (I call it crap because that's what
>> I think it is!) will make releases smoother and go quicker...
Tim> I really doubt that; I think the majority of the packages you
Tim> call crap don't have huge dependencies or are heavily
Tim> dependent upon. Unless of course you call things like glibc,
Tim> perl, gcc or the base of gnome and kde crap that is.
Rubbish! Once up on a time, when Debian GNU/Linux WAS for the Enterprise
(ie, it had the quality needed to call it an Enterprise distribution)
we managed to release in a quite reasonable time. And Debian wasn't big,
but still had everything that one could ask for on a server.
I should say that SERVER is the keyword _I_ use when talking about
'Enterprise'... If you want a workstation, install SuSE, RH, Whatever.
There's PLENTY of 'workstation' (ie, 'user') distributions around, but
only ONE server distribution (sorry, I don't honnor Slackware as a
distribution - it's a joke! :)
Ok, there's a few server distributions, but I always put Debian GNU/Linux
as number one there... But with the last few 'stable releases', I do not
call it 'the best' distribution any more! I'm getting quite feed up with
the way releases are handled... I don't mind late releases, as long as
they are GOOD!
So when talking 'crud' and 'crap' here, I mean 'everything that is not
needed/wanted on a server'. Example on that is anything that uses a GUI
(ie, X11 stuff such as window managers, games), the lg-* (The Linux
Gazette) packages etc, etc... The list could be long...
Some exceptions needs to be done here, since a compiler is NOT wanted
on a server, but still needs to be available...
--
South Africa FSF fissionable subway SEAL Team 6 SDI KGB Saddam Hussein
assassination munitions 747 Serbian NSA colonel Mossad
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Benj. Mako Hill
> Am Di, den 18.11.2003 schrieb Andreas Tille um 08:48:
>
> > Just note that Klaus Knopper was *very* interested about my idea to
> > integrate Knoppix stuff into Debian. He recognized that this could
> > save him time even if the first step of sane inclusion is quite hard.
>
> The idea to integrate Knoppix stuff back to Debian also occured to me. I
> am glad to hear that Klaus likes the idea too. Have you put any further
> thought into the question how to accomplish that?
>
> At the d-i debcamp in Oldenburg I met a guy who also does Knoppix
> development work. He too seemed to be interested in the idea so I am
> CC'ing him.
The Debain-Nonprofit Custom Distro has made bootable Debian-CDs the
first order of business and the good news is that we're essentially
there -- I've been botting off bootable Debain-NP CDs all weekend.
We're not using Knoppix but rather the Knoppix-deritive Morphix
because it seems to be a bit more modular and, more importantly,
because the main Morphix developer, Alex de Landgraf, has been involved
with Debain-NP since the beginning.
At the very least, we can document the process of making these CDs and
we can work with whoever plans on packaging these.
Regards,
Mako
--
Benjamin Mako Hill
ma...@debian.org
http://mako.yukidoke.org/
Anthony Towns
> At the very least, we can document the process of making these CDs and
> we can work with whoever plans on packaging these.
Is there a process for making these CDs from nothing more than debs
downloaded from debian.org?
Obviously it's non-trivial, but it should be possible to have debootstrap
(or a similar tool) construct bootable Knoppix-esque CDs without any
user-interaction IMO.
Cheers,
aj
--
Anthony Towns <a...@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
Australian DMCA (the Digital Agenda Amendments) Under Review!
-- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda
Andreas Tille
> Is there a process for making these CDs from nothing more than debs
> downloaded from debian.org?
If it is Morphix then this is not possible or intended. However Morphix is
n fact a good base to get this done.
> Obviously it's non-trivial, but it should be possible to have debootstrap
> (or a similar tool) construct bootable Knoppix-esque CDs without any
> user-interaction IMO.
I hope that people like the Morphix developer(s) will grab the idea to do
so. In fact it is more than trivial but in the end it would make building
customized Knoppix CDs trivial which is the goal of Morphix (if I understand
the web page right).
Kind regards
Andreas.
Javier Fernández-Sanguino Peña
> On Mon, Nov 24, 2003 at 10:34:45AM +0100, Benj. Mako Hill wrote:
> > At the very least, we can document the process of making these CDs and
> > we can work with whoever plans on packaging these.
>
> Is there a process for making these CDs from nothing more than debs
> downloaded from debian.org?
I know at least of one such process and its the one used at metadistros
(metadistros.hispalinux.es). The tool in this case is called 'calzador'.
IIRC it basicly depends on having a chroot environment set with the OS
image you want to burn and it adds that together with the bootup stuff.
>
> Obviously it's non-trivial, but it should be possible to have debootstrap
> (or a similar tool) construct bootable Knoppix-esque CDs without any
> user-interaction IMO.
There's still much to do in order to develop said script but some projects
were trying to automate this process. It still remains to see if these
scripts are going to be reusable and could be included in Debian.
Regards
Javi
Andreas Tille
> > Is there a process for making these CDs from nothing more than debs
> > downloaded from debian.org?
>
> I know at least of one such process and its the one used at metadistros
> (metadistros.hispalinux.es). The tool in this case is called 'calzador'.
> IIRC it basicly depends on having a chroot environment set with the OS
> image you want to burn and it adds that together with the bootup stuff.
~> apt-cache search calzador
has no output and this is (one of) the problem here. What we need is
*complete* integration. The profit would be on both sides: Metadistros
would get well known in the Debian community (first step would be an
internationalized web page). On the other hand Debian would become
fit for even more user tasks.
> There's still much to do in order to develop said script but some projects
> were trying to automate this process. It still remains to see if these
> scripts are going to be reusable and could be included in Debian.
Why?
Any piece of free software might be able to include into Debian.
Kind regards
Andreas.
Goswin von Brederlow
> On Tue, 25 Nov 2003, Javier Fernández-Sanguino Peña wrote:
>
> > > Is there a process for making these CDs from nothing more than debs
> > > downloaded from debian.org?
> >
> > I know at least of one such process and its the one used at metadistros
> > (metadistros.hispalinux.es). The tool in this case is called 'calzador'.
> > IIRC it basicly depends on having a chroot environment set with the OS
> > image you want to burn and it adds that together with the bootup stuff.
>
> ~> apt-cache search calzador
>
> has no output and this is (one of) the problem here. What we need is
> *complete* integration. The profit would be on both sides: Metadistros
> would get well known in the Debian community (first step would be an
> internationalized web page). On the other hand Debian would become
> fit for even more user tasks.
>
> > There's still much to do in order to develop said script but some projects
> > were trying to automate this process. It still remains to see if these
> > scripts are going to be reusable and could be included in Debian.
> Why?
> Any piece of free software might be able to include into Debian.
>
> Kind regards
>
> Andreas.
Hi,
I am the author of Debix and some might already know me from the
Linuxtag or the Oldenburg D-I Debcamp.
First, before you ask, Debix developement is currently on hold in
favour of working on D-I but D-I is getting to a stage where it can
utilize Debix so it will start back up soon.
Debix is ment as a tool to make any linux system into a live CD with
no change to the linux system. With the help of the device mapper
(kernel part of lvm2) and an initrd a (compressed) loopback file on
the cdrom (or other medium) is made seemingly writeable. Any changes
to the loopback file will be stored in ram.
Using Debix you can take a completly normal Debian system created with
debootstrap and make it a live CD. Added features are that you can
move the data from the cdrom to any other blockdevice in the
background while the user is working to make a harddisk install for
example. The user would just provide the partition and at some time
later the cdrom would eject and the install is done and already
running, allways had been. Given a cdrom and a burner you can update
the running system (apt-get update; apt-get dist-upgrade) and reburn it.
Why do I tell you this?
Debian will soon have Debix to make transparent live CDs. All you have
to worry is getting the autodetection and autoconfiguration into
policy conform debs that makes your live CD so great. Once you can
install your system on a harddisk or chroot or update Debian to such a
system your ready to make a live CD with Debix.
MfG
Goswin
Andreas Tille
> Why do I tell you this?
This is easy to tell: It's absolutely on topic.
> Debian will soon have Debix to make transparent live CDs. All you have
> to worry is getting the autodetection and autoconfiguration into
> policy conform debs that makes your live CD so great. Once you can
I'm not keen on the name Knoppix. But we have to move all the nice
auto-detection stuff of Knoppix into this build system. Moreover there
might be some help in preconfiguration of desktop etc, which is more
or less done in Knoppix (or Gnoppix for Gnome). People might say that
some stuff in Knoppix might violate Debian policy. But I see no direct
relevance of Debian policy for a derived LiveCD as long as the
preparation is done in a clean chroot ... and this violation is
necessary / makes sense.
Kind regards
Andreas.
Goswin von Brederlow
> On Tue, 25 Nov 2003, Goswin von Brederlow wrote:
>
> > Why do I tell you this?
> This is easy to tell: It's absolutely on topic.
>
> > Debian will soon have Debix to make transparent live CDs. All you have
> > to worry is getting the autodetection and autoconfiguration into
> > policy conform debs that makes your live CD so great. Once you can
> I'm not keen on the name Knoppix. But we have to move all the nice
> auto-detection stuff of Knoppix into this build system. Moreover there
> might be some help in preconfiguration of desktop etc, which is more
> or less done in Knoppix (or Gnoppix for Gnome). People might say that
> some stuff in Knoppix might violate Debian policy. But I see no direct
> relevance of Debian policy for a derived LiveCD as long as the
> preparation is done in a clean chroot ... and this violation is
> necessary / makes sense.
Acutally no. Debix will not get any of that.
Its your job as the user of debix to provide a already "knopified"
chroot or to provide debs that debix will install via debootstrap to
create a filesystem for the cd.
Producing debs for this would be better because then you can easily
update and modify the system. Making the debs policy cleans allows
them to enter debian. The debs should be such that they can be used on
a normal debian harddisk installation. Debix takes care of the live cd
stuff transparently. This also mean any debian user can just upgrade
his debian to a knoppix.
If can't work with the policy but still want something in debian you
would have to make a package that can create a knoppix chroot,
i.e. package the scripts that transform a "normal" debian to
knoppix. But I strongly suggest building policy conform debs for
everything even if it means some things become slightly more
complex (or bend the policy).
I suggest putting all the knoppix debs into task knoppix. That way
users can install debian and when task-sel pops up they select task
knoppix, wait some and then they have they fully featured knoppix on
the harddisk. Not as smooth as the live CD but still much easier than
configuring everything themself.
MfG
Goswin
Andreas Tille
> Its your job as the user of debix to provide a already "knopified"
> chroot or to provide debs that debix will install via debootstrap to
> create a filesystem for the cd.
In fact, debix solves the last part of my proposal to create a Knoppix
from Debian-Mirror.
> Producing debs for this would be better because then you can easily
> update and modify the system.
Absolutely.
> Making the debs policy cleans allows
> them to enter debian. The debs should be such that they can be used on
> a normal debian harddisk installation.
You are describing a perfect world. For sure I would prefer this as well.
But I hate it if people tell me that building Knoppix from scratch is
impossible because of some policy problems because I regard those problems
as solvable in the end if we would get a *working* solution in the first
run. The problem is that some configuration has to be "adapted" which
could be solved by writing debconf patches for some packages if necessary.
> Debix takes care of the live cd
> stuff transparently. This also mean any debian user can just upgrade
> his debian to a knoppix.
Hmmm, I can't parse the sense of this. IMHO Knoppix is just the live CD
system.
> If can't work with the policy but still want something in debian you
> would have to make a package that can create a knoppix chroot,
> i.e. package the scripts that transform a "normal" debian to
> knoppix. But I strongly suggest building policy conform debs for
> everything even if it means some things become slightly more
> complex (or bend the policy).
See above.
> I suggest putting all the knoppix debs into task knoppix. That way
> users can install debian and when task-sel pops up they select task
> knoppix, wait some and then they have they fully featured knoppix on
> the harddisk. Not as smooth as the live CD but still much easier than
> configuring everything themself.
This is the plan I introduece in my talk at LinuxDays Luxembourg and
this is exactly the goal of the debian-knoppix project on Alioth
even if it is only intended for the chroot system with the aim to
build a Knoppix CD from it. I can't see the advantage of a Knoppix
system - it is just Debian (on a LiveCD with hardware detection).
Kind regards
Andreas.
--
Sie schaffen eine Wüste und nennen es Frieden.
-- Publius Cornelius Tacitus (55-120)
Cameron Patrick
| So when talking 'crud' and 'crap' here, I mean 'everything that is not
| needed/wanted on a server'. Example on that is anything that uses a GUI
| (ie, X11 stuff such as window managers, games), the lg-* (The Linux
| Gazette) packages etc, etc... The list could be long...
Now that is just rubbish! To start with, Debian aims to be useful on
more than just servers. The web page describes it as "the universal
operating system"; one of the nice features about Debian, from my
perspective, is that an enormous amount of software is packaged for and
included with it. Normally the Debian developers do a bloody good job
of packaging things consistently and sensibly. (And for the record, I'm
not one.)
It is also conceivable that the 'crap' that you decry might be required
on a server - if that server is a terminal server providing applications
to remote X displays, for example, having X11 installed would be a
requirement.
Further to this, if you don't want to have a given package installed on
your server, you are quite welcome to /not/ install it! Packages which
are not installed take up a negligible amount of space and have no
adverse security implications. For the most part, the packages which
might be considered to be holding up the release (such as XFree) are in
fact wanted by a considerable proportion (in fact, in the case of X, I
would say an overwhelming majority) of Debian's users. Channelling the
considerable effort being devoted to packaging, say, XFree86 or KDE to
fixing problems in other packages could perhaps help get a stable
release out sooner, but would more likely result in the release process
taking just as long, and countless people bickering about how useless
Debian is for their purposes, now that it doesn't contain X.
Cameron.
Goswin von Brederlow
> On Tue, 25 Nov 2003, Goswin von Brederlow wrote:
>
> > Its your job as the user of debix to provide a already "knopified"
> > chroot or to provide debs that debix will install via debootstrap to
> > create a filesystem for the cd.
> In fact, debix solves the last part of my proposal to create a Knoppix
> from Debian-Mirror.
>
> > Producing debs for this would be better because then you can easily
> > update and modify the system.
> Absolutely.
>
> > Making the debs policy cleans allows
> > them to enter debian. The debs should be such that they can be used on
> > a normal debian harddisk installation.
> You are describing a perfect world. For sure I would prefer this as well.
> But I hate it if people tell me that building Knoppix from scratch is
> impossible because of some policy problems because I regard those problems
> as solvable in the end if we would get a *working* solution in the first
> run. The problem is that some configuration has to be "adapted" which
> could be solved by writing debconf patches for some packages if necessary.
>
> > Debix takes care of the live cd
> > stuff transparently. This also mean any debian user can just upgrade
> > his debian to a knoppix.
> Hmmm, I can't parse the sense of this. IMHO Knoppix is just the live CD
> system.
If knoppix is all handled by debs you can koppify your installed
system by "apt-get install <knoppix debs>". Thats the end goal of
getting knoppix into Debian in my opinion.
> > If can't work with the policy but still want something in debian you
> > would have to make a package that can create a knoppix chroot,
> > i.e. package the scripts that transform a "normal" debian to
> > knoppix. But I strongly suggest building policy conform debs for
> > everything even if it means some things become slightly more
> > complex (or bend the policy).
> See above.
As a first approach making a "build knoppix" package is ok but the
package should shrink over time. Knopper has published his build
scripts so they can be adapted and packages easily.
> > I suggest putting all the knoppix debs into task knoppix. That way
> > users can install debian and when task-sel pops up they select task
> > knoppix, wait some and then they have they fully featured knoppix on
> > the harddisk. Not as smooth as the live CD but still much easier than
> > configuring everything themself.
> This is the plan I introduece in my talk at LinuxDays Luxembourg and
> this is exactly the goal of the debian-knoppix project on Alioth
> even if it is only intended for the chroot system with the aim to
> build a Knoppix CD from it. I can't see the advantage of a Knoppix
> system - it is just Debian (on a LiveCD with hardware detection).
For the same reason that users want the hd-install function on the
knoppix.
It might even be such a trivial thing as that they want to watch dvds
with knoppix but have only one dvd drive. Ok, for this debix can push
the cdrom into ram, if you have enough, and eject it.
MfG
Goswin
Anthony Towns
> call it 'the best' distribution any more! I'm getting quite feed up with
> the way releases are handled... I don't mind late releases, as long as
> they are GOOD!
Uh, dude:
Package: libroxen-logsql (debian/main).
Maintainer: Turbo Fredriksson <tu...@debian.org>
213967 [ ] libroxen-logsql: The debian/copyright file is not correct
Package: midentd (debian/main).
Maintainer: Turbo Fredriksson <tu...@debian.org>
152801 [ ] midentd: An override for "/var/run/identd" already ...
Package: netsaint-plugins (non-US/main).
Maintainer: Turbo Fredriksson <tu...@debian.org>
183429 [ MR ] netsaint-plugins_1.2.9.4-28(m68k/unstable/zeus): fails ...
192419 [ ] netsaint-plugins - post-installation script returned ...
198830 [ ] netsaint-plugins: FTBFS with gcc-3.3: Uses multiline ...
Package: netsaint-plugins-ldap (non-US/main).
Maintainer: Turbo Fredriksson <tu...@debian.org>
197400 [ ] netsaint-plugins-ldap - failes to connect to slapd 2.1
Mathieu Roy
[...]
> Tim> I really doubt that; I think the majority of the packages you
> Tim> call crap don't have huge dependencies or are heavily
> Tim> dependent upon. Unless of course you call things like glibc,
> Tim> perl, gcc or the base of gnome and kde crap that is.
>
> Rubbish! Once up on a time, when Debian GNU/Linux WAS for the Enterprise
> (ie, it had the quality needed to call it an Enterprise distribution)
> we managed to release in a quite reasonable time. And Debian wasn't big,
> but still had everything that one could ask for on a server.
1. Can you explain how this paragraph is related to the one you reply
too (except of being posted on the same mailing-list with the same
Subject: header)
2. Can you explain what makes you think that Enteprise is equal to
server?
> I should say that SERVER is the keyword _I_ use when talking about
>'Enterprise'... If you want a workstation, install SuSE, RH,
>Whatever.
I already commented this confusion between enterprise and server.
3. Now, next step, what makes you think that Debian specifically
target?
4. What makes you think that RedHat, for instance, specifically target
Desktop computers?
[...]
> Ok, there's a few server distributions, but I always put Debian
>GNU/Linux as number one there...
Good for you.
>But with the last few 'stable releases', I do not call it 'the best'
>distribution any more! I'm getting quite feed up with the way
>releases are handled... I don't mind late releases, as long as they
>are GOOD!
5. So the latest releases are bad? How so?
6. You do not mind "late release". So why do you argue about Debian
not releasing stable in a "quite reasonable time"?
> So when talking 'crud' and 'crap' here, I mean 'everything that is not
> needed/wanted on a server'. Example on that is anything that uses a GUI
> (ie, X11 stuff such as window managers, games), the lg-* (The Linux
> Gazette) packages etc, etc... The list could be long...
So everything that you have no interest in is crap. If I follow your
policy, I should tell that your mail is definitely total crap.
But well, even following others policies, I could reach such a
conclusion.
> Some exceptions needs to be done here, since a compiler is NOT wanted
> on a server
God spoke. Amen.
--
Mathieu Roy
+---------------------------------------------------------------------+
| General Homepage: http://yeupou.coleumes.org/ |
| Computing Homepage: http://alberich.coleumes.org/ |
| Not a native english speaker: |
| http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english |
+---------------------------------------------------------------------+
Andreas Tille
> If knoppix is all handled by debs you can koppify your installed
> system by "apt-get install <knoppix debs>". Thats the end goal of
> getting knoppix into Debian in my opinion.
So we have very different opinions about Knoppix. I understand
Knoppix as plain Debian prepared as live CD while it has some nice
preconfiguration but this is more or less debian-desktop work and
has absolutely nothing to do with Knoppix.
> For the same reason that users want the hd-install function on the
> knoppix.
I see this as workaround to get a nice Debian installer. This will
be mostly fixed by d-i (hopefully).
Kind regards
Andreas.
--
Sie schaffen eine Wüste und nennen es Frieden.
-- Publius Cornelius Tacitus (55-120)
Keegan Quinn
> On Tue, 25 Nov 2003, Goswin von Brederlow wrote:
> > If knoppix is all handled by debs you can koppify your installed
> > system by "apt-get install <knoppix debs>". Thats the end goal of
> > getting knoppix into Debian in my opinion.
> So we have very different opinions about Knoppix. I understand
> Knoppix as plain Debian prepared as live CD while it has some nice
> preconfiguration but this is more or less debian-desktop work and
> has absolutely nothing to do with Knoppix.
Have you actually -used- Knoppix? It's based on Debian, but there's a
lot of stuff that is not Policy-compliant. The Knoppix hard-disk
installer creates a system that bears little resemblance to the base
system we all know and love.
I thought much the same as you, before I tried to help a couple of
people out with their Knoppix installations. Wishful thinking.
- Keegan
Andreas Mueller
> Andreas Tille <til...@rki.de> writes:
> > On Tue, 25 Nov 2003, Goswin von Brederlow wrote:
> >
> > > Its your job as the user of debix to provide a already "knopified"
> > > chroot or to provide debs that debix will install via debootstrap to
> > > create a filesystem for the cd.
> > In fact, debix solves the last part of my proposal to create a Knoppix
> > from Debian-Mirror.
The easiest way for a debian-live-cd is, run cdbackup.
There a lot of interesting projects based on debian, ex. gibraltar,
debian 4 Xbox, Lindows, all of them are debianbased. Impossible to
include all them into debian. I think its better to help those projects,
bring them closer to debian. Find out what is different compared to a
deb. Xfree is the same piece of software. I´m quit sure you can find
every software from knoppix inside debian.
Technically you boot a ( i can't understand why ) modified debian-base
system and start automatic hardware-configuration then your Desktop/
Firewall/ File-server/ Cluster. I do not understand differentiated to a
debian. A cool/colorful Desktop ?
> > > Producing debs for this would be better because then you can easily
> > > update and modify the system.
> > Absolutely.
> >
> > > Making the debs policy cleans allows
> > > them to enter debian. The debs should be such that they can be used on
> > > a normal debian harddisk installation.
> > You are describing a perfect world. For sure I would prefer this as well.
> > But I hate it if people tell me that building Knoppix from scratch is
> > impossible because of some policy problems because I regard those problems
> > as solvable in the end if we would get a *working* solution in the first
> > run. The problem is that some configuration has to be "adapted" which
> > could be solved by writing debconf patches for some packages if necessary.
> >
> > > Debix takes care of the live cd
> > > stuff transparently. This also mean any debian user can just upgrade
> > > his debian to a knoppix.
> > Hmmm, I can't parse the sense of this. IMHO Knoppix is just the live CD
> > system.
[...]
Cheers,
amu
Goswin von Brederlow
> Am Di, den 25.11.2003 schrieb Goswin von Brederlow um 17:02:
> > Andreas Tille <til...@rki.de> writes:
> > > On Tue, 25 Nov 2003, Goswin von Brederlow wrote:
> > >
> > > > Its your job as the user of debix to provide a already "knopified"
> > > > chroot or to provide debs that debix will install via debootstrap to
> > > > create a filesystem for the cd.
> > > In fact, debix solves the last part of my proposal to create a Knoppix
> > > from Debian-Mirror.
>
> The easiest way for a debian-live-cd is, run cdbackup.
> There a lot of interesting projects based on debian, ex. gibraltar,
> debian 4 Xbox, Lindows, all of them are debianbased. Impossible to
> include all them into debian. I think its better to help those projects,
> bring them closer to debian. Find out what is different compared to a
> deb. Xfree is the same piece of software. I´m quit sure you can find
> every software from knoppix inside debian.
>
> Technically you boot a ( i can't understand why ) modified debian-base
With debix you start the debix kernel (kernel-image with
kernel-patch-device-mapper or a 2.6.x kernel when it comes out) with
an initrd. The initrd detects some hardware to find the cdrom, mount
it and sets up a snapshot over the loopback file on cdrom. That in
turn is then mounted, /etc/fstab adapted to the current mountpoints,
pivot_rooted and chrooted into and /sbin/init started like any normal
boot.
I have a cd image with a 100% debian woody base system created with
the boot-floppies from woody as the loopback file. Works
perfectly. Thats thegoal of debix, a 0 change live CD creation.
> system and start automatic hardware-configuration then your Desktop/
> Firewall/ File-server/ Cluster. I do not understand differentiated to a
> debian. A cool/colorful Desktop ?
The important part is autodetection and autoconfiguration of
hardware. Configuring say X in debian is a pain since 99.9% of all
people can use the autogenerated config from say knoppix.
Basically that autoconfiguration needs to be merged into the debs but
the maintainer is not realy open for this. And writing a second deb to
configure X would be against policy.
Whats left? Fork the xfree deb? No way.
For the xfree-autoconf package (or whatever it will be called) I
probably have to dpkg-divert the X server and replace it with a wraper
that makes it use different config files, those generated by
xfree-autoconf. Thats quite ugly.
Goswin von Brederlow
> On Tue, 25 Nov 2003, Goswin von Brederlow wrote:
>
> > If knoppix is all handled by debs you can koppify your installed
> > system by "apt-get install <knoppix debs>". Thats the end goal of
> > getting knoppix into Debian in my opinion.
> So we have very different opinions about Knoppix. I understand
> Knoppix as plain Debian prepared as live CD while it has some nice
> preconfiguration but this is more or less debian-desktop work and
> has absolutely nothing to do with Knoppix.
Debix (through the device mapper) completly removes the live CD aspect
of the installation. The CD part becomes completly transparent. The
Knoppix developers are quite intrested in this since all the other
methods (onionfs, lucientfs, symlink farm) all, well, suck. When 2.6
is released and becomes stable device mapper support is in the
standard kernel so no extra patches will be neccessary, which is
another argument for it.
> > For the same reason that users want the hd-install function on the
> > knoppix.
> I see this as workaround to get a nice Debian installer. This will
> be mostly fixed by d-i (hopefully).
D-I doesn't realy go that way. Its just a nicer, modular design of
boot-floppies. You can add nice modules to it to do this kind of work
but it a different approach from a live cd. D-I does an install from
scratch with a minimal system (the initrd on the floppy or boot image)
using the udebs and then another install of base onto the target
medium.
MfG
Goswin
Anthony Towns
> > Is there a process for making these CDs from nothing more than debs
> > downloaded from debian.org?
> I know at least of one such process and its the one used at metadistros
> (metadistros.hispalinux.es). The tool in this case is called 'calzador'.
Is there any code that goes with that? I saw the wiki, but not knowing any
Spanish, didn't really get much from it.
> IIRC it basicly depends on having a chroot environment set with the OS
> image you want to burn and it adds that together with the bootup stuff.
> > Obviously it's non-trivial, but it should be possible to have debootstrap
> > (or a similar tool) construct bootable Knoppix-esque CDs without any
> > user-interaction IMO.
I'm envisaging something like:
mkdir sarge-chroot
debootstrap --include knoppix,calzador sarge sarge-chroot
# setup a chroot environment with knoppix and calzador tools
chroot sarge-chroot /usr/sbin/knoppix install-pkgs
# install and configure the standard "knoppix" patches
calzador setup-for-readonly sarge-chroot
# reconfigure /etc so chroot can be booted on a readonly
# root
mkisofs -b /usr/lib/calzador/boot_image -o myknoppix.iso sarge-chroot
# create an bootable isofs image
cdrecord ...
# then burn it to a CD
Being able to automatically install a useful system with lots of gnome
and kde and whatever other stuff without having to spend hours in dselect
or aptitude or answering questions or doing other configuration stuff
has obvious benefits, as does being able to easily convert an existing
system into something you can burn to a CD.
Also obvious, though, is that both those steps are hard: working out
a good set of packages to install, and configuring them usefully is
non-trivial; as is making Debian work with a read-only root.
(While the hypothetical /usr/sbin/knoppix and /usr/sbin/tasksel both
solve similar problems they're not quite the same -- /usr/sbin/knoppix
needs to select _and_ configure all the packages you want, tasksel just
selects them. debconf might not be enough either -- /usr/sbin/knoppix
might need to actually modify various files in /etc, too)
Andreas Tille
> Technically you boot a ( i can't understand why ) modified debian-base
> system and start automatic hardware-configuration then your Desktop/
> Firewall/ File-server/ Cluster. I do not understand differentiated to a
> debian. A cool/colorful Desktop ?
I have no problem with Debian derived distributions and I'm sure people
who are doing this have thought about it. But currently Debian is missing
something: We have no brain dead method to create a user customized CD
with really good auto detection. IMHO, Knoppix and its derivatives might
fill this gap. That's why my idea was to reintegrate Knoppix but I would
have no problem if somebody would like to do it from scratch.
The popularity of Knoppix speaks for what users really like. The fact that
there are so many Knoppix derivatives speaks for the need of customizing
a live CD which is currently not as easy as users might deserve it.
Kind regards
Andreas.
Tom
[snip]
> .. But currently Debian is missing
> something: We have no brain dead method to create a user customized CD
[snip]
What things are autodetected by Knoppix and its ilk?
What things are not autodetected?
What things are autodetected in "compatibility mode", i.e. will likely
require configuration tweaks for maximum performance?
What things are so easy to autodetect that they are "just right every
time"?
What's the ratio of things in each category?
Why don't you just move autodetection into the main kernel or driver trees?
I don't see why it needs to be this complicated...
Goswin von Brederlow
> On Tue, Nov 25, 2003 at 08:39:16AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> > > Obviously it's non-trivial, but it should be possible to have debootstrap
> > > (or a similar tool) construct bootable Knoppix-esque CDs without any
> > > user-interaction IMO.
>
> I'm envisaging something like:
>
> mkdir sarge-chroot
> debootstrap --include knoppix,calzador sarge sarge-chroot
> # setup a chroot environment with knoppix and calzador tools
> chroot sarge-chroot /usr/sbin/knoppix install-pkgs
> # install and configure the standard "knoppix" patches
This remains to be done.
> calzador setup-for-readonly sarge-chroot
> # reconfigure /etc so chroot can be booted on a readonly
> # root
> mkisofs -b /usr/lib/calzador/boot_image -o myknoppix.iso sarge-chroot
> # create an bootable isofs image
This becomes:
debix --from-dir sarge-chroot myknoppix.iso
Which internally does (simplified):
mkdir myknoppix
cp kernel initrd bootloader myknoppix
genext2fs -x myknoppix/debix.img -d sarge-chroot
mkisofs -o myknoppix.iso myknoppix
The beauty of using device mapper (which operates on the block device
level) is that its transparent to the system.
> cdrecord ...
> # then burn it to a CD
>
> Being able to automatically install a useful system with lots of gnome
> and kde and whatever other stuff without having to spend hours in dselect
> or aptitude or answering questions or doing other configuration stuff
> has obvious benefits, as does being able to easily convert an existing
> system into something you can burn to a CD.
>
> Also obvious, though, is that both those steps are hard: working out
> a good set of packages to install, and configuring them usefully is
> non-trivial; as is making Debian work with a read-only root.
Debian only has a very few things left that need to be changed for a
read-only root. All software should be changed to allow for linking
files or dirs into a ramdisk or to a kernel file (/etc/mtab ->
/proc/mounts). If you know of any that can't cope a link to a
writeable place let me know and file a bug.
Also with debix you don't have a read-only root unless you want to.
> (While the hypothetical /usr/sbin/knoppix and /usr/sbin/tasksel both
> solve similar problems they're not quite the same -- /usr/sbin/knoppix
> needs to select _and_ configure all the packages you want, tasksel just
> selects them. debconf might not be enough either -- /usr/sbin/knoppix
> might need to actually modify various files in /etc, too)
>
> Cheers,
> aj
Idealy debconf should be enough or a wraper package should be
available. Using only policy conform debs is my goal for a knopix
integration. Too many people have come into irc and complained that
updating knoppix to debian/sid broke everything. If knoppix actually
were part of debian that would be very bad.
MfG
Goswin
Turbo Fredriksson
> On Fri, Nov 21, 2003 at 03:00:20PM +0100, Turbo Fredriksson wrote:
>
> | So when talking 'crud' and 'crap' here, I mean 'everything that is not
> | needed/wanted on a server'. Example on that is anything that uses a GUI
> | (ie, X11 stuff such as window managers, games), the lg-* (The Linux
> | Gazette) packages etc, etc... The list could be long...
>
> Now that is just rubbish! To start with, Debian aims to be useful on
> more than just servers.
Does it? Than that is wrong in my opinion. We don't need an additional
'distribution that fits everything'. We need a (GOOD!) _server_ distribution.
And I always thought Debian GNU/Linux was that distribution...
> The web page describes it as "the universal operating system"; one
> of the nice features about Debian, from my perspective, is that an
> enormous amount of software is packaged for and included with it.
Me to. That's always the first thing I mention. But we have getting more
and more troubles getting a release 'out the door'. One of the (biggest)
problems is the shear size of the distribution. It's to big, and not enough
developers to test and fix bugs...
> It is also conceivable that the 'crap' that you decry might be required
> on a server - if that server is a terminal server providing applications
> to remote X displays, for example, having X11 installed would be a
> requirement.
Oki, fine. In any case, we need to rethink our 'target audience' and make
sure that audience get the BEST of the best...
> Further to this, if you don't want to have a given package installed on
> your server, you are quite welcome to /not/ install it!
That have absolutely nothing to do with the issue(s)! I say again: The problem
with getting releases out the door in a timely manner (no, two years between
releases is NOT 'timely manner'!!) is the shear size of the distribution.
--
critical FSF Ft. Meade president radar Qaddafi 747 $400 million in
gold bullion security class struggle BATF attack tritium Iran KGB
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Andreas Tille
> Why don't you just move autodetection into the main kernel or driver trees?
I do not want autodetection on my Debian installation on a certain box
because it makes no sense for me. If I change hardware I know what I'm doing
and I know what I will have to change.
I live CD is different: You never know on which machine it will be used.
That's why anecessary here.
> I don't see why it needs to be this complicated...
It's not complicated - it's just different.
Kind regards
Andreas.
Andreas Tille
> That have absolutely nothing to do with the issue(s)! I say again: The problem
> with getting releases out the door in a timely manner (no, two years between
> releases is NOT 'timely manner'!!) is the shear size of the distribution.
Hmm, are you aware that long living releases are exactly what enterprises
regard as an advantage and that this would support your "Enterprise-only-idea"?
BTW, feel free to ignore the Custom Distributions approach which tries to
cope with the size of Debian for certain tasks.
Kind regards
Andreas.
Turbo Fredriksson
> On Fri, Nov 21, 2003 at 03:00:20PM +0100, Turbo Fredriksson wrote:
> > But with the last few 'stable releases', I do not
> > call it 'the best' distribution any more! I'm getting quite feed up with
> > the way releases are handled... I don't mind late releases, as long as
> > they are GOOD!
>
> Uh, dude:
I'm fully aware of this. And if you look at my initial mail, I clearly state
that I'm part of the problem!
But since we're (more than?) 600 developers, maintaining 8000 packages is difficult.
But if those 600 developers only had say 3000 (just a number out the head), then
more bugs could be fixed, and I could get more help fixing MY bugs when/if I don't
have the time (or knowledge, which is the case in the listed packages).
--
assassination toluene $400 million in gold bullion strategic Cuba
South Africa 767 president killed FSF plutonium FBI radar Cocaine
cryptographic
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Turbo Fredriksson
> Turbo Fredriksson <tu...@debian.org> a tapoté :
>
> > Tim> I really doubt that; I think the majority of the packages you
> > Tim> call crap don't have huge dependencies or are heavily
> > Tim> dependent upon. Unless of course you call things like glibc,
> > Tim> perl, gcc or the base of gnome and kde crap that is.
> >
> > Rubbish! Once up on a time, when Debian GNU/Linux WAS for the Enterprise
> > (ie, it had the quality needed to call it an Enterprise distribution)
> > we managed to release in a quite reasonable time. And Debian wasn't big,
> > but still had everything that one could ask for on a server.
>
> 1. Can you explain how this paragraph is related to the one you reply
> too (except of being posted on the same mailing-list with the same
> Subject: header)
> 2. Can you explain what makes you think that Enteprise is equal to
> server?
A server is part of an enterprise. It's also part of organisations, services
etc, but the main part of an enterprise (from the IT perspective) is the
servers. Without good and solid servers, you can't run an enterprise.
I've been working for companies, that had a very (!) relaxed view of the
servers, and they have ALL (!) gone bankrupt eventually, primarily because
the servers just couldn't deliver what the sales staff was selling...
I'm not saying that 'server' and 'enterprise' is the same thing. I'm saying
that without good and solid servers that deliver solid services, you don't
HAVE an enterprise....
> > I should say that SERVER is the keyword _I_ use when talking about
> >'Enterprise'... If you want a workstation, install SuSE, RH,
> >Whatever.
>
> 3. Now, next step, what makes you think that Debian specifically
> target?
Experience.
> 4. What makes you think that RedHat, for instance, specifically target
> Desktop computers?
Ditto.
Debian GNU/Linux have ALWAYS been targeted (primarily) for servers. To
provide a secure, stable distribution. And that is an absolute requirement
on a server (in my opinion).
> >But with the last few 'stable releases', I do not call it 'the best'
> >distribution any more! I'm getting quite feed up with the way
> >releases are handled... I don't mind late releases, as long as they
> >are GOOD!
>
> 5. So the latest releases are bad? How so?
The upgrade to woody sucked BIG! It required (big) knowledge on how the
distribution was organised, because there where lot's of dependency conflicts
etc. I can't remember in detail what there where, but I charged around
100 man hours to different customers that just couldn't do the upgrade
them self...
> 6. You do not mind "late release". So why do you argue about Debian
> not releasing stable in a "quite reasonable time"?
Because Debian have _always_ been late! It's getting ridiculous. This is something
we get bad credit for all the time, and EVERYONE complains about this. It is not
reasonable to run two-three year old software on a server. In three years,
a software have progressed so much in terms of performance and stability, that
it's just "business requirement" to have it upgraded. OpenAFS is one such example
that I run myself... The version in woody sucks (for me), compared to the latest one...
> > So when talking 'crud' and 'crap' here, I mean 'everything that is not
> > needed/wanted on a server'. Example on that is anything that uses a GUI
> > (ie, X11 stuff such as window managers, games), the lg-* (The Linux
> > Gazette) packages etc, etc... The list could be long...
>
> So everything that you have no interest in is crap. If I follow your
> policy, I should tell that your mail is definitely total crap.
> But well, even following others policies, I could reach such a
> conclusion.
Be my guest. If you can't read, or can't read between the lines, that's your
problem, not mine. I never, once!, said that "everything I'm not interested in
is crap". That was your words.
--
NSA Honduras terrorist Marxist Ft. Bragg Ortega Qaddafi subway
plutonium Kennedy Waco, Texas president Rule Psix congress Delta Force
[See http://www.aclu.org/echelonwatch/index.html for more about this]
David Weinehall
> Quoting Anthony Towns <a...@azure.humbug.org.au>:
>
> > On Fri, Nov 21, 2003 at 03:00:20PM +0100, Turbo Fredriksson wrote:
> > > But with the last few 'stable releases', I do not call it 'the
> > > best' distribution any more! I'm getting quite feed up with the
> > > way releases are handled... I don't mind late releases, as long as
> > > they are GOOD!
> >
> > Uh, dude:
>
> I'm fully aware of this. And if you look at my initial mail, I clearly
> state that I'm part of the problem!
>
> But since we're (more than?) 600 developers, maintaining 8000 packages
> is difficult. But if those 600 developers only had say 3000 (just a
> number out the head), then more bugs could be fixed, and I could get
> more help fixing MY bugs when/if I don't have the time (or knowledge,
> which is the case in the listed packages).
No, because if we only had, say, 3000 packages, a lot of people wouldn't
have their pet packages left in Debian, and thus nothing to care for...
Would you become an active apache2-maintainer if we dumped Roxen? After
all, we don't need more than one webserver, do we?!
I try to submit fixes for other packages too, but only for packages I
use. The reason? I want to be able to have at least a chance to know if
something goes haywire. And some of the packages I use I wouldn't
possibly be able to send fixes for anyway without first learning to
master other programming languages.
Regards: David Weinehall
--
/) David Weinehall <t...@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
Russell Coker
> But since we're (more than?) 600 developers, maintaining 8000 packages is
> difficult. But if those 600 developers only had say 3000 (just a number out
> the head), then more bugs could be fixed, and I could get more help fixing
> MY bugs when/if I don't have the time (or knowledge, which is the case in
> the listed packages). --
Let's consider for the sake of discussion that this package cull involved
removing Postfix and KDE (we have Exim and GNOME).
This would force me to build my own packages of Postfix and KDE instead of
doing some of the other things I do (or maybe change to a distribution that
had KDE).
Removing packages from a commercial distro will allow resources to be deployed
elsewhere. Removing packages from Debian would result in a duplication of
work as every developer who wants the package in question maintains their own
build tree, and thus takes resources away from other development.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Wouter Verhelst
> Debian GNU/Linux have ALWAYS been targeted (primarily) for servers.
Could you point me at the specific paragraph in either the constitution
or the social contract, or in perhaps any other official document by the
Debian project as a whole that supports this statement?
If not, I can but conclude that your are misinformed. Debian is for "our
users and free software" (Social Contract 4). In the past, our users
have primarily been "people running servers", but that has clearly
changed. Saying that Debian is only for servers and that nobody should
be using it on the desktop is like saying that Linux should only be used
by volunteers and hobbyists, because they're the ones who originally
created it and gave it momentum.
Especially trying to tell other volunteers how they should use their
time is, uh, silly. We're volunteers; if we're no longer interested, we
won't be volunteers anymore and will move on to other things.
--
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
-- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Ralf Hildebrandt
> On Wed, Nov 26, 2003 at 11:57:12AM +0100, Turbo Fredriksson wrote:
> > Debian GNU/Linux have ALWAYS been targeted (primarily) for servers.
>
> Could you point me at the specific paragraph in either the constitution
> or the social contract, or in perhaps any other official document by the
> Debian project as a whole that supports this statement?
Especially since stable doesn't even install on recent server boxes...
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hil...@charite.de
Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-916
Referat V a - Kommunikationsnetze - AIM. ralfpostfix
Daniel Martin
>> 3. Now, next step, what makes you think that Debian specifically
>> target?
>
> Experience.
>
>> 4. What makes you think that RedHat, for instance, specifically target
>> Desktop computers?
>
> Ditto.
>
>
>
> Debian GNU/Linux have ALWAYS been targeted (primarily) for servers. To
> provide a secure, stable distribution. And that is an absolute requirement
> on a server (in my opinion).
As others have already said, your experience is telling you very
different things from what my experience is telling me.
The thing that makes Debian unique and not JALD (Just Another Linux
Distribution) is, in my experience, our strict adherence to the DFSG,
as guided by the Debian Social Contract. Debian is different from
other distributions the way that the FSF is different from other
organizations that make free software - Debian is a *philosophy*.
It happens that along the way in pursuit that philosophy we've
produced a distribution that some people find happens to meet their
server needs admirably. (and, unfortunately, some people have found
that Debian fails to meet their desktop needs - it meets mine, but
some people don't have my good taste) However, this is a coincidence
or, at best a byproduct of producing a distribution in line with
Debian's philosophy. I can find no evidence that there was ever a
deliberate attempt to focus on one type of user. (Beyond, "the type
of user who would support a 100% free software distribution")
Yes, I'm saying that licensing flame wars are an essential part of
Debian. No, I don't like the flame wars more than the next person,
but I understand that they're necessary.
Javier Fernández-Sanguino Peña
> > If knoppix is all handled by debs you can koppify your installed
> > system by "apt-get install <knoppix debs>". Thats the end goal of
> > getting knoppix into Debian in my opinion.
> So we have very different opinions about Knoppix. I understand
> Knoppix as plain Debian prepared as live CD while it has some nice
> preconfiguration but this is more or less debian-desktop work and
> has absolutely nothing to do with Knoppix.
>
Ummm... You are wrong here. Knoppix (or Knoppix-derived versions) provide
three things:
1- a live CD (can be easily developed with the usual tools)
2- autoconfiguration of hardware (again, this is or could be integrated
into Debian)
3- preconfiguration of all the software and customisation for a specific
need.
4- a system to duplicate this live Cd into hard disk, making the necessary
changes based on what was auto-detected.
The (3) part is not something that debian-desktop will do since it boils
down to modifying, at leisure, the system's configuration (/etc directly,
since there is not a single point of configuration, debconf is not an
option here). This preconfiguration is the one that allows customisation
for the system to end-users and it basicly boils down to doing it on your
own system (touching files, tweaking stuff, adding tools, etc.) and then
using it as an image for the live-CD (1) and as an 'image' for user
installations (4).
It's also something that cannot be 'packaged' easily (there are as many
possible setups as users out there), and usually this packaging violates
policy (since the package would modify other packages configuration
files).
The nice part of Knoppix is not that it auto-detects hardware since this
can be done already in Debian (kudzu and the like are already available)
but that somebody has taken the time to customize the environment (the
desktop or whatever) to suit the needs of an specific group. He has
selected the tools that will be available and has customised them to work
as expect.
For example, take a spanish user group for example with ~0 computer
administration knowledge that want an Internet environment. You can provide
a system that is a replica of yours which is already configured enabling
spanish i18n everywhere (task that involves modifying /etc/ configuration
files), with Mozilla already configure to work in spanish (see #192293),
bookmarks for common spanish sites, with the desktop already configured
simulating Windows behaviour, with xchat already configured with
spanish IRC channels, etc.
Hope that clears up the idea
Javi
Javier Fernández-Sanguino Peña
> On Tue, Nov 25, 2003 at 08:39:16AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> > > Is there a process for making these CDs from nothing more than debs
> > > downloaded from debian.org?
> > I know at least of one such process and its the one used at metadistros
> > (metadistros.hispalinux.es). The tool in this case is called 'calzador'.
Looking at the question again I see that I did not answer the question
properly. The process used by Metadistros is not based exclusively on
Debian downloaded debs, but uses some custom tools/software. The 'calzador'
is really just part of the process and is really a set of preconfiguration
data/scripts for use in a LiveCD.
>
> Is there any code that goes with that? I saw the wiki, but not knowing any
> Spanish, didn't really get much from it.
Yes, maybe not too ready for mainstream:
ftp://ftp.softwarelibre.ulpgc.es/METADISTROS/calzador/calzador.tar.bz2
the (modified) kernel modules for Live-CD support are available at
ftp://ftp.softwarelibre.ulpgc.es/METADISTROS/calzador/modulos.tar.bz2
The procedure is not yet completely automated (I got it wrong, sorry). It
is described (in Spanish) at
http://metadistros.hispalinux.es/tiki-index.php?page=HowTo
> > IIRC it basicly depends on having a chroot environment set with the OS
> > image you want to burn and it adds that together with the bootup stuff.
>
> > > Obviously it's non-trivial, but it should be possible to have debootstrap
> > > (or a similar tool) construct bootable Knoppix-esque CDs without any
> > > user-interaction IMO.
>
> I'm envisaging something like:
>
> mkdir sarge-chroot
> debootstrap --include knoppix,calzador sarge sarge-chroot
> # setup a chroot environment with knoppix and calzador tools
> chroot sarge-chroot /usr/sbin/knoppix install-pkgs
> # install and configure the standard "knoppix" patches
This step in meta-distros is based on a meta-package that downloads all the
needed packages and dependancies.
(...)
> Being able to automatically install a useful system with lots of gnome
> and kde and whatever other stuff without having to spend hours in dselect
> or aptitude or answering questions or doing other configuration stuff
> has obvious benefits, as does being able to easily convert an existing
> system into something you can burn to a CD.
That's really what has made interest in Knoppix-like distributions spark.
> Also obvious, though, is that both those steps are hard: working out
> a good set of packages to install, and configuring them usefully is
> non-trivial; as is making Debian work with a read-only root.
That's why people usually 'remaster' Knoppix instead of starting from
scratch. That is, they take the live-CD, dump it to disk, chroot into it,
remove/add stuff and generate a new liveCd.
> (While the hypothetical /usr/sbin/knoppix and /usr/sbin/tasksel both
> solve similar problems they're not quite the same -- /usr/sbin/knoppix
> needs to select _and_ configure all the packages you want, tasksel just
> selects them. debconf might not be enough either -- /usr/sbin/knoppix
> might need to actually modify various files in /etc, too)
Taken into account the configuration stuff in Live-CDs is usually done
manually and is also very specific to the kind of live-CD you want to
create (as well as who will use it, what applications you want to include,
etc..). I don't believe that should be included in a /usr/sbin/knoppix.
I might be wrong however.
Regards
Javi
Tollef Fog Heen
| Especially since stable doesn't even install on recent server boxes...
Installed fine on my dual Opteron. I doubt you'll get very much more
recent hardware.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
Ralf Hildebrandt
> * Ralf Hildebrandt
>
> | Especially since stable doesn't even install on recent server boxes...
>
> Installed fine on my dual Opteron. I doubt you'll get very much more
> recent hardware.
The problem being the non supported hardware (like in our case the
Intel Gigabit network card, which was only supported from 2.4.20
upwards). This makes a network install a pain.
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hil...@charite.de
Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-916
Referat V a - Kommunikationsnetze - AIM. ralfpostfix
John Goerzen
> > Could you point me at the specific paragraph in either the constitution
> > or the social contract, or in perhaps any other official document by the
> > Debian project as a whole that supports this statement?
>
> Especially since stable doesn't even install on recent server boxes...
Oh, I guess you must be talking about things like our new rack-mount
PowerEdge 2650 with aacraid built in? A machine that the stable CD
installed with no trouble whatsoever?
What are you talking about? Supporting new server hardware is not the
same as supporting the latest graphics card. At *worst*, you can pop in
a new kernel and be good to go.
Goswin von Brederlow
> On Wed, Nov 26, 2003 at 08:07:16AM +0100, Andreas Tille wrote:
> [snip]
> > .. But currently Debian is missing
> > something: We have no brain dead method to create a user customized CD
> > with really good auto detection. ..
> [snip]
>
> What things are autodetected by Knoppix and its ilk?
Two major things I can name:
kernel modules (apt-get install discover(2) or hotplug takes care of
that)
XFree configuration
> What things are not autodetected?
>
> What things are autodetected in "compatibility mode", i.e. will likely
> require configuration tweaks for maximum performance?
XFree might fail to work perfectly or might need a bootparameter to
use a framebufer driver instead. But I've heard far more people on irc
saying knoppix works but debian they can't get working than the other
way around.
> What things are so easy to autodetect that they are "just right every
> time"?
>
> What's the ratio of things in each category?
>
> Why don't you just move autodetection into the main kernel or driver trees?
Keep stuff out of the kernel. Its too big already. We don't need or
want autodetection of the monitor frequencies or the dsl contracktor
in the kernel.
> I don't see why it needs to be this complicated...
Three things: 1. thick headed maintainers, 2. policy, 3. time
MfG
Goswin
Turbo Fredriksson
> On Wed, 26 Nov 2003, Turbo Fredriksson wrote:
>
> > That have absolutely nothing to do with the issue(s)! I say again: The problem
> > with getting releases out the door in a timely manner (no, two years between
> > releases is NOT 'timely manner'!!) is the shear size of the distribution.
> Hmm, are you aware that long living releases are exactly what enterprises
> regard as an advantage and that this would support your "Enterprise-only-idea"?
Two-three years? No way!
> BTW, feel free to ignore the Custom Distributions approach which tries to
> cope with the size of Debian for certain tasks.
I don't. I think they are wonderfull, and exactly what's needed. But for the
server side of the enterprise, all that should be supplied by Debian GNU/Linux.
All the currently existing derivates of Debian GNU/Linux is for the end-user,
and that's fine.
--
fissionable Uzi FSF SDI cracking 767 Soviet South Africa congress
critical explosion Ortega jihad Clinton quiche
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Anthony Towns
> Taken into account the configuration stuff in Live-CDs is usually done
> manually and is also very specific to the kind of live-CD you want to
> create (as well as who will use it, what applications you want to include,
> etc..). I don't believe that should be included in a /usr/sbin/knoppix.
> I might be wrong however.
Maybe I should've called it /usr/sbin/klaus_knopper ;)
Anyway, the stuff that hypothetical binary does is:
* mark a bunch of packages for install, and run apt-get on them
* configure them in some pre-deterined way
The first is trivial to automate once you've selected the packages,
although it can suck a bit to maintain as some of the packages get
dropped from unstable.
The second is harder to automate, but it's something we need to do
anyway: it's the same thing we want to be able to dump images out to
a hundred computers in a university lab, or a thousand computers on
secretaries desks at your favourite multinational or government agency,
or ten-thousand computers in a roll-out for a new search engine.
Getting that working for a single case (live CDs), is a good way to get
it working well for the general case, and even if not, tends to make
the single case a bunch easier.
Tollef Fog Heen
| The problem being the non supported hardware (like in our case the
| Intel Gigabit network card, which was only supported from 2.4.20
| upwards). This makes a network install a pain.
Then netboot it with a more up-to-date-kernel.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
Turbo Fredriksson
> No, because if we only had, say, 3000 packages, a lot of people wouldn't
> have their pet packages left in Debian, and thus nothing to care for...
> Would you become an active apache2-maintainer if we dumped Roxen? After
> all, we don't need more than one webserver, do we?!
Yes we do, but we don't need xMb of Linux Gazette, 'lots' of megs for misc
games etc. The list can probably be made long... That can be provided by
any of the the Debian GNU/Linux derivates...
--
Clinton 767 Soviet smuggle arrangements Peking Marxist Rule Psix
Ft. Meade FBI subway colonel pits SEAL Team 6 congress
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Turbo Fredriksson
> On Wed, 26 Nov 2003 21:35, Turbo Fredriksson <tu...@debian.org> wrote:
> > But since we're (more than?) 600 developers, maintaining 8000 packages is
> > difficult. But if those 600 developers only had say 3000 (just a number out
> > the head), then more bugs could be fixed, and I could get more help fixing
> > MY bugs when/if I don't have the time (or knowledge, which is the case in
> > the listed packages). --
>
> Let's consider for the sake of discussion that this package cull involved
> removing Postfix and KDE (we have Exim and GNOME).
Postfix is needed in the 'Enterprise'. Just because we have Exim, don't meen we
can't have multiple choises. Some entrprises would REFUSE to run anything than
Sendmail (or qmail in my case). If that isn't supplied, I wouldn't be able to
run Debian GNU/Linux. Choise is good, but I think we've overdone it...
About KDE. I don't like it so I wouldn't cry if it went out. But I guess the
discussion on what "an Enterprise" really entitles. I think that Debian GNU/Linux
should provide the _server_ end of the Enterprise, not the _whole_ Enterprise...
--
Soviet genetic strategic Semtex toluene terrorist Marxist fissionable
subway arrangements Nazi Panama Mossad cracking NORAD
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Mark Brown
> Quoting David Weinehall <t...@debian.org>:
> > No, because if we only had, say, 3000 packages, a lot of people wouldn't
> > have their pet packages left in Debian, and thus nothing to care for...
> Yes we do, but we don't need xMb of Linux Gazette, 'lots' of megs for misc
> games etc. The list can probably be made long... That can be provided by
> any of the the Debian GNU/Linux derivates...
You're missing the point. Fewer packages doesn't automatically mean
more people working on the packages that remain.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Tom
> --
> fissionable Uzi FSF SDI cracking 767 Soviet South Africa congress
> critical explosion Ortega jihad Clinton quiche
> [See http://www.aclu.org/echelonwatch/index.html for more about this]
Just because you have the right to free speech does not mean you have
the right to yell "Fire" in a crowded movie theatre.
Intentionally causing everybody's mail traffic to look like bomb threats
is pretty close to yelling "Fire" in a theatre.
If you want to fuck with the government, go right ahead Mr. Ruby Ridge,
but leave me the hell out of it.
David Weinehall
>
> > No, because if we only had, say, 3000 packages, a lot of people wouldn't
> > have their pet packages left in Debian, and thus nothing to care for...
> > Would you become an active apache2-maintainer if we dumped Roxen? After
> > all, we don't need more than one webserver, do we?!
>
> Yes we do, but we don't need xMb of Linux Gazette, 'lots' of megs for misc
> games etc. The list can probably be made long... That can be provided by
> any of the the Debian GNU/Linux derivates...
Ah, but it isn't the xMB's of Linux Gazette, games etc that are holding
back the release, but rather important packages such as glibc, xfree86
etc. Generally, nothing depends on a game, so if games are everything
holding up a release, then "Tough luck - better luck next time", and lo!
they are gone. This isn't the case for packages with a lot of
dependencies on them however. Those packages hold up the release.
So if you really want to see a release soon, dig up the release-critical
bugs that holds up the largest amount of other packages and dig in.
Regards: David Weinehall
--
/) David Weinehall <t...@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
Eike "zyro" Sauer
> Intentionally causing everybody's mail traffic to look like bomb threats
> is pretty close to yelling "Fire" in a theatre.
If your government (which ever that might be) isn't able to
tell apart mailing lists from terrorists' conspirative emails,
you really should vote for another one.
Ciao,
Eike
Andreas Tille
> > Hmm, are you aware that long living releases are exactly what enterprises
> > regard as an advantage and that this would support your "Enterprise-only-idea"?
>
> Two-three years? No way!
I recently upgraded two Potato boxes to Woody.
> > BTW, feel free to ignore the Custom Distributions approach which tries to
> > cope with the size of Debian for certain tasks.
>
> I don't. I think they are wonderfull, and exactly what's needed. But for the
> server side of the enterprise, all that should be supplied by Debian GNU/Linux.
>
> All the currently existing derivates of Debian GNU/Linux is for the end-user,
> and that's fine.
Once people.d.o is available again please read
http://people.debian.org/~tille/debian-med/talks/200311_lux_cust/html/mgp00008.html
twice and decide whether you are ignoring Custom Distributions when writing
paragraphs like the one above.
Kind regards
Andreas.
--
Sie schaffen eine Wüste und nennen es Frieden.
-- Publius Cornelius Tacitus (55-120)
Tom
> Tom schrieb:
> > Intentionally causing everybody's mail traffic to look like bomb threats
> > is pretty close to yelling "Fire" in a theatre.
>
> If your government (which ever that might be) isn't able to
> tell apart mailing lists from terrorists' conspirative emails,
> you really should vote for another one.
Sorry, you don't get to play the moral high ground on this.
Yelling "Fire" in a crowded theatre does not mean you are starting
fires. It means you are intentionally causing disruption for the
express purpose of disrputing society -- and that is a right you DO NOT
have.
You have a right to protest -- sure -- but that right is not limitless.
We have a saying: "Your right to swing your fist stops at my nose."
You are forcing me to go along with something I don't believe in. It's
very rude.
Turbo Fredriksson
> * Wouter Verhelst <wou...@grep.be>:
> > On Wed, Nov 26, 2003 at 11:57:12AM +0100, Turbo Fredriksson wrote:
> > > Debian GNU/Linux have ALWAYS been targeted (primarily) for servers.
> >
> > Could you point me at the specific paragraph in either the constitution
> > or the social contract, or in perhaps any other official document by the
> > Debian project as a whole that supports this statement?
>
> Especially since stable doesn't even install on recent server boxes...
Thanx. I love it when someone else is proving my point!
--
kibo ammonium cryptographic spy North Korea Uzi SEAL Team 6 FSF
supercomputer Noriega Albanian toluene iodine counter-intelligence
assassination
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Turbo Fredriksson
> On Wed, Nov 26, 2003 at 11:57:12AM +0100, Turbo Fredriksson wrote:
> > Debian GNU/Linux have ALWAYS been targeted (primarily) for servers.
>
> Could you point me at the specific paragraph in either the constitution
> or the social contract, or in perhaps any other official document by the
> Debian project as a whole that supports this statement?
No I can't. But it's been up for discussion on the mailinglists a NUMBER of
times, and the conclution was always that Debian GNU/Linux is a server OS,
but not primarily (note: in that order, more or less exact words).
> If not, I can but conclude that your are misinformed. Debian is for "our
> users and free software" (Social Contract 4). In the past, our users
> have primarily been "people running servers", but that has clearly
> changed. Saying that Debian is only for servers and that nobody should
> be using it on the desktop is like saying that Linux should only be used
> by volunteers and hobbyists, because they're the ones who originally
> created it and gave it momentum.
Now don't put words in my mouth, and I won't put any in yours! Yes, the
users are more and more non-admins and that's just fine. But SOMEONE needs
to supply _exactly_ what the admin needs. And sine (basically) nonone else
is doing it, I think that Debian GNU/Linux should rediscover it's roots and
supply this...
> Especially trying to tell other volunteers how they should use their
> time is, uh, silly. We're volunteers; if we're no longer interested, we
> won't be volunteers anymore and will move on to other things.
Yes. And I'm also a volunteer. You and all the others that think Debian
GNU/Linux should be a 'one-size-fits-all' kind'a distribution is trying to
do something that just won't work in the long run. And that long run is
WAY behind us. It should be quite obvious that it doesn't work to have
such a huge distribution. There's only one distribution that is this big,
and that's ours. Just that fact should tell you something. It doesn't
work...
--
KGB Panama Marxist iodine cryptographic NSA Mossad Cocaine Semtex
Peking strategic munitions killed PLO Ortega
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Wouter Verhelst
>
> > No, because if we only had, say, 3000 packages, a lot of people wouldn't
> > have their pet packages left in Debian, and thus nothing to care for...
> > Would you become an active apache2-maintainer if we dumped Roxen? After
> > all, we don't need more than one webserver, do we?!
>
> Yes we do,
Well, that's your opinion. In my opinion, we don't *need* 20
webservers, 14 MTA's, and whatnot[1]. Then again, my laptop isn't really
a webserver, and I do understand the reason for the fact we do have 20
webservers and 14 MTA's: Having more packages implies having more
choice. Choice is good.
> but we don't need xMb of Linux Gazette,
Shall we throw out doc-linux-text and doc-linux-html while we're at it?
> 'lots' of megs for misc games etc. The list can probably be made
> long... That can be provided by any of the the Debian GNU/Linux
> derivates...
Why do you insist on putting these in their own private tiny bit? Isn't
it better to have a "Universal Operating System" which can be employed
in any number of ways, including a mixed system?
[1] try for yourself:
grep-available -FProvides httpd -sPackage|wc -l
grep-available -FProvides mail-transport-agent -sPackage|wc -l
Andreas Tille
> Ummm... You are wrong here. Knoppix (or Knoppix-derived versions) provide
> three things:
I do not intend to argue who is wrong here. At least I had several talks
with Klaus Knopper in his mother tongue and I'm very sure that he intended
to make a live CD. The hdinstall script (and its modifications / rewrites)
was hidden a long time to allow only experienced users to do what Klaus
regarded as nice contribution.
> 1- a live CD (can be easily developed with the usual tools)
>
> 2- autoconfiguration of hardware (again, this is or could be integrated
> into Debian)
>
> 3- preconfiguration of all the software and customisation for a specific
> need.
>
> 4- a system to duplicate this live Cd into hard disk, making the necessary
> changes based on what was auto-detected.
Well, this is your interpretation of Knoppix. It is a nice feature but
there is no reference that Klaus Knopper has this purpose in mind (even if
it works). That's why I was talking always about a live CD - and this is
my main goal for Custom Debian distributions. The install feature would be
a nice add on, but not the primary goal. We have d-i.
> The nice part of Knoppix is not that it auto-detects hardware since this
> can be done already in Debian
You are definitely missing the point here: I do not want to install Debian.
I want to go to a teacher in a scool, a customer or to a random PC I want
to run my MagicPoint presentation, put my live CD into it and leave the
PC as it was before once I'm ready.
> Hope that clears up the idea
^^^
Please specify "the" in the centence above. I guess you mean "my idea of
how I want to use Knoppix". This is perfectly OK and useful. But there
are other ideas worth thinking about it.
Kind regards
Andreas.
Turbo Fredriksson
> The thing that makes Debian unique and not JALD (Just Another Linux
> Distribution) is, in my experience, our strict adherence to the DFSG,
> as guided by the Debian Social Contract. Debian is different from
> other distributions the way that the FSF is different from other
> organizations that make free software - Debian is a *philosophy*.
Rubbish. Debian GNU/Linux of today is a distribution which will package
ANYTHING as long as it's DFSG. Other than that, we're becoming more and
more a JALD as you niceley put it.
There's nothing special about Debian GNU/Linux any more. It's not that
more stable, upgrades isn't that much better, but most of all 'our support
for (some) new hardware really stink!'. Woody is just way to old to be
the perfect (server) OS.
--
Qaddafi ammonium assassination Delta Force Iran Kennedy Albanian
tritium fissionable pits smuggle Clinton Rule Psix 747 security
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Matt Zimmerman
> Debix (through the device mapper) completly removes the live CD aspect of
> the installation. The CD part becomes completly transparent. The Knoppix
> developers are quite intrested in this since all the other methods
> (onionfs, lucientfs, symlink farm) all, well, suck. When 2.6 is released
> and becomes stable device mapper support is in the standard kernel so no
> extra patches will be neccessary, which is another argument for it.
So am I to understand that you plan to use device-mapper snapshots in order
to provide copy-on-write at the block device level in order to implement
this? If so, this is interesting. I assume you will use a RAM disk for
writable storage? What filesystem will you use?
--
- mdz
Eike "zyro" Sauer
> It means you are intentionally causing disruption for the
> express purpose of disrputing society -- and that is a right you DO NOT
> have.
Nothing is disrupted if nothing is scanning my email.
I don't favour a society reading my emails.
It's totally different from the cinema "example".
I do favour cinemas and I do favour people screming if a fire broke out.
> We have a saying: "Your right to swing your fist stops at my nose."
Very right.
> You are forcing me to go along with something I don't believe in. It's
> very rude.
How are you "going along with" that?
You are the receiver, not the sender of the email.
If someone is visiting you looking for bombs,
blame them, not me.
Ciao,
Eike
PS: I'll try to set Fup-To: poster, hope it gets through
the news->mail gateway.
Wouter Verhelst
>
> > On Wed, 26 Nov 2003, Turbo Fredriksson wrote:
> >
> > > That have absolutely nothing to do with the issue(s)! I say again: The problem
> > > with getting releases out the door in a timely manner (no, two years between
> > > releases is NOT 'timely manner'!!) is the shear size of the distribution.
> > Hmm, are you aware that long living releases are exactly what enterprises
> > regard as an advantage and that this would support your "Enterprise-only-idea"?
>
> Two-three years? No way!
Uhm.
In the winter of 2001-2002, I worked at interim at a certain large
multinational corporation (whose name I shall not share, since I don't
know whether they'd like me sharing this kind of information; but which
most certainly qualifies for the definition of the term "enterprise"),
where they had just started migrating their desktops to Windows 2000...
from Windows '95. Yes, that means that before 2001, they did not install
anything on their desktops except for Windows '95.
Isn't that, like, 5-6 years?
And we're talking about desktops here. Not servers, where enterprises
usually take a while longer than on their desktop to migrate to
different systems.
--
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
-- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Alastair McKinstry
>> Tom schrieb:
>> > Intentionally causing everybody's mail traffic to look like bomb threats
>> > is pretty close to yelling "Fire" in a theatre.
>>
>> If your government (which ever that might be) isn't able to
>> tell apart mailing lists from terrorists' conspirative emails,
>> you really should vote for another one.
>
>Sorry, you don't get to play the moral high ground on this.
>Yelling "Fire" in a crowded theatre does not mean you are starting
>fires. It means you are intentionally causing disruption for the
>express purpose of disrputing society -- and that is a right you DO NOT
>have.
>
>You have a right to protest -- sure -- but that right is not limitless.
>
>We have a saying: "Your right to swing your fist stops at my nose."
>
>You are forcing me to go along with something I don't believe in. It's
>very rude.
>
>
The intention appending keywords to mail is to make it impossible to conduct
_mass_surveillance_ , by monitoring all
email looking for stuff "you dont like".
That stuff _may_ be terrorist action, but it can, and frequently
has been, legitimate political and social action: I do not want a government
I disapprove of having the ability to know
whats going on in the political opposition and neutralising it.
There are other methods of fighting crimes such as terrorism,
and the ones we allow governments to use in our name must
be targetted to the minority conducting these acts.
Hence, the reason I don't include such tag lines (any more) to my mail is that
I believe modern filters in Echelon, etc. can
easily dismiss them. I believe Echelon should be dismantled,
and approve strongly of disrupting such things.
Can we take this thread to somewhere more relevant?
debian-curiosa for example (it is Debian related, in that
its spook.el in emacs generating this stuff :-)
- Alastair McKinstry
Matt Zimmerman
> When 2.6 is released and becomes stable device mapper support is in the
> standard kernel so no extra patches will be neccessary, which is another
> argument for it.
It may be even sooner than that, see http://bugs.debian.org/213063
--
- mdz
Tom
> Tom schrieb:
> > It means you are intentionally causing disruption for the
> > express purpose of disrputing society -- and that is a right you DO NOT
> > have.
>
> Nothing is disrupted if nothing is scanning my email.
> I don't favour a society reading my emails.
>
> It's totally different from the cinema "example".
> I do favour cinemas and I do favour people screming if a fire broke out.
>
> > We have a saying: "Your right to swing your fist stops at my nose."
>
> Very right.
>
> > You are forcing me to go along with something I don't believe in. It's
> > very rude.
>
> How are you "going along with" that?
> You are the receiver, not the sender of the email.
> If someone is visiting you looking for bombs,
> blame them, not me.
Let's say for the sake of argument I don't believe in drug laws (I
don't). Would I be justified in leaving a bag of coke on your lawn and
to call the cops saying: "I think you should really be on the lookout in
that neighborhood."
The question of whether or not it is okay to intentionally cause others
to be the subject of surveillance is completely separate from whether or
not that surveillance is legal, or scary.
So I don't support Echelon nor do I support anyone's intentional efforts
to make me a target of Echelon. The first half dozen times the .SIG I
thought "boy, that guy sure is making a statement" then I realized :
he's making a statement for me too!
Send those bits to people who want to get them. At best its spam.
But this is a flamewar, and I will make no further responses nor read
any further responses, because I tend to get out of hand on this list
:-)
Wouter Verhelst
> Quoting Wouter Verhelst <wou...@grep.be>:
>
> > On Wed, Nov 26, 2003 at 11:57:12AM +0100, Turbo Fredriksson wrote:
> > > Debian GNU/Linux have ALWAYS been targeted (primarily) for servers.
> >
> > Could you point me at the specific paragraph in either the constitution
> > or the social contract, or in perhaps any other official document by the
> > Debian project as a whole that supports this statement?
>
> No I can't.
In that case, what you've been saying simply isn't true. The only
organization who can say something about the intended purpose of the
Debian distribution is the Debian Project. In this case, if there is no
official document that supports your statement, your statement is false.
> But it's been up for discussion on the mailinglists a NUMBER of
> times, and the conclution was always that Debian GNU/Linux is a server OS,
> but not primarily (note: in that order, more or less exact words).
What mailinglists? Do they have any connection to the Debian Project? If
not, see above -- and even then, a mailinglist is hardly an authoritative
source...
> > If not, I can but conclude that your are misinformed. Debian is for "our
> > users and free software" (Social Contract 4). In the past, our users
> > have primarily been "people running servers", but that has clearly
> > changed. Saying that Debian is only for servers and that nobody should
> > be using it on the desktop is like saying that Linux should only be used
> > by volunteers and hobbyists, because they're the ones who originally
> > created it and gave it momentum.
>
> Now don't put words in my mouth,
Where did I put words in your mouth? I made a comparison, there's a huge
difference.
[...]
> WAY behind us. It should be quite obvious that it doesn't work to have
> such a huge distribution. There's only one distribution that is this big,
> and that's ours. Just that fact should tell you something. It doesn't
> work...
I'm not saying that the way we manage things currently is perfect. Yes,
maybe we should change and improve the way we work; but throwing stuff
out isn't exactly the right way to do it.
John Hasler
> But since we're (more than?) 600 developers, maintaining 8000 packages is
> difficult. But if those 600 developers only had say 3000 (just a number
> out the head), then more bugs could be fixed, and I could get more help
> fixing MY bugs when/if I don't have the time (or knowledge, which is the
> case in the listed packages).
And if dumping 5000 packages resulted in the loss of 500 developers?
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, Wisconsin
Toens Bueker
>> | Especially since stable doesn't even install on recent server boxes...
>>
>> Installed fine on my dual Opteron. I doubt you'll get very much more
>> recent hardware.
>
> The problem being the non supported hardware (like in
> our case the Intel Gigabit network card, which was only
> supported from 2.4.20 upwards). This makes a network
> install a pain.
There are some workarounds. One is
http://people.debian.org/~blade/XFS-Install/
from Eduard Bloch.
There is an downloadable ISO-Image (floppies, too, of
course), which lets you install woody based on
2.4.20 (and xfs, if you like).
The floppies include various drivers for SCSI controllers,
etc. (and even for your intel card, iirc).
by
Töns
--
There is no safe distance.
Thomas Hood
> Debian only has a very few things left that need to be changed for a
> read-only root. All software should be changed to allow for linking
> files or dirs into a ramdisk or to a kernel file (/etc/mtab ->
> /proc/mounts). If you know of any that can't cope a link to a
> writeable place let me know and file a bug.
>
> Also with debix you don't have a read-only root unless you want to.
Info: I have a page that summarizes read-only root issues:
http://panopticon.csustan.edu/thood/readonly-root.html
Re: my "allow mtab to be at the end of a symlink" patch ...
The patch was acknowledged by the util-linux upstream maintainer.
No promise was made that the patch would be applied, however.
--
Thomas Hood <jdt...@yahoo.co.uk>
Turbo Fredriksson
> And we're talking about desktops here. Not servers, where enterprises
> usually take a while longer than on their desktop to migrate to
> different systems.
I don't think the differences between Potato and Woody constitutes the
title 'different system', but ok. I agree in most part that an upgrade
shouldn't be done lightly.
It's just that for the last year I've had to upgrade a lot of customer
machines to Unstable and/or Testing because of the shear 'oldness' of
the system. LDAP, Kerberos, most mail server (except QMail, thank good
- must mean something :) and most notably Samba etc etc have had so
many new features and improved performance/security that it was a
requirement to upgrade.
But a distribution that takes security, stability, 'upgradability'
(don't seem to be a word according to ispell, but I guess I get my
point through :) and most of all is very slim can get updates and
upgrades through the door quicker than a _HUGE_ distribution.
I wish there WAS a way to combine the need for many packages and
the things I _require_ from a server OS, but we've tried a few,
and none of them have worked. The current system with packages
slowly migrating from unstable to stable via testing don't work
either. So get your thinking hat on and solve the problem if you're
so hot for lots of packages. I have thought about this on and of
for years, and still haven't had a good idea...
--
nuclear Waco, Texas subway critical ammonium bomb genetic Soviet pits
Khaddafi counter-intelligence terrorist president kibo iodine
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Turbo Fredriksson
> On Wed, Nov 26, 2003 at 04:38:52PM +0100, Turbo Fredriksson wrote:
> > Quoting David Weinehall <t...@debian.org>:
>
> > > No, because if we only had, say, 3000 packages, a lot of people wouldn't
> > > have their pet packages left in Debian, and thus nothing to care for...
>
> > Yes we do, but we don't need xMb of Linux Gazette, 'lots' of megs for misc
> > games etc. The list can probably be made long... That can be provided by
> > any of the the Debian GNU/Linux derivates...
>
> You're missing the point. Fewer packages doesn't automatically mean
> more people working on the packages that remain.
Those that are interested in making the best server distribution the
'Net have ever seen (which Debian GNU/Linux was 'once up on a time' -
five years ago roughly) can continue. Those that aren't, and are only
interested in calling themselfs 'Official Debian GNU/Linux Developer'
can go work for RH. They make a sucky distribution so that should fit
them just right.
--
subway ammunition plutonium kibo 767 iodine domestic disruption
Cocaine BATF PLO jihad genetic explosion Marxist DES
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Turbo Fredriksson
> > but we don't need xMb of Linux Gazette,
>
> Shall we throw out doc-linux-text and doc-linux-html while we're at it?
<beggingly>Yes please.</beggingly>
> Isn't it better to have a "Universal Operating System" which can be employed
> in any number of ways, including a mixed system?
Yes it is, if it worked. It doesn't.
--
North Korea Waco, Texas Clinton subway FSF security Rule Psix
fissionable smuggle CIA Khaddafi NSA president SDI BATF
Javier Fernández-Sanguino Peña
> On Wed, 26 Nov 2003, Javier Fernández-Sanguino Peña wrote:
>
> > Ummm... You are wrong here. Knoppix (or Knoppix-derived versions) provide
> > three things:
> I do not intend to argue who is wrong here. At least I had several talks
> with Klaus Knopper in his mother tongue and I'm very sure that he intended
> to make a live CD. The hdinstall script (and its modifications / rewrites)
> was hidden a long time to allow only experienced users to do what Klaus
> regarded as nice contribution.
Sorry, I don't intend to discuss on this. Still, the hdinstall stuff is one
of the things people creating derived live-cd versions (or live-cds made
from scratch) are very fond of. This is the thing that has enabled Linex,
for example, to be deployed on 3200 computers (200 different
schools). Even if this was not a side effect that Klaus was interested in,
it's definitely something that others feel as important.
> > 4- a system to duplicate this live Cd into hard disk, making the necessary
> > changes based on what was auto-detected.
> Well, this is your interpretation of Knoppix. It is a nice feature but
> there is no reference that Klaus Knopper has this purpose in mind (even if
> it works). That's why I was talking always about a live CD - and this is
> my main goal for Custom Debian distributions. The install feature would be
> a nice add on, but not the primary goal. We have d-i.
d-i is perfect for a custom installation, it's never going to be a system
in which everything is already predefined and the user just says 'install
this'. Notice that the step 4 is linked a lot with 3. If the live-cd
distribution is not customised it makes not sense to install it to hard
disk, if it is, it makes all the sense.
>
> > The nice part of Knoppix is not that it auto-detects hardware since this
> > can be done already in Debian
> You are definitely missing the point here: I do not want to install Debian.
> I want to go to a teacher in a scool, a customer or to a random PC I want
> to run my MagicPoint presentation, put my live CD into it and leave the
> PC as it was before once I'm ready.
That's what you want to do. That's not what others might want, I'm giving
another POV.
>
> > Hope that clears up the idea
> ^^^
> Please specify "the" in the centence above. I guess you mean "my idea of
> how I want to use Knoppix". This is perfectly OK and useful. But there
> are other ideas worth thinking about it.
Sorry, "the idea" meant "the idea of the people working in the Metadistros
project". I'm sure that there are other points of view, I'm just sharing
those of others projects which should try to integrate with Debian too.
Still, the idea has to mature IMHO in order for this to be done.
Regards
Javi
Turbo Fredriksson
> Turbo Fredriksson writes:
> > But since we're (more than?) 600 developers, maintaining 8000 packages is
> > difficult. But if those 600 developers only had say 3000 (just a number
> > out the head), then more bugs could be fixed, and I could get more help
> > fixing MY bugs when/if I don't have the time (or knowledge, which is the
> > case in the listed packages).
>
> And if dumping 5000 packages resulted in the loss of 500 developers?
It won't. It may half the developer base, but I assume that there are 300
others that want to participate...
Besides the point really. Those that don't want to be a part of making
the best server OS should not be forced to be. We're not doing this so
that we can have a high developer base. We're doing this because we want
to do something good.
--
South Africa ammunition FBI congress tritium Treasury supercomputer
jihad colonel Soviet explosion iodine arrangements munitions security
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Turbo Fredriksson
> > No I can't.
>
> In that case, what you've been saying simply isn't true.
Drawing similarities about the Echelon stuff (other thread). Just because
the government(s) is saying that this is not happening, doesn't make it
true.
Official and unofficial sources doesn't always need to agree. Look at the
mailing list archives, and you'll see that 'a huge part' of the developers
agree with me. The most loud is 'otherwise engaged' right now.
> What mailinglists? Do they have any connection to the Debian Project? If
> not, see above -- and even then, a mailinglist is hardly an authoritative
> source...
If you ARE stupid, pretend you're not. That's usually the best action.
> > > If not, I can but conclude that your are misinformed. Debian is for "our
> > > users and free software" (Social Contract 4). In the past, our users
> > > have primarily been "people running servers", but that has clearly
> > > changed. Saying that Debian is only for servers and that nobody should
> > > be using it on the desktop is like saying that Linux should only be used
> > > by volunteers and hobbyists, because they're the ones who originally
> > > created it and gave it momentum.
> >
> > Now don't put words in my mouth,
>
> Where did I put words in your mouth? I made a comparison, there's a huge
> difference.
Read line four to seven above.
> I'm not saying that the way we manage things currently is perfect. Yes,
> maybe we should change and improve the way we work; but throwing stuff
> out isn't exactly the right way to do it.
Then what is? Do you really think that you're smarter than the rest of us?
Then why haven't you already presented a way to release on time?! I'm not
saying that just because I've been doing this (being a Debian GNU/Linux
developer) for the last 8 years makes me more right than you. I'm saying that
I've seen developers come and go in frustration that nothing happen and
because we can't do ONE thing right.
What ARE we doing? Making a free OS? A stable one? A good one? What? We
need to decide what our target audience is, and deliver what they need.
--
CIA Ft. Bragg Kennedy ammunition Semtex colonel Serbian Iran genetic
counter-intelligence SDI Peking attack Uzi Ft. Meade
Turbo Fredriksson
> There are some workarounds. One is
This is the second (or was it third) workaround presented... What I'm
trying to point out is that these shouldn't be necessary. They are, but
they shouldn't...
Releasing more often (but maintaining quality which is difficult in it
self) should make workarounds unneeded.
> There is an downloadable ISO-Image (floppies, too, of
> course), which lets you install woody based on
> 2.4.20 (and xfs, if you like).
All we who have used Debian GNU/Linux for a while know all this. If not,
we find out quickly enough. But having the same quality and simplicity
as RH (when it comes to installation, not when actually running the
system!) will make 'linux illiterates' being able to install Debian
GNU/Linux as a server OS. It shouldn't be TO easy, but...
--
terrorist Mossad Nazi radar Ft. Bragg SEAL Team 6 cryptographic
Albanian NORAD colonel plutonium subway tritium ammunition security
[See http://www.aclu.org/echelonwatch/index.html for more about this]
Goswin von Brederlow
> On Wed, 26 Nov 2003, Javier Fernández-Sanguino Peña wrote:
> > The nice part of Knoppix is not that it auto-detects hardware since this
> > can be done already in Debian
> You are definitely missing the point here: I do not want to install Debian.
> I want to go to a teacher in a scool, a customer or to a random PC I want
> to run my MagicPoint presentation, put my live CD into it and leave the
> PC as it was before once I'm ready.
Another real live example of the use of Knopix also comes from school.
To teach the student something about linux the teacher puts one
knoppix cd/dvd into one (his/hers) machine before class and starts the
netboot server. Then all other machines are turned on and the class is
ready to begin.
No need to wipe out windows or make space for dual boot.
No previous class having messed up the configuration, added backdoors
or otherwise break the system.
At the end of class every pupil saves his data to floppy or a
fileserver, turns the computer off and everything is back to the way
it was before.
MfG
Goswin
Goswin von Brederlow
> On Wed, Nov 26, 2003 at 01:46:28AM +0100, Goswin von Brederlow wrote:
>
> > Debix (through the device mapper) completly removes the live CD aspect of
> > the installation. The CD part becomes completly transparent. The Knoppix
> > developers are quite intrested in this since all the other methods
> > (onionfs, lucientfs, symlink farm) all, well, suck. When 2.6 is released
> > and becomes stable device mapper support is in the standard kernel so no
> > extra patches will be neccessary, which is another argument for it.
>
> So am I to understand that you plan to use device-mapper snapshots in order
> to provide copy-on-write at the block device level in order to implement
> this? If so, this is interesting. I assume you will use a RAM disk for
> writable storage? What filesystem will you use?
Yes, thats exactly how it works. One device for the loopback file, one
for the ramdisk/tmpfs storage and a copy-on-write snapshot combining
those two into the real root device.
Recent kernels allow using loopback files on tmpfs. Older kernels need
to use one or more ramdisks.
The problem with ramdisks is that the default size is 4 MB and
specifying the ramdisk size as boot parameter is not allways
possible. Compiling it in is also bad. With tmpfs the size can be set
at runtime and if someone adds swap that will be used for the tmpfs as
well when needed.
As filesystem I only used ext2. But device mapper provides a normal
block device like any other. Only think to note is that using a
journaled filesystem like ext3, xfs or reiserfs might not be the best
idea since the journal will fill up 32 MB (or whatever the fs has) of
ram with no benefit.
On the other hand if harddisk install is to be suported using xfs
would have the big advanted that one can move the device snapshot onto
the harddisk and grow the filesystem to fit. The moving is done with a
kernel thread beneeth the block device and at some point the data will
have moved from the cdrom and ramdisk to harddisk and the
cdrom/ramdisk can be ejected/freed. You never have to reboot or
otherwise stop your work. At some point it will just tell you its
done.
MfG
Goswin
Goswin von Brederlow
> On Wed, Nov 26, 2003 at 01:46:28AM +0100, Goswin von Brederlow wrote:
>
> > When 2.6 is released and becomes stable device mapper support is in the
> > standard kernel so no extra patches will be neccessary, which is another
> > argument for it.
>
> It may be even sooner than that, see http://bugs.debian.org/213063
Great, last time I talked to Xu (around 2.4.20 or 21) he was against
adding them.
MfG
Goswin
Matt Zimmerman
> Matt Zimmerman <m...@debian.org> writes:
> > So am I to understand that you plan to use device-mapper snapshots in order
> > to provide copy-on-write at the block device level in order to implement
> > this? If so, this is interesting. I assume you will use a RAM disk for
> > writable storage? What filesystem will you use?
>
> Yes, thats exactly how it works. One device for the loopback file, one
> for the ramdisk/tmpfs storage and a copy-on-write snapshot combining
> those two into the real root device.
>
> Recent kernels allow using loopback files on tmpfs. Older kernels need
> to use one or more ramdisks.
Hmm, so a loopback file on tmpfs could be sparsely allocated, and tmpfs
would dynamically allocate memory as it grew. Very nice.
> As filesystem I only used ext2. But device mapper provides a normal block
> device like any other. Only think to note is that using a journaled
> filesystem like ext3, xfs or reiserfs might not be the best idea since the
> journal will fill up 32 MB (or whatever the fs has) of ram with no
> benefit.
Correct, a journal does not make sense. I do wonder, though, whether
particular filesystems would attempt to minimize resource consumption in a
situation like this, by reusing deleted blocks rather than allocating new
ones, something opposite to what jffs2 does.
--
- mdz