12:32 a.m.
I noticed that http://fedoraproject.org/get-fedora appears to be
strongly promoting i386 Fedora over x86_64. Is this intentional or an
oversight?
12:55 a.m.
On 11/18/2009 01:32 AM, Gregory Maxwell wrote:
I noticed that http://fedoraproject.org/get-fedora appears to be
strongly promoting i386 Fedora over x86_64. Is this intentional or an
oversight?
I agree, that was my first impression as well.
However, if you just want a single "download now" button, 32-bit would
get you the widest hardware coverage.
Jeff
12:13 p.m.
> I noticed that http://fedoraproject.org/get-fedora appears to be
> strongly promoting i386 Fedora over x86_64. Is this intentional or an
> oversight?
I agree, that was my first impression as well.
However, if you just want a single "download now" button,
32-bit would get
you the widest hardware coverage.
And you can run a 32-bit OS on an 64-bit architecture. The other way
doesn't work. ^^
12:55 a.m.
I think this is a script which reads your currently used architecture
and provide a dl link. please insert a x86_64 livecd and try it again!
2009/11/18, Gregory Maxwell <gmaxwell(a)gmail.com>:
I noticed that http://fedoraproject.org/get-fedora appears to be
strongly promoting i386 Fedora over x86_64. Is this intentional or an
oversight?
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Josephine "Fine" Tannhäuser
2.6.18-164.2.1.el5 2.6.30.9-90.fc11.i586
1:30 a.m.
On Tuesday 17 November 2009 10:55:22 pm Josephine Tannhäuser wrote:
I think this is a script which reads your currently used
architecture
and provide a dl link. please insert a x86_64 livecd and try it again!
That doesn't appear to be true. I double checked that the user agent string
Firefox is sending includes x86_64, and I still get the 32-bit version
suggested.
Regards,
--
Conrad Meyer <cemeyer(a)u.washington.edu>
3:24 a.m.
On 11/18/09 07:55, Josephine Tannhäuser wrote:
I think this is a script which reads your currently used
architecture
and provide a dl link. please insert a x86_64 livecd and try it again!
Wrong. Going there with Fedora 11/x86_64 (firefox) offers the 32bit
version too.
cheers,
Gerd
4:33 a.m.
2009/11/18 Gerd Hoffmann <kraxel(a)redhat.com>
On 11/18/09 07:55, Josephine Tannhäuser wrote:
> I think this is a script which reads your currently used architecture
> and provide a dl link. please insert a x86_64 livecd and try it again!
>
Wrong. Going there with Fedora 11/x86_64 (firefox) offers the 32bit
version too.
cheers,
Gerd
There's no javascript on the page checking client arch; i think the idea was
discarded, because the machines used to download and install most of the
times are not the same.
I really like the "more download options" link found in the spins website
(which is
awesome, kudos to the designers), showing an additional x86_64 download
block with dhtml.
cheers
--
Guido Grazioli <guido.grazioli(a)gmail.com>
Via Parri 11 48011 - Alfonsine (RA)
Mobile: +39 347 1017202 (10-18)
Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278
Linked in: http://www.linkedin.com/in/guidograzioli
10:32 a.m.
On Wed, Nov 18, 2009 at 1:55 AM, Josephine Tannhäuser
<josephine.tannhauser(a)googlemail.com> wrote:
2009/11/18, Gregory Maxwell <gmaxwell(a)gmail.com>:
> I noticed that http://fedoraproject.org/get-fedora appears to be
> strongly promoting i386 Fedora over x86_64. Is this intentional or an
> oversight?
I think this is a script which reads your currently used architecture
and provide a dl link. please insert a x86_64 livecd and try it again!
As others have pointed out: this is not so and probably can't produce
reasonable results.
On Wed, Nov 18, 2009 at 1:55 AM, Jeff Garzik <jgarzik(a)pobox.com> wrote:
However, if you just want a single "download now" button,
32-bit would get
you the widest hardware coverage.
Absolutely. Although it was my understanding that the stated goal was to
encourage everyone on capable hardware to run x86_64, and previous
editions of the download page did seem to do that.
I don't personally have much of a horse in that race beyond the fact that I
argued against dropping support for some older systems in the 32 bit build
based on the position that users on new hardware should be running x86_64.
There is obviously a trade-off in having the simplest possible install vs
getting people the best platform support. Considering the complexity of
the overall install I think the extra work to select an architecture at
download time would be a comparatively small hurdle.
In any case— the trade-off here should be consciously chosen and not the
result of an oversight in the development of the download page.
(Which I think think is generally quite good).
6:11 p.m.
On Wed, Nov 18, 2009 at 1:32 AM, Gregory Maxwell wrote:
I noticed that http://fedoraproject.org/get-fedora appears to be
strongly promoting i386 Fedora over x86_64. Is this intentional or an
oversight?
It is intentional. This is one of the standard discussion topics of
this list. And it usually stems from or leads to a KDE/Gnome fight.
The primary reason why it is this way is usually defended by:
"When my aunt comes to the download page, she won't know which version
to download because she doesn't know what 64 bit is. The goal is to
have my aunt download something that will work. It doesn't matter how
good it works."
It is no surprise that this is also the primary reason why Gnome
Desktop spin is called the Desktop spin. However, I think people are
more busy with the "user playing root" thread, so that this thread got
discarded for now.
Orcan
7:27 p.m.
Gregory Maxwell wrote:
I noticed that http://fedoraproject.org/get-fedora appears to be
strongly promoting i386 Fedora over x86_64. Is this intentional or an
oversight?
This is, sadly, intentional. I and others have been complaining about this
for months, we got ignored, all in the names of making things work for
people who are not smart enough to figure out whether their computer is 64-
bit or not. The argument that almost all new non-netbook machines are 64-bit
anyway also got ignored.
IMHO, the right solution is to make the 64-bit edition the default download
and to work on making the error message people get when trying to install it
on a 32-bit machine nicer: "We're sorry, but your computer is too old to
install this 64-bit version of Fedora. Please download the legacy 32-bit
edition instead."
Kevin Kofler
7:47 p.m.
On Wed, Nov 18, 2009 at 7:27 PM, Kevin Kofler <kevin.kofler(a)chello.at>wrote:
Gregory Maxwell wrote:
> I noticed that http://fedoraproject.org/get-fedora appears to be
> strongly promoting i386 Fedora over x86_64. Is this intentional or an
> oversight?
This is, sadly, intentional. I and others have been complaining about this
for months, we got ignored, all in the names of making things work for
people who are not smart enough to figure out whether their computer is 64-
bit or not. The argument that almost all new non-netbook machines are
64-bit
anyway also got ignored.
IMHO, the right solution is to make the 64-bit edition the default download
and to work on making the error message people get when trying to install
it
on a 32-bit machine nicer: "We're sorry, but your computer is too old to
install this 64-bit version of Fedora. Please download the legacy 32-bit
edition instead."
Kevin Kofler
Is it right to call 32-bit legacy though? As it is, the Intel architecture
doesn't seem like a true 64-bit architecture. It seems more like it extends
the 32-bit arch and wraps 64-bitness around it.
In any case, 32-bit shouldn't be considered legacy until every type of
computer sold is 64-bit. And the fact is, that isn't true. Netbooks are
entirely 32-bit currently, and a majority of low end desktops are still
32-bit only.
7:56 p.m.
King InuYasha wrote:
In any case, 32-bit shouldn't be considered legacy until every
type of
computer sold is 64-bit. And the fact is, that isn't true.
It already basically was before netbooks came and turned the clock back. :-(
Netbooks are entirely 32-bit currently
Yeah, they're a huge step backwards (and not just for 64-bit computing, but
also for CPU speed, RAM, disk space (especially where SSDs are used instead
of the traditional HDDs) and LCD pixel counts (as a result of compactness,
but this breaks many apps who have been assuming that the 640×480 era was
long past and that 800×600 was the bare minimum – the original plan for KDE
4 was even to require 1024×768!)).
and a majority of low end desktops are still 32-bit only.
Huh? What low-end desktops? All the current desktop CPUs are 64-bit. Even
the desktop versions (not the netbook versions) of the Atom are. There may
be some mini-desktops with netbook CPUs, but those aren't really the
standard desktops.
Kevin Kofler
7:56 p.m.
On 11/19/2009 07:26 AM, Kevin Kofler wrote:
King InuYasha wrote:
> In any case, 32-bit shouldn't be considered legacy until every type of
> computer sold is 64-bit. And the fact is, that isn't true.
It already basically was before netbooks came and turned the clock back. :-(
Regardless of your take on that, it is now a very very popular segment
and many users are going to run Fedora on those systems (ie) 32-bit is
getting a whole new life all over again. We cannot call them legacy or
side line them.
My not too old laptop is 32-bit only (Dell D420 if you care).
Rahul
3:36 a.m.
Rahul Sundaram wrote:
Regardless of your take on that, it is now a very very popular
segment
and many users are going to run Fedora on those systems (ie) 32-bit is
getting a whole new life all over again. We cannot call them legacy or
side line them.
The netbook problem can be addressed by a "download netbook edition" link
which can then be not only 32-bit, but also using a desktop optimized for
netbook display and RAM sizes rather than the default GNOME.
Kevin Kofler
3:54 a.m.
On 11/19/2009 03:06 PM, Kevin Kofler wrote:
Rahul Sundaram wrote:
> Regardless of your take on that, it is now a very very popular segment
> and many users are going to run Fedora on those systems (ie) 32-bit is
> getting a whole new life all over again. We cannot call them legacy or
> side line them.
The netbook problem can be addressed by a "download netbook edition" link
which can then be not only 32-bit, but also using a desktop optimized for
netbook display and RAM sizes rather than the default GNOME.
Someone will have to volunteer to do that and IMO, the default ISO image
should just work for netbooks anyway.
Rahul
10:56 a.m.
On Thu, 2009-11-19 at 15:24 +0530, Rahul Sundaram wrote:
On 11/19/2009 03:06 PM, Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> Regardless of your take on that, it is now a very very popular segment
>> and many users are going to run Fedora on those systems (ie) 32-bit is
>> getting a whole new life all over again. We cannot call them legacy or
>> side line them.
>
> The netbook problem can be addressed by a "download netbook edition" link
> which can then be not only 32-bit, but also using a desktop optimized for
> netbook display and RAM sizes rather than the default GNOME.
Someone will have to volunteer to do that and IMO, the default ISO image
should just work for netbooks anyway.
Rahul
See the Moblin respin. Too late to be a spin for F12, could be one of
the official spins for F13.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:45 a.m.
On 11/19/2009 05:56 PM, Jesse Keating wrote:
On Thu, 2009-11-19 at 15:24 +0530, Rahul Sundaram wrote:
> On 11/19/2009 03:06 PM, Kevin Kofler wrote:
>> Rahul Sundaram wrote:
>>> Regardless of your take on that, it is now a very very popular segment
>>> and many users are going to run Fedora on those systems (ie) 32-bit is
>>> getting a whole new life all over again. We cannot call them legacy or
>>> side line them.
>>
>> The netbook problem can be addressed by a "download netbook edition"
link
>> which can then be not only 32-bit, but also using a desktop optimized for
>> netbook display and RAM sizes rather than the default GNOME.
>
> Someone will have to volunteer to do that and IMO, the default ISO image
> should just work for netbooks anyway.
>
> Rahul
>
See the Moblin respin. Too late to be a spin for F12, could be one of
the official spins for F13.
You must not confuse moblin with netbooks, nettops or
with i386/32bit
machines in general. The moblin desktop is addressing a completely
different audience.
Ralf
12:14 p.m.
On Thu, 2009-11-19 at 18:45 +0100, Ralf Corsepius wrote:
You must not confuse moblin with netbooks, nettops or with i386/32bit
machines in general. The moblin desktop is addressing a completely
different audience.
Oh? That's not what I got from
http://fedoraproject.org/wiki/Features/FedoraMoblin
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
8:52 p.m.
On 11/19/2009 07:14 PM, Jesse Keating wrote:
On Thu, 2009-11-19 at 18:45 +0100, Ralf Corsepius wrote:
> You must not confuse moblin with netbooks, nettops or with i386/32bit
> machines in general. The moblin desktop is addressing a completely
> different audience.
>
Oh? That's not what I got from
http://fedoraproject.org/wiki/Features/FedoraMoblin
It's what I get from this
web-page and what I got from testing the
original Moblin desktop.
IMO, they are targetting MID devices, competing with Android, Smart
phones and similar.
That's a completely different audience as I am talking about: People
using netbooks, nettops and old i386s as inexpensive, "secondary"
machine for everyday, "low end" desktop usage, such as "browsing the
web", "word processing", "presentations", "photo
browsing" etc.
Ralf
11:31 p.m.
On 11/20/2009 08:22 AM, Ralf Corsepius wrote:
On 11/19/2009 07:14 PM, Jesse Keating wrote:
> On Thu, 2009-11-19 at 18:45 +0100, Ralf Corsepius wrote:
>> You must not confuse moblin with netbooks, nettops or with i386/32bit
>> machines in general. The moblin desktop is addressing a completely
>> different audience.
>>
>
> Oh? That's not what I got from
> http://fedoraproject.org/wiki/Features/FedoraMoblin
It's what I get from this web-page and what I got from testing the
original Moblin desktop.
IMO, they are targetting MID devices, competing with Android, Smart
phones and similar.
That's a completely different audience as I am talking about: People
using netbooks, nettops and old i386s as inexpensive, "secondary"
machine for everyday, "low end" desktop usage, such as "browsing the
web", "word processing", "presentations", "photo
browsing" etc.
User experience part of the page says
"Users of the Fedora Moblin Spin would have a much better user
experience on their NetBook, NetTop and other small devices"
Rahul
11:50 p.m.
On 11/20/2009 06:31 AM, Rahul Sundaram wrote:
On 11/20/2009 08:22 AM, Ralf Corsepius wrote:
> On 11/19/2009 07:14 PM, Jesse Keating wrote:
>> On Thu, 2009-11-19 at 18:45 +0100, Ralf Corsepius wrote:
>>> You must not confuse moblin with netbooks, nettops or with i386/32bit
>>> machines in general. The moblin desktop is addressing a completely
>>> different audience.
>>>
>>
>> Oh? That's not what I got from
>> http://fedoraproject.org/wiki/Features/FedoraMoblin
> It's what I get from this web-page and what I got from testing the
> original Moblin desktop.
>
> IMO, they are targetting MID devices, competing with Android, Smart
> phones and similar.
>
> That's a completely different audience as I am talking about: People
> using netbooks, nettops and old i386s as inexpensive, "secondary"
> machine for everyday, "low end" desktop usage, such as "browsing the
> web", "word processing", "presentations", "photo
browsing" etc.
User experience part of the page says
"Users of the Fedora Moblin Spin would have a much better user
experience on their NetBook, NetTop and other small devices"
That's what
the marketing department wants it to be.
Reality speaks a different language:
* People are using their everyday desktop even on low end machines and
do not want to fiddle around with "custom netbooks desktops".
* People consider their low end machine's performance sufficient for
such use-cases.
The essentially the same rationale/reason why netbooks/nettops with
WinXP have been a huge success and why netbooks with "custom desktops"
were a failure.
Ralf
11:54 p.m.
On 11/20/2009 11:20 AM, Ralf Corsepius wrote:
> "Users of the Fedora Moblin Spin would have a much better
user
> experience on their NetBook, NetTop and other small devices"
That's what the marketing department wants it to be.
Meh. You said the target of the spin is not netbooks but it clearly is.
Reality speaks a different language:
* People are using their everyday desktop even on low end machines and
do not want to fiddle around with "custom netbooks desktops".
* People consider their low end machine's performance sufficient for
such use-cases.
I am not sure why I should accept your version of reality over any
other. Any references to back up your claims?
The essentially the same rationale/reason why netbooks/nettops with
WinXP have been a huge success and why netbooks with "custom desktops"
were a failure.
Actually, netbooks represent one of the highest market shares for Linux
on the client side and nany of them are running custom desktops
http://www.desktoplinux.com/news/NS5114054156.html
Rahul
12:20 a.m.
On 11/20/2009 06:54 AM, Rahul Sundaram wrote:
On 11/20/2009 11:20 AM, Ralf Corsepius wrote:
>> "Users of the Fedora Moblin Spin would have a much better user
>> experience on their NetBook, NetTop and other small devices"
> That's what the marketing department wants it to be.
Meh. You said the target of the spin is not netbooks but it clearly is.
You violently don't want to understand.
The moblin stuff is a different use-case, primarily addressing the very
low end of HW, which is competing with SmartPhones, the XOs and the like.
I am talking about is people using netbook/nettops as "secondary
desktops" for "normal usage".
> Reality speaks a different language:
> * People are using their everyday desktop even on low end machines and
> do not want to fiddle around with "custom netbooks desktops".
> * People consider their low end machine's performance sufficient for
> such use-cases.
I am not sure why I should accept your version of reality over any
other. Any references to back up your claims?
It's what I am using netbooks for, everybody around me uses netbooks
for, what newpapers tell and what I can buy in stores.
The mass of "Atom based" machines you can buy around here either have
"Win XP" preinstalled or meanwhile occasionally come with Win7.
Linux based netbooks/nettops can hardly be found in stores anywhere.
> The essentially the same rationale/reason why netbooks/nettops
with
> WinXP have been a huge success and why netbooks with "custom desktops"
> were a failure.
Actually, netbooks represent one of the highest market shares for Linux
on the client side and nany of them are running custom desktops
http://www.desktoplinux.com/news/NS5114054156.html
Well you'll likely find a static proving anything.
All I can say, my netbook easily outperforms many "older desktops" and
is quite suiteable for everyday office- and home use-cases, using an
ordinary Fedora setup. I don't have any use for Moblin and consider
Moblin to be a waste of resources.
Ralf
12:23 a.m.
On 11/20/2009 11:50 AM, Ralf Corsepius wrote:
On 11/20/2009 06:54 AM, Rahul Sundaram wrote:
> On 11/20/2009 11:20 AM, Ralf Corsepius wrote:
>>> "Users of the Fedora Moblin Spin would have a much better user
>>> experience on their NetBook, NetTop and other small devices"
>> That's what the marketing department wants it to be.
>
> Meh. You said the target of the spin is not netbooks but it clearly is.
You violently don't want to understand.
The moblin stuff is a different use-case, primarily addressing the very
low end of HW, which is competing with SmartPhones, the XOs and the like.
I understand your impressions but your claim that the Moblin spin isn't
targeted at netbooks is just plain wrong. There is just no way around that.
People are using custom desktops in netbooks all the time and yes, those
custom desktops are gaining market share. I gave you a desktop market
study as a reference already, Look at what Dell is recently shipping for
instance. Just hand waving wildly doesn't cut it.
Rahul
1:44 a.m.
On 11/20/2009 07:23 AM, Rahul Sundaram wrote:
On 11/20/2009 11:50 AM, Ralf Corsepius wrote:
> On 11/20/2009 06:54 AM, Rahul Sundaram wrote:
>> On 11/20/2009 11:20 AM, Ralf Corsepius wrote:
>>>> "Users of the Fedora Moblin Spin would have a much better user
>>>> experience on their NetBook, NetTop and other small devices"
>>> That's what the marketing department wants it to be.
>>
>> Meh. You said the target of the spin is not netbooks but it clearly is.
>
> You violently don't want to understand.
>
> The moblin stuff is a different use-case, primarily addressing the very
> low end of HW, which is competing with SmartPhones, the XOs and the like.
I understand your impressions but your claim that the Moblin spin isn't
targeted at netbooks is just plain wrong.
I never said this - They are addressing a different use-case !
It's a use-case, HW vendors want to see emphasized because they are
confronted with the fact that netbook/netbooks are competing with
"ordinary desktops", which had caused their returns to shrink, because
they are selling less "big" end-consumer machines.
Ralf
4:26 p.m.
> The moblin stuff is a different use-case, primarily addressing
the very low end of HW, which is competing with SmartPhones, the XOs and the like.
I understand your impressions but your claim that the Moblin spin
isn't targeted at netbooks is just plain wrong. There is just no way around that.
People are using custom desktops in netbooks all the time and yes,
those custom desktops are gaining market share.
There is a marketshare for BOTH!
The "newbs" wanna have an easy to use interface --> Moblin.
The "pros" wanna have ar "real" desktop --> Fedora.
5:12 a.m.
> On 11/20/2009 11:20 AM, Ralf Corsepius wrote:
>>>
>>> "Users of the Fedora Moblin Spin would have a much better user
>>> experience on their NetBook, NetTop and other small devices"
>>
>> That's what the marketing department wants it to be.
>
> Meh. You said the target of the spin is not netbooks but it clearly is.
You violently don't want to understand.
Actually I disagree.
The moblin stuff is a different use-case, primarily addressing the
very low
end of HW, which is competing with SmartPhones, the XOs and the like.
Actually its not targeting very low end hardware at all. It uses
clutter and the whole interface is rendered in OpenGL. You need a card
that can do that and the XO and other "very low end hardware" won't
cut it.
I am talking about is people using netbook/nettops as "secondary
desktops"
for "normal usage".
That is one use case of a Netbook/Nettop device. The other use case is
people that want to use it as a social and communications device to
keep in touch with friends, listen to music, check email and update
facebook. Both are very valid use cases and both are very popular just
because the Moblin user interface doesn't suit you it doesn't mean its
not a valid use case and one that lots of people want to use. The fact
there's been nearly 10K downloads of the beta live images prove that.
>> Reality speaks a different language:
>> * People are using their everyday desktop even on low end machines and
>> do not want to fiddle around with "custom netbooks desktops".
>> * People consider their low end machine's performance sufficient for
>> such use-cases.
>
> I am not sure why I should accept your version of reality over any
> other. Any references to back up your claims?
It's what I am using netbooks for, everybody around me uses netbooks for,
what newpapers tell and what I can buy in stores.
The mass of "Atom based" machines you can buy around here either have
"Win
XP" preinstalled or meanwhile occasionally come with Win7.
Maybe where you live but Linux still makes up a large portion of the
netbook market. With a decent interface like Moblin that I believe
will improve. It doesn't fit everyones use case but the fact is that a
large percentage of the public only use their computer for Web
browsing, Music, photos, Instant Messaging, email and Social
Networking and Moblin fits that perfectly.
Linux based netbooks/nettops can hardly be found in stores anywhere.
>> The essentially the same rationale/reason why netbooks/nettops with
>> WinXP have been a huge success and why netbooks with "custom desktops"
>> were a failure.
>
> Actually, netbooks represent one of the highest market shares for Linux
> on the client side and nany of them are running custom desktops
>
> http://www.desktoplinux.com/news/NS5114054156.html
Well you'll likely find a static proving anything.
All I can say, my netbook easily outperforms many "older desktops" and is
quite suiteable for everyday office- and home use-cases, using an ordinary
Fedora setup. I don't have any use for Moblin and consider Moblin to be a
waste of resources.
To you it might be, I'm well aware of your opinions but yours is not
the only opinion and if you look at the netbook manufacturers you'll
see that they're all announcing Moblin devices. Hell Dell is even
shipping it in Beta to get it out there. So just because it doesn't
fit your taste it doesn't mean its wrong. Ultimately its another
option like GNOME or KDE or LXDE or enlightenment.
Peter
4:58 a.m.
>> You must not confuse moblin with netbooks, nettops or with
i386/32bit
>> machines in general. The moblin desktop is addressing a completely
>> different audience.
>>
>
> Oh? That's not what I got from
> http://fedoraproject.org/wiki/Features/FedoraMoblin
It's what I get from this web-page and what I got from testing the original
Moblin desktop.
No the Moblin 2.0 and 2.1 releases target NetBooks and Nettop devices
solely. A later release of Moblin 2.1 will also be targeted for MID
and Phone devices but will be using a slight different interface to
the current Moblin with the same underlying tech.
IMO, they are targetting MID devices, competing with Android, Smart
phones
and similar.
Not at the moment they're not/
That's a completely different audience as I am talking about:
People using
netbooks, nettops and old i386s as inexpensive, "secondary" machine for
everyday, "low end" desktop usage, such as "browsing the web",
"word
processing", "presentations", "photo browsing" etc.
They are targeting Netbooks for the online type of device. They are
targeted at web browsing, Social Networking, Media
(Audio/Video/Photos) and Instant messaging running on small
inexpensive netbook devices. They will do presentations and word
processing quite happily as well as it based on gtk and clutter so all
the usual gnome apps will run but that's not the main target.
Peter
5:14 a.m.
On 11/20/2009 11:58 AM, Peter Robinson wrote:
> IMO, they are targetting MID devices, competing with Android,
Smart phones
> and similar.
Not at the moment they're not/
Then please explain what they are targetting.
So far, all of Moblin I have seen was them trying to turn a multi-user
environment/desktop into a single-user, Smart-phone/Kiosk-like desktop.
> That's a completely different audience as I am talking about:
People using
> netbooks, nettops and old i386s as inexpensive, "secondary" machine for
> everyday, "low end" desktop usage, such as "browsing the web",
"word
> processing", "presentations", "photo browsing" etc.
They are targeting Netbooks for the online type of device.
What is this? UTMS, WLAN, LAN, Bluetooth etc.?
How is this kind of device different from an "ordinary desktop" with
UTMS, WLAN, LAN, Bluetooth ...?
They are
targeted at web browsing, Social Networking, Media
(Audio/Video/Photos) and Instant messaging running on small
inexpensive netbook devices. They will do presentations and word
processing quite happily as well as it based on gtk and clutter so all
the usual gnome apps will run but that's not the main target.
In my
understanding this is exactly the same target audience as all
other "desktop installations" address - So, why does it exist?
Getting rid of the "multi-user overhead", turning Linux into Windows?
Catering the the Telcos to address the TelCos' audiences? This would be
the Smartphone/Android etc. audience.
Ralf
5:24 a.m.
On Fri, Nov 20, 2009 at 11:14 AM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
On 11/20/2009 11:58 AM, Peter Robinson wrote:
>> IMO, they are targetting MID devices, competing with Android, Smart
>> phones
>> and similar.
>
> Not at the moment they're not/
Then please explain what they are targetting.
Netbooks.
So far, all of Moblin I have seen was them trying to turn a
multi-user
environment/desktop into a single-user, Smart-phone/Kiosk-like desktop.
>> That's a completely different audience as I am talking about: People
>> using
>> netbooks, nettops and old i386s as inexpensive, "secondary" machine
for
>> everyday, "low end" desktop usage, such as "browsing the
web", "word
>> processing", "presentations", "photo browsing" etc.
>
> They are targeting Netbooks for the online type of device.
What is this? UTMS, WLAN, LAN, Bluetooth etc.?
How is this kind of device different from an "ordinary desktop" with UTMS,
WLAN, LAN, Bluetooth ...?
Its not but its a move away from the traditional start menu style of
interface to one with Social networking and other communications at
its core. Like Sugar is a move away from a standard desktop for
education. It doesn't suit everyone one but it doesn't mean its wrong.
And for the target market its targeting it works very well.
> They are
> targeted at web browsing, Social Networking, Media
> (Audio/Video/Photos) and Instant messaging running on small
> inexpensive netbook devices. They will do presentations and word
> processing quite happily as well as it based on gtk and clutter so all
> the usual gnome apps will run but that's not the main target.
In my understanding this is exactly the same target audience as all other
"desktop installations" address - So, why does it exist?
Why do both gnome and kde and other desktop environments exist. They
all achieve the same thing so why have more that one? The target is
more the online market than a standard desktop market. Ones that use
web based apps and the likes of twitter and itunes more than they do a
word processor or spreadsheet.
Getting rid of the "multi-user overhead", turning Linux
into Windows?
You can run it multi user just fine. I do so myself.
Catering the the Telcos to address the TelCos' audiences? This
would be the
Smartphone/Android etc. audience.
No. A netbook isn't a smart phone.... you can't put it in your pocket.
Peter
2:02 a.m.
On 11/19/2009 08:14 PM, Jesse Keating wrote:
On Thu, 2009-11-19 at 18:45 +0100, Ralf Corsepius wrote:
> You must not confuse moblin with netbooks, nettops or with i386/32bit
> machines in general. The moblin desktop is addressing a completely
> different audience.
Oh? That's not what I got from
http://fedoraproject.org/wiki/Features/FedoraMoblin
Moblin is not about hardware, you can run it on a powerful 64 bit
desktop, while my netbook is perfectly able to run a normal GNOME desktop.
Moblin is about users, made for those with a small set of basic needs,
which in many cases are people using netbooks or less powerful hardware,
but there are a lot of other user cases for such hardware, beyond Moblin.
--
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/
4:30 a.m.
On 11/20/2009 09:02 AM, Nicu Buculei wrote:
On 11/19/2009 08:14 PM, Jesse Keating wrote:
> On Thu, 2009-11-19 at 18:45 +0100, Ralf Corsepius wrote:
>> You must not confuse moblin with netbooks, nettops or with i386/32bit
>> machines in general. The moblin desktop is addressing a completely
>> different audience.
>
> Oh? That's not what I got from
> http://fedoraproject.org/wiki/Features/FedoraMoblin
Moblin is not about hardware, you can run it on a powerful 64 bit
desktop, while my netbook is perfectly able to run a normal GNOME desktop.
Moblin is about users, made for those with a small set of basic needs,
which in many cases are people using netbooks or less powerful hardware,
but there are a lot of other user cases for such hardware, beyond Moblin.
Exactly.
As I tried to express several times before in this thread: Moblin is
addressing and entirely different use-case.
Whether this use-case of interest in individual situations is a
different question - To some it might be interesting, to me, it is not.
Ralf
2:04 p.m.
On 11/20/2009 05:30 AM, Ralf Corsepius wrote:
As I tried to express several times before in this thread: Moblin is
addressing and entirely different use-case.
Whether this use-case of interest in individual situations is a
different question - To some it might be interesting, to me, it is not.
Yes, so the [great-]+grandparent argument that GNOME and KDE can assume
Nx768 isn't valid, since Moblin isn't a replacement for them for some
large cross-section of netbook users. I've got at least one bug filed
on NetworkManager applet going over 600 pixels for basic functionality,
but it was recently changed from bug to enhancement.
I use an eeePC for mobile work mostly because I can run Fedora and the
Mozilla suite on it and it gets absurd battery life (I can work most of
an 8-hour train ride). Still, this thread has inspired me to go check
out the Moblin spin again - it could be useful for other use cases.
-Bill
--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.603.448.4440
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
12:50 p.m.
The netbook problem can be addressed by a "download netbook
edition" link
which can then be not only 32-bit, but also using a desktop optimized for
netbook display and RAM sizes rather than the default GNOME.
There is a Fedora 12 LXDE Spin that I think would fit the gap. But it
need some love. :>
8:13 p.m.
Yeah, they're a huge step backwards (and not just for 64-bit
computing, but
also for CPU speed, RAM, disk space (especially where SSDs are used
instead
of the traditional HDDs) and LCD pixel counts
I like this fact. I think this will push Linux. Code on slow machines,
and on "normal" machines, the system will kick-ass! :D
1:29 a.m.
On Thu, Nov 19, 2009 at 2:56 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
King InuYasha wrote:
> In any case, 32-bit shouldn't be considered legacy until every type of
> computer sold is 64-bit. And the fact is, that isn't true.
It already basically was before netbooks came and turned the clock back. :-(
> Netbooks are entirely 32-bit currently
Yeah, they're a huge step backwards (and not just for 64-bit computing, but
also for CPU speed, RAM, disk space (especially where SSDs are used instead
of the traditional HDDs)
If you ever used an SSD you wouldn't call it a step backwards, it is
so much better than a traditional HD that I don't want a Laptop
without one ever again.
HDDs should be the ones of the past, but for that prices need to drop.
Anyway offtopic here.
8:48 a.m.
On 11/18/2009 08:47 PM, King InuYasha wrote:
In any case, 32-bit shouldn't be considered legacy until every
type of
computer sold is 64-bit. And the fact is, that isn't true. Netbooks are
entirely 32-bit currently, and a majority of low end desktops are still
32-bit only.
This simply isn't factually the case. Most new low end desktops on the
market right now will run 64-bit quite happily, and
http://www.google.com/search?q=atom+330+netbook yields plenty of results.
--
Peter
If you're not part of the solution, then you're part of the precipitate.
3:34 p.m.
On Wed, 2009-11-18 at 19:47 -0600, King InuYasha wrote:
Netbooks are entirely 32-bit currently, and a majority of low end
desktops are still 32-bit only.
I don't think your second assertion is true. I'm not aware of any
currently-sold desktop processor, no matter how low end, which is not
x86-64 capable. The very cheapest processor you can buy from my friendly
local dealer is a 'Celeron 430', which is x86-64 capable. The last
processor Intel released which was not x86-64 capable, so far as I can
figure out, was the Celeron D 310, released December 2005. The last
non-x86-64-capable chip AMD released was the 'Paris' Sempron family,
which came in July 2004. The subsequent 'Palermo' Sempron family,
released February 2005, had x86-64 support.
If you're talking about already-existing systems rather than newly sold
ones, there's more of a case there, but even so we've been in a
64-bit-capable world aside from netbook Atom CPUs for over four years
now.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:35 p.m.
On Thu, 2009-11-19 at 13:34 -0800, Adam Williamson wrote:
On Wed, 2009-11-18 at 19:47 -0600, King InuYasha wrote:
> Netbooks are entirely 32-bit currently, and a majority of low end
> desktops are still 32-bit only.
I don't think your second assertion is true. I'm not aware of any
currently-sold desktop processor, no matter how low end, which is not
x86-64 capable. The very cheapest processor you can buy from my friendly
local dealer is a 'Celeron 430', which is x86-64 capable. The last
processor Intel released which was not x86-64 capable, so far as I can
figure out, was the Celeron D 310, released December 2005. The last
non-x86-64-capable chip AMD released was the 'Paris' Sempron family,
which came in July 2004. The subsequent 'Palermo' Sempron family,
released February 2005, had x86-64 support.
If you're talking about already-existing systems rather than newly sold
ones, there's more of a case there, but even so we've been in a
64-bit-capable world aside from netbook Atom CPUs for over four years
now.
oh, damn. Forgot the first Intel Core mobile families. Core Solo and
Core Duo are 32-bit only. The last of those showed up in January 2007,
so quite a bit more recent.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:38 p.m.
On 11/19/2009 04:35 PM, Adam Williamson wrote:
On Thu, 2009-11-19 at 13:34 -0800, Adam Williamson wrote:
> On Wed, 2009-11-18 at 19:47 -0600, King InuYasha wrote:
>> Netbooks are entirely 32-bit currently, and a majority of low end
>> desktops are still 32-bit only.
>
> I don't think your second assertion is true. I'm not aware of any
> currently-sold desktop processor, no matter how low end, which is not
> x86-64 capable. The very cheapest processor you can buy from my friendly
> local dealer is a 'Celeron 430', which is x86-64 capable. The last
> processor Intel released which was not x86-64 capable, so far as I can
> figure out, was the Celeron D 310, released December 2005. The last
> non-x86-64-capable chip AMD released was the 'Paris' Sempron family,
> which came in July 2004. The subsequent 'Palermo' Sempron family,
> released February 2005, had x86-64 support.
>
> If you're talking about already-existing systems rather than newly sold
> ones, there's more of a case there, but even so we've been in a
> 64-bit-capable world aside from netbook Atom CPUs for over four years
> now.
oh, damn. Forgot the first Intel Core mobile families. Core Solo and
Core Duo are 32-bit only. The last of those showed up in January 2007,
so quite a bit more recent.
The netbook-grade Atoms mentioned a few times in this thread are certainly newer than
that.
--CJD
4:02 p.m.
On Thu, 2009-11-19 at 16:38 -0500, Casey Dahlin wrote:
The netbook-grade Atoms mentioned a few times in this thread are
certainly newer than that.
I did specifically say 'aside from those', since they're already clearly
under consideration.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:54 p.m.
Once upon a time, Adam Williamson <awilliam(a)redhat.com> said:
The last
processor Intel released which was not x86-64 capable, so far as I can
figure out, was the Celeron D 310, released December 2005. The last
non-x86-64-capable chip AMD released was the 'Paris' Sempron family,
which came in July 2004. The subsequent 'Palermo' Sempron family,
released February 2005, had x86-64 support.
Don't just go by release date, go by end-of-sale date. When did Intel
and AMD _stop_ selling CPUs that did not have 64 bit support? That's
what really matters.
I have a Thinkpad from early 2006 that is 32 bit only for example. It
works perfectly fine, so I am in no hurry to replace it just because it
is only 32 bit.
--
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.
4:04 p.m.
On Thu, 2009-11-19 at 15:54 -0600, Chris Adams wrote:
Once upon a time, Adam Williamson <awilliam(a)redhat.com> said:
> The last
> processor Intel released which was not x86-64 capable, so far as I can
> figure out, was the Celeron D 310, released December 2005. The last
> non-x86-64-capable chip AMD released was the 'Paris' Sempron family,
> which came in July 2004. The subsequent 'Palermo' Sempron family,
> released February 2005, had x86-64 support.
Don't just go by release date, go by end-of-sale date. When did Intel
and AMD _stop_ selling CPUs that did not have 64 bit support? That's
what really matters.
Usually fairly soon after, CPUs have pretty short shelf-lives these
days.
I have a Thinkpad from early 2006 that is 32 bit only for example.
It
works perfectly fine, so I am in no hurry to replace it just because it
is only 32 bit.
see my 'oops' follow-up - I forgot to consider the first rev of the Core
architecture, which was 32-bit only and current until Jan 2007. The
follow-up 'Core 2' architecture was x86-64 capable. You probably have a
Core Duo or Core Solo CPU in that thing.
(Core 2 CPUs replaced Core CPUs in shipping models very quickly after
Core 2 was released, which kinda supports my first point of this mail).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:14 p.m.
Once upon a time, Adam Williamson <awilliam(a)redhat.com> said:
On Thu, 2009-11-19 at 15:54 -0600, Chris Adams wrote:
> I have a Thinkpad from early 2006 that is 32 bit only for example. It
> works perfectly fine, so I am in no hurry to replace it just because it
> is only 32 bit.
see my 'oops' follow-up - I forgot to consider the first rev of the Core
architecture, which was 32-bit only and current until Jan 2007. The
follow-up 'Core 2' architecture was x86-64 capable. You probably have a
Core Duo or Core Solo CPU in that thing.
I just checked, and it is actually a Pentium M (Dothan core).
--
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.
4:20 p.m.
On Thu, 2009-11-19 at 16:14 -0600, Chris Adams wrote:
Once upon a time, Adam Williamson <awilliam(a)redhat.com> said:
> On Thu, 2009-11-19 at 15:54 -0600, Chris Adams wrote:
> > I have a Thinkpad from early 2006 that is 32 bit only for example. It
> > works perfectly fine, so I am in no hurry to replace it just because it
> > is only 32 bit.
>
> see my 'oops' follow-up - I forgot to consider the first rev of the Core
> architecture, which was 32-bit only and current until Jan 2007. The
> follow-up 'Core 2' architecture was x86-64 capable. You probably have a
> Core Duo or Core Solo CPU in that thing.
I just checked, and it is actually a Pentium M (Dothan core).
damn, my psychic powers stink lately.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:04 p.m.
IMHO, the right solution is to make the 64-bit edition the default
download
and to work on making the error message people get when trying to install it
on a 32-bit machine nicer: "We're sorry, but your computer is too old to
install this 64-bit version of Fedora. Please download the legacy 32-bit
edition instead."
That would be an aweful first experience. Imagine her thoughts: "Oh. I
made something wrong.. Maybe it's nothing for me.."
I suggest to let it as it is and check the system (if 64bit or 32bit)
when it is running.
Maybe then a little popup comes up with something like:
"You're pc could be run faster, if you upgrade this operating system
to the 64bit version of it. You can download them here if you like:
[Link]"
Even better would be:
"You're pc could be run faster, if you upgrade this operating system
to the 64bit version of it. You can do so by clicking here: [Button]"
8:13 p.m.
Ikem Krueger wrote:
"You're pc could be run faster, if you upgrade this
operating system
to the 64bit version of it. You can download them here if you like:
[Link]"
That gives very little incentive to fetch the correct version. Making the
optimistic assumption and saying "I'm sorry, but this version won't
work" in
the failure case will definitely get everybody to use the optimal version
for their machine. And I think that by now the vast majority of our userbase
uses 64-bit-capable machines.
Kevin Kofler
3:44 p.m.
On 11/18/2009 09:22 PM, Ikem Krueger wrote:
> That gives very little incentive to fetch the correct version.
Why should a person bother with it, when a pc can do that?
Perhaps Kevin is advocating for a strategy that will reduce mirror
bandwidth? Of course there are a heck of a lot of variables in the
preceding sentence.
> > And I think that by now the vast majority of our userbase
uses 64-bit-capable machines.
I don't know. Maybe a poll would be good for that? :)
smolt would be good for that. It doesn't answer the question of when to
switch over of if that's a good idea.
Where would a check for proper bittedness be fit in the boot process?
Kernel boot is too late, I think. Grub? ISOLINUX?
Some simple guidance on the download page would be helpful.
"Are you installing Fedora on the computer you're using now?" [YES] [NO]
YES -> is any sort of check even possible if the user is running
32-bit on 64-bit?
NO -> offer guidance about date of manufacture, netbooks, re-visit the
page from LiveCD, and offer 32-bit as a "most compatible, I'm not sure"
link.
-Bill
--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.603.448.4440
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
5:39 p.m.
Bill McGonigle wrote:
"Are you installing Fedora on the computer you're using
now?" [YES] [NO]
YES -> is any sort of check even possible if the user is running
32-bit on 64-bit?
Yes, if the CPU has the lm (long mode) flag, it's a 64-bit-capable CPU and
using the 32-bit version is suboptimal.
Kevin Kofler
2:05 p.m.
On 11/19/2009 06:39 PM, Kevin Kofler wrote:
Yes, if the CPU has the lm (long mode) flag, it's a
64-bit-capable CPU and
using the 32-bit version is suboptimal.
how can this be checked from within a web browser? Trusted Java applet?
-Bill
--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.603.448.4440
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
10:27 a.m.
On Thu, 19 Nov 2009 17:39:16 -0600, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
Bill McGonigle wrote:
> "Are you installing Fedora on the computer you're using now?" [YES]
> [NO]
> YES -> is any sort of check even possible if the user is running
> 32-bit on 64-bit?
Yes, if the CPU has the lm (long mode) flag, it's a 64-bit-capable CPU
and
using the 32-bit version is suboptimal.
Kevin Kofler
But wouldn't it be better to use 32 bit when less then 4 GB of ram is
present?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
11:41 a.m.
On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd
<robinstar1574(a)gmail.com> wrote:
On Thu, 19 Nov 2009 17:39:16 -0600, Kevin Kofler
<kevin.kofler(a)chello.at>
wrote:
> Bill McGonigle wrote:
>>
>> "Are you installing Fedora on the computer you're using now?" [YES]
[NO]
>> YES -> is any sort of check even possible if the user is running
>> 32-bit on 64-bit?
>
> Yes, if the CPU has the lm (long mode) flag, it's a 64-bit-capable CPU and
> using the 32-bit version is suboptimal.
>
> Kevin Kofler
>
But wouldn't it be better to use 32 bit when less then 4 GB of ram is
present?
no, using x86_64 means more registers, sse2 as default floating point
instruction set, better calling convention (register passing vs.
stack) or in other words in most cases faster code.
11:47 a.m.
On 12/08/2009 06:41 PM, drago01 wrote:
On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd
<robinstar1574(a)gmail.com> wrote:
> On Thu, 19 Nov 2009 17:39:16 -0600, Kevin Kofler<kevin.kofler(a)chello.at>
> wrote:
>
>> Bill McGonigle wrote:
>>>
>>> "Are you installing Fedora on the computer you're using now?"
[YES] [NO]
>>> YES -> is any sort of check even possible if the user is running
>>> 32-bit on 64-bit?
>>
>> Yes, if the CPU has the lm (long mode) flag, it's a 64-bit-capable CPU and
>> using the 32-bit version is suboptimal.
>>
>> Kevin Kofler
>>
> But wouldn't it be better to use 32 bit when less then 4 GB of ram is
> present?
no, using x86_64 means more registers, sse2 as default floating point
instruction set, better calling convention (register passing vs.
stack) or in other words in most cases faster code.
That's one side, the other side is:
* Larger demands on RAM (x86_64 is more demanding on memory
requirements).
* More packages (rpms) to cope with.
* The "faster" is hardly sensible to ordinary users.
Ralf
1:02 p.m.
On Tue, Dec 8, 2009 at 12:47 PM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
That's one side, the other side is:
* Larger demands on RAM (x86_64 is more demanding on memory
requirements).
Even if it were a full doubling (which is the absolute worst case
possible), it would only be pushing the effective cost of memory back
roughly 18 months or so. In reality the increase should be much less
than 2x.
* More packages (rpms) to cope with.
Hmm? I'm not sure what you're talking about there. It's completely
reasonable to run an exclusively x86_64 system. I don't see why it
implies any more packages.
* The "faster" is hardly sensible to ordinary users.
You could equally say that the difference in memory consumption is not
relevant to most ordinary users.
Performance matters to everyone at least sometimes, but memory is only
a big issue when you don't have enough. I think very few people
running fedora are all that low on memory.
Fedora has already chosen to make the 32bit builds incompatible with
pre-686 systems for performance gains much smaller than you typically
get from x86_64 vs x86, so it seems that some people think that
performance is pretty important.
Even the most undemanding users care about performance in at least
some areas, for example on any given hardware x86_64 libtheora can
play larger videos than 32-bit. On some hardware x86_64 vs 32bit is
the difference between good and bad 1080p playback.
I think if your position is that most users don't care about
performance and other things (like compatibility) are more important
then you should strongly promote x86_64 Fedora for everyone who can
use it. If x86_64 fedora is widely used by those who can there will be
less pressure to put leading-edge but less compatible features into
the 32bit fedora build.
11:51 p.m.
On 12/08/2009 08:02 PM, Gregory Maxwell wrote:
On Tue, Dec 8, 2009 at 12:47 PM, Ralf
Corsepius<rc040203(a)freenet.de> wrote:
> That's one side, the other side is:
> * Larger demands on RAM (x86_64 is more demanding on memory
> requirements).
Even if it were a full doubling (which is the absolute worst case
possible), it would only be pushing the effective cost of memory back
roughly 18 months or so. In reality the increase should be much less
than 2x.
Correct - I didn't say "twice", I only said
"more".
On systems with smaller memory (or with soldered memory) this "more" can
be the "drop" which may be responsible for exceeding memory demands to
beyond physical memory and be the cause of swapping.
> * More packages (rpms) to cope with.
Hmm? I'm not sure what you're talking about there.
multilibs.
x86_64 means coping with more packages in an installation (ca. 1/3
more). This has an impact on maintenance complexity (parallel
installation of i386 packages), on metadata sizes (yum bandwith
demands), etc.
> * The "faster" is hardly sensible to ordinary users.
You could equally say that the difference in memory consumption is not
relevant to most ordinary users.
No. At the very point a system starts swapping,
memory consumption will
become sensible.
Fedora has already chosen to make the 32bit builds incompatible with
pre-686 systems for performance gains
Yes, a decision I consider to be a Fedora
managment mistake.
Seems to me, as if some people in Fedora's leadership don't want to
understand that being able to deploy Linux on "old" or "recycled"
hardware used to be one big selling point in Linux.
Certainly, Fedora devs tend to be equipped with modern HW, but it's a
mistake to believe everybody is.
I think if your position is that most users don't care about
performance and other things (like compatibility) are more important
then you should strongly promote x86_64 Fedora for everyone who can
use it.
Not quite. My position actually is: Most users don't care much about
1-2% improved performance nor about improved internals (more registers
etc.), as long as "their system" does what they want it to do.
That said, these users don't actually care about using 64bit or 32bit
Linux, as long as "their applications" behave "reasonable" and as long
as the OS is easy to use.
Or differently: I don't need a car with a 250kw engine and 7 seats to
drive to the supermarket. My 8-years of VW Polo with its 50kW engine
will also do ;)
Ralf
7:05 a.m.
On Wed, Dec 09, 2009 at 06:51:59 +0100,
Ralf Corsepius <rc040203(a)freenet.de> wrote:
Seems to me, as if some people in Fedora's leadership don't want to
understand that being able to deploy Linux on "old" or "recycled"
hardware used to be one big selling point in Linux.
I think the question is really, is Fedora suitable for being deployed
on older hardware? Currently it isn't (for some value of older).
I think if people wanted to try and make this happen, it could happen.
But it would be a lot of work and might be different enough that it
couldn't use the Fedora brand.
8:26 a.m.
On 12/09/2009 02:05 PM, Bruno Wolff III wrote:
On Wed, Dec 09, 2009 at 06:51:59 +0100,
Ralf Corsepius<rc040203(a)freenet.de> wrote:
> Seems to me, as if some people in Fedora's leadership don't want to
> understand that being able to deploy Linux on "old" or
"recycled"
> hardware used to be one big selling point in Linux.
>
I think the question is really, is Fedora suitable for being deployed
on older hardware?
In its early days, it was.
Currently it isn't (for some value of older).
Ageed, it isn't anymore. As I feel, <sarcasm> "Fedora has
followed up
Microsoft the Vista way" </sarcasm>
Those using modern hardware may find this "cool", those who don't,
switch away to using different distros.
I think if people wanted to try and make this happen, it could
happen.
<sigh> It wasn't a lot of work in the early Fedora day - It simply
worked out of the box! </sign>
However, some $DEITY's have decided otherwise ...
I am inclined to think "inevitably, because such platforms aren't the
platforms most developers use nor the platforms "RHEL is aiming at" ...
These people think in terms of "Quad machines" and "RH clients", but
forget about the amount of "old" machines which are still actively being
used and about "use-case niches".
Ralf
9:14 a.m.
On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote:
However, some $DEITY's have decided otherwise ...
I am inclined to think "inevitably, because such platforms aren't the
platforms most developers use nor the platforms "RHEL is aiming at" ...
These people think in terms of "Quad machines" and "RH clients", but
forget about the amount of "old" machines which are still actively being
used and about "use-case niches".
A+ for, eventually, coming to the obvious solution. Although,
personally, I haven't had a quad core yet all the computers I currently
have running are either laptops or dual cores. The minimum RAM size on
any of these 5 boxes is 2GB.
I'd be surprised to find that anyone working as a full time developer
has any (non-virt) boxes that are spec'd less than that.
And yes, shockingly, developers will test on the machines they have
easy access to.
So, yeh, if _you_ want to support slower machines ... _you_ will have
to do the work, you might get help from the community but just ranting
on f-d-l "Everyone should solve my problems" is unlikely to actually
help. IMO.
--
James Antill - james(a)fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.25
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
9:32 a.m.
On Wed, Dec 09, 2009 at 10:14:10 -0500,
James Antill <james(a)fedoraproject.org> wrote:
So, yeh, if _you_ want to support slower machines ... _you_ will have
to do the work, you might get help from the community but just ranting
on f-d-l "Everyone should solve my problems" is unlikely to actually
help. IMO.
I think the question is more about supporting machines with less memory
and processors that don't support all of the 686 instructions.
I have a couple of old laptops that I use at a gaming convention once a year
that have pentium 90s with 24MB of memory. I have redhat 6.2 on them,
but would have liked to have tried using Fedora on at least one of them.
But I wouldn't be able to use anaconda to do the install and I might need
to build a custom kernel to cut the memory needed down a bit. But I'll probably
just leave them as is and in a few years find some other old hand me down
laptop to replace them.
I also have a couple of low end routers that currently have ddwrt images
on them. When openwrt has 2.6 kernel broadcom support, I plan to switch
over to openwrt. But it would be cool to be able to run a Fedora based
router spin on them if such a thing existed. (Not cool enough for me to do
the development, as I have other things I want done more.)
9:51 a.m.
On 12/09/2009 07:14 AM, James Antill wrote:
... The minimum RAM size on any of these 5 boxes is 2GB.
I'd be surprised to find that anyone working as a full time developer
has any (non-virt) boxes that are spec'd less than that.
Surprise! I have 4 boxes that are 1GB or less (as low as 320MB),
and several that are 2GB or more.
And yes, shockingly, developers will test on the machines they have
easy access to.
Sometimes I doubt even that, particularly when shipped software
has python syntax errors (type mismatch, wrong number of arguments,
no such member, ...)
--
3:03 p.m.
John Reiser wrote:
Sometimes I doubt even that, particularly when shipped software
has python syntax errors (type mismatch, wrong number of arguments,
no such member, ...)
<rant>The joys of interpreted languages… In a compiled language, such an
error would just fail the build.</rant>
Kevin Kofler
3:07 p.m.
On Wed, Dec 9, 2009 at 10:03 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
John Reiser wrote:
> Sometimes I doubt even that, particularly when shipped software
> has python syntax errors (type mismatch, wrong number of arguments,
> no such member, ...)
<rant>The joys of interpreted languages… In a compiled language, such an
error would just fail the build.</rant>
where a sightly different error can lead to a segault or even a
exploitable security hole .... (or in short every language has it pros
and cons)
10:47 a.m.
On 12/09/2009 04:14 PM, James Antill wrote:
On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote:
So, yeh, if _you_ want to support slower machines
Well, I do
not want to, I can't avoid to ...
... _you_ will have
to do the work, you might get help from the community but just ranting
on f-d-l "Everyone should solve my problems" is unlikely to actually
help. IMO.
There is an easier solution: Stop using/promoting/advertising Fedora and
switch to a different distro ...
Ralf
10:51 a.m.
On Wed, 9 Dec 2009, Ralf Corsepius wrote:
On 12/09/2009 04:14 PM, James Antill wrote:
> On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote:
> So, yeh, if _you_ want to support slower machines
Well, I do not want to, I can't avoid to ...
> ... _you_ will have
> to do the work, you might get help from the community but just ranting
> on f-d-l "Everyone should solve my problems" is unlikely to actually
> help. IMO.
There is an easier solution: Stop using/promoting/advertising Fedora and
switch to a different distro ...
okay, for you, that sounds like it may be the best option. You are
obviously unhappy with fedora. We've appreciated your constructive
contributions but if you are no longer interested in working on/with
fedora, then we wish you well in your endeavors.
It would be most polite to officially orphan your packages before you go.
Thanks and good luck in the future.
-sv
11:05 a.m.
On 12/09/2009 05:51 PM, Seth Vidal wrote:
On Wed, 9 Dec 2009, Ralf Corsepius wrote:
> On 12/09/2009 04:14 PM, James Antill wrote:
>> On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote:
>
>> So, yeh, if _you_ want to support slower machines
> Well, I do not want to, I can't avoid to ...
>
>> ... _you_ will have
>> to do the work, you might get help from the community but just ranting
>> on f-d-l "Everyone should solve my problems" is unlikely to actually
>> help. IMO.
>
> There is an easier solution: Stop using/promoting/advertising Fedora
> and switch to a different distro ...
>
okay, for you, that sounds like it may be the best option. You are
obviously unhappy with fedora.
Did I say this? I am unhappy with Fedora's
management's decisions.
Technically, Fedora is quite usable (most of the time), on more or
modern machines.
We've appreciated your constructive
contributions but if you are no longer interested in working on/with
fedora, then we wish you well in your endeavors.
If I wasn't interested in
Fedora, I wouldn't complain. It's just that
Fedora increasingly diverges from my needs and increasingly is not
applicable for my purposes.
Less abstract: This development forces me to not recommend Fedora (or
RHEL) to customers.
It would be most polite to officially orphan your packages before you
go.
Thanks you for sheding more insights in how you intend to take community
interests into account.
10:51 a.m.
On 12/09/2009 10:17 PM, Ralf Corsepius wrote:
On 12/09/2009 04:14 PM, James Antill wrote:
> On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote:
> So, yeh, if _you_ want to support slower machines
Well, I do not want to, I can't avoid to ...
> ... _you_ will have
> to do the work, you might get help from the community but just ranting
> on f-d-l "Everyone should solve my problems" is unlikely to actually
> help. IMO.
There is an easier solution: Stop using/promoting/advertising Fedora and
switch to a different distro ...
Absolutely. Fedora can't be everything to everybody. If noone is willing
to do the work involved, try and find the tools to do the job better.
Just ranting isn't useful.
Rahul
1:27 p.m.
if _you_ want to support slower machines ... _you_ will have to do
the work, you might get help from the community but just ranting on f-d-l "Everyone
should solve my problems" is unlikely to actually help. IMO.
I would if I could. I can't program. Else I would just shutup and
would DO the work!
So the only thing I can do is "babel". Alternative I can just sit
there and see how the things become worse..
1:19 p.m.
> Fedora has already chosen to make the 32bit builds incompatible
with pre-686 systems for performance gains
Yes, a decision I consider to be a Fedora managment mistake.
Seems to me, as if some people in Fedora's leadership don't
want to understand that being able to deploy Linux on "old" or
"recycled" hardware used to be one big selling point in Linux.
Certainly, Fedora devs tend to be equipped with modern HW, but
it's a mistake to believe everybody is.
> I think if your position is that most users don't care about
performance and other things (like compatibility) are more important then you should
strongly promote x86_64 Fedora for everyone who can use it.
Not quite. My position actually is: Most users don't care much
about 1-2% improved performance nor about improved internals (more registers etc.), as
long as "their system" does what they want it to do.
That said, these users don't actually care about using 64bit or
32bit Linux, as long as "their applications" behave "reasonable" and
as long as the OS is easy to use.
Or differently: I don't need a car with a 250kw engine and 7
seats to drive to the supermarket. My 8-years of VW Polo with its 50kW engine will also do
;)
I totally agree with you. :)
2:26 p.m.
On Tuesday 08 December 2009, Kevin Kofler wrote:
Ralf Corsepius wrote:
> * More packages (rpms) to cope with.
Only if you pollute your system with 32-bit multilibs. A pure x86_64 system
doesn't have any more packages than a 32-bit one.
Fedora x86_64 repos do however carry ix86 packages around which shows in
metadata sizes and I guess to some extent in performance of some yum
operations. These probably aren't things to be generally overly concerned
about though, and maybe not even what Ralf meant (he specifically mentioned
rpms).
11:35 p.m.
On 12/08/2009 09:26 PM, Ville Skyttä wrote:
On Tuesday 08 December 2009, Kevin Kofler wrote:
> Ralf Corsepius wrote:
>> * More packages (rpms) to cope with.
>
> Only if you pollute your system with 32-bit multilibs. A pure x86_64 system
> doesn't have any more packages than a 32-bit one.
Fedora x86_64 repos do however carry ix86 packages around which shows in
metadata sizes and I guess to some extent in performance of some yum
operations.
and in ...
... bandwidth demands ...
... package dep conflicts resolution ...
... maintenance efforts (At the very point you have one true 32bit-only
capable machine around, installing x86_64 on a single machine means
duplicating the maintenance effort).
These probably aren't things to be generally overly concerned
about though,
... try a yum update over GSM or over a modem and you'll very
soon
experience what I am talking about.
and maybe not even what Ralf meant (he specifically mentioned
rpms).
I was indirectly referring to this (c.f. another thread on this list
earlier this week).
Ralf
12:37 p.m.
On Wednesday 09 December 2009, Ralf Corsepius wrote:
On 12/08/2009 09:26 PM, Ville Skyttä wrote:
> These probably aren't things to be generally overly
concerned
> about though,
... try a yum update over GSM or over a modem and you'll very soon
experience what I am talking about.
Been there, done that occasionally. Scenarios like that just don't happen to
be part of what I meant by "generally".
But I'd have nothing against "purifying" x86_64 repos and instructing people
who need something from ix86 repos to enable them as well. I suppose this is
something PackageKit could even suggest on demand. Anyway I also suppose that
if it was this simple, it would have been done already.
1:30 p.m.
On Wed, 9 Dec 2009, Ville Skyttä wrote:
On Wednesday 09 December 2009, Ralf Corsepius wrote:
> On 12/08/2009 09:26 PM, Ville Skyttä wrote:
>> These probably aren't things to be generally overly concerned
>> about though,
>
> ... try a yum update over GSM or over a modem and you'll very soon
> experience what I am talking about.
Been there, done that occasionally. Scenarios like that just don't happen to
be part of what I meant by "generally".
But I'd have nothing against "purifying" x86_64 repos and instructing
people
who need something from ix86 repos to enable them as well. I suppose this is
something PackageKit could even suggest on demand. Anyway I also suppose that
if it was this simple, it would have been done already.
if you want to purify x86_64 you can always add:
exclude=*.i[3456]86
to your yum.conf under [main]
-sv
2:39 p.m.
On Wednesday 09 December 2009, Seth Vidal wrote:
On Wed, 9 Dec 2009, Ville Skyttä wrote:
> But I'd have nothing against "purifying" x86_64 repos and instructing
> people who need something from ix86 repos to enable them as well. I
> suppose this is something PackageKit could even suggest on demand.
> Anyway I also suppose that if it was this simple, it would have been done
> already.
if you want to purify x86_64 you can always add:
exclude=*.i[3456]86
to your yum.conf under [main]
Yeah, I've done that in some setups but I was talking about purifying the
_repos_ above; that setting doesn't affect them, e.g. it doesn't make the
metadata to be downloaded any smaller. (As said, not that I think it's a big
general issue at all, but just that I'd personally have nothing against if it
would be "fixed" nevertheless.)
3:10 p.m.
Ville Skyttä wrote:
Yeah, I've done that in some setups but I was talking about
purifying the
_repos_ above; that setting doesn't affect them, e.g. it doesn't make the
metadata to be downloaded any smaller. (As said, not that I think it's a
big general issue at all, but just that I'd personally have nothing
against if it would be "fixed" nevertheless.)
Kicking out multilibs from the repos might also make it much faster to
compose updates repositories. A lot of time is wasted computing multilibs
now.
Kevin Kofler
3:49 p.m.
Once upon a time, Ville Skyttä <ville.skytta(a)iki.fi> said:
Yeah, I've done that in some setups but I was talking about
purifying the
_repos_ above; that setting doesn't affect them, e.g. it doesn't make the
metadata to be downloaded any smaller. (As said, not that I think it's a big
general issue at all, but just that I'd personally have nothing against if it
would be "fixed" nevertheless.)
One way to make this smaller (without any overlap) would be to split the
current two (i386 and x86_64) repos into three: i386-common, i386,
x86_64. For an i386 system, you use i386 and i386-common, for a
multilib x86_64 system you use x86_64 and i386-common, and for a pure
x86_64 system you use just x86_64.
I don't know if it is worth the trouble though.
--
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.
3:51 p.m.
On Wed, 9 Dec 2009, Chris Adams wrote:
Once upon a time, Ville Skyttä <ville.skytta(a)iki.fi> said:
> Yeah, I've done that in some setups but I was talking about purifying the
> _repos_ above; that setting doesn't affect them, e.g. it doesn't make the
> metadata to be downloaded any smaller. (As said, not that I think it's a big
> general issue at all, but just that I'd personally have nothing against if it
> would be "fixed" nevertheless.)
One way to make this smaller (without any overlap) would be to split the
current two (i386 and x86_64) repos into three: i386-common, i386,
x86_64. For an i386 system, you use i386 and i386-common, for a
multilib x86_64 system you use x86_64 and i386-common, and for a pure
x86_64 system you use just x86_64.
I don't know if it is worth the trouble though.
and then you have to do that as well for updates. :(
-sv
3:48 p.m.
Le mercredi 09 décembre 2009 à 14:30 -0500, Seth Vidal a écrit :
> if you want to purify x86_64 you can always add:
> exclude=*.i[3456]86
> to your yum.conf under [main]
However, it would be nice if a pure x86_64 index was generated somewhere
for people who run pure 64 bit systems and do not want to download 32
bit metadata all year round just to exclude it localy
--
Nicolas Mailhot
2:57 p.m.
Kevin Kofler wrote:
Ralf Corsepius wrote:
> * More packages (rpms) to cope with.
>
Only if you pollute your system with 32-bit multilibs. A pure x86_64 system
doesn't have any more packages than a 32-bit one. We don't even install
multilibs by default anymore.
Kevin Kofler
32-bit multilibs seems hard to avoid if you want to run wine.
1:07 p.m.
On Tue, 2009-12-08 at 18:41 +0100, drago01 wrote:
On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd
> But wouldn't it be better to use 32 bit when less then 4 GB
of ram is
> present?
no, using x86_64 means more registers, sse2 as default floating point
instruction set, better calling convention (register passing vs.
stack) or in other words in most cases faster code.
Indeed. Intel 64 (x86_64) is really a different animal. More registers,
different behaviors, and not just an LP64 version of what was there
before. I've spent the last few weeks finally reading the x86_64 docs on
my Kindle and really look forward to the older stuff just dying.
Jon.
8 a.m.
On Tuesday, 08 December 2009 at 20:07, Jon Masters wrote:
On Tue, 2009-12-08 at 18:41 +0100, drago01 wrote:
> On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd
> > But wouldn't it be better to use 32 bit when less then 4 GB of ram is
> > present?
>
> no, using x86_64 means more registers, sse2 as default floating point
> instruction set, better calling convention (register passing vs.
> stack) or in other words in most cases faster code.
Indeed. Intel 64 (x86_64) is really a different animal. More registers,
Actually, x86_64 is an AMD invention (originally called AMD64)
and is called EM64T by Intel. The only "Intel 64" I can think of
is IA64, i.e. Itanium (called "Itanic" by some).
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"
8:26 a.m.
Le Mer 9 décembre 2009 15:00, Dominik 'Rathann' Mierzejewski a écrit :
Actually, x86_64 is an AMD invention (originally called AMD64)
and is called EM64T by Intel. The only "Intel 64" I can think of
is IA64, i.e. Itanium (called "Itanic" by some).
When Intel realised Itanium was a failure, they dumped the ia32/ia64
classification and adopted x32/x64 (which is the same thing, except x64 !=
ia64, talk about hiding past mistakes)
--
Nicolas Mailhot
8:28 a.m.
On Wed, Dec 09, 2009 at 03:00:51PM +0100, Dominik 'Rathann' Mierzejewski wrote:
Actually, x86_64 is an AMD invention (originally called AMD64)
and is called EM64T by Intel. The only "Intel 64" I can think of
is IA64, i.e. Itanium (called "Itanic" by some).
http://www.intel.com/technology/intel64/
We have always been at war with Itanium,
--
Matthew Garrett | mjg59(a)srcf.ucam.org
5:20 a.m.
On Wednesday, 09 December 2009 at 22:11, Kevin Kofler wrote:
Dominik 'Rathann' Mierzejewski wrote:
> Actually, x86_64 is an AMD invention (originally called AMD64)
> and is called EM64T by Intel. The only "Intel 64" I can think of
> is IA64, i.e. Itanium (called "Itanic" by some).
EM64T was renamed to Intel 64 eons ago.
Call me a dinosaur, then. ;)
I stand corrected.
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"
9:29 a.m.
On Thu, Dec 10, 2009 at 12:20:28PM +0100, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 09 December 2009 at 22:11, Kevin Kofler wrote:
> Dominik 'Rathann' Mierzejewski wrote:
> > Actually, x86_64 is an AMD invention (originally called AMD64)
> > and is called EM64T by Intel. The only "Intel 64" I can think of
> > is IA64, i.e. Itanium (called "Itanic" by some).
>
> EM64T was renamed to Intel 64 eons ago.
Call me a dinosaur, then. ;)
I stand corrected.
Easy mistake to make considering it started as CT, then was IA-32e, then
EM64T, and finally Intel 64. All of them refer to the same thing at some
point.
Justin
8:30 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Another data point for this thread:
Running a 64-bit kernel with a 32-bit userland is a common practice on
non-x86 platforms, and non-Linux OS's. For a lot of tasks, you simply
do not need 64-bit pointers and a 64-bit process address space. Both
executable code and in-memory data structures tend to be smaller on 32-bit.
cp(1), for example, can be 32-bit as long as it supports O_LARGEFILE and
off64_t.
Jeff
8:55 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Jeff Garzik <jgarzik(a)pobox.com> said:
Running a 64-bit kernel with a 32-bit userland is a common practice
on
non-x86 platforms, and non-Linux OS's. For a lot of tasks, you simply
do not need 64-bit pointers and a 64-bit process address space. Both
executable code and in-memory data structures tend to be smaller on 32-bit.
However, on x86, the 32->64 bit jump also gives a larger register set
and (IIRC) SSE (or SSE2?) on all chips, which allows better code
generation for all kinds of things.
The i386 architecture is register-starved compared to many other
architectures.
--
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.
8:56 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Another data point for this thread:
x86 is unlike other architectures because 64-bit also has twice as many
registers as 32-bit. So you get to trade off the benefits of register
allocation across more registers against the memory/cache footprint of
64-bit pointers.
1:16 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On 11/18/2009 09:56 PM, Roland McGrath wrote:
> Another data point for this thread:
x86 is unlike other architectures because 64-bit also has twice as many
registers as 32-bit. So you get to trade off the benefits of register
allocation across more registers against the memory/cache footprint of
64-bit pointers.
Absolutely. x86-64 is definitely one of my favorite ISAs. Worlds
improvement from i386.
Jeff
12:34 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, 18 Nov 2009, Roland McGrath wrote:
x86 is unlike other architectures because 64-bit also has twice as
many registers as 32-bit. So you get to trade off the benefits of
register allocation across more registers against the memory/cache
footprint of 64-bit pointers.
For what percentage of code is that an appreciable advantage?
regards,
--
Paul Jakma paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
QOTD:
"If he learns from his mistakes, pretty soon he'll know everything."
12:53 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Paul Jakma <paul(a)dishone.st> writes:
On Wed, 18 Nov 2009, Roland McGrath wrote:
> x86 is unlike other architectures because 64-bit also has twice as
> many registers as 32-bit. So you get to trade off the benefits of
> register allocation across more registers against the memory/cache
> footprint of 64-bit pointers.
For what percentage of code is that an appreciable advantage?
Pretty much everything, actually. The x86 ISA completely sucks.
regards, tom lane
3:42 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 2009-12-13 at 13:53 -0500, Tom Lane wrote:
Paul Jakma <paul(a)dishone.st> writes:
> On Wed, 18 Nov 2009, Roland McGrath wrote:
>> x86 is unlike other architectures because 64-bit also has twice as
>> many registers as 32-bit. So you get to trade off the benefits of
>> register allocation across more registers against the memory/cache
>> footprint of 64-bit pointers.
> For what percentage of code is that an appreciable advantage?
Pretty much everything, actually. The x86 ISA completely sucks.
Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very
different beast. Intel fixed a lot of the issues with the (more than 20
year old really x86 ISA) and it's not simply a doubling of memory
footprint because variable width instructions are used in the first
place, and continue to be used in the newer ISA upgrade.
Personally, I think anyone running i386 on x86_64 who isn't doing some
kind of testing under KVM or similar is completely wasting their
computing resources and should receive a free copy of the Intel
documentation for the holidays ;)
Jon.
4:19 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Jon Masters <jonathan(a)jonmasters.org> said:
Indeed. Paul, take a look at the Intel 64 ISA and you'll see
it's a very
different beast. Intel fixed a lot of the issues with the (more than 20
year old really x86 ISA)
That would be AMD that fixed it, not Intel. Intel tried to push
everybody to a new architecture (Itanium), while AMD revised and
extended i386 to 64 bits. After Itanium failed to catch on in the
marketplace, Intel had to copy AMD's work.
--
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.
6:20 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, Dec 13, 2009 at 16:19:54 -0600,
Chris Adams <cmadams(a)hiwaay.net> wrote:
That would be AMD that fixed it, not Intel. Intel tried to push
everybody to a new architecture (Itanium), while AMD revised and
extended i386 to 64 bits. After Itanium failed to catch on in the
marketplace, Intel had to copy AMD's work.
I expect that has a lot to do with AMD being open source friendly. If they
had had to rely on Microsoft to get an OS to run on their machine, they
probably would have failed as well.
6:32 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, Dec 14, 2009 at 00:20, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Sun, Dec 13, 2009 at 16:19:54 -0600,
Chris Adams <cmadams(a)hiwaay.net> wrote:
>
> That would be AMD that fixed it, not Intel. Intel tried to push
> everybody to a new architecture (Itanium), while AMD revised and
> extended i386 to 64 bits. After Itanium failed to catch on in the
> marketplace, Intel had to copy AMD's work.
I expect that has a lot to do with AMD being open source friendly. If they
had had to rely on Microsoft to get an OS to run on their machine, they
probably would have failed as well.
Actually i think the reason AMDs approach worked was because it was
backward compatible with ix86 so instead of having to have an OS ready
up front and people having to migrate wholesale customers could start
upgrading to x86_64 processors slowly while still using 32bit OS. Then
as 64bit OS becomes available people can use that whilst still
enjoying their favorite apps that haven't yet been ported to 64bit. In
short it was evolutionary rather than revolutionary.
--
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
8:35 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, Dec 14, 2009 at 00:32:15 +0000,
John5342 <john5342(a)googlemail.com> wrote:
Actually i think the reason AMDs approach worked was because it was
backward compatible with ix86 so instead of having to have an OS ready
up front and people having to migrate wholesale customers could start
upgrading to x86_64 processors slowly while still using 32bit OS. Then
as 64bit OS becomes available people can use that whilst still
enjoying their favorite apps that haven't yet been ported to 64bit. In
short it was evolutionary rather than revolutionary.
I think that was also needed. But I don't think they would have been able to
get traction in the server market without having the prompt linux / gcc
support.
12:56 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 2009-12-13 at 16:19 -0600, Chris Adams wrote:
Once upon a time, Jon Masters <jonathan(a)jonmasters.org> said:
> Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very
> different beast. Intel fixed a lot of the issues with the (more than 20
> year old really x86 ISA)
That would be AMD that fixed it, not Intel. Intel tried to push
everybody to a new architecture (Itanium), while AMD revised and
extended i386 to 64 bits. After Itanium failed to catch on in the
marketplace, Intel had to copy AMD's work.
That's presumptuous and unfair. Sure, without AMD and others we'd likely
be on Itanium (which I actually quite like as an architecture) but Intel
64 isn't just some copy-and-paste effort either. Besides, whatever the
history we shouldn't be encouraging people to use plain older x86.
Jon.
10:42 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On 12/14/2009 01:56 AM, Jon Masters wrote:
On Sun, 2009-12-13 at 16:19 -0600, Chris Adams wrote:
> Once upon a time, Jon Masters<jonathan(a)jonmasters.org> said:
>> Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very
>> different beast. Intel fixed a lot of the issues with the (more than 20
>> year old really x86 ISA)
>
> That would be AMD that fixed it, not Intel. Intel tried to push
> everybody to a new architecture (Itanium), while AMD revised and
> extended i386 to 64 bits. After Itanium failed to catch on in the
> marketplace, Intel had to copy AMD's work.
That's presumptuous and unfair. Sure, without AMD and others we'd likely
be on Itanium (which I actually quite like as an architecture) but Intel
64 isn't just some copy-and-paste effort either.
I thought Intel adopted AMD 64-bit extensions pretty much wholesale. No
shame in that---they were well-designed and well engineered. We the CPU
consumers should be thankful for how well this was executed by both
Intel and AMD. Kudos to Intel for acting in the best interest of their
customers especially since they had so much invested in Itanium, both
financially and in term of company pride.
While Itanium (aka Itanic :) was well-intentioned and looked good on
paper, Intel/HP run into practical problems with the extent to which
VLIW can be exploited by compilers, and with the hardware
implementations, so that the actual performance is underwhelming. The
Itanium siren song contributed to demise of SGI and wobbliness of HP so
let's not be too nostalgic about it.
12:33 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, 18 Nov 2009, Jeff Garzik wrote:
Running a 64-bit kernel with a 32-bit userland is a common practice
on non-x86 platforms, and non-Linux OS's.
FWIW, it works on Linux too. I ran F10 i386 on a x86_64 kernel for a
while. About the only thing that doesn't work right is yum wrt kernel
updates.
For a lot of tasks, you simply do not need 64-bit pointers and a
64-bit process address space. Both executable code and in-memory
data structures tend to be smaller on 32-bit.
Indeed.
It would be nice if i386-userspace/x64-kernel were officially
support..
regards,
--
Paul Jakma paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
Blore's Razor:
Given a choice between two theories, take the one which is funnier.
12:41 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, Dec 13, 2009 at 7:33 PM, Paul Jakma <paul(a)dishone.st> wrote:
On Wed, 18 Nov 2009, Jeff Garzik wrote:
> Running a 64-bit kernel with a 32-bit userland is a common practice on
> non-x86 platforms, and non-Linux OS's.
FWIW, it works on Linux too. I ran F10 i386 on a x86_64 kernel for a while.
About the only thing that doesn't work right is yum wrt kernel updates.
> For a lot of tasks, you simply do not need 64-bit pointers and a 64-bit
> process address space. Both executable code and in-memory data structures
> tend to be smaller on 32-bit.
Indeed.
It would be nice if i386-userspace/x64-kernel were officially support..
such a setup does not make much sense, when your hardware supports
x86_64 not using it for userspace is a waste ....
1:16 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 13 Dec 2009, drago01 wrote:
such a setup does not make much sense, when your hardware supports
x86_64 not using it for userspace is a waste ....
a) i386 has a lower memory footprint, as has been mentioned in this
thread.
b) The amount of code on your system that is CPU bound and/or
memory-bound due to register pressure, to an extent that the x64
registers would make an appreciable difference is probably not
that significant
- kernel hotpots
- graphics hotspots (X server perhaps)
I havn't measured this, but nor have the people who say x86_64 is
faster AFAICT, and there's plenty of experience to say that most
software is far from CPU bound or memory bound.
c) There is a definite cost to a distro in having to maintain 2
x86_64 and i386 as separate arches
- QA
- package building and distribution
Every supported arch increases the size of the test matrix.
Minimising the number of arches you have to, say, test a "cp"
bugfix against helps reduce QA load and helps you get better
software to your users, faster (better cause you release time
spent on architecture QA that can be spent on improving software
generally).
d) Like or not, i386 is the de-facto standard for binary interfaces:
- Netscape plugins
- Windows executables
The retort no doubt will "Oh but this is Fedora, we don't care
about any closed-source stuff", but that would miss the point
entirely re *Interface*. The i386 machine can be a plugin
interface between 2 different open-source systems, e.g. consider:
- VM images to run in, say, QEMU/KVM
- Sandboxing technologies for, say, browser plugins (I think
Google have stuff in this area)
- Free software windows-only apps (don't know if they exist)
All the code here can be open-source/free-software and still be
relying on i386 as a widely known and hence convenient
/interface/. As such, it likely needs to be supported on x86_64
kernel-based systems anyway, as performantly as possible. (And
yeah, I gather KVM x86_64 doesn't work for i386 VMs - annoying).
So personally I think x86_64-pure is unrealistic and, independently,
I think 32-on-64 makes sense, but hey. :)
regards,
--
Paul Jakma paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
He who despises himself nevertheless esteems himself as a self-despiser.
-- Friedrich Nietzsche
1:27 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 13 Dec 2009, Paul Jakma wrote:
b) The amount of code on your system that is CPU bound and/or
memory-bound due to register pressure, to an extent that the x64
faster AFAICT, and there's plenty of experience to say that
most
software is far from CPU bound or memory bound.
Oops, this is unclear - "memory bound" here in these 2 cases refers
to memory-I/O, not amount of memory.
regards,
--
Paul Jakma paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
Plus ,ca change, plus c'est la m^eme chose.
[The more things change, the more they remain the same.]
-- Alphonse Karr, "Les Gu^epes"
2:09 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, Dec 13, 2009 at 8:16 PM, Paul Jakma <paul(a)dishone.st> wrote:
On Sun, 13 Dec 2009, drago01 wrote:
> such a setup does not make much sense, when your hardware supports x86_64
> not using it for userspace is a waste ....
a) i386 has a lower memory footprint, as has been mentioned in this
thread.
Yes which is pretty much the only valid complaint but trading memory
for performance is a price I am willing to take ...
b) The amount of code on your system that is CPU bound and/or
memory-bound due to register pressure, to an extent that the x64
registers would make an appreciable difference is probably not
that significant
- kernel hotpots
The kernel doesn't do any have computing...
- graphics hotspots (X server perhaps)
I havn't measured this, but nor have the people who say x86_64 is
faster AFAICT, and there's plenty of experience to say that most
software is far from CPU bound or memory bound.
Yes but the stuff adds up, you gain almost nothing by running i686
code but where it matters x86_64 can make a HUGE difference.
c) There is a definite cost to a distro in having to maintain 2
x86_64 and i386 as separate arches
Not a reason to move forward with hardware development.
d) Like or not, i386 is the de-facto standard for binary interfaces:
- Netscape plugins
This is slowly being fixed.
- Windows executables
Nobody stops you from running i386 apps on a x86_64 system.
- VM images to run in, say, QEMU/KVM
- Sandboxing technologies for, say, browser plugins (I think
Google have stuff in this area)
- Free software windows-only apps (don't know if they exist)
All the code here can be open-source/free-software and still be
relying on i386 as a widely known and hence convenient
/interface/. As such, it likely needs to be supported on x86_64
kernel-based systems anyway, as performantly as possible. (And
yeah, I gather KVM x86_64 doesn't work for i386 VMs - annoying).
Er.. don't quite get your point here, what is stopping me from running
i686 VMs on a x86_64 host?
I have been doing this for a while and there are there problems (you
don't even need multilib for that)
So personally I think x86_64-pure is unrealistic and, independently,
I think
32-on-64 makes sense, but hey. :)
I did not suggest using pure x86_64 but using x86_64 where we can (ie.
not just the kernel).
2:10 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, Dec 13, 2009 at 9:09 PM, drago01 <drago01(a)gmail.com> wrote:
> c) There is a definite cost to a distro in having to maintain 2
> x86_64 and i386 as separate arches
Not a reason to move forward with hardware development.
reason to _not_ move ...
Er.. don't quite get your point here, what is stopping me from
running
i686 VMs on a x86_64 host?
I have been doing this for a while and there are there problems (you
don't even need multilib for that)
should read _zero_ problems.
3:35 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Paul Jakma <paul(a)dishone.st> said:
b) The amount of code on your system that is CPU bound and/or
memory-bound due to register pressure, to an extent that the x64
registers would make an appreciable difference is probably not
that significant
- kernel hotpots
- graphics hotspots (X server perhaps)
I havn't measured this, but nor have the people who say x86_64 is
faster AFAICT, and there's plenty of experience to say that most
software is far from CPU bound or memory bound.
As soon as you bring in even one 64 bit user-space program that is run
much, you've pulled in at least glibc and friends. At that point, you
might as well run all (or as close to all as possible) 64 bit
user-space, because the libraries are shared (code will be in the cache,
etc.).
The only time my systems have run 32 bit code in several years is for
the Flash plugin (since the open-source plugins don't seem to be able to
keep up and since the 64 bit Adobe plugin doesn't seem to get the
security updates) and sometimes the Acrobat Reader plugin (since I've
run into websites that assume they can embed PDFs in the page and AFAIK
there's no plugin for Evince).
Since both cases are not all that common in my every-day use, I don't
hit the 32 bit libraries and such very often. Running a single-arch and
single-lib system is more efficient.
As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it
much in the real world. I have one 32 bit desktop at work, and
comparing the resident RAM usage between it and a 64 bit desktop, I
don't see much difference in the common desktop programs. I know that
for some reason PHP on 64 bit arches bloats up significantly (at least
older versions), but that's the only major difference I've seen.
--
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.
4:24 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 13 Dec 2009, Chris Adams wrote:
As soon as you bring in even one 64 bit user-space program that is
run
much, you've pulled in at least glibc and friends. At that point, you
might as well run all (or as close to all as possible) 64 bit
user-space, because the libraries are shared (code will be in the cache,
etc.).
That's assuming that the footprint of libraries relative to distinct
applications is large enough to cancel out the space savings. (I have
no data either way). A 64bit kernel doesn't need any 32bit userspace.
An X server, on my 32bit system has about 8.5MB of programme text
(server and libs) and loads about another 1.5MB worth of modules
itself, i.e. 10MB.
So if you ran a 32bit system with a 64bit kernel and X server, you'd
lose out on about 10MB of shareable code. For comparison, my 32bit
system has O(10) times that allocated to things like browsers and
feed-readers. It's using 4.8GB in total (ex buffers/cache)
apparently.
Space for text (programmes, code) is simply insignificant these days,
compared to the huge amounts of data which programmes allocate - data
which sometimes includes a lot of pointers.
You're also assuming that this cancels out the other benefits.
The only time my systems have run 32 bit code in several years is
for
the Flash plugin (since the open-source plugins don't seem to be able to
keep up and since the 64 bit Adobe plugin doesn't seem to get the
security updates) and sometimes the Acrobat Reader plugin (since I've
run into websites that assume they can embed PDFs in the page and AFAIK
there's no plugin for Evince).
It's interesting that both you and drago have "almost always" (to
paraphrase) run 64bit pure systems. Surely that *reinforces* my point
about the futility of "64bit pure systems" as an achievable goal (in
the aggregate across all reasonable uses of a distro), and i386 being
a de-facto standard for software interfaces.
As for the RAM overhead of 64 bit code vs. 32 bit code, I don't
see it
much in the real world. I have one 32 bit desktop at work, and
comparing the resident RAM usage between it and a 64 bit desktop, I
don't see much difference in the common desktop programs.
That's the wrong comparison - compare the aggregate RAM usage, with
each system in similar states.
I know that for some reason PHP on 64 bit arches bloats up
significantly (at least older versions), but that's the only major
difference I've seen.
Pointer rich data structures, likely..
Anyway, as I don't intend to contribute anything, I'll try stop
making noise.
Aside to the list: Thanks for all the hard-work on Fedora ;)
regards,
--
Paul Jakma paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
Dogs just don't seem to be able to tell the difference between important people
and the rest of us.
5:26 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
That's assuming that the footprint of libraries relative to
distinct
applications is large enough to cancel out the space savings. (I have no
data either way). A 64bit kernel doesn't need any 32bit userspace. An X
server, on my 32bit system has about 8.5MB of programme text (server and
libs) and loads about another 1.5MB worth of modules itself, i.e. 10MB.
Regarding shared libraries its worth noting the point about
"Instruction pointer relative data access":
http://en.wikipedia.org/wiki/X86-64#Architectural_features
Cheers,
Debarshi
--
One reason that life is complex is that it has a real part and an
imaginary part.
-- Andrew Koenig
6:33 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Debarshi Ray wrote:
Regarding shared libraries its worth noting the point about
"Instruction pointer relative data access":
http://en.wikipedia.org/wiki/X86-64#Architectural_features
You're missing the point.
If I put you in front of 2 identical machines, one running 32bit and
one 64bit software, would you be able to tell which one was which,
from the interactive performance of common applications? I'd be
willing to bet that for the vast majority of applications you
wouldn't be.
The point is that few applications need to be 64bit (this may change
in time, when email and browser apps start to demand 4GB+, but that
time is a while away - per-process memory demands should stay flat
for a while if browsers and the like switch from
single-process/multi-threaded to a multi-processes model).
For the few apps where it makes a difference, sure, run them as
64bit.
(Also, please assume in any replies that I have a modicum of clue
about the low-level technical details between i386 and x86_64).
regards,
--
Paul Jakma paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
magnetic interferance from money/credit cards
9:07 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Paul Jakma <paul(a)dishone.st> said:
If I put you in front of 2 identical machines, one running 32bit and
one 64bit software, would you be able to tell which one was which,
from the interactive performance of common applications? I'd be
willing to bet that for the vast majority of applications you
wouldn't be.
Then you might as well run the native system architecture, which is 64
bit, rather than try to figure out which apps run better as 32 bit and
maintain a full duplicate set of libraries! :-)
--
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.
10:12 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, Dec 14, 2009 at 7:33 AM, Paul Jakma <paul(a)dishone.st> wrote:
If I put you in front of 2 identical machines, one running 32bit
and one 64bit software, would you be able to tell which one was
which, from the interactive performance of common applications? I'd
be willing to bet that for the vast majority of applications you
wouldn't be.
Yet I could tell from the applications where performance is important.
You reject my metric, I reject yours. Something of an impasse.
[snip]
time, when email and browser apps start to demand 4GB+, but that time
is a
while away
I enjoyed how in nearly one breath you claim that performance is usually
irrelevant then go on to name an application where performance is quite
visible: A considerable amount of page load time is browser rendering.
(It's also not too hard to make firefox use more than 3GB of virtual
address space, though I admit you do need to work at it a little)
What was the point of this conversation again?
People have demonstrated on this list, with benchmarks, that x86_64 makes a
material performance improvement across a broad swath of applications where
performance matters.
You point out that users don't care about performance in many cases. I do not
disagree but I have no clue how we can qualify or quantify that.
Certainly, when some website posts benchmarks of Fedora vs other distribution
those threads get a lot of discussion but that isn't really evidence.
I also do not know how it is relevant, in context of x86_64, to Fedora as the
use of x86_64 is effectively free. The costs, such as reduced compatibility
with binary browser plugins, are simply not relevant to many people.
You're obviously convinced of your opinion, other people hold the view that
good performance is part of the distribution's core job.
Other than the point that x86_64 also increases security (from greatly
increased address space layout randomization, and reduced PIE cost), I think
we've hit on every point for and against using x86_64 in this thread— yet
I think not a single person has changed their initial view.
I don't see how any resolution is going to come from further discussion.
11:18 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Gregory Maxwell wrote:
Yet I could tell from the applications where performance is
important.
You reject my metric, I reject yours. Something of an impasse.
I'm not rejecting the performance metric at all.
(It's also not too hard to make firefox use more than 3GB of
virtual
address space, though I admit you do need to work at it a little)
Only because it's obsolete. Multi-process browsers use a lot less
RAM per process.
What was the point of this conversation again?
For those who can't sort by thread in their MUA: To ask that
32-userspace-on-64 be supported (it pretty much all works, except for
yum updating certain things, like the kernel), as there are definite
benefits to a 32-by-default userspace.
Some people chose to argue "But you should just run 64bit
completely", despite people already having described one reason to
32bit (memory usage). And from that we somehow got into a "x86_64
versus x86" thread of doom, with (IMHO) much missing of the general
point.
Anyway, enough.
regards,
--
Paul Jakma paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
Where do you go to get anorexia?
-- Shelley Winters
12:34 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, Dec 14, 2009 at 05:18:47PM +0000, Paul Jakma wrote:
For those who can't sort by thread in their MUA: To ask that
32-userspace-on-64 be supported (it pretty much all works, except for
yum updating certain things, like the kernel), as there are definite
benefits to a 32-by-default userspace.
There's little testing effort done on this. People still occasionally
trip over bugs in the ioctl conversion code in the kernel, and there's a
couple of other cases where exported ABI doesn't get converted
correctly. Now, while it's undeniable that these are bugs that should be
fixed, it's also pretty difficult to justify adding a third x86 variant
to our list of supported configurations, especially when it's known to
be more problematic than the other two that already satisfy almost
everybody's needs.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:50 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 2009-12-14 at 12:33 +0000, Paul Jakma wrote:
You're missing the point.
If I put you in front of 2 identical machines, one running 32bit and
one 64bit software, would you be able to tell which one was which,
from the interactive performance of common applications? I'd be
willing to bet that for the vast majority of applications you
wouldn't be.
That's a silly argument, because it simply relies on the fact that most
uses of computers aren't CPU-bound at all. In the same way I could
probably steal half the RAM from your system and clock the CPU down 50%
(the BOFH's favourite revenue-generating technique!) and from 'the
interactive performance of common applications' you wouldn't be able to
tell the difference. I don't think that _means_ very much, though.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:17 p.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Adam Williamson wrote:
On Mon, 2009-12-14 at 12:33 +0000, Paul Jakma wrote:
> You're missing the point.
>
> If I put you in front of 2 identical machines, one running 32bit and
> one 64bit software, would you be able to tell which one was which,
> from the interactive performance of common applications? I'd be
> willing to bet that for the vast majority of applications you
> wouldn't be.
That's a silly argument, because it simply relies on the fact
that most
uses of computers aren't CPU-bound at all. In the same way I could
probably steal half the RAM from your system and clock the CPU down 50%
(the BOFH's favourite revenue-generating technique!) and from 'the
interactive performance of common applications' you wouldn't be able to
tell the difference. I don't think that _means_ very much, though.
It's quite meaningful, e.g. for power conservation. As you no doubt
are aware of, modern system regularly clock down the CPU.
regards,
--
Paul Jakma paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
It occurred to me lately that nothing has occurred to me lately.
1:43 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Hi.
On Sun, 13 Dec 2009 15:35:27 -0600, Chris Adams wrote:
The only time my systems have run 32 bit code in several years is
for
the Flash plugin (since the open-source plugins don't seem to be able
to keep up and since the 64 bit Adobe plugin doesn't seem to get the
security updates)
It does. There may not be a yum repo for it, but the last update was some
days ago to 10.0 r42, similar to the 32 bit version.
3:27 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le Dim 13 décembre 2009 22:35, Chris Adams a écrit :
As for the RAM overhead of 64 bit code vs. 32 bit code, I don't
see it
much in the real world.
The worst case I've seen reported is when the RAM overhead managed to
annihilate register improvements (worst case in a very specific load). So "RAM
overhead" is pretty much a urban myth on x86_64
--
Nicolas Mailhot
5:51 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On 12/14/2009 10:27 AM, Nicolas Mailhot wrote:
Le Dim 13 décembre 2009 22:35, Chris Adams a écrit :
> As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it
> much in the real world.
The worst case I've seen reported is when the RAM overhead managed to
annihilate register improvements (worst case in a very specific load). So "RAM
overhead" is pretty much a urban myth on x86_64
It's not an urban myth - Conversely, it can quite easily be proven:
int main()
{
long i;
void *array[1000000];
for ( i = 0; i < 1000000; i++ ) {
array[i] = (void*) i;
};
while(1) {};
}
Compile this snippet for -m64/-m32:
# gcc -m64 -o test-64 -Wall test.c
# gcc -m32 -o test-32 -Wall test.c
Then run them and watch memory consumption (here "top"):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5909 corsepiu 20 0 11536 8128 248 R 100.0 0.4 0:16.93 test-64
5903 corsepiu 20 0 5560 4180 224 R 99.0 0.2 1:10.20 test-32
QED
Of course, this is an extreme case, but they also aren't "that rare" in
real world cases.
Ralf
6:16 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Ralf Corsepius wrote:
Of course, this is an extreme case,
It isn't that extreme - pointers can make up a significant component
of data-structures. E.g. any programme that has to store many
instances of small amounts of data, the pointer size can have a big
impact on memory usage. If the data is heavily inter-linked, even
more so.
Whether that's the case for most applications, I do not know however.
It would though be interesting for someone to go measure this,
especially in the aggregate.
regards,
--
Paul Jakma paul(a)jakma.org Key ID: 64A2FF6A
Fortune:
If this is timesharing, give me my share right now.
6:31 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le Lun 14 décembre 2009 12:51, Ralf Corsepius a écrit :
Of course, this is an extreme case, but they also aren't
"that rare" in
real world cases.
They aren't "that rare" on very specific workloads (numeric computation).
People in those fields often have large datasets that appreciate lots of
memory (ours work with GiB-sized datasets at least)
--
Nicolas Mailhot
7:23 a.m.
New subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le Lun 14 décembre 2009 13:31, Nicolas Mailhot a écrit :
Le Lun 14 décembre 2009 12:51, Ralf Corsepius a écrit :
> Of course, this is an extreme case, but they also aren't "that rare"
in
> real world cases.
They aren't "that rare" on very specific workloads (numeric computation).
People in those fields often have large datasets that appreciate lots of
memory (ours work with GiB-sized datasets at least)
BTW, I didn't claim the overhead didn't exist, just that it was more than
compensated in practice by access to more memory and architecture improvements
in real world use cases (for the people who care about performance, ie people
who are ready to buy a ram stick to win a few percentages in speed tests. If
speed is not worth a ram stick for you given today's ridiculous ram prices you
should not argue in some percentages more or less in processing times)
--
Nicolas Mailhot
5:56 a.m.
Kevin Kofler wrote:
Ikem Krueger wrote:
> "You're pc could be run faster, if you upgrade this operating system
> to the 64bit version of it. You can download them here if you like:
> [Link]"
That gives very little incentive to fetch the correct version. Making the
optimistic assumption and saying "I'm sorry, but this version won't
work" in
the failure case will definitely get everybody to use the optimal version
for their machine. And I think that by now the vast majority of our userbase
uses 64-bit-capable machines.
And, "upgrading to 64bit" actually means "reinstall everything from
scratch"
as a 32->64 upgrade is still impossible, right?
The only reasonable approach is a download panel like:
64bit version, for hardware with 64 bit support such as: (general guidelines)
- desktops newer than 2005
- laptops newer than 2006
- netbooks newer than 2008
[maybe with more accurate dates or rules]
32bit version, for hardware without 64 bit support such as: (general guidelines)
- old machines
- small netbooks
Unsure about this choice?
- the machine you are using now {is 64 bit / is not 64 bit} (so we preselected this
choice for you)
- to check another machine, download this tool and run it
This is supposing the hardware capability (not simply the 64bitness of the
current O.S.) is detectable in a browser; if not the tool has to be used.
The tool can be a small windows exec / small linux script; in alternative,
it could be a small ISO image fedora-detect-arch.iso which just prints
"this machine is 64 bit capable" or "this machine is not 64 bit
capable".
I would also suggest to avoid framing the difference as
32 bit / 64 bit
but use a more aggressive
64 bit capable, 64 bit uncapable
if we want to promote x86_64.
Finally, saying:
- 32 bit (it will run everywhere)
- 64 bit (maybe it will not run)
is definitely the worst way. :-)
Best regards.
--
Roberto Ragusa mail at robertoragusa.it
8:13 p.m.
On Wed, Nov 18, 2009 at 8:04 PM, Ikem Krueger
<ikem.krueger(a)googlemail.com>wrote:
> IMHO, the right solution is to make the 64-bit edition the
default
download
> and to work on making the error message people get when trying to install
it
> on a 32-bit machine nicer: "We're sorry, but your computer is too old to
> install this 64-bit version of Fedora. Please download the legacy 32-bit
> edition instead."
That would be an aweful first experience. Imagine her thoughts: "Oh. I
made something wrong.. Maybe it's nothing for me.."
I suggest to let it as it is and check the system (if 64bit or 32bit)
when it is running.
Maybe then a little popup comes up with something like:
"You're pc could be run faster, if you upgrade this operating system
to the 64bit version of it. You can download them here if you like:
[Link]"
Even better would be:
"You're pc could be run faster, if you upgrade this operating system
to the 64bit version of it. You can do so by clicking here: [Button]"
Except, that could be false advertising. In most cases, where CPU
computation is not used heavily, 64-bit is actually SLOWER than the 32-bit
counterpart. Optimizations are narrowing the gap, but it still remains
true.
8:23 p.m.
On Wed, Nov 18, 2009 at 8:18 PM, Ikem Krueger
<ikem.krueger(a)googlemail.com>wrote:
> Except, that could be false advertising. In most cases, where
CPU
> computation is not used heavily, 64-bit is actually SLOWER than the
32-bit
> counterpart. Optimizations are narrowing the gap, but it still remains
> true.
Why then should someone prefer 64bit over 32bit?
4 Reasons:
1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not really
affecting us much, most of us will replace our PCs long before then)
2: Access more than 4GB of RAM (definitely becoming increasingly important)
3: Enhanced performance-critical computational capabilities (if you do a lot
of complex HD photo, HD video, or HD audio work, or if you do a lot of raw
complex math on your computer, this is EXTREMELY important)
4: Better virtual machine performance
8:30 p.m.
> Why then should someone prefer 64bit over 32bit?
4 Reasons:
1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038
(not really affecting us much, most of us will replace our PCs long before then)
What do the people with 32bit cpus who won't/can't upgrade?
2: Access more than 4GB of RAM (definitely becoming increasingly
important)
I hope for the apps, not for the system. I don't want to become Linux
the next Vista..
3: Enhanced performance-critical computational capabilities (if you
do a lot of complex HD photo, HD video, or HD audio work, or if you do a lot of raw
complex math on your computer, this is EXTREMELY important)
4: Better virtual machine performance
Thanks for the answer. :)
9:44 p.m.
On Wed, Nov 18, 2009 at 8:30 PM, Ikem Krueger
<ikem.krueger(a)googlemail.com>wrote:
>> Why then should someone prefer 64bit over 32bit?
> 4 Reasons:
> 1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not
really affecting us much, most of us will replace our PCs long before then)
What do the people with 32bit cpus who won't/can't upgrade?
Then the Y2k38 problem occurs, which is what the theoretical Y2K problem
would have been.
> 2: Access more than 4GB of RAM (definitely becoming
increasingly
important)
I hope for the apps, not for the system. I don't want to become Linux
the next Vista..
It isn't the OS itself that will be requiring more than 4GB of RAM (at least
I hope not in Linux, Windows is a lost cause... Perhaps ReactOS will pull it
off?), but rather the applications used on the computer. Nowadays, it isn't
unusual for applications to require at least 512MB of RAM. That builds up,
quite quickly.
> 3: Enhanced performance-critical computational capabilities (if you do a
lot of complex HD photo, HD video, or HD audio work, or if you do a lot of
raw complex math on your computer, this is EXTREMELY important)
> 4: Better virtual machine performance
Thanks for the answer. :)
You're welcome ;)
1:03 a.m.
> What do the people with 32bit cpus who won't/can't
upgrade?
Then the Y2k38 problem occurs, which is what the theoretical Y2K
problem
would have been.
No. I meant, what is the solution?
Can't we not just write down the time somewhere and began to count the
time from "zero"? o.O
Nowadays, it isn't unusual for applications to require at least
512MB of RAM. That builds up, quite quickly.
I have only 512MB RAM and I think it is more then enough! And I don't
plan to upgrade. If the app eats all my memory, I look for an
alternative!
4:08 a.m.
Hi.
On Wed, 18 Nov 2009 20:23:31 -0600, King InuYasha wrote:
1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038
(not
really affecting us much, most of us will replace our PCs long before
then)
As much as I am in favour of 64 bit, but that is a red herring. 32bit
systems are perfectly capable of handling 64bit values. The problem
here is all the existing software which assumes that a time_t is 32
bit. Or have not been using time_t but (u)int32_t (if you're luck) or
int (if you're unlucky).
3:13 p.m.
On 11/18/2009 09:23 PM, King InuYasha wrote:
On Wed, Nov 18, 2009 at 8:18 PM, Ikem Krueger
<ikem.krueger(a)googlemail.com <mailto:ikem.krueger@googlemail.com>> wrote:
> Except, that could be false advertising. In most cases, where CPU
> computation is not used heavily, 64-bit is actually SLOWER than
the 32-bit
> counterpart. Optimizations are narrowing the gap, but it still remains
> true.
Why then should someone prefer 64bit over 32bit?
4 Reasons:
1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not
really affecting us much, most of us will replace our PCs long before then)
I believe even 32-bit kernels now keep the time in a 64-bit integer. This shouldn't
apply any more.
2: Access more than 4GB of RAM (definitely becoming increasingly
important)
The 4GB limit is only on processes. Most recent 32-bit Intels can address 32GB of system
memory. Not necessarily relevant, but a win for Linux (Microsoft never figured out how to
make this work :).
--CJD
3:21 p.m.
On 11/19/2009 04:13 PM, Casey Dahlin wrote:
On 11/18/2009 09:23 PM, King InuYasha wrote:
> On Wed, Nov 18, 2009 at 8:18 PM, Ikem Krueger
>
> 1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not
> really affecting us much, most of us will replace our PCs long before then)
I believe even 32-bit kernels now keep the time in a 64-bit integer.
This shouldn't apply any more.
Sure it does -- time_t in userland is 32-bit, and that's what applications
are using, and what the system call interface supports.
--
Peter
Any connection between your reality and mine is purely coincidental.
3:22 p.m.
On 11/19/2009 04:21 PM, Peter Jones wrote:
On 11/19/2009 04:13 PM, Casey Dahlin wrote:
> On 11/18/2009 09:23 PM, King InuYasha wrote:
>> On Wed, Nov 18, 2009 at 8:18 PM, Ikem Krueger
>>
>> 1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not
>> really affecting us much, most of us will replace our PCs long before then)
>
> I believe even 32-bit kernels now keep the time in a 64-bit integer.
> This shouldn't apply any more.
Sure it does -- time_t in userland is 32-bit, and that's what applications
are using, and what the system call interface supports.
Problematic, but we do have 29 years to fix it :)
--CJD
3:24 p.m.
On Thu, Nov 19, 2009 at 10:22 PM, Casey Dahlin <cdahlin(a)redhat.com> wrote:
On 11/19/2009 04:21 PM, Peter Jones wrote:
> On 11/19/2009 04:13 PM, Casey Dahlin wrote:
>> On 11/18/2009 09:23 PM, King InuYasha wrote:
>>> On Wed, Nov 18, 2009 at 8:18 PM, Ikem Krueger
>>>
>>> 1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not
>>> really affecting us much, most of us will replace our PCs long before then)
>>
>> I believe even 32-bit kernels now keep the time in a 64-bit integer.
>> This shouldn't apply any more.
>
> Sure it does -- time_t in userland is 32-bit, and that's what applications
> are using, and what the system call interface supports.
>
Problematic, but we do have 29 years to fix it :)
Hah ... yeah because 32bit machines will be relevant by then...
Can I complain that fedora does not work on my 29+ years old system
right now (that I don't even have)
3:42 p.m.
Dnia 2009-11-19, o godz. 16:13:39
Casey Dahlin <cdahlin(a)redhat.com> napisał(a):
The 4GB limit is only on processes. Most recent 32-bit Intels can
address
32GB of system memory. Not necessarily relevant, but a win for Linux
(Microsoft never figured out how to make this work :).
"Most recent" is
over 10 years and actually, the limit is 64 GB.
And Microsoft never had to "figure it out", they've supported PAE in
Windows
2000 and XP up to SP1 IIRC, then made a marketing decision to disable it on
desktop systems with XP SP2:
http://www.geoffchappell.com/viewer.htm?doc=notes/windows/license/memory.htm
Lam, a happy i686 user
3:50 p.m.
On Thu, Nov 19, 2009 at 04:13:39PM -0500, Casey Dahlin wrote:
Most recent 32-bit Intels can address 32GB of system memory.
It might be possible, but it's really not a good idea.
Even 16GB is pushing it. At that point, your lower 1GB of memory is so full
of page structs, that quickly invoking the oom-killer is inevitable.
Dave
3:54 p.m.
On 11/19/2009 04:50 PM, Dave Jones wrote:
On Thu, Nov 19, 2009 at 04:13:39PM -0500, Casey Dahlin wrote:
> Most recent 32-bit Intels can address 32GB of system memory.
It might be possible, but it's really not a good idea.
Even 16GB is pushing it. At that point, your lower 1GB of memory is so full
of page structs, that quickly invoking the oom-killer is inevitable.
Dave
The kernel seems to run into a lot of issues when you give it an atypically high amount of
memory. Its muuuch better in 64 bit but there's still a point where strange things
start happening (right around 256GB from what I've seen).
--CJD
4:28 p.m.
Hi.
On Thu, 19 Nov 2009 16:13:39 -0500, Casey Dahlin wrote
The 4GB limit is only on processes. Most recent 32-bit Intels can
address 32GB of system memory.
PAE is no fun at all.
Not necessarily relevant, but a win
for Linux (Microsoft never figured out how to make this work :).
Rather MS did no longer want to take the blame for driver authors
who did not anticipate that more than 4GB RAM in a 32 bit system
and decided to cut rather than fight. The 32 bit server versions
(which need approved drivers) have no trouble with more RAM.
2:08 p.m.
On 11/19/2009 05:28 PM, Ralf Ertzinger wrote:
> Not necessarily relevant, but a win
> for Linux (Microsoft never figured out how to make this work :).
Rather MS did no longer want to take the blame for driver authors
who did not anticipate that more than 4GB RAM in a 32 bit system
and decided to cut rather than fight. The 32 bit server versions
(which need approved drivers) have no trouble with more RAM.
That is the charitable explanation---more cynical analysis points out
that the functionality is there, but is disabled by a licensing check:
http://www.geoffchappell.com/viewer.htm?doc=notes/windows/license/memory.htm
przemek klosowski
2:13 a.m.
On Wed, Nov 18, 2009 at 9:13 PM, King InuYasha <ngompa13(a)gmail.com> wrote:
Except, that could be false advertising. In most cases, where CPU
computation is not used heavily, 64-bit is actually SLOWER than the 32-bit
counterpart. Optimizations are narrowing the gap, but it still remains
true.
You might want to try restating that, because what you're saying
sounds like "In cases where the CPU isn't used, 32bit is faster".
Which isn't sensible. What I think you're intending to say that
x86_64 is only faster on small tight pure-compute kernels like data
compression or image processing, but I don't believe that is correct
anymore. The biggest gaps I encounter in x86_64 performance anymore
tend to be due to things like missing optimizations in glibc.
x86_64 supporting 64bit registers is really only a small aspect of the
enhancements. Other important improvements include SSE2 as a mandatory
architectural feature (as well as a number of other things, like
cmov), support for larger processes, improvements to syscall entry,
and a doubling of the registers (also sse registers). The last of
these is very important because x86 has historically been very
register starved and x86_64 makes it basically reasonable.
The primary downside of x86_64 is that the larger pointers increase
memory usage. You might expect to see some loss in performance from
increased cache footprint, but I don't on the multi-megabyte caches on
the desktop CPUs.
Suggest a benchmark.
Now— On a memory starved system. Thats another matter entirely, you
have my full agreement that 32bit installs are better off if the
alternative is 64bits and swapping. :)
2:59 a.m.
Actually it is a pity to usually see those convos drift off with
arguments like "but my computer has...". Actually besides for netbooks
32bit is legacy. sure there is old hardware around and there is still
32bit fedora.... but with that analogy... none of them work on my c64
anyways.. and yea i know many people that still have one (<- really
true!)
jokes aside...
i find kevin koflers idea yet the best posted solution. Even the most
boring arguments like the fact that in the past 2 popular proprietary
browser plugins didnt work on 64bit platform none of them are true
anymore. (from my pov that was never really a blocker because i am the
opinion that a few proprietary things shouldnt stop a huge open source
project from progressing ahead). 64bit works since ages (actively
using it since 4 years+) and these days most of the development focus
should be on modern hardware, because this project is leaping ahead
into the future and 32bit is largely the past.
btw... you dont need to buy a netbook to get the performance benefits
of an ssd. *writing that on f12 64bit on a lenovo x301 with ssd*, and
no... ssds are not a step back but a leap ahead in many regards: power
consumption, read performance, no seek times, close to no heat
generation and no moveable parts (so no head crashes when you run
around with the laptop.) -> but that wasnt the real topic this thread
was initially about.
kind regards,
Rudolf Kastl
1:40 p.m.
On Thu, Nov 19, 2009 at 9:59 AM, Rudolf Kastl <che666(a)gmail.com> wrote:
btw... you dont need to buy a netbook to get the performance
benefits
of an ssd. *writing that on f12 64bit on a lenovo x301 with ssd*, and
no... ssds are not a step back but a leap ahead in many regards: power
consumption, read performance, no seek times, close to no heat
generation and no moveable parts (so no head crashes when you run
around with the laptop.) -> but that wasnt the real topic this thread
was initially about.
I know I never said that SSDs are netbook only, just because the
diskspace is less than traditional HDs does not mean that they are a
step back.
6:24 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
King InuYasha wrote:
Except, that could be false advertising. In most cases, where CPU
computation is not used heavily, 64-bit is actually SLOWER than the
32-bit counterpart. Optimizations are narrowing the gap, but it still
remains true.
On ppc versus PPC64, sparc vs. sparc64, and possibly other architectures
that may be true, however on x86 vs. x86_64 arch as a whole it is not
generally the case, in particular because the x86_64 arch has double the
number of available registers for gcc to play with.
Whenever I have done any performance testing comparisons between x86 and
x86_64, all I/O bound processes tend to come out with very similar
results, however the more CPU bound a task is, the more likely the app
is to have up to a 30% performance gain depending on various factors.
gcc for example tends to build much faster on x86_64 than on x86.
The only cases where I've personally seen an x86_64 built application
perform poorly compared to the i386 built version of the app on the same
system, when investigated - turned out to be that the source code of the
application had x86 specific assembly language which got used on the x86
build, and much slower C fallbacks when used on x86_64 (and other
arches). There probably aren't a lot of packages in the distribution
that contain x86-only hand crafted assembler which end up using C
fallbacks on x86_64, but it is one possibility.
What applications are you aware of which run slower on x86_64 than on
x86 on the same system? It would be interesting to investigate
whichever ones you've discovered to find out why they are slower as it
shouldn't generally occur, although I'd suspect it would be a case of
fast path x86 specific optimizations with a slow path for non-x86 as
mentioned above.
Just curious what you may have observed differs.
- --
Mike A. Harris Website: http://mharris.ca
Google Wave: mike.andrew.harris - at - googlewave.com
https://identi.ca/mharris | https://twitter.com/mikeaharris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFLBopw4RNf2rTIeUARAsDyAJ9vLCngIPvtALZXvzaeeN4y30cRtgCcDIXx
9zgCcX+8xCtl4jiCLmVJSOI=
=ss6n
-----END PGP SIGNATURE-----
6:29 a.m.
Mike A. Harris wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
King InuYasha wrote:
> Except, that could be false advertising. In most cases, where CPU
> computation is not used heavily, 64-bit is actually SLOWER than the
> 32-bit counterpart. Optimizations are narrowing the gap, but it still
> remains true.
On ppc versus PPC64, sparc vs. sparc64, and possibly other architectures
that may be true, however on x86 vs. x86_64 arch as a whole it is not
generally the case, in particular because the x86_64 arch has double the
number of available registers for gcc to play with.
Also, x86_64 has a much better ABI: args get passed in registers, not on
the stack.
What applications are you aware of which run slower on x86_64 than
on
x86 on the same system?
There used to be Java slowdowns, but this was fixed with the "compressed
OOPs" option.
Andrew.
11:58 a.m.
On Thu, Nov 19, 2009 at 02:27:32AM +0100, Kevin Kofler wrote:
Gregory Maxwell wrote:
> I noticed that http://fedoraproject.org/get-fedora appears to be
> strongly promoting i386 Fedora over x86_64. Is this intentional or an
> oversight?
IMHO, the right solution is to make the 64-bit edition the default download
and to work on making the error message people get when trying to install it
on a 32-bit machine nicer: "We're sorry, but your computer is too old to
install this 64-bit version of Fedora. Please download the legacy 32-bit
edition instead."
This is not the right solution. For much of the world, the time it takes
to download an ISO is meaningful. As much as I would like to see 64bit as
the default, it just isn't possible. What would make more sense is having
the defaults state more clearly that they are the 32bit version. Perhaps
make the 64bit version more prominent than it is now. Fedora has been
available for x86_64 for 5.5 years now, and a large portion of the hardware
out there is 64bit capable. Leave the defaults as 32bit so that people who
don't know what they have will get an ISO that works, but make it clear
that 64bit versions are available with something visible on the main
page. People who don't know what it is won't bother, people who do will
not have to dig to find it.
Justin
3:19 p.m.
On 11/18/2009 08:27 PM, Kevin Kofler wrote:
IMHO, the right solution is to make the 64-bit edition the default
download
and to work on making the error message people get when trying to install it
on a 32-bit machine nicer: "We're sorry, but your computer is too old to
install this 64-bit version of Fedora. Please download the legacy 32-bit
edition instead."
Kevin Kofler
Why put the users most likely to dislike us (low-computer-literacy newbies using old
computers) through such a hassle?
I/M/HO the right solution is to get Intel and AMD's permission to use images of their
case badges. Then we can present the architecture choice in a way that absolutely any user
can answer:
"Which of the following is stamped on the side of your computer?"
*Series of pictures of case stickers follows*
--CJD
4:16 p.m.
On Thu, 2009-11-19 at 16:19 -0500, Casey Dahlin wrote:
Why put the users most likely to dislike us (low-computer-literacy
newbies using old computers) through such a hassle?
And here the Board's hard work comes into play. Reference, the current
state of the discussion on Fedora's target audience:
https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg003...
"We found four defining characteristics that we
believe best describe the Fedora distribution's target audience:
Someone who (1) is voluntarily switching to Linux, (2) is familiar
with computers, but is not necessarily a hacker or developer, (3) is
likely to collaborate in some fashion when something's wrong with
Fedora, and (4) wants to use Fedora for general productivity, either
using desktop applications or a Web browser."
as per that, 'low-computer-literacy newbies' are not the user group
towards which Fedora is primarily targeted, hence their needs should not
be a high priority in designing the download page.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:23 a.m.
Kevin Kofler <kevin.kofler(a)chello.at> writes:
This is, sadly, intentional. I and others have been complaining about
this
for months, we got ignored, all in the names of making things work for
people who are not smart enough to figure out whether their computer is 64-
bit or not. The argument that almost all new non-netbook machines are 64-bit
anyway also got ignored.
If only the 32-bit version was smart enough to install a 64-bit kernel
when appropriate, this would not be such a disaster. Running a 32-bit
kernel with 4GB of memory is asking for trouble, and machines with 4GB
are probably as common as netbooks.
32-bit or 64-bit userland doesn't make such a difference.
/Benny
5:46 a.m.
On Fri, Nov 20, 2009 at 12:23:33PM +0100, Benny Amorsen wrote:
Kevin Kofler <kevin.kofler(a)chello.at> writes:
> This is, sadly, intentional. I and others have been complaining about this
> for months, we got ignored, all in the names of making things work for
> people who are not smart enough to figure out whether their computer is 64-
> bit or not. The argument that almost all new non-netbook machines are 64-bit
> anyway also got ignored.
If only the 32-bit version was smart enough to install a 64-bit kernel
when appropriate, this would not be such a disaster. Running a 32-bit
kernel with 4GB of memory is asking for trouble, and machines with 4GB
are probably as common as netbooks.
Like in this failed F11 feature?
https://fedoraproject.org/w/index.php?title=Features/ArchitectureSupport&...
--
Tomasz Torcz RIP is irrevelant. Spoofing is futile.
xmpp: zdzichubg(a)chrome.pl Your routes will be aggreggated. -- Alex Yuriev
4:21 p.m.
Benny Amorsen wrote:
If only the 32-bit version was smart enough to install a 64-bit
kernel
when appropriate, this would not be such a disaster.
That's just a broken hackaround (and not really implementable for the live
images), the real solution is to get people to just use the 64-bit version.
Kevin Kofler
4:25 p.m.
On Fri, Nov 20, 2009 at 11:21 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Benny Amorsen wrote:
> If only the 32-bit version was smart enough to install a 64-bit kernel
> when appropriate, this would not be such a disaster.
That's just a broken hackaround (and not really implementable for the live
images), the real solution is to get people to just use the 64-bit version.
We could have to images on one disk and let the bootloader load the
appropriate one, but this would involve going away from CDs (which we
should do anyway, we can't live in the past forever and still claim to
be a leading edge distro)
4:50 p.m.
drago01 wrote:
We could have to images on one disk and let the bootloader load the
appropriate one, but this would involve going away from CDs (which we
should do anyway, we can't live in the past forever and still claim to
be a leading edge distro)
If we don't want to live in the past, we should go away from 32-bit, not
from CDs. ;-) Doubling the download size for everyone is a bad solution.
Kevin Kofler
6:29 p.m.
Benny Amorsen wrote:
Kevin Kofler <kevin.kofler(a)chello.at> writes:
> If we don't want to live in the past, we should go away from 32-bit, not
> from CDs. ;-) Doubling the download size for everyone is a bad solution.
An extra kernel shouldn't be that big a problem.
But it doesn't really solve the issue, as your userland will still be
suboptimal. 64-bit is not just about the kernel.
Kevin Kofler
6:30 p.m.
Benny Amorsen wrote:
Kevin Kofler <kevin.kofler(a)chello.at> writes:
> (and not really implementable for the live images)
Why not? It should be reasonably easy to handle that in the boot loader.
1. Needs GRUB hackery to support transparently. (For the DVD, Anaconda can
detect the architecture and install a kernel accordingly, but for a live CD,
we don't have any such support.)
2. Not enough room on a CD for the extra kernel.
And it doesn't solve the real issue anyway.
Kevin Kofler
8:02 p.m.
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
1. Needs GRUB hackery to support transparently. (For the DVD,
Anaconda can
detect the architecture and install a kernel accordingly, but for a live CD,
we don't have any such support.)
That would be SYSLINUX hackery, not GRUB hackery. The CD and DVD images
use ISOLINUX to boot. SYSLINUX has a module interface; I don't know if
it could handle a quick check for the "lm" CPU capability and choose a
different menu file or not.
This obviously doesn't address CD space or other issues; just pointing
out the boot loader piece could be relatively easy.
--
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.
2:52 a.m.
On Fri, 2009-11-20 at 20:02 -0600, Chris Adams wrote:
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
> 1. Needs GRUB hackery to support transparently. (For the DVD, Anaconda can
> detect the architecture and install a kernel accordingly, but for a live CD,
> we don't have any such support.)
That would be SYSLINUX hackery, not GRUB hackery. The CD and DVD images
use ISOLINUX to boot. SYSLINUX has a module interface; I don't know if
it could handle a quick check for the "lm" CPU capability and choose a
different menu file or not.
FWIW, there is a syslinux module named ifcpu64 that will load different
kernels/initrds based on whether the cpu is 64-bit. I use it in
pxelinux at our school so our 64-bit Fedora image automatically gets
installed on the systems that can support it, while our 32-bit Fedora
image gets installed on the rest.
Jonathan
11:52 p.m.
On 11/21/2009 03:52 AM, Jonathan Dieter wrote:
FWIW, there is a syslinux module named ifcpu64 that will load
different
kernels/initrds based on whether the cpu is 64-bit.
Cool, do syslinux modules work in isolinux? We could have a tiny 32-bit
image on a 64-bit CD that would say, "sorry, you got the wrong CD".
-Bill
--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.603.448.4440
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
1:35 a.m.
On Sun, 2009-11-22 at 00:52 -0500, Bill McGonigle wrote:
On 11/21/2009 03:52 AM, Jonathan Dieter wrote:
> FWIW, there is a syslinux module named ifcpu64 that will load different
> kernels/initrds based on whether the cpu is 64-bit.
Cool, do syslinux modules work in isolinux? We could have a tiny 32-bit
image on a 64-bit CD that would say, "sorry, you got the wrong CD".
They should; it's all the same project. I think the the 64-bit kernel
already gives a sane error message when you attempt to run it on a
32-bit machine.
Jonathan
2:15 a.m.
On Sun, Nov 22, 2009 at 1:35 AM, Jonathan Dieter <jdieter(a)gmail.com> wrote:
On Sun, 2009-11-22 at 00:52 -0500, Bill McGonigle wrote:
> On 11/21/2009 03:52 AM, Jonathan Dieter wrote:
> > FWIW, there is a syslinux module named ifcpu64 that will load different
> > kernels/initrds based on whether the cpu is 64-bit.
>
> Cool, do syslinux modules work in isolinux? We could have a tiny 32-bit
> image on a 64-bit CD that would say, "sorry, you got the wrong CD".
They should; it's all the same project. I think the the 64-bit kernel
already gives a sane error message when you attempt to run it on a
32-bit machine.
Jonathan
I wonder... Why can't we have 32-bit Linux able to run 64-bit applications?
Mac OS X can do it.
3:51 a.m.
On Sun, Nov 22, 2009 at 9:15 AM, Sir Gallantmon <ngompa13(a)gmail.com> wrote:
On Sun, Nov 22, 2009 at 1:35 AM, Jonathan Dieter
<jdieter(a)gmail.com> wrote:
>
> On Sun, 2009-11-22 at 00:52 -0500, Bill McGonigle wrote:
> > On 11/21/2009 03:52 AM, Jonathan Dieter wrote:
> > > FWIW, there is a syslinux module named ifcpu64 that will load
> > > different
> > > kernels/initrds based on whether the cpu is 64-bit.
> >
> > Cool, do syslinux modules work in isolinux? We could have a tiny 32-bit
> > image on a 64-bit CD that would say, "sorry, you got the wrong CD".
>
> They should; it's all the same project. I think the the 64-bit kernel
> already gives a sane error message when you attempt to run it on a
> 32-bit machine.
>
> Jonathan
>
I wonder... Why can't we have 32-bit Linux able to run 64-bit applications?
Mac OS X can do it.
1) because it isn't possible
2) no it doesn't mac OS X use a 64bit hypervisor and run the rest inside it.
3:52 a.m.
On Sun, Nov 22, 2009 at 10:51 AM, drago01 <drago01(a)gmail.com> wrote:
On Sun, Nov 22, 2009 at 9:15 AM, Sir Gallantmon
<ngompa13(a)gmail.com> wrote:
> On Sun, Nov 22, 2009 at 1:35 AM, Jonathan Dieter <jdieter(a)gmail.com> wrote:
>>
>> On Sun, 2009-11-22 at 00:52 -0500, Bill McGonigle wrote:
>> > On 11/21/2009 03:52 AM, Jonathan Dieter wrote:
>> > > FWIW, there is a syslinux module named ifcpu64 that will load
>> > > different
>> > > kernels/initrds based on whether the cpu is 64-bit.
>> >
>> > Cool, do syslinux modules work in isolinux? We could have a tiny 32-bit
>> > image on a 64-bit CD that would say, "sorry, you got the wrong
CD".
>>
>> They should; it's all the same project. I think the the 64-bit kernel
>> already gives a sane error message when you attempt to run it on a
>> 32-bit machine.
>>
>> Jonathan
>>
>
> I wonder... Why can't we have 32-bit Linux able to run 64-bit applications?
> Mac OS X can do it.
1) because it isn't possible
2) no it doesn't mac OS X use a 64bit hypervisor and run the rest inside it.
An more importantly ... why should we want that?
5246
days inactive
5272
days old
164 comments
50 participants
participants (50)
-
Adam Williamson -
Andrew Haley -
Benny Amorsen -
Bill McGonigle -
Bruno Wolff III -
Casey Dahlin -
Chris Adams -
Conrad Meyer -
Dave Jones -
Debarshi Ray -
Dominik 'Rathann' Mierzejewski -
drago01 -
Gerd Hoffmann -
Gregory Maxwell -
Guido Grazioli -
Ikem Krueger -
James Antill -
Jeff Garzik -
Jesse Keating -
John Reiser -
John5342 -
Jon Masters -
Jon Masters -
Jonathan Dieter -
Josephine Tannhäuser -
Justin Forbes -
Kevin Kofler -
Leszek Matok -
Matthew Garrett -
Mike A. Harris -
Neal Gompa -
Nicolas Mailhot -
Nicu Buculei -
Orcan Ogetbil -
Paul Jakma -
Peter Jones -
Peter Robinson -
Przemek Klosowski -
Rahul Sundaram -
Ralf Corsepius -
Ralf Ertzinger -
Rallias UberNerd -
Roberto Ragusa -
Roland McGrath -
Rudolf Kastl -
Seth Vidal -
shmuel siegel -
Tom Lane -
Tomasz Torcz -
Ville Skyttä