2:35 p.m.
Kevin Fenzi (kevin(a)scrye.com) said, in the FESCo meeting summary:
* Architecture Support
https://fedoraproject.org/wiki/Features/ArchitectureSupport
FESCo tabled this to revisit this next week. There were questions
about OLPC support and LSTP client machines. Discussion to continue
on fedora-devel list.
As a followup to the discussion on compiler flags, this feature was
written up to describe a plan for what to do overall about what
architectures we support. The main points are:
- install x86_64 kernel on 32-bit OS where appropriate
- install PAE kernel on other 32-bit OS installs where appropriate
- build only i686 and above for Fedora
The last one is the issue that caused discussion during the FESCo
meeting. The main points raised:
- XO support
There is concern that building for i686 might break binaries on the XO.
The Geode on the XO self-reports as i586; this may need slight frobbing.
Aside from that, it "supports the i686 (Pentium Pro) instruction set, MMX,
the parts of SSE that do not involve SSE registers, 3DNow! Enhanced, a
couple Geode-specific instructions and a few SSE2 instructions."
(http://wiki.laptop.org/go/Geode_instruction_set)
This implies it should work; however, there have been bugs in the past
(https://bugzilla.redhat.com/show_bug.cgi?id=200330). Chris Ball stated
"my input as OLPC software dude is that we're probably okay with dropping
586, but it would be great if someone heled us test that everything's
looking okay first."
- K12Linux/thin client
Some older thin client hardware is not i686 compatible. Warren has more
info on this. One question I have is that some of this is mentioned
as being Geode - wouldn't this fall into the same category as the XO?
Also, just how much of this hardware is out there using Fedora now
(as oppposed to RHEL, CentOS, or some other distribution?)
More info is on the feature page. Note that in the smolt stats, i586
accounts for less than one twentieth of one percent of active systems,
an order of magnitude less than PowerPC.
Bill
2:42 p.m.
On Fri, Jan 30, 2009 at 9:35 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Kevin Fenzi (kevin(a)scrye.com) said, in the FESCo meeting summary:
> * Architecture Support
> https://fedoraproject.org/wiki/Features/ArchitectureSupport
>
> FESCo tabled this to revisit this next week. There were questions
> about OLPC support and LSTP client machines. Discussion to continue
> on fedora-devel list.
As a followup to the discussion on compiler flags, this feature was
written up to describe a plan for what to do overall about what
architectures we support. The main points are:
- install x86_64 kernel on 32-bit OS where appropriate
How is this going to work for livecd installs ?
Let yum pull in a x86_64 kernel on the first update if supported?
2:47 p.m.
drago01 (drago01(a)gmail.com) said:
> As a followup to the discussion on compiler flags, this feature
was
> written up to describe a plan for what to do overall about what
> architectures we support. The main points are:
>
> - install x86_64 kernel on 32-bit OS where appropriate
How is this going to work for livecd installs ?
Yet to be determined.
Bill
2:51 p.m.
On Fri, 30 Jan 2009, Bill Nottingham wrote:
- install x86_64 kernel on 32-bit OS where appropriate
- install PAE kernel on other 32-bit OS installs where appropriate
How does the "where appropriate" exactly work? I didn't find technical
details for this...
- build only i686 and above for Fedora
But we will keep the .i386.rpm for regular RPM packages anyway or are we
"upgrading" all ENVRA namings to .i586.rpm or .i686.rpm?
Greetings,
Robert
2:58 p.m.
On Fri, Jan 30, 2009 at 9:51 PM, Robert Scheck <robert(a)fedoraproject.org> wrote:
On Fri, 30 Jan 2009, Bill Nottingham wrote:
> - install x86_64 kernel on 32-bit OS where appropriate
> - install PAE kernel on other 32-bit OS installs where appropriate
How does the "where appropriate" exactly work? I didn't find technical
details for this...
If the hw is capable of doing so (ie any "modern" cpu)
> - build only i686 and above for Fedora
But we will keep the .i386.rpm for regular RPM packages anyway or are we
"upgrading" all ENVRA namings to .i586.rpm or .i686.rpm?
Mass rebuild to go i686.rpm
3:19 p.m.
On Fri, 30 Jan 2009, drago01 wrote:
On Fri, Jan 30, 2009 at 9:51 PM, Robert Scheck wrote:
> How does the "where appropriate" exactly work? I didn't find
technical
> details for this...
If the hw is capable of doing so (ie any "modern" cpu)
Means that anaconda and yum will examine /proc/cpuinfo for example and look
for CPU flags and decide on that? And how will other updaters/installers as
e.g. smart/apt handle that? Or will we get this checks directly into RPM?
> But we will keep the .i386.rpm for regular RPM packages anyway
or are we
> "upgrading" all ENVRA namings to .i586.rpm or .i686.rpm?
Mass rebuild to go i686.rpm
Okay, so we will have then only *.i686.rpm for 32 bit Intel everywhere?
Greetings,
Robert
3:36 p.m.
Robert Scheck (robert(a)fedoraproject.org) said:
> If the hw is capable of doing so (ie any "modern"
cpu)
Means that anaconda and yum will examine /proc/cpuinfo for example and look
for CPU flags and decide on that? And how will other updaters/installers as
e.g. smart/apt handle that? Or will we get this checks directly into RPM?
The 'choosing the best kernel' logic has always been outside the
package manager, dating back to the days of a separate SMP kernel.
Bill
3:36 p.m.
On Fri, Jan 30, 2009 at 10:19 PM, Robert Scheck
<robert(a)fedoraproject.org> wrote:
On Fri, 30 Jan 2009, drago01 wrote:
> On Fri, Jan 30, 2009 at 9:51 PM, Robert Scheck wrote:
> > How does the "where appropriate" exactly work? I didn't find
technical
> > details for this...
>
> If the hw is capable of doing so (ie any "modern" cpu)
Means that anaconda and yum will examine /proc/cpuinfo for example and look
for CPU flags and decide on that? And how will other updaters/installers as
e.g. smart/apt handle that? Or will we get this checks directly into RPM?
why should anything but anaconda care?
just upgrade what is installed to what is in the repos.
> > But we will keep the .i386.rpm for regular RPM packages
anyway or are we
> > "upgrading" all ENVRA namings to .i586.rpm or .i686.rpm?
>
> Mass rebuild to go i686.rpm
Okay, so we will have then only *.i686.rpm for 32 bit Intel everywhere?
yes
3:29 p.m.
Once upon a time, Bill Nottingham <notting(a)redhat.com> said:
As a followup to the discussion on compiler flags, this feature was
written up to describe a plan for what to do overall about what
architectures we support. The main points are:
- install x86_64 kernel on 32-bit OS where appropriate
IIRC, I asked about this a few years ago and got told that there was a
performance hit (not big but measurable) for running the 64 bit kernel
and 32 bit userland. Maybe that was wrong or is now outdated.
Right now, it is still possible to install on one i686 system and plug
the drive into another, which this could break (installing on i686 and
moving to <i686 has been broken for a long time, so maybe this isn't a
big consideration).
What are the chances GRUB/syslinux could be taught to look at a few
special CPU flags (can you fetch the important flags from real mode?)
and only present "compatible" (as determined by config arguments, not
GRUB/syslinux poking into kernels) boot options? That would help the
LiveCD case as well. You could have both 32-PAE and 64 kernels on the
CD and choose at boot time, although that would take up a large amount
of space (so maybe not feasible for LiveCD).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
5:37 p.m.
On Friday, January 30 2009, Chris Adams said:
What are the chances GRUB/syslinux could be taught to look at a few
special CPU flags (can you fetch the important flags from real mode?)
and only present "compatible" (as determined by config arguments, not
GRUB/syslinux poking into kernels) boot options? That would help the
LiveCD case as well. You could have both 32-PAE and 64 kernels on the
CD and choose at boot time, although that would take up a large amount
of space (so maybe not feasible for LiveCD).
A com32 module could be written without too much trouble for syslinux,
but space on the live images make it kind of a moot point (imho) as it
seems better to ship more applications as opposed to more kernels on the
live image
Jeremy
9:12 a.m.
Chris Adams <cmadams(a)hiwaay.net> writes:
IIRC, I asked about this a few years ago and got told that there was
a
performance hit (not big but measurable) for running the 64 bit kernel
and 32 bit userland. Maybe that was wrong or is now outdated.
It should be the other way around -- 64 bit kernel should be faster.
The only downside is that the kernel may take a little more memory,
but that isn't really a problem for non-embedded systems.
What are the chances GRUB/syslinux could be taught to look at a few
special CPU flags (can you fetch the important flags from real mode?)
and only present "compatible" (as determined by config arguments, not
GRUB/syslinux poking into kernels) boot options? That would help the
LiveCD case as well. You could have both 32-PAE and 64 kernels on the
CD and choose at boot time, although that would take up a large amount
of space (so maybe not feasible for LiveCD).
That would be rather neat. Tricky, but neat.
/Benny
9:57 a.m.
Benny Amorsen wrote:
> What are the chances GRUB/syslinux could be taught to look at a
few
> special CPU flags (can you fetch the important flags from real mode?)
> and only present "compatible" (as determined by config arguments, not
> GRUB/syslinux poking into kernels) boot options? That would help the
> LiveCD case as well. You could have both 32-PAE and 64 kernels on the
> CD and choose at boot time, although that would take up a large amount
> of space (so maybe not feasible for LiveCD).
That would be rather neat. Tricky, but neat.
But our live images are already heavily size-constrained. There's definitely
no room for multiple kernels on the KDE live image, and I don't think the
GNOME image has any room left either.
Kevin Kofler
10:06 a.m.
I wrote:
But our live images are already heavily size-constrained.
There's
definitely no room for multiple kernels on the KDE live image, and I don't
think the GNOME image has any room left either.
And I'll add to this that I think the real solution is to make the x86_64
image the default download and the 32-bit image a separate link (maybe
marketed primarily for netbooks). Most computers these days are 64-bit
capable. (Almost all the new non-netbook computers are.) Running 32-bit
userspace on a 64-bit kernel is just a kludge, we should be promoting pure
64-bit instead.
Kevin Kofler
10:11 a.m.
On Sat, Jan 31, 2009 at 5:06 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
I wrote:
> But our live images are already heavily size-constrained. There's
> definitely no room for multiple kernels on the KDE live image, and I don't
> think the GNOME image has any room left either.
And I'll add to this that I think the real solution is to make the x86_64
image the default download and the 32-bit image a separate link (maybe
marketed primarily for netbooks). Most computers these days are 64-bit
capable. (Almost all the new non-netbook computers are.) Running 32-bit
userspace on a 64-bit kernel is just a kludge, we should be promoting pure
64-bit instead.
Yeah users should not have to search for the 64bit version, it should
be the default with a link "For older systems click here"(32bit
version).
10:16 a.m.
drago01 wrote:
Yeah users should not have to search for the 64bit version, it
should
be the default with a link "For older systems click here"(32bit
version).
+1, except it should be "For netbooks or older computers click here (32-bit
version)".
Unfortunately, most netbooks are not 64-bit capable. :-( The netbook
versions of the Atom have it disabled ("for power consumption reasons",
they say; I think there's also some differential pricing involved) and the
Celeron used on the original EeePCs and some other netbooks is also a
32-bit only version (based on the original Core Solo, AFAIK).
Kevin Kofler
2:42 p.m.
Kevin Kofler wrote:
I wrote:
> But our live images are already heavily size-constrained. There's
> definitely no room for multiple kernels on the KDE live image, and I don't
> think the GNOME image has any room left either.
And I'll add to this that I think the real solution is to make the x86_64
image the default download and the 32-bit image a separate link (maybe
marketed primarily for netbooks). Most computers these days are 64-bit
capable. (Almost all the new non-netbook computers are.)
Most *new* (non-netbook) hardware, sure. What about existing hardware?
Both my home machines are still 32-bit (one is not even 1 GHz CPU!).
Running 32-bit
userspace on a 64-bit kernel is just a kludge, we should be promoting pure
64-bit instead.
Didn't we just have the "32-bit is actually faster" discussion? Okay,
not true for x86, but the above statement still isn't entirely accurate.
That said, I do agree that running i686 on an x86_64 is a bit silly :-).
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
We interrupt this e-mail to bring you a lame signature attempting to be
witty.
10:07 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
But our live images are already heavily size-constrained. There's
definitely
no room for multiple kernels on the KDE live image, and I don't think the
GNOME image has any room left either.
Was already discussed the requirement of CDs nowadays? Even the oldest
computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
Regards,
Jan
10:12 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
> But our live images are already heavily size-constrained. There's definitely
> no room for multiple kernels on the KDE live image, and I don't think the
> GNOME image has any room left either.
Was already discussed the requirement of CDs nowadays? Even the oldest
computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
Well for x86_64 we can/should do this.
Good luck on finding a x86_64 computer/laptop without a DVD drive.
10:14 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
drago01 wrote:
Well for x86_64 we can/should do this.
Good luck on finding a x86_64 computer/laptop without a DVD drive.
But x86_64 doesn't need multiple kernels, it needs only the x86_64 one. PAE
is not needed on x86_64 and 32-bit kernels don't work with 64-bit
userspace.
Kevin Kofler
10:39 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 5:14 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
drago01 wrote:
> Well for x86_64 we can/should do this.
> Good luck on finding a x86_64 computer/laptop without a DVD drive.
But x86_64 doesn't need multiple kernels, it needs only the x86_64 one. PAE
is not needed on x86_64 and 32-bit kernels don't work with 64-bit
userspace.
That's not about kernels, we should move away from a CD atleast for
x86_64 instead of not shipping useful apps for size reasons (ex:
OO.org)
10:47 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
drago01 wrote:
That's not about kernels, we should move away from a CD atleast
for
x86_64 instead of not shipping useful apps for size reasons (ex:
OO.org)
OO.o still has no working KDE 4 integration, and we don't even have the KDE
3 integration packaged, so I'm not sure it would be a good idea to put it
on the KDE spin anyway. KOffice 2 is the way to go in the long run.
Kevin Kofler
10:56 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 5:47 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
drago01 wrote:
> That's not about kernels, we should move away from a CD atleast for
> x86_64 instead of not shipping useful apps for size reasons (ex:
> OO.org)
OO.o still has no working KDE 4 integration, and we don't even have the KDE
3 integration packaged, so I'm not sure it would be a good idea to put it
on the KDE spin anyway. KOffice 2 is the way to go in the long run.
Even the KDE spin would profit from moving to DVD because its afaik
english only while the Desktop live cd has the translations.
11:22 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 05:12:18PM +0100, drago01 wrote:
On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>> But our live images are already heavily size-constrained. There's definitely
>> no room for multiple kernels on the KDE live image, and I don't think the
>> GNOME image has any room left either.
>
> Was already discussed the requirement of CDs nowadays? Even the oldest
> computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
Well for x86_64 we can/should do this.
Good luck on finding a x86_64 computer/laptop without a DVD drive.
http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/ca...
Note that while a DVD drive is an option, it does not come with one
by default and it costs $225.00 extra. It took me 30 seconds to
find that machine. I'm sure there are more.
josh
11:29 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Jan 31, 2009, at 11:22 AM, Josh Boyer wrote:
On Sat, Jan 31, 2009 at 05:12:18PM +0100, drago01 wrote:
> On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil
> <jan.kratochvil(a)redhat.com> wrote:
>> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>>> But our live images are already heavily size-constrained. There's
>>> definitely
>>> no room for multiple kernels on the KDE live image, and I don't
>>> think the
>>> GNOME image has any room left either.
>>
>> Was already discussed the requirement of CDs nowadays? Even the
>> oldest
>> computers already have DVD and I miss more a fully-featured
>> LiveDVD 5GB spin.
>
> Well for x86_64 we can/should do this.
> Good luck on finding a x86_64 computer/laptop without a DVD drive.
http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/ca...
Note that while a DVD drive is an option, it does not come with one
by default and it costs $225.00 extra. It took me 30 seconds to
find that machine. I'm sure there are more.
I think that is a poor example for this discussion since it doesn't
have a CD option at all. The link is to a laptop with no optical
media. The only media choice is a DVD burner.
joe
11:41 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 11:29:49AM -0600, Joe Nall wrote:
On Jan 31, 2009, at 11:22 AM, Josh Boyer wrote:
> On Sat, Jan 31, 2009 at 05:12:18PM +0100, drago01 wrote:
>> On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil
>> <jan.kratochvil(a)redhat.com> wrote:
>>> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>>>> But our live images are already heavily size-constrained. There's
>>>> definitely
>>>> no room for multiple kernels on the KDE live image, and I don't
>>>> think the
>>>> GNOME image has any room left either.
>>>
>>> Was already discussed the requirement of CDs nowadays? Even the
>>> oldest
>>> computers already have DVD and I miss more a fully-featured
>>> LiveDVD 5GB spin.
>>
>> Well for x86_64 we can/should do this.
>> Good luck on finding a x86_64 computer/laptop without a DVD drive.
>
>
http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/ca...
>
> Note that while a DVD drive is an option, it does not come with one
> by default and it costs $225.00 extra. It took me 30 seconds to
> find that machine. I'm sure there are more.
I think that is a poor example for this discussion since it doesn't have
a CD option at all. The link is to a laptop with no optical media. The
only media choice is a DVD burner.
You can think whatever you like. The assertion was that all x86_64
machines have a CD/DVD drive and that is very much not the case.
josh
11:49 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 6:41 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Sat, Jan 31, 2009 at 11:29:49AM -0600, Joe Nall wrote:
>
> On Jan 31, 2009, at 11:22 AM, Josh Boyer wrote:
>
>> On Sat, Jan 31, 2009 at 05:12:18PM +0100, drago01 wrote:
>>> On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil
>>> <jan.kratochvil(a)redhat.com> wrote:
>>>> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>>>>> But our live images are already heavily size-constrained.
There's
>>>>> definitely
>>>>> no room for multiple kernels on the KDE live image, and I don't
>>>>> think the
>>>>> GNOME image has any room left either.
>>>>
>>>> Was already discussed the requirement of CDs nowadays? Even the
>>>> oldest
>>>> computers already have DVD and I miss more a fully-featured
>>>> LiveDVD 5GB spin.
>>>
>>> Well for x86_64 we can/should do this.
>>> Good luck on finding a x86_64 computer/laptop without a DVD drive.
>>
>>
http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/ca...
>>
>> Note that while a DVD drive is an option, it does not come with one
>> by default and it costs $225.00 extra. It took me 30 seconds to
>> find that machine. I'm sure there are more.
>
> I think that is a poor example for this discussion since it doesn't have
> a CD option at all. The link is to a laptop with no optical media. The
> only media choice is a DVD burner.
You can think whatever you like. The assertion was that all x86_64
machines have a CD/DVD drive and that is very much not the case.
Well lets change this "all x86_64 hardware with optical drives" ...
because it does not matter for such a machine if we use a CD or a DVD.
11:53 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 12:41 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
> I think that is a poor example for this discussion since it
doesn't have
> a CD option at all. The link is to a laptop with no optical media. The
> only media choice is a DVD burner.
You can think whatever you like. The assertion was that all x86_64
machines have a CD/DVD drive and that is very much not the case.
No it wasn't— That was what he *stated*, but its clear from the
context thats not what he intended to assert.
The discussion is regarding switching the LiveCD into a LiveDVD. The
intended assertion is that these systems which had CD support at all
also had DVD support.
Your counter example is no more useful than pointing out some
screenless x86_64 based telephone switch which didn't have a DVD. :)
4:26 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 12:22:19PM -0500, Josh Boyer wrote:
http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/ca...
Note that while a DVD drive is an option, it does not come with one
by default and it costs $225.00 extra. It took me 30 seconds to
find that machine. I'm sure there are more.
8Gb USB stick, which can hold bootable dvd contents, $15. Your turn.
OG.
5:10 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 3:26 PM, Olivier Galibert <galibert(a)pobox.com> wrote:
8Gb USB stick, which can hold bootable dvd contents, $15. Your turn.
So we're leaving the developing world to Ubuntu now?
Not that I necessarily think that's a bad idea; Fedora can't be all
things to all people, and being cutting-edge doesn't always combine so
well with supporting old hardware...
I'm just waiting for a bunch of business-oriented @redhat.com people
to jump in now ;-)
--wes
9 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
I used to have a row image of a hard disk (for qemu) 4.1GB in size
saved on FAT32
we (in ojuba.org) have built a livecd of oo.o based on fedora (gnome)
most of the packages are from fedora except oo.o which I built to cut
off some java features from oo.o to save the size of gcj
and of course it have only one langpack installed
---
my guess that full liveDVD is a bad thing because for installation one
can't select packages
and if a small scratch hit it the entire system can't be installed
while with usual dvd if file-roller*.rpm was damaged you can unselect
it and download it later
--
a good tradeoff might be a liveDVD/USB spin with about 1GB
1:05 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sun, Feb 1, 2009 at 12:10 AM, Wes Shull <wes.shull(a)gmail.com> wrote:
On Sat, Jan 31, 2009 at 3:26 PM, Olivier Galibert
<galibert(a)pobox.com> wrote:
> 8Gb USB stick, which can hold bootable dvd contents, $15. Your turn.
So we're leaving the developing world to Ubuntu now?
They can/have to use the x86 livecd anyway for their older system.
We are talking about moving the x86_64 live spin to a DVD.
8:21 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sunday, February 01 2009, drago01 said:
On Sun, Feb 1, 2009 at 12:10 AM, Wes Shull
<wes.shull(a)gmail.com> wrote:
> On Sat, Jan 31, 2009 at 3:26 PM, Olivier Galibert <galibert(a)pobox.com> wrote:
>
>> 8Gb USB stick, which can hold bootable dvd contents, $15. Your turn.
>
> So we're leaving the developing world to Ubuntu now?
They can/have to use the x86 livecd anyway for their older system.
We are talking about moving the x86_64 live spin to a DVD.
The problem then is that there are more configs to maintain. And in
point of fact, the x86_64 images were larger than CD-sized for a few
releases and there were more than a handful of complaints from people
wanting to use them on x86_64 boxes with only CD drives.
Jeremy
11:09 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Mon, Feb 2, 2009 at 3:21 PM, Jeremy Katz <katzj(a)redhat.com> wrote:
On Sunday, February 01 2009, drago01 said:
> On Sun, Feb 1, 2009 at 12:10 AM, Wes Shull <wes.shull(a)gmail.com> wrote:
> > On Sat, Jan 31, 2009 at 3:26 PM, Olivier Galibert <galibert(a)pobox.com>
wrote:
> >
> >> 8Gb USB stick, which can hold bootable dvd contents, $15. Your turn.
> >
> > So we're leaving the developing world to Ubuntu now?
>
> They can/have to use the x86 livecd anyway for their older system.
> We are talking about moving the x86_64 live spin to a DVD.
The problem then is that there are more configs to maintain.
Sure but how much extra work does this add? We can reuse the same
kickstart files and add/remove packages where it makes sense.
As for testing both need to be tested anyway.
And in
point of fact, the x86_64 images were larger than CD-sized for a few
releases and there were more than a handful of complaints from people
wanting to use them on x86_64 boxes with only CD drives.
Any pointers to those complains ? This shouldn't be an issue for the
majority of x86_64 boxes (and no I don't talk about boxes without
optical drives).
If there are same rare cases with such hardware they still have the
liveusb option if they don't want to buy a dvd drive/burner.
2:10 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Monday, February 02 2009, drago01 said:
On Mon, Feb 2, 2009 at 3:21 PM, Jeremy Katz <katzj(a)redhat.com>
wrote:
> On Sunday, February 01 2009, drago01 said:
>> On Sun, Feb 1, 2009 at 12:10 AM, Wes Shull <wes.shull(a)gmail.com> wrote:
>> > On Sat, Jan 31, 2009 at 3:26 PM, Olivier Galibert
<galibert(a)pobox.com> wrote:
>> >
>> >> 8Gb USB stick, which can hold bootable dvd contents, $15. Your turn.
>> >
>> > So we're leaving the developing world to Ubuntu now?
>>
>> They can/have to use the x86 livecd anyway for their older system.
>> We are talking about moving the x86_64 live spin to a DVD.
>
> The problem then is that there are more configs to maintain.
Sure but how much extra work does this add? We can reuse the same
kickstart files and add/remove packages where it makes sense.
As for testing both need to be tested anyway.
It's a fair bit of extra work because now you have to be thinking about
what to substitute in, what you lose by not going with a specific
package, and a slew of other things. It's not just "add more junk"
because in that case, you'd end up with some duplicates that make the
experience _less_ good
>And in
> point of fact, the x86_64 images were larger than CD-sized for a few
> releases and there were more than a handful of complaints from people
> wanting to use them on x86_64 boxes with only CD drives.
Any pointers to those complains ? This shouldn't be an issue for the
majority of x86_64 boxes (and no I don't talk about boxes without
optical drives).
If there are same rare cases with such hardware they still have the
liveusb option if they don't want to buy a dvd drive/burner.
Go back and read the mailing list and forum archives. I certainly
wasn't the person pushing it (hell, CDs themselves haven't mattered to
me now in a long time), instead, I just was the person that heard all of
the complaints.
And it's not just about DVD *readers*. It's also about relative pricing
of media and scarcity of writers
Jeremy
1:41 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, 2009-01-31 at 17:12 +0100, drago01 wrote:
On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>> But our live images are already heavily size-constrained. There's
definitely
>> no room for multiple kernels on the KDE live image, and I don't think the
>> GNOME image has any room left either.
>
> Was already discussed the requirement of CDs nowadays? Even the oldest
> computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
Well for x86_64 we can/should do this.
Good luck on finding a x86_64 computer/laptop without a DVD drive.
The problem isn't DVD readers, it's DVD writers. I sure don't own any,
and I have two x86-64 machines. I've had enough problems with CDRs being
unreliable, somehow I don't think higher density is going to help any. I
feel my money is better spent on more HDs and flash drives.
11:39 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
Callum Lerwick (seg(a)haxxed.com) said:
> Well for x86_64 we can/should do this.
> Good luck on finding a x86_64 computer/laptop without a DVD drive.
The problem isn't DVD readers, it's DVD writers. I sure don't own any,
and I have two x86-64 machines. I've had enough problems with CDRs being
unreliable, somehow I don't think higher density is going to help any. I
feel my money is better spent on more HDs and flash drives.
But 'flash drives' solves the DVD size isse for you.
Bill
6:07 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Mon, 2009-02-02 at 12:39 -0500, Bill Nottingham wrote:
Callum Lerwick (seg(a)haxxed.com) said:
> > Well for x86_64 we can/should do this.
> > Good luck on finding a x86_64 computer/laptop without a DVD drive.
>
> The problem isn't DVD readers, it's DVD writers. I sure don't own any,
> and I have two x86-64 machines. I've had enough problems with CDRs being
> unreliable, somehow I don't think higher density is going to help any. I
> feel my money is better spent on more HDs and flash drives.
But 'flash drives' solves the DVD size isse for you.
Well, the biggest USB stick I have at the moment is 1gb, but this thread
provided an excuse to order me an 8gb. I'm ready now. :) But keep in
mind the FAT 4gb-1b limit. I'd happily format it NTFS if we could boot
LiveUSB from NTFS. syslinux doesn't support this, but patches for GRUB
apparently exist:
http://www.geocities.com/lode_leroy/grubinstall/
And syslinux upstream is at least open to NTFS support:
http://syslinux.zytor.com/archives/2007-April/008303.html
But I can't find any sign of progress on it.
We're going to need this eventually. As flash drives get bigger, FAT
becomes more and more undesirable.
6:10 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
Callum Lerwick wrote:
Well, the biggest USB stick I have at the moment is 1gb, but this
thread
provided an excuse to order me an 8gb. I'm ready now. :) But keep in
mind the FAT 4gb-1b limit. I'd happily format it NTFS if we could boot
LiveUSB from NTFS. syslinux doesn't support this, but patches for GRUB
apparently exist:
Why not format it ext2/3/4? ;-) That's what I did (and went on to use
the same stick to install Cambridge on my Asus).
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
ELANG: input is in wrong language (please use English on English lists)
1:48 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Thu, Feb 05, 2009 at 18:10:32 -0600,
Matthew Woehlke <mw_triad(a)users.sourceforge.net> wrote:
Callum Lerwick wrote:
> Well, the biggest USB stick I have at the moment is 1gb, but this thread
> provided an excuse to order me an 8gb. I'm ready now. :) But keep in
> mind the FAT 4gb-1b limit. I'd happily format it NTFS if we could boot
> LiveUSB from NTFS. syslinux doesn't support this, but patches for GRUB
> apparently exist:
Why not format it ext2/3/4? ;-) That's what I did (and went on to use
the same stick to install Cambridge on my Asus).
Because then it can't be used to transfer files to and from windows systems
without booting from it.
11 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
Bruno Wolff III wrote:
On Thu, Feb 05, 2009 at 18:10:32 -0600,
Matthew Woehlke <mw_triad(a)nospam.please> wrote:
Ahem. Please do not quote my e-mail address unobfuscated in message bodies.
> Why not format it ext2/3/4? ;-) That's what I did (and went
on to use
> the same stick to install Cambridge on my Asus).
Because then it can't be used to transfer files to and from windows systems
without booting from it.
"windows systems"? What are those? ;-)
(I could also ask why you'd ever want to use such a system /without/
booting it from the stick so that you have a real OS :-), but I concede
that if you have to deal with such, then needing to install a 'doze extX
driver can be annoying.)
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"Let's call it an accidental feature." -- Larry Wall
11:18 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Fri, Feb 06, 2009 at 11:00:34 -0600,
Matthew Woehlke <mw_triad(a)users.sourceforge.net> wrote:
Bruno Wolff III wrote:
> On Thu, Feb 05, 2009 at 18:10:32 -0600,
> Matthew Woehlke <mw_triad(a)nospam.please> wrote:
Ahem. Please do not quote my e-mail address unobfuscated in message bodies.
Right because spammers can't figure out how to undo obfusication. Or subscribe
to the lists. In any case the archives do obfusicate the addresses on the
normal web interface. Though they can pull them out of the gzip'd archives
if they really want to avoid unobfusicating them. If you are really concerned
about this, I suggest using the list address in your from header instead
of your own email address.
>> Why not format it ext2/3/4? ;-) That's what I did (and went on to use
>> the same stick to install Cambridge on my Asus).
>
> Because then it can't be used to transfer files to and from windows systems
> without booting from it.
"windows systems"? What are those? ;-)
(I could also ask why you'd ever want to use such a system /without/
booting it from the stick so that you have a real OS :-), but I concede
that if you have to deal with such, then needing to install a 'doze extX
driver can be annoying.)
It's a useful way to transfer files from machines that aren't owned by me.
Though I normally use a luks encrypted USB drive that I wouldn't enter the
password for on someone else's box no matter what the OS. Eventually I'll
get another one and probably keep one that is for insecure use and then I
might as well use NTFS so I am not as limited in which OS's I can use it
with. And it may have a live OS on it to boot.
3:40 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
Bruno Wolff III wrote:
On Thu, Feb 05, 2009 at 18:10:32 -0600,
Matthew Woehlke <mw_triad(a)users.sourceforge.net> wrote:
> Callum Lerwick wrote:
>> Well, the biggest USB stick I have at the moment is 1gb, but this thread
>> provided an excuse to order me an 8gb. I'm ready now. :) But keep in
>> mind the FAT 4gb-1b limit. I'd happily format it NTFS if we could boot
>> LiveUSB from NTFS. syslinux doesn't support this, but patches for GRUB
>> apparently exist:
> Why not format it ext2/3/4? ;-) That's what I did (and went on to use
> the same stick to install Cambridge on my Asus).
Because then it can't be used to transfer files to and from windows systems
without booting from it.
http://www.fs-driver.org/
Rahul
8:02 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Feb 07, 2009 at 15:10:25 +0530,
Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
Bruno Wolff III wrote:
>
> Because then it can't be used to transfer files to and from windows systems
> without booting from it.
http://www.fs-driver.org/
But you can't count on that being installed and may not be in a position
to install it when you want to copy over files. Similar to not being able
to be able to count on being able to boot off a usb device and have it mount
the Windows system's file systems.
8:04 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
Bruno Wolff III wrote:
On Sat, Feb 07, 2009 at 15:10:25 +0530,
Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
> Bruno Wolff III wrote:
>> Because then it can't be used to transfer files to and from windows systems
>> without booting from it.
> http://www.fs-driver.org/
But you can't count on that being installed and may not be in a position
to install it when you want to copy over files.
Copy the installer into the USB device and install it when you need to.
There are other similar choices even if you don't have administrative
access.
Similar to not being able
to be able to count on being able to boot off a usb device and have
it mount
the Windows system's file systems.
IIRC, ntfs-3g is installed by default.
Rahul
8:12 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Feb 07, 2009 at 19:34:20 +0530,
Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
Copy the installer into the USB device and install it when you need to.
There are other similar choices even if you don't have administrative
access.
Really? It sounds like a security issue if you can install drivers for
mounting file systems without admin rights.
Similar to not being able
> to be able to count on being able to boot off a usb device and have it mount
> the Windows system's file systems.
IIRC, ntfs-3g is installed by default.
I wasn't refering to a driver issue, but having the bios not be able to
boot from usb devices eitehr because they are old computers or because the
bios is locked down. (At work a lot of machines get locked down because
they are physically accessible to the public, attached to our network
and we don't want people to boot their own OS on them and cause problems.)
8:20 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
Bruno Wolff III wrote:
On Sat, Feb 07, 2009 at 19:34:20 +0530,
Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
> Copy the installer into the USB device and install it when you need to.
> There are other similar choices even if you don't have administrative
> access.
Really? It sounds like a security issue if you can install drivers for
mounting file systems without admin rights.
UAC nags you but proceeds without a password in Vista (OEM
installation). Many Windows users constantly run their system as a admin
without a password. Is that a security issue? yes but considering the
number of Linux users who are unhappy when GDM doesn't allow root user
to login, I would suspect end users don't care about security much, if
at all. Shocking, I know but more to the point, if you want say just
read access, you don't need admin rights to install explore2fs ( Was
just a binary you could run without any installation. Long time since I
did that and things might have changed now but worth considering).
If your system doesn't support USB booting, then you do need regular
media or network boot.
Rahul
6:13 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
Callum Lerwick wrote:
We're going to need this eventually. As flash drives get bigger,
FAT
becomes more and more undesirable.
That's what ext2/ext3/ext4 is for.
Kevin Kofler
3:54 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Fri, 2009-02-06 at 01:13 +0100, Kevin Kofler wrote:
Callum Lerwick wrote:
> We're going to need this eventually. As flash drives get bigger, FAT
> becomes more and more undesirable.
That's what ext2/ext3/ext4 is for.
Except that I most often use USB sticks for transfer among Windows
machines, as they need constant reinstalling and don't come with such
niceties as ssh and rsync. And some WinXP does not have network drivers
for out of the box...
Though as USB sticks get bigger I suppose it becomes more practical to
just partition the drive out and put a full Fedora install on it...
6:18 a.m.
New subject: Validity of the CD size limit nowadays
On Fr Februar 6 2009, Kevin Kofler wrote:
Callum Lerwick wrote:
> We're going to need this eventually. As flash drives get bigger, FAT
> becomes more and more undesirable.
That's what ext2/ext3/ext4 is for.
I am not sure about ext4, but with ext{2,3} one will run into permission
problems, if one uses it on several machines with several users that have
different user ids.
Regards,
Till
6:21 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Thu, 2009-02-05 at 18:07 -0600, Callum Lerwick wrote:
Well, the biggest USB stick I have at the moment is 1gb, but this
thread
provided an excuse to order me an 8gb. I'm ready now. :) But keep in
mind the FAT 4gb-1b limit. I'd happily format it NTFS if we could boot
LiveUSB from NTFS.
Be careful:
http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
10:43 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 17:07:28 +0100,
Jan Kratochvil <jan.kratochvil(a)redhat.com> wrote:
On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
> But our live images are already heavily size-constrained. There's definitely
> no room for multiple kernels on the KDE live image, and I don't think the
> GNOME image has any room left either.
Was already discussed the requirement of CDs nowadays? Even the oldest
computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
If you want DVD iso's to be over 4 GiB you should provide comments to
the Spins SIG soon. There are concerns that DVD images over 4 GiB but
less than 4.7 GB (which is what will fit on common DVD types) will cause
problems for people using vfat.
10:45 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
Bruno Wolff III wrote:
If you want DVD iso's to be over 4 GiB you should provide
comments to
the Spins SIG soon. There are concerns that DVD images over 4 GiB but
less than 4.7 GB (which is what will fit on common DVD types) will cause
problems for people using vfat.
The vfat limit is 2 GB, so 4 or 4.7 GB will make no difference for vfat
users, neither will work.
Kevin Kofler
10:50 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 5:45 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Bruno Wolff III wrote:
> If you want DVD iso's to be over 4 GiB you should provide comments to
> the Spins SIG soon. There are concerns that DVD images over 4 GiB but
> less than 4.7 GB (which is what will fit on common DVD types) will cause
> problems for people using vfat.
The vfat limit is 2 GB, so 4 or 4.7 GB will make no difference for vfat
users, neither will work.
File size limit on fat32 is 4GB not 2.
2:48 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 9:36 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
drago01 wrote:
> File size limit on fat32 is 4GB not 2.
Then try saving a file with more than 2 GB with Window$ Me...
I never tried that but I did store 3GB+ files on external FAT32
formatted media with both winXP and linux.
A 2GB limit would rather mean that the app you used does not support
LFS (and therefore is limited to 2GB files).
But the filesystem FAT32 has a 4GB filesysize limit ( 4GB - 1 byte to be exact).
"The maximum possible size for a file on a FAT32 volume is 4 GiB minus
1 byte (2^32-1 bytes)" [1]
1: http://en.wikipedia.org/wiki/FAT_32#FAT32
1:49 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, 2009-01-31 at 21:36 +0100, Kevin Kofler wrote:
drago01 wrote:
> File size limit on fat32 is 4GB not 2.
Then try saving a file with more than 2 GB with Window$ Me...
Do we really care about Win9x? WinME was EOLed 2.5 years ago. Let it
die. Microsoft already has.
10:46 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 5:43 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Sat, Jan 31, 2009 at 17:07:28 +0100,
Jan Kratochvil <jan.kratochvil(a)redhat.com> wrote:
> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
> > But our live images are already heavily size-constrained. There's
definitely
> > no room for multiple kernels on the KDE live image, and I don't think the
> > GNOME image has any room left either.
>
> Was already discussed the requirement of CDs nowadays? Even the oldest
> computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
If you want DVD iso's to be over 4 GiB you should provide comments to
the Spins SIG soon. There are concerns that DVD images over 4 GiB but
less than 4.7 GB (which is what will fit on common DVD types) will cause
problems for people using vfat.
Well the point is not the size of the DVD image itself but having a
liveDVD instead of a liveCD (going away from the 700MB size limit)
12:17 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 11:46 AM, drago01 <drago01(a)gmail.com> wrote:
Well the point is not the size of the DVD image itself but having a
liveDVD instead of a liveCD (going away from the 700MB size limit)
Keep in mind that the same spin for all arches is produced using the
same kickstart (i.e. fedora-livecd-desktop.ks). So the technical
feasibility of keeping a LiveCD for x86 and DVD for x86_64 is nearly
nil, unless we broke up the kickstarts (which I for one am not in
favor of).
2:18 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 7:17 PM, Jon Stanley <jonstanley(a)gmail.com> wrote:
On Sat, Jan 31, 2009 at 11:46 AM, drago01 <drago01(a)gmail.com>
wrote:
> Well the point is not the size of the DVD image itself but having a
> liveDVD instead of a liveCD (going away from the 700MB size limit)
Keep in mind that the same spin for all arches is produced using the
same kickstart (i.e. fedora-livecd-desktop.ks). So the technical
feasibility of keeping a LiveCD for x86 and DVD for x86_64 is nearly
nil, unless we broke up the kickstarts (which I for one am not in
favor of).
I am aware of that, but as both need to be tested anyway that should
not be really a blocker.
Instead of just discussion this every 2nd release[1] (same as the boot
time thread [2] that shows up at the beginning of each rawhide cycle),
we should decide whether we[3] want this, and then go on implementing
this.
1: it just feels like this so don't come up with "but there was no
such thread for fedora n"
2: and ends up into a do we need a MTA started by default flamewar
(but that's a different topic)
3: now who is "we" ... FESCO, rel-eng ? Who is app to make this decision ?
8:23 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Saturday, January 31 2009, drago01 said:
3: now who is "we" ... FESCO, rel-eng ? Who is app to make
this decision ?
The last time a "we will ship CDs" decision was made, it was made by the
Board so I think that's probably the precedent.
Jeremy
11:19 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Mon, Feb 2, 2009 at 3:23 PM, Jeremy Katz <katzj(a)redhat.com> wrote:
On Saturday, January 31 2009, drago01 said:
> 3: now who is "we" ... FESCO, rel-eng ? Who is app to make this decision ?
The last time a "we will ship CDs" decision was made, it was made by the
Board so I think that's probably the precedent.
The former Board decision was about supporting CDs at all, now we want
to move to a DVD for _modern_ hardware and stick with CDs for the
older ones (that would not be able to use the x86_64 image anyway even
if it where CD sized)
1:45 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 05:07:28PM +0100, Jan Kratochvil wrote:
Was already discussed the requirement of CDs nowadays? Even the
oldest
computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
On $SUBJECT don't forget virtualization and .iso files. I use the ISO
format as a (somewhat inconvenient) way to boot virtual machines, and
probably less than 1 in 10 of those ISOs that I download get burned
onto any physical object.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
12:48 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sat, Jan 31, 2009 at 11:07 AM, Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
> But our live images are already heavily size-constrained. There's definitely
> no room for multiple kernels on the KDE live image, and I don't think the
> GNOME image has any room left either.
Was already discussed the requirement of CDs nowadays? Even the oldest
computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
From the desktop perspective I like having something around CD size
since it keeps us focused, in terms of:
* Even if someone can burn a DVD, it's a lot to download; keep in mind
not everyone has fast Internet
* Having higher quality software percentage wise
* Not losing focus into developer tools, scientific analysis, creative
tools, 3D games etc. The desktop image is a desktop core.
* Encouraging us to reduce technology duplication in that core set
The fact that it can be burned to a physical CD is a bonus.
11:03 a.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
On Sun, Feb 1, 2009 at 7:48 PM, Colin Walters <walters(a)verbum.org> wrote:
On Sat, Jan 31, 2009 at 11:07 AM, Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>> But our live images are already heavily size-constrained. There's definitely
>> no room for multiple kernels on the KDE live image, and I don't think the
>> GNOME image has any room left either.
>
> Was already discussed the requirement of CDs nowadays? Even the oldest
> computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
>From the desktop perspective I like having something around CD size
since it keeps us focused, in terms of:
* Even if someone can burn a DVD, it's a lot to download; keep in mind
not everyone has fast Internet
* Having higher quality software percentage wise
* Not losing focus into developer tools, scientific analysis, creative
tools, 3D games etc. The desktop image is a desktop core.
* Encouraging us to reduce technology duplication in that core set
That's the job of the spin maintainer to not include everything under
the sun just because it fits on the media.
(i.e only add apps that are useful for your spins target audience)
The fact that it can be burned to a physical CD is a bonus.
Well the x86_64 images was sightly bigger than a CD anyway, so the
only bonus is the download size, but again only because it can be up
to 4.7GB size does not mean it has to use all this space.
12:53 p.m.
New subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for]
Jan Kratochvil wrote:
On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
> But our live images are already heavily size-constrained. There's definitely
> no room for multiple kernels on the KDE live image, and I don't think the
> GNOME image has any room left either.
Was already discussed the requirement of CDs nowadays? Even the oldest
computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
Maybe not if you are in a developing economy.
Where your PC is a >=P1 | >=P3
and it came with a CD.
Even it the developed world.
You have an old box to put XFCE\LXDe on,
why would you want a DVD install,
when a slim CD would do?
There are arguments for both cd and dvd.
Frank
4:29 p.m.
On Friday 30 January 2009, Bill Nottingham wrote:
Kevin Fenzi (kevin(a)scrye.com) said, in the FESCo meeting summary:
> * Architecture Support
> https://fedoraproject.org/wiki/Features/ArchitectureSupport
* 32-bit x86 would be built for i686 by default. 586-compatible
processors
would no longer be supported.
[...]
* i386: -march=i586 -mtune=generic
Should the latter be -march=i686?
6:31 p.m.
Ville Skyttä wrote:
On Friday 30 January 2009, Bill Nottingham wrote:
> Kevin Fenzi (kevin(a)scrye.com) said, in the FESCo meeting summary:
>> * Architecture Support
>> https://fedoraproject.org/wiki/Features/ArchitectureSupport
> * 32-bit x86 would be built for i686 by default. 586-compatible processors
> would no longer be supported.
[...]
> * i386: -march=i586 -mtune=generic
Should the latter be -march=i686?
I was wondering this too but in the opposite direction -- why build
everything for i686 by default if we're only updating the compiler flags
to i586?
Jakub's email sparking this Feature listed the major benefit from
getting new instructions with -march=i486. He then listed additional
helpful instructions when using -march=i586. Nothing listed for
-march=i686.
-Toshio
11:41 a.m.
Toshio Kuratomi (a.badger(a)gmail.com) said:
>> * 32-bit x86 would be built for i686 by default.
586-compatible processors
>> would no longer be supported.
> [...]
>> * i386: -march=i586 -mtune=generic
>
> Should the latter be -march=i686?
>
I was wondering this too but in the opposite direction -- why build
everything for i686 by default if we're only updating the compiler flags
to i586?
Jakub's email sparking this Feature listed the major benefit from
getting new instructions with -march=i486. He then listed additional
helpful instructions when using -march=i586. Nothing listed for
-march=i686.
The idea is that RPMs are built for i686, ergo, they will get
-march=i686 explicitly passed to the compiler. The default compiler
flags for 32-bit will be -march=i586, which will allow people to
build i586-compatible code if they so desire.
Bill
5:09 p.m.
On Friday, 30 January 2009 at 21:35, Bill Nottingham wrote:
Kevin Fenzi (kevin(a)scrye.com) said, in the FESCo meeting summary:
> * Architecture Support
> https://fedoraproject.org/wiki/Features/ArchitectureSupport
>
> FESCo tabled this to revisit this next week. There were questions
> about OLPC support and LSTP client machines. Discussion to continue
> on fedora-devel list.
As a followup to the discussion on compiler flags, this feature was
written up to describe a plan for what to do overall about what
architectures we support. The main points are:
- install x86_64 kernel on 32-bit OS where appropriate
- install PAE kernel on other 32-bit OS installs where appropriate
- build only i686 and above for Fedora
There's going to be some screaming from VIA C3 and AMD K6 users about this.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:25 p.m.
On Friday 30 January 2009 03:09:00 pm Dominik 'Rathann' Mierzejewski wrote:
On Friday, 30 January 2009 at 21:35, Bill Nottingham wrote:
> Kevin Fenzi (kevin(a)scrye.com) said, in the FESCo meeting summary:
> > * Architecture Support
> > https://fedoraproject.org/wiki/Features/ArchitectureSupport
> >
> > FESCo tabled this to revisit this next week. There were questions
> > about OLPC support and LSTP client machines. Discussion to continue
> > on fedora-devel list.
>
> As a followup to the discussion on compiler flags, this feature was
> written up to describe a plan for what to do overall about what
> architectures we support. The main points are:
>
> - install x86_64 kernel on 32-bit OS where appropriate
> - install PAE kernel on other 32-bit OS installs where appropriate
> - build only i686 and above for Fedora
There's going to be some screaming from VIA C3 and AMD K6 users about this.
Regards,
R.
Also breaks support for original pentium (i586) CPUs. My router will be
perpetually stuck at Fedora 10, I guess.
Regards,
--
Conrad Meyer <konrad(a)tylerc.org>
11:44 a.m.
Conrad Meyer (konrad(a)tylerc.org) said:
On Friday 30 January 2009 03:09:00 pm Dominik 'Rathann'
Mierzejewski wrote:
> There's going to be some screaming from VIA C3 and AMD K6 users about this.
Also breaks support for original pentium (i586) CPUs. My router will be
perpetually stuck at Fedora 10, I guess.
Correct. However, by the only statistics we have available, that's
an amazingly small percantage of our userbase (.04%, to be precise.)
Bill
12:06 p.m.
>>>> "BN" == Bill Nottingham
<notting(a)redhat.com> writes:
BN> Correct. However, by the only statistics we have available, that's
BN> an amazingly small percantage of our userbase (.04%, to be
BN> precise.)
I can't help but point out that it's disingenuous to continue to quote
that figure when it's already been stated that the main use of such
systems is in a situation where smolt will never be run.
- J<
12:42 p.m.
Jason L Tibbitts III (tibbs(a)math.uh.edu) said:
BN> Correct. However, by the only statistics we have available,
that's
BN> an amazingly small percantage of our userbase (.04%, to be
BN> precise.)
I can't help but point out that it's disingenuous to continue to quote
that figure when it's already been stated that the main use of such
systems is in a situation where smolt will never be run.
Please re-read. "the only statistics we have available". If you've
got better ones, please share.
Bill
1:03 p.m.
>>>> "BN" == Bill Nottingham
<notting(a)redhat.com> writes:
BN> Please re-read.
No need.
BN> "the only statistics we have available".
"are flawed". Don't quote them at all if you know they aren't
correct. That's my only point here.
BN> If you've got better ones, please share.
You know I don't. You also know that my not having any doesn't have
any bearing at all on the fact that you shouldn't be quoting
statistics you know to be incorrect.
- J<
1:08 p.m.
Jason L Tibbitts III (tibbs(a)math.uh.edu) said:
BN> "the only statistics we have available".
"are flawed". Don't quote them at all if you know they aren't
correct. That's my only point here.
Best available. The only statement to the otherwise is unsubstantiated
by any statistics, so it very well could be off just by a factor of two,
which still makes the number pretty insignificant. Unless you say
that our one statistic is flawed, so we should just give in to hearsay
everywhere?
Also, the usage cases that Warren stated *are not the usage cases
mentioned that I was responding to*, anyway.
Bill
1:17 p.m.
On Mon, Feb 2, 2009 at 2:03 PM, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
>>>>> "BN" == Bill Nottingham
<notting(a)redhat.com> writes:
BN> Please re-read.
No need.
BN> "the only statistics we have available".
"are flawed". Don't quote them at all if you know they aren't
correct. That's my only point here.
BN> If you've got better ones, please share.
You know I don't. You also know that my not having any doesn't have
any bearing at all on the fact that you shouldn't be quoting
statistics you know to be incorrect.
With x86_64 (hopefully) covering the majority of the modern systems
what is the harm in leaving x86 i586 compatible?
Isn't the only difference in arch=i686 as far as userspace is
concerned cmov? It seems that some people question the general
usefulness of cmov:
http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus
"Pentium or better" is a nice understandable break point. "Pentium pro
or better" far less so. Fedora already has an offering for the high
end (x86_64; which also implies many other performance improving
differences)…
8:06 p.m.
"Pentium Pro or better" is pretty reasonable. AFAICT, if I look really hard,
the earliest PC I can buy around here is the first generation Pentium II
(pre MMX). Most OSes do not support the i586 arch unless it's specifically
geared towards older PCs or firewall distros. Linux mainstream distros seem
to be unusually keen on remaining utterly backwards compatible as far as
CPUs go. I personally think going that far back is unreasonable if it isn't
explicitly stated in the goals of the project itself. For example, Damn
Small Linux can remain arched at i386/i486, because its goal is to run on
older machines as well as newer ones. Ubuntu or Fedora don't really have any
business running on older machines, but Ubuntu is exempt because of their
shared base with Xubuntu, which IS aimed for older machines. OpenSUSE Linux
(how I despise thee *hisses*) runs primarily on i586 arch, with the
exception of the kernel and a few other packages; however, in practice it
doesn't run on a Pentium I. Honestly, I think Fedora needs to stop
bottlenecking its performance by not optimizing its code for i586 or i686. I
would prefer the code to be optimized to i686 when built as RPMs.
On Mon, Feb 2, 2009 at 1:17 PM, Gregory Maxwell <gmaxwell(a)gmail.com> wrote:
On Mon, Feb 2, 2009 at 2:03 PM, Jason L Tibbitts III
<tibbs(a)math.uh.edu>
wrote:
>>>>>> "BN" == Bill Nottingham <notting(a)redhat.com>
writes:
>
> BN> Please re-read.
>
> No need.
>
> BN> "the only statistics we have available".
>
> "are flawed". Don't quote them at all if you know they aren't
> correct. That's my only point here.
>
> BN> If you've got better ones, please share.
>
> You know I don't. You also know that my not having any doesn't have
> any bearing at all on the fact that you shouldn't be quoting
> statistics you know to be incorrect.
With x86_64 (hopefully) covering the majority of the modern systems
what is the harm in leaving x86 i586 compatible?
Isn't the only difference in arch=i686 as far as userspace is
concerned cmov? It seems that some people question the general
usefulness of cmov:
http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus
"Pentium or better" is a nice understandable break point. "Pentium pro
or better" far less so. Fedora already has an offering for the high
end (x86_64; which also implies many other performance improving
differences)…
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
12:01 a.m.
2009/2/2 King InuYasha <ngompa13(a)gmail.com>:
[snip]
Honestly, I think Fedora needs to stop
bottlenecking its performance by not optimizing its code for i586 or i686. I
would prefer the code to be optimized to i686 when built as RPMs.
-march != -mtune. The code is already tuned for more modern CPUs.
Allow me to repeat this: (loudly, not to be mean but because people
seem to miss it) FEDORA x86 IS ALREADY OPTIMIZED FOR MODERN CPUS.
mtune should result in the overwhelming majority of the performance
difference with none of the compatibility issues. -march=i686 adds a
single instruction of disputable value, cmov. In exchange for getting
this one additional instruction it breaks compatibility with pentium,
VIA C3 (Nehemiah has cmov, but eden does not; I have an eden600 board
here which is only ~3 years old!) , AMD K6, etc and potential
performance problems on Pentium 4.
Do you have benchmarks that show given a constant -mtune that
-march=i686 makes a material difference for any significant userspace
apps vs -march=i586, if not why are you being so insistent and
damning of the current compatible behavior?
We know that -march=i686 will break compatibility for a small but
measurable number of users (and potentially a larger unmeasurable
number), do we know if we'll even get a measurable gain in exchange?
We would see much more substantial gains from things like -msse2 &
fpmath=sse but, unfortunately, unlike i586 there are a *lot* of
systems out there (and still being sold) which do not have all the
fancy instruction set extensions.
Repeating myself here… When it comes down to it, we already have a
"performance compiled" distribution: x86_64 which has every i686 knob
turned on and then some. If you care about whatever really minute gain
you'd get out of arch=i686, then you really should be looking for an
x86_64 system. (The higher end atoms are quite attractive I hear…)
7:32 a.m.
On Tuesday, 03 February 2009 at 07:01, Gregory Maxwell wrote:
2009/2/2 King InuYasha <ngompa13(a)gmail.com>:
[snip]
> Honestly, I think Fedora needs to stop
> bottlenecking its performance by not optimizing its code for i586 or i686. I
> would prefer the code to be optimized to i686 when built as RPMs.
-march != -mtune. The code is already tuned for more modern CPUs.
Allow me to repeat this: (loudly, not to be mean but because people
seem to miss it) FEDORA x86 IS ALREADY OPTIMIZED FOR MODERN CPUS.
mtune should result in the overwhelming majority of the performance
difference with none of the compatibility issues. -march=i686 adds a
single instruction of disputable value, cmov.
It is not of disputable value. While FFmpeg is not part of Fedora (it's
in RPMFusion), its H.264 decoder uses cmov to gain measurable speed
increase in decoding.
In exchange for getting
this one additional instruction it breaks compatibility with pentium,
VIA C3 (Nehemiah has cmov, but eden does not; I have an eden600 board
here which is only ~3 years old!) , AMD K6, etc and potential
performance problems on Pentium 4.
Pentium 4 is one big performance problem. Nothing optimized (-mtune)
for P4 will run efficiently on everything else. IMHO we shouldn't care
too much for P4, because doing so will be at the cost of everyone else.
Do you have benchmarks that show given a constant -mtune that
-march=i686 makes a material difference for any significant userspace
apps vs -march=i586, if not why are you being so insistent and
damning of the current compatible behavior?
Which applications do you suggest for testing this hypothesis?
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:44 a.m.
On Tue, Feb 3, 2009 at 8:32 AM, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
> Do you have benchmarks that show given a constant -mtune that
> -march=i686 makes a material difference for any significant userspace
> apps vs -march=i586, if not why are you being so insistent and
> damning of the current compatible behavior?
Which applications do you suggest for testing this hypothesis?
Most easily measured things (rsvg rendering, freetype) probably aren't
ever performance critical for typical users. I think the codec idea
is good both on the 'likely to benefit from cmov' perspective as well
as 'performance actually matters' perspective, but it ought to be
things the Fedora ships. Although, for video the video driver (and
hardware YUV->RGB) is probably more important than codec speed.
Ideally the test ought to be done on something modern that can't do
x86_64 (low end atom perhaps), since if you're on x86_64 you ought to
be using the x86_64 distro or suffering whatever performance you don't
get... but I don't have anything x86 handy.
So, libtheora decoding HD video.
libTheora-i586 5.872
libTheora-i686 5.86
libTheora-x86_64 5.643
libTheora-i586(no asm) 9.396
libTheora-i686(no asm) 9.142
libTheora-x86_64(no asm) 8.04
So, we learn— If you want performance for codecs use hand coded
assembly or at least x86_64. :)
For the with assembly version the improvement is 0.2%, without asm, 2.7%.
I'm a bit disappointed: This hasn't shown a real world improvement
(0.2% isn't helpful), but it suggests that one might be possible for
some other application.
Can someone suggest something else which is performance relevant for many users?
---Method disclosure---
Video is http://community.elphel.com/videos/1920x1072_24FPS.ogg
[gmaxwell@sonolumen libtheora-1.0]$ CFLAGS='-m32 -march=i586
-mtune=core2' ./configure --target=i586 ; make clean ; make -j5
[gmaxwell@sonolumen examples]$ (for i in `seq 1 10` ; do (time -p
./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ;
done ) | awk '{sum+=$2} END { print sum/NR}'
5.872
[gmaxwell@sonolumen libtheora-1.0]$ CFLAGS='-m32 -march=i686
-mtune=core2' ./configure --target=i686 ; make clean ; make -j5
[gmaxwell@sonolumen examples]$ (for i in `seq 1 10` ; do (time -p
./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ;
done ) | awk '{sum+=$2} END { print sum/NR}'
5.86
[gmaxwell@sonolumen libtheora-1.0]$ CFLAGS='-m32 -march=i686
-mtune=core2' ./configure --disable-asm ; make clean ; make -j5
[gmaxwell@sonolumen examples]$ (for i in `seq 1 10` ; do (time -p
./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ;
done ) | awk '{sum+=$2} END { print sum/NR}'
9.142
[gmaxwell@sonolumen libtheora-1.0]$ CFLAGS='-m32 -march=i586
-mtune=core2' ./configure --disable-asm ; make clean ; make -j5
[gmaxwell@sonolumen examples]$ (for i in seq 1 10 ; do (time -p
./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ;
done ) | awk '{sum+=$2} END { print sum/NR}'
9.396
[gmaxwell@sonolumen libtheora-1.0]$ CFLAGS='-mtune=core2' ./configure
--disable-asm ; make clean ; make -j5
[gmaxwell@sonolumen examples]$ (for i in `seq 1 10` ; do (time -p
./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ;
done ) | awk '{sum+=$2} END { print sum/NR}'
8.04
[gmaxwell@sonolumen libtheora-1.0]$ CFLAGS='-mtune=core2' ./configure
; make clean ; make -j5
[gmaxwell@sonolumen examples]$ (for i in `seq 1 10` ; do (time -p
./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ;
done ) | awk '{sum+=$2} END { print sum/NR}'
5.643
1:27 p.m.
On Tue, 2009-02-03 at 19:29 +0100, Nicolas Mailhot wrote:
Le mardi 03 février 2009 à 11:44 -0500, Gregory Maxwell a écrit :
> Most easily measured things (rsvg rendering, freetype) probably aren't
> ever performance critical for typical users.
You're very wrong about any codepath used to display text
+1, c'mon, outline font rasterization is the slowest thing a modern GUI
does, and it's doing it constantly. Everything else, such as line draws,
area fill, and blitting are accelerated to hell and back on pretty much
every video card made since 1993, thus I would bet on freetype being the
*most* performance critical bit of software in the GUI rendering
pipeline. (Can't do much about hardware speed other than buy better
hardware...)
SVG is also slow, but also not quite as common. Bitmaps (PNG, JPG) still
seem to dominate.
(And yes, font bitmaps are cached so it's not rasterizing every time
text is drawn, but still, my bet is on it being the biggest target for
optimization.)
2:29 p.m.
On Tue, 2009-02-03 at 01:01 -0500, Gregory Maxwell wrote:
We would see much more substantial gains from things like -msse2
&
fpmath=sse but, unfortunately, unlike i586 there are a *lot* of
systems out there (and still being sold) which do not have all the
fancy instruction set extensions.
I've found -mfpmath=sse to actually be slightly slower than x87. GCC
just isn't very good at SSE yet, but people have been tuning its x87
output for decades now.
And at this point, all really performance critical bits of code I've
ever seen, are already using runtime selection of hand-tuned SSE/MMX/etc
inner loops. This is absolutely key. There's little gain to be had from
diddling with GCC's instruction set usage because most performance
critical software is already using hand-tuned assembly in their hotpaths
on CPUs that support them.
Going -O3 rather than -O2 is going to make a bigger difference than
anything else. If you want to improve performance, you need to run
profiles, locate performance critical bits of code, figure out if -O3 is
beneficial, and/or write some hand tuned assembly/intrinsic code.
Not to mention, the biggest performance problem on modern processors is
memory. Minimizing cache thrashing is way more important than what
instructions you use. Optimize data structures before code.
Repeating myself here… When it comes down to it, we already have a
"performance compiled" distribution: x86_64 which has every i686 knob
turned on and then some. If you care about whatever really minute gain
you'd get out of arch=i686, then you really should be looking for an
x86_64 system. (The higher end atoms are quite attractive I hear…)
Yes, most new hardware has been 64-bit capable for years now. There's
little reason to cut off i586 users, when x86-64 already provides a
convenient cutoff point.
My advice as an amateur optimization specialist: Don't bother with
-march=i686, there's just not enough gain over i586 vs the cost.
And actually I find -march=i586 questionable, is the one additional
instruction something GCC is ever going to use on its own? But i486 is
so ancient I'm not going to cry if we dump it. :)
2:41 p.m.
2009/2/3 Callum Lerwick <seg(a)haxxed.com>:
On Tue, 2009-02-03 at 01:01 -0500, Gregory Maxwell wrote:
> We would see much more substantial gains from things like -msse2 &
> fpmath=sse but, unfortunately, unlike i586 there are a *lot* of
> systems out there (and still being sold) which do not have all the
> fancy instruction set extensions.
I've found -mfpmath=sse to actually be slightly slower than x87. GCC
just isn't very good at SSE yet, but people have been tuning its x87
output for decades now.
And at this point, all really performance critical bits of code I've
ever seen, are already using runtime selection of hand-tuned SSE/MMX/etc
inner loops. This is absolutely key. There's little gain to be had from
diddling with GCC's instruction set usage because most performance
critical software is already using hand-tuned assembly in their hotpaths
on CPUs that support them.
Speaking of, it's worth mentioning liboil:
http://liboil.freedesktop.org/wiki/
8 a.m.
Callum Lerwick wrote:
Going -O3 rather than -O2 is going to make a bigger difference than
anything else. If you want to improve performance, you need to run
profiles, locate performance critical bits of code, figure out if -O3 is
beneficial, and/or write some hand tuned assembly/intrinsic code.
Not to mention, the biggest performance problem on modern processors is
memory. Minimizing cache thrashing is way more important than what
instructions you use. Optimize data structures before code.
That's actually an argument for investigating -Os, not -O3.
Kevin Kofler
11:15 a.m.
On Wed, 2009-02-04 at 15:00 +0100, Kevin Kofler wrote:
Callum Lerwick wrote:
> Going -O3 rather than -O2 is going to make a bigger difference than
> anything else. If you want to improve performance, you need to run
> profiles, locate performance critical bits of code, figure out if -O3 is
> beneficial, and/or write some hand tuned assembly/intrinsic code.
>
> Not to mention, the biggest performance problem on modern processors is
> memory. Minimizing cache thrashing is way more important than what
> instructions you use. Optimize data structures before code.
That's actually an argument for investigating -Os, not -O3.
I don't think code size is what's making Firefox eat up 1gb RAM. But
defaulting to -Os, and using -O2/-O3 on "hot" libraries and such might
not be a bad idea.
It's the most basic rule of optimization. 90% of your runtime is in %10
of the code. Optimize that %10 of the code, and forget the rest. It's
wasted effort.
http://en.wikipedia.org/wiki/Amdahl's_law
2:20 p.m.
On Wednesday 04 February 2009 09:15:47 am Callum Lerwick wrote:
On Wed, 2009-02-04 at 15:00 +0100, Kevin Kofler wrote:
> Callum Lerwick wrote:
> > Going -O3 rather than -O2 is going to make a bigger difference than
> > anything else. If you want to improve performance, you need to run
> > profiles, locate performance critical bits of code, figure out if -O3
> > is beneficial, and/or write some hand tuned assembly/intrinsic code.
> >
> > Not to mention, the biggest performance problem on modern processors is
> > memory. Minimizing cache thrashing is way more important than what
> > instructions you use. Optimize data structures before code.
>
> That's actually an argument for investigating -Os, not -O3.
I don't think code size is what's making Firefox eat up 1gb RAM.
Nor is Firefox's 1GB of ram causing cache thrashing...
--
Conrad Meyer <konrad(a)tylerc.org>
6:18 a.m.
On Wed, 2009-02-04 at 12:20 -0800, Conrad Meyer wrote:
On Wednesday 04 February 2009 09:15:47 am Callum Lerwick wrote:
> On Wed, 2009-02-04 at 15:00 +0100, Kevin Kofler wrote:
> > Callum Lerwick wrote:
> > > Going -O3 rather than -O2 is going to make a bigger difference than
> > > anything else. If you want to improve performance, you need to run
> > > profiles, locate performance critical bits of code, figure out if -O3
> > > is beneficial, and/or write some hand tuned assembly/intrinsic code.
> > >
> > > Not to mention, the biggest performance problem on modern processors is
> > > memory. Minimizing cache thrashing is way more important than what
> > > instructions you use. Optimize data structures before code.
> >
> > That's actually an argument for investigating -Os, not -O3.
There's two caches, instruction cache and data cache. -Os optimizes the
icache footprint, but the icache is rarely the problem. The problem is
the dcache.
The two are getting confused here.
> I don't think code size is what's making Firefox eat up
1gb RAM.
Nor is Firefox's 1GB of ram causing cache thrashing...
You don't think a bigger RAM footprint directly corresponds to a bigger
cache footprint? The bigger the dataset, the more dcache misses you're
going to see. The more RAM you eat, the less is available for the kernel
to use for block cache. And of course swapping will render all your
hours spent tweaking data structures and squeezing every last
instruction out of your inner loops quite moot.
The optimization priority list goes like this:
1) Minimize macro-level memory usage. Less overall memory usage, the
better. Less swapping, more RAM available for disk cache, less upgrade
treadmill. Everyone wins, big and small, from OLPC on up to 32-core Xeon
godbox.
2) Optimize cache usage. Minimize cache thrashing. You can't even
measure if your cycle shaving is doing anything at all if your memory
access patterns aren't reasonably optimal.
3) Only then do you optimize instruction usage.
3:30 p.m.
Here are some numbers(attached) using nbench (run on a core 2 duo
T7400 with 4MB L2 Cache).
To summarize the results:
i686 vs i586 does add +2% performance
going to x86_64 you gain +10 % (or 9.1% from i686)
from -O2 to -O3 there is a 4.9% performance win on x86_64 and 3.7%*
(more than i686 vs i586) on x86.
So instead of changing arch and breaking compatibility we should
switch from -O2 to -O3
* tested with -march=i686 can rerun with -march=i586 if needed.
-Os is also included.
4:27 p.m.
drago01 wrote:
So instead of changing arch and breaking compatibility we should
switch from -O2 to -O3
But several upstreams say they tried and it didn't change anything or even
made things worse. And it'll be consuming more memory, both RAM and disk
space. I'm not convinced it is a good idea.
Kevin Kofler
4:47 p.m.
On Thu, Feb 5, 2009 at 1:27 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
But several upstreams say they tried and it didn't change
anything or even
made things worse. And it'll be consuming more memory, both RAM and disk
space. I'm not convinced it is a good idea.
Can you distill that down into a set of prioritized benchmarks. If
someone were going to play around with optimization switches. What are
the minimum matrix of obtainable benchmarks that such an effort would
have to meet in order to be considered a credible test?
-jef
4:04 p.m.
Kevin Kofler wrote:
Callum Lerwick wrote:
> Going -O3 rather than -O2 is going to make a bigger difference than
> anything else. If you want to improve performance, you need to run
> profiles, locate performance critical bits of code, figure out if -O3 is
> beneficial, and/or write some hand tuned assembly/intrinsic code.
>
> Not to mention, the biggest performance problem on modern processors is
> memory. Minimizing cache thrashing is way more important than what
> instructions you use. Optimize data structures before code.
That's actually an argument for investigating -Os, not -O3.
Kevin Kofler
In 2004 there were some experiments performed by some NCSU students on the
effect of -Os on code size and performance:
people.redhat.com/wcohen/ncsu2004/Space%20Optimizations.pdf
There was some minor reductions in cache misses, major page faults, and startup
times for the mozilla application.
-Will
5:18 p.m.
On Fri, 30 Jan 2009 21:35:05 +0100, Bill Nottingham wrote:
Kevin Fenzi (kevin(a)scrye.com) said, in the FESCo meeting summary:
> * Architecture Support
> https://fedoraproject.org/wiki/Features/ArchitectureSupport
[...]
- install x86_64 kernel on 32-bit OS where appropriate
Could you please provide more public background for this FESCo decision?
Particularly why not to automatically install the whole x86_64 distro where
appropriate? The DVD media should contain both arches as in the real world
found out the users are not aware if they have 64bit-capable hardware.
x86_64 provides CPU instruction set + ABI improvements which usually overcome
its only performance disadvantage of larger addresses, some benchmarks at:
http://www.amd64.org/fileadmin/user_upload/pub/64bit_Linux-Myths_and_Fact...
Guessing some software (codecs?) may fallback on 64-bit to unoptimized C code
instead of some assembly one but Fedora would at least show the usefulness of
the updates of such software for the x86_64 arch.
Regards,
Jan
5:47 p.m.
On Sat, Jan 31, 2009 at 12:18:47AM +0100, Jan Kratochvil wrote:
On Fri, 30 Jan 2009 21:35:05 +0100, Bill Nottingham wrote:
> Kevin Fenzi (kevin(a)scrye.com) said, in the FESCo meeting summary:
> > * Architecture Support
> > https://fedoraproject.org/wiki/Features/ArchitectureSupport
[...]
> - install x86_64 kernel on 32-bit OS where appropriate
Could you please provide more public background for this FESCo decision?
It isn't a FESCo decision. It is still being discussed. See the meeting
minutes for the FESCo meeting where we delayed voting on this until next
week.
josh
6:47 p.m.
On Fri, Jan 30, 2009 at 6:18 PM, Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
[snip]
Guessing some software (codecs?) may fallback on 64-bit to
unoptimized C code
instead of some assembly one but Fedora would at least show the usefulness of
the updates of such software for the x86_64 arch.
Try GLIBC: For example, x86_64 exp() (and expf()) is *much* slower
than x86. (At least as of my testing in Fedora 9, I haven't measured
F10… the point being that these differences can lurk in unexpected
places.
They need to be fixed in anycase, but useful to keep in mind.
7:58 p.m.
On Fri, 2009-01-30 at 19:47 -0500, Gregory Maxwell wrote:
On Fri, Jan 30, 2009 at 6:18 PM, Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
[snip]
> Guessing some software (codecs?) may fallback on 64-bit to unoptimized C code
> instead of some assembly one but Fedora would at least show the usefulness of
> the updates of such software for the x86_64 arch.
Try GLIBC: For example, x86_64 exp() (and expf()) is *much* slower
than x86. (At least as of my testing in Fedora 9, I haven't measured
F10… the point being that these differences can lurk in unexpected
places.
Last I checked, gcc was unable to translate libm calls into nice inline
instructions on x86_64 like it can on i386, as it's apparently only
implemented for x87 and not SSE. x86-64 ends up with function calls
inside inner loops instead of an instruction or two. I've done a lot of
eyeballing of gcc's asm output...
They need to be fixed in anycase, but useful to keep in mind.
Yes, if someone could get gcc's SSE FP optimization on par with x87, it
would probably speed up quite a few inner loops... :)
11:46 a.m.
Jan Kratochvil (jan.kratochvil(a)redhat.com) said:
Particularly why not to automatically install the whole x86_64 distro
where
appropriate? The DVD media should contain both arches as in the real world
found out the users are not aware if they have 64bit-capable hardware.
Well, to be somewhat glib, because that sort of setup wouldn't actually fit on
a DVD.
Bill
6:07 a.m.
On Mon, 02 Feb 2009 18:46:24 +0100, Bill Nottingham wrote:
Jan Kratochvil (jan.kratochvil(a)redhat.com) said:
> Particularly why not to automatically install the whole x86_64 distro where
> appropriate? The DVD media should contain both arches as in the real world
> found out the users are not aware if they have 64bit-capable hardware.
Well, to be somewhat glib, because that sort of setup wouldn't actually fit on
a DVD.
Agree; I just was thinking about the LiveCD/DVD installation mode and there is
enough room for i686+x86_64 LiveDVD.
I find hard to believe Fedora still in the 21st century suggests degrading the
machine by a 32bit OS: http://fedoraproject.org/get-fedora
Regards,
Jan
8:01 a.m.
Jan Kratochvil wrote:
I find hard to believe Fedora still in the 21st century suggests
degrading
the machine by a 32bit OS: http://fedoraproject.org/get-fedora
+1
The x86_64 version ought to be the default! In the current presentation,
it's hidden really badly (you need to go to the complete list).
Kevin Kofler
5:37 p.m.
On Friday, January 30 2009, Bill Nottingham said:
- XO support
There is concern that building for i686 might break binaries on the XO.
The Geode on the XO self-reports as i586; this may need slight frobbing.
Aside from that, it "supports the i686 (Pentium Pro) instruction set, MMX,
the parts of SSE that do not involve SSE registers, 3DNow! Enhanced, a
couple Geode-specific instructions and a few SSE2 instructions."
(http://wiki.laptop.org/go/Geode_instruction_set)
This implies it should work; however, there have been bugs in the past
(https://bugzilla.redhat.com/show_bug.cgi?id=200330). Chris Ball stated
"my input as OLPC software dude is that we're probably okay with dropping
586, but it would be great if someone heled us test that everything's
looking okay first."
The live images have been doing i686 kernel and glibc and work okay on
the XO. So add that as more anecdotal evidence of it not being a
problem
Jeremy
12:41 a.m.
Bill Nottingham wrote:
- K12Linux/thin client
Some older thin client hardware is not i686 compatible. Warren has more
info on this. One question I have is that some of this is mentioned
as being Geode - wouldn't this fall into the same category as the XO?
Geode is a popular thin client chipset that continues to be sold today.
VIA i586 without cmov was sold in thin clients until recently.
Anything older I do not care about.
More info is on the feature page. Note that in the smolt stats, i586
accounts for less than one twentieth of one percent of active systems,
an order of magnitude less than PowerPC.
smolt stats are not coming from i586 machines because these are not the
same kind of Fedora installs. It is inappropriate to enable smolt
reporting by default for several reasons including minimizing chroot
size, and read-only root makes it impossible to record that it shouldn't
report again during the next boot.
The statistics are not representative of the real world.
Warren Togami
wtogami(a)redhat.com
8:25 a.m.
On Sunday, February 01 2009, Warren Togami said:
Bill Nottingham wrote:
> - K12Linux/thin client
>
> Some older thin client hardware is not i686 compatible. Warren has more
> info on this. One question I have is that some of this is mentioned
> as being Geode - wouldn't this fall into the same category as the XO?
Geode is a popular thin client chipset that continues to be sold today.
VIA i586 without cmov was sold in thin clients until recently. Anything
older I do not care about.
Most Geode is processor family 5, but supports cmov and so is "i686"
compatible, inasmuch as we care
Jeremy
8:31 a.m.
>> Some older thin client hardware is not i686 compatible.
Warren has more
>> info on this. One question I have is that some of this is mentioned
>> as being Geode - wouldn't this fall into the same category as the XO?
>
> Geode is a popular thin client chipset that continues to be sold today.
> VIA i586 without cmov was sold in thin clients until recently. Anything
> older I do not care about.
Most Geode is processor family 5, but supports cmov and so is "i686"
compatible, inasmuch as we care
Yes, my Fit-PC with a LX800 runs the i686 kernel/glibc/openssl fine
but rpm still sees it as i586 so upgrades of those always have to be
done with rpm -U --ignorearch otherwise it doesn't work.
Peter.
11:47 a.m.
Warren Togami (wtogami(a)redhat.com) said:
smolt stats are not coming from i586 machines because these are not
the
same kind of Fedora installs. It is inappropriate to enable smolt
reporting by default for several reasons including minimizing chroot
size, and read-only root makes it impossible to record that it shouldn't
report again during the next boot.
The statistics are not representative of the real world.
How would we get statistics representative of the real world?
Bill
4:54 a.m.
New subject: Features/ArchitectureSupport - x86_64 kernel 32 bit userspace
Bill Nottingham wrote:
- install x86_64 kernel on 32-bit OS where appropriate
This is really exciting, but I remember to have read somewhere of
some compatibility issues.
In particular, could someone report success/failure for the nvidia
binary module?
Is it true that the x86_64 kernel part depends on x86_64 GL/X11 part
which depends on x86_64 X11, which depends on x86_64 glibc... and so
the system is basically being entirely switched to x86_64?
I know the policy about binary modules: the vendors have to cope
with their problems and Fedora will not slow down to help them.
But it looks interesting anyway to know for sure what happens.
Any other similar problems to investigate?
I think free stuff is compatible or fixable (kvm? fuse? openjdk? ...),
but there is also widely used proprietary software
(ATI closed source driver? vmware? ...).
Best regards.
--
Roberto Ragusa mail at robertoragusa.it
7:18 a.m.
New subject: Features/ArchitectureSupport - x86_64 kernel 32 bit userspace
On Thu, Feb 26, 2009 at 11:54 AM, Roberto Ragusa <mail(a)robertoragusa.it> wrote:
Bill Nottingham wrote:
>
> - install x86_64 kernel on 32-bit OS where appropriate
This is really exciting, but I remember to have read somewhere of
some compatibility issues.
Should work (solaris had a similar setup and they supported it)
In particular, could someone report success/failure for the nvidia
binary module?
Is it true that the x86_64 kernel part depends on x86_64 GL/X11 part
which depends on x86_64 X11, which depends on x86_64 glibc... and so
the system is basically being entirely switched to x86_64?
No, but imho if you have a x86_64 capable machine you should be using x86_64
I know the policy about binary modules: the vendors have to cope
with their problems and Fedora will not slow down to help them.
But it looks interesting anyway to know for sure what happens.
Any other similar problems to investigate?
I think free stuff is compatible or fixable (kvm? fuse? openjdk? ...),
kvm should work fine, same for fuse.
dunno why you ask about openjdk its just a regular userspace app.
but there is also widely used proprietary software
(ATI closed source driver? vmware? ...).
No idea, but they should be fine too. (besides nobody is stopping you
from using a i586 if you really need/want that or just move to x86_64
;) )
7:49 a.m.
New subject: Features/ArchitectureSupport - x86_64 kernel 32 bit userspace
drago01 wrote:
On Thu, Feb 26, 2009 at 11:54 AM, Roberto Ragusa
<mail(a)robertoragusa.it> wrote:
> Bill Nottingham wrote:
>> - install x86_64 kernel on 32-bit OS where appropriate
> This is really exciting, but I remember to have read somewhere of
> some compatibility issues.
Should work (solaris had a similar setup and they supported it)
Agreed, I know it should work by default. Just wondering about
corner cases (the nvidia rumor, basically).
> In particular, could someone report success/failure for the
nvidia
> binary module?
> Is it true that the x86_64 kernel part depends on x86_64 GL/X11 part
> which depends on x86_64 X11, which depends on x86_64 glibc... and so
> the system is basically being entirely switched to x86_64?
No, but imho if you have a x86_64 capable machine you should be using x86_64
Well, yes, x86_64 is an option, but there could be reasons to live with
32bit userspace; for example if I have a proprietary 32bit app which would
require many i386 libs on x86_64, or just to have a development environment
where one can compile for i386 without worrying about compiler flags and
linking the right stuff, or just to avoid an installation from scratch
(upgrade i386->x86_64 is still unsupported, right?).
The nvidia problem was, IIRC, that something (arch dependent) is shared by
the kernel part and userspace part (sizes of passed data structures, maybe).
I was not able to find a reference to this discussion on the net,
so I'm asking here if anyone knows about that.
It would be bad design by nvidia, sure.
> I think free stuff is compatible or fixable (kvm? fuse? openjdk?
...),
kvm should work fine, same for fuse.
dunno why you ask about openjdk its just a regular userspace app.
You are right. Openjdk is JIT compiled, but there is no particular
kernel interaction.
> but there is also widely used proprietary software
> (ATI closed source driver? vmware? ...).
No idea, but they should be fine too. (besides nobody is stopping you
from using a i586 if you really need/want that or just move to x86_64
;) )
Obviously yes. :-)
In fact, when I upgraded my laptop to 4GiB months ago, I wondered
about the alternatives:
a) switch to 32bit PAE
b) switch to x86_64 kernel
c) switch to x86_64 kernel and apps
I discarded c) for upgrade simplicity and avoided trying b) for the nvidia
issue we are talking about (so, I'm currently running a) ).
Best regards.
--
Roberto Ragusa mail at robertoragusa.it
8:41 a.m.
New subject: Features/ArchitectureSupport - x86_64 kernel 32 bit userspace
On Thu, Feb 26, 2009 at 02:18:48PM +0100, drago01 wrote:
On Thu, Feb 26, 2009 at 11:54 AM, Roberto Ragusa
<mail(a)robertoragusa.it> wrote:
> This is really exciting, but I remember to have read somewhere of
> some compatibility issues.
Should work (solaris had a similar setup and they supported it)
You lose vm86() mode, so dosemu won't work. You also have to hope that
all the ioctl compatibility works - historically this hasn't been the
case for all subsystems.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
8:56 a.m.
New subject: Features/ArchitectureSupport - x86_64 kernel 32 bit userspace
Matthew Garrett (mjg(a)redhat.com) said:
> Should work (solaris had a similar setup and they supported it)
You lose vm86() mode, so dosemu won't work. You also have to hope that
all the ioctl compatibility works - historically this hasn't been the
case for all subsystems.
But any such subsystems where this is the case are already broken
on ppc64/sparc64.
Bill
10:11 a.m.
New subject: Features/ArchitectureSupport - x86_64 kernel 32 bit userspace
On Thu, Feb 26, 2009 at 09:56:20AM -0500, Bill Nottingham wrote:
Matthew Garrett (mjg(a)redhat.com) said:
> > Should work (solaris had a similar setup and they supported it)
>
> You lose vm86() mode, so dosemu won't work. You also have to hope that
> all the ioctl compatibility works - historically this hasn't been the
> case for all subsystems.
But any such subsystems where this is the case are already broken
on ppc64/sparc64.
Yeah, but I suspect we have more USB scanner users on x86 than ppc64
(for instance).
--
Matthew Garrett | mjg59(a)srcf.ucam.org
5536
days inactive
5563
days old
110 comments
37 participants
participants (37)
-
Benny Amorsen -
Bill Nottingham -
Bruno Wolff III -
Callum Lerwick -
Chris Adams -
Colin Walters -
Conrad Meyer -
Dominik 'Rathann' Mierzejewski -
drago01 -
Frank Murphy -
Gregory Maxwell -
Ignacio Vazquez-Abrams -
Jan Kratochvil -
Jason L Tibbitts III -
Jef Spaleta -
Jeremy Katz -
Joe Nall -
Jon Stanley -
Josh Boyer -
Kevin Kofler -
Matthew Garrett -
Matthew Woehlke -
Muayyad AlSadi -
Neal Gompa -
Nicolas Mailhot -
Olivier Galibert -
Peter Robinson -
Rahul Sundaram -
Richard W.M. Jones -
Robert Scheck -
Roberto Ragusa -
Till Maas -
Toshio Kuratomi -
Ville Skyttä -
Warren Togami -
Wes Shull -
William Cohen