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

[Miles Bader]

Will Newton <[EMAIL PROTECTED]> writes:
>> > Would you please contribute your suggestions (either improve bits at that
>> > page or somewhere else) of how to improve things. Thanks.
>>
>> What makes you think I have any?
>
> A lack of familiarity with your posts?

Not fair; asuffield is often needlessly inflammatory, but he's posted
plenty of useful and insightful stuff.

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff


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

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

[Miles Bader]

"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> But the problem is that for this to work this way, you have to support
> downgrades. With a more complex scheme supporting redowngrades (i.e.
> upgrading and downgrading again when no user-made changes were done)
> would be needed.
> This has to be supported on a per package level in order to work. Many
> packages are boring enough a normal downgrade will work, but there are
> enough cases like databases to be converted to a new format or even
> only some reodering of some symlinks, that are not trivially revertable.

I always assumed that if downgrading didn't work, it was a bug; is this
not true?

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!


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

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

[Don Armstrong]

On Tue, 07 Jun 2005, Olaf van der Spek wrote:
> Petri Latvala wrote:
> >1) divert the other? what's the use of another package version then
> 
> That depends on system-wide vs per-user vs per-environment.

If you want something done per-user/per-environment, you can always
use dpkg-deb -x foo.deb .; or whatever to unpack the version you want
to run manually.

Alternatively, you can have a chroot with the strange versions that
you want.

Having multiple versions system wide when you haven't explicitly
planned for multple versions is just asking for madness. It's
especially insane when there are already reasonable methods for having
multiple versions of things installed when that is a reasonable thing
to do. (Think libfoo2, autoconf2.13 or similar.)
 

Don Armstrong

-- 
"For those who understand, no explanation is necessary.
 For those who do not, none is possible."

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

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

[David Starner]

"Thaddeus H. Black" writes:
> We are going to support Unicode because we have
> no practical alternative.  However, Unicode is a bad
> standard.  It is highly overwrought.  Its philosophy is
> wrong.  Its use complicates many things which do not
> need complication. 

Lots of accusations but no backup.

> Insofar as it contaminates clean
> ascii in Debian source code and English-language
> documentation, it is not a good thing.

It doesn't change anything in source code; source code is still
ASCII. As for documentation, it's no different from any other 
English language document. ASCII does not suffice for good 
English, which has angled quotes and different lengths of dashes, 
which was recognized by TeX, for a old school computer example.

> However, past character-set discussions on debian-devel
> have also established how maddening it is to see a '-'
> in a man page, unsearchable because it is not really a
> '-';

The simple fact is, there is a variety of dashes used in proper 
English printing, and any universal character set is going to 
have to deal with that. You can turn off this feature in man with 
a one line change in a config file, and Debian could make it the 
default; or programs that let you search text could merge
the various dashes at the same time they're merging cases.

> Unicode vastly complicates or altogether breaks rational
> assumptions about how a simple printf() will display on
> the terminal.

Assuming that bytes and columns are equivalent is irrational.
It is impossible to satisfy, given that there are thousands of 
characters that historically have fit in one column or logically
should.

> If I lose the easy ability to make a
> column of ':' line neatly up in column 25 of the
> terminal,

It's called wcwidth.

> while gaining the ability to display Nepalese
> subjoined circumflexes and the International Phonetic
> Alphabet bidirectionally, this is probably not a win for
> me.

One system that supports everyone is a win for Debian
and the rest of the world.

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

[Alban Browaeys]

Le Tue, 07 Jun 2005 23:20:37 +0100, Colin Watson a écrit :

> en_GB.ISO-8859-1 doesn't exist unless you go to the effort of defining
> it yourself - it's not in /usr/share/i18n/SUPPORTED. (Yes, in this case
> there happens to be an ISO-8859-15 equivalent, but that's not the case
> everywhere.)


ahem ... /etc/locale.alias /etc/locale.gen
and /usr/X11R6/lib/X11/locale/locale.alias ...

legacy names includes the charset whatever it is ...

Well it does not help with ssh :-/

Regards
Alban




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

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

[Benjamin Mesing]

On Tue, 2005-06-07 at 19:30 +0300, Meelis Roos wrote:
> JFSP> - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 
> 4=5
> 
> Why? Display manager as a normal service that can be started and stopped
> like other services is very natural. No need to confuse the users with
> more runlevels since there's not much point in differentiating them
> nowadays.
Two points come to my mind.
 1. in case your X-Config is broken booting in runlevel 3 offers a
nice way to fix this
 2. it is defined in the LSB

Greetings Ben


-- 
Please do not sent any email to the [EMAIL PROTECTED] - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.


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

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

[Bob Proulx]

Benjamin Mesing wrote:
> Meelis Roos wrote:
> > JFSP> - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 
> > 4=5
> > 
> > Why? Display manager as a normal service that can be started and stopped
> > like other services is very natural. No need to confuse the users with
> > more runlevels since there's not much point in differentiating them
> > nowadays.
> Two points come to my mind.
>  1. in case your X-Config is broken booting in runlevel 3 offers a
> nice way to fix this

How will switching to run level 3 fix this problem?  Your X config is
still broken.

If your X configuration is broken and your X won't start then that is
effectively the same thing as the proposed run level 3 anyway.  So
what is the point?

>  2. it is defined in the LSB

Can't argue with that.

Bob


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

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

[Ian Campbell]

On Wed, 2005-06-08 at 07:54 +0200, Benjamin Mesing wrote:
> On Tue, 2005-06-07 at 19:30 +0300, Meelis Roos wrote:
> > JFSP> - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 
> > 4=5
> > 
> > Why? Display manager as a normal service that can be started and stopped
> > like other services is very natural. No need to confuse the users with
> > more runlevels since there's not much point in differentiating them
> > nowadays.
> Two points come to my mind.
>  1. in case your X-Config is broken booting in runlevel 3 offers a
> nice way to fix this

Debian already has a nice way to fix this -- if X doesn't start it tries
a couple of times and then disables itself and offers to show you the
log or drop you to a login prompt.

I don't know if this functionality is from the X packages or from gdm
etc. but it is a much better solution than the band aid offered by
run-levels...

Ian.
-- 
Ian Campbell

Ignorance is when you don't know anything and somebody finds it out.


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

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

[Tollef Fog Heen]

* Miles Bader 

| I always assumed that if downgrading didn't work, it was a bug; is this
| not true?

Downgrades are not and have not been supported.

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

