Re: And now for something completely different... etch!

[Goswin von Brederlow]

Manoj Srivastava <[EMAIL PROTECTED] (va, manoj)> writes:

> On Wed, 22 Jun 2005 07:22:33 -0400 (EDT), Freddie Unpenstein <[EMAIL 
> PROTECTED]> said: 
>
>>> > - inetd begone! -> xinetd (better mechanism to control DoS,
>>> >   separation, etc.)
>
>>> xinetd begone. There is no justification for using anything
>>> resembling inetd on a modern system.
>
>> What planet do you live on?  I want MORE use of inetd, not less.  I
>> want to be able to select a service, and tell the system whether I
>> want it running all the time, or only when needed.
>
> Why? What you offer here are preferences and opinions, with
>  nothing to back them up. Previous posters in the discussion have
>  offered reasons not to use inet daemons -- off the top of my head, it
>  was a) in the current day and age, an idling daemon does not consume
>  a significant amount of resources, b) a inted daemon adds complexity
>  to the mix, and another point of failure/attack c) It adds latency to
>  response for the daemon (I may have missed other points).
>
> What do you have to counter these points? I can speculate that
>  you may disagree with point a above, but if so, I think in my
>  experience point a has been justified.
>
> manoj

What amounts to significant is higly usage dependent. In embeded use,
e.g. all those wireless routers with linux out there, wasting an extra
MB ram might be critical. On the other hand the ram has to be
available in case the service does get used anyway. But there might be
cases where only one of several alternative services is in use at any
given time (e.g. either telnet or http configuration frontend). Having
both always loaded needs more resources.

Using inetd means services don't have to be manualy restarted when the
config file is changed (as that is parsed on each connect).

Inetd gives a single point to control access. A single point to filter
out unwanted or unalowed access. Easier than to implement the same
access restrictions in every daemon.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Paul TBBle Hampson]

On Thu, Jun 23, 2005 at 09:58:31PM +0200, Tollef Fog Heen wrote:
> * Paul TBBle Hampson 

> | The charset of your terminal is orthogonal to the charset you're
> | talking on the IRC network with to my mind, since even the built-in
> | recode support lets you set a default charset for IRC traffic.

> No, it's not, since at least one of the most popular IRC clients
> (irssi) doesn't have recode support (yet).

Which version are you running? There's recode.pl and charsetwars.pl
in irssi-scripts in Woody, and if you grab a CVS build, there's
recode support built in too. (Actually, I don't know that charsetwars.pl
was in Woody. I only discovered it recently. ^_^)

I've been using irssi from a UTF-8 terminal on SJIS channels on my
Woody web server since September 2003, at least. The enormous time
between irssi releases means I've had to run a CVS version on my
unstable local box for about twelve months, to fix interesting
DCC and frontend bugs.

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgpLZKzzTBN3T.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Tollef Fog Heen]

* Paul TBBle Hampson 

| The charset of your terminal is orthogonal to the charset you're
| talking on the IRC network with to my mind, since even the built-in
| recode support lets you set a default charset for IRC traffic.

No, it's not, since at least one of the most popular IRC clients
(irssi) doesn't have recode support (yet).

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Jim Crilly]

On 06/22/05 12:02:53PM -0500, Manoj Srivastava wrote:
> On Wed, 22 Jun 2005 07:22:33 -0400 (EDT), Freddie Unpenstein <[EMAIL 
> PROTECTED]> said: 
> 
> >> > - inetd begone! -> xinetd (better mechanism to control DoS,
> >> >   separation, etc.)
> 
> >> xinetd begone. There is no justification for using anything
> >> resembling inetd on a modern system.
> 
> > What planet do you live on?  I want MORE use of inetd, not less.  I
> > want to be able to select a service, and tell the system whether I
> > want it running all the time, or only when needed.
> 
> Why? What you offer here are preferences and opinions, with
>  nothing to back them up. Previous posters in the discussion have
>  offered reasons not to use inet daemons -- off the top of my head, it
>  was a) in the current day and age, an idling daemon does not consume
>  a significant amount of resources, b) a inted daemon adds complexity
>  to the mix, and another point of failure/attack c) It adds latency to
>  response for the daemon (I may have missed other points).
> 
> What do you have to counter these points? I can speculate that
>  you may disagree with point a above, but if so, I think in my
>  experience point a has been justified.

>From the security aspect using xinetd automatically gets you things like
connection rate limiting, tcp wrappers support, source address
restrcitions,
available time restrictions, connection logging, interface binding, etc.

Sure some daemons already sport those options, but not all do and if a
standard is to be chosen it should be safer one. If you know the service
well enough to configure it you probably also know how to disable the
xinetd instance and enable the init script.

> 
> manoj

Jim.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Manoj Srivastava]

On Wed, 22 Jun 2005 07:22:33 -0400 (EDT), Freddie Unpenstein <[EMAIL 
PROTECTED]> said: 

>> > - inetd begone! -> xinetd (better mechanism to control DoS,
>> >   separation, etc.)

>> xinetd begone. There is no justification for using anything
>> resembling inetd on a modern system.

> What planet do you live on?  I want MORE use of inetd, not less.  I
> want to be able to select a service, and tell the system whether I
> want it running all the time, or only when needed.

Why? What you offer here are preferences and opinions, with
 nothing to back them up. Previous posters in the discussion have
 offered reasons not to use inet daemons -- off the top of my head, it
 was a) in the current day and age, an idling daemon does not consume
 a significant amount of resources, b) a inted daemon adds complexity
 to the mix, and another point of failure/attack c) It adds latency to
 response for the daemon (I may have missed other points).

What do you have to counter these points? I can speculate that
 you may disagree with point a above, but if so, I think in my
 experience point a has been justified.

manoj
-- 
Rome was not built in one day. John Heywood
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Freddie Unpenstein]

> > - inetd begone! -> xinetd (better mechanism to control DoS,
> >   separation, etc.)

> xinetd begone. There is no justification for using anything
> resembling inetd on a modern system.

What planet do you live on?  I want MORE use of inetd, not less.  I want to be 
able to select a service, and tell the system whether I want it running all the 
time, or only when needed.

In several cases as it is, I've taken services out of the boot sequence and 
placed them into ppp.d, inetd, or simply only start them when I need to. 


Fredderic

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Russell Coker]

On Friday 17 June 2005 22:06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > But if someone can change the cache of data written by prelink then why
> > couldn't they also change the program that does the md5 checks to make it
> > always return a good result?
>
> They can, but I've never seen a rootkit with that level of sophistication;

There have been root-kits that hide files and show the original versions to 
programs that do checks.  This is not really difficult to do with a kernel 
module.

> and if there was one, there's still the option of booting from read-only
> media to check (which is the only safe way to audit your system anyway).

True.

-- 
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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Steve Langasek]

On Thu, Jun 16, 2005 at 01:51:04PM +1000, Russell Coker wrote:
> regarding prelink

> On Thursday 16 June 2005 08:18, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > > One of the points of the md5sum verification is to ensure that the
> > > binaries haven't been tampered with.  If one can tamper with the binaries
> > > by modifying some file in /var/cache instead, doesn't that just
> > > reintroduce the same problem?

> > There are two basic reasons why people want md5sums of their binaries: to
> > know when their filesystem is eating files, and as an extra layer of
> > security to tell them their binaries have been modified by an intruder.  In
> > the first instance, removing the cache and regenerating it would be
> > sufficient to eliminate any corrupted files; in the second instance,
> > removing the cache and regenerating it would be sufficient to eliminate any
> > trojaned files (though, what a strange attack vector that would be :).

> I think that the idea would be:

> Prelink changes certain fixed parts of the binary, most of the file is never 
> changed.  The parts that are changed would have their original values stored 
> so that a checking tool can do a md5 or sha sum of the main part of the file 
> plus the original values for the parts that prelink changes.

In which case, /var/cache is absolutely the wrong place to store those
original values, since they can't be regenerated based on information on the
rest of the system.

I figured people were going the other way around with this, and suggesting
that prelink store its *output* in /var/cache, with support in the dynamic
loader for merging it in at the correct moment.

> But if someone can change the cache of data written by prelink then why 
> couldn't they also change the program that does the md5 checks to make it 
> always return a good result?

They can, but I've never seen a rootkit with that level of sophistication;
and if there was one, there's still the option of booting from read-only
media to check (which is the only safe way to audit your system anyway).

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Paul TBBle Hampson]

On Thu, Jun 09, 2005 at 10:09:06AM +0200, Tollef Fog Heen wrote:
> * Christian Perrier 

> | > Again, do not mess with cultures you do not understand.
> | 
> | Do you have real examples?

> IRC.  An example is the current irssi in Debian which doesn't do
> recoding between different locales.  (And that is needed, since IRC
> doesn't have a charset concept and there are still loads and loads of
> users out there with clients which interpret everything as Latin1.)

I'm not clear how this is an argument against UTF-8 by default...?

The charset of your terminal is orthogonal to the charset you're
talking on the IRC network with to my mind, since even the built-in
recode support lets you set a default charset for IRC traffic.

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgpFwhEZSTmSu.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Helmut Wollmersdorfer]

Gunnar Wolf wrote:

Enrico Zini dijo [Thu, Jun 09, 2005 at 12:49:39PM +0200]:



I've been it_IT.UTF-8 for quite a while with no problems.  And I also
get to be able to write the name of my girlfriend, which Latin1 cannot
encode, together with accented Italian words, which BIG5 cannot encode.



H... Silly me thought that Italian was the only Latin language
which used no diacritics. Which kind of accents does it have?


Even en_GB has diacritics.

Hopefully all this encoding problems disappear with the growing 
popularity of UNICODE/UTF-8.


E.g. besides German, Hungarian, Slowenian und Croation are official 
languages here in Austria, which must be supported through local 
government. Choosing Latin1 is a common mistake, 'Eastern Latin' would 
be the better choice. Besides it would IMHO be more political correct to 
write the names of all the Polish, Balkan, French, Eastern, Scandinavian 
and Latinos living here with original diacritics.


Helmut Wollmersdorfer


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Enrico Zini]

On Thu, Jun 16, 2005 at 01:01:17AM -0500, Gunnar Wolf wrote:

> H... Silly me thought that Italian was the only Latin language
> which used no diacritics. Which kind of accents does it have?

Italian can have accents over vowels, some are read differently if they
are grave or acute:

  à è é í ò ó ú
  À È É Í Ò Ó Ú

it's also matter of debate if the accent over a, i or u is grave or
acute.

Dieresis are used in poetry, to split a diptongue (piëtà) as well as
when writing words coming from some dialect (siüra).

Circumflexes were used in the past when a word becoming plural would end
in double 'i' (declivî).

More could show up when spelling arcaic Italian (who sometimes had an
extra letter for a sweet 'z' sound), dialects (who have all sort of
diacritics that can change from dialect to dialect and from spelling
method to spelling method) or of course when writing mixed languages in
the boundary regions where there is more than one official language.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Chris Halls]

On Wednesday 15 Jun 2005 10:09, Steve Langasek wrote:
> On Wed, Jun 15, 2005 at 10:31:45AM +0200, Petter Reinholdtsen wrote:
> > I didn't see anyone proposing prelinking so far.  I've seen rumors
> > that program start time for some programs decrease a lot if prelinking
> > is enabled.  It would be nice if we could speed up the login time, or
> > for example the openoffice start time.  Is prelinking the way to go?
> > Should it be enabled by default?
>
> Using prelink invalidates the md5sums of files belonging to Debian
> packages. Has anyone done any work to address this?

Not that I know of, and that's why we do not enable it by default in OOo.

