I noticed that http://fedoraproject.org/get-fedora appears to be strongly promoting i386 Fedora over x86_64. Is this intentional or an oversight?
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
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. ^^
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@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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
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,
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
2009/11/18 Gerd Hoffmann kraxel@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
On Wed, Nov 18, 2009 at 1:55 AM, Josephine Tannhäuser josephine.tannhauser@googlemail.com wrote:
2009/11/18, Gregory Maxwell gmaxwell@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@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).
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
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
On Wed, Nov 18, 2009 at 7:27 PM, Kevin Kofler kevin.kofler@chello.atwrote:
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
On Fri, Nov 20, 2009 at 11:14 AM, Ralf Corsepius rc040203@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
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.
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
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
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. :>
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
On Thu, Nov 19, 2009 at 2:56 AM, Kevin Kofler kevin.kofler@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.
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.
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.
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.
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
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.
Once upon a time, Adam Williamson awilliam@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.
On Thu, 2009-11-19 at 15:54 -0600, Chris Adams wrote:
Once upon a time, Adam Williamson awilliam@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).
Once upon a time, Adam Williamson awilliam@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).
On Thu, 2009-11-19 at 16:14 -0600, Chris Adams wrote:
Once upon a time, Adam Williamson awilliam@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.
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]"
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
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 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
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
On Thu, 19 Nov 2009 17:39:16 -0600, Kevin Kofler kevin.kofler@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?
On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd robinstar1574@gmail.com wrote:
On Thu, 19 Nov 2009 17:39:16 -0600, Kevin Kofler kevin.kofler@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.
On 12/08/2009 06:41 PM, drago01 wrote:
On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd robinstar1574@gmail.com wrote:
On Thu, 19 Nov 2009 17:39:16 -0600, Kevin Koflerkevin.kofler@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 KoflerBut 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
On Tue, Dec 8, 2009 at 12:47 PM, Ralf Corsepius rc040203@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.
On 12/08/2009 08:02 PM, Gregory Maxwell wrote:
On Tue, Dec 8, 2009 at 12:47 PM, Ralf Corsepiusrc040203@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
On Wed, Dec 09, 2009 at 06:51:59 +0100, Ralf Corsepius rc040203@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.
On 12/09/2009 02:05 PM, Bruno Wolff III wrote:
On Wed, Dec 09, 2009 at 06:51:59 +0100, Ralf Corsepiusrc040203@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
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.
On Wed, Dec 09, 2009 at 10:14:10 -0500, James Antill james@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.)
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, ...)
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
On Wed, Dec 9, 2009 at 10:03 PM, Kevin Kofler kevin.kofler@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)
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
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
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.
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
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..
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. :)
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).
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
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.
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
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.)
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
Once upon a time, Ville Skyttä ville.skytta@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.
On Wed, 9 Dec 2009, Chris Adams wrote:
Once upon a time, Ville Skyttä ville.skytta@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
On Wed, Dec 9, 2009 at 4:51 PM, Seth Vidal skvidal@fedoraproject.org wrote:
and then you have to do that as well for updates. :(
Not if you don't have a separate updates repo, no?
On Wed, 9 Dec 2009, Gregory Maxwell wrote:
On Wed, Dec 9, 2009 at 4:51 PM, Seth Vidal skvidal@fedoraproject.org wrote:
and then you have to do that as well for updates. :(
Not if you don't have a separate updates repo, no?
still need an updates-testing.
-sv
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
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.
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.
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.
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)
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,
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.
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
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
Once upon a time, Jeff Garzik jgarzik@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.
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.
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
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@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
On Sun, 2009-12-13 at 13:53 -0500, Tom Lane wrote:
Paul Jakma paul@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.
Once upon a time, Jon Masters jonathan@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.
On Sun, Dec 13, 2009 at 16:19:54 -0600, Chris Adams cmadams@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.
On Mon, Dec 14, 2009 at 00:20, Bruno Wolff III bruno@wolff.to wrote:
On Sun, Dec 13, 2009 at 16:19:54 -0600, Chris Adams cmadams@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.
On Mon, Dec 14, 2009 at 00:32:15 +0000, John5342 john5342@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.
On Sun, 2009-12-13 at 16:19 -0600, Chris Adams wrote:
Once upon a time, Jon Masters jonathan@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.
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 Mastersjonathan@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.
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,
On Sun, Dec 13, 2009 at 7:33 PM, Paul Jakma paul@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 ....
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,
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,
On Sun, Dec 13, 2009 at 8:16 PM, Paul Jakma paul@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).
On Sun, Dec 13, 2009 at 9:09 PM, drago01 drago01@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.
Once upon a time, Paul Jakma paul@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.
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,
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
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,
Once upon a time, Paul Jakma paul@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! :-)
On Mon, Dec 14, 2009 at 7:33 AM, Paul Jakma paul@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.
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,
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.
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.
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,
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.
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
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
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,
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)
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)
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.
On Wed, Nov 18, 2009 at 8:04 PM, Ikem Krueger ikem.krueger@googlemail.comwrote:
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.
On Wed, Nov 18, 2009 at 8:18 PM, Ikem Krueger ikem.krueger@googlemail.comwrote:
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
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. :)
On Wed, Nov 18, 2009 at 8:30 PM, Ikem Krueger ikem.krueger@googlemail.comwrote:
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 ;)
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!
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).
On 11/18/2009 09:23 PM, King InuYasha wrote:
On Wed, Nov 18, 2009 at 8:18 PM, Ikem Krueger <ikem.krueger@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
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.
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
On Thu, Nov 19, 2009 at 10:22 PM, Casey Dahlin cdahlin@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)
Dnia 2009-11-19, o godz. 16:13:39 Casey Dahlin cdahlin@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
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
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
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.
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
On Wed, Nov 18, 2009 at 9:13 PM, King InuYasha ngompa13@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. :)
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
On Thu, Nov 19, 2009 at 9:59 AM, Rudolf Kastl che666@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.
-----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
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.
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
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
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/msg00350....
"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.
Kevin Kofler kevin.kofler@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
On Fri, Nov 20, 2009 at 12:23:33PM +0100, Benny Amorsen wrote:
Kevin Kofler kevin.kofler@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&...
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
On Fri, Nov 20, 2009 at 11:21 PM, Kevin Kofler kevin.kofler@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)
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
Kevin Kofler kevin.kofler@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.
/Benny
Benny Amorsen wrote:
Kevin Kofler kevin.kofler@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
Kevin Kofler kevin.kofler@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.
/Benny
Benny Amorsen wrote:
Kevin Kofler kevin.kofler@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
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
- 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.
On Fri, 2009-11-20 at 20:02 -0600, Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
- 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
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
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
On Sun, Nov 22, 2009 at 1:35 AM, Jonathan Dieter jdieter@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.
On Sun, Nov 22, 2009 at 9:15 AM, Sir Gallantmon ngompa13@gmail.com wrote:
On Sun, Nov 22, 2009 at 1:35 AM, Jonathan Dieter jdieter@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.
On Sun, Nov 22, 2009 at 10:51 AM, drago01 drago01@gmail.com wrote:
On Sun, Nov 22, 2009 at 9:15 AM, Sir Gallantmon ngompa13@gmail.com wrote:
On Sun, Nov 22, 2009 at 1:35 AM, Jonathan Dieter jdieter@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.
- because it isn't possible
- 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?
devel@lists.stg.fedoraproject.org
-
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ä