[Marco d'Itri]

On Jun 07, Roger Leigh <[EMAIL PROTECTED]> wrote:

> - - The locale codeset should be UTF-8 for all new installs by default.
FFS! When will people learn to not mess with other cultures they know
nothing about?
Feel free to advocate a different default charset for *your* locale, but
do not pretend to know what's better for other locales.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Jesus Climent]

On Tue, Jun 07, 2005 at 01:28:13PM +0200, Marco d'Itri wrote:
>
> 2.4 kernels are obsolete *now*, are not getting many new drivers and
> the lack of sysfs and other features make some packages much more
> complex than they should be.

That does not make them obsolete. They are in maintenance mode, with security
updates being applied.

>From your definition of obsolete, Woody was obsolete for a very long time, and
yet it was updated with security fixes, which made it usable for many people.

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

Wait Master, it might be dangerous... you go first.
--Igor (Young Frankenstein)


-- 
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 Mon, Jun 06, 2005 at 09:21:37PM -0400, Joey Hess wrote:
> This solves your problem fairly well, since the issue then becomes only
> keeping d-i secure and keeping the installed system secure, not keeping
> the system secure while it's installing itself. Daemons will not be
> started dueing the installation, and will come up on reboot.

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.

I do _not_ want a web server right after apt-get installing it, since
everybody has to move the default page and create their own content.

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

It's a soldier's duty. You wouldn't understand.
--The Colonel (Akira)


-- 
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 07, 2005 at 02:32:53PM +0100, Andrew Suffield wrote:
> On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fern?ndez-Sanguino Pe?a 
> wrote:
> > - inetd begone! -> xinetd (better mechanism to control DoS, privilege
> >   separation, etc.)
> 
> xinetd begone. There is no justification for using anything resembling
> inetd on a modern system.

Easy setting of a stunnel?

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

Still, better have init 2 than having to hack the boot command line to set
init=/bin/bash, having to remount in rw and editing whatever you fucked up,
before all the services go up and people start login into your server.

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

Where are you going, Starfish and Friends?
--Chad (Charlie's Angels)


-- 
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 08, Jesus Climent <[EMAIL PROTECTED]> wrote:

> I do _not_ want a web server right after apt-get installing it, since
> everybody has to move the default page and create their own content.
_I_ do.
If I install a daemon, it's because I want it to use it (weird, isn't
it?).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Jesus Climent]

On Tue, Jun 07, 2005 at 02:40:48PM +0100, Andrew Suffield wrote:
> 
> Why on earth would you? It's just more administrative overhead, and
> yet another package you didn't need.

What made you _think_ i dont need it?

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

I fell asleep in my shithole apartment and I woke up in an actual shithole.
--Adam (Saw)


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

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

[David Goodenough]

On Tuesday 07 June 2005 22:40, Olaf van der Spek wrote:
> Petri Latvala wrote:
> > On Tue, Jun 07, 2005 at 11:40:55AM +0200, Olaf van der Spek wrote:
> >>The ability to have multiple versions of a package installed at the same
> >>time.
> >
> > (Sorry Olaf, for getting this twice, my fingers work too fast)
> >
> > No, dear $DEITY. This "feature" is the major thing I hate about
> > rpms. It's so easy to get wrong and install a package's new version
> > side-by-side when you meant to update the old one. And don't say "just
> > be careful" when there are people in the world who are not seasoned
> > sysadmin veterans who audit every init.d script and whatnot.
> >
> > Making installing another version on the side as a
> > --force-this-I-really-want-to-kick-myself option would not be as bad,
> > but still as bad. This just won't work. Both versions supply
> > $PATH/$FILE, and then what?
>
> Supporting side-by-side file installation isn't (that) simple. But that
> doesn't mean it wouldn't be useful.
> A mechanism would be needed to specify which version of an application
> should be run. Should this be system-wide, per-user, per-environment?
Being able to install a package, not as root but as an ordinary user (and
obviously some packages can not do this as they need access to 
restricted resources) would be really useful.  Yes I can do this as a chroot
or in a virtual system, but that requires a complete install.  

It has often struck me as odd that the structure of program directories
and control files at the user level is different to that at the system level.
So while having a bin directory in a user's home is quite normal, having
an etc directory is not.  Instead control files tend to be hidden in .
directories.  But I guess this is not a debate for Debian, rather for the
FHS.  If one had an etc directory in a home directory then programs 
you run would need to look for unrestricted options in your etc copy of any
control files before looking in the system wide etc directory.

David
>
> > 1) divert the other? what's the use of another package version then
>
> That depends on system-wide vs per-user vs per-environment.
>
> > 2) install to another dir / another name of the file? Again, what's
> > the use
> >
> > 3) this is a library so it only has a .so file with another soname so
> > no name clashes. Hey, oops, different library soname already means a
> > different package (this, I think, is the reason why rpm supports
> > multiple versions)
>
> Does it?
> I thought minor updates didn't change soname?


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

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

[David Pashley]

On Jun 08, 2005 at 08:07, Ian Campbell praised the llamas by saying:
> On Wed, 2005-06-08 at 07:54 +0200, Benjamin Mesing wrote:
> 
> Debian already has a nice way to fix this -- if X doesn't start it tries
> a couple of times and then disables itself and offers to show you the
> log or drop you to a login prompt.
> 
> I don't know if this functionality is from the X packages or from gdm
> etc. but it is a much better solution than the band aid offered by
> run-levels...
> 
Plus you can always boot at runlevel 1 if you really don't want to
attempt starting X.


-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


-- 
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 07, 2005 at 01:03:12AM +0200, Javier Fernández-Sanguino Peña wrote:
> 
> [ Installation improvements ] 

Encrypted root/swap on the d-i installation.
Booting from the d-i and not need a reboot ?

> [ Security improvements ] 

No automatic start of daemons (already mentioned in another post)
tls in MTAs by default.

> [ Admin improvements ]
> - Possibility to startup the OS in "control" mode: select which init 
>   scripts  will run, this provides a way to work-around hardware issues after
>   d-i has installed the base system (personal example: #301112)

Seconded. Even with specific modules loading (select which of the modules from
/etc/modules is actualy loaded). (I just bit a problem with rivafb which
renders the system unbootable)

> - 'Status' in init.d scripts (#291148)

Seconded, too.

> [ End user improvements ] 

Ability to select if the system is multiuser targetted and allow users to log
while a previous user is logged in by default. Single user systems could have
it disabbled.

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

Grool... I meant to say "cool" and then I started to say "great." 
--Cady (Mean Girls)


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

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

[Matthew Palmer]

On Wed, Jun 08, 2005 at 10:23:06AM +0200, Jesus Climent wrote:
> On Mon, Jun 06, 2005 at 09:21:37PM -0400, Joey Hess wrote:
> > This solves your problem fairly well, since the issue then becomes only
> > keeping d-i secure and keeping the installed system secure, not keeping
> > the system secure while it's installing itself. Daemons will not be
> > started dueing the installation, and will come up on reboot.
> 
> 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.

Jesus, meet policy-rc.d.

- Matt


signature.asc
Description: Digital signature

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

[Lars Wirzenius]

ke, 2005-06-08 kello 10:32 +0200, Marco d'Itri kirjoitti:
> On Jun 08, Jesus Climent <[EMAIL PROTECTED]> wrote:
> 
> > I do _not_ want a web server right after apt-get installing it, since
> > everybody has to move the default page and create their own content.
> _I_ do.
> If I install a daemon, it's because I want it to use it (weird, isn't
> it?).

Installing packages in chroots, for example for
installation/upgrade/removal testing, is a further reason to not start
daemons automatically. On the other hand, Marco's position is also
sensible. This suggests that a scheme where the sysadmin can choose for
themselves is in order. A low-priority debconf question, perhaps.


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

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

[Bob Proulx]

Lars Wirzenius wrote:
> Marco d'Itri kirjoitti:
> > Jesus Climent wrote:
> > > I do _not_ want a web server right after apt-get installing it, since
> > > everybody has to move the default page and create their own content.
> >
> > _I_ do.
> > If I install a daemon, it's because I want it to use it (weird, isn't
> > it?).

