The Cray 3 did *not* sink Cray Research. The Cray 3 sunk Cray Supercomputer, which was a different company. Cray Research built an aweful lot of machines after the Cray Supercomputer spinoff. As to what, exactly, sunk Cray to the point of the SGI merger, that is a hard question. Some technical issues coupled with lower defense spending and bad management.
The merger with Cray is *NOT* what broke SGI's back. SGI loved to heap that on the former Cray employees, but that's not the case. Incompetant management, impossible business plans, and lack of a vision on what to do with Cray after the purchase is what has sunk SGI.
Another thing that has sunk SGI, other than incompetant upper management under the Beluzzo administration, is what you bring up in the next paragraph - the number of things that you can do *only* on an SGI is shrinking. SGI failed to recognize this.
As for 10-gig-E and MOSIX: a) 10gig-E doesn't really exist yet in a commodity box b) Even when it does, no commodity PC is going to be able to drive it at full speed c) MOSIX is not yet where Irix is in terms of large scale SSI's and d) in the time it takes for all the first three things to get fixed, SGI is going to have something better (or they'll be out of business).
As for your last paragraph, NO commodity PC presently available has the I/O bandwidth to drive even *ONE* 10-gig-E card at full speed, let alone 4. Also, 10-gig-E cards aren't cheap. Sorry, but you're going to be spending $5500/node even for a PC. Will we be there in 5 years? Yeah, probably, but in 5 years, SGI and Cray will be making even bigger systems.
Oh yeah, one last thing - an x86 can't address as much RAM as this thing can because it's a 32 bit and not 64 bit processor.
See my post above. Crays in the past were cooled by 3 things, none of them water: Freon, Flourinert, and air. Circulating large amounts of water through a system that uses as much power as ours do is, well, a bit on the risky side:)
Crays have never been cooled by liquid nitrogen or any other super-cold liquid. The explanation for this that was given to me is that the super-cooling causes too great a temperature change to keep the parts reliable as they have to be warmed up every time they are turned on.
The Cray 1 and Cray X-MP were cooled by a freon-cooled cold plate. The Y-MP, C90, T3D, and T3E have a chilled liquid called Flourinert (some derivative of an artificial blood plasma, I believe, which is made by 3M) cirulating through a cold plate between boards. The Cray 2 and Cray T90 were cooled by being immersed in a vat of Flourinert. The Y-MP/EL, J90, and SV1 are all air cooled. The X1 (aka SV2) is cooled by spraying Flourinert onto the chips.
I believe, though I'm not 100% certain, that this system will be air cooled, presumably by lots of big fans:)
Err, I don't wanna burst your bubble, but even under Unix, a bad driver can ruin your day. As another poster above mentioned, drivers have full access to everything. This means they get to crash your system. This is true under Solaris, Net/Free/OpenBSD, Linux, Irix, Windows, MacOS 9, MacOS X, ProDOS, and just about anything else you can think of. While it would be theoretically possible to isolate off driver access, in reality it becomes rather difficult. Irix has an interface to do drivers entirely in userspace, but even then, there is a possibility that they can screw stuff up since they are directly manipulating hardware.
Hey, I didn't say *I* would do that:) (Of course all of my code is in C or assembler anyway...) The problem is more that you aren't always dealing with packages that you've written. I've had to merge some source code together and had files with both.c and.C and.h and.H.
As for getting the two confused, if you're used to the convention it makes perfect sense. If you aren't, it's a PITA. This is true of many things in Unix:)
Well, you don't *need* it, but convention is that files ending in.c are C files and files ending in.C are C++ files. Conceivably, you might want random.c and random.C in the same directory.... I'm sure there are plenty of other such examples. The biggest reason is that if you plan to use a MOSX box as a Unix box, it would be nice if it worked in a way similar to every other Unix machine you are using. I use Irix, Linux, Solaris, NetBSD, and MacOS X. OSX is the only one of those that's not case sensitive. That can occasionally make life interesting.
In general, no. I think what you are after is something called auditing, not journaling. The only goal of journaling is to maintain consistancy of the filesystem, not to keep a log of what has happened on the machine for security reasons. The way most journaled filesystems work, after the transaction has been completely written to disk, the journal entry is erased and reused. This won't help you. However, an audit log will. Any system intended as a "trusted" system (SGI has "Trusted Irix" and I think there's a trusted Solaris as well) will do such logging. It will also do a number of other things which you may or may not like to increase your security. I don't know of any open-source auditing packages out there, but one probably exists somewhere.
Actually, I'd guess that the memory bus is the bottleneck of modern PC's, but regardless of whether or not I'm right there, journaled filesystems tend to slow down writes more than reads (since reads don't require as many, if any, journal entries). So as far as performance goes, it probably won't slow down the performance of just reads (ie, applications loading) by 10%. The majority of the time, you are doing reads and not writes to the disk.
Re:Message Passing vs. Single System Image
on
Ask Donald Becker
·
· Score: 3, Informative
These two ideas aren't mutually exclusive. The Cray T3E is a single system image machine, but applications running on it are almost exclusively message passing in nature. My opinion on why there aren't proliferations of SSI clusters is because they are a lot harder to build. If you go with a set of seperate machines, which means you don't have a single *memory* image, getting the various kernels involved to all talk to each other is non-trivial. If you go with a single memory image, then you're not really doing a cluster, you are building a real supercomputer. Examples of single memory image machines of large size include the Sun Enterprise 1x000 line, the SGI Origin 2000/3000 series, the Cray T3E, and the not-quite-in-full-production-yet Cray X1.
As for the 32 bit address limit, it's already a problem. For large scientific code, 4GB per processor is already not enough. Now, people live with it, but that doesn't mean they like it. Intel's 36-bit addressing hack doesn't help, either, since you still have a single-virtual-address space limitation of 32 bits. This is probably the biggest motivation to go to a 64 bit architecture. Note that this problem also applies to large databases.
PIC is different from Superscalar and Vector for a variety of reasons. First, most PIC implementations require the user to pick out which instructions can run in parallel (at least the IA64 implementation does). Superscalar processors have a large amount of logic in them to allow the processor to prove to itself that certain instructions can run out of order or in parallel. Also, most current superscalar processors are single issue (ie, only one instruction can start executing per clock). PIC processors are typically multi-issue processors.
As for the differences with vector processors, these are even greater. A vector processor is something called SIMD (single isntruction, multiple data). So, you can, for example, do a pare-wise addition of two arrays all in parallel. However, you couldn't add two numbers together while simultaneously subtracting two other numbers from each other unless the processor had an intruction to do that. Ie, you only get to issue one type of instruction, not multiple arbitrary instructions.
It is theoretically possible to mix-and-match these approaches. I don't know a whole lot about PIC processors, but Cray processors employ a mix of superscalar (for scalar instructions) and vector. PowerPC with Altivec also employs some vector instructions to a mostly superscalar procesor.
Re:Why is SGI not switching to FreeBSD ?
on
A Look at IRIX 6.5.17
·
· Score: 4, Informative
How on earth did this comment get moderated "insightful"?!?! I'm not really sure where to start here:
crash-resistant, high-performance file system. Ever heard of "XFS"??? It's journaled and has been around almost longer than the FreeBSD project.
First multithreaded kernel: Um.... Right... Multithreaded kernels have been around for probably a decade if not more. FreeBSD is hardly the first. Irix has had kernel threads for ages. The first reference I can find to them is in '95 (and I suspect they have been around longer than that) when FreeBSD didn't even run on multiprocessor systems.
First "compact" kernel: What is a "compact" kernel? The FreeBSD kernel is a monolithic BSD kernel. Irix is a monolithic System V kernel. Even Linux is a monolithic kernel (of Linus + other's design). Microkernels haven't lived up to their initial hype (though MacOS X uses one), but neither they nor monolithic kernels are "obsolete".
Now don't get me wrong, FreeBSD is a great OS. I have run it in the past and regularly use it. But it doesn't run on 1024 processors, have multiple tens of terabytes of storage in a single filesystem, and manage a terabyte of RAM. It's not designed for that. Irix is.
Uh, SGI sells more than multimedia workstations. They sell 1024 processor supercomputers too and memory bandwidth *IS* the world in high performance computing. That's why supercomputers like high end SGI's and Cray's can still beat the crap out of a cluster on a number of applications. That said, Irix is also quite good at scaling up to large processor counts. If you can find me another example of a single kernel OS that scales to 1024 processors, I'd be quite shocked. The only SSI OS on that scale that I can think of is Unicos/mk (the Cray T3E operating system).
I do, however, agree that benchmarks are often quite useless. The way it any machine performs is highly dependant on what mix of jobs/applications you plan to run on it.
Problem not solved. Some of these companies want to use IM to comunicate with their *customers*. Now, they could, I suppose, mandate that the customer use a given client, but that isn't necessarily going to go over too big with the customer, especially if the customer is either a) religiously attached to their present platform/opposed to the company's platform of choice or b) not all that good at computers and or short on time and doesn't want to learn a new program.
One would also think (although I'll bet there isn't actually a regulation about this) that a financial firm requiring its customers to use proprietary technology from a company on which they are also doing financial analysis would be a bit of a conflict of interest. Not that *that* would ever happen on Wall Street....
Well, as you well know since you worked for SGI, SGI's plans change rapidly:) By the time I got to the project in '99, there were no plans for the SN1 architecture to support McKinley - that's SN2. Alas, SN1-IA64 is dead. It was killed in spring of '01 (which is a part of why I am no longer working for SGI...).
Anyhow, I have definetly looked inside more C-bricks than I can count when I worked on the SN1 (both MIPS and IA64) partitioning software.
Err, as I point out in a post below, this is not an Origin 3000 series machine, but you're right, it will be partitionable.
Also, a hint on partitioning - ditch mkpart. Use partmgr. mkpart was one of the biggest pains in my rear when I worked on the O3000 partitioning code.... Also, nice to see someone running code I've worked on:)
So it was more like "we got a moron for a CEO who was totally in love with Bill Gates". He got SGI to commit to running Windows, even on big systems (in fact, the internal hardware manuals for a large system I worked with there actually mentioned booting "an OS such as Irix or Windows", even though that plan had long since been dropped). This caused SGI to lose a large number of top-notch developers who didn't really want anything to do with Windows. The same moron CEO, "Rocket Rick" Belluzo (who recently got the axe at Microsoft), and his yes-men made a number of other dumb descisions that nearly killed the company. Finally, he quit (before he could be tarred, featered, and run out of town on a rail) in August of '99 and was replaced by competant management (the present CEO, Bob Bishop, who brought in a bunch of other people who are a lot better than Rocket Rick's crowd).
In any case, the large systems capable of running Windows didn't appear until after he left and by the time they did, the descision had been made to unload Windows and go with a useful OS (Linux). This is what triggered SGI to get involved heavily in Linux development. Irix was another OS that was considered for the Itanium platform, but there were a variety of reasons why that wasn't picked.
So, that's the short story on why SGI is presently making this system with Linux and why some people have mentioned Windows on large SGI's.
The poster on this is wrong. An Origin 3800 has MIPS processors and runs Irix (although there was a "toy" Linux port to Origin 2000 machines that would be fairly easy to adapt to the 3000 series). This is "the upcoming Itanium 2 system from SGI" that the press release mentions (what the marketing department at SGI will ultimately come up with for a name, I have no clue). While they are similar systems (both use ccNUMA and similar in other ways that I can't go into here), they use different memory control ASICs.
In any case, the poster made it sound like you can just plug Itanium 2's into an Origin 3000 and *bang* you've got a Linux system which is not correct.
Oh, NASA has realized this. They just aren't given any budget for it by Congress. Now you can argue the merits of whether or not they should be given such a budget or whether they could actually accomplish such a feat (I tend to think they could if Congress actually committed to it and didn't flip-flop and force them to rejustify the project every year), but they certainly would *like* to put a human on Mars.
Chip companies doing this aren't necessarily "purposefully limiting features". In all likelyhood, the Celeron is really a P2 that failed diagnostics on half the cache. So, basically, the chip is bad so you have a choice as Intel - toss it in the trash or disable the area of the cache that is bad and sell it for less money. The lower clock rate chips are chips that, for whatever reason, didn't check out right at the higher clock rates. When we get prototype chips back for our stuff, we often find that they all run at fine at slightly different clock rates . Let's say we were shooting for a chip that runs at 100MHz (obviously, we are running faster than that in real life) - some of the chips may run fine at 110MHz while others may not work above 90MHz.
The point is, Intel probably is selling "failed" chips as Celerons or slower chips. I believe the 486SX was a 486DX where the floating point pipe failed diags.
Some people enjoy the challenge. Other people actually need to use their computers to get something done.
I am usually in the "enjoy the challenge" category, but when I'm at work (I'm a developer), I want my desktop box to "just work" 'cause I have enough challenges in debugging the operating system I'm working on without having to debug the one running my development environment.
Linux "just works" if it "just likes" your hardware. Sure, you learn a lot by poking through the config files to figure out what tweak you need to make it run with your configuration. However, I'd wager that the majority of people out there don't have the slightest interest in learning that. Those people are Apple's target market.
This isn't entrapment because they are being charged with hacking *other* systems (at least that's what the article implied). They aren't being charged for the demonstration they did for the FBI. The FBI just used the demonstration to gather information they needed to prosecute them for the other offense. As to whether the FBI violated other laws (US or Russian) I'm in over my head but I suspect that they didn't violate US law. I believe there are circumstances where you don't need a search warant (reasonably suspicion? Any lawyers around to comment?) to conduct a search. If that's true, that probably would apply here - the people were wanted for hacking, it is reasonable to assume that they had evidence of this on their personal computers.
That's odd. I walked into the Apple Store in the Mall of America and said "Hi, I need the 10.1 upgrade" and got handed the package and was in and out of the store (without paying, I might add) within 5 minutes. It would have been shorter but I had to stop and drool over the large flat panel display...
I realize that this is a troll, but I'll reply anyway. The technologies that are invented for super-computing class systems have a way of making their way over time into a machine that you *will* put under your desk. Both MMX and more Altivec (a beefier version of MMX that is in certain PowerPC processors including the ones in I think all current Macs) are based on vector processing technology and ideas originally designed by Seymore Cray in the 70's for the Cray I. So the answer is, everyone cares, even if nobody knows exactly why. I won't pretend that I know exactly what technology from current Crays will end up in desktop systems in 10 years, but *something* probably will. The same can be said for the technology that is in current SGI and IBM (etc) supercomputers.
For another example, clustering technology (which I'm sure is going to get posted about in this thread) was an attempt to duplicate and borrows ideas from the massively parallel machines like the Cray T3E, the SGI Origin, and the old Thinking Machines boxes.
There is *plenty* of hypothesizing in real computer science. IT is not computer science and if you're in a program that only teaches IT, you're not in a good CS program. Here are some examples. THe entire field of computer algorithms is very closely related to higher mathematics. Theories on how to search and sort, how to navigate through graphs of information, etc. can all be proved using various forms of advanced algrebra such as ring and group theory.
In operating systems, deadlock avoidance algorithms, scheduling theory, etc. are all hot topics.
Something that gets a lot of airplay here on Slashdot is cryptography which is, once again, related to math or flat out *is* math. RSA relies on the inability to factor the product of two large primes easily.
In high performance computing and even Internet design, there's analysis of traffic flow through a system and how to design for redundancy.
Now you can learn this stuff as just a set of rules, but you won't really invent anything new that way. Just as you could learn something about chemistry like "I mix these two chemicals together and they go *boom*". But just as you wouldn't call the latter statement "learning chemistry", you wouldn't call memorizing the details of how to configure a Cisco router computer science.
Well, while it is blatently obvious to you and I that hobbyist programming is not labor, it may not be so obvious to a judge when presented as "Apple is now shipping a product on which they are trying to make a profit that includes code that was written for Apple by a 15 year old". I can definetly see someone interpreting that as "labor". Also, I believe that Apple could still get in trouble even if both the kid and his parents agreed that it was not labor.
The building model planes part doesn't apply unless you plan on selling them for profit after they are built and don't conform to the laws on number of hours worked at certain times, etc.
Slashdot Mirror
The Cray 3 did *not* sink Cray Research. The Cray 3 sunk Cray Supercomputer, which was a different company. Cray Research built an aweful lot of machines after the Cray Supercomputer spinoff. As to what, exactly, sunk Cray to the point of the SGI merger, that is a hard question. Some technical issues coupled with lower defense spending and bad management.
The merger with Cray is *NOT* what broke SGI's back. SGI loved to heap that on the former Cray employees, but that's not the case. Incompetant management, impossible business plans, and lack of a vision on what to do with Cray after the purchase is what has sunk SGI.
Another thing that has sunk SGI, other than incompetant upper management under the Beluzzo administration, is what you bring up in the next paragraph - the number of things that you can do *only* on an SGI is shrinking. SGI failed to recognize this.
As for 10-gig-E and MOSIX: a) 10gig-E doesn't really exist yet in a commodity box b) Even when it does, no commodity PC is going to be able to drive it at full speed c) MOSIX is not yet where Irix is in terms of large scale SSI's and d) in the time it takes for all the first three things to get fixed, SGI is going to have something better (or they'll be out of business).
As for your last paragraph, NO commodity PC presently available has the I/O bandwidth to drive even *ONE* 10-gig-E card at full speed, let alone 4. Also, 10-gig-E cards aren't cheap. Sorry, but you're going to be spending $5500/node even for a PC. Will we be there in 5 years? Yeah, probably, but in 5 years, SGI and Cray will be making even bigger systems.
Oh yeah, one last thing - an x86 can't address as much RAM as this thing can because it's a 32 bit and not 64 bit processor.
See my post above. Crays in the past were cooled by 3 things, none of them water: Freon, Flourinert, and air. Circulating large amounts of water through a system that uses as much power as ours do is, well, a bit on the risky side :)
The Cray 1 and Cray X-MP were cooled by a freon-cooled cold plate. The Y-MP, C90, T3D, and T3E have a chilled liquid called Flourinert (some derivative of an artificial blood plasma, I believe, which is made by 3M) cirulating through a cold plate between boards. The Cray 2 and Cray T90 were cooled by being immersed in a vat of Flourinert. The Y-MP/EL, J90, and SV1 are all air cooled. The X1 (aka SV2) is cooled by spraying Flourinert onto the chips.
I believe, though I'm not 100% certain, that this system will be air cooled, presumably by lots of big fans
Err, I don't wanna burst your bubble, but even under Unix, a bad driver can ruin your day. As another poster above mentioned, drivers have full access to everything. This means they get to crash your system. This is true under Solaris, Net/Free/OpenBSD, Linux, Irix, Windows, MacOS 9, MacOS X, ProDOS, and just about anything else you can think of. While it would be theoretically possible to isolate off driver access, in reality it becomes rather difficult. Irix has an interface to do drivers entirely in userspace, but even then, there is a possibility that they can screw stuff up since they are directly manipulating hardware.
As for getting the two confused, if you're used to the convention it makes perfect sense. If you aren't, it's a PITA. This is true of many things in Unix
Well, you don't *need* it, but convention is that files ending in .c are C files and files ending in .C are C++ files. Conceivably, you might want random.c and random.C in the same directory.... I'm sure there are plenty of other such examples. The biggest reason is that if you plan to use a MOSX box as a Unix box, it would be nice if it worked in a way similar to every other Unix machine you are using. I use Irix, Linux, Solaris, NetBSD, and MacOS X. OSX is the only one of those that's not case sensitive. That can occasionally make life interesting.
In general, no. I think what you are after is something called auditing, not journaling. The only goal of journaling is to maintain consistancy of the filesystem, not to keep a log of what has happened on the machine for security reasons. The way most journaled filesystems work, after the transaction has been completely written to disk, the journal entry is erased and reused. This won't help you. However, an audit log will. Any system intended as a "trusted" system (SGI has "Trusted Irix" and I think there's a trusted Solaris as well) will do such logging. It will also do a number of other things which you may or may not like to increase your security. I don't know of any open-source auditing packages out there, but one probably exists somewhere.
Actually, I'd guess that the memory bus is the bottleneck of modern PC's, but regardless of whether or not I'm right there, journaled filesystems tend to slow down writes more than reads (since reads don't require as many, if any, journal entries). So as far as performance goes, it probably won't slow down the performance of just reads (ie, applications loading) by 10%. The majority of the time, you are doing reads and not writes to the disk.
As for the 32 bit address limit, it's already a problem. For large scientific code, 4GB per processor is already not enough. Now, people live with it, but that doesn't mean they like it. Intel's 36-bit addressing hack doesn't help, either, since you still have a single-virtual-address space limitation of 32 bits. This is probably the biggest motivation to go to a 64 bit architecture. Note that this problem also applies to large databases.
As for the differences with vector processors, these are even greater. A vector processor is something called SIMD (single isntruction, multiple data). So, you can, for example, do a pare-wise addition of two arrays all in parallel. However, you couldn't add two numbers together while simultaneously subtracting two other numbers from each other unless the processor had an intruction to do that. Ie, you only get to issue one type of instruction, not multiple arbitrary instructions.
It is theoretically possible to mix-and-match these approaches. I don't know a whole lot about PIC processors, but Cray processors employ a mix of superscalar (for scalar instructions) and vector. PowerPC with Altivec also employs some vector instructions to a mostly superscalar procesor.
crash-resistant, high-performance file system. Ever heard of "XFS"??? It's journaled and has been around almost longer than the FreeBSD project.
First multithreaded kernel: Um.... Right... Multithreaded kernels have been around for probably a decade if not more. FreeBSD is hardly the first. Irix has had kernel threads for ages. The first reference I can find to them is in '95 (and I suspect they have been around longer than that) when FreeBSD didn't even run on multiprocessor systems.
First "compact" kernel: What is a "compact" kernel? The FreeBSD kernel is a monolithic BSD kernel. Irix is a monolithic System V kernel. Even Linux is a monolithic kernel (of Linus + other's design). Microkernels haven't lived up to their initial hype (though MacOS X uses one), but neither they nor monolithic kernels are "obsolete".
Now don't get me wrong, FreeBSD is a great OS. I have run it in the past and regularly use it. But it doesn't run on 1024 processors, have multiple tens of terabytes of storage in a single filesystem, and manage a terabyte of RAM. It's not designed for that. Irix is.
I do, however, agree that benchmarks are often quite useless. The way it any machine performs is highly dependant on what mix of jobs/applications you plan to run on it.
One would also think (although I'll bet there isn't actually a regulation about this) that a financial firm requiring its customers to use proprietary technology from a company on which they are also doing financial analysis would be a bit of a conflict of interest. Not that *that* would ever happen on Wall Street....
Anyhow, I have definetly looked inside more C-bricks than I can count when I worked on the SN1 (both MIPS and IA64) partitioning software.
Also, a hint on partitioning - ditch mkpart. Use partmgr. mkpart was one of the biggest pains in my rear when I worked on the O3000 partitioning code.... Also, nice to see someone running code I've worked on
In any case, the large systems capable of running Windows didn't appear until after he left and by the time they did, the descision had been made to unload Windows and go with a useful OS (Linux). This is what triggered SGI to get involved heavily in Linux development. Irix was another OS that was considered for the Itanium platform, but there were a variety of reasons why that wasn't picked.
So, that's the short story on why SGI is presently making this system with Linux and why some people have mentioned Windows on large SGI's.
In any case, the poster made it sound like you can just plug Itanium 2's into an Origin 3000 and *bang* you've got a Linux system which is not correct.
Oh, NASA has realized this. They just aren't given any budget for it by Congress. Now you can argue the merits of whether or not they should be given such a budget or whether they could actually accomplish such a feat (I tend to think they could if Congress actually committed to it and didn't flip-flop and force them to rejustify the project every year), but they certainly would *like* to put a human on Mars.
The point is, Intel probably is selling "failed" chips as Celerons or slower chips. I believe the 486SX was a 486DX where the floating point pipe failed diags.
I am usually in the "enjoy the challenge" category, but when I'm at work (I'm a developer), I want my desktop box to "just work" 'cause I have enough challenges in debugging the operating system I'm working on without having to debug the one running my development environment.
Linux "just works" if it "just likes" your hardware. Sure, you learn a lot by poking through the config files to figure out what tweak you need to make it run with your configuration. However, I'd wager that the majority of people out there don't have the slightest interest in learning that. Those people are Apple's target market.
This isn't entrapment because they are being charged with hacking *other* systems (at least that's what the article implied). They aren't being charged for the demonstration they did for the FBI. The FBI just used the demonstration to gather information they needed to prosecute them for the other offense. As to whether the FBI violated other laws (US or Russian) I'm in over my head but I suspect that they didn't violate US law. I believe there are circumstances where you don't need a search warant (reasonably suspicion? Any lawyers around to comment?) to conduct a search. If that's true, that probably would apply here - the people were wanted for hacking, it is reasonable to assume that they had evidence of this on their personal computers.
That's odd. I walked into the Apple Store in the Mall of America and said "Hi, I need the 10.1 upgrade" and got handed the package and was in and out of the store (without paying, I might add) within 5 minutes. It would have been shorter but I had to stop and drool over the large flat panel display...
For another example, clustering technology (which I'm sure is going to get posted about in this thread) was an attempt to duplicate and borrows ideas from the massively parallel machines like the Cray T3E, the SGI Origin, and the old Thinking Machines boxes.
In operating systems, deadlock avoidance algorithms, scheduling theory, etc. are all hot topics.
Something that gets a lot of airplay here on Slashdot is cryptography which is, once again, related to math or flat out *is* math. RSA relies on the inability to factor the product of two large primes easily.
In high performance computing and even Internet design, there's analysis of traffic flow through a system and how to design for redundancy.
Now you can learn this stuff as just a set of rules, but you won't really invent anything new that way. Just as you could learn something about chemistry like "I mix these two chemicals together and they go *boom*". But just as you wouldn't call the latter statement "learning chemistry", you wouldn't call memorizing the details of how to configure a Cisco router computer science.
The building model planes part doesn't apply unless you plan on selling them for profit after they are built and don't conform to the laws on number of hours worked at certain times, etc.