Actually, on the subject of OOo load time, that should decrease significantly 
once we have it compiled with the new gcc that has symbol visibility support.  
75% of OOo startup time is spent in the dynamic linker, so reducing the 
number of symbols that need to be resolved will make a big difference.

Chris


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Peter 'p2' De Schrijver]

> 
> Ummm... And if instead of asking the user for a disk change, this
> mini-initrd just keeps polling the floppy for a non-erroneous read
> (this means, the drive is not empty) with the correct magic at the
> correct place?

I don't think you actually have to read anything. You can use the disk
change line to see if a disk has been inserted or not.

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Olaf van der Spek]

On 6/16/05, Joerg Friedrich <[EMAIL PROTECTED]> wrote:
> Steve Langasek schrieb am Dienstag, 14. Juni 2005 um 03:12:09 -0700:
> > Consistent LFS support - Steve Langasek <[EMAIL PROTECTED]>
> 
> Short question:
> What does LFS mean? The first thing which comes into my mind is Linux
> from Scratch. Seems not to fit in this context.

http://www.google.com/search?q=define:lfs

My guess: Large File Support, specifically files larger than 2Gb on
32-bit systems.

Re: And now for something completely different... etch!

[Olaf van der Spek]

On 6/16/05, Russell Coker <[EMAIL PROTECTED]> wrote:
> But if someone can change the cache of data written by prelink then why
> couldn't they also change the program that does the md5 checks to make it
> always return a good result?

A long, long time ago, you were supposed to boot from a read-only
floppy and run the virus scanner from there. I guess the same applies
here, if you really wish to be sure.

Re: And now for something completely different... etch!

[Joerg Friedrich]

Steve Langasek schrieb am Dienstag, 14. Juni 2005 um 03:12:09 -0700:
> Consistent LFS support - Steve Langasek <[EMAIL PROTECTED]>

Short question: 
What does LFS mean? The first thing which comes into my mind is Linux
from Scratch. Seems not to fit in this context.



-- 
J�Friedrich

There are only 10 types of people:
Those who understand binary and those who don't.

Re: And now for something completely different... etch!

[Steve Langasek]

On Thu, Jun 16, 2005 at 01:01:17AM -0500, Gunnar Wolf wrote:
> Enrico Zini dijo [Thu, Jun 09, 2005 at 12:49:39PM +0200]:
> > I've been it_IT.UTF-8 for quite a while with no problems.  And I also
> > get to be able to write the name of my girlfriend, which Latin1 cannot
> > encode, together with accented Italian words, which BIG5 cannot encode.

> H... Silly me thought that Italian was the only Latin language
> which used no diacritics. Which kind of accents does it have?

acute and grave accented vowels.

-- 
Steve Langasek
postmodern programmer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Gunnar Wolf]

Enrico Zini dijo [Thu, Jun 09, 2005 at 12:49:39PM +0200]:
> I've been it_IT.UTF-8 for quite a while with no problems.  And I also
> get to be able to write the name of my girlfriend, which Latin1 cannot
> encode, together with accented Italian words, which BIG5 cannot encode.

H... Silly me thought that Italian was the only Latin language
which used no diacritics. Which kind of accents does it have?

(yes, OT and couple-of-days-late, I know)

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: And now for something completely different... etch!

[Gunnar Wolf]

Andrew Suffield dijo [Tue, Jun 07, 2005 at 02:32:53PM +0100]:
> > - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5
> 
> No way. Debian has always avoided mindlessly dictating what runlevels
> must be used for. There's no reason to destroy this feature now. And
> there's no advantage to consuming an entire runlevel just to say
> "/etc/init.d/xdm stop" or "/etc/init.d/networking stop", which is
> all that you are proposing.

We could provide default settings that lead to the LSB-specified
functionality that Javier suggests, but without falling in RedHat's
IMHO fucked up habit of starting [xwkg]dm not from an explicit script
(/etc/rc?.d/Sxx?dm), but directly from /etc/inittab, hiding it from
the user. If our display manager packages are set up to start only
from runlevel 4 or higher, but you and me can set them up to start on
any lower ones, we'll all be happy, won't we? Same thing for
networking.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: And now for something completely different... etch!

[Gunnar Wolf]

Joey Hess dijo [Wed, Jun 15, 2005 at 09:40:59PM -0400]:
> Gunnar Wolf wrote:
> > Ummm... And if instead of asking the user for a disk change, this
> > mini-initrd just keeps polling the floppy for a non-erroneous read
> > (this means, the drive is not empty) with the correct magic at the
> > correct place?
> 
> This assumes that the kernel works better than it really does. You'll
> get oopes on some machines, I can tell you from experience.

What can I do but long at the Amiga? ;-)

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: And now for something completely different... etch!

[Russell Coker]

regarding prelink

On Thursday 16 June 2005 08:18, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > One of the points of the md5sum verification is to ensure that the
> > binaries haven't been tampered with.  If one can tamper with the binaries
> > by modifying some file in /var/cache instead, doesn't that just
> > reintroduce the same problem?
>
> There are two basic reasons why people want md5sums of their binaries: to
> know when their filesystem is eating files, and as an extra layer of
> security to tell them their binaries have been modified by an intruder.  In
> the first instance, removing the cache and regenerating it would be
> sufficient to eliminate any corrupted files; in the second instance,
> removing the cache and regenerating it would be sufficient to eliminate any
> trojaned files (though, what a strange attack vector that would be :).

I think that the idea would be:

Prelink changes certain fixed parts of the binary, most of the file is never 
changed.  The parts that are changed would have their original values stored 
so that a checking tool can do a md5 or sha sum of the main part of the file 
plus the original values for the parts that prelink changes.  Changing the 
parts of the file which were changed by prelink such that the md5 or sha 
matches even after changing the body of the file would require cracking md5 
or sha - this may be possible but is still quite difficult.

But if someone can change the cache of data written by prelink then why 
couldn't they also change the program that does the md5 checks to make it 
always return a good result?

-- 
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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Joey Hess]

Gunnar Wolf wrote:
> Ummm... And if instead of asking the user for a disk change, this
> mini-initrd just keeps polling the floppy for a non-erroneous read
> (this means, the drive is not empty) with the correct magic at the
> correct place?

This assumes that the kernel works better than it really does. You'll
get oopes on some machines, I can tell you from experience.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Gunnar Wolf]

Goswin von Brederlow dijo [Sun, Jun 12, 2005 at 08:46:47AM +0200]:
> Intermittendly we had a multi floppy setup.
> 
> The first floppy contains the kernel and a minimal initrd. That
> prompts for the second floppy and the user to press return and then
> adds the contents of the 2nd floppy to tmpfs.
> 
> There was just one problem with it:
> The floppy was to small to include usb keyboard support.

Ummm... And if instead of asking the user for a disk change, this
mini-initrd just keeps polling the floppy for a non-erroneous read
(this means, the drive is not empty) with the correct magic at the
correct place?

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Steve Langasek]

On Wed, Jun 15, 2005 at 01:10:57PM -0700, Russ Allbery wrote:
> Ian Campbell <[EMAIL PROTECTED]> writes:

> > I might be talking out of my arse (99% probability ;-)) but I thought
> > I'd heard that it was possible to store the pre-linking information
> > separately to the binaries, under /var/cache or something for example.

> > Am/was I imagining things?

> One of the points of the md5sum verification is to ensure that the
> binaries haven't been tampered with.  If one can tamper with the binaries
> by modifying some file in /var/cache instead, doesn't that just
> reintroduce the same problem?

There are two basic reasons why people want md5sums of their binaries: to
know when their filesystem is eating files, and as an extra layer of
security to tell them their binaries have been modified by an intruder.  In
the first instance, removing the cache and regenerating it would be
sufficient to eliminate any corrupted files; in the second instance,
removing the cache and regenerating it would be sufficient to eliminate any
trojaned files (though, what a strange attack vector that would be :).

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Javier Fernandez-Sanguino]

[ Note: I was unsubscribe to -devel due to a hw problem in my current
mail-end so this quoting is suboptimal, had to use the web archives ]

Steve said:
>Ok, sure.  Here are a few one-liners about various things I'm aware of
>that one person or another wants to see happen in the etch timeframe,
>together with the name of the person who has claimed responsibility:
>

Added to my list (will resubmit it when the thread settles down).

>You seem to have a rather long wishlist of your own; are these all things
>that you personally plan to work on during the etch cycle?  If so, kudos!
>If not, which ones are you expecting to spend your time on, and which are
>you looking for help with?

I'm neither brilliant enough nor do I have enough spare time to work
on all of those. I pumped up the list for others to discuss and
(maybe) take over. I'm working or plan to work in:

- QA of base packages (did my share of NMUs to some already and I'm
  willing to do more, if the maintainers allow me to :)
- Security audits of core and extra packages
- Improvements of checksecurity and cron for sysadmins
- Documentation improvements (and better exposure of i18n docs)
- QA of Dummy and unmaintained packages

I would like maintainers to get involved in any and all the items of
the wishlist that they feel are worth working on. The discussion in
this thread highlights many things that people believe should be
improved on (even though there might be different POVs on some
issues). I'm sad to see some important (to me) features that
nobody else thinks are worth discussing about but if they are not done
it's no big deal.

> Javier said:
>> [ Release improvements ]
>> - Prune packages from release based on popularity, packages which are not
>>   used by anyone should not go in! (not enough peer review, probably
>>   not audited, bug ridden with bugs, including security making security
>>   handling a nightmare)
>
>It is, after all, quite difficult to determine that a package is not used by
>*anyone*.  You can use popcon to give you prospective candidates, but popcon
>doesn't prove the package is unused (and, well, a simple statement from the
>maintainer is counterevidence).
>
>That doesn't mean I think you're using the wrong metric; I'm just noting
>that the payoff for looking for unused packages tends to be very low
>:)

When doing automatic source code security auditing of some basic stuff
(/tmp races) early this year I've found an important correlation
between the popcon value and whether ASAT (my "Advanced Security Audit
Tool" (TM) [1]) had found a real security bug or it was just a false
positive. The lower the popcon value, the higher the chance of it
being a real security bug.

In any case, popcon is currently, IMHO, a better metric to detect low
quality stuff than bug counts since over-used packages (with,
consequently, have higher popularity values) attrack far more bugs
than packages that are only used by 1 person (its maintainer). Maybe
considering also the frequency of uploads to the archive or the time
of the last upload would help in detecting under-maintained stuff. I'll
let the QA team decide on that :-)

Regards

Javier


[1] Actually it was something like:
for each package in the distribution;
   unpack in {package_dir} 
 run find {package_dir} -xdev -type f 2>/dev/null |xargs grep -ir "/tmp" |
 grep -v ^/usr/share/doc 

:-)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Marco d'Itri]

On Jun 15, Olaf van der Spek <[EMAIL PROTECTED]> wrote:

> But it leaves the choice of using prelinking to the user instead of
> 'forcing' the entire system to use it.
There is no need to choose. If prelinking works, all users should use
prelinking.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Ian Campbell]

On Wed, 2005-06-15 at 13:10 -0700, Russ Allbery wrote:
> Ian Campbell <[EMAIL PROTECTED]> writes:
> 
> > I might be talking out of my arse (99% probability ;-)) but I thought
> > I'd heard that it was possible to store the pre-linking information
> > separately to the binaries, under /var/cache or something for example.
> 
> > Am/was I imagining things?
> 
> One of the points of the md5sum verification is to ensure that the
> binaries haven't been tampered with.  If one can tamper with the binaries
> by modifying some file in /var/cache instead, doesn't that just
> reintroduce the same problem?