I also want the daemon running if I have installed it.  I believe this
is one of the great distinguishing features for Debian.  If you
install something then it just works.  (To the extent possible.)

Even for a web server where you will want to modify the default page,
it tells the person installing it immediately that everything is
working as desired.  This is really a nice feature and should not be
lost nor taken as a mis-feature.

> Installing packages in chroots, for example for
> installation/upgrade/removal testing, is a further reason to not
> start daemons automatically.

As mentioned by another this is exactly what policy-rc.d is designed
to handle.  Having worked with other distros using their native
methods I can tell you that Debian is well in the lead with a
significantly better design here.

> On the other hand, Marco's position is also
> sensible. This suggests that a scheme where the sysadmin can choose for
> themselves is in order. A low-priority debconf question, perhaps.

I would not want to see a debconf question for this, even at low
priority and defaulted to yes.  They are an annoyance when installing
and better handled differently.  Using policy-rc.d is the superior
solution.

Bob


signature.asc
Description: Digital signature

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

[Jesus Climent]

On Wed, Jun 08, 2005 at 07:03:56PM +1000, Matthew Palmer wrote:
> > 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.
> 
> Jesus, meet policy-rc.d.

[EMAIL PROTECTED]:~$ man policy-rc.d
No manual entry for policy-rc.d


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

I say you are Lord, and I should know. I've followed a few.
--Arthur (Life of Brian)


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

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

[Matthew Palmer]

On Wed, Jun 08, 2005 at 10:31:33AM +0200, Jesus Climent wrote:
> > > - 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.
> 
> Still, better have init 2 than having to hack the boot command line to set
> init=/bin/bash, having to remount in rw and editing whatever you fucked up,
> before all the services go up and people start login into your server.

It's called single-user mode.

- Matt


signature.asc
Description: Digital signature

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

[Olaf van der Spek]

Don Armstrong wrote:

On Tue, 07 Jun 2005, Olaf van der Spek wrote:


Petri Latvala wrote:


1) divert the other? what's the use of another package version then


That depends on system-wide vs per-user vs per-environment.



If you want something done per-user/per-environment, you can always
use dpkg-deb -x foo.deb .; or whatever to unpack the version you want
to run manually.


What if that package depends on a library that conflicts with a library 
you have installed but you also don't want to uninstall the already 
installed library?

What if you do not want to lose the automatic management of apt-get?


Alternatively, you can have a chroot with the strange versions that
you want.

Having multiple versions system wide when you haven't explicitly
planned for multple versions is just asking for madness. It's


Who said it should be possible without explicitly planning?


especially insane when there are already reasonable methods for having
multiple versions of things installed when that is a reasonable thing
to do. (Think libfoo2, autoconf2.13 or similar.)
 


Don Armstrong




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

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

[Bob Proulx]

Jesus Climent wrote:
> Matthew Palmer wrote:
> > Jesus, meet policy-rc.d.
> 
> [EMAIL PROTECTED]:~$ man policy-rc.d
> No manual entry for policy-rc.d

Look here:

  /usr/share/doc/sysv-rc/README.policy-rc.d.gz

  http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt

Bob


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

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

[Filippo Giunchedi]

Javier Fernández-Sanguino Peña wrote on 7-06-2005 1:03:
[snip]

[ Admin improvements ]
- Possibility to startup the OS in "control" mode: select which init 
  scripts  will run, this provides a way to work-around hardware issues after

  d-i has installed the base system (personal example: #301112)
- 'Status' in init.d scripts (#291148)


- some functions for consistent output when starting/stopping init.d 
scripts (verbose as default and/or simple as [ok]/[notok] (ok, this is 
really needed only on a desktop, in production you are supposed to read 
and debug error messages yourself))


filippo


--
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 Tue, Jun 07, 2005 at 06:09:01PM -0500, John Hasler wrote:
> Roberto C. Sanchez writes:
> > Where, pray tell, is a newbie going to learn about [runlevels]?
> 
> a) By having used Red Hat.
> b) By reading up on Linux before trying to use it (yes, some people _do_
>that).

Yup.  They'll also have learned that packages are managed by rpm.
We'd better change our package management system.


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!

[Colin Watson]

On Tue, Jun 07, 2005 at 10:56:44PM -0500, David Starner wrote:
> "Thaddeus H. Black" writes:
> > However, past character-set discussions on debian-devel
> > have also established how maddening it is to see a '-'
> > in a man page, unsearchable because it is not really a
> > '-';
> 
> The simple fact is, there is a variety of dashes used in proper 
> English printing, and any universal character set is going to 
> have to deal with that. You can turn off this feature in man with 
> a one line change in a config file, and Debian could make it the 
> default;

I already did:

groff (1.18.1.1-7) unstable; urgency=low

  * Too many fonts are missing the Unicode HYPHEN character, so I give up.
Render "-" as HYPHEN-MINUS (ASCII 0x2D) by default. (Of course, manual
pages using "-" when they should be using "\-" should still be fixed.)

 -- Colin Watson <[EMAIL PROTECTED]>  Fri, 18 Mar 2005 17:57:51 +

> or programs that let you search text could merge the various dashes at
> the same time they're merging cases.

That would be far preferable.

Cheers,

