Bill Nottingham wrote:
> John (J5) Palmieri (johnp(a)redhat.com) said:
>>I hadn't gotten to the point of looking at the code yet. I was going to
>>make some test packages, see how it worked as an esd replacement and
>>then go ahead and start looking at it. If it is as you say,
>>impenetrable spaghetti, then I don't want to gain yet another
>>unmaintainable package. Is it your position that the things that are
>>wrong with Polyaudio would be harder to fix than just fixing esd? Or
>>perhaps there are better alternatives around? If we can find a solution
>>that is easy to integrate, maintain and audit I am all for that.
> Well... direct alsa usage can handle the ESD stuff, as long as you
> don't care about network audio (and someone may want to write a shim
> esd-like layer for playback.)
> How important is network audio, anyway?
There are lots of thin client installation, it's important.
Why these scripts/services are default executed/activated at boot time
after Core installation?
- pcmcia: also executed when pcmcia is not present
- isdn: also executed when isdn is not present
- mdmonitor: activated without RAID partitions
- rhnsd: Fedora Core users use RHN for manage/update packages?
- NFS/RPC: activated/executed many scripts about NFS... If I am an NFS
user I think I can activate some scripts/services at boot time.
- cpuspeed: many CPUs (like AthlonXP and other) don't support cpuspeed
Nils O. Selåsdal wrote:
> Nils Philippsen wrote:
>> On Thu, 2004-10-28 at 11:30 +0200, Ralf Ertzinger wrote:
>>> I noticed that external storage deviced that are automagically added to
>>> /etc/fstab by hal do not get the sync flag anymore (at least I think
>>> used to get it). Is this intentional?
>>> I know that sync does not solve all problems with suddenly disappearing
>>> devices, but it sure helps :)
>> IIRC it depends on the size of the storage, i.e. if it is below a
>> certain size it won't get moutned sync because then it's probably some
>> kind of a flash device which can only be written a certain number of
>> times. In that case, sync is a bad idea because it will wear your device
>> much faster.
> What about noatime for such devices ? Shouldn't that help the wear of such
> devices ? Especially since many flash devices have FAT fileystems on
> atime seems to be mapped to the other time fields on fat.
Pretty much ignore this if I'm not mistaken.
FC3 seems to add noatime, FC2 does not.
Nils Philippsen wrote:
> On Thu, 2004-10-28 at 11:30 +0200, Ralf Ertzinger wrote:
>>I noticed that external storage deviced that are automagically added to
>>/etc/fstab by hal do not get the sync flag anymore (at least I think they
>>used to get it). Is this intentional?
>>I know that sync does not solve all problems with suddenly disappearing
>>devices, but it sure helps :)
> IIRC it depends on the size of the storage, i.e. if it is below a
> certain size it won't get moutned sync because then it's probably some
> kind of a flash device which can only be written a certain number of
> times. In that case, sync is a bad idea because it will wear your device
> much faster.
What about noatime for such devices ? Shouldn't that help the wear of such
devices ? Especially since many flash devices have FAT fileystems on them,and
atime seems to be mapped to the other time fields on fat.
I've tried today for the second time to "save" data from an xfs filesystem
from an x86_64 machine which doesn't boot anymore. I don't have any other
x86_64 machine to put the drive in and access it, so I'm not 100% sure
about this "problem", but :
When I try to mount that xfs filesystem on an x86 machine (running FC Devel
and already has some "native" xfs filesystems), I get a nasty segfault...
so I was wondering about filesystem "binary compatibility" across
architectures. As I have some ppcs, an x86_64 and plenty of x86, not being
able to use an existing filesystem across all would definitely make me stay
away from it, could that be the case with xfs? Does anyone know a way to be
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 2.91 (FC3 Test 2) - Linux kernel 2.6.9-1.643.radeon
Load : 1.14 1.13 1.15
It's time for the only really critical decision of the entire release: THE
The candidates for your consideration:
Please send an e-mail to me by Thursday Oct. 27, highlighting your vote.
P.S. There are lots of great possibilities for names, We only can use one
in the end, and a good deal of time has already been spent in the Name
Narrowing-Down Process, so unfortunately the choice does have to be
limited to these three. Thanks for understanding...
I just pushed a 2.1.11 up and Jeremy was kind enough to build it for me
for the FC3 tree.
This should correct a number of config file issues people have had. Now
instead of silently exiting it will tell you what you did wrong and why
the config file is wrong. In some cases it will nicely ignore the error
and move along, in others it will point and laugh at you.
Please give this update a bunch of tests, we want to make sure things
are happy before fc3 is released.
Here they are:
A machine I managed crashed today. The console (25 lines) indicated a
kernel fault in an interrupt handler. After reboot, two pre-crash
kernel oopses were in the log (see attached). The commonality between
the two seems to be a spin_lock being already locked in mm/slab.c.
The oops times were 10:43 and 11:01; the machine crashed somewhere
between 11:01 and 11:10 judging by /var/log/cron (how can I get a more
accurate time of crash?).
This machine is running FC2 kernel 2.6.8-1.521 #1 Mon Aug 16 09:01:18
EDT 2004 i686 i686 i386. The machine had been up for about two weeks
(when it was first put in service with this OS installation), and there
was no apparent unusual activity on it today. It's an NFS fileserver.
Any ideas? Is this likely a problem in the kernel, or with my hardware?