On Thu, Jun 18, 2009 at 4:22 PM, Bill Nottinghamnott...@redhat.com wrote:
Martin Langhoff (martin.langh...@gmail.com) said:
To note: it _is_ reported as a 586, so at least ancillary work in
yum/anaconda/rpm will be needed so that installing F12 on these
supported but not quite 686 CPUs is
On Wed, 2009-06-24 at 00:48 -0400, Gregory Maxwell wrote:
Atom systems are frequently battery powered, so improvements there can
also to increased battery life. P4, OTOH, already requires a locally
installed atomic power plant so energy isn't an issue there.
There were actually some P4
There were actually some P4 laptops. They tended to be very large (to
contain the required power and cooling) and have a battery life measured
in minutes. They probably should also have come with heavy-duty lap heat
protectors...
I had a HP xe4500, with a P4M-1.6ghz, and its battery lasted 3
2009/6/25 Adam Williamson awill...@redhat.com:
There were actually some P4 laptops. They tended to be very large (to
contain the required power and cooling) and have a battery life measured
in minutes. They probably should also have come with heavy-duty lap heat
protectors...
I doubt anyone
- Optimize for Atom
I also don't get this one. Why not optimize for the cpu architectur in
use by most fedora-x86 users, like p4 or c2d?
It seems crazy to optimize for a cpu with maybe 5% market share, just
because its the only x86 cpu left. (by the way, the via C7 is still
sold too).
- Clemens
Clemens Eisserer (linuxhi...@gmail.com) said:
- Optimize for Atom
I also don't get this one. Why not optimize for the cpu architectur in
use by most fedora-x86 users, like p4 or c2d?
It seems crazy to optimize for a cpu with maybe 5% market share, just
because its the only x86 cpu left.
1) Optimizing for P4 is ... messy
2) If you're using C2D, etc., you can already use the 64-bit distro.
So why not stay with generic, where most users would benefit.
Sure I could use 64-bit, as could all the others using 32-bit on
64-bit capable CPUs (I guess 50% of all fedora-x86 users).
-
On Tue, Jun 23, 2009 at 4:19 PM, Clemens Eissererlinuxhi...@gmail.com wrote:
1) Optimizing for P4 is ... messy
2) If you're using C2D, etc., you can already use the 64-bit distro.
So why not stay with generic, where most users would benefit.
Sure I could use 64-bit, as could all the others
+1 For the i686 with atom optimizations. This seems like a solid suggestion
and Gregory's argument seems logical.
-Adam
(From my G1)
On Jun 23, 2009 11:49 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Jun 23, 2009 at 4:19 PM, Clemens Eissererlinuxhi...@gmail.com
wrote: 1) Optimizing
Glen Turner (g...@gdt.id.au) said:
On 19/06/09 00:19, Bill Nottingham wrote:
No, period - I haven't seen anyone in the community say that they're
testing it on i586-class hardware.
Hi Bill,
Your wiki page has some jargon (i586) which I'm trying
to reduce to manufacturer products, as you
No, period - I haven't seen anyone in the community say that they're
testing it on i586-class hardware.
Hi Bill,
Your wiki page has some jargon (i586) which I'm trying
to reduce to manufacturer products, as you have already
done for the AMD products.
F12 x86 will not work on i586 (or
Why can't you just leave it as-is?
I mean is 1% improvement (for cpu intensive workload) really worth
changing anything?
Instead of messing arround with stuff like that, I guess a lot of code
would benefit of beeing build with profile driven optimizations, which
often yields a 5-15% improvement
Clemens Eisserer linuxhi...@gmail.com writes:
I mean is 1% improvement (for cpu intensive workload) really worth
changing anything?
No, especially if it screws somebody (not me though).
--
Krzysztof Halasa
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
On Sun, Jun 21, 2009 at 11:24:35PM +0930, Glen Turner wrote:
F12 x86 will not work on i586 (or i686 without CMOV)
Intel Pentium
Intel Pentium Pro
VIA Cyrix III
VIA C3 and C3-M (Samuel 2)
VIA C3 and C3-M (Ezra)
VIA C3 and C3-M
On Sun, Jun 21, 2009 at 3:54 PM, Glen Turnerg...@gdt.id.au wrote:
On 19/06/09 00:19, Bill Nottingham wrote:
No, period - I haven't seen anyone in the community say that they're
testing it on i586-class hardware.
Hi Bill,
Your wiki page has some jargon (i586) which I'm trying
to reduce to
On 18/06/09 11:03, Jeff Spaleta wrote:
Its all a matter of how you look at it. If it turns out that a lot of
64bit hardware owners are running 32bit Fedora 11...
It would be useful if anaconda displayed a info box telling people when
they were considering installing 32b Linux on systems with
On 06/17/2009 12:17 PM, Jeff Spaleta wrote:
On Wed, Jun 17, 2009 at 9:52 AM, Bill Nottinghamnott...@redhat.com wrote:
I'm thinking specifically with people with Centrino stickered
laptops of unclear vintage who may not realize that they have a 64bit
capable machine even when they do. The
On 06/17/09 21:17, Jeff Spaleta wrote:
On Wed, Jun 17, 2009 at 9:52 AM, Bill Nottinghamnott...@redhat.com wrote:
- Atom is the only currently produced 32-bit x86 chip of note; optimize
for what's currently available
Just as an aside, can we do anything to help people identify whether
their
- We don't really support i586 in any meaningful matter
What does this mean? Does Fedora not run on i586? Why was there a
mass-rebuild for i586 if it doesn't work?
I know of *no one* in the community who tests on i586 to ensure that it
works. (If this drags them out of silence, so be
I'm not sure I understand why not. Are you saying that if RedHat
decided that RHEL7 was to support Sparc , there'd be no interest in
making that a primary arch?
ppc/ppc64 is supported in RHEL. It is no longer a primary arch in Fedora.
Sorry? I thought it was still primary until after F-12.
On Wed, Jun 17, 2009 at 06:14:33PM -0400, Chris Ball wrote:
Hi,
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
That's not true; Geode has cmov, and should be compatible with
Hi,
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
That's not true; Geode has cmov, and should be compatible with gcc's i686.
It does work - I have CentOS 5.3 installed currently
On Wed, Jun 17, 2009 at 6:58 PM, Jeff Spaletajspal...@gmail.com wrote:
On Wed, Jun 17, 2009 at 2:28 PM, James Hubbardjameshubb...@gmail.com wrote:
Trying to berate people into using x86_64 as I've seen in this and
other threads has gotten annoying.
Berate? I'm not trying to berate anyone.
Gerd Hoffmann (kra...@redhat.com) said:
On 06/17/09 19:52, Bill Nottingham wrote:
P4 2.4Ghz Athlon 3400+Core2Duo E6850 Atom N270
march=i686/ -1.1% +2.0% +0.9% +0.6%
mtune=generic
march=i586/ +0.3% -0.3% -0.2%
On Wednesday 17 June 2009 20:46:30 Peter Robinson wrote:
I'm not sure I understand why not. Are you saying that if RedHat
decided that RHEL7 was to support Sparc , there'd be no interest in
making that a primary arch?
ppc/ppc64 is supported in RHEL. It is no longer a primary arch in
Peter Robinson (pbrobin...@gmail.com) said:
I know of *no one* in the community who tests on i586 to ensure that it
works. (If this drags them out of silence, so be it!) It is certainly not
part of the QA matrix for testing RCs. On the kernel side, I doubt the
kernel
team even has
Ralf Corsepius (rc040...@freenet.de) said:
*That's* what I mean by we don't really support i586 in any meaningful
manner.
You seem to be speaking in terms of You == RH.
No, period - I haven't seen anyone in the community say that they're
testing it on i586-class hardware.
Bill
--
On Thu, Jun 18, 2009 at 4:48 PM, Bill Nottinghamnott...@redhat.com wrote:
Peter Robinson (pbrobin...@gmail.com) said:
I know of *no one* in the community who tests on i586 to ensure that it
works. (If this drags them out of silence, so be it!) It is certainly not
part of the QA matrix for
Martin Langhoff (martin.langh...@gmail.com) said:
To note: it _is_ reported as a 586, so at least ancillary work in
yum/anaconda/rpm will be needed so that installing F12 on these
supported but not quite 686 CPUs is possible, avoiding the hackery
of installing it on a true 686 and then
On Thu, 2009-06-18 at 10:08 -0400, Jarod Wilson wrote:
[1] doesn't mean a mass rebuild won't happen for RHEL6. Also doesn't
mean that it will. Hand-wavy can't talk about unreleased products...
While not speaking in definitives, and while not speaking /for/ Red Hat,
it is extremely unlikely
On Thu, Jun 18, 2009 at 5:22 PM, Bill Nottinghamnott...@redhat.com wrote:
+arch_compat: geode: i686
...
That should do the trick. :)
Cool. Didn't know we had that compat mechanism available.
Back to my humid cave then...
m
--
martin.langh...@gmail.com
mar...@laptop.org -- School Server
On Wed, 2009-06-17 at 22:19 -0400, Josh Boyer wrote:
perhaps it's best if we just agree to agree?
well that just doesn't sound like the f-d-l spirit at _all_. :D
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
Bill Nottingham wrote:
Ralf Corsepius (rc040...@freenet.de) said:
*That's* what I mean by we don't really support i586 in any meaningful
manner.
You seem to be speaking in terms of You == RH.
No, period - I haven't seen anyone in the community say that they're
testing it on i586-class
On Wed, Jun 17, 2009 at 3:28 AM, Kevin Koflerkevin.kof...@chello.at wrote:
drago01 wrote:
Only in certain apps, and most of them have handwritten SSE routines
anyway.
Not all the apps with handwritten SSE routines can detect the CPU at
runtime, there's a significant amount which needs to be
Orcan Ogetbil, Tue, 16 Jun 2009 20:16:36 -0400:
- Let's keep F-12 the same: ppc, ppc64, i586, x86_64 - Since ppc and
ppc64 are going to be dropped from F-13, fill in the blank spot with
i686+SSE2, i.e. F-13: i586, i686+SSE2, x86_64
Everyone happy?
No, I hate we will be missing other-endian
On Tue, Jun 16, 2009 at 09:33:22PM -0400, Orcan Ogetbil wrote:
Now where does the i686+SSE2 come into play? Does this SSE2 have any
effect on those programs that do not contain SSE(2) related assembly code?
Is this 1-2% improvement that you are mentioning only about these kind of
programs
Gregory Maxwell (gmaxw...@gmail.com) said:
I doubt having consistently lower FP precision is anything many users
are asking for. The few that do can usually take care of themselves.
And yet you say we should push them all to x86_64, which has
the same lower precision?
- More clearly
PLEASE do not do this.
If we stop supporting Pentium II and Pentium III, I have to buy a whole
lot of new hardware. Dead serious.
Could we do i686 as a secondary arch, and swap with i386 further in the
future?
While I understand you may have a lot of older hardware, the point of a
BTW are those new VIA netbooks SSE2-capable?
Additionally, what will this do to RHEL? I can't imagine RHEL
customers being too happy about this for RHEL7(?), and if i386 would
still be in RHEL, it would worry me that it would only be a secondary
arch in Fedora. . .
This is not relevant
- Intel i586 (all)
- Intel Pentium Pro
- Intel Pentium II
- Intel Pentium III
- 32-bit AMD Athlon
As an ambassador, it's going to be hard to explain people that I can't
install Fedora 12 on their computers that still run Windows XP, Ubuntu
and others perfectly fine.
We see 32 bit Athlon
Gregory Maxwell (gmaxw...@gmail.com) said:
'outside'. Please don't just dismiss these recent systems, they are a
real issue.
According to public smolt stats:
http://smolt.fedoraproject.org/static/stats/stats.html
only 0.38% of the userbase is non-Intel/AMD. (Number of registered
Now where does the i686+SSE2 come into play? Does this SSE2 have any
effect on those programs that do not contain SSE(2) related assembly code?
Is this 1-2% improvement that you are mentioning only about these kind of
programs (that do not contain assembly code)?
One advantage of SSE2 is
Peter Robinson wrote:
[...] why maintain x86 at all?
Because it's 58% of our userbase (source: F11 torrent stats.)
How much of that 58% is actually 64 bit machines running the 32 bit OS?
I'm going to guess, a lot of it?
60% of my installations are x86 (75% if you count only hardware, and
Removing support for still-functional hardware is a trademark of
Microsoft, not Linux.
I'd also argue that doing another full rebuild of the OS for a 1%
performance gain on a single architecture is not a particularly
production use of resources.
The 1% comes from i586 - i686; SSE2 would be
On Wed, 2009-06-17 at 02:55 +0200, Kevin Kofler wrote:
Bruno Wolff III wrote:
Is there going to be a way to tell which binaries actually use sse2
instructions, so that the others can be inherited by a secondary arch?
Due to how GCC works, if the compiler flags enable SSE/SSE2, basically
On Tuesday 16 June 2009, Steven M. Parrish wrote:
The OLPC folks have made a commitment use Fedora as the base for future
releases for not only the XO-1.0 but for the new XO-1.5 which is still in
development.
Does use Fedora as the base mean they'll be using binary packages as is from
Den 2009-06-17 18:42, Ville Skyttä skrev:
On Tuesday 16 June 2009, Steven M. Parrish wrote:
The OLPC folks have made a commitment use Fedora as the base for future
Does use Fedora as the base mean they'll be using binary packages as is from
Fedora, without rebuilding them?
Yes.
/abo
--
Given the loud feedback, I've updated the proposal at:
https://fedoraproject.org/wiki/Features/F12X86Support
The revised proposal:
- Build all packages for i686 (this requires cmov)
- Optimize for Atom
Why?
- We don't really support i586 in any meaningful matter
- OLPC still works with
On 06/17/2009 07:52 PM, Bill Nottingham wrote:
Given the loud feedback, I've updated the proposal at:
https://fedoraproject.org/wiki/Features/F12X86Support
The revised proposal:
- Build all packages for i686 (this requires cmov)
- Optimize for Atom
Why?
- We don't really support i586
Once upon a time, Bill Nottingham nott...@redhat.com said:
Why?
- We don't really support i586 in any meaningful matter
What does this mean? Does Fedora not run on i586? Why was there a
mass-rebuild for i586 if it doesn't work?
- We are likely doing a mass rebuild for F-12 anyways, might
Gregory Maxwell (gmaxw...@gmail.com) said:
Consider:
-Os on the x86 build?
Back when I tested before, -Os unilaterally made things worse across
Athlon64/C2D/Atom.
Bill
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Wed, Jun 17, 2009 at 02:41:54PM -0400, Bill Nottingham wrote:
Gregory Maxwell (gmaxw...@gmail.com) said:
Consider:
-Os on the x86 build?
Back when I tested before, -Os unilaterally made things worse across
Athlon64/C2D/Atom.
Note that GCC 4.4 switches -Os on for unlikely executed
On Wed, Jun 17, 2009 at 8:46 PM, Jakub Jelinekja...@redhat.com wrote:
On Wed, Jun 17, 2009 at 02:41:54PM -0400, Bill Nottingham wrote:
Gregory Maxwell (gmaxw...@gmail.com) said:
Consider:
-Os on the x86 build?
Back when I tested before, -Os unilaterally made things worse across
Once upon a time, drago01 drag...@gmail.com said:
Is this (bloated code) really a problem if the code runs faster?
Bloated code:
== more disk space (not too critical except for LiveCD type setup)
== more RAM usage (most have lots of RAM so not too bad)
== more cache misses (slows down code
On Wed, Jun 17, 2009 at 08:56:58PM +0200, drago01 wrote:
Note that GCC 4.4 switches -Os on for unlikely executed basic blocks and/or
unlikely executed functions (of course profile feedback helps here a lot,
but even without it the heuristics gets it right in many cases), so forcing
-Os for
On Wed, Jun 17, 2009 at 9:01 PM, Jakub Jelinekja...@redhat.com wrote:
On Wed, Jun 17, 2009 at 08:56:58PM +0200, drago01 wrote:
Note that GCC 4.4 switches -Os on for unlikely executed basic blocks and/or
unlikely executed functions (of course profile feedback helps here a lot,
but even
On Wed, Jun 17, 2009 at 04:22:21PM +0100, Peter Robinson wrote:
BTW are those new VIA netbooks SSE2-capable?
Additionally, what will this do to RHEL? I can't imagine RHEL
customers being too happy about this for RHEL7(?), and if i386 would
still be in RHEL, it would worry me that it would
Hi,
The revised proposal:
- Build all packages for i686 (this requires cmov)
- Optimize for Atom
This sounds good to me/OLPC. Thanks!
- Chris.
--
Chris Ball c...@laptop.org
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
On Wed, Jun 17, 2009 at 7:52 PM, Bill Nottinghamnott...@redhat.com wrote:
Given the loud feedback, I've updated the proposal at:
https://fedoraproject.org/wiki/Features/F12X86Support
The revised proposal:
- Build all packages for i686 (this requires cmov)
- Optimize for Atom
Sounds
On Wed, Jun 17, 2009 at 9:52 AM, Bill Nottinghamnott...@redhat.com wrote:
- Atom is the only currently produced 32-bit x86 chip of note; optimize
for what's currently available
Just as an aside, can we do anything to help people identify whether
their hardware is 64bit capable?
I'm thinking
On Tuesday 16 June 2009, Steven M. Parrish wrote:
The OLPC folks have made a commitment use Fedora as the base for future
releases for not only the XO-1.0 but for the new XO-1.5 which is still in
development.
Does use Fedora as the base mean they'll be using binary packages as is
from
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
and for what ...
P4 2.4Ghz Athlon 3400+Core2Duo E6850 Atom N270
march=i686/ -1.1% +2.0% +0.9%
On Wed, Jun 17, 2009 at 2:00 PM, Richard W.M. Jonesrjo...@redhat.com wrote:
This just doesn't look worthwhile at all.
My proposal is that we actually start to 'downgrade' x86, start
compiling for baseline i386, and try to support people running Fedora
on really old hardware, through projects
Hi,
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
That's not true; Geode has cmov, and should be compatible with gcc's i686.
- Chris.
--
Chris Ball c...@laptop.org
--
Richard W.M. Jones rjo...@redhat.com writes:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
No, though it cuts out VIA C3 (used mostly(?) on EPIA (mini-ITX)
boards). I have one but it had never run Fedora (only PXE ramdisk-based
small LFS).
Hmm... Just checked
David Woodhouse wrote:
I'm after a system-wide answer, not a microbenchmark for zlib or crypto
code. It should take into account any overheads involved in
saving/restoring registers on context switch that wouldn't otherwise
have to be saved/restored.
Doesn't the kernel have to save/restore
Hi,
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
That's not true; Geode has cmov, and should be compatible with gcc's i686.
Agreed, I've run i686 kernel/openssl on a geode based
The OLPC folks have made a commitment use Fedora as the base for future
releases for not only the XO-1.0 but for the new XO-1.5 which is still in
development.
Does use Fedora as the base mean they'll be using binary packages as is from
Fedora, without rebuilding them?
Yes! The vast majority
On Wed, Jun 17, 2009 at 4:55 PM, Kevin Koflerkevin.kof...@chello.at wrote:
Jeff Spaleta wrote:
Well, we need to start by actually telling people a 64-bit version exists in
the first place! The crappy download page needs to be fixed! We should go
back to something like get-fedora-all, the
On Wed, 2009-06-17 at 14:58 -0800, Jeff Spaleta wrote:
Can smolt tell give me an
indication of the percentage of 64bit capable systems which are
running 32bit Fedora? Hmm.
Question is, how reliable would smolt be, if you don't know how many
more are *not* reporting to smolt anyway, via not
On Thu, Jun 18, 2009 at 01:46:30AM +0100, Peter Robinson wrote:
I'm not sure I understand why not. Are you saying that if RedHat
decided that RHEL7 was to support Sparc , there'd be no interest in
making that a primary arch?
ppc/ppc64 is supported in RHEL. It is no longer a primary arch in
On Wed, 17 Jun 2009 10:03:38 +0200
drago01 drag...@gmail.com wrote:
...snip...
A way that would fix this is a LiveDVD with both the x86_64 and x86
image on it and let the bootloader boot the appropriate version. (I
don't know if this is possible with the current tools). But this would
result
Chris Adams (cmad...@hiwaay.net) said:
- We don't really support i586 in any meaningful matter
What does this mean? Does Fedora not run on i586? Why was there a
mass-rebuild for i586 if it doesn't work?
I know of *no one* in the community who tests on i586 to ensure that it
works. (If
Once upon a time, Bill Nottingham nott...@redhat.com said:
Chris Adams (cmad...@hiwaay.net) said:
How does this affect multilib on x86_64?
It doesn't.
What I meant was what was the impact on running 32 bit binaries on the
64 bit OS (e.g. run your benchmarks there as well).
--
Chris Adams
Chris Adams (cmad...@hiwaay.net) said:
How does this affect multilib on x86_64?
It doesn't.
What I meant was what was the impact on running 32 bit binaries on the
64 bit OS (e.g. run your benchmarks there as well).
Unless I've completely missed something (always a possiblity), 32-bit
On Wed, 17 Jun 2009, Mike Chambers wrote:
On Wed, 2009-06-17 at 14:58 -0800, Jeff Spaleta wrote:
Can smolt tell give me an
indication of the percentage of 64bit capable systems which are
running 32bit Fedora? Hmm.
Question is, how reliable would smolt be, if you don't know how many
Mike McGrath (mmcgr...@redhat.com) said:
Can smolt tell give me an
indication of the percentage of 64bit capable systems which are
running 32bit Fedora? Hmm.
Question is, how reliable would smolt be, if you don't know how many
more are *not* reporting to smolt anyway, via not on
On Wed, Jun 17, 2009 at 23:00:38 +0100,
Richard W.M. Jones rjo...@redhat.com wrote:
My proposal is that we actually start to 'downgrade' x86, start
compiling for baseline i386, and try to support people running Fedora
on really old hardware, through projects like the Minimal Platform
On 06/17/2009 08:10 PM, Bill Nottingham wrote:
See the Fedora Foundations [1] and Objectives [2] page. If we're truly
about being on the leading edge, being innovative, etc., the main target
of Fedora should be current hardware, even if older hardware is still
supported. The only *current*
On Wed, Jun 17, 2009 at 3:55 PM, Mike Chambersm...@miketc.net wrote:
Question is, how reliable would smolt be, if you don't know how many
more are *not* reporting to smolt anyway, via not on internet but on
just a local network?
I'll take it with a grain of salt...but I've no a priori reason
On 06/17/2009 03:00 PM, Richard W.M. Jones wrote:
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
and for what ...
P4 2.4Ghz Athlon 3400+Core2Duo E6850 Atom N270
On Wednesday 17 June 2009 05:00:38 pm Richard W.M. Jones wrote:
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
and for what ...
P4 2.4Ghz Athlon 3400+Core2Duo E6850
On 06/17/2009 11:10 PM, Bill Nottingham wrote:
- We are likely doing a mass rebuild for F-12 anyways, might as well switch
while we're doing it
That's a pretty poor justification.
The common complaint leveled about doing it was why go to the extra effort.
If we're doing a mass rebuild,
Moving to i686+SSE2 while still keeping full support for i586 would imply:
* A secondary arch
* Bits in preupgrade/anaconda to pick the secondary arch on upgrade
* Extra confusion on the download page
Of course, those aren't all hard requirements, but still, I doubt it's
worth the trouble...
Le Lun 15 juin 2009 23:18, Richard W.M. Jones a écrit :
On Mon, Jun 15, 2009 at 01:53:13PM -0400, Bill Nottingham wrote:
- AMD Geode
I'm a little worried about this one.
IIRC my employer uses many Geode GX2 embedded boxes (no mechanical
parts is a design requirement). They're not on
Josh Boyer, Mon, 15 Jun 2009 15:28:04 -0400:
Another option would be to retain the current i586 support, and add the
i686+SSE2 as a new primary arch, with an eye towards depreciating the
current x32 support down the road. There would seem to be less initial
pain involved here, and everyone would
Tom Lane wrote:
Bill Nottingham nott...@redhat.com writes:
drago01 (drag...@gmail.com) said:
Moving to i686 is fine, non i686 chips are mostly dead (but the
perfomance gain from moving to i686 from i586 is questionable at
best).
... how so? It's consistently 1-2% in reasonable benchmarks
Bill Nottingham wrote:
What CPUs do we lose that F11 supports?
- Intel Pentium III
- AMD Geode
- VIA C3
I still have this three in production.
If somebody want some gain and have modern computer [1] he should use
x86_64. He will get SSE2 from scratch and as bonus he will get lm, nx
and
On 06/15/2009 07:53 PM, Bill Nottingham wrote:
Way back when in February [1], FESCo decided that for Fedora 11, i586 would
be the default architecture, and for Fedora 12, it would be some variant of
i686. It's time to follow through on that action item.
I've submitted
On Mon, 2009-06-15 at 13:53 -0400, Bill Nottingham wrote:
Way back when in February [1], FESCo decided that for Fedora 11, i586 would
be the default architecture, and for Fedora 12, it would be some variant of
i686. It's time to follow through on that action item.
I've submitted
On Tue, Jun 16, 2009 at 09:06:37AM +, Matej Cepl wrote:
Josh Boyer, Mon, 15 Jun 2009 15:28:04 -0400:
Another option would be to retain the current i586 support, and add the
i686+SSE2 as a new primary arch, with an eye towards depreciating the
current x32 support down the road. There would
Seth Vidal wrote:
On Mon, 15 Jun 2009, Jon Ciesla wrote:
Seth Vidal wrote:
On Mon, 15 Jun 2009, Jon Ciesla wrote:
BTW are those new VIA netbooks SSE2-capable?
Additionally, what will this do to RHEL? I can't imagine RHEL
customers being too happy about this for RHEL7(?), and if i386
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Frank Murphy wrote:
On 16/06/09 04:56, Matt Domsch wrote:
with a BIOS a little over 5 years old. Is it long in the
tooth? sure. Is it still very
functional? you bet.
I wouldn't go so far as to require sse2 in such a move.
I would
On Mon, 15 Jun 2009, Bill Nottingham wrote:
What CPUs do we lose that F11 supports?
- Intel i586 (all)
- Intel Pentium Pro
- Intel Pentium II
- Intel Pentium III
- 32-bit AMD Athlon
- AMD Geode
- VIA C3
- Transmeta Crusoe
Oh joy. I still have PIII laptops, Athlon desktops and servers here
Once upon a time, Bill Nottingham nott...@redhat.com said:
Jon Ciesla (l...@jcomserv.net) said:
Additionally, what will this do to RHEL? I can't imagine RHEL customers
being too happy about this for RHEL7(?), and if i386 would still be in
RHEL, it would worry me that it would only be
Chris Adams wrote:
I think the big question is this: is this worth the effort? Almost all
the new systems should just be running x86_64 anyway. Why does x86 (32
bit) need to throw out working architectures? Adding them back as a
secondary arch just increases the workload (for somebody) that
On Mon, 15 Jun 2009, Bill Nottingham wrote:
It is 25 actively reporting machines. I've heard the following
reasons why a Centaur or similar CPU class may be reported low:
- Hey, we use a non-GUI server!
- Hey, we're LTSP!
- Hey, we didn't run the firstboot client!
- Older hardware is
Once upon a time, Bill Nottingham nott...@redhat.com said:
Because that's significantly less of our userbase. I'd love to have
harder numbers, but we're still talking about a set of CPUs that
(outside of corner cases like the Geode and C3) ceased production
anywhere from 4 (Athlon) to 6 (P3)
On Tue, 2009-06-16 at 11:42 -0400, Bill Nottingham wrote:
Chris Adams (cmad...@hiwaay.net) said:
Removing support for still-functional hardware is a trademark of
Microsoft, not Linux.
I'd also argue that doing another full rebuild of the OS for a 1%
performance gain on a single
Jonathan Dieter (jdie...@gmail.com) said:
The 1% comes from i586 - i686; SSE2 would be additional on top of
that. But given the vehement opposition, I can see dropping the SSE2
requirement. I'm still fairly convinced that going to i686 is the right
move - we really don't support i586 as a
1 - 100 of 158 matches
Mail list logo