-- 
Colin Watson   [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!

[Benjamin Mesing]

> If your X configuration is broken and your X won't start then that is
> effectively the same thing as the proposed run level 3 anyway.  So
> what is the point?
Well, I used to have problems with my graphiccard that hard locked the
system on startup. Being able to do boot into runlevel (RL) 3 without X
(that was back on SuSE), was really nice. I know single user mode can
handle this, but single user is not very comfortable (Who wants to work
with only one tty?).
So mainly its a matter of comfort and consistence with LSB.
Btw. I didn't realize that Debian uses other RL definitions until I
first tried to boot into RL 2.

Greetings Ben




-- 
Please do not sent any email to the [EMAIL PROTECTED] - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.


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

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

[Simon Huggins]

On Tue, Jun 07, 2005 at 02:25:22PM +0100, Andrew Suffield wrote:
> On Tue, Jun 07, 2005 at 10:23:33AM +0200, Thomas Hood wrote:
> > To begin with we can all go back and review:
> > http://wiki.debian.net/index.cgi?ReleaseProposals
> I reviewed it and it still all falls into two groups:
>  - Votes for more money ("Suck less", "Release better and more often")

Why do you think release more often is a vote for "more money"?

I think having a target date, even a target month for release, would
help everyone and reduce the posts to -release lately where people have
finally crawled out of the woodwork to say please let such and such a
package in.

Has anyone stepped forwards to do release management of etch?  What are
their ideas of what's achievable?

Simon.

-- 
Black Cat Networks-("Her name is Bambi?" - Scully)-
UK domain, email and web hosting  -( )-
http://www.blackcatnetworks.co.uk -( )-


signature.asc
Description: Digital signature

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

[Wouter Verhelst]

On Wed, Jun 08, 2005 at 01:15:18PM +0200, Benjamin Mesing wrote:
> 
> > If your X configuration is broken and your X won't start then that is
> > effectively the same thing as the proposed run level 3 anyway.  So
> > what is the point?
> Well, I used to have problems with my graphiccard that hard locked the
> system on startup. Being able to do boot into runlevel (RL) 3 without X
> (that was back on SuSE), was really nice. I know single user mode can
> handle this, but single user is not very comfortable (Who wants to work
> with only one tty?).

Nobody. However, you're assuming that xdm et al will keep trying to
start an X server, even if it fails. Luckily, the respective initscripts
are far more clever than that.

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

[Josselin Mouette]

Le mercredi 08 juin 2005 à 10:13 +0200, Marco d'Itri a écrit :
> On Jun 07, Roger Leigh <[EMAIL PROTECTED]> wrote:
> 
> > - - The locale codeset should be UTF-8 for all new installs by default.
> FFS! When will people learn to not mess with other cultures they know
> nothing about?
> Feel free to advocate a different default charset for *your* locale, but
> do not pretend to know what's better for other locales.

As we have hundreds of broken packages assuming e.g. that the filenames
on disk are encoded in the current locale's character set, the only way
to make them interact properly with other applications is to set a
UTF8-locale.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

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

[Andrew Suffield]

On Wed, Jun 08, 2005 at 02:18:28PM +0100, Simon Huggins wrote:
> On Tue, Jun 07, 2005 at 02:25:22PM +0100, Andrew Suffield wrote:
> > On Tue, Jun 07, 2005 at 10:23:33AM +0200, Thomas Hood wrote:
> > > To begin with we can all go back and review:
> > > http://wiki.debian.net/index.cgi?ReleaseProposals
> > I reviewed it and it still all falls into two groups:
> >  - Votes for more money ("Suck less", "Release better and more often")
> 
> Why do you think release more often is a vote for "more money"?

A 'vote for more money' is a crazy habit that plagues various forms of
government and corporation, but most commonly the worker
cooperative. It's when the workers pass a vote that simply pays them
higher wages, or anything similar. The problem with it being that
voting for it doesn't generate any extra money to pay them, so it's
just not going to happen.

The point here would be that this subset of the 'proposals' doesn't
contain anything that would accomplish the stated goal. It's all very
well to say 'we should release more often' or 'maintainers should suck
less', but saying it won't make it happen. I don't consider statements
like "We should fix the problems" to be meaningful proposals, it's
just manager-style bullshit.

> I think having a target date, even a target month for release, would
> help everyone and reduce the posts to -release lately where people have
> finally crawled out of the woodwork to say please let such and such a
> package in.

This one is "release managers should make real, practical, believable
plans and communicate them to the developers, and then stick to
them". Which, I will note, is not on that wiki page. Also it already
seems to have been happening for sarge, now that Anthony Towns has
been replaced, so I don't think it really qualifies as a proposal.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

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

[Andrew Suffield]

On Wed, Jun 08, 2005 at 10:33:05AM +0200, Jesus Climent wrote:
> On Tue, Jun 07, 2005 at 02:40:48PM +0100, Andrew Suffield wrote:
> > 
> > Why on earth would you? It's just more administrative overhead, and
> > yet another package you didn't need.
> 
> What made you _think_ i dont need it?

Historically (like, 1980s and early 1990s) there was severe memory
pressure, and just running inetd instead of the full daemons could
make a significant difference. 'Modern' (anything in the last five
years) hardware and kernel memory management doesn't show the same
problem. There may still exist cases where inetd would actually make
an improvement, but I've never seen one (and I've looked). How often
do you have a daemon that places significant load on physical memory
and swap space, but *is not doing anything*? Remember that daemons
which have any serious amount of work to do are not candidates for
inetd.

These days, the sort of behaviour that would mean inetd made a
significant improvement would normally be classified as a kernel bug.

This is parallel to the 'compile stuff with cpu-specific options'
noise from gentoo and the like. There was a time when it made a
significant difference (notably the i586), but nowadays it basically
doesn't, except in corner cases (libc, ssl).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

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

[Javier Fernández-Sanguino Peña]

On Wed, Jun 08, 2005 at 03:34:26PM +0200, Wouter Verhelst wrote:
> 
> Nobody. However, you're assuming that xdm et al will keep trying to
> start an X server, even if it fails. Luckily, the respective initscripts
> are far more clever than that.

I've had a laptop that froze because of X starting up and using the wrong
driver to access the card (some of the embedded graphic cards in laptops
are really crappy). The only way to fix this was to startup with a rescue
CD and preventing xdm from running with an 'exit 0' in its initd script (or
by removing its links). At the time, I would have appreciated the
opportunity to bootup in a runlevel that wouldn't try to start up the X
environment until I had fixed the issue.

Just my 2c

Javier


signature.asc
Description: Digital signature

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

[Marco d'Itri]

On Jun 08, Josselin Mouette <[EMAIL PROTECTED]> wrote:

> > FFS! When will people learn to not mess with other cultures they know
> > nothing about?
> > Feel free to advocate a different default charset for *your* locale, but
> > do not pretend to know what's better for other locales.
> As we have hundreds of broken packages assuming e.g. that the filenames
> on disk are encoded in the current locale's character set, the only way
> to make them interact properly with other applications is to set a
> UTF8-locale.
Wrong. The problem is packages which need to interact with text files,
mail and usenet messages generated by broken software, and for which
assuming UTF-8 would be totally wrong.
Again, do not mess with cultures you do not understand.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Roberto C. Sanchez]

On Wed, Jun 08, 2005 at 07:58:32PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Wed, Jun 08, 2005 at 03:34:26PM +0200, Wouter Verhelst wrote:
> > 
> > Nobody. However, you're assuming that xdm et al will keep trying to
> > start an X server, even if it fails. Luckily, the respective initscripts
> > are far more clever than that.
> 
> I've had a laptop that froze because of X starting up and using the wrong
> driver to access the card (some of the embedded graphic cards in laptops
> are really crappy). The only way to fix this was to startup with a rescue
> CD and preventing xdm from running with an 'exit 0' in its initd script (or
> by removing its links). At the time, I would have appreciated the
> opportunity to bootup in a runlevel that wouldn't try to start up the X
> environment until I had fixed the issue.
> 

