Actually, my Dell laptop has 4 pin firewire, and my MSI Athlon64 mobo has both firewire ports, so it isn't just Sony. I have yet to see a Mac with a 4 pin port on it, but they are relatively common, as far as any PC with onboard firewire can be considered common. Of course, the only PCI cards I have run across were the 6 pin type.
Or, get something like a fanless VIA EPIA box running VNC. Perfectly silent. Runs fast over 100 Mb ethernet, and you still have all the power of your G5 for applying filters, and effects very fast. I am just about ready to make a fanless box for my own use because my Athlon 64 is too loud to comfortably sleep next to while doing renders or large downloads over night. Not as bad as some of my Sun boxen, tho... Anyhow, I think everything with fans will go in the closet, and I'll just VNC into my Sun/Mac/Athlon64 boxen for all the stuff I do.
There would be no need to install software. Just run all http traffic through a proxy server. Have the proxy server insert a Java or Javascript applet into every web page. So, while I read slashdot, a little 1 pixel by 1 pixel "web bug style" applet is busily doing some ray tracing, or some other readily paralleliseable app. The applet tells the proxy what it figured out when the user clicks to the next link, and so on. Now, how feasable is this? Assume that Java runs at 100% of native speed on whatever code you are running. Assume everybody has Java turned on. Assume everybody has a 1 GHz PIII laptop, and you average 10 people connected at a time.
A Quad opteron would probably be faster than the distributed computing setup running in the coffee shop, but it'd cost more. You can run your proxy server off a throwaway PII.
Now, who in fuck's sake are you going to sell 10 GHz worth of aggregate cycles to? The technical issue is minimal. Where is the business case? You have a fast, but high latency cluster. Bad for things like game servers. Commercial rendering services are few and far between, and you would need to take on clients who don't care that their scene files are being rendered on Joe Coffe Drinker's laptop, which ain't high security.
For anything like a game server, you really do need to have installed client software, and latency still isn't going to be what you would like. Plus, you need to pay somebody to be a tech support monkey. Thngs need to JUST WORK in order for people to keep coming back. Where is this commodity cycle market? Is it on NASDAQ?
I was diagnosed with mono on Valentines day. I also got a teddy bear from her in the mail. A week later, she explained it was over, and tried to give back the jewelry. As I understand it, *her* Valentines day was quite nice. She had a romantic dinner. Not really geeky, or related to slashdot at all, but that's my most interesting Valentines story. Or, to quote userfriendly... "It was a hell of a massacre."
Clearly, God wrote the myBrain implimentation using an object oriented language. All God had to do to impliment both Chimp and Human was to have us inherit from our superclass (earlyHominid). Chimp impliments HairyBody and FecesThrowing, while Human impliments the LanguageUser API.
LanguageUser is an API that can be used from many classes, like Thread in Java, and so Vulcan and Klingon can impliment that same API. The code reuse is, IMHO, impressive.
Naturally, with the insane inhertience involved in a complex organism, there are some unused stubs, like FleeFromBiggerFish(), or further up the inheritence tree, ConsumeSmallerOrganism(Bacteria B) which has been replaced by ConsumeSmallerOrganism(MacroscopicOrginism M)
But, the beauty of it all is that it was designed with a reasonable assumption about available resources. We haven't run out of code space, despite the lack of code sharing between VM's. Humans have plenty of room left to be a parent class for the next child class, which will impliment the ODK* 2 intelligence API's and what not!
(* The Organism Development Kit Standard Edition 2 Platform is actually ODK 1.2 -- marketing just doesn't like periods in version numbers. Also check out Organism Enterprise Edition for dynamic organisms on websites, and Organism Mobile Edition for tomagatchi like applications on cell phones!)
Your statements are all correct. What's your point? The poster I was responding to suggested that MS was hiding windows 64 because of collusion with Intel. My response was twofold. First, I pointed out that MS is certainly not hiding win64. Second, the reason you don't hear more about it isn't because Intel is making MS keep things hush hush. The reason is that it's just not ready to sell. MS sees Opteron sales, and knows that they are going to Linux. If they could have win64 ready by now, they would.
And, my mentioning Linux was pretty much just an effort to avoid being assumed to be some sort of MS shill. I'm not a fan of Windows, I just think that win2k3 will be decent when it's done. I wanted to sound leet.
First you say I have to point out than Windows Server 2003 64 bit edition is currently a free download and THEN you go on to point how totally ALPHA-Quality it is.
Mind you, this is not even slightly a Desktop OS (eg WHERE is XP-64?)
And this you're comparing to Linux on AMD64 which works pretty much as good there as it does anywhere else?
As it's been said here, Wine is not an emulator. The reason it works as well as it does is BECAUSE it's running on x86 hardware. Having it emulate x86 is going to really bog it down. I seriously doubt it will work better than VirtualPC. However, if they can get hardware vidoe acceleration working, then it might just be worth it.
Video acceleration comes free, through a few layers of abstraction. Basically, the windows program will call some Win32 API function FooDrawTextlpsz(string);
The CPU emulator runs along fine and dandy until it hits this point, and needs to jump to the Win32 native API code. It calls WINE for this.
WINE is a natively compiled PPC application / library, so FooDrawText is just native compiled PPC code.
WINE takes the Win32 function, and uses an Xlib equivalent. XFooMakeStringGetDrawn(string, MONACO) or whatever.
The X server takes this Xlib call, and passes it to the Aqua drawing system, because on Mac OS X, the X Server is just an Application running alongside other native Apps.
So, Aqua draws the text into the window at the correct position, just as windows would on a native system.
This window is treated as a texture object.
The texture is used by the Quartz Compositing engine to draw the window to the screen by using OpenGL.
OpenGL takes the instructions to draw the windows, and hands them off to the video driver.
The video driver then instructs the card to finally draw the window onto the screen, using native commands for the specific card.
Lo and behold, the X86 Win32 request to draw text has resulted in a picture of some letters in our frame buffer.
Egad, I should probably take up baking.
So, anyhow, my point is that the Wine/ppc guys don't need to write an emulator for the video hardware. Though it's heavily abstracted, they get video acceleration for free thanks to the existing Xlib code. The Win32 application never touches the actual video device - it just makes API calls which make things happen to the hardware. Now, if this were a DOS emulator, it'd be completely different. You would need to actually emulate a VGA card that the program can have to itself.
As somebody who has worm a *lot* of tin foil hats...
The tinfoil hat crowd would happily tell you that the reason there's no 64 bit windows is because Microsoft knew about this a long time ago and deliberately held off releasing Win64 technology because of some shady business dealings with Intel.
I have to point out than Windows Server 2003 64 bit edition is currently a free download from MS's website, and comes with a one year free trial.
I have it installed. I rather like it. But, it's damn well not ready for prime time. It couldn't pick up the ethernet on my Athlon64 without some headaches. Lots of people are having trouble with SATA. There is no hardware 3D, even with the latest detonators. My sound hardware apparently has no driver support of any sort.
Seriously, it just isn't ready. MS is doing some respectable things with 2k3. No stupid luna theme, IE is way locked down by default, and it bitches at you if you try a weak administrator password. (it's even pickier than Linux about what it calls 'weak')
Linux is in a much better state. Fedora Core.96 for AMD64 picked up my ethernet right off, and my sound seems to work for playing, but I haven't gotten it to record anything. The detonators are still a work in progress... I hear reports of people getting them running, but I have no luck.
And yes, I really do mean that I wear a lot of tin foil hats. I even visited the Periodic Table Table whilst wearing one. I got into a discussion with Theodore Gray about the purity of the aluminium in 'Tin Foil' Hats, while I was at Wolfram research. I own a VAX, an Athlon 64, and I've made a pilgrimage to the periodic table table. Do I get a Karma bonus?
"The real question is have they finally dumped the stupid x86 instruction set in favour of a space/energy/coding efficient RISC set?"
Now, don't take this as a troll, cus it isn't. I have Sun boxen, and PowerPC boxen at arms reach ATM, and I love them.
RISC does not always mean fast! Nor does it mean anything else! In fact, for the sorts of problems that we are facing right now, X86 actually seems like a pretty sane choice of architecture.
The company in question - Intel - sells at least a zillion processors a year. They have substantial manpower and money to throw at optimisation.
Transistors are plentiful. 1.5 zillion transistors spent on the mutha of all instruction decoders equated to exactly one tenth of one percent of the number of transistors that will be used for cache.
Latency and Bandwidth to main memory suck. Big Time. A cache miss during a fetch can literally mean 100's of cycles spent waiting. CPU's are faster than memory bandwidth, even with deluxomatic DDR8 overclocked to eleven gagillion times faster than it ought to be.
So, given this information about the current state of affairs...
We want an ISA that has very dense code. Dense code means less bandwidth spent fetching instructions. Dense code means more code fits in cache = better apparent latency.
Also, it doesn't really matter how complex the architecture gets. Simplicity would help, but we would reach a point of diminishing returns.
Now, lets compare something sane like PPC or MIPS and something evil like VAX or x86.
The RISC architectures win on simplicity. If you are on a tight budget, or have limited staff, it'll be easier to optimise a RISC design. CISC architectures or only reasonably if you are big. (In this context, yes, VIA counts as big... SGI really doesn't sell many CPU's...)
Since RISC wins in simplicity of design, it'll also tend to win in tight transistor budgets. Need big transistors because you are doing rad-hardened work? Doing embedded design that needs to fit a whole system onto a paperclip? Doing a CPU for a price-sensitive home-console? Battery life your main concern? Heat output? You should probably seriously consider a RISC approach.
Now, lets think about a classical RISC architecture versus X86 in terms of code density. For one, CISC tends to use variable length instructions. So, a simple op like "increment a register" doesn't need to take 32 bits. On RISC, you tend to have fixed instruction lengths. (I'm terribly oversimplifying, deal with it.) So, any instruction will be the full word size, no matter how small.
X86 also has some godawfully complex instructions that are very long and ugly. These instructions can usually be accomplished only with multiple instructions on a RISC architecture.
So, as you can see, in a latency/bandwidth limited application, a CISC type instruction set essentially acts as a compression scheme for your code, which can be a Big Deal.
My own favorite ISA was IBM S/370. It had variable length instructions, but everything was relatively simple. You could read the machine code if you had to -- you just had to go op by op to figure out where one instruction started and the next began. It also had those cute little 24 bit memory addresses. They were cuter than pokemon.
So, my apologies for posting such a lengthy thingamajig, but I think I've managed to stay reasonably coherent... Yeah, X86 - she's ugly and horrible, but she can be made fast if you throw a billion dollars at her!
Intel has already publicly admitted to having X86 processors with 64 bit extension in development. Also, take a look at microsoft, who refer to X86-64 as "64 bit extended architecture."
Everybody and his brother figured out long ago that Itanium is not something that will penetrate effectively into the desktop market. It's hot, expensive, incompatible, etc. It requires a ton of work to get code running smoothly on Itanium. Th only amazing thing is how long it took intel to admit that it had egg on its face!
Pixar hooked up with Disney in 'ancient times.' When Toy Story was still just an idea, nobody had *ever* made a 3D animated feature. Pixar knew they could do it, but they didn't have the marketing muscle. So, They signed a contract with disney to deliver, IIRC, five features. Disney had a sweet ride, but Pixar was never really very happy with the contract. Watch, for example, Brother Bear. Now, go watch any Pixar film. You will notice that there is a lot more interesting, grown up humor in the Pixar movies. This isn't to say that Pixer will strike out and target adult audiences with violent-anime-esque features from now on, or anything, but Pixar is going to have a lot of room to flex its creative muscles, and basically do whatever it wants. Huzzah! I simply can't wait to see what they come up with over the next five years. It ought to be grand.
Disney, meanwhile, decided to scrap all 2D animation recently. They did this because, apparently, they think Pixar's success is because they work in 3D. While this may have had a lot to do with the buzz behind TS1, it just ain't the case. The reason Pixar movies make mad money is because they are good movies. Finding Nemo could have been made with a dull pencil on notebook paper, and those guys still would have made something worth seeing!
Well, sure, *reeeealy* early printers couldn't properly print ye olde thorn, but seriously, who still uses daisywheel printers? Isn't everybody using laser/inkjet/dot matrix nowadays? Okay, so maybe I am trolling, but it still feels good!
allow me to explain this in a manner slashdotters will understand:
Middle English is like K+R C. ANSI C rewrote a lot of the rules, so K+R code won't compile on your modern gcc3, but that doesn't make it incorrect. Just archaic. If you haven't done so, I strongly reccomend checking into very early dialects of C, so you can see (C See C See) how much the language has evolved into ANSI-C, C++, Java, etc.
And, just a random rant, what ever happened to, "To Bray" ?!?! That was a great fucking verb and we have just completely lost it! Same with the infinitive "To Wold" This was some good shit, and now the language is all fucking inconsistent without an infinitive form for "I will it to be"! "To Will" is just cheezy, compared to, "To Wold."
Check out Sir Gawain and the Green Knight in the original text if you can some time. It roxxors. They brayed shit all about in that book. They had thorn as a letter, rather than this wierd "th" double letter bullshit. English was *better* then, not rougher. Think about AREXX scripting on the Amiga. It was nice and simple, and elegant. Now, we have VB and shit like that. All sorts of legacy bullshit that gets entrenched, and you can't change because of the way the scripting language worked best for some Win16 programmer in 1992. Same thing happened to English.
I, for one, welcome our middle english speaking overlords!
So, does this mean that we might be seeing 2.2 in Debian by the time 2.8 is released?
Okay, so maybe I am a troll, but I'm also a proud debian used on four architechtures!
Re:The original Macintosh had no SCSI port.
on
Macintosh 2004 Case Mod
·
· Score: 2, Interesting
I plainly stated it wasn't a stock item!:) Hell, This M0001 next to me has 1 MB of RAM. I swear to god! The SCSI is a centronics 50 port (rather than a DB25 that would later become standard) that sits vertically on the top-back of the mac. The system boots off of a SCSI 30 MB hard drive. (This was added much later that 1984, IIRC, but the original manuals that I acquired with the system were in a house fire...::sob:: The hard drive itself, amazingly, was in the fire, too, but it still boots. The system is running system 6.0.8. I wish I'd had a chance to talk to the guy who gave it to me. He just wanted rid of it. I assumed it was a classic, or something quite mundane, until I looked closer when I got it home. I was quite surprised to see I had a piece of history (for free!)
For the record, I recently got a SCSI ethernet adapter for my Macintosh. Yes, that's Macintosh. No "Plus." Model M0001. And, no, the SCSI wasn't a stock item at that point...:) I haven't quite managed to get it running as a web server. (The original macintosh has no MMU, so don't bother to suggest Linux), but It is still perfectly capable of doing lots of things without being gutted. For shame! And, once I get it running as a server on my DSL line, I fully intend to proudly put on my business cards that I am operating one of the oldest (though, certainly not the oldest) servers on the internet!
No, mine isn't. And by the way, despite the claims of the manufacturer, Soylent green is not 100% people. Quit believing advertising, and you will be just fine. Better yet, take up spectroscopy as a hobby. Chicks dig spectroscopes!
What about running the second DAC at 1.5x the voltage. Think about it for a second, and then tell me how many bits it come out to. Yes, you would have to interleave bits between the DACs, but it still ought to work...:)
Impossible? Impossible why? I don't see why this would be the case. In fact, I imagine that with minimum wiring you could run two 16bit DACs in parallel, one handling the top 16 bits at twice the voltage, the other handling the low 16.
You mean the top 16 bits at 65536x the voltage, and the other handling the low 16. Else you've just produced a 17 bit DAC.
AFAICT, this is not a Big Deal. They recieved acknolegement from the rover, they just haven't heard anything since. It's certainly possible it went haywire, and flipped itself over, and is now just doomed, but it seems unlikely. Sojourner managed to survive comms glitches, and I'm sure this buggy will, too. Hell, it's not like dropped packets are unheard of on the Internet, and we still manage to read slashdot every day.
I suppose if I was ambitious, this would be a good time for a joke about sSFGKJL%% NO CARRIER
You know, I try and explain the elegant simplicity of my God Bang theory to people and they just laugh. What could be a simpler explanation for the origin of the universe than God exploding?
<<Sometimes the most simplest answer explains the most complex things. And yet people still don't accept them. Cliff notes anyone?>>
I have to say, as somebody who has always preferred to use dual head systems, I've always wondered what game developers might come up with in a dual-head environment. RTS games with a full map and a zoomed-in view simultaneously. A FPS with front and rear views. Even without thinking hard, it's really easy to come up with novel and potentially fun uses for two screens.
Now... (And, I hope I don't get modded too far down for this...) Imagine a beowulf cluster of these things! he he.
Personally, I'm still waiting for the end form of what Virtual Boy wanted to be. A pair of small, light wight glasses that are no bulkier than a convenient pair of sunglasses, with enough CPU to make some interesting 3D scenes. Add in an accelerometer, and a bearing sensor, and you have a kick ass augmented reality platform. I'd love to see what guys like Miyamoto could do with that sort of gear!
Also, the ideo of a video- iPod suddenly stops sucking so badly when the display is a pair of glasses instead of a cheezy box you have to hold in front of yoru face.
I see you've never met an SGI die hard. Sun guys seem to be very cool, preferring Solaris, but using BSD, Linux and Mac OS X where convenient. SGI zealots whine about Macintrash, Linsux, peecee's, and place everything that isn't irix on MIPS on the same level as WinDOS.
Mac Users, by and large, are really no worse than a bad Linux Zealot. They have a nice architecture, and a decent OS, and they don't like anything else, but they don't actively attack other platforms in the same way that SGI nuts do.
<<I personally consider the Macintosh to be the "official platform" of zealotry. Mac zealots are a unique bunch and I think are the most obnoxious of zealots. Plus they have the original "figurehead" in Steve Jobs. Sure Linux has "The Linus" and Windows (can you be a Windows zealot?) has "Gates of Borg" but Jobs came before them and his reality distortion field is IMO stronger. >>
I have an original Macintosh (As in model number M0001). Still looks perfectly sharp. Monochrome monitors don't lose convergence, or suffer any color related problems like color monitors do, so it should be able to keep going for a while.
OTOH, a color monitor has three guns, so I must concede that a color monitor ought to be more likely to have at least one tube working than a monochrome monitor of the same vintage, just from a redundancy standpoint...
My oldest monitor would be my VAX monitor, but I don't have one. My VAX is a server, and comes from the days when that meant that there simply wasn't anywhere to plug a monitor into it. You damn well plug in a terminal and you like it!
Slashdot Mirror
Actually, my Dell laptop has 4 pin firewire, and my MSI Athlon64 mobo has both firewire ports, so it isn't just Sony. I have yet to see a Mac with a 4 pin port on it, but they are relatively common, as far as any PC with onboard firewire can be considered common. Of course, the only PCI cards I have run across were the 6 pin type.
Or, get something like a fanless VIA EPIA box running VNC. Perfectly silent. Runs fast over 100 Mb ethernet, and you still have all the power of your G5 for applying filters, and effects very fast. I am just about ready to make a fanless box for my own use because my Athlon 64 is too loud to comfortably sleep next to while doing renders or large downloads over night. Not as bad as some of my Sun boxen, tho... Anyhow, I think everything with fans will go in the closet, and I'll just VNC into my Sun/Mac/Athlon64 boxen for all the stuff I do.
There would be no need to install software. Just run all http traffic through a proxy server. Have the proxy server insert a Java or Javascript applet into every web page. So, while I read slashdot, a little 1 pixel by 1 pixel "web bug style" applet is busily doing some ray tracing, or some other readily paralleliseable app. The applet tells the proxy what it figured out when the user clicks to the next link, and so on. Now, how feasable is this? Assume that Java runs at 100% of native speed on whatever code you are running. Assume everybody has Java turned on. Assume everybody has a 1 GHz PIII laptop, and you average 10 people connected at a time.
A Quad opteron would probably be faster than the distributed computing setup running in the coffee shop, but it'd cost more. You can run your proxy server off a throwaway PII.
Now, who in fuck's sake are you going to sell 10 GHz worth of aggregate cycles to? The technical issue is minimal. Where is the business case? You have a fast, but high latency cluster. Bad for things like game servers. Commercial rendering services are few and far between, and you would need to take on clients who don't care that their scene files are being rendered on Joe Coffe Drinker's laptop, which ain't high security.
For anything like a game server, you really do need to have installed client software, and latency still isn't going to be what you would like. Plus, you need to pay somebody to be a tech support monkey. Thngs need to JUST WORK in order for people to keep coming back. Where is this commodity cycle market? Is it on NASDAQ?
I was diagnosed with mono on Valentines day. I also got a teddy bear from her in the mail. A week later, she explained it was over, and tried to give back the jewelry. As I understand it, *her* Valentines day was quite nice. She had a romantic dinner. Not really geeky, or related to slashdot at all, but that's my most interesting Valentines story. Or, to quote userfriendly... "It was a hell of a massacre."
Clearly, God wrote the myBrain implimentation using an object oriented language. All God had to do to impliment both Chimp and Human was to have us inherit from our superclass (earlyHominid). Chimp impliments HairyBody and FecesThrowing, while Human impliments the LanguageUser API.
LanguageUser is an API that can be used from many classes, like Thread in Java, and so Vulcan and Klingon can impliment that same API. The code reuse is, IMHO, impressive.
Naturally, with the insane inhertience involved in a complex organism, there are some unused stubs, like FleeFromBiggerFish(), or further up the inheritence tree, ConsumeSmallerOrganism(Bacteria B) which has been replaced by ConsumeSmallerOrganism(MacroscopicOrginism M)
But, the beauty of it all is that it was designed with a reasonable assumption about available resources. We haven't run out of code space, despite the lack of code sharing between VM's. Humans have plenty of room left to be a parent class for the next child class, which will impliment the ODK* 2 intelligence API's and what not!
(* The Organism Development Kit Standard Edition 2 Platform is actually ODK 1.2 -- marketing just doesn't like periods in version numbers. Also check out Organism Enterprise Edition for dynamic organisms on websites, and Organism Mobile Edition for tomagatchi like applications on cell phones!)
don't worry -- I've got it! Imagine Darl, petrified, and with hit grits down his pants!
Your statements are all correct. What's your point? The poster I was responding to suggested that MS was hiding windows 64 because of collusion with Intel. My response was twofold. First, I pointed out that MS is certainly not hiding win64. Second, the reason you don't hear more about it isn't because Intel is making MS keep things hush hush. The reason is that it's just not ready to sell. MS sees Opteron sales, and knows that they are going to Linux. If they could have win64 ready by now, they would.
And, my mentioning Linux was pretty much just an effort to avoid being assumed to be some sort of MS shill. I'm not a fan of Windows, I just think that win2k3 will be decent when it's done. I wanted to sound leet.
First you say I have to point out than Windows Server 2003 64 bit edition is currently a free download and THEN you go on to point how totally ALPHA-Quality it is.
Mind you, this is not even slightly a Desktop OS (eg WHERE is XP-64?)
And this you're comparing to Linux on AMD64 which works pretty much as good there as it does anywhere else?
As it's been said here, Wine is not an emulator. The reason it works as well as it does is BECAUSE it's running on x86 hardware. Having it emulate x86 is going to really bog it down. I seriously doubt it will work better than VirtualPC. However, if they can get hardware vidoe acceleration working, then it might just be worth it.
Video acceleration comes free, through a few layers of abstraction. Basically, the windows program will call some Win32 API function
FooDrawTextlpsz(string);
The CPU emulator runs along fine and dandy until it hits this point, and needs to jump to the Win32 native API code. It calls WINE for this.
WINE is a natively compiled PPC application / library, so FooDrawText is just native compiled PPC code.
WINE takes the Win32 function, and uses an Xlib equivalent. XFooMakeStringGetDrawn(string, MONACO) or whatever.
The X server takes this Xlib call, and passes it to the Aqua drawing system, because on Mac OS X, the X Server is just an Application running alongside other native Apps.
So, Aqua draws the text into the window at the correct position, just as windows would on a native system.
This window is treated as a texture object.
The texture is used by the Quartz Compositing engine to draw the window to the screen by using OpenGL.
OpenGL takes the instructions to draw the windows, and hands them off to the video driver.
The video driver then instructs the card to finally draw the window onto the screen, using native commands for the specific card.
Lo and behold, the X86 Win32 request to draw text has resulted in a picture of some letters in our frame buffer.
Egad, I should probably take up baking.
So, anyhow, my point is that the Wine/ppc guys don't need to write an emulator for the video hardware. Though it's heavily abstracted, they get video acceleration for free thanks to the existing Xlib code. The Win32 application never touches the actual video device - it just makes API calls which make things happen to the hardware. Now, if this were a DOS emulator, it'd be completely different. You would need to actually emulate a VGA card that the program can have to itself.
As somebody who has worm a *lot* of tin foil hats...
.96 for AMD64 picked up my ethernet right off, and my sound seems to work for playing, but I haven't gotten it to record anything. The detonators are still a work in progress... I hear reports of people getting them running, but I have no luck.
The tinfoil hat crowd would happily tell you that the reason there's no 64 bit windows is because Microsoft knew about this a long time ago and deliberately held off releasing Win64 technology because of some shady business dealings with Intel.
I have to point out than Windows Server 2003 64 bit edition is currently a free download from MS's website, and comes with a one year free trial.
I have it installed. I rather like it. But, it's damn well not ready for prime time. It couldn't pick up the ethernet on my Athlon64 without some headaches. Lots of people are having trouble with SATA. There is no hardware 3D, even with the latest detonators. My sound hardware apparently has no driver support of any sort.
Seriously, it just isn't ready. MS is doing some respectable things with 2k3. No stupid luna theme, IE is way locked down by default, and it bitches at you if you try a weak administrator password. (it's even pickier than Linux about what it calls 'weak')
Linux is in a much better state. Fedora Core
And yes, I really do mean that I wear a lot of tin foil hats. I even visited the Periodic Table Table whilst wearing one. I got into a discussion with Theodore Gray about the purity of the aluminium in 'Tin Foil' Hats, while I was at Wolfram research. I own a VAX, an Athlon 64, and I've made a pilgrimage to the periodic table table. Do I get a Karma bonus?
"The real question is have they finally dumped the stupid x86 instruction set in favour of a space/energy/coding efficient RISC set?"
Now, don't take this as a troll, cus it isn't. I have Sun boxen, and PowerPC boxen at arms reach ATM, and I love them.
RISC does not always mean fast! Nor does it mean anything else! In fact, for the sorts of problems that we are facing right now, X86 actually seems like a pretty sane choice of architecture.
The company in question - Intel - sells at least a zillion processors a year. They have substantial manpower and money to throw at optimisation.
Transistors are plentiful. 1.5 zillion transistors spent on the mutha of all instruction decoders equated to exactly one tenth of one percent of the number of transistors that will be used for cache.
Latency and Bandwidth to main memory suck. Big Time. A cache miss during a fetch can literally mean 100's of cycles spent waiting. CPU's are faster than memory bandwidth, even with deluxomatic DDR8 overclocked to eleven gagillion times faster than it ought to be.
So, given this information about the current state of affairs...
We want an ISA that has very dense code. Dense code means less bandwidth spent fetching instructions. Dense code means more code fits in cache = better apparent latency.
Also, it doesn't really matter how complex the architecture gets. Simplicity would help, but we would reach a point of diminishing returns.
Now, lets compare something sane like PPC or MIPS and something evil like VAX or x86.
The RISC architectures win on simplicity. If you are on a tight budget, or have limited staff, it'll be easier to optimise a RISC design. CISC architectures or only reasonably if you are big. (In this context, yes, VIA counts as big... SGI really doesn't sell many CPU's...)
Since RISC wins in simplicity of design, it'll also tend to win in tight transistor budgets. Need big transistors because you are doing rad-hardened work? Doing embedded design that needs to fit a whole system onto a paperclip? Doing a CPU for a price-sensitive home-console? Battery life your main concern? Heat output? You should probably seriously consider a RISC approach.
Now, lets think about a classical RISC architecture versus X86 in terms of code density. For one, CISC tends to use variable length instructions. So, a simple op like "increment a register" doesn't need to take 32 bits. On RISC, you tend to have fixed instruction lengths. (I'm terribly oversimplifying, deal with it.) So, any instruction will be the full word size, no matter how small.
X86 also has some godawfully complex instructions that are very long and ugly. These instructions can usually be accomplished only with multiple instructions on a RISC architecture.
So, as you can see, in a latency/bandwidth limited application, a CISC type instruction set essentially acts as a compression scheme for your code, which can be a Big Deal.
My own favorite ISA was IBM S/370. It had variable length instructions, but everything was relatively simple. You could read the machine code if you had to -- you just had to go op by op to figure out where one instruction started and the next began. It also had those cute little 24 bit memory addresses. They were cuter than pokemon.
So, my apologies for posting such a lengthy thingamajig, but I think I've managed to stay reasonably coherent... Yeah, X86 - she's ugly and horrible, but she can be made fast if you throw a billion dollars at her!
Intel has already publicly admitted to having X86 processors with 64 bit extension in development. Also, take a look at microsoft, who refer to X86-64 as "64 bit extended architecture."
Everybody and his brother figured out long ago that Itanium is not something that will penetrate effectively into the desktop market. It's hot, expensive, incompatible, etc. It requires a ton of work to get code running smoothly on Itanium. Th only amazing thing is how long it took intel to admit that it had egg on its face!
Pixar hooked up with Disney in 'ancient times.' When Toy Story was still just an idea, nobody had *ever* made a 3D animated feature. Pixar knew they could do it, but they didn't have the marketing muscle. So, They signed a contract with disney to deliver, IIRC, five features. Disney had a sweet ride, but Pixar was never really very happy with the contract. Watch, for example, Brother Bear. Now, go watch any Pixar film. You will notice that there is a lot more interesting, grown up humor in the Pixar movies. This isn't to say that Pixer will strike out and target adult audiences with violent-anime-esque features from now on, or anything, but Pixar is going to have a lot of room to flex its creative muscles, and basically do whatever it wants. Huzzah! I simply can't wait to see what they come up with over the next five years. It ought to be grand.
Disney, meanwhile, decided to scrap all 2D animation recently. They did this because, apparently, they think Pixar's success is because they work in 3D. While this may have had a lot to do with the buzz behind TS1, it just ain't the case. The reason Pixar movies make mad money is because they are good movies. Finding Nemo could have been made with a dull pencil on notebook paper, and those guys still would have made something worth seeing!
Wait, why is the balrog in SF2? And, does the street fighter two balrog have wings? Oh, wait, now I get it... Balrogs have shiny wings!
t m
Amazingly, this *is* on topic!
http://nfg.2y.net/games/x68k_sleeves/capcom1.sh
Wow, I totally didn't realise how awesome the world was when I was a kid!
Well, sure, *reeeealy* early printers couldn't properly print ye olde thorn, but seriously, who still uses daisywheel printers? Isn't everybody using laser/inkjet/dot matrix nowadays? Okay, so maybe I am trolling, but it still feels good!
allow me to explain this in a manner slashdotters will understand :
Middle English is like K+R C. ANSI C rewrote a lot of the rules, so K+R code won't compile on your modern gcc3, but that doesn't make it incorrect. Just archaic. If you haven't done so, I strongly reccomend checking into very early dialects of C, so you can see (C See C See) how much the language has evolved into ANSI-C, C++, Java, etc.
And, just a random rant, what ever happened to, "To Bray" ?!?! That was a great fucking verb and we have just completely lost it! Same with the infinitive "To Wold" This was some good shit, and now the language is all fucking inconsistent without an infinitive form for "I will it to be"! "To Will" is just cheezy, compared to, "To Wold."
Check out Sir Gawain and the Green Knight in the original text if you can some time. It roxxors. They brayed shit all about in that book. They had thorn as a letter, rather than this wierd "th" double letter bullshit. English was *better* then, not rougher. Think about AREXX scripting on the Amiga. It was nice and simple, and elegant. Now, we have VB and shit like that. All sorts of legacy bullshit that gets entrenched, and you can't change because of the way the scripting language worked best for some Win16 programmer in 1992. Same thing happened to English.
I, for one, welcome our middle english speaking overlords!
So, does this mean that we might be seeing 2.2 in Debian by the time 2.8 is released?
Okay, so maybe I am a troll, but I'm also a proud debian used on four architechtures!
I plainly stated it wasn't a stock item! :) Hell, This M0001 next to me has 1 MB of RAM. I swear to god! The SCSI is a centronics 50 port (rather than a DB25 that would later become standard) that sits vertically on the top-back of the mac. The system boots off of a SCSI 30 MB hard drive. (This was added much later that 1984, IIRC, but the original manuals that I acquired with the system were in a house fire... ::sob:: The hard drive itself, amazingly, was in the fire, too, but it still boots. The system is running system 6.0.8. I wish I'd had a chance to talk to the guy who gave it to me. He just wanted rid of it. I assumed it was a classic, or something quite mundane, until I looked closer when I got it home. I was quite surprised to see I had a piece of history (for free!)
For the record, I recently got a SCSI ethernet adapter for my Macintosh. Yes, that's Macintosh. No "Plus." Model M0001. And, no, the SCSI wasn't a stock item at that point... :) I haven't quite managed to get it running as a web server. (The original macintosh has no MMU, so don't bother to suggest Linux), but It is still perfectly capable of doing lots of things without being gutted. For shame! And, once I get it running as a server on my DSL line, I fully intend to proudly put on my business cards that I am operating one of the oldest (though, certainly not the oldest) servers on the internet!
No, mine isn't. And by the way, despite the claims of the manufacturer, Soylent green is not 100% people. Quit believing advertising, and you will be just fine. Better yet, take up spectroscopy as a hobby. Chicks dig spectroscopes!
What about running the second DAC at 1.5x the voltage. Think about it for a second, and then tell me how many bits it come out to. Yes, you would have to interleave bits between the DACs, but it still ought to work...
Impossible? Impossible why? I don't see why this would be the case. In fact, I imagine that with minimum wiring you could run two 16bit DACs in parallel, one handling the top 16 bits at twice the voltage, the other handling the low 16.
You mean the top 16 bits at 65536x the voltage, and the other handling the low 16. Else you've just produced a 17 bit DAC.
AFAICT, this is not a Big Deal. They recieved acknolegement from the rover, they just haven't heard anything since. It's certainly possible it went haywire, and flipped itself over, and is now just doomed, but it seems unlikely. Sojourner managed to survive comms glitches, and I'm sure this buggy will, too. Hell, it's not like dropped packets are unheard of on the Internet, and we still manage to read slashdot every day.
I suppose if I was ambitious, this would be a good time for a joke about sSFGKJL%% NO CARRIER
You know, I try and explain the elegant simplicity of my God Bang theory to people and they just laugh. What could be a simpler explanation for the origin of the universe than God exploding?
<<Sometimes the most simplest answer explains the most complex things. And yet people still don't accept them. Cliff notes anyone?>>
I have to say, as somebody who has always preferred to use dual head systems, I've always wondered what game developers might come up with in a dual-head environment. RTS games with a full map and a zoomed-in view simultaneously. A FPS with front and rear views. Even without thinking hard, it's really easy to come up with novel and potentially fun uses for two screens.
Now... (And, I hope I don't get modded too far down for this...) Imagine a beowulf cluster of these things! he he.
Personally, I'm still waiting for the end form of what Virtual Boy wanted to be. A pair of small, light wight glasses that are no bulkier than a convenient pair of sunglasses, with enough CPU to make some interesting 3D scenes. Add in an accelerometer, and a bearing sensor, and you have a kick ass augmented reality platform. I'd love to see what guys like Miyamoto could do with that sort of gear!
Also, the ideo of a video- iPod suddenly stops sucking so badly when the display is a pair of glasses instead of a cheezy box you have to hold in front of yoru face.
I see you've never met an SGI die hard. Sun guys seem to be very cool, preferring Solaris, but using BSD, Linux and Mac OS X where convenient. SGI zealots whine about Macintrash, Linsux, peecee's, and place everything that isn't irix on MIPS on the same level as WinDOS.
Mac Users, by and large, are really no worse than a bad Linux Zealot. They have a nice architecture, and a decent OS, and they don't like anything else, but they don't actively attack other platforms in the same way that SGI nuts do.
<<I personally consider the Macintosh to be the "official platform" of zealotry. Mac zealots are a unique bunch and I think are the most obnoxious of zealots. Plus they have the original "figurehead" in Steve Jobs. Sure Linux has "The Linus" and Windows (can you be a Windows zealot?) has "Gates of Borg" but Jobs came before them and his reality distortion field is IMO stronger.
>>
<
Cheers,
Ian>>
I have an original Macintosh (As in model number M0001). Still looks perfectly sharp. Monochrome monitors don't lose convergence, or suffer any color related problems like color monitors do, so it should be able to keep going for a while.
OTOH, a color monitor has three guns, so I must concede that a color monitor ought to be more likely to have at least one tube working than a monochrome monitor of the same vintage, just from a redundancy standpoint...
My oldest monitor would be my VAX monitor, but I don't have one. My VAX is a server, and comes from the days when that meant that there simply wasn't anywhere to plug a monitor into it. You damn well plug in a terminal and you like it!