I guess so, but then the prelinking tool could just store the md5 sums
of the prelink data files somewhere.

Ian.

-- 
Ian Campbell

I HAVE to buy a new "DODGE MISER" and two dozen JORDACHE JEANS because
my viewscreen is "USER-FRIENDLY"!!


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

Re: And now for something completely different... etch!

[Olaf van der Spek]

On 6/15/05, Russ Allbery <[EMAIL PROTECTED]> wrote:
> Ian Campbell <[EMAIL PROTECTED]> writes:
> 
> > I might be talking out of my arse (99% probability ;-)) but I thought
> > I'd heard that it was possible to store the pre-linking information
> > separately to the binaries, under /var/cache or something for example.
> 
> > Am/was I imagining things?
> 
> One of the points of the md5sum verification is to ensure that the
> binaries haven't been tampered with.  If one can tamper with the binaries
> by modifying some file in /var/cache instead, doesn't that just
> reintroduce the same problem?

But it leaves the choice of using prelinking to the user instead of
'forcing' the entire system to use it.

Re: And now for something completely different... etch!

[Russ Allbery]

Ian Campbell <[EMAIL PROTECTED]> writes:

> I might be talking out of my arse (99% probability ;-)) but I thought
> I'd heard that it was possible to store the pre-linking information
> separately to the binaries, under /var/cache or something for example.

> Am/was I imagining things?

One of the points of the md5sum verification is to ensure that the
binaries haven't been tampered with.  If one can tamper with the binaries
by modifying some file in /var/cache instead, doesn't that just
reintroduce the same problem?

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Olaf van der Spek]

On 6/15/05, Ian Campbell <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-06-15 at 12:45 +0200, Wouter Verhelst wrote:
> > > Using prelink invalidates the md5sums of files belonging to Debian 
> > > packages.
> > > Has anyone done any work to address this?
> >
> > The only way to address that is to update the md5sum after prelinking is
> > done.
> 
> I might be talking out of my arse (99% probability ;-)) but I thought
> I'd heard that it was possible to store the pre-linking information
> separately to the binaries, under /var/cache or something for example.
> 
> Am/was I imagining things?

I was thinking about that solution too. If it doesn't exist, we'll
just have to create it. :)

Re: And now for something completely different... etch!

[Ian Campbell]

On Wed, 2005-06-15 at 12:45 +0200, Wouter Verhelst wrote:
> > Using prelink invalidates the md5sums of files belonging to Debian packages.
> > Has anyone done any work to address this?
> 
> The only way to address that is to update the md5sum after prelinking is
> done.

I might be talking out of my arse (99% probability ;-)) but I thought
I'd heard that it was possible to store the pre-linking information
separately to the binaries, under /var/cache or something for example.

Am/was I imagining things?

Ian.
-- 
Ian Campbell
Current Noise: Slayer - Jesus Saves

Randal can write one-liners again.  Everyone is happy, and peace spreads
over the whole Earth.
 -- Larry Wall in <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Wouter Verhelst]

On Wed, Jun 15, 2005 at 02:09:49AM -0700, Steve Langasek wrote:
> On Wed, Jun 15, 2005 at 10:31:45AM +0200, Petter Reinholdtsen wrote:
> > I didn't see anyone proposing prelinking so far.  I've seen rumors
> > that program start time for some programs decrease a lot if prelinking
> > is enabled.  It would be nice if we could speed up the login time, or
> > for example the openoffice start time.  Is prelinking the way to go?
> > Should it be enabled by default?
> 
> Using prelink invalidates the md5sums of files belonging to Debian packages.
> Has anyone done any work to address this?

The only way to address that is to update the md5sum after prelinking is
done. However, doing that is rather problematic, as it would either
require a check of the md5sum before the prelinking phase, or result in
a binary where the md5sum isn't useful anymore (it might have been
compromised in the time between the installation of the package and the
last update of the md5sum).

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Kevin Mark]

On Tue, Jun 14, 2005 at 03:12:09AM -0700, Steve Langasek wrote:
> On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fernández-Sanguino Peña 
> wrote:
> > So, without further delay, here's my "Etch-wishlist", it's biased on some
> > of the things I've personally worked on and would like to keep working on
> > for etch. I would love to hear the Release Managers opinion on what they 
> > believe should be Release Goals for etch besides the things we all already 
> > know about (non-free documentation purged from main, changes in supported 
> > architectures...)
> 
> > Feel free to add some new items or add (hopefully new) information to the 
> > ones I list below:
> 
> Ok, sure.  Here are a few one-liners about various things I'm aware of
> that one person or another wants to see happen in the etch timeframe,
> together with the name of the person who has claimed responsibility:
> 
> Toolchain update to gcc/g++ 4.0 - Matthias Klose <[EMAIL PROTECTED]>
> Switch to dependency-based init.d handling --  Lars Wirzenius <[EMAIL 
> PROTECTED]>
> Drop libpng2/libpng10-0/libpng3 packages - Josselin Mouette <[EMAIL 
> PROTECTED]>
> Drop libmysqlclient10/libmysqlclient12 packages - Adam Conrad <[EMAIL 
> PROTECTED]>
> Consistent LFS support - Steve Langasek <[EMAIL PROTECTED]>
> Bend all library packages to my will - Steve Langasek <[EMAIL PROTECTED]>
> 
> You seem to have a rather long wishlist of your own; are these all things
> that you personally plan to work on during the etch cycle?  If so, kudos!
> If not, which ones are you expecting to spend your time on, and which are
> you looking for help with?
Hi Steve,
I was thinking of Bridge, at least the little I know about the game,
where you guess how many tricks(in this case tasks) you can get in the
game -- a contract I think.  Would it be cruel to make some such page of
'contracts' updated by each DD and have someone update the list of
completed tasks monthly. Since volunteers in Debian work on what floats
their boat, I'd be curious to see by release's end, who has lived up to
their own expectations of their contract. Any one for betting? Would
having a public airing of one's own goals be motivating or not?
just feeling in a devilish mood ;-)
Cheers,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Steve Langasek]

On Wed, Jun 15, 2005 at 10:31:45AM +0200, Petter Reinholdtsen wrote:
> I didn't see anyone proposing prelinking so far.  I've seen rumors
> that program start time for some programs decrease a lot if prelinking
> is enabled.  It would be nice if we could speed up the login time, or
> for example the openoffice start time.  Is prelinking the way to go?
> Should it be enabled by default?

Using prelink invalidates the md5sums of files belonging to Debian packages.
Has anyone done any work to address this?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Petter Reinholdtsen]

I didn't see anyone proposing prelinking so far.  I've seen rumors
that program start time for some programs decrease a lot if prelinking
is enabled.  It would be nice if we could speed up the login time, or
for example the openoffice start time.  Is prelinking the way to go?
Should it be enabled by default?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Gustavo Noronha Silva]

Em Dom, 2005-06-12 às 00:38 +0200, Frans Pop escreveu:
> IMO we should try very hard to keep floppy installation supported.

Everything depends on how much we're 'paying' for such a support. If the
overhead gets very hard to handle we better choose to drop some support
in order to keep ourselves sane.

You will allways have the option of bootstraping your system using an
older version of Debian, for example, and then upgrading to the version
you actually want to use.

We should not be exchanging our developers' sanity for somewhat rare
corner cases which you can work around in a somewhat easy way.

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



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

Re: And now for something completely different... etch!

[Rich Walker]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Tue, Jun 14, 2005 at 02:14:45PM -0300, Humberto Massa Guimarães wrote:
>
>> (1) LSB -- which Debian's policy vows to follow -- mandates the
>> default differentiated runlevels.
>
> No.  Please read
> .

Given that they *suggest* a set of runlevels, which provides "one spare for
local config", would it be out of order for users to file wishlist bugs
on packages not following these guidelines?

cheers, Rich.

-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Jesus Climent]

On Tue, Jun 14, 2005 at 11:47:38AM -0500, Manoj Srivastava wrote:
> On Mon, 13 Jun 2005 22:01:58 +0200, Jesus Climent <[EMAIL PROTECTED]> said: 
> 
> _Why_ did you not create you own run level schema, BTW, if you
>  have indeed needed them so often? (I haven't felt that itch yet, or I
>  would have; creating differentiated run levels is not exactly rocket
>  science). 

Because other did it for me. It is called LSB, and i think we should adhere to
it, while keeping the possibility of configuring your runlevels the way you
please.

The question is: why is the Debian default any better than the LSB one, if we
can keep the possibility of self-configuration?

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

You're just jealous because I'm a real freak and you have to wear a mask.
--Penguin (Batman Returns)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Steve Langasek]

On Tue, Jun 14, 2005 at 01:01:25PM -0500, Manoj Srivastava wrote:

> > (3) Substituting diferentiated runlevels by the old, 3-runlevel
> > scheme is relatively easy, as it is to create otherwise customized
> > runlevels, independently of where one comes from. So, why not?

> It is work, and most users seem to not care. The few that do,
>  often do not agree with each other about what a run level schema
>  oughty to look like.

There's pretty strong agreement, actually, that it should look like the one
used by Red Hat et al., which is clearly defined and has a long history...

> > IE, IMHO, Debian should adopt the 6-runlevel scheme dictated by the
> > LSB (0=off, 1=single, 2=multi,no-net, 3=multi, 4=5=multi+DM,
> > 6=reboot) because (1) it's praxis to the other distros, (2) it's in
> > the LSB and (3) there is no good reason not to.

>   Shrug. Talk to the people whoi do the work, then, or those
>  responsible for these packages.

So you would have the maintainers of the display manager packages implement
these changes unilaterally?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Steve Langasek]

On Tue, Jun 14, 2005 at 02:14:45PM -0300, Humberto Massa Guimarães wrote:
> Maybe I can shed some light on this

> ** Manoj Srivastava ::

> > > That common is common enough?

> > Not really. There is nothing to indicate that how you
> > fashioned your run levels would make sense for, say, me.
> > People whoi really want tailored run-levels often have
> > very definite ideas about how these run-levels would be
> > tailored; it is unlikely that a predefined solution
> > designed by committee in Debian would suit their needs,
> > and they would have to roll their own, anyway, and a
> > predefined solution would just get in their way.

> > _Why_ did you not create you own run level schema, BTW, if
> > you have indeed needed them so often? (I haven't felt that
> > itch yet, or I would have; creating differentiated run
> > levels is not exactly rocket science). 

> I think this all evades the real questions, that are:

> (1) LSB -- which Debian's policy vows to follow -- mandates the
> default differentiated runlevels.

No.  Please read
.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[John Hasler]

Adrian von Bidder writes:
> The people you probably mean when you write "admin" (with the quotes)
> usually, in my experience, go into blank-stare-mode when I mention the
> word 'runlevel' or even 'command line'.

There are many who have a primitive notion of what runlevels are and how to
use them but have no idea how to change them.  The advice to boot to
runlevel 3 to fix X is commonly seen even on debian-user.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mail clients and threading... (was: Re: And now for something completely different... etch!)

[Brian Nelson]

On Tue, Jun 14, 2005 at 08:06:07PM +0200, Adrian von Bidder wrote:
> On Tuesday 14 June 2005 19.14, Humberto Massa Guimarães wrote:
> [...]
> 
> Hmmm.  Is it just my kmail, or does your mailer produce strange (or no?) 
> In-Reply-To headers?  

It's not just you.

> All your posts I saw (and none others afaict) appeared to be in reply
> to some completely irrelevant other message in the same thread - it's
> extremely annoying to read your postings that way.

X-Mailer: Internet Mail Service (5.5.2653.19)

