Intel has similar problems, but they manage to work around it by releasing as much 'open' code as possible, then leaving the proprietary bits in an optional binary shared object. Intel hasn't released the *.so file yet, but that seems like the most reasonable solution, not to mention that an endeavoring outsider might be able to reverse-engineer or even completely re-implement those 'secret' bits.
The beauty is that there's a working 2D and 3D graphics driver that everyone can port and improve upon, there's 'extra' functionality to those who need it and can be encumbered by the restrictive license, and the interfaces and methods of access for the proprietary parts are clearly labeled in the open code, leaving room for members of the community to implement them on their own.
I used to buy ATI for all my Linux machines, but the past few years the R300 rift opened wider and wider, and the open-source support for the new cards got more and more flaky (not the drivers themselves, they just keep falling farther and farther behind the hardware offerings). I've switched to Intel integrated graphics for my machines, the GMA 3000 and X3000 are actually enough horsepower for all my needs, Intel is commited to providing open code, and the picture quality seems just as good as the two 'titans' offer.
They're useless to me unless the source is available, preferably under the GPL. I really wish they'd work -inside- the framework of the kernel, Mesa, and xorg projects instead of building one-off binary drivers. What if I want to use their card on PowerPC, want to link against the latest (or a non-mainline) kernel, or just want to run an all-open system?
My employer recently 'consolidated' their server farm too. We used to have a room with fifty aging Dell PowerEdge servers, each running independently, requiring massive support, cooling, and electricity.
Now we have ten VM servers running all the migrated services, PLUS a room with about fifty aging Dell PowerEdge servers, each running independently, requiring massive support, cooling, and electricity.
I never thought 'consolidation' would require so much more space, electricity, air conditioning, and upgrades to core switches and UPS units.
I follow prerelease kernels and I've been waiting for this. I've found that running my VMWare hosts and guests with tickless, low-HZ, voluntary-preempted kernels is seriously reducing the overhead you get when you run more virtual CPUs than real ones in your box.
I can't wait for it to mature on PPC, MIPS, and x86_64! Right now it's 32-bit x86 only.
Um, that's not the way it works. Why should Apple program their GUI so it runs on really old video cards when they support accelerated GPU-based effects on hardware all the way back to 2001?
Part of selling an integrated software/hardware system is that you don't have to write all that 'lowest common denominator' code. There's no reason to write the thing so it scales down below the hardware you've sold in the past five years (and I'd say Apple is pretty generous at that).
Also, OS X 10.4 isn't 'slow' on any hardware that can do Quartz Extreme, which is pretty much everything since the 533MHz G4. I have an iMac G3 that it's slow as a dog on, but that's totally to be expected; modern Linux distros are slow as a dog on that hardware too.
Lets be honest here: technology marches on, you can't get nice compositing in Linux without a modern video card, you can't get OS X to run quickly on hardware that predates pixel shaders, and Vista won't run too well on your 800MHz Duron. Sure, Linux scales down better, but you still won't be able to get all the goodies you would if you had a modern system.
Re:why does linux lag windows in features?
on
VMware Fusion goes Beta
·
· Score: 2, Insightful
I'd venture to say that it's because there are so many options when you're running on linux. How many different versions of X, how many different window managers, and how many libraries for drawing to the screen (Xlib, GTK+1, GTK+2, Qt, XVideo, etc.) would they have to write hooks for?
I'm a linux guy myself, and I love the choices I get (just switched window managers recently, in fact), but that's why you won't get those kind of features when you're running it in a VM session.
It's compatible with the other VMWare products!
on
VMware Fusion goes Beta
·
· Score: 5, Interesting
What I really wanted was compatibility with VMWare's other apps, and they delivered. I can justify a Mac at my desk if I can author sessions that eventually live up on our server farm.
Interoperability is HUGE when it comes to virtualization. There's a lot of value to being able to 'build' a server in my bedroom and upload it to bigger metal when I get to work. Parallels didn't have that, VMWare does. I'm going with VMWare.
I'm back to running a 32-bit kernel and userland on my 64-bit CPU and a lot of things like those that were broken work again.
No matter what you did, running -anything-, be it 16, 32, or 64-bit would be much faster on your X2 3800+ than it would on your single-core 2400+.
In my case, running 64-bit with compat. libs for 32-bit apps was actually slowing my system down for most things because there was a lot less RAM available for disk caching.
The only thing that's slower than before is encoding video, and it's only a few percent worse, a small tradeoff for being able to use YouTube without adding 140MB to my resident set.
Some day, running 64-bit native will be the right thing to do for me, but I don't expect it for at least a few months.
Turns out that keeping a tidy place, standing up straight, speaking with big words, and having a taste for fine scotch and wine before the age of forty are all indicators to the opposite sex that you're a homosexual.
I tend to have much better luck picking up ladies when I'm unshaven and unwashed, hunched over a bar drinking a cheap beer on a sunday night. Something about a sink full of dirty dishes and dirty clothes in a pile on the floor says 'real man' to the ladies.
The native AMD64/EMT64 Linux distro for AMD and Intel chips is labeled 'amd64' in the Gentoo world. Once you're past the Gentoo stuff, the developers tend to call it all x86_64.
If you want to run native 64-bit linux on modern Intel chips, you use the 'amd64' distribution. Intel 'stole' AMD's implementation after they realized that IA64 wasn't going anywhere near your desktop.
1. I'm a purist, and having my top two apps (firefox and openoffice) run in compat. mode seems stupid to me. 2. 64-bit native was only about 3% faster. Really. 3. 64-bit Linux seemed to chew up a lot more RAM, cutting into my precious disk cache, making some operations slower than they are now in 32-bit mode. 4. 32-bit Linux is more stable. Things 'just work' that wouldn't when I was running native. 5. I can keep one config and one build of the system for all my older boxes that don't have 64-bit hardware.
I just bought a Core 2 Duo board and processor. I immediately installed the native 64-bit Gentoo on it, but after two months, I decided to go back to running the x86 distribution. I've been using Linux since 1998, and Gentoo on x86 and PowerPC since before 1.4, and I wasn't very happy with amd64.
I'm a desktop user with 2GB RAM, the server is a PowerPC with 1.5GB RAM. I've never seen a system munch memory like this box when it was running 64-bit Linux. Running all those compatability libraries (for Firefox, OpenOffice, and several other apps) seemed to eat a ton of RAM.
Until every app and plugin I use is 64-bit native, I think I'll stay with 32-bit operating systems.
As for 64-bit hardware, you really don't have much choice if you want to buy new hardware. There's no reason NOT to buy 64-bit processors these days, you get the best bang for your buck with AMD64 or EMT64 CPUs. 32-bit operating systems benefit from the new processors almost as much as 64-bit systems do, so go ahead and 'go 32 on 64' if you want a modern computer.
Seriously, I'm in New England and I'm friends with a LOT of very hip, trustworthy, boy-scout-type people. Depending on where exactly you are, this could be as easy as draining your pipes and handing a set of keys to someone you can trust.
Definitely drain the pipes, though.
And message me if you need a human for anything... I might be able to help.
What percent of the working population at-large has been arrested at some point in their life? If it's more than 30%, previous arrest could be a good thing for companies. In any case, you'd have to factor-in the overall working population's 'arrest rate' to the equation to see -how much more likely- a person who's been arrested is to commit a workplace crime than someone who hasn't.
I'm the guy in charge of this sort of decision on a network of about 1,200 computers and our policy this year is to set _ALL_ Windows boxes to a fixed 512MB pagefile. If someone is actually USING that much swap, I _WANT_ them to crash and have to call me so I can order them more RAM. So far the only time this has happened was in the computer lab that has Maya.
If you're actually swapping out more than 256MB in this day and age, if you actually are executing from swap... It's time to buy more RAM.
That's exactly what I'm worried about. The GCC developers still allow new DFA profiles to be added during point-releases. Someone ought to write one for these new CPUs so we can get the best buck:bang ratio.
I've been looking at benchmarks and such and 64-bit is faster by a few percent, because of the extra registers and some ops fitting into one instruction rather than two, but the difference in convenience for me is HUGE. I primarily use this machine as my workstation, and I encode a fair amount of video on it. If my encoding takes a few extra minutes and I can still use the Adobe Flash plugin and VMWare Workstation 5, I'm a happy camper. Its worth staying in 32-bit mode until everything I need is 64-bit native.
I thought 'nocona' would get you all the instruction sets you wanted, but the execution core and scheduling of the Core 2 are much closer to the Pentium-M. You might be better off specifying 'Pentium-M' and using switches to enable SSE3. The Core and Core 2 are much closer to the i686 (P3) than they are to the NetBurst (P4) under the hood, even though the Core series can chew on a lot of the newer SIMD instructions and shares an FSB with some Pentium 4s.
I'm going to buy an e6600-based desktop in the winter, and I'm wondering if GCC will add tuning for the Core 2 processors. My guess is that '-Os -march=pentium-m -msse3 -mfpmath=sse' is the way to do it now in 32-bit mode, but there have been enough changes in the Core 2 to make for a new DFA profile, no? I thought they radically revamped the Pentium3 core, adding execution units and such.
I just rebuilt my Core (1) Duo laptop with the aforementioned options and it seems to get me the most bang for my buck.
From what I've read, compiling and running in 32-bit mode is still the best choice for now, the Core 2 is a lot better than the EM64T pentium 4 at running 64-bit code, but still not as fast as just using the 32-bit code (stuff like video encoding is happening in the 128-bit vector unit anyway, and I don't need more than 4GB addressable space).
It's not 100% native 64-bit like the AMD64 is, but it's closer than the existing EM64T CPUs. From what I've read, the Core 2 is actually a bit slower when in 64-bit mode than when in 32-bit mode (but much less so than the Pentium 4-based CPUs, which were MUCH slower in 64-bit mode).
The Core 1 CPUs were basically Pentium IIIs with extra instructions and much-revamped layout and FSB. The 64-bit Pentium 4s were regular Pentium 4s with the ability to break down 64-bit instructions into chunks that the lowest-level of the CPU could work with. The Core 2 is still the venerable i686 from the good 'ole days, but they've done some rather dramatic changes (much more than from PIII -> Core 1), including execution units that can chew 64-bit instructions in the raw. The other huge advantage of Core 2 is that Intel FINALLY fixed SSE. Until now, SSE always used at least two clocks to get 128-bit work done, and usually many more. Now SSE has been fixed to be a lot more like the Altivec unit on the G4, it works like a _real_ vector coprocessor and can chew on 128-bit instructions in one clock.
Overall, my impression is that the implementation isn't as 'clean' as the AMD64, but Intel invested in all the right places, and the overall product is obviously a winner. Sometimes doing the 'wrong thing' really well is better than doing the 'right thing' three years ago and sitting on it. When AMD fixes their SIMD implementation, I'll go back to championing the Athlon; until then, the Core 2 is the best bang, for your buck or otherwise.
What I'd like to see is a system that bids up or down the wage depending on the value of the hours it needs filled. I have friends who work bars that make the same on wednesday afternoon as they do on a saturday night. Needless to say, they have a lot more 'callouts' on the weekend nights.
All the Intel-based Macs so far (excepting the ones that just came out last week) use the i945 chipset, and the integrated graphics are i950GMA chips. I believe the Linux drivers are all working, there might be some device IDs that need to be added to the drivers' #include files to let them know that the devices belong to them.
last I checked there were no accelerated Intel drivers for Linux.
Are you serious? The i810 through the i915 are fully supported in both 2D and 3D with open-source drivers. This is just a continuation of that through the latest 945 and 965 GMA chipsets.
The open-source Intel drivers eclipsed the open-source ATI drivers a while ago too, the i945 integrated chipset benchmarks about three times the speed of my Radeon 9200 with Mesa-6.5 under xorg-7.1.
My next box is going to be an i965 with a Core 2 strapped onto it, My guess is that it will perform better in Linux than any 'real' graphics card.
http://ftp.x.org/pub/X11R7.0/doc/html/i810.4.htm l
Slashdot Mirror
I've been using Amarok on my OS X Mac for over a year. I have Fink and KDE installed and it works fine.
Intel has similar problems, but they manage to work around it by releasing as much 'open' code as possible, then leaving the proprietary bits in an optional binary shared object. Intel hasn't released the *.so file yet, but that seems like the most reasonable solution, not to mention that an endeavoring outsider might be able to reverse-engineer or even completely re-implement those 'secret' bits.
The beauty is that there's a working 2D and 3D graphics driver that everyone can port and improve upon, there's 'extra' functionality to those who need it and can be encumbered by the restrictive license, and the interfaces and methods of access for the proprietary parts are clearly labeled in the open code, leaving room for members of the community to implement them on their own.
I used to buy ATI for all my Linux machines, but the past few years the R300 rift opened wider and wider, and the open-source support for the new cards got more and more flaky (not the drivers themselves, they just keep falling farther and farther behind the hardware offerings). I've switched to Intel integrated graphics for my machines, the GMA 3000 and X3000 are actually enough horsepower for all my needs, Intel is commited to providing open code, and the picture quality seems just as good as the two 'titans' offer.
They're useless to me unless the source is available, preferably under the GPL. I really wish they'd work -inside- the framework of the kernel, Mesa, and xorg projects instead of building one-off binary drivers. What if I want to use their card on PowerPC, want to link against the latest (or a non-mainline) kernel, or just want to run an all-open system?
My employer recently 'consolidated' their server farm too. We used to have a room with fifty aging Dell PowerEdge servers, each running independently, requiring massive support, cooling, and electricity.
Now we have ten VM servers running all the migrated services, PLUS a room with about fifty aging Dell PowerEdge servers, each running independently, requiring massive support, cooling, and electricity.
I never thought 'consolidation' would require so much more space, electricity, air conditioning, and upgrades to core switches and UPS units.
I follow prerelease kernels and I've been waiting for this. I've found that running my VMWare hosts and guests with tickless, low-HZ, voluntary-preempted kernels is seriously reducing the overhead you get when you run more virtual CPUs than real ones in your box.
I can't wait for it to mature on PPC, MIPS, and x86_64! Right now it's 32-bit x86 only.
Um, that's not the way it works. Why should Apple program their GUI so it runs on really old video cards when they support accelerated GPU-based effects on hardware all the way back to 2001?
Part of selling an integrated software/hardware system is that you don't have to write all that 'lowest common denominator' code. There's no reason to write the thing so it scales down below the hardware you've sold in the past five years (and I'd say Apple is pretty generous at that).
Also, OS X 10.4 isn't 'slow' on any hardware that can do Quartz Extreme, which is pretty much everything since the 533MHz G4. I have an iMac G3 that it's slow as a dog on, but that's totally to be expected; modern Linux distros are slow as a dog on that hardware too.
Lets be honest here: technology marches on, you can't get nice compositing in Linux without a modern video card, you can't get OS X to run quickly on hardware that predates pixel shaders, and Vista won't run too well on your 800MHz Duron. Sure, Linux scales down better, but you still won't be able to get all the goodies you would if you had a modern system.
I'd venture to say that it's because there are so many options when you're running on linux. How many different versions of X, how many different window managers, and how many libraries for drawing to the screen (Xlib, GTK+1, GTK+2, Qt, XVideo, etc.) would they have to write hooks for?
I'm a linux guy myself, and I love the choices I get (just switched window managers recently, in fact), but that's why you won't get those kind of features when you're running it in a VM session.
What I really wanted was compatibility with VMWare's other apps, and they delivered. I can justify a Mac at my desk if I can author sessions that eventually live up on our server farm.
Interoperability is HUGE when it comes to virtualization. There's a lot of value to being able to 'build' a server in my bedroom and upload it to bigger metal when I get to work. Parallels didn't have that, VMWare does. I'm going with VMWare.
So your Flash player works fine? How about mplayerplug-in?
What happens when you browse to a site with a movie embedded in it, like http://www.apple.com/getamac ?
I'm back to running a 32-bit kernel and userland on my 64-bit CPU and a lot of things like those that were broken work again.
No matter what you did, running -anything-, be it 16, 32, or 64-bit would be much faster on your X2 3800+ than it would on your single-core 2400+.
In my case, running 64-bit with compat. libs for 32-bit apps was actually slowing my system down for most things because there was a lot less RAM available for disk caching.
The only thing that's slower than before is encoding video, and it's only a few percent worse, a small tradeoff for being able to use YouTube without adding 140MB to my resident set.
Some day, running 64-bit native will be the right thing to do for me, but I don't expect it for at least a few months.
I'm the same way and have the same problem.
Turns out that keeping a tidy place, standing up straight, speaking with big words, and having a taste for fine scotch and wine before the age of forty are all indicators to the opposite sex that you're a homosexual.
I tend to have much better luck picking up ladies when I'm unshaven and unwashed, hunched over a bar drinking a cheap beer on a sunday night. Something about a sink full of dirty dishes and dirty clothes in a pile on the floor says 'real man' to the ladies.
The native AMD64/EMT64 Linux distro for AMD and Intel chips is labeled 'amd64' in the Gentoo world. Once you're past the Gentoo stuff, the developers tend to call it all x86_64.
If you want to run native 64-bit linux on modern Intel chips, you use the 'amd64' distribution. Intel 'stole' AMD's implementation after they realized that IA64 wasn't going anywhere near your desktop.
I'm switching back to 32-bit because:
1. I'm a purist, and having my top two apps (firefox and openoffice) run in compat. mode seems stupid to me.
2. 64-bit native was only about 3% faster. Really.
3. 64-bit Linux seemed to chew up a lot more RAM, cutting into my precious disk cache, making some operations slower than they are now in 32-bit mode.
4. 32-bit Linux is more stable. Things 'just work' that wouldn't when I was running native.
5. I can keep one config and one build of the system for all my older boxes that don't have 64-bit hardware.
I just bought a Core 2 Duo board and processor. I immediately installed the native 64-bit Gentoo on it, but after two months, I decided to go back to running the x86 distribution. I've been using Linux since 1998, and Gentoo on x86 and PowerPC since before 1.4, and I wasn't very happy with amd64.
I'm a desktop user with 2GB RAM, the server is a PowerPC with 1.5GB RAM. I've never seen a system munch memory like this box when it was running 64-bit Linux. Running all those compatability libraries (for Firefox, OpenOffice, and several other apps) seemed to eat a ton of RAM.
Until every app and plugin I use is 64-bit native, I think I'll stay with 32-bit operating systems.
As for 64-bit hardware, you really don't have much choice if you want to buy new hardware. There's no reason NOT to buy 64-bit processors these days, you get the best bang for your buck with AMD64 or EMT64 CPUs. 32-bit operating systems benefit from the new processors almost as much as 64-bit systems do, so go ahead and 'go 32 on 64' if you want a modern computer.
Seriously, I'm in New England and I'm friends with a LOT of very hip, trustworthy, boy-scout-type people. Depending on where exactly you are, this could be as easy as draining your pipes and handing a set of keys to someone you can trust.
Definitely drain the pipes, though.
And message me if you need a human for anything... I might be able to help.
AIM: MarcQuadra
What percent of the working population at-large has been arrested at some point in their life? If it's more than 30%, previous arrest could be a good thing for companies. In any case, you'd have to factor-in the overall working population's 'arrest rate' to the equation to see -how much more likely- a person who's been arrested is to commit a workplace crime than someone who hasn't.
I'm the guy in charge of this sort of decision on a network of about 1,200 computers and our policy this year is to set _ALL_ Windows boxes to a fixed 512MB pagefile. If someone is actually USING that much swap, I _WANT_ them to crash and have to call me so I can order them more RAM. So far the only time this has happened was in the computer lab that has Maya.
If you're actually swapping out more than 256MB in this day and age, if you actually are executing from swap... It's time to buy more RAM.
That's exactly what I'm worried about. The GCC developers still allow new DFA profiles to be added during point-releases. Someone ought to write one for these new CPUs so we can get the best buck:bang ratio.
I've been looking at benchmarks and such and 64-bit is faster by a few percent, because of the extra registers and some ops fitting into one instruction rather than two, but the difference in convenience for me is HUGE. I primarily use this machine as my workstation, and I encode a fair amount of video on it. If my encoding takes a few extra minutes and I can still use the Adobe Flash plugin and VMWare Workstation 5, I'm a happy camper. Its worth staying in 32-bit mode until everything I need is 64-bit native.
I thought 'nocona' would get you all the instruction sets you wanted, but the execution core and scheduling of the Core 2 are much closer to the Pentium-M. You might be better off specifying 'Pentium-M' and using switches to enable SSE3. The Core and Core 2 are much closer to the i686 (P3) than they are to the NetBurst (P4) under the hood, even though the Core series can chew on a lot of the newer SIMD instructions and shares an FSB with some Pentium 4s.
I'm going to buy an e6600-based desktop in the winter, and I'm wondering if GCC will add tuning for the Core 2 processors. My guess is that '-Os -march=pentium-m -msse3 -mfpmath=sse' is the way to do it now in 32-bit mode, but there have been enough changes in the Core 2 to make for a new DFA profile, no? I thought they radically revamped the Pentium3 core, adding execution units and such.
I just rebuilt my Core (1) Duo laptop with the aforementioned options and it seems to get me the most bang for my buck.
From what I've read, compiling and running in 32-bit mode is still the best choice for now, the Core 2 is a lot better than the EM64T pentium 4 at running 64-bit code, but still not as fast as just using the 32-bit code (stuff like video encoding is happening in the 128-bit vector unit anyway, and I don't need more than 4GB addressable space).
It's not 100% native 64-bit like the AMD64 is, but it's closer than the existing EM64T CPUs. From what I've read, the Core 2 is actually a bit slower when in 64-bit mode than when in 32-bit mode (but much less so than the Pentium 4-based CPUs, which were MUCH slower in 64-bit mode).
The Core 1 CPUs were basically Pentium IIIs with extra instructions and much-revamped layout and FSB. The 64-bit Pentium 4s were regular Pentium 4s with the ability to break down 64-bit instructions into chunks that the lowest-level of the CPU could work with. The Core 2 is still the venerable i686 from the good 'ole days, but they've done some rather dramatic changes (much more than from PIII -> Core 1), including execution units that can chew 64-bit instructions in the raw. The other huge advantage of Core 2 is that Intel FINALLY fixed SSE. Until now, SSE always used at least two clocks to get 128-bit work done, and usually many more. Now SSE has been fixed to be a lot more like the Altivec unit on the G4, it works like a _real_ vector coprocessor and can chew on 128-bit instructions in one clock.
Overall, my impression is that the implementation isn't as 'clean' as the AMD64, but Intel invested in all the right places, and the overall product is obviously a winner. Sometimes doing the 'wrong thing' really well is better than doing the 'right thing' three years ago and sitting on it. When AMD fixes their SIMD implementation, I'll go back to championing the Athlon; until then, the Core 2 is the best bang, for your buck or otherwise.
What I'd like to see is a system that bids up or down the wage depending on the value of the hours it needs filled. I have friends who work bars that make the same on wednesday afternoon as they do on a saturday night. Needless to say, they have a lot more 'callouts' on the weekend nights.
All the Intel-based Macs so far (excepting the ones that just came out last week) use the i945 chipset, and the integrated graphics are i950GMA chips. I believe the Linux drivers are all working, there might be some device IDs that need to be added to the drivers' #include files to let them know that the devices belong to them.
Are you serious? The i810 through the i915 are fully supported in both 2D and 3D with open-source drivers. This is just a continuation of that through the latest 945 and 965 GMA chipsets.
The open-source Intel drivers eclipsed the open-source ATI drivers a while ago too, the i945 integrated chipset benchmarks about three times the speed of my Radeon 9200 with Mesa-6.5 under xorg-7.1.
My next box is going to be an i965 with a Core 2 strapped onto it, My guess is that it will perform better in Linux than any 'real' graphics card.
http://ftp.x.org/pub/X11R7.0/doc/html/i810.4.htm l