Subject Threading
by Tom Syroid
My apologies, Paul. My bad. I frequent a number of lists, and I typically
do as you note. It was late, and my brain was obviously heading for
la-la-land ahead of my body.
Won't happen again.
Best,
/tom
--On Thursday, July 24, 2003 14:23:55 -0400 Paul Iadonisi
<pri.rhl1(a)iadonisi.to> wrote:
> No flame intended here, just a friendly request to those posting to this
> list.
> It's pretty well accepted on most mailing lists (and I hope it becomes
> so for this one) that posters don't 'reply' to messages using their
> mailer's reply button unless they are truly reply to the message in
> question. The number one reason is that it messes up the 'threading'
> function of most mailers and this problem usually shows up in the list
> archives as well.
20 years, 9 months
Re: 2.6.0-test1 kernel? gcc 3.3 compiler?
by Jack Bowling
----- Original Message -----
From: Bill Nottingham <notting(a)redhat.com>
Date: Thursday, July 24, 2003 10:27 pm
Subject: Re: 2.6.0-test1 kernel? gcc 3.3 compiler?
> Alan Cox (alan(a)redhat.com) said:
> > > USB1 module. I also had to take settings from
> /etc/modules.conf to
> > > /etc/modprobe.conf This was especially annoying since I use a USB
> >
> > There is a script with the 2.5 module tools to generate a conf
> file from
> > your existing one. It knows some of the name changes but submit
> others> to Rusty Russell
>
> It should be run on installation of the new modutils, but only once.
> If it's not working, that's a bug.
Bill - Perhaps I don't understand the process. How about those of us who have a play box where the hardware config changes a lot with time? Should not the script be run everytime it detects a diff between the most recent modules.conf and the modprobe.conf? Or something like that anyway. Seems that it should be trying to pick up changes more frequently anyway.
jb
20 years, 9 months
Speeding up boot process
by Jean-Eric Cuendet
Hi,
What do you think guys if someone did the following to speed the boot
time in RHL?
- Boot kernel (uncompressible)
- Run the init scripts S00 -> S50
- Start X + XDM + UserLogin
- Continue init scripts S51->S99 in background
It's necessary to start keyboard, mouse, network before letting the user
login.
But it's not necessary to start LDAP, CUPS, MySQL, etc..
It would speed up the boot a lot and is easy to implement.
Do you see problems?
-jec
--
Jean-Eric Cuendet
Riskpro Technologies SA
Av du 14 avril 1b, 1020 Renens Switzerland
Principal: +41 21 637 0110 Fax: +41 21 637 01 11
Direct: +41 21 637 0123
E-mail: jean-eric.cuendet(a)rptec.ch
http://www.rptec.ch
--------------------------------------------------------
20 years, 9 months
Re: Bring back configurability in expert mode
by Jack Bowling
Jef S. wrote -
<<<I'd much rather focus any external developer time...on sane default
groups and a sane 'minimal' mode that can be booted into to continue
detailed package installation, from say external yum repos...in one-off
installs(where as kickstart is clearly the way to go for large
replication installs.) Hell i say take this package selection stuff out
of the installer as much as you can...and make a minimal base install
the default, with a nice featurerich firstboot environment>>>
OK. Have two big freaking buttons at the beginning of the install. NEWBIE and SLACKWARE. Then we can have the best rhgb has to offer and the best text-based install there is. The Slack installer is GPLed, I reckon.
jb
Jack Bowling wrote, somewhere in the digest:
>[snip]
>> Leave the dummy installer in RHEL and give those who want the
>> > "expert" mode exactly what they want in RHLP's installer.
>>
>> And maintain two installers? That sounds like a horrible waste of
>> already limited resources.
>Indeed it does. Which is why it will hopefully be coded up by somebody
>ex-RH under the upcoming RHL regime. Then they can maintain it
>themselves and only have it vetted through you. Or is that not how
>things are supposed to work soon?
Bah thats still a waste...yer just adding extra resource to create
multiple codebases...instead of using that extra resources to come to a
reasonable agreement as to how to tackle ALL the competing interests
sorrounding installs in a sane, logical way. I'd much rather get an
external developer on board to fix something like r-c-p or firstboot to
enhance the post-install process to recover and surpass the flexibility
that use to be in the installer. There needs to be a reasonable
development direction that the development community basically agrees to
walk down together. Competing installer bases...wasteful, and should be
avoided inside this project.
I'd much rather focus any external developer time...on sane default
groups and a sane 'minimal' mode that can be booted into to continue
detailed package installation, from say external yum repos...in one-off
installs(where as kickstart is clearly the way to go for large
replication installs.) Hell i say take this package selection stuff out
of the installer as much as you can...and make a minimal base install
the default, with a nice featurerich firstboot environment. is it really
a good idea to do as much as the installer is doing from the cdrom
ramdisk environment? is the complexity of the installer affecting the
minimal hardware requirements needed to do an install? I for one, find i
need to be much more picky about what i'm installing, on older systems
becuase of resource constraints...and if streamlining the installer
process and ripping out as much of the package management logic from it
as can be moved into a firstboot situation helps with lower the required
hardware specs for an install, that would make some sense to me and
provides more value to me than a complicated package selection process
during the cdrom install.
-jef"RFE:yum repos as native anaconda install media option"spaleta
20 years, 9 months
recent added translations to i18n.redhat.com missing
by Marius Andreiana
Hi
I've added romanian [ro] translations to i18n cvs about 2-3 weeks ago
for several packages ( redhat-menus, redhat-artwork, usermode ).
They are still missing from current rhl-beta.
Will these packages be rebuild with newer translations before the final
comes out?
Thanks,
--
Marius Andreiana
Soluţii informatice bazate pe Linux / Linux-based IT solutions
www.galuna.ro
20 years, 9 months
Re: Bring back configurability in expert mode
by Jef Spaleta
Jack Bowling wrote, somewhere in the digest:
>[snip]
>> Leave the dummy installer in RHEL and give those who want the
>> > "expert" mode exactly what they want in RHLP's installer.
>>
>> And maintain two installers? That sounds like a horrible waste of
>> already limited resources.
>Indeed it does. Which is why it will hopefully be coded up by somebody
>ex-RH under the upcoming RHL regime. Then they can maintain it
>themselves and only have it vetted through you. Or is that not how
>things are supposed to work soon?
Bah thats still a waste...yer just adding extra resource to create
multiple codebases...instead of using that extra resources to come to a
reasonable agreement as to how to tackle ALL the competing interests
sorrounding installs in a sane, logical way. I'd much rather get an
external developer on board to fix something like r-c-p or firstboot to
enhance the post-install process to recover and surpass the flexibility
that use to be in the installer. There needs to be a reasonable
development direction that the development community basically agrees to
walk down together. Competing installer bases...wasteful, and should be
avoided inside this project.
I'd much rather focus any external developer time...on sane default
groups and a sane 'minimal' mode that can be booted into to continue
detailed package installation, from say external yum repos...in one-off
installs(where as kickstart is clearly the way to go for large
replication installs.) Hell i say take this package selection stuff out
of the installer as much as you can...and make a minimal base install
the default, with a nice featurerich firstboot environment. is it really
a good idea to do as much as the installer is doing from the cdrom
ramdisk environment? is the complexity of the installer affecting the
minimal hardware requirements needed to do an install? I for one, find i
need to be much more picky about what i'm installing, on older systems
becuase of resource constraints...and if streamlining the installer
process and ripping out as much of the package management logic from it
as can be moved into a firstboot situation helps with lower the required
hardware specs for an install, that would make some sense to me and
provides more value to me than a complicated package selection process
during the cdrom install.
-jef"RFE:yum repos as native anaconda install media option"spaleta
20 years, 9 months
Listman?
by Benjamin Vander Jagt
And again, most of my emails aren't reaching the list anymore.
Getting hundreds more emails per day is nice, but not being able to
reply most of the time. (Hope this one gets through.)
Please please get rid of Listman and get a forum, like everyone else...
--
Benjamin Vander Jagt <benjaminvanderjagt(a)adelphia.net>
20 years, 9 months
RE: modules.conf and new modtils? (broken?)
by Pavel Rosenboim
> -----Original Message-----
> From: Matthew Miller [mailto:mattdm@mattdm.org]
> Sent: Thu, July 24, 2003 7:13 PM
> To: rhl-beta-list(a)redhat.com
> Subject: Re: modules.conf and new modtils? (broken?)
>
>
> On Thu, Jul 24, 2003 at 05:58:44PM +0200, Pavel Rozenboim wrote:
> > > A bit of investigation shows that when the module loads,
> the parameters
> > > in /etc/modules.conf are being ignored -- including the
> very important
> > > one which sets the device minor number. GIving the
> parameters to insmod
> > > manually works fine. WHat's going on here?
> > /etc/modprobe.conf file is used with 2.5 kernels.
>
> Well, as I said, it's not working with the old kernel either.
That's strange - it worked find for me with 2.4 kernels.
> There's no man
> page for that file -- is it the same format?
It's similar, but there are differences. You can't use conditional
statements there, but all the aliases should work. I couldn't find any
documentation about it.
>
> --
> Matthew Miller mattdm(a)mattdm.org
> <http://www.mattdm.org/>
> Boston University Linux ------>
<http://linux.bu.edu/>
--
Rhl-beta-list mailing list
Rhl-beta-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/rhl-beta-list
20 years, 9 months
RE: modules.conf and new modtils? (broken?)
by Pavel Rosenboim
> -----Original Message-----
> From: Matthew Miller [mailto:mattdm@mattdm.org]
> Sent: Thu, July 24, 2003 4:35 PM
> To: rhl-beta-list(a)redhat.com
> Subject: modules.conf and new modtils? (broken?)
>
>
> I installed the new modutils packages from Arjan's web page
> as part of an
> attempt to try out 2.6-test on my Vaio U101. The new kernel
> doesn't work
> very smoothly, but that'll get worked out sooner or later.
> More alarming,
> though: suddenly, the sonypi driver didn't work under the
> *old* kernel.
>
> A bit of investigation shows that when the module loads, the
> parameters in
> /etc/modules.conf are being ignored -- including the very
> important one
> which sets the device minor number. GIving the parameters to insmod
> manually works fine. WHat's going on here?
/etc/modprobe.conf file is used with 2.5 kernels.
20 years, 9 months