Whoops! That should read: 32-bit MIPS R4400SC. MIPS processors with PC in the name don't even have secondary (L2) cache. I mean, the SC in R4400SC stands for secondary cache; you'd think that I would pay more attention. And seeing how hinv on that machine reports 1 megabyte of secondary cache, I don't see how I could have anything other than a SC processor.
Ever since the 8086/8088 duo, the bus width of a CPU has been decoupled from its word size. For a long time, the external bus width of (non Rambus) 32-bit CPUs has been wider than 32 bits.
I realize this, and at no point did I say that 32-bit CPUs used data buses that were only 32 bits wide. But it only makes sense that the width of the data bus for a 64-bit CPU would be twice that of a 32-bit CPU, whatever that might be (128 bits, 256 bits, you get the point).
You could put a small cache in a 64-bit CPU. I don't really see the point of that statement. While a huge amount of cache isn't a requirement for 64-bit CPUs per se, I've yet to see a 64-bit CPU that didn't have easily twice as much cache as a 32-bit x86 CPU.
Hell, the 32-bit MIPS R4400PC that powers the SGI Indy sitting next to me has 1 megabyte of L2 cache, and it was made back in something like 1995.
64 bits has little to do with it; you're mostly paying for cache and bandwidth when you buy high end CPUs.
When did I say otherwise? While that's certainly how the majority of the price breaks down, the large cache size isn't why you buy them.
Why they want to remove things that make programming easier is beyond me.
One of the things about a true RISC processor is that it has no microcode, no microengine, etc. The instructions run directly on the bare hardware.
This means that the instructions that would require a microengine to implement get taken out of the instruction set.
Additionally, RISC favors a more simplified instruction set design (using simple memory address modes instead of complex ones, can only load/store directly to or directly from registers, etc.) with LOTS of general purpose registers, which, as far as assembly programming goes, actually make things easier. In reality, most of the instructions that get left out would never have been used, so it's a waste to include them. The x86 instruction set, for example, is chock full of opcodes that nobody uses.
The only real disadvantage to RISC is the larger code size.
But ask anybody who has done assembly language programming on both x86 and a decent RISC architecture which of the two they prefer, and x86 will most always lose out.
64-bit code needs 8 bytes to hold every pointer. This will serve to eat up more cache and memory bandwidth, which are already major bottlenecks for any CPU.
The only thing this eats up is cache; because the system has a correspondingly wider data bus, there isn't a hit in memory bandwidth (unless the designers are trying to be cheap bastards and give a 64-bit CPU the same data bus width you'd use for a 32-bit CPU). And most 64-bit CPUs have a lot of cache.
And as for what kind of applications you potentially need several gigabytes worth of memory for, there's scientific processing and the like.
This is why I hate New Scientist. I think its very possible that they exist solely to keep the population misinformed.
DNA is not a complete blueprint on how to build a human being. This is why clones don't look exactly like what they are a clone of.
Besides, listening solely to geneticists on human behavior is like listening to somebody who's only designed CPUs talk about artificial intelligence; chances are, they aren't giving you the complete picture, most likely because they themselves don't have it. The human brain is self-organizing to a degree, and does much of this based on environmental influences. A clone of you would not have your memories, would not act like you, would not think like you, and would not even look exactly like you.
While I think that genetics can make us lean a little one way or the other when it comes to things like personality types, the development of a human being is such a complex process, you cannot simply attribute the way a person behaves solely to one thing.
And, of course, the whole "genetics determine personality and behavior" is just a convenient and legitimate-sounding way for some people to shirk personal responsibility. "No your honor, I didn't want to kill him, but the men in my family are genetically pre-disposed towards agressive, often murderous behavior! My dad killed my mom, so I can't be blamed for shooting that guy, because it was the murderer genes I inherited that made me do it!"
he was coached not only by Jackson, but by the FX supervisor
Actors playing live-action characters get coached by several people too. The director, their voice coach (if they're not doing their native accent), their acting coach, sometimes even the cinematographer.
Which is why our current obsession with actors and the thinking that what we see on screen is all them (ignoring the director, the screenwriter, the editor, the cinematographer, etc.) is just plain dumb.
At one point we were talking about Gollum as this creature that could transcend human movement. So he could do spider-like or frog-like things, like jumping on a wall and sticking to it. But as we started filming Andy -- he was a very good actor. He portrayed the role to the enth degree, and a lot of the motion that you see coming out of our digital Gollum is, joint for joint, what Andy Serkis was doing on the set.
Note to Slashdot Editors: please stop refering to Film Gimp as a tool used by movie studios. It isn't.
Rather, it is a tool used by VFX studios. While the VFX studios may work for the movie studios, they have nothing to do with the MPAA, Jack Valenti, etc.
For that matter, neither do most of the people in the movie industry (movie industry != MPAA && movie industry != studio execs), at least not directly, but that is another matter for another discussion.
(PS does not properly support 16-bit color, a neccessity in modern pipelines.)
I'm going to stamp out the idiots right now and say that Film Gimp does not support 16-bit per pixel color (aka high-color). Rather, it supports 16-bit per channel color, or 48-bits (64 with an alpha channel) per pixel.
It also supports 32-bit floating point per channel, for things like HDR (High Dynamic Range) imaging.
Actually, having commonly typed keys on opposite sides of the keyboard makes it easier to type quickly, since you don't have to type entire words with one hand. While the fingers on your left hand are moving into position, the fingers on your right hand can be typing, and then vice versa.
Even after them, some manufacturers tried to be different. I present for evidence the Commodore64, which used a modified version of that horrid UK layout.
Get an SGI keyboard, preferrably one of the granite ones with the "cube" logo. Though they're made by SGI, they're standard US 101-key PS/2 keyboards, and will work on anything that accepts US 101-key PS/2 keyboards, including PCs.
They have excellent tactile feedback, and are juuust clicky enough, but you don't have to bang on them.
And they don't have those annoying Windows keys.
AFAIK, they only come in the PS/2 variety (no USB).
I'd suggest not buying one directly from SGI, though. Try going to a place like Reputable Systems or Mashek, or maybe eBay.
buttons like page up and down and that block just need to go away
I disagree. I use page up/page down all the time, mostly when I want to scroll back through the console without having to take my hands off the keyboard.
Home and End find use occasionally, but I could live without Insert and Delete.
On US keyboards, the ` and the ~ are on the same key. Not that it's any better, just different.
The backslash is to the left of the Z? I don't know how I'd get by with out a large shift key right next to the Z key.
On US keyboards, there are generally two variations: ones that have a wide, flat enter and backspace key, with the \ stuck between them, and the ones that have a regular-sized backspace key, with the \ immediately to the left of it, with an enter key shaped like a reversed L.
In the world of non-linear video editing, such as on systems like Avid, the keyboard is your friend.
Editors who only use the mouse are much slower than editors who use both the keyboard and mouse at the same time (one hand on the keyboard, the other on the mouse).
If somebody made a device that you could connect to your computer that was similar to an off-line 3-point editing board, but with extra buttons that you could map to commonly-used Avid functions, that would kick so much ass. You'd still need to use the mouse, though (to select clips, bins, etc.).
And besides, the keyboard is still the best way to enter text. Especially if the text you're entering isn't a real word, like in programming.
which will first execute the command "gtk-config --cflags --libs" and then use its output on the command line for gcc.
It's much easier to just stick that into my program's makefile than typing out all the necessary compiler flags and libraries needed to compile a GTK+ program, and is more portable. On my system, I'd need to instead insert into the makefile:
It's pretty much required that you use gtk-config when compiling GTK+ programs, since not everybody on every OS is going to have all the libraries and whatnot in the same place, and gtk-config will give you output customized for your machine. If you didn't have the backtick key, you'd have to type it out, and lose a degree of portability.
Slashdot Mirror
Hell, the 32-bit MIPS R4400PC
Whoops! That should read: 32-bit MIPS R4400SC. MIPS processors with PC in the name don't even have secondary (L2) cache. I mean, the SC in R4400SC stands for secondary cache; you'd think that I would pay more attention. And seeing how hinv on that machine reports 1 megabyte of secondary cache, I don't see how I could have anything other than a SC processor.
Preview, preview, preview!
Ever since the 8086/8088 duo, the bus width of a CPU has been decoupled from its word size. For a long time, the external bus width of (non Rambus) 32-bit CPUs has been wider than 32 bits.
I realize this, and at no point did I say that 32-bit CPUs used data buses that were only 32 bits wide. But it only makes sense that the width of the data bus for a 64-bit CPU would be twice that of a 32-bit CPU, whatever that might be (128 bits, 256 bits, you get the point).
You could put a small cache in a 64-bit CPU.
I don't really see the point of that statement. While a huge amount of cache isn't a requirement for 64-bit CPUs per se, I've yet to see a 64-bit CPU that didn't have easily twice as much cache as a 32-bit x86 CPU.
Hell, the 32-bit MIPS R4400PC that powers the SGI Indy sitting next to me has 1 megabyte of L2 cache, and it was made back in something like 1995.
64 bits has little to do with it; you're mostly paying for cache and bandwidth when you buy high end CPUs.
When did I say otherwise? While that's certainly how the majority of the price breaks down, the large cache size isn't why you buy them.
Of course, Linus works in America, where McDonalds makes French fries, not chips.
Why they want to remove things that make programming easier is beyond me.
One of the things about a true RISC processor is that it has no microcode, no microengine, etc. The instructions run directly on the bare hardware.
This means that the instructions that would require a microengine to implement get taken out of the instruction set.
Additionally, RISC favors a more simplified instruction set design (using simple memory address modes instead of complex ones, can only load/store directly to or directly from registers, etc.) with LOTS of general purpose registers, which, as far as assembly programming goes, actually make things easier. In reality, most of the instructions that get left out would never have been used, so it's a waste to include them. The x86 instruction set, for example, is chock full of opcodes that nobody uses.
The only real disadvantage to RISC is the larger code size.
But ask anybody who has done assembly language programming on both x86 and a decent RISC architecture which of the two they prefer, and x86 will most always lose out.
64-bit code needs 8 bytes to hold every pointer. This will serve to eat up more cache and memory bandwidth, which are already major bottlenecks for any CPU.
The only thing this eats up is cache; because the system has a correspondingly wider data bus, there isn't a hit in memory bandwidth (unless the designers are trying to be cheap bastards and give a 64-bit CPU the same data bus width you'd use for a 32-bit CPU). And most 64-bit CPUs have a lot of cache.
And as for what kind of applications you potentially need several gigabytes worth of memory for, there's scientific processing and the like.
I'll second that. While I don't live in Alaska, I've visited it, and small airplanes are definately a necessity.
IIRC, Juneau, the capital city of Alaska, is inaccessible by road. The only way to get into the city is by boat or by air.
Exactly.
This is why I hate New Scientist. I think its very possible that they exist solely to keep the population misinformed.
DNA is not a complete blueprint on how to build a human being. This is why clones don't look exactly like what they are a clone of.
Besides, listening solely to geneticists on human behavior is like listening to somebody who's only designed CPUs talk about artificial intelligence; chances are, they aren't giving you the complete picture, most likely because they themselves don't have it. The human brain is self-organizing to a degree, and does much of this based on environmental influences. A clone of you would not have your memories, would not act like you, would not think like you, and would not even look exactly like you.
While I think that genetics can make us lean a little one way or the other when it comes to things like personality types, the development of a human being is such a complex process, you cannot simply attribute the way a person behaves solely to one thing.
And, of course, the whole "genetics determine personality and behavior" is just a convenient and legitimate-sounding way for some people to shirk personal responsibility. "No your honor, I didn't want to kill him, but the men in my family are genetically pre-disposed towards agressive, often murderous behavior! My dad killed my mom, so I can't be blamed for shooting that guy, because it was the murderer genes I inherited that made me do it!"
dos2unix is your friend
It's a wonder he and Steve Jobs don't get along better.
On the other hand, if they're both screaming at each other instead of their respective employees, that would explain it.
Actors playing live-action characters get coached by several people too. The director, their voice coach (if they're not doing their native accent), their acting coach, sometimes even the cinematographer.
Which is why our current obsession with actors and the thinking that what we see on screen is all them (ignoring the director, the screenwriter, the editor, the cinematographer, etc.) is just plain dumb.
That said, Gollum would have been very different withouth Andy Serkis. Read this article on VFXPro.com.
It says, and I quote:
How exactly would a hyperbaric chamber have anything to do with pedophelia?
Note to Slashdot Editors: please stop refering to Film Gimp as a tool used by movie studios. It isn't.
Rather, it is a tool used by VFX studios. While the VFX studios may work for the movie studios, they have nothing to do with the MPAA, Jack Valenti, etc.
For that matter, neither do most of the people in the movie industry (movie industry != MPAA && movie industry != studio execs), at least not directly, but that is another matter for another discussion.
(PS does not properly support 16-bit color, a neccessity in modern pipelines.)
I'm going to stamp out the idiots right now and say that Film Gimp does not support 16-bit per pixel color (aka high-color). Rather, it supports 16-bit per channel color, or 48-bits (64 with an alpha channel) per pixel.
It also supports 32-bit floating point per channel, for things like HDR (High Dynamic Range) imaging.
Buy an SGI keyboard from Reputable Systems or Mashek.
Nice US 101-key PS/2 keyboards with good tactile feedback, keys that are clickly but not too clicky, and no Windows keys.
Actually, having commonly typed keys on opposite sides of the keyboard makes it easier to type quickly, since you don't have to type entire words with one hand. While the fingers on your left hand are moving into position, the fingers on your right hand can be typing, and then vice versa.
Since I use my right hand to work the mouse, it is more comfortable to have my left hand on the WASD keys, which are on the left side of the keyboard.
Even after them, some manufacturers tried to be different. I present for evidence the Commodore64, which used a modified version of that horrid UK layout.
I hate to be the one to tell you this, but undo is not :w
;)
That could explain some of the problems you've been having
You can have my SGI granite keyboard (yep, the ones with the cube logo, not the lame new logo) when you pry it from my cold dead fingers.
I got a granite "cube" keyboard for $5. I wouldn't trade it for the world...
Well, ok, I might trade it for the world, but not much else...
Get an SGI keyboard, preferrably one of the granite ones with the "cube" logo. Though they're made by SGI, they're standard US 101-key PS/2 keyboards, and will work on anything that accepts US 101-key PS/2 keyboards, including PCs.
They have excellent tactile feedback, and are juuust clicky enough, but you don't have to bang on them.
And they don't have those annoying Windows keys.
AFAIK, they only come in the PS/2 variety (no USB).
I'd suggest not buying one directly from SGI, though. Try going to a place like Reputable Systems or Mashek, or maybe eBay.
buttons like page up and down and that block just need to go away
I disagree. I use page up/page down all the time, mostly when I want to scroll back through the console without having to take my hands off the keyboard.
Home and End find use occasionally, but I could live without Insert and Delete.
Ahh, I see you're from the UK.
On US keyboards, the ` and the ~ are on the same key. Not that it's any better, just different.
The backslash is to the left of the Z? I don't know how I'd get by with out a large shift key right next to the Z key.
On US keyboards, there are generally two variations: ones that have a wide, flat enter and backspace key, with the \ stuck between them, and the ones that have a regular-sized backspace key, with the \ immediately to the left of it, with an enter key shaped like a reversed L.
If you look in the video editing ... field
In the world of non-linear video editing, such as on systems like Avid, the keyboard is your friend.
Editors who only use the mouse are much slower than editors who use both the keyboard and mouse at the same time (one hand on the keyboard, the other on the mouse).
If somebody made a device that you could connect to your computer that was similar to an off-line 3-point editing board, but with extra buttons that you could map to commonly-used Avid functions, that would kick so much ass. You'd still need to use the mouse, though (to select clips, bins, etc.).
And besides, the keyboard is still the best way to enter text. Especially if the text you're entering isn't a real word, like in programming.
As far as the ` (backtick) key goes, its obvious he's not very proficient with *nix.
Whatever is between the backticks gets executed.
For example, to compile a GTK+ program, you'd do something likewhich will first execute the command "gtk-config --cflags --libs" and then use its output on the command line for gcc.
It's much easier to just stick that into my program's makefile than typing out all the necessary compiler flags and libraries needed to compile a GTK+ program, and is more portable. On my system, I'd need to instead insert into the makefile:It's pretty much required that you use gtk-config when compiling GTK+ programs, since not everybody on every OS is going to have all the libraries and whatnot in the same place, and gtk-config will give you output customized for your machine. If you didn't have the backtick key, you'd have to type it out, and lose a degree of portability.
I'll keep the backtick key, thank you very much.