Is that not the purpose of single user mode or run level 1?

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


pgpXehaC3rFGT.pgp
Description: PGP signature

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

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Jun 08, Josselin Mouette <[EMAIL PROTECTED]> wrote:
>
>> As we have hundreds of broken packages assuming e.g. that the filenames
>> on disk are encoded in the current locale's character set, the only way
>> to make them interact properly with other applications is to set a
>> UTF8-locale.
> Wrong. The problem is packages which need to interact with text files,
> mail and usenet messages generated by broken software, and for which
> assuming UTF-8 would be totally wrong.

This is completely orthogonal to making UTF-8 the default locale
codeset.

The transition will in no way affect your need to use an old-fashioned
8-bit locale codeset if you need to do that.  I fully expect that many
people will do exactly this for years to come, and the changing of the
*default* will not prevent this.

Please bear in mind that this is a change we need to make, which most
of the major commercial distributions did over a year ago, if not
before.  Have you tried installing a recent SuSE or RedHat to check
this?  When I checked late last year, all locales were UTF-8 by
default.  We should have done this long before sarge was released.


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 

iD8DBQFCp1AlVcFcaSW/uEgRAs6GAJ4vMt+LVtRtt1xkLtLVF+vNWJQgVACgiZkb
6rnIalPBufuLiu0gi+2LjNI=
=BSIL
-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!

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Colin Watson <[EMAIL PROTECTED]> writes:

> On Tue, Jun 07, 2005 at 10:28:37PM +0100, Roger Leigh wrote:
>> Tollef Fog Heen <[EMAIL PROTECTED]> writes:
>> > Eh?  You can't change that around just like that, it will break in the
>> > cases where people ssh in from machines with latin1 locales for
>> > instance (and use the PassEnv feature of newer SSHs).
>> 
>> IMHO if you want features like that to work, you should be fully
>> qualifying your locale.
>
> en_GB.ISO-8859-1 doesn't exist unless you go to the effort of defining
> it yourself - it's not in /usr/share/i18n/SUPPORTED. (Yes, in this case
> there happens to be an ISO-8859-15 equivalent, but that's not the case
> everywhere.)
>
> I'm fairly sure I remember glibc upstream vowing never to change the
> meaning of existing locales. Certainly this post from a locale hacker
> well-known in these parts comes to mind:
>
>   http://lists.debian.org/debian-i18n/2004/10/msg00075.html

I see.  If it needs to be kept that way for backwards-compatibility,
that's fair enough.

It's interesting that they chose "eo_EO UTF-8" and
"eo_EO.ISO-8859-3 ISO-9959-3" as the locale names, though!  (If it's a
new locale, I guess there are no problems with that.)

> /usr/share/i18n/SUPPORTED is a little more than "the defaults", I think.
> It's at least standard across systems that use glibc (in that you may
> get additional entries, but you won't get different entries). This makes
> up sufficiently many systems to make me pay attention.

I took the list to mean the set of locale/codeset combinations
supported by the C library locale data, and assumed it was my choice
to name them as I saw fit.  I do worry that in 5 years time we will
hate the fact that we *must* qualify our locale with ".UTF-8" despite
the fact it is the default.  I already find it really annoying, hence
the reason I renamed them.

That said, I'd still like UTF-8 to become the default, whatever the
locale naming scheme we have to use.


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 

iD8DBQFCp1SYVcFcaSW/uEgRAuFEAJ0YVLctuf0aCNjLR0GncDgtCyjJJwCg8C8b
+UXXHesnbtDmdHHJ8qM+Lcc=
=rrjD
-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!

[Javier Fernández-Sanguino Peña]

On Wed, Jun 08, 2005 at 02:17:46PM -0400, Roberto C. Sanchez wrote:
> 
> Is that not the purpose of single user mode or run level 1?

Pray tell me how can run level 1 be enough to solve the problem I described 
if you need to have networking capabitilies to:

a) find a solution to your plight through Google. Yes, you can manually 
start up the netbase stuff you need, but that's hardly some novice can do:

Compare
"init 1 -> root login (ummm what was my user password?) --> start up 
networking -> use lynx (wait, are you browsing as root?)" 

to 

"select non-X startup in grub -> login as your user -> use lynx"

b) have somebody remotely assist you through SSH

Compare 
"init 1 -> root login -> start up networking -> start up ssh -> phone 
friend"

to

"select non-X startup in grub -> (wait for system to startup) -> phone 
friend"

Consider this ficticious scenario: if the "frozen system due to X
misconfiguration" had been my parent's and they have had an option to "boot
with no X" then I could have been able to ask them to start up their system
with that option and diagnost it from my home instead of driving to my 
parent's to fix the issue on console. 

Yes, most people with Debian experience could work around this but it's way
beyond most desktop users that don't know what init.d is.

