So you're talking about a system that's about $1540 pre-shipping (which would probably run close to $100). And that's with the cheapest motherboard and RAM money can buy.
The dual 1.8ghz machine with otherwise similar specs from Apple is $1999. So you're paying a premium for quality system design and support, and software.
Somehow I doubt that Alienware will get the patents that are 'pending' - I'd imagine that SGI probably already has a whole portfolio covering this area, since this kind of thing is their bread and butter.
RTFA: It's not using SLI. The screen is divided in half; one card handles the top half, the other handles the bottom. Both cards have to use the same driver, and there's an additional PCI card that syncs things up. It's an expensive and relatively inefficient solution.
How I assume it's going to work: both cards keep the same geometry/texture/whatever information in RAM. They both try and render the same scene, only the software tells each to render only one half of the screenby "blue-screening" -- defining a polygon that's solid blue that covers one half of the screen. Since all modern video cards do an early Z, the polys under the blue poly will never be tessellated and filled. The pixels for the blue polygon are really easy to fill. Then, the compositor card uses the blue screens as masks.
Again, that's just a guess. My knowledge of OpenGL and other 3D programming API's is limited to my senior project. You may be able to define viewable windows and background colors or something.
RTFA: Multiple patents pending on the technology. Likely not on the concept of having multiple PCI Express x16 slots, just on the software and compositing/sync hardware.
I was speaking about general editing tasks -- cutting and pasting, saving/loading files -- normal stuff.
Saying "administrative tasks" is pretty general as well. Yeah, if I want to delete every third XML file containing the word "caramel", that's easier and faster on the command line. Copying a group of files or renaming stuff is often faster in a GUI. It's also faster in a GUI to change preferences/options than to edit random text files in/etc by hand.
That being said, I truly appreciate being able to do so from either angle; that way I can SSH in over a slow link and still get real work done.
If I recall correctly, Xerox did the same kind of study in the late 70's/early 80's. They made an experimental fully-graphical interface and word processor. They tested experienced users using both emacs and the graphical word processor, and the GUI always won.
I could be slightly incorrect with the details here, particularly with the dates. My HCI professor at college told me she was part of the test when she worked at Xerox PARC.
I'm guessing that you are planning on running very large memory applications (> 2 Gig per process), otherwise 64bit support is useless.
Not at all true! AMD64 has twice the number of general-purpose registers available in 64-bit mode. Some apps also just run faster in 64-bit, like POVray.
The difference with the on-board RAID on most mobo's is that you can boot to the RAID array. With pure software RAID, you need a non-RAID drive to boot from.
Yay -- a clone of RegEdit.exe! Just what the doctor ordered! And I thought Linux would never get as cryptic as Windows!
Seriously... you've got to be kidding. Although it's *slightly* less awful than RegEdit, it still sucks. I was still unable to find a way to change the highlight color in a given theme.
Some people don't like the "spatial" nautilus and would prefer the default behavior to be just like every other damn UI currently used. Some people like to change colors of UI elements because they otherwise like a theme, but can't stand the damn ugly yellow the theme designer chose for the highlight color.
And yes, these are individual preferences. People who fall in the "power user" catagory are important too. And no, "power user" != "ueber-hacker" for all values. Some people just like to get damn work done in a way that makes sense for them.
On *NIX, I currently use KDE, which also is quite imperfect (KControl sucks, too many different freakin' media players, some odd behavioral quirks), but at least I can make it act more like how I want without firing up emacs and reading docs online.
Although his tone was attrocious, I have to agree with him on some points. GNOME is too damn hard to configure. Yes, simplicity is a good thing, but if that's what you want, keep all of the other options *somewhere*, even if it's buried. The KDE tactic -- throw a billion options at the user on one screen -- isn't good either.
There are plenty of ways of solving the problem. Unfortunately, GNOME took the approach that if the users don't like it, they better learn vi.
I have to say I'm the same way. There's a few popular bands I like (or, bands that were once popular -- Pink Floyd, Rush, Cream, etc.), but for the most part I tend to buy obscure progressive rock and classical stuff that you'd never hear on ClearChannel.
And yes, downloading MP3's is pretty much a pre-req to buying a CD. I'm not dropping $10-$20 on an album if I'm not sure I'll like it.
Honestly, before I signed a contract to buy a house, I was spending about $100/month on music for the past year. No way I'd pay for ANY form of lossy-compressed audio, though. I'll buy the CD, rip Oggs, and take it to work so I can listen easilly.
It's an unexpected turn that makes a LOT of sense. If you read the article, the real catalyst for this change is the decision to go with 2 or more cores on one die that share the same L2 cache. The P4 is a poor architecture to do this with. Yes, nothing can really beat it at simple integer math, but it's got lots of problems:
1) The core is fscking big! 2) high frequency == draws lots of juice == runs way too hot 3) 20 stage pipeline (or like 30 in case of Prescott) makes penalties way too high on a branch mis-prediction, and requires more cache to minimize the impact.
The Pentium M architecture has a relatively high IPC, and lack of int throughput that is lost from lower overall clockspeed can be overcome by paralellism that multicore will bring. It also is rather efficient as far as power goes, and a much smaller core overall.
Perfectly valid point; you can tweak the hell out of any OS. Most modern distros come with something Windows-update-esqu. I just thought the parent had a one-sided view.
I set stuff up on my parents' Win2K box to make my troubleshooting life easier. Honestly, I'm hoping by the next time they get a new PC that the big retailers will offer a decent Linux distro pre-installed and pre-configured with a rescue-disc type thingie. The only reason I haven't switched them over is because they want support, and the ability to just plug in the rescue disc and have it work.
Or I could convince them to spend the extra bucks and get a Mac. OSX would be loads easier to troubleshoot, expecially since I don't run Windows outside of work any more.
No, but I could make a link on my mom's desktop that runs "apt-get update && apt-get dist-upgrade", and another that emails me her IP address so I can fix it via SSH...
To the best of my knowledge, there's no such thing as a Linux virus. There are worms and trojan horses, but no amount of anti-virus software is going to stop a dumb user from executing a trojan.
AMD has a dual-core version of the Opteron due in '05... and supposedly it's pin-compatible with the single core models. You can use todays motherboards, and slap 2-core versions in to turn a 2-socket board into a 4-way system. That is a sweet upgrade...
Python and Perl attempt to solve more or less the same problems in different ways. The main difference is that Python is executable pseudocode, while Perl is executable line noise.
Neither. DVI would be impossible, and we're not talking about real-time stuff. The AGP/PCI Express X16 bus would be fine. The GPU would be treated like a parallel vector math unit, and be able to process large groups of pixels, and store them in VRAM, which would be used more like conventional RAM than a frame buffer. When the frame (or part of it) is done, it's sent back to main memory or hard disc. AGP can actually do this easilly through sideband addressing (accessing main memory without arbitration of the CPU. Not sure about PCI Express, but it offers a hell of a lot more bandwidth.
DVI can handle 8/16/32-bit color at upwards of 1600x1200. For film, you'd want way higher resolution (at least 1922x1080) stored at at least 64bit floating-point color depth for post-processing.
Hello? We're not talking about real-time rendering here! We're talking about final renderings for movies at way higher res than most TMDS transmitters can handle, and WAY higher color depth than is supported by DVI (128-bit floating-point)
I don't know... remember, NVIDIA makes AMD chipsets. I could see NVIDIA making a successor to the nForce3 line that is made for a render-cluster node: Dual (or quad, or even 8-way) Opteron, 8 PCI Express X16 slots... If this tech can do what they are saying, it could be incredibly profitable. How many outfits would pay top dollar to have their rendering time cut by a factor of 10 or greater?
If SCO goes bankrupt, this (I assume) goes in a legal round file somewhere. Then we can just wait for Microsoft to come at us directly with an army of lawyers that dwarfs IBM.
Not bloody likely. IBM is a bigger company with a much bigger patent portfolio and many more lawyers than Microsoft.
Slashdot Mirror
Ok... here goes... the cheapest dual Opteron system I can build, based on the 1.8ghz Opteron 244:
Mobo: MSI K8T Master2-FAR $220
CPU1: AMD Opteron 244, Retail $330
CPU1: AMD Opteron 244, Retail $330
DIMM1: 128MB ECC Registered DIMM $ 60
DIMM1: 128MB ECC Registered DIMM $ 60
HDA1: WD800JD 7200RPM 80GB SATA $ 75
VID: GeForceFX 5200 $ 55
DVD: 8X DVD+/-RW $ 90
CASE: Lian-Li PC-V1000 $200
PWR: Antec TRUE430 $ 70
MISC: keyboard, mouse, fans, etc.$ 50
=====
total $1540
So you're talking about a system that's about $1540 pre-shipping (which would probably run close to $100). And that's with the cheapest motherboard and RAM money can buy.
The dual 1.8ghz machine with otherwise similar specs from Apple is $1999. So you're paying a premium for quality system design and support, and software.
Somehow I doubt that Alienware will get the patents that are 'pending' - I'd imagine that SGI probably already has a whole portfolio covering this area, since this kind of thing is their bread and butter.
Yes, because nobody is granted patents when there is a lot of prior art.
RTFA: It's not using SLI. The screen is divided in half; one card handles the top half, the other handles the bottom. Both cards have to use the same driver, and there's an additional PCI card that syncs things up. It's an expensive and relatively inefficient solution.
How I assume it's going to work: both cards keep the same geometry/texture/whatever information in RAM. They both try and render the same scene, only the software tells each to render only one half of the screenby "blue-screening" -- defining a polygon that's solid blue that covers one half of the screen. Since all modern video cards do an early Z, the polys under the blue poly will never be tessellated and filled. The pixels for the blue polygon are really easy to fill. Then, the compositor card uses the blue screens as masks.
Again, that's just a guess. My knowledge of OpenGL and other 3D programming API's is limited to my senior project. You may be able to define viewable windows and background colors or something.
RTFA: Multiple patents pending on the technology. Likely not on the concept of having multiple PCI Express x16 slots, just on the software and compositing/sync hardware.
Hence the use of the word "often", and the example I gave of deleting every third XML file that contains the word "caramel".
I was speaking about general editing tasks -- cutting and pasting, saving/loading files -- normal stuff.
/etc by hand.
Saying "administrative tasks" is pretty general as well. Yeah, if I want to delete every third XML file containing the word "caramel", that's easier and faster on the command line. Copying a group of files or renaming stuff is often faster in a GUI. It's also faster in a GUI to change preferences/options than to edit random text files in
That being said, I truly appreciate being able to do so from either angle; that way I can SSH in over a slow link and still get real work done.
If I recall correctly, Xerox did the same kind of study in the late 70's/early 80's. They made an experimental fully-graphical interface and word processor. They tested experienced users using both emacs and the graphical word processor, and the GUI always won.
I could be slightly incorrect with the details here, particularly with the dates. My HCI professor at college told me she was part of the test when she worked at Xerox PARC.
Not at all true! AMD64 has twice the number of general-purpose registers available in 64-bit mode. Some apps also just run faster in 64-bit, like POVray.
The difference with the on-board RAID on most mobo's is that you can boot to the RAID array. With pure software RAID, you need a non-RAID drive to boot from.
Yay -- a clone of RegEdit.exe! Just what the doctor ordered! And I thought Linux would never get as cryptic as Windows!
Seriously... you've got to be kidding. Although it's *slightly* less awful than RegEdit, it still sucks. I was still unable to find a way to change the highlight color in a given theme.
Some people don't like the "spatial" nautilus and would prefer the default behavior to be just like every other damn UI currently used. Some people like to change colors of UI elements because they otherwise like a theme, but can't stand the damn ugly yellow the theme designer chose for the highlight color.
And yes, these are individual preferences. People who fall in the "power user" catagory are important too. And no, "power user" != "ueber-hacker" for all values. Some people just like to get damn work done in a way that makes sense for them.
On *NIX, I currently use KDE, which also is quite imperfect (KControl sucks, too many different freakin' media players, some odd behavioral quirks), but at least I can make it act more like how I want without firing up emacs and reading docs online.
Although his tone was attrocious, I have to agree with him on some points. GNOME is too damn hard to configure. Yes, simplicity is a good thing, but if that's what you want, keep all of the other options *somewhere*, even if it's buried. The KDE tactic -- throw a billion options at the user on one screen -- isn't good either.
There are plenty of ways of solving the problem. Unfortunately, GNOME took the approach that if the users don't like it, they better learn vi.
I have to say I'm the same way. There's a few popular bands I like (or, bands that were once popular -- Pink Floyd, Rush, Cream, etc.), but for the most part I tend to buy obscure progressive rock and classical stuff that you'd never hear on ClearChannel.
And yes, downloading MP3's is pretty much a pre-req to buying a CD. I'm not dropping $10-$20 on an album if I'm not sure I'll like it.
Honestly, before I signed a contract to buy a house, I was spending about $100/month on music for the past year. No way I'd pay for ANY form of lossy-compressed audio, though. I'll buy the CD, rip Oggs, and take it to work so I can listen easilly.
It's an unexpected turn that makes a LOT of sense. If you read the article, the real catalyst for this change is the decision to go with 2 or more cores on one die that share the same L2 cache. The P4 is a poor architecture to do this with. Yes, nothing can really beat it at simple integer math, but it's got lots of problems:
1) The core is fscking big!
2) high frequency == draws lots of juice == runs way too hot
3) 20 stage pipeline (or like 30 in case of Prescott) makes penalties way too high on a branch mis-prediction, and requires more cache to minimize the impact.
The Pentium M architecture has a relatively high IPC, and lack of int throughput that is lost from lower overall clockspeed can be overcome by paralellism that multicore will bring. It also is rather efficient as far as power goes, and a much smaller core overall.
Perfectly valid point; you can tweak the hell out of any OS. Most modern distros come with something Windows-update-esqu. I just thought the parent had a one-sided view.
I set stuff up on my parents' Win2K box to make my troubleshooting life easier. Honestly, I'm hoping by the next time they get a new PC that the big retailers will offer a decent Linux distro pre-installed and pre-configured with a rescue-disc type thingie. The only reason I haven't switched them over is because they want support, and the ability to just plug in the rescue disc and have it work.
Or I could convince them to spend the extra bucks and get a Mac. OSX would be loads easier to troubleshoot, expecially since I don't run Windows outside of work any more.
No, but I could make a link on my mom's desktop that runs "apt-get update && apt-get dist-upgrade", and another that emails me her IP address so I can fix it via SSH...
To the best of my knowledge, there's no such thing as a Linux virus. There are worms and trojan horses, but no amount of anti-virus software is going to stop a dumb user from executing a trojan.
Ok, then, use a distributed client... rent peoples CPU time, and run the script on millions of PC's.
AMD has a dual-core version of the Opteron due in '05... and supposedly it's pin-compatible with the single core models. You can use todays motherboards, and slap 2-core versions in to turn a 2-socket board into a 4-way system. That is a sweet upgrade...
It was explained to me like this once:
Python and Perl attempt to solve more or less the same problems in different ways. The main difference is that Python is executable pseudocode, while Perl is executable line noise.
Neither. DVI would be impossible, and we're not talking about real-time stuff. The AGP/PCI Express X16 bus would be fine. The GPU would be treated like a parallel vector math unit, and be able to process large groups of pixels, and store them in VRAM, which would be used more like conventional RAM than a frame buffer. When the frame (or part of it) is done, it's sent back to main memory or hard disc. AGP can actually do this easilly through sideband addressing (accessing main memory without arbitration of the CPU. Not sure about PCI Express, but it offers a hell of a lot more bandwidth.
DVI can handle 8/16/32-bit color at upwards of 1600x1200. For film, you'd want way higher resolution (at least 1922x1080) stored at at least 64bit floating-point color depth for post-processing.
Hello? We're not talking about real-time rendering here! We're talking about final renderings for movies at way higher res than most TMDS transmitters can handle, and WAY higher color depth than is supported by DVI (128-bit floating-point)
I don't know... remember, NVIDIA makes AMD chipsets. I could see NVIDIA making a successor to the nForce3 line that is made for a render-cluster node: Dual (or quad, or even 8-way) Opteron, 8 PCI Express X16 slots... If this tech can do what they are saying, it could be incredibly profitable. How many outfits would pay top dollar to have their rendering time cut by a factor of 10 or greater?
This is just the next logical progression.
- If SCO goes bankrupt, this (I assume) goes in a legal round file somewhere. Then we can just wait for Microsoft to come at us directly with an army of lawyers that dwarfs IBM.
Not bloody likely. IBM is a bigger company with a much bigger patent portfolio and many more lawyers than Microsoft.FYI -- the Dell 20.1" 2001FP routinely sells for $900 or so. I've seen a Dell promotion where it sold for $750.