Idiotic MS junk, I believe...

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: And now for something completely different... etch!

[Humberto Massa Guimarães]

** Manoj Srivastava ::

> > (4) It *does* generate an unnecessary difference between Debian and
> > *all* *other* distros, with no reasonable motive at all.
> 
> We differ on what we considered reasonable.

But not *one* reasonable motive for differing was cited in this whole thread. 
So, right, we differ on what we consider reasonable, but why is differing in 
this point considered reasonable?
 
> 
> > IE, IMHO, Debian should adopt the 6-runlevel scheme dictated by the
> > LSB (0=off, 1=single, 2=multi,no-net, 3=multi, 4=5=multi+DM,
> > 6=reboot) because (1) it's praxis to the other distros, (2) it's in
> > the LSB and (3) there is no good reason not to.
> 
>   Shrug. Talk to the people whoi do the work, then, or those
>  responsible for these packages.

I assumed they would be on-list...

--
Massa


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

mail clients and threading... (was: Re: And now for something completely different... etch!)

[Adrian von Bidder]

On Tuesday 14 June 2005 19.14, Humberto Massa Guimarães wrote:
[...]

Hmmm.  Is it just my kmail, or does your mailer produce strange (or no?) 
In-Reply-To headers?  All your posts I saw (and none others afaict) 
appeared to be in reply to some completely irrelevant other message in the 
same thread - it's extremely annoying to read your postings that way.

cheers
-- vbi

-- 
Beware of the FUD - know your enemies. This week
* Patent Law, and how it is currently abused. *
http://fortytwo.ch/opinion


pgp0zUh6k4URu.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Manoj Srivastava]

On Tue, 14 Jun 2005 14:14:45 -0300, Humberto Massa Guimarães <[EMAIL 
PROTECTED]> said: 

> Maybe I can shed some light on this
> ** Manoj Srivastava ::

>> > That common is common enough?
>> 
>> Not really. There is nothing to indicate that how you fashioned
>> your run levels would make sense for, say, me.  People whoi really
>> want tailored run-levels often have very definite ideas about how
>> these run-levels would be tailored; it is unlikely that a
>> predefined solution designed by committee in Debian would suit
>> their needs, and they would have to roll their own, anyway, and a
>> predefined solution would just get in their way.
>> 
>> _Why_ did you not create you own run level schema, BTW, if you have
>> indeed needed them so often? (I haven't felt that itch yet, or I
>> would have; creating differentiated run levels is not exactly
>> rocket science).

> I think this all evades the real questions, that are:

> (1) LSB -- which Debian's policy vows to follow -- mandates the
> default differentiated runlevels. Why are not doing it?

The Debian technical policy does no such thing. Could yopu
 point to me the section that says otherwise, if you think I am wrong?
 Certainly, some Debian developers have expressed support for the LSB,
 and have put in work to ensure we comply where we can, but there is
 no mandated policy which is being ignored here.

> (2) The differentiated runlevels by default *do* have practical, and
> in many cases important, utilizations (the X-freezing is a good
> example). Why not?

There is nothing that states that there is a run level schema
 that would fit most users better than the one we have now. We have
 mechanisms to allow for starting, or not, of daemons at far fner
 granularity than a static, 3-more-diffrentiated-levels schemas that I
 have seen.

> (3) Substituting diferentiated runlevels by the old, 3-runlevel
> scheme is relatively easy, as it is to create otherwise customized
> runlevels, independently of where one comes from. So, why not?

It is work, and most users seem to not care. The few that do,
 often do not agree with each other about what a run level schema
 oughty to look like.

> (4) It *does* generate an unnecessary difference between Debian and
> *all* *other* distros, with no reasonable motive at all.

We differ on what we considered reasonable.

> IE, IMHO, Debian should adopt the 6-runlevel scheme dictated by the
> LSB (0=off, 1=single, 2=multi,no-net, 3=multi, 4=5=multi+DM,
> 6=reboot) because (1) it's praxis to the other distros, (2) it's in
> the LSB and (3) there is no good reason not to.

Shrug. Talk to the people whoi do the work, then, or those
 responsible for these packages.

manoj
-- 
To be or not to be, that is the bottom line.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Humberto Massa Guimarães]

Maybe I can shed some light on this

** Manoj Srivastava ::

> > That common is common enough?
> 
> Not really. There is nothing to indicate that how you
> fashioned your run levels would make sense for, say, me.
> People whoi really want tailored run-levels often have
> very definite ideas about how these run-levels would be
> tailored; it is unlikely that a predefined solution
> designed by committee in Debian would suit their needs,
> and they would have to roll their own, anyway, and a
> predefined solution would just get in their way.
> 
> _Why_ did you not create you own run level schema, BTW, if
> you have indeed needed them so often? (I haven't felt that
> itch yet, or I would have; creating differentiated run
> levels is not exactly rocket science). 

I think this all evades the real questions, that are:

(1) LSB -- which Debian's policy vows to follow -- mandates the
default differentiated runlevels. Why are not doing it?

(2) The differentiated runlevels by default *do* have practical, and
in many cases important, utilizations (the X-freezing is a good
example). Why not?

(3) Substituting diferentiated runlevels by the old, 3-runlevel
scheme is relatively easy, as it is to create otherwise customized
runlevels, independently of where one comes from. So, why not?

(4) It *does* generate an unnecessary difference between Debian and
*all* *other* distros, with no reasonable motive at all.

IE, IMHO, Debian should adopt the 6-runlevel scheme dictated by the
LSB (0=off, 1=single, 2=multi,no-net, 3=multi, 4=5=multi+DM,
6=reboot) because (1) it's praxis to the other distros, (2) it's in
the LSB and (3) there is no good reason not to.

--
HTH,
Massa


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Manoj Srivastava]

On Mon, 13 Jun 2005 22:01:58 +0200, Jesus Climent <[EMAIL PROTECTED]> said: 

> On Thu, Jun 09, 2005 at 09:25:22AM +1000, Matthew Palmer wrote:
>> On Thu, Jun 09, 2005 at 01:13:16AM +0200, Javier Fernández-Sanguino Peña 
>> wrote:
>> > to find their own (sometimes flawed) solution to a very common
>> > problem.
>> 
>> Years using Linux: 10.
>> 
>> Times I've absolutely needed an X-less boot when an XDM was
>> installed: 0.
>> 
>> How common was that problem you were trying to solve, again?

> Years using linux: 11 (argh, or 12, i cannot even remember)

> Times I needed the above discussed feature: several.

> That common is common enough?

Not really. There is nothing to indicate that how you
 fashioned your run levels would make sense for, say, me. People whoi
 really want tailored run-levels often have very definite ideas about
 how these run-levels would be tailored; it is unlikely that a
 predefined solution designed by committee in Debian would suit their
 needs, and they would have to roll their own, anyway, and a
 predefined solution would just get in their way.

_Why_ did you not create you own run level schema, BTW, if you
 have indeed needed them so often? (I haven't felt that itch yet, or I
 would have; creating differentiated run levels is not exactly rocket
 science). 

manoj
-- 
"The Schizophrenic: An Unauthorized Autobiography"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Adrian von Bidder]

On Monday 13 June 2005 23.00, John Hasler wrote:
> Jesus Climent writes:
> > Exactly my point, what impedes an admin to set some defaults wether the
> > system comes as it comes now or with some predefined options and
> > settings?
>
> Nothing, except for the fact that most "admins" haven't the foggiest idea
> how to do that.  Thus the suggestion that the default runlevels be what
> most people expect them to be.

The people you probably mean when you write "admin" (with the quotes) 
usually, in my experience, go into blank-stare-mode when I mention the word 
'runlevel' or even 'command line'.

I guess you can count me to the "the people who care will have their own 
ideas anyway, 90% of all others don't know anything and so wouldn't be able 
to take advantage of any special runlevel configuration" fraction.

cheers
-- vbi

-- 
Today is Setting Orange, the 19th day of Confusion in the YOLD 3171


pgp5HgMg0W1UA.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Bill Allombert]

On Tue, Jun 14, 2005 at 02:00:02PM +0200, Romain Francoise wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > Toolchain update to gcc/g++ 4.0 - Matthias Klose <[EMAIL PROTECTED]>
> > Switch to dependency-based init.d handling --  Lars Wirzenius <[EMAIL 
> > PROTECTED]>
> > Drop libpng2/libpng10-0/libpng3 packages - Josselin Mouette <[EMAIL 
> > PROTECTED]>
> > Drop libmysqlclient10/libmysqlclient12 packages - Adam Conrad <[EMAIL 
> > PROTECTED]>
> > Consistent LFS support - Steve Langasek <[EMAIL PROTECTED]>
> 
> libpcap0.9 transition - myself (more on that later)

Getting rid of circular dependencies - myself
Several menu transitions - myself

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Romain Francoise]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Toolchain update to gcc/g++ 4.0 - Matthias Klose <[EMAIL PROTECTED]>
> Switch to dependency-based init.d handling --  Lars Wirzenius <[EMAIL 
> PROTECTED]>
> Drop libpng2/libpng10-0/libpng3 packages - Josselin Mouette <[EMAIL 
> PROTECTED]>
> Drop libmysqlclient10/libmysqlclient12 packages - Adam Conrad <[EMAIL 
> PROTECTED]>
> Consistent LFS support - Steve Langasek <[EMAIL PROTECTED]>

libpcap0.9 transition - myself (more on that later)

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Steve Langasek]

On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fernández-Sanguino Peña wrote:
> So, without further delay, here's my "Etch-wishlist", it's biased on some
> of the things I've personally worked on and would like to keep working on
> for etch. I would love to hear the Release Managers opinion on what they 
> believe should be Release Goals for etch besides the things we all already 
> know about (non-free documentation purged from main, changes in supported 
> architectures...)

> Feel free to add some new items or add (hopefully new) information to the 
> ones I list below:

Ok, sure.  Here are a few one-liners about various things I'm aware of
that one person or another wants to see happen in the etch timeframe,
together with the name of the person who has claimed responsibility:

Toolchain update to gcc/g++ 4.0 - Matthias Klose <[EMAIL PROTECTED]>
Switch to dependency-based init.d handling --  Lars Wirzenius <[EMAIL 
PROTECTED]>
Drop libpng2/libpng10-0/libpng3 packages - Josselin Mouette <[EMAIL PROTECTED]>
Drop libmysqlclient10/libmysqlclient12 packages - Adam Conrad <[EMAIL 
PROTECTED]>
Consistent LFS support - Steve Langasek <[EMAIL PROTECTED]>
Bend all library packages to my will - Steve Langasek <[EMAIL PROTECTED]>

You seem to have a rather long wishlist of your own; are these all things
that you personally plan to work on during the etch cycle?  If so, kudos!
If not, which ones are you expecting to spend your time on, and which are
you looking for help with?

It would be nice to see more communication still from maintainers when
they're planning large transitions in unstable; for instance, GNOME 2.10
started being uploaded to unstable without anyone letting the release team
know it was coming, and I'm told there are a couple of places where this
might make the toolchain transition more complicated than it needed to be.

> [ Release improvements ] 
> - Prune packages from release based on popularity, packages which are not
>   used by anyone should not go in! (not enough peer review, probably
>   not audited, bug ridden with bugs, including security making security
>   handling a nightmare)

It is, after all, quite difficult to determine that a package is not used by
*anyone*.  You can use popcon to give you prospective candidates, but popcon
doesn't prove the package is unused (and, well, a simple statement from the
maintainer is counterevidence).

That doesn't mean I think you're using the wrong metric; I'm just noting
that the payoff for looking for unused packages tends to be very low :)

> - Remove _all_ out of date dummy packages! (see #308711 and other bugs!)

Ongoing area of work; Jeroen has bumped these bugs to 'serious' now, so they
ought to find themselves cleaned up fairly quickly, I think.

> - Better (not manual!) tracking of bugs associated with testing release

Which we get when version tracking is added to the BTS.

Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Jesus Climent]

On Mon, Jun 13, 2005 at 04:00:25PM -0500, John Hasler wrote:
> 
> Nothing, except for the fact that most "admins" haven't the foggiest idea
> how to do that.  Thus the suggestion that the default runlevels be what
> most people expect them to be.
> 
> And it _does_ come with "predefined options and settings": ones unique to
> Debian.

5 runlevels acting exactly the same way?

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

Bates Motel... 12 rooms, 12 vacancies.
--Norman Bates (Psycho)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Peter Samuelson]

[Darren Salt]
> ISTM that a non-standard disk format (21 sectors per track and/or
> more tracks) would help - or would this just cause too many problems?

I think it's safe to assume anyone can boot and read a 1600 kB floppy.
1743 kB is common but possibly problematic.


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Russell Coker]

On Tuesday 14 June 2005 02:32, Darren Salt <[EMAIL PROTECTED]> 
wrote:
> ISTM that a non-standard disk format (21 sectors per track and/or more
> tracks) would help - or would this just cause too many problems?

AFAIK it's not possible for the BIOS to boot from a 21 sector track.

I have heard of people formatting track 0 as 18 sectors and giving it the code 
needed to switch to 21 sector mode for the other tracks.  It's an ugly hack 
and difficult to produce.

For floppy disks to be widely usable we want them to be writable on random 
machines.  In the past I've used Windows, DOS, and OS/2 machines to write 
Linux disks.  A disk with different numbers of sectors on different tracks 
would probably only be writable on Linux.

21 sector track disks can be written on DOS and used to be writable on Windows 
(not sure how they work with NT).  Having an initial disk in 18 sector mode 
that then loads from 21 sector disks might be viable.

-- 
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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[John Hasler]

Jesus Climent writes:
> Exactly my point, what impedes an admin to set some defaults wether the
> system comes as it comes now or with some predefined options and
> settings?

Nothing, except for the fact that most "admins" haven't the foggiest idea
how to do that.  Thus the suggestion that the default runlevels be what
most people expect them to be.

And it _does_ come with "predefined options and settings": ones unique to
Debian.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Jesus Climent]

On Thu, Jun 09, 2005 at 01:18:39PM +0200, Josselin Mouette wrote:
> 
> How would these runlevels be "wasted"? We're only talking about the
> default configuration, not about something a system administrator
> couldn't change.

Exactly my point, what impedes an admin to set some defaults wether the system
comes as it comes now or with some predefined options and settings?

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

This is ridiculous. It's crazy. I feel like I'm babysitting, except I'm 
not getting paid.
--Stef (The Goonies)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Jesus Climent]

On Thu, Jun 09, 2005 at 09:25:22AM +1000, Matthew Palmer wrote:
> On Thu, Jun 09, 2005 at 01:13:16AM +0200, Javier Fernández-Sanguino Peña 
> wrote:
> > to find their own (sometimes flawed) solution to a very common problem. 
> 
> Years using Linux: 10.
> 
> Times I've absolutely needed an X-less boot when an XDM was installed: 0.
> 
> How common was that problem you were trying to solve, again?

Years using linux: 11 (argh, or 12, i cannot even remember)

Times I needed the above discussed feature: several.

That common is common enough?

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

Problem? I haven't got a problem. I've got fucking problems. Plural.
--Ted the Bellhop (Four Rooms)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Darren Salt]

I demand that Andreas Gredler may or may not have written...

> On Thu, Jun 09, 2005 at 07:58:11PM -0400, Joey Hess wrote:
[snip]
>> Since d-i currently puts the initrd that reads the second floppy (or
>> other USB media) on the boot floppy with the kernel, we either have to
>> shoehorn that initrd, which is currently 644k, onto the same floppy,
>> reducing its size by 414k somehow.

> I have to take a look at the initrd. 414k sounds much to me :-(

ISTM that a non-standard disk format (21 sectors per track and/or more
tracks) would help - or would this just cause too many problems?

[snip]
-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| sarge,| Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   Say NO to software patents

Academy: A modern school where football is taught.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Darren Salt]

I demand that Marco d'Itri may or may not have written...

> On Jun 12, Frans Pop <[EMAIL PROTECTED]> wrote:
>> I have a very nice Pentium I (my internet gateway) that has a broken
>> CD-drive and no USB (and certainly wouldn't boot from USB even if it had)
>> but that installs perfectly from floppy.

> You said it: it's *broken*.
> Expecting to support some old hardware is OK, expecting to support old and
> broken hardware is not.

In that case, replace the CD-ROM drive. ;-)

>> There are also other platforms that only do floppy boots (older macs,
>> probably m68k too).

> Looks like they should use floppy + netboot then.

An install on a Risc PC can be done without any removable installation media,
although it's possible that the newer or less common Ethernet cards aren't
supported.

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| sarge,| youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)

Oh my! Another kludge!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Brendan]

On Saturday 11 June 2005 08:34 am, David Weinehall wrote:
> 2.6.25?!  The current release pace for the 2.6-kernel is somewhere along
> 2-3 months / kernel.  The kernel version now is 2.6.11, but 2.6.12 is
> out any day now, hopefully.  Unless there are some radical changes,
> there won't be more than 6-8 new kernels released 18 months from now.
> So we're more looking at 2.6.20.

Yes, and how overdue was Sarge? I think it's laughable to say what "will" 
happen. 2.6.25 may be a conservative estimate.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Danny Cautaert]

On 2005-06-12, Goswin von Brederlow
<[EMAIL PROTECTED]> wrote:
> The best way to make multi floppy boot work would be to use initramfs
> with a static C binary linked against klibc that does the prompting
> and loading of the 2nd/3rd/... floppy. That way you can save as much
> space as possible for kernel and modules (or similar with initrd for
> 2.4.x).

I don't know anything about klibc, but I would like to add that you
don't necessarily need to link against any libc in order to prompt
and load more as long as you only use kernel syscalls. One good example
of this are the initrd's created by loop-aes's build-initrd.sh which
only use syscalls to mount another partition; it then uses a trick to
mount this second partition as /lib so you can have there a full glibc
and any other libraries, binaries and/or modules. This gives you a nice
2KiB initrd.

(Recent versions of build-initrd.sh link against dietlibc, but don't
initialize it, the reason for this is to allow parameter passing to
init, but it still delivers a nice small 2-3KiB initrd)

-- 
Greetings from Oostende (BE) -*- Danny Cautaert (DaCa) 
Write me in Dutch, French or English * GnuPG preferred
Meet me at LinuxTag * 22-25 June 2005 * Karlsruhe (DE)
 or at DebConf 5 * 10-17 July 2005 * Helsinki (FI)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Stephen Birch]

Steve Greenland([EMAIL PROTECTED])@2005-06-09 10:06:
> I suspect that the problem is that you're confusing "obsolete" with
> "not current". "Obsolete" caries the connotation of "useless except for
> entertainment/hobbiest purposes". For example, steam engine cars are
> obsolete. The 1999 Toyota Camry is not.

Of course, one should remember that obsolescence is subjective. Some
might argue that the 1999 Toyota Camry was obsolete at birth while a
steam engine car is still an attractive proposition :-)

Steve



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Goswin von Brederlow]

Andreas Gredler <[EMAIL PROTECTED]> writes:

> On Sun, Jun 12, 2005 at 02:17:08PM +1000, Russell Coker wrote:
>> On Sunday 12 June 2005 09:14, Frans Pop <[EMAIL PROTECTED]> wrote:
>> > Some older BIOSes don't allow booting from CD-ROM, let alone netbooting or
>> 
>> It's easy to solve the problem of a BIOS that doesn't support booting from 
>> CD-ROM.  You have a boot loader on a floppy disk that loads the kernel and 
>> initrd from CD.
>
> This is of course a good workaround. But this floppies have to be
> available. Does debian have such floppies?
>
>> People who have really old hardware should ask at their local LUG if someone 
>> has any unused computers that they don't need.  I've offered quite a few old 
>> computers for free to members of my LUG.  Recently I offered a P3-800 
>> machine 
>> with broken PSU and a Pentium 200 machine that was fully operational and 
>> found no-one who wanted them.  It seems that at my LUG there's no-one who 
>> has 
>> lesser hardware.
>
> I've seen a lot of servers for small companies, which are older ;-(
>
> greets Jimmy

The i386 CD images contain a floppy image of the smart boot manager
(sbm) that allows you to boot cdroms on hardware that doesn't.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Tollef Fog Heen]

* Andreas Gredler 

| - Network boot: PXE cards in older HW are as rare as motherboards
|   booting from USB, IMO.

A new PXE-capable networking card costs in the range of 20€ and should
work on most machines.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: And now for something completely different... etch!

[Andreas Gredler]

On Sun, Jun 12, 2005 at 12:52:58AM +0200, Marco d'Itri wrote:
> On Jun 12, Russell Coker <[EMAIL PROTECTED]> wrote:
> 
> > Why not use a USB flash device for booting?  All the recent machines I've 
> > tried have booted from a 64M USB device which gives plenty of space for 
> > such 
> > things.  Older machines would be restricted to booting from CD-ROM.
> Agreed. While it would take me some work to find a working blank floppy
> to copy something on, it would be much faster for me to boot from the
> network, USB flash drive or CD (in this order).

- Network boot: PXE cards in older HW are as rare as motherboards
  booting from USB, IMO.

- USB: Even my notebook (about 3 years old) is too stupid to boot from
  USB

- CD-ROM: Often had a problem with SCSI cards with old BIOS

But I agree, that it's hard to find working floppies and I'd be happy
when I'd could throw away all floppy disks and drives. But unfortunately
I sometimes really need them.

greets Jimmy