C'mon there are plenty of OSes out there who have multiple bootup profiles 
that range from a rescue shell (our runlevel 1) to full environment. That's 
useful to debug issues ("why doesn't the system bootup? it must be because 
of the automatic hardware detection/configuration, it works in profile X 
but not in Y") and to have a limited but functional environment when you 
can work around an issue.

I fail to understand why there's so much resistance to this feature when
others find it very useful Fedora Core / RedHat, SuSE, Mandrake in the
Linux distributions area and in all the different (gasp) Windows versions.

Oh well...

Javier
 


signature.asc
Description: Digital signature

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

[Marco d'Itri]

On Jun 08, Roger Leigh <[EMAIL PROTECTED]> wrote:

> > Wrong. The problem is packages which need to interact with text files,
> > mail and usenet messages generated by broken software, and for which
> > assuming UTF-8 would be totally wrong.
> This is completely orthogonal to making UTF-8 the default locale
> codeset.
No, it's not because most applications do not allow setting a different
"default charset".

> The transition will in no way affect your need to use an old-fashioned
> 8-bit locale codeset if you need to do that.  I fully expect that many
> people will do exactly this for years to come, and the changing of the
> *default* will not prevent this.
So you think that we should change the default and then tell everybody
to switch back to have their systems working as expected?

> Please bear in mind that this is a change we need to make, which most
> of the major commercial distributions did over a year ago, if not
> before.
This hardly makes it a "need".

Unsurprisingly, looks you live in a country where anything else than
US-ASCII was rarely used in the past.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Jesus Climent]

On Wed, Jun 08, 2005 at 10:28:28PM +0200, Javier Fernández-Sanguino Peña wrote:
> 
> I fail to understand why there's so much resistance to this feature when
> others find it very useful Fedora Core / RedHat, SuSE, Mandrake in the
> Linux distributions area and in all the different (gasp) Windows versions.

I also fail to see how the argument of "the final user can then configure them
at pleasure" holds, since you still can do that when they come pre-configured
as 1->single, 2->multi+network, 3->2+X

Or however they come.

-- 
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 know what the real tragedy of this day is? I'm not even supposed to 
be here today!
--Dante Hicks (Clerks)


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

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Jun 08, Roger Leigh <[EMAIL PROTECTED]> wrote:
>
>> > Wrong. The problem is packages which need to interact with text files,
>> > mail and usenet messages generated by broken software, and for which
>> > assuming UTF-8 would be totally wrong.
>> This is completely orthogonal to making UTF-8 the default locale
>> codeset.
> No, it's not because most applications do not allow setting a different
> "default charset".

Please could you re-read what I wrote?  What you are saying does not
follow from that.

By default locale charset, I'm referring to the defaults in the
locales package, which are used to generate /etc/locale.gen.  If you
don't want UTF-8 locales, choose the alternatives at this point.  End
of problem.

If you chose both UTF-8 and old locales, there's also the system
default in /etc/environment, which you set to whatever you want.  In
addition if you don't want this systemwide default, you just choose a
different locale, or override it in your .bashrc or with gdm or
wherever.  Where's the difficulty in that?

>> Please bear in mind that this is a change we need to make, which most
>> of the major commercial distributions did over a year ago, if not
>> before.
> This hardly makes it a "need".

GNU/Linux has been slowly moving to UCS since the late '90s.  We are
now well past the point where it's mostly usable and ready for proper
use.  Debian is well behind the times here.

As something to ponder: with all current gcc's in Debian, UTF-8 and
UCS-4 are used as the internal narrow and wide string literal encoding
in all binaries, independent of the C source encoding.  See
http://groups-beta.google.com/group/comp.lang.c.moderated/browse_thread/thread/b421c9ec1894f818/a688cf269948db80#a688cf269948db80
for an example.

> Unsurprisingly, looks you live in a country where anything else than
> US-ASCII was rarely used in the past.

ISO-8859-1 actually.  But this is not really topical.


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 

iD8DBQFCp2MPVcFcaSW/uEgRAlmfAKCbH0iNvjcmYzKXWh0bx20/ckQ18wCdHWgx
ouiUnSYJUM9x4ggBFhDhFr8=
=GfSG
-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!

[Don Armstrong]

On Wed, 08 Jun 2005, Javier Fern?ndez-Sanguino Pe?a wrote:
> On Wed, Jun 08, 2005 at 02:17:46PM -0400, Roberto C. Sanchez wrote:
> > Is that not the purpose of single user mode or run level 1?
> 
> Consider this ficticious scenario: if the "frozen system due to X
> misconfiguration" had been my parent's and they have had an option
> to "boot with no X" then I could have been able to ask them to start
> up their system with that option and diagnost it from my home
> instead of driving to my parent's to fix the issue on console.

There's nothing stoping you from creating a runlevel that doesn't load
your display manager, or doesn't run some daemon. That's what the
flexibility of not having defined runlevels grants you.

Furthermore, it's not like you couldn't trivially disable the DM from
init1 (echo "false" >/etc/X11/default-display-manager or similar) then
telinit 3; or whatever.
 
> Yes, most people with Debian experience could work around this but
> it's way beyond most desktop users that don't know what init.d is.

These people probably won't be able to operate the console anyway, so
a non-X startup isn't going to help them much.


Don Armstrong

-- 
Il semble que la perfection soit atteinte non quand il n'y a plus rien
a ajouter, mais quand il n'y a plus rien a retrancher.
(Perfection is apparently not achieved when nothing more can be added,
but when nothing else can be removed.)
 -- Antoine de Saint-Exupe'ry, Terres des Hommes

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

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

[Javier Fernández-Sanguino Peña]

On Wed, Jun 08, 2005 at 01:43:24PM -0700, Don Armstrong wrote:
> > Yes, most people with Debian experience could work around this but
> > it's way beyond most desktop users that don't know what init.d is.
> 
> These people probably won't be able to operate the console anyway, so
> a non-X startup isn't going to help them much.

I didn't say they would operate through console (although login in in text 
mode and googling using links is not beyond desktop users) but that a non-X 
startup with networking would make it possible to remotely support these 
cases.

Yes, I know I can setup all the boxes I want this way. The question is: is 
this feature useful enough that it can be the default? My (personal) answer 
is yes and I'm not the only one answering it this way, take a look at other 
OSes and you'll see the same answer again and again. In this particular 
case I think the current Debian posture is wrong, not user (or sysadmin) 
friendly and wouldn't take much to improve upon without forcing everybody 
to find their own (sometimes flawed) solution to a very common problem. 

Regards

Javier


signature.asc
Description: Digital signature

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

[Josselin Mouette]

Le mercredi 08 juin 2005 à 20:06 +0200, Marco d'Itri a écrit :
> On Jun 08, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> 
> > > FFS! When will people learn to not mess with other cultures they know
> > > nothing about?
> > > Feel free to advocate a different default charset for *your* locale, but
> > > do not pretend to know what's better for other locales.
> > As we have hundreds of broken packages assuming e.g. that the filenames
> > on disk are encoded in the current locale's character set, the only way
> > to make them interact properly with other applications is to set a
> > UTF8-locale.
> Wrong. The problem is packages which need to interact with text files,
> mail and usenet messages generated by broken software, and for which
> assuming UTF-8 would be totally wrong.

Please come up with real-life examples. Most mail software in Debian, as
well as a good share of our text editors, can deal with several
character sets. The only limitation is nano, our default text editor.
Apart from it, I don't have anything broken with the UTF8 locale I've
been using for a year. On the other side, I can come up with a great
bunch of applications that break with a non-UTF8 locale, starting with
bash and ls.

> Again, do not mess with cultures you do not understand.

No comment.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

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

[Matthew Palmer]

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?

- Matt


signature.asc
Description: Digital signature

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

[Rich Walker]

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

Or maybe you inhabit the "Windows is stable" parallel Usenet-propagating
universe :->

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!

[Wesley J. Landaker]

On Wednesday 08 June 2005 17:25, 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.

If you were really using Linux 10 years ago, you must have had some great 
hardware that you only ever booted into X, or you just never installed any 
XDM at all, instead of just running it when it was needed. X sucked up an 
enourmous amount of memory and resources on a 386 with a few megs of RAM, 
but it was a great way to run Mosaic. =)

> How common was that problem you were trying to solve, again?

Anyway, I'm not arguing for the defaults being either way, but just because 
it's not common for you, doesn't mean it's not common in general. 

I don't often customize runlevels very much, but usually the first thing I 
do when I install a Debian system is remove all the xdm's from 2 and 3 and 
add them to 5. I switch between those all the time on systems that are 
mostly lights servers but sometimes need to become desktops on the fly when 
an extra warm body shows up.

-- 
Wesley J. Landaker <[EMAIL PROTECTED]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgp7PGcxAgner.pgp
Description: PGP signature

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

