The silence is one of the best features of electric and hybrid cars. Why is New York the city that never sleeps? Because it's so damn loud from all the cars.
On a separate note, modern IDEs, such as Eclipse, require the use of the mouse. I would argue that this streamlines the coding process, leaving the developer to focus on the actual design and logic.
Any tool that requires you to use it in a particular way is just plain broken. I should be able to dictate to the tool how I will use it, not the other way around.
Among other things, POWER is 64-bit and big-endian. Most current x86 is 32-bit, and all x86 is little-endian. If people don't write their file load / save code properly, the endian difference can be a major PAIN.:(
Right...can you give me a URL to any on-line dealer where I can buy a board? I searched on google for about 20 minutes and all I came up with was a beta program for ~$1,000.
In legal terms, the summary means jack. Look at the claims. That's what a judge will look at. Specifically, look at the independent cliams (i.e., the ones that DON'T say "The method of claim XYZ wherein blah blah blah").
Now, I've read most of the independet claims of that patent and I've written a JPEG compression codec, and I have a very, VERY hard time seeing how it would even apply. After 15 years of non-enforcement of a patent that doesn't even clearly apply, I wish them the best of luck.
Disclaimer: these are my opinions, not my employer's.
There is something that people commonly miss here. This is not like the problem that SSH tries to solve. SSH uses encryption to foil foreign proxies. This works because the foreign proxy will not have access to the keys/passwords. However, a "cheating" proxy will have access to ALL of the information (i.e., keys, passwords, etc.) that the application has.
How hard would it be to write a proxy that would snoop an SSH connection if you had access to all of the key/password data? I suspect that even the script kiddies could probably do it! Encryption is not "the" answer to the problem.
The Saturn was very difficult to program. It was a very strange environment that forced programmers to jump through many hoops and have lots of special case code to do such "simple" things as texture mapping.
The PSX had, by far, the best development system at the time. It shipped with libraries, a C compiler (unheard of at the time), and (I believe) some art tools.
The net effect of these two issues was that there were a lot more good games for the PSX first. Remember folks, it's ALL about the software.
The PSX came out waaaaay before the N64. Not only that, most people don't want to pay a premium price for their games on a ROM instead of a CD. I honestly think that was one of Nintendo's biggest mistakes ever.
AND they can cluster them together - real clusters not failover.
Actually, Sequent (recently bought by IBM) has been shipping systems for some years now, too. We also support real clustering, too (that is if you consider shared disks with multipath fibre channel I/O real clustering *grin* ). Not to sound like an ass, DG had never even given a thought to cc-NUMA until a Sequent VP left and went to work there.:/
If I recall correctly, your description matches what Sequent published on their web site. They seemed to be using ccNUMA with a fairly large MESI cache on their custom chips.
I'm not exactly sure which cc protocol is used, but this is basically correct. It seems like there might be an extra state, but I can't remember. The cache is 4MB.
Their hardware interconnect was a SCI (Scalable Coherent Interconnect) ring with a bandwidth of around 1 Gb/sec/link. This is not, IMHO, the best link to use today. In fairness to Sequent, SCI may have been the best thing available at the time. They started shipping in '96 or '97, so the R&D must have happened a few years earlier.
That hits the nail right on the head. Also, at the time the company was not seeing the best of times, so getting a working product out fast was pretty much the top priority. There are quite a few people that IBM primarily bought us for our next generation interconnect, but that starts to wander into NDA territory.:)
I also thought the multi-path I/O was pretty cool. It is a FibreChannel SAN (Storage Area Network) with multiple controllers, F-C switches, and EMC RAID boxes, with fail-overs that work a little like the Internet, rerouting around dead hardware.
Hehe...throw Clusters, CFS (Clustered File System) and SVM (System Volume Manager) into this mix and you can basically get more I/O bandwidth than any other system available. Not to sound too much like a marketing lackey, being able to connect *4* 64 proc boxes to just about as much disk space as you can get (there is a limit, but I don't know what it is) and have them all access in a nice, friendly, coherent manner just kicks ass.
uhhhm... you're talking about two different things. i said 'porting linux to a numa-q.' numa-q is a brand name of a type of (x86) server. so, there's really no porting of linux to be done.
But... just because it is x86 doesn't mean there is no coding to be done!
Very, very true. We (Sequent/IBM) have had Linux up on single quads in our labs for over a year. That part required 0 work because a single quad can be configured to look, basically, like a 4-way PC. However, as soon as you add another quad to the system, extra code needs to be added to boot strap the additional quads. It goes even beyond this because each quad can have different CPUs. One of our main production machines has 16 PPro 180s, 4 PII 450s, 8 PIII 495s, and 4 PIII 700s. Clearly the Linux assumption that all CPUs will be the same fails miserably here.
To be quite frank about it, everything about NUMA is hard. Getting the hardware to work is hard. Getting the OS to work is hard. If it weren't so damn hard, don't you think that more than 3 companies (Sequent/IBM, SGI, and Data General) would have NUMA systems?
you said 'coding an OS for numa,
You're correct, I meant "coding numa for an OS".
Well, NUMA (or cc-NUMA more specifially) is a function of the *hardware*, and the software has to support it. You wouldn't say "coding SMP for an OS" would you? Coding an OS for NUMA is correct.
Slashdot Mirror
The silence is one of the best features of electric and hybrid cars. Why is New York the city that never sleeps? Because it's so damn loud from all the cars.
On a separate note, modern IDEs, such as Eclipse, require the use of the mouse. I would argue that this streamlines the coding process, leaving the developer to focus on the actual design and logic.
Any tool that requires you to use it in a particular way is just plain broken. I should be able to dictate to the tool how I will use it, not the other way around.
Is it just me, or does spending $1,245 on a server to save $10 on your power bill seem insane?
Among other things, POWER is 64-bit and big-endian. Most current x86 is 32-bit, and all x86 is little-endian. If people don't write their file load / save code properly, the endian difference can be a major PAIN. :(
Right...can you give me a URL to any on-line dealer where I can buy a board? I searched on google for about 20 minutes and all I came up with was a beta program for ~$1,000.
In legal terms, the summary means jack. Look at the claims. That's what a judge will look at. Specifically, look at the independent cliams (i.e., the ones that DON'T say "The method of claim XYZ wherein blah blah blah").
Now, I've read most of the independet claims of that patent and I've written a JPEG compression codec, and I have a very, VERY hard time seeing how it would even apply. After 15 years of non-enforcement of a patent that doesn't even clearly apply, I wish them the best of luck.
Disclaimer: these are my opinions, not my employer's.
How hard would it be to write a proxy that would snoop an SSH connection if you had access to all of the key/password data? I suspect that even the script kiddies could probably do it! Encryption is not "the" answer to the problem.
The real question is, when will the first silicon ship that supports VQ and something like S3TC or FXT1 (or whatever it is)?
The net effect of these two issues was that there were a lot more good games for the PSX first. Remember folks, it's ALL about the software.
To be quite frank about it, everything about NUMA is hard. Getting the hardware to work is hard. Getting the OS to work is hard. If it weren't so damn hard, don't you think that more than 3 companies (Sequent/IBM, SGI, and Data General) would have NUMA systems?
Well, NUMA (or cc-NUMA more specifially) is a function of the *hardware*, and the software has to support it. You wouldn't say "coding SMP for an OS" would you? Coding an OS for NUMA is correct.