I'm really surprised to see that the man-pages package in FC4 is the same
release than FC3, i.e. 1.67.
Is there any reason for not providing the latest release avaliable?
Alain PORTAL -- Service Commun de Microscopie Électronique
Université de Montpellier II -- Case Courrier 087
Place Eugène Bataillon -- 34095 Montpellier Cedex 05
Tél. : 04 67 14 37 35 -- Fax. : 04 67 14 37 37
NO WORD ATTACHMENTS: http://www.gnu.org/philosophy/no-word-attachments.fr.htmlhttp://www.giromini.org/usenet-fr/repondre.html
I have a tvcard with a saa7134 chip which worked find in fc4 i386.
now running on amd64 I get during boot:
PCI: device 0000:02:08.0 has unknown header type 7f, ignoring.
and can't see it in lspci.
I am using kernel-2.6.12-1.1387_FC4
Should I fill a bug?
Or is something missconfigured?
-----BEGIN PGP SIGNED MESSAGE-----
Havoc Pennington's entry on his blog (aggregated at p.g.o and other
places) entitled "finished software" led me to think about metacity
again for the first time in a while.
Metacity is admirably stable as a tool; it's one part of my desktop that
never calls attention to itself with problems, glaring features, or
distractions. I never think about it, rarely have to refer to it, and
hear few questions about it.
Yeah, if there were some piece of software in the desktop that I could
regard as in "maintenance mode", metacity would be it. But the topic
got me to thinking about where room for improvement lay, but rather than
filing a bug, I wanted to ask for the general opinion on one thing:
Does the "best-fit" window placement algorithm annoy anyone else ?
After I open a couple of windows and all the vacant real-estate is gone,
all the rest proceed to overlap one another almost as perfectly as
possible all the way up in the top-left corner. Placing windows
perfectly atop one another seems broken.
What's the logic ? Is this an area for improvement/development ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
-----END PGP SIGNATURE-----
Jeff's comment about grabbing from a local mirror got me thinking about
distances to mirrors. So, I tried tracing the route to my local
University of Wisconsin, Madison mirror about 5 Miles down the road in
the Comp. Sci. building. For some odd reason sbcglobal is routing that
traffic through Chicago, Ill and back, about a 300 mile round trip.
Pinging is fast and my dsl line to always maxed out. There must be some
bizarrely fat pipes between Madison and Chicago; I might as well look
for a mirror in Chicago.
Le mercredi 06 juillet 2005 à 13:47 -0400, James Cloos a écrit :
> >>>>> "Nicolas" == Nicolas Mailhot <nicolas.mailhot(a)laposte.net> writes:
> Nicolas> dejavu just made it in fedora extras. Does it have the same
> Nicolas> problem ? (if the answer is yes the dejavu people seem to
> Nicolas> fix their fonts pretty fast - just make them release a fixed
> Nicolas> version and I'll respin the dejavu package)
Thank you very much.
I must say it's a pleasure to see the DejaVu project thriving like any
other core FOSS project after all the various failures and dead ends on
the Linux font front.
Just continue like this and you'll create the corefonts of the FOSS
On Wed, Jul 06, 2005 at 07:26:59AM -0500, Ian Pilcher wrote:
> Arjan van de Ven wrote:
> >On Wed, 2005-07-06 at 07:13 -0400, Build System wrote:
> >>- Drop x86-64 SMP kernels, and make generic kernel use SMP.
> >why is this??
> Presumably it's because so many processors these days are either Hyper-
> Threaded or (soon) dual-core. At some point, the benefit of building
> and shipping uni-processor kernels is less than the cost.
Indeed. The proportion of UP vs SMP x86-64's out there is only
going to increase in favour of SMP. Last numbers I read showed
that HT EM64T's outsold AMD64's already. As the UP kernel gets
less and less testing moving forward, it doesn't really offer
any great benefit to shipping it. Especially as the performance
overheads of running SMP locking on UP is negligable.
Finally, there's going to be an extra set of kernels for x86-64 xen
at some point, which pushes the total number of kernels up yet again.
As we're constantly battling for CD space, this tradeoff seemed worth it.
If test1 goes out, and it blows up horribly (ie, there are lots of
single CPU x86-64 boxes out there which can't run the SMP kernel)
we'll look at reconsidering this decision. Given x86-64 doesn't have
the crappy lineage that it's 32bit predecessor has, I'm confident that
this won't be the case.
I'd like to see the supported number of CPUs jump from 64 to 512 so that it
would be possible to run Fedora Core 5 on large CPU systems.
Covered by BZ #162570.
--- kernel-2.6.11/linux-2.6.11/.config.orig 2005-07-06 12:30:02.696189724 -0400
+++ kernel-2.6.11/linux-2.6.11/.config 2005-07-06 12:30:16.484275493 -0400
@@ -93,7 +93,7 @@ CONFIG_IA64_CYCLONE=y
# CONFIG_HOTPLUG_CPU is not set
# CONFIG_PREEMPT is not set