[Robert Collins]

On Thu, 2005-06-09 at 09:25 +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?

Its not frequency but impact. In, oh, 94, I had a linux box that started
hard locking when the *DM started. Having a X-less, networked startup
config in lilo was a life saver.

The cost of having a networked, X-less rc level is pretty darn low. Why
do you not want one ?

Rob

-- 
GPG key available at: .


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

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

[Christian Perrier]

> Again, do not mess with cultures you do not understand.


Do you have real examples?



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

* 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.)

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

[Miros/law Baran]

9.06.2005 pisze Tollef Fog Heen ([EMAIL PROTECTED]):

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

s/Latin1/any 8-bit encoding from the iso-8859-* range/

Jubal

-- 
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] 

Say the secret word and the duck is yours.


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

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

[Frank Lenaerts]

on Thu, Jun 09, 2005 at 02:30:26AM +0200, Wesley J. Landaker wrote about Re: 
And now for something completely different... etch!:
> I don't often customize runlevels very much, but usually the first thing
> I 
> do when I install a Debian system is remove all the xdm's from 2 and 3
> and 
> add them to 5. I switch between those all the time on systems that are 

The first thing I do after installing xdm is often (not on single
workstations) disabling the startup of the X server because the machine
running xdm is a central application server i.e. client workstations start X
with -query / ... to get a login on the application server. 

I don't want an X server running on the application server so I change xdm's
default configuration. I want to start an X server on the client, so I
create a startup script to start the X server in a non conventional way.

Currently, the runlevel indicates which things are started and these things
can be anything. I consider it a nice and flexible abstraction.

The proposal however, indicates that a runlevel would be dedicated to X. In
my setup, this would mean that my application server would have to run in
this dedicated X runlevel because xdm happens to be started there. However,
this machine doesn't run X at all ... It doesn't seem to feel right i.e. the
abstraction is polluted with implementation issues.

> mostly lights servers but sometimes need to become desktops on the fly
> when 
> an extra warm body shows up.
>
> -- 
> Wesley J. Landaker <[EMAIL PROTECTED]>
> OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2

-- 
[EMAIL PROTECTED]

"Those who do not understand Unix are condemned to reinvent it, poorly."
-- Henry Spencer 


-- 
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 08, 2005 at 07:58:32PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Wed, Jun 08, 2005 at 03:34:26PM +0200, Wouter Verhelst wrote:
> > 
> > Nobody. However, you're assuming that xdm et al will keep trying to
> > start an X server, even if it fails. Luckily, the respective initscripts
> > are far more clever than that.
> 
> I've had a laptop that froze because of X starting up and using the wrong
> driver to access the card (some of the embedded graphic cards in laptops
> are really crappy). The only way to fix this was to startup with a rescue
> CD and preventing xdm from running with an 'exit 0' in its initd script (or
> by removing its links). At the time, I would have appreciated the
> opportunity to bootup in a runlevel that wouldn't try to start up the X
> environment until I had fixed the issue.

Now, that is why we have runlevel 1. But in most cases, wasting
runlevels to things that could just as easily be fixed by ending the
attempts to start is silly.

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

[David Pashley]

On Jun 09, 2005 at 09:09, Tollef Fog Heen praised the llamas by saying:
> * 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.)
> 
One of the new features of irssi 0.8.10 (when it gets released) is
recoding support built in.

-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


-- 
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 08, 2005 at 10:13:00AM +0200, Marco d'Itri wrote:
> On Jun 07, Roger Leigh <[EMAIL PROTECTED]> wrote:
> 
> > - - The locale codeset should be UTF-8 for all new installs by default.
> FFS! When will people learn to not mess with other cultures they know
> nothing about?
> Feel free to advocate a different default charset for *your* locale, but
> do not pretend to know what's better for other locales.

What is the problem with UTF-8 in the Italian locale?

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

[Enrico Zini]

On Thu, Jun 09, 2005 at 11:41:09AM +0200, Wouter Verhelst wrote:
> On Wed, Jun 08, 2005 at 10:13:00AM +0200, Marco d'Itri wrote:
> > On Jun 07, Roger Leigh <[EMAIL PROTECTED]> wrote:
> > > - - The locale codeset should be UTF-8 for all new installs by default.
> > FFS! When will people learn to not mess with other cultures they know
> > nothing about?
> > Feel free to advocate a different default charset for *your* locale, but
> > do not pretend to know what's better for other locales.
> What is the problem with UTF-8 in the Italian locale?

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.


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!

[Simon Huggins]

On Wed, Jun 08, 2005 at 06:22:15PM +0100, Andrew Suffield wrote:
> On Wed, Jun 08, 2005 at 02:18:28PM +0100, Simon Huggins wrote:
> > I think having a target date, even a target month for release, would
> > help everyone and reduce the posts to -release lately where people
> > have finally crawled out of the woodwork to say please let such and
> > such a package in.
> This one is "release managers should make real, practical, believable
> plans and communicate them to the developers, and then stick to them".
> Which, I will note, is not on that wiki page. Also it already seems to
> have been happening for sarge, now that Anthony Towns has been
> replaced, so I don't think it really qualifies as a proposal.

Well ok, I see this as part of http://wiki.debian.net/?FixedReleaseDate

Though I'd rather trade this off to say "we'll release in 18 months
time" and then slip a month if we have to than have an absolutely fixed
date.

Simon.

-- 
oOoOo  If at first you don't succeed, you'll get lots of advice.   oOoOo
 oOoOooOoOo
  oOoOo  oOoOo
  htag.pl 0.0.22 ::: http://www.earth.li/~huggie/


signature.asc
Description: Digital signature

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

[Marco d'Itri]

On Jun 09, Josselin Mouette <[EMAIL PROTECTED]> wrote:

> > Wrong. The problem is packages which need to interact with text files,
> > mail and usenet messages generated by broken software, and for which
> > assuming UTF-8 would be totally wrong.
> Please come up with real-life examples. Most mail software in Debian, as
> well as a good share of our text editors, can deal with several
> character sets.
I did. The problem is not if they can deal with LANG=it_IT.UTF-8, but
how they deal with unlabeled Latin 1 text streams when LANG=it_IT.UTF-8.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Marco d'Itri]

On Jun 08, Roger Leigh <[EMAIL PROTECTED]> wrote:

> >> > Wrong. The problem is packages which need to interact with text files,
> >> > mail and usenet messages generated by broken software, and for which
> >> > assuming UTF-8 would be totally wrong.
> >> This is completely orthogonal to making UTF-8 the default locale
> >> codeset.
> > No, it's not because most applications do not allow setting a different
> > "default charset".
> 
> Please could you re-read what I wrote?  What you are saying does not
> follow from that.
> 
> By default locale charset, I'm referring to the defaults in the
> locales package, which are used to generate /etc/locale.gen.  If you
I'm not. I'm referring to the charset which is used by applications to
interpret unlabeled text streams.

> GNU/Linux has been slowly moving to UCS since the late '90s.  We are
> now well past the point where it's mostly usable and ready for proper
> use.  Debian is well behind the times here.
UTF-8 support is good. A default may be good for some locales and wrong
for others.

> As something to ponder: with all current gcc's in Debian, UTF-8 and
> UCS-4 are used as the internal narrow and wide string literal encoding
> in all binaries, independent of the C source encoding.  See
I can't see why this would be relevant. I'm not arguing about the merits
of Unicode.

> > Unsurprisingly, looks you live in a country where anything else than
> > US-ASCII was rarely used in the past.
> ISO-8859-1 actually.  But this is not really topical.
It is, it explains why you do not understand the issue.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Humberto Massa Guimarães]

