Earlier this year on this list several of us were discussing the
possibility of adjustments being made to the architecture optimizations
of the Fedora Core packages. One of the suggestions thrown around that
had zero opposition was changing the base architecture from i386 to
i486. Why has this not been done? This is especially poignant since
Fedora Core 1 finally broke i386 compatibility with its kernel.
I'm sending a related note on the Pentium 4.
I'm guessing that I should know this, sorry, but with the last initscripts
update, I now get a message like
"can't find /proc/bus/usb in /etc/fstab or /etc/mtab"
I have googled to see what should be in /etc/fstab and have found four
usbdev /proc/bus/usb usbdevfs defaults 0 0
usbdevfs /proc/bus/usb usbdevfs noauto 0 0
none /proc/bus/usb usbdevfs defaults 0 0
/proc/bus/usb /proc/bus/usb usbdevfs defaults 0 0
What should I have? I do have a /proc/bus/usb that is populated.
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
bpmATec-groupDOTcom Greg Glenn
xmms is (imho) the best music player that ships with FC simply from a
usability standpoint, small screen footprint etc.
However, it does not use the gtk2 interface and does not use the
I found what I think would be a good replacement - it currently does
not work for me, so it has that against it, but that may be because I
updated my gstreamer plugins from stock fc3 (to 0.8.6) though that
hasn't effected other gstreamer apps.
It's called eina - http://bolgo.cent.uji.es/proyectos/eina-en
It has a very small screen footprint, and simple easy to use interface.
It works for me up to the point of actually playing a song, then it
hangs (I've only tried mp3 - I haven't tried flac or ogg). But I think
it is worth looking into for possible inclusion in Fedora Extras and
eventual replacement of xmms, which doesn't seem interested in gtk2 or
> rpm -qi openoffice.org-i18n
Name : openoffice.org-i18n Relocations: (not relocatable)
Version : 1.1.2 Vendor: Red Hat, Inc.
Release : 12.7 Build Date: Tue Nov 23 23:38:11
Install Date: Sat Nov 27 10:46:07 2004 Build Host:
Group : Applications/Productivity Source RPM:
Size : 645925614 License: LGPL
Would it make sense to split openoffice.org-i18n up somewhat? For example,
I'm only interested in Finnish and not about Africaans, Catalan, Arabian and
what not. 650MB is pretty much for stuff that is not needed at all; it's a
huge download (although it compresses well), but also takes up disk space
Or is it just infeasible idea to split it in smaller parts?
BTW: Anyone tried openoffice 2.0 beta yet? I don't suppose there are fedora
rawhide compatible rpm's for it somewhere?
-- v --
I am not entirely sure if this is how to do it. But, here goes:
In the past you could configure printers using the RedHat supplied tools
(as found in menus) in Samba. I am no longer seeing this. I have checked
the option in print conf to share the printers and autodiscover them. I
think this is a cups thing. However, this doesn't even seem to be
working with my systems. (I do have all the systems checked to discover
the shared printers.)
Even if this was working, this doesn't share them with the Windows
In FC4 is it possible to add an option in printconf or what not that
will share them via Samba as well as cups method?
"What makes his world so hard to see clearly is not its strangeness but
its usualness. Familiarity can blind you." -- Robert M. Pirsig
I have been using the following changes to some network parameters on all
of my machines for a long time, and I was wondering whether they ought to
be set by default.
net.ipv4.conf.all.rp_filter (current: 0, proposed: 1)
net.ipv4.conf.all.accept_redirects (current: 1, proposed: 0)
net.ipv4.icmp_echo_ignore_broadcasts (current: 0, proposed: 1)
net.ipv4.icmp_ignore_bogus_error_responses (current: 0, proposed: 1)
While I admit that the current values can serve a certain use in some
situations, I think that in the majority of configurations the proposed
values are more sensible.
"Carpe dentem! Seize the teeth!" -- Mrs Doubtfire
On Maw, 2004-11-30 at 18:23, Jim Gettys wrote:
> I agree with you and Kristian and I have started work, specifically on
> the input system side to do exactly what you suggest. Similar
> work ought to be done someday for the screens themselves (hotplug being
> a reality even for screens; today with PCMCIA and PCI express is just
> beginning to ship).
Mobility Electronics have been shipping cardbus hotplug video for about
5 or 6 years now (E1000V). They make fun toys for this sort of testing
and are cheap on ebay generally 8)
On Sun, Nov 28, 2004 at 05:42:41PM -0500, William M. Quarles wrote:
> A. I'm tired of Red Hat holding back on optimizations. The architecture
> tree/network that RPM consults is kind of screwed up. Not to mention
> that it is ridiculous to compile packages for i386 architecture that
> will never run on an i386, especially when the developers have dropped
> in MMX instrcutions in the assembly anyways, so the i386 designation is
> then meaningless.
Those applications should be doing the relevant cpuid checks at runtime
before using them. Fedora supports processors that don't have MMX.
If you have a list of applications that don't do this, file bugs
> It would be nice if RPM could call compilations for
> say pentium-mmx or pentium2 rather than forcing developers to insert
> this code manually via assembly
The number of packages using assembler is tiny compared to the
number of applications shipped. And no gcc options are going to
change that for the most part. gcc is getting better all the time,
but hand-written assembler is hard to beat for speed-critical
operations in packages that really need the speed.
> B. Red Hat developers were saying before that we need more optimization
> for the Pentium 4 because it is obviously not running as well on i686
> optimizations as it could. However, I have yet to see a Pentium 4
> optimized Fedora Core kernel come out. Perhaps they're busy debating
> about whether to call it pentium4 or i786.
The idea had crossed my mind to ship the 686 kernel as p4 optimised
the last time this discussion came around for benchmarking purposes.
Not around round tuits.
> C. If it doesn't hurt and it would probably help, I don't see what's the
> matter with making an Athlon-optimized kernel.
A number of reasons.
- It's one more column in the matrix of supported kernels to worry about.
This may seem insignificant, but it takes quite a while to push
a kernel package through the buildsystem given how many variants
it spits out. On a busy day (like for eg, just before release), it
can take the better part of a day to get packages built.
- The gain just isn't worth it over the 2.4 kernels.
Now that the runtime optimisations get performed in 2.6, theres only
one thing thats missing that would be in an Athlon optimised kernel,
and thats the optimised copy_page/clear_page, which are really only
a win when a lot of data is being copied back/forth between the kernel,
and even then, only under certain usage patterns. I'll be surprised
if this shows up on any real-world application.
- anyone this concerned about that last 1-2% of performance will want
to recompiling their own kernel anyway to disable such things as
highmem support when not needed, or selinux, or 4g4g, or..
> And considering the
> complaints that I have seen, it would make even more sense to make a
> Pentium 4-optimized kernel available even if the Athlon one was not
As above. A seperate kernel is probably overkill.
Compiling the 686 kernel with gcc tunings for p4 (but no instructions)
might make sense however.
Is this a issue of new version of samba or a my wrong configuraton (the
smb.conf is a standard file released whit samba) ?
[lesca@lesca lesca]$ smbclient -L printerone
Domain=[DOM] OS=[Unix] Server=[Samba 3.0.9-1.fc3]
Sharename Type Comment
--------- ---- -------
tmp Disk Temporary file space
pubblica Disk Cartella pubblica x Tutti
IPC$ IPC IPC Service (Samba Server Printerone)
ADMIN$ IPC IPC Service (Samba Server Printerone)
hp4000N Printer laser1
hp4050N Printer laser2
hp4200N Printer laser3
lasri1 Printer lasri1
Printer share name IS laser1, descri is hp4000N ecc...
I have other printers whit the same description (hp4000N) but whit
[lesca@sispay ~]$ lpstat -v
device for laser1: socket://laser1:9100/
device for laser2: socket://laser2:9100/
device for laser3: socket://laser3:9100/
device for laser4: socket://laser4:9100/
device for laser5: socket://laser5:9100/
device for laser6: socket://laser6:9100/
device for lasri1: socket://lasri1:9100/
[root@sispay lesca]# grep -B 1 Info /etc/cups/printers.conf
Dario Lesca <d.lesca(a)solinos.it>
I have had some difficulties with installing a box with a "RIVA128" gfx
The install process itself goes all well. Problems turns up when it has
finished installing packages (which took a couple of hours, using NFS...
Dead-slow machine...), and reboots.
When it has rebooted, it comes to a point where it says "configuring
kernel parametres". And there it stops (i had it hanging there for a
weekend, just to be shure. It was still hung when i got back on monday
Rigth before this happens, it tries to bring up RHGB, which fails
miserably. But it fails, it don't chrash the box. Only way (i) have
found to solve it, is to boot into single user (it does then get past
the "configuring kernel parameters" without problems), and changing the
driver from "nv" to "vesa". reboot gets up rhgb, but it still hangs
there (or at least when it comes to firstboot). I i then kill power,
boot it into single user mode, and *then* using "init 5" to get it up
(twice - firstboot chrashes in the first atempt, taking the rest of the
thing with it, but it don't happen again...), it works up to GDM. I can
then shutdown and reboot and everything else (after fixing monitor
resolution and refresh...) without problems.
As far as i can see, this is more than one bug, and i don't know where
to file'em. xorg? kudzu? firstboot? rhgb? kernel?