-- 
 Andreas "Jimmy" Gredler 
   ,'"`. http://www.g-tec.co.at/ | [EMAIL PROTECTED]
  (  grml.org -» Linux for texttool-users and sysadmins
   `._,  http://www.grml.org/| [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Andreas Gredler]

On Sun, Jun 12, 2005 at 02:17:08PM +1000, Russell Coker wrote:
> On Sunday 12 June 2005 09:14, Frans Pop <[EMAIL PROTECTED]> wrote:
> > Some older BIOSes don't allow booting from CD-ROM, let alone netbooting or
> 
> It's easy to solve the problem of a BIOS that doesn't support booting from 
> CD-ROM.  You have a boot loader on a floppy disk that loads the kernel and 
> initrd from CD.

This is of course a good workaround. But this floppies have to be
available. Does debian have such floppies?

> People who have really old hardware should ask at their local LUG if someone 
> has any unused computers that they don't need.  I've offered quite a few old 
> computers for free to members of my LUG.  Recently I offered a P3-800 machine 
> with broken PSU and a Pentium 200 machine that was fully operational and 
> found no-one who wanted them.  It seems that at my LUG there's no-one who has 
> lesser hardware.

I've seen a lot of servers for small companies, which are older ;-(

greets Jimmy

-- 
 Andreas "Jimmy" Gredler 
   ,'"`. http://www.g-tec.co.at/ | [EMAIL PROTECTED]
  (  grml.org -» Linux for texttool-users and sysadmins
   `._,  http://www.grml.org/| [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Russell Coker]

On Sunday 12 June 2005 19:54, Cesar Martinez Izquierdo <[EMAIL PROTECTED]> 
wrote:
> El Domingo 12 Junio 2005 01:24, Russell Coker escribió:
> > wrote:
> > > What about switching from getty to mingetty? Is there any reason to use
> > > getty by default?
> >
> > Is there any reason to change?
>
> Then I discovered mingetty, which claims to be "small, efficient". I also
> discovered that getty has some code to allow dial in our computer, which
> most of the people don't use nowadays and it makes getty more complex than
> required.

-rwxr-xr-x  1 root root 12904 Mar  3 00:13 /sbin/mingetty
-rwxr-xr-x  1 root root 14264 Mar 23 01:21 /sbin/getty

1360 bytes difference.  Also note that both file sizes are between 12K and 16K 
in size.  On a ReiserFS file system with tails enabled this may actually save 
some disk space.  On an ext2/3 file system it won't make any difference to 
disk space.  Memory is also allocated in 4K chunks so it's unlikely to make 
any difference to memory use.

> Then I switched to mingetty and I never had problems with it.
> I sold my old hardware before the bug in getty got fixed.
> Now it seems that the problem is fixed (according to DBTS), but anyway I
> think that it is not a bad idea to switch to the simpler, smaller program
> that just-do-the-work. I think that the users that need a different *getty
> program have very specific needs and they know how to swich form mingetty
> to *getty (and anyway maybe they don't use getty but mgetty).

The problem is that a change is likely to cause problems for some people.  
Without any clear benefit it's probably not worth the bother.

-- 
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

Re: And now for something completely different... etch!

[Cameron Patrick]

Eduard Bloch wrote:

> > Why would it have to be before the kernel? Actualy all floppies should
> 
> Because you can do it before the kernel needs to be running (including
> the whole userspace overhead needed to prompt the user to insert the usb
> floppy, for example, and work with it).

FWIW, the NetBSD bootloader supports something like this.  The default
install kernel comes to around 2.7mb.  The bootloader reads the kernel
and mfs image containing the installer off a couple of floppy discs
(which don't contain normal filesystems but instead some kind of
multi-volume tar archive for extra perversity).

Cameron.



signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Tollef Fog Heen]

* Brian May 

| klibc? Not yet in Debian, is there any reason for this?

It's just been ITP-ed;
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312563

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Why apt-get is not a proper software search engine (was Re: And now for something completely different... etch!)

[Peter Samuelson]

[Christian Aichinger]
> The reverse dependency count just isn't a very good metric for "is an
> end-user package". I think it's also a job for debtags or something
> like it, to tell us what is an end-user package and what isn't.

Or popularity-contest could be enhanced to note auto-installed
packages.  Now that aptitude is gaining traction (particularly in
command-line mode - I guess people have been using it in full-screen
mode for awhile), the aptitude auto-install flag probably actually
means something for a good % of popcon participants.

Come to think of it, that's a good wishlist bug for popcon anyway.


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Eduard Bloch]

Moin Goswin!
Goswin von Brederlow schrieb am Sonntag, den 12. Juni 2005:

> Why would it have to be before the kernel? Actualy all floppies should

Because you can do it before the kernel needs to be running (including
the whole userspace overhead needed to prompt the user to insert the usb
floppy, for example, and work with it).

> contain the bootloader and any order should work. Let the bootloader
> sort the chunks into the right place. The extra code needed for this
> is minimal.

Aha. Then do it, thank you.

Regards,
Eduard.

-- 
Delenn: We are star stuff. We are the universe made manifest trying to figure
itself out.
 -- Quotes from Babylon 5 --


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Cesar Martinez Izquierdo]

El Domingo 12 Junio 2005 01:24, Russell Coker escribió:
> On Tuesday 07 June 2005 19:31, Cesar Martinez Izquierdo
> <[EMAIL PROTECTED]>
>
> wrote:
> > What about switching from getty to mingetty? Is there any reason to use
> > getty by default?
>
> Is there any reason to change?

Well, I'm not very well informed about the subject, but some time ago I run in 
problems with getty freezing.
Then I discovered mingetty, which claims to be "small, efficient". I also 
discovered that getty has some code to allow dial in our computer, which most 
of the people don't use nowadays and it makes getty more complex than 
required.

Then I switched to mingetty and I never had problems with it.
I sold my old hardware before the bug in getty got fixed.
Now it seems that the problem is fixed (according to DBTS), but anyway I think 
that it is not a bad idea to switch to the simpler, smaller program that 
just-do-the-work. I think that the users that need a different *getty program 
have very specific needs and they know how to swich form mingetty to *getty 
(and anyway maybe they don't use getty but mgetty).

On the other hand, I see that the memory usage diferences between getty and 
mingetty are really small, so maybe the change is not worthy...

Regards,

  César

Re: And now for something completely different... etch!

[Goswin von Brederlow]

Eduard Bloch <[EMAIL PROTECTED]> writes:

> #include 
> * Joey Hess [Thu, Jun 09 2005, 07:58:11PM]:
>> Andreas Gredler wrote:
>> > Is there a way to handle this? Could a kernel be patched to read data
>> > from multiple floppy disks? I know that this question sounds a little
>> > bit stupid, but floppies still seem to be the most reliable way to boot.
>> 
>> [EMAIL PROTECTED]:/boot>ls -l vmlinuz-2.6.11-1-386
>> -rw-r--r--  1 root root 1170465 May 20 04:54 vmlinuz-2.6.11-1-386
> ...
>> Or we could make make some compromise, such as using the kernel initrd
>> loader to load the initrd from a second floppy, which might cause
>> problems for USB floppy installs (does the kernel initrd loader support
>> usb floppies?) and would break the floppy+usb stick install path. It
>> would also add yet another floppy to the install, probably.
>
> These problems (kernel too large, post-loading initrd from non-floppy
> media not reliable) has been existing even with b-fs three years ago.
> The best idea in those days came IIRC from Herbert, suggesting to modify
> the boot loader (syslinux) in order to preload the initrd while beeing
> in BIOS mode, having access to all devices it provides.
>
> It looks a bit unusual if the initrd is to be loaded before the kernel
> floppy, but it could work, IMO.
>
> Regards,
> Eduard.

Why would it have to be before the kernel? Actualy all floppies should
contain the bootloader and any order should work. Let the bootloader
sort the chunks into the right place. The extra code needed for this
is minimal.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Eduard Bloch]

#include 
* Joey Hess [Thu, Jun 09 2005, 07:58:11PM]:
> Andreas Gredler wrote:
> > Is there a way to handle this? Could a kernel be patched to read data
> > from multiple floppy disks? I know that this question sounds a little
> > bit stupid, but floppies still seem to be the most reliable way to boot.
> 
> [EMAIL PROTECTED]:/boot>ls -l vmlinuz-2.6.11-1-386
> -rw-r--r--  1 root root 1170465 May 20 04:54 vmlinuz-2.6.11-1-386
...
> Or we could make make some compromise, such as using the kernel initrd
> loader to load the initrd from a second floppy, which might cause
> problems for USB floppy installs (does the kernel initrd loader support
> usb floppies?) and would break the floppy+usb stick install path. It
> would also add yet another floppy to the install, probably.

These problems (kernel too large, post-loading initrd from non-floppy
media not reliable) has been existing even with b-fs three years ago.
The best idea in those days came IIRC from Herbert, suggesting to modify
the boot loader (syslinux) in order to preload the initrd while beeing
in BIOS mode, having access to all devices it provides.

It looks a bit unusual if the initrd is to be loaded before the kernel
floppy, but it could work, IMO.

Regards,
Eduard.



signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Goswin von Brederlow]

Andreas Gredler <[EMAIL PROTECTED]> writes:

> On Thu, Jun 09, 2005 at 07:58:11PM -0400, Joey Hess wrote:
>> Andreas Gredler wrote:
>> > Is there a way to handle this? Could a kernel be patched to read data
>> > from multiple floppy disks? I know that this question sounds a little
>> > bit stupid, but floppies still seem to be the most reliable way to boot.
>> 
>> [EMAIL PROTECTED]:/boot>ls -l vmlinuz-2.6.11-1-386
>> -rw-r--r--  1 root root 1170465 May 20 04:54 vmlinuz-2.6.11-1-386
>> 
>> Since d-i currently puts the initrd that reads the second floppy (or
>> other USB media) on the boot floppy with the kernel, we either have to
>> shoehorn that initrd, which is currently 644k, onto the same floppy,
>> reducing its size by 414k somehow. 
>
> I have to take a look at the initrd. 414k sounds much to me :-(

Intermittendly we had a multi floppy setup.

The first floppy contains the kernel and a minimal initrd. That
prompts for the second floppy and the user to press return and then
adds the contents of the 2nd floppy to tmpfs.

There was just one problem with it:
The floppy was to small to include usb keyboard support.


The best way to make multi floppy boot work would be to use initramfs
with a static C binary linked against klibc that does the prompting
and loading of the 2nd/3rd/... floppy. That way you can save as much
space as possible for kernel and modules (or similar with initrd for
2.4.x).

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Russell Coker]

On Sunday 12 June 2005 09:14, Frans Pop <[EMAIL PROTECTED]> wrote:
> Some older BIOSes don't allow booting from CD-ROM, let alone netbooting or

It's easy to solve the problem of a BIOS that doesn't support booting from 
CD-ROM.  You have a boot loader on a floppy disk that loads the kernel and 
initrd from CD.

> I hope not if it can be avoided with a little bit of extra effort. As long
> as the kernel supports it, we should try to allow people to install
> Debian on it. For me, it's one of the attractions of Open Source.

Supporting old kernels also takes time, not only from the people who maintain 
the kernels but from people who maintain applications that depend on kernel 
functionality.

People who have really old hardware should ask at their local LUG if someone 
has any unused computers that they don't need.  I've offered quite a few old 
computers for free to members of my LUG.  Recently I offered a P3-800 machine 
with broken PSU and a Pentium 200 machine that was fully operational and 
found no-one who wanted them.  It seems that at my LUG there's no-one who has 
lesser hardware.

-- 
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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Russell Coker]

On Sunday 12 June 2005 08:38, Frans Pop <[EMAIL PROTECTED]> wrote:
> On Sunday 12 June 2005 00:24, Russell Coker wrote:
> > New laptops tend to ship without floppy drives and desktop machines
> > will surely follow soon.  Plans for future hardware support should not
> > involve floppy disks.
>
> Please, we do not only support new hardware.
> I have a very nice Pentium I (my internet gateway) that has a broken
> CD-drive and no USB (and certainly wouldn't boot from USB even if it had)
> but that installs perfectly from floppy.

I have a couple of very nice Cobalt machines that have no option for booting 
from removable media.  I installed Debian on them by removing the hard disks 
and using a desktop machine to do the install.  The same method would work 
for broken hardware such as you possess.

> There are also other platforms that only do floppy boots (older macs,
> probably m68k too).

It seems that M68K Macs will be different from all other supported machines in 
every way.  There's no reason to upgrade the Debian install process on those 
machines.

> IMO we should try very hard to keep floppy installation supported.

There's nothing stopping someone who has ancient hardware from installing 
Woody or Sarge and then upgrading.  There's no reason for us not to require 
that the installer only support hardware that is <10 years old and fully 
functional.

Incidentally the going price for CD-ROM drives is $10 or less.

-- 
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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Joey Hess]

Brian May wrote:
> Yaird appears to be newer and better then mkinitrd

d-i images are not created with mkinitrd.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Brian May]

> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:

Joey> Since d-i currently puts the initrd that reads the second
Joey> floppy (or other USB media) on the boot floppy with the
Joey> kernel, we either have to shoehorn that initrd, which is
Joey> currently 644k, onto the same floppy, reducing its size by
Joey> 414k somehow.

I suggest having a look at
yaird. http://www.xs4all.nl/~ekonijn/yaird/yaird.html> Downloads
at http://www.xs4all.nl/~ekonijn/yaird/>

Yaird appears to be newer and better then mkinitrd, and may help lower
the size of the image. Also, it uses initramfs/cpio, supports both
Debian and Fedora, looks like it would be easy to customize, etc.

I am not sure it is appropriate to use yaird for d-i, I haven't
investigated this in depth. Even if it is not suitable out of the box,
I suspect it should be possible to customize it so that it is
suitable.

On my system (using standard libc6), there is a huge difference in
size:

[521] [snoopy:bam] ~ >ls -l /tmp/test.img /boot/initrd.img-2.6.8-2-k7
-rw-r--r--  1 root root 4648960 Jun  5 12:49 /boot/initrd.img-2.6.8-2-k7
-rw---  1 root root 1107666 Jun 12 09:00 /tmp/test.img

By default, only essential files (+jbd!!!) are copied (my system is
IDE RAID using ext3):

[520] [snoopy:bam] ~ >sudo zcat /tmp/test.img | cpio --list
.
bin
bin/cat
bin/dash
bin/mkdir
bin/mknod
bin/mount
bin/sleep
bin/umount
dev
dev/console
dev/null
etc
home
home/bam
home/bam/local
home/bam/local/lib
home/bam/local/lib/yaird
home/bam/local/lib/yaird/exec
home/bam/local/lib/yaird/exec/run_init
lib
lib/modules
lib/modules/2.6.8-2-k7
lib/modules/2.6.8-2-k7/kernel
lib/modules/2.6.8-2-k7/kernel/drivers
lib/modules/2.6.8-2-k7/kernel/drivers/ide
lib/modules/2.6.8-2-k7/kernel/drivers/ide/pci
lib/modules/2.6.8-2-k7/kernel/drivers/ide/pci/via82cxxx.ko
lib/modules/2.6.8-2-k7/kernel/drivers/ide/ide-core.ko
lib/modules/2.6.8-2-k7/kernel/drivers/ide/ide-disk.ko
lib/modules/2.6.8-2-k7/kernel/drivers/ide/ide-generic.ko
lib/modules/2.6.8-2-k7/kernel/drivers/md
lib/modules/2.6.8-2-k7/kernel/drivers/md/md.ko
lib/modules/2.6.8-2-k7/kernel/drivers/md/raid1.ko
lib/modules/2.6.8-2-k7/kernel/fs
lib/modules/2.6.8-2-k7/kernel/fs/ext3
lib/modules/2.6.8-2-k7/kernel/fs/ext3/ext3.ko
lib/modules/2.6.8-2-k7/kernel/fs/jbd
lib/modules/2.6.8-2-k7/kernel/fs/jbd/jbd.ko
lib/modules/2.6.8-2-k7/kernel/fs/mbcache.ko
lib/tls
lib/tls/libc-2.3.2.so
lib/tls/libm-2.3.2.so
lib/tls/libpthread-0.60.so
lib/tls/librt-2.3.2.so
lib/tls/libc.so.6
lib/tls/libm.so.6
lib/tls/libpthread.so.0
lib/tls/librt.so.1
lib/ld-2.3.2.so
lib/libblkid.so.1.0
lib/libuuid.so.1.2
lib/ld-linux.so.2
lib/libblkid.so.1
lib/libuuid.so.1
mnt
proc
sbin
sbin/insmod
sbin/mdadm
sys
var
init
4926 blocks

No doubt this would be even more with klibc.

The only downside I see is that it is still being developed, and
considered "incomplete" at the moment.

Also, it is not in Debian.

I have not yet tested i for booting.

Joey> uclibc is one possibility, but 409-some kilobytes of that
Joey> 644k are used for kernel modules and other stuff that uclibc
Joey> wouldn't effect (much); only 235k is used for libc
Joey> currently, and I fear those numbers don't add up to uclibc
Joey> making it small enough, unless uclibc occupys only 5k of the
Joey> compressed disk. Maybe other changes, like using initramfs
Joey> for that image, a little kernel hacking to remove a few
Joey> modules that are barely used (like ide-core which is on
Joey> there for only 1 symbol on 2.4; didn't check 2.6), and so on
Joey> might just make it work.

klibc? Not yet in Debian, is there any reason for this?
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Frans Pop]

On Sunday 12 June 2005 00:51, Marco d'Itri wrote:
> On Jun 12, Frans Pop <[EMAIL PROTECTED]> wrote:
> > I have a very nice Pentium I (my internet gateway) that has a broken
> > CD-drive and no USB (and certainly wouldn't boot from USB even if it
> > had) but that installs perfectly from floppy.
> You said it: it's *broken*.

Pardon my French, but that's bullshit. The system is perfectly fine. Since 
when is a CD drive an essential component. Since never!

> Expecting to support some old hardware is OK, expecting to support old
> and broken hardware is not.

Some older BIOSes don't allow booting from CD-ROM, let alone netbooting or 
booting from USB. Are we going to be like M$ and force users to buy the 
latest and greatest hardware to run Debian?

I hope not if it can be avoided with a little bit of extra effort. As long 
as the kernel supports it, we should try to allow people to install 
Debian on it. For me, it's one of the attractions of Open Source.


pgpciJI6k5JLo.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Marco d'Itri]

On Jun 12, Frans Pop <[EMAIL PROTECTED]> wrote:

> I have a very nice Pentium I (my internet gateway) that has a broken 
> CD-drive and no USB (and certainly wouldn't boot from USB even if it had) 
> but that installs perfectly from floppy.
You said it: it's *broken*.
Expecting to support some old hardware is OK, expecting to support old
and broken hardware is not.

> There are also other platforms that only do floppy boots (older macs, 
> probably m68k too).
Looks like they should use floppy + netboot then.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Marco d'Itri]

On Jun 12, Russell Coker <[EMAIL PROTECTED]> wrote:

> Why not use a USB flash device for booting?  All the recent machines I've 
> tried have booted from a 64M USB device which gives plenty of space for such 
> things.  Older machines would be restricted to booting from CD-ROM.
Agreed. While it would take me some work to find a working blank floppy
to copy something on, it would be much faster for me to boot from the
network, USB flash drive or CD (in this order).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Frans Pop]

On Sunday 12 June 2005 00:24, Russell Coker wrote:
> New laptops tend to ship without floppy drives and desktop machines
> will surely follow soon.  Plans for future hardware support should not
> involve floppy disks.

Please, we do not only support new hardware.
I have a very nice Pentium I (my internet gateway) that has a broken 
CD-drive and no USB (and certainly wouldn't boot from USB even if it had) 
but that installs perfectly from floppy.
There are also other platforms that only do floppy boots (older macs, 
probably m68k too).

IMO we should try very hard to keep floppy installation supported.


pgpEme5MM7QKV.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Russell Coker]

On Tuesday 07 June 2005 19:12, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 07, 2005 at 01:47:12AM +0200, Marco d'Itri wrote:
> > On Jun 07, Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote:
> > > - _No_ bugs in base packages (well, at least no old bugs). Base system
> > >   should be upgraded to latest upstream (forward patches!) this
> > > includes PAM, modutils...
> >
> > In my wishlist there is NO support of 2.4 kernels, so modutils would
> > become unneeded.
> > 2.4.x kernels are already obsolete by now except that for some doorstop
> > architectures, I do not know about any other modern distribution which
> > still installs one.
>
> Since (at least) potato, Debian has always supported more than one major
> line of kernels. I don't see why we suddenly would need to change that
> now.

For architectures that require older kernels we can keep them.  But for i386 
and other platforms that work well on 2.6.x we should not support older 
kernels.

Some features that are planned for Etch such as SE Linux require a 2.6.x 
kernel.

-- 
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

Re: And now for something completely different... etch!

[Russell Coker]

On Tuesday 07 June 2005 19:31, Cesar Martinez Izquierdo <[EMAIL PROTECTED]> 
wrote:
> What about switching from getty to mingetty? Is there any reason to use
> getty by default?

Is there any reason to change?

-- 
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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Russell Coker]

On Friday 10 June 2005 09:58, Joey Hess <[EMAIL PROTECTED]> wrote:
> Since d-i currently puts the initrd that reads the second floppy (or
> other USB media) on the boot floppy with the kernel, we either have to
> shoehorn that initrd, which is currently 644k, onto the same floppy,
> reducing its size by 414k somehow.

Why not use a USB flash device for booting?  All the recent machines I've 
tried have booted from a 64M USB device which gives plenty of space for such 
things.  Older machines would be restricted to booting from CD-ROM.

A combination of USB flash storage for the rare new machines that don't have 
CD/DVD drives and CD-ROM for older machines will cater for the vast majority 
of machines that are out there.

New laptops tend to ship without floppy drives and desktop machines will 
surely follow soon.  Plans for future hardware support should not involve 
floppy disks.

-- 
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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Martin Zobel-Helas]

Hi,

On Tuesday, 07 Jun 2005, you wrote:
> Feel free to add some new items or add (hopefully new) information to the 
> ones I list below:
> 

- A lot of programms use tcpwrapper which I appreciate a lot. However,
  it is quite often not too easy to find out what to write in
  hosts.allow to allow access to exactly that program. Frankly speaking,
  having that information always in the manpage seems a good idea to me.
  (i would like to see that as recommondation for packages in etch)

- IPv6 Readyness
  packages in etch should be able to handle IPv6.
  There are still a bunch of packages which are not able to handle IPv6.

- packages in base or packages up to priority standard must not use savelog.
  There is at least one package in base i know off which uses savelog to
  rotate logfiles. Using logrotate is a more save way, as it gives the
  user the possibility to configure more easyly when logfiles are
  rotated. I would like to see 5(j) of etch release-policy adjusted or
  best, to say, all packages must use logrotate.

Greetings
Martin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Andreas Gredler]

On Thu, Jun 09, 2005 at 07:58:11PM -0400, Joey Hess wrote:
> Andreas Gredler wrote:
> > Is there a way to handle this? Could a kernel be patched to read data
> > from multiple floppy disks? I know that this question sounds a little
> > bit stupid, but floppies still seem to be the most reliable way to boot.
> 
> [EMAIL PROTECTED]:/boot>ls -l vmlinuz-2.6.11-1-386
> -rw-r--r--  1 root root 1170465 May 20 04:54 vmlinuz-2.6.11-1-386
> 
> Since d-i currently puts the initrd that reads the second floppy (or
> other USB media) on the boot floppy with the kernel, we either have to
> shoehorn that initrd, which is currently 644k, onto the same floppy,
> reducing its size by 414k somehow. 

I have to take a look at the initrd. 414k sounds much to me :-(

> uclibc is one possibility, but 409-some kilobytes of that 644k are used
> for kernel modules and other stuff that uclibc wouldn't effect (much);
> only 235k is used for libc currently, and I fear those numbers don't add
> up to uclibc making it small enough, unless uclibc occupys only 5k of
> the compressed disk. Maybe other changes, like using initramfs for that
> image, a little kernel hacking to remove a few modules that are barely
> used (like ide-core which is on there for only 1 symbol on 2.4; didn't
> check 2.6), and so on might just make it work.

Removing kernel modules might work for 2.6 but I'm afraid that the
kernel will still grow and we will sometimes end up with a kernel, which
will never fit on a floppy disk again. But maybe I'm too pessimistic ;-)
(But maybe there won't be any motherboards left,  that aren't able to boot
from USB)

> Or we could make make some compromise, such as using the kernel initrd
> loader to load the initrd from a second floppy, which might cause
> problems for USB floppy installs (does the kernel initrd loader support
> usb floppies?) and would break the floppy+usb stick install path. It
> would also add yet another floppy to the install, probably.

I think one more floppy would be ok, if initrd loader is able to load
the initrd from usb floppies or anything else.
IMO the first boot media is always the most problematic one. Maybe I
can't boot from USB, but I can boot from floppy and then read data (like
initrd) from a usb-device.

greets Jimmy

-- 
 Andreas "Jimmy" Gredler 
   ,'"`. http://www.g-tec.co.at/ | [EMAIL PROTECTED]
  (  grml.org -» Linux for texttool-users and sysadmins
   `._,  http://www.grml.org/| [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[David Weinehall]

On Fri, Jun 10, 2005 at 12:20:14AM +0200, Giuseppe Sacco wrote:
> Il giorno gio, 09-06-2005 alle 19:06 +0200, Frans Pop ha scritto:
> > On Thursday 09 June 2005 18:45, Marco d'Itri wrote:
> > > On Jun 09, Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> > > > Dropping 2.4 can easily be done on relatively short notice prior to
> > > > etch release, so no need to worry about now.
> > >
> > > It would be too late, because at that time we would have wasted a
> > > couple of years trying to support them.
> > > This kind of decision should be taken early in the development cycle.
> > 
> > Making the decision early would also help d-i development as we could then 
> > start cleaning e.g. keyboard selection (and console-data).
> > Being able to rely on sysfs being present would also simplify hardware 
> > detection in some cases.
> 
> Right, this would really simplify d-i development. My personal opinion
> is that 2.6.8 isn't enought mature to be used on server installation
> with multidisk, lvm and XFS.
> But, when Etch will be released, we will probably have 2.6.25 or such
> available. I think, in this case, 2.6 could really be offered as a
> complete replacement for 2.4.

2.6.25?!  The current release pace for the 2.6-kernel is somewhere along
2-3 months / kernel.  The kernel version now is 2.6.11, but 2.6.12 is
out any day now, hopefully.  Unless there are some radical changes,
there won't be more than 6-8 new kernels released 18 months from now.
So we're more looking at 2.6.20.

I totally agree about goes 2.6.xx full out, however.  2.6.11 is already
pretty stable, 2.6.12 promise to be even more so.


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Marco d'Itri]

On Jun 11, Brian May <[EMAIL PROTECTED]> wrote:

> Not all packages use/support this.
Then they should be fixed.
Udev has good reasons to work differently, and the chroot case was
fixed a long time ago.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Brian May]

> "Grzegorz" == Grzegorz B Prokopski <[EMAIL PROTECTED]> writes:

Grzegorz> On Tue, 2005-07-06 at 01:03 +0200, Javier
Grzegorz> Fernández-Sanguino Peña wrote:
>> [ Installation improvements ] - Firewall configuration during
>> installation (ala Fedora Core or SuSE): module for
>> d-i. Currently, the system is exposed just during installation
>> on some systems (empty root password?)

Grzegorz> Right.  Especially for workstation installation
Grzegorz> something like below would allow to connect from
Grzegorz> workstation to anywhere else, but not to any servers ran
Grzegorz> on workstation.

I would suggest shorewall with a very simple default configuration.

IMHO, shorewall seems to be easy to use and configure, and can be used
in very simple single computer setups to very complicated networks.

The difficulty with supporting firewalls is that people will expect
"if I install package X, then it should automatically adjust the
firewall to allow it to work". I really do *not* want to go down this
path.

The firewall is up to the administrator to decide on, not the package
maintainers.
-- 
Brian May <[EMAIL PROTECTED]>

Re: And now for something completely different... etch!

[Brian May]

> "Matthew" == Matthew Palmer <[EMAIL PROTECTED]> writes:

>> Add to the list of daemon related features the "not start
>> daemons by default" and wait for the admin to define which ones
>> to start from /etc/defaults or whatever.

Matthew> Jesus, meet policy-rc.d.

Not all packages use/support this.

Most recent example I have personally identified is udev (when
creating a Debian system using a script in a chroot, the script
couldn't unmount the partition when it was finished, because udev was
running and had mounted additional filesystems - the only solution I
could come up with was to stop the daemon in the chroot before
unmounting the file-system).
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Adrian von Bidder <[EMAIL PROTECTED]> writes:

> On Tuesday 07 June 2005 23.32, Roger Leigh wrote:
>> Frans Pop <[EMAIL PROTECTED]> writes:
>> > On Tuesday 07 June 2005 23:02, Roger Leigh wrote:
>> >> Existing installs are already configured with debconf.  Their
>> >> /etc/locale.gen will not be touched.
>> >>
>> >> If you do dpkg-reconfigure locales, then users could have the locale
>> >> switch to UTF-8 if they so choose.
>> >
>> > AFAIK locales are automatically regenerated when the locales package is
>> > upgraded, so this _would_ effect every existing install directly on
>> > upgrade to the new release.
>>
>> locale-gen is run, but /etc/locale.gen is not necessarily altered.  If
>> you don't change it, it will regenerate the same locales you already
>> have.
>
> But 'the same locale I already have' would probably mean 'the locale with 
> the name of the locale I previously had' which has now suddenly changed its 
> behaviour.

This would be safe, since the locale codeset is part of the name.
When the current locale selections are merged with i18n/SUPPORTED, it
wouldn't change anything behind your back.  But this is probably the
wrong approach, as others have said.


I've since made a patch, and filed this as bug #312927.  I'd
appreciate any comments.  It's a trivial and (I hope!)
non-controversial change.  It certainly won't affect the choices of or
the behaviour of the available locales; it rather just recommends that
UTF-8 locales be used unless the user has a good reason not to.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCqgNnVcFcaSW/uEgRAjXFAKCL4YoHDw9OI4mhs/LnQ9pjZK0ucACbB4Ch
vFjugEqBcVCNMlTVoMRV4cU=
=usOo
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Rich Walker]

Darren Salt <[EMAIL PROTECTED]> writes:

> I demand that Rich Walker may or may not have written...
>
>> Matthew Palmer <[EMAIL PROTECTED]> writes:
>>> How common was that problem you were trying to solve, again?
>
>> Presumably, you never used an S3 video card.
>
>> (Locks up on leaving X in many card/X permutations).
>
> IME (one S3 ViRGE), that's VESA driver territory. (No lockup problems, though
> - at least, not that I recall...)

Specifically, it was using Xserver-s3v rather than X 4.

If you left X, the machine became un-usable: I recall having to connect
over the network to shut it down, and having to document how to do that
for the customer.

I know; I should have used a different card: but there were deadlines
involved...

cheers, Rich.

-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Josselin Mouette]

Le jeudi 09 juin 2005 à 18:03 +0200, Wouter Verhelst a écrit :
> > How would these runlevels be "wasted"? We're only talking about the
> > default configuration, not about something a system administrator
> > couldn't change.
> 
> In theory.
> 
> In practice, many third-party applications will make assumptions about
> the availability and configuration of runlevels, and will break horribly
> if anything is different from what they expect; this has happened on
> those RedHat systems that I've tried this on.

If they already exist, they're likely to check for a Debian system, and
to make Debian-specific assumptions about the runlevel configuration, so
the problem is the same.

Furthermore, I don't think basing our decisions on what broken,
third-party software can do is a good idea.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: And now for something completely different... etch!

[Joey Hess]

Andreas Gredler wrote:
> Is there a way to handle this? Could a kernel be patched to read data
> from multiple floppy disks? I know that this question sounds a little
> bit stupid, but floppies still seem to be the most reliable way to boot.

[EMAIL PROTECTED]:/boot>ls -l vmlinuz-2.6.11-1-386
-rw-r--r--  1 root root 1170465 May 20 04:54 vmlinuz-2.6.11-1-386

Since d-i currently puts the initrd that reads the second floppy (or
other USB media) on the boot floppy with the kernel, we either have to
shoehorn that initrd, which is currently 644k, onto the same floppy,
reducing its size by 414k somehow. 

uclibc is one possibility, but 409-some kilobytes of that 644k are used
for kernel modules and other stuff that uclibc wouldn't effect (much);
only 235k is used for libc currently, and I fear those numbers don't add
up to uclibc making it small enough, unless uclibc occupys only 5k of
the compressed disk. Maybe other changes, like using initramfs for that
image, a little kernel hacking to remove a few modules that are barely
used (like ide-core which is on there for only 1 symbol on 2.4; didn't
check 2.6), and so on might just make it work.

Or we could make make some compromise, such as using the kernel initrd
loader to load the initrd from a second floppy, which might cause
problems for USB floppy installs (does the kernel initrd loader support
usb floppies?) and would break the floppy+usb stick install path. It
would also add yet another floppy to the install, probably.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Andreas Gredler]

On Thu, Jun 09, 2005 at 02:24:12PM -0400, Joey Hess wrote:
> Adrian von Bidder wrote:
> > Dropping 2.4 can easily be done on relatively short notice prior to etch 
> > release, so no need to worry about now.
> 
> Relatively short notice of several months, even ignoring problems we
> currently can't solve such as 2.6 not fitting on floppies for the
> installer, at least.

Is there a way to handle this? Could a kernel be patched to read data
from multiple floppy disks? I know that this question sounds a little
bit stupid, but floppies still seem to be the most reliable way to boot.

greets Jimmy

-- 
 Andreas "Jimmy" Gredler 
   ,'"`. http://www.g-tec.co.at/ | [EMAIL PROTECTED]
  (  grml.org -» Linux for texttool-users and sysadmins
   `._,  http://www.grml.org/| [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Giuseppe Sacco]

Il giorno gio, 09-06-2005 alle 19:06 +0200, Frans Pop ha scritto:
> On Thursday 09 June 2005 18:45, Marco d'Itri wrote:
> > On Jun 09, Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> > > Dropping 2.4 can easily be done on relatively short notice prior to
> > > etch release, so no need to worry about now.
> >
> > It would be too late, because at that time we would have wasted a
> > couple of years trying to support them.
> > This kind of decision should be taken early in the development cycle.
> 
> Making the decision early would also help d-i development as we could then 
> start cleaning e.g. keyboard selection (and console-data).
> Being able to rely on sysfs being present would also simplify hardware 
> detection in some cases.

Right, this would really simplify d-i development. My personal opinion
is that 2.6.8 isn't enought mature to be used on server installation
with multidisk, lvm and XFS.
But, when Etch will be released, we will probably have 2.6.25 or such
available. I think, in this case, 2.6 could really be offered as a
complete replacement for 2.4.

Giuseppe


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: And now for something completely different... etch!

[Otavio Salvador]

> "humberto" == Humberto Massa Guimarães <[EMAIL PROTECTED]> writes:

humberto> * John Hasler ::
>> Wouter Verhelst writes: > In practice, many third-party
>> applications will make assumptions > about the availability and
>> configuration of runlevels...
>> 
>> Seems to me that the most likely such assumption is that the
>> runlevels are Red Hat-like.

humberto> IOW, the most likely assumption is that the runlevels
humberto> follow the LSB

I agree with you.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Re: And now for something completely different... etch!

[Marco d'Itri]

On Jun 09, Joey Hess <[EMAIL PROTECTED]> wrote:

> I agree, and it seems they have the maintainers interested in
> maintaining 2.4.
The main issue is not maintaining kernel images, but supporting them
in other packages.

-- 
ciao,
Marco


signature.asc
Description: Digital signature