Matt 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.
Idem here
>
> Times I've absolutely needed an X-less boot when an XDM was installed: 0.
Mine: 30 or more.
>
> How common was that problem you were trying to solve, again?
It depends on how great is the hardware you have access to. In Brasil, we have 
a lot of crappy SiS mb-integrated video, and stuff like it, that would easily 
freeze the machine if X configuration is not *milimetrically* well-adjusted.
--
HTH, Massa

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

[Josselin Mouette]

Le jeudi 09 juin 2005 à 10:53 +0200, Wouter Verhelst a écrit :
> > At the time, I would have appreciated the
> > opportunity to bootup in a runlevel that wouldn't try to start up the X
> > environment until I had fixed the issue.
> 
> Now, that is why we have runlevel 1. But in most cases, wasting
> runlevels to things that could just as easily be fixed by ending the
> attempts to start is silly.

How would these runlevels be "wasted"? We're only talking about the
default configuration, not about something a system administrator
couldn't change.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

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

[Josselin Mouette]

Le jeudi 09 juin 2005 à 13:21 +0200, Marco d'Itri a écrit :
> On Jun 09, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> 
> > > Wrong. The problem is packages which need to interact with text files,
> > > mail and usenet messages generated by broken software, and for which
> > > assuming UTF-8 would be totally wrong.
> > Please come up with real-life examples. Most mail software in Debian, as
> > well as a good share of our text editors, can deal with several
> > character sets.
> I did. The problem is not if they can deal with LANG=it_IT.UTF-8, but
> how they deal with unlabeled Latin 1 text streams when LANG=it_IT.UTF-8.

At least evolution and all mozilla derivatives can set a default
character set for unlabeled text streams.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

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

[John Hasler]

Frank Lenaerts writes:
> The proposal however, indicates that a runlevel would be dedicated to
> X. In my setup, this would mean that my application server would have to
> run in this dedicated X runlevel because xdm happens to be started there.

The proposal would do nothing to prevent you from continuing to customize
your runlevels.  We are mererly proposing to change the default, not to
impose anything on you.
-- 
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!

[Wouter Verhelst]

On Thu, Jun 09, 2005 at 01:18:39PM +0200, Josselin Mouette wrote:
> Le jeudi 09 juin 2005 à 10:53 +0200, Wouter Verhelst a écrit :
> > Now, that is why we have runlevel 1. But in most cases, wasting
> > runlevels to things that could just as easily be fixed by ending the
> > attempts to start is silly.
> 
> 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.

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

[Steve Greenland]

On 07-Jun-05, 12:51 (CDT), Marco d'Itri <[EMAIL PROTECTED]> wrote: 
> On Jun 07, Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> 
> > > In my wishlist there is NO support of 2.4 kernels
> > Hmm.  I've never verified this myself, however until recently it was often 
> > claimed that 2.6 is still quite a bit worse than 2.4 for some workloads - 
> This does not make it true.

Nor does your assertion that "2.4 is obsolete" make it true. There are
obviously enough people still running 2.4 to justify Marcelo's continued
maintenance effort. 

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.

Now, it may be that there is no need to ship 2.4 kernels in etch. There
are strong reasons to minimize the number of different kernels we need
to support, and if all of the targeted architectures are well supported
by 2.6, well and good. But simply claiming that "2.4 is obsolete" is not
a useful contribution to that decision.


Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
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 Tuesday 07 June 2005 19.51, Marco d'Itri wrote:
> On Jun 07, Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> > > In my wishlist there is NO support of 2.4 kernels
> >
> > Hmm.  I've never verified this myself, however until recently it was
> > often claimed that 2.6 is still quite a bit worse than 2.4 for some
> > workloads -
>
> This does not make it true.

No it doesn't.  But it indicates that there are still people who prefer 2.4 
to 2.6.

Dropping 2.4 can easily be done on relatively short notice prior to etch 
release, so no need to worry about now.

Also, I feel that the decision to ship 2.4 or not can be left up to the 
kernel team - if they have the manpower, fine, if not, dropping 2.4 
certainly is an option.

cheers
-- vbi

-- 
Available for key signing in Zürich and Basel, Switzerland
(what's this? Look at http://fortytwo.ch/gpg/intro)


pgpiK9LtGpwnr.pgp
Description: PGP signature

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

[Marco d'Itri]

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.

> Also, I feel that the decision to ship 2.4 or not can be left up to the 
> kernel team - if they have the manpower, fine, if not, dropping 2.4 
> certainly is an option.
So you would not mind if e.g. alsa-base or hotplug started to depend on
udev, which depends on 2.6 kernels? This is the kind of situation I'm
discussing.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Adrian von Bidder]

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.

No easy way out - either you force people to adapt locale.gen, or you don't 
change locale names.

cheers
-- vbi

-- 
"L'uomo" - diceva S... - "e' un animale ben sciocco, almeno a giudicare
da me stesso".
-- Nicolas de Chamfort, "Caratteri e aneddoti"


pgp2EjmpgyML8.pgp
Description: PGP signature

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

[Frans Pop]

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.


pgp0SKYarfXri.pgp
Description: PGP signature

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

[Darren Salt]

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

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| sarge,| youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   Let's keep the pound sterling

He is no lawyer who cannot take two sides.


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

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

[Joey Hess]

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.

> Also, I feel that the decision to ship 2.4 or not can be left up to the 
> kernel team - if they have the manpower, fine, if not, dropping 2.4 
> certainly is an option.

I agree, and it seems they have the maintainers interested in
maintaining 2.4.

-- 
see shy jo


signature.asc
Description: Digital signature

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

[=?iso-8859-1?Q?Humberto_Massa_Guimar=E3es?=]

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

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

--
[]s,
Massa


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

> > Also, I feel that the decision to ship 2.4 or not can be left up to the 
> > kernel team - if they have the manpower, fine, if not, dropping 2.4 
> > certainly is an option.

> I agree, and it seems they have the maintainers interested in
> maintaining 2.4.

Hmm, if we're referring to the Debian kernel team, I'm not so sure of that.
My impression is that the people currently maintaining the 2.4 tree for
Debian regard it as a necessary evil...

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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