If it's graphics you're into, most of the algorithm stuff (other than some 3D games rendering) is very much in the public domain. Get one of the many excellent books and implement the algorithms therein, you'll learn a lot more.
Foley & Van Dam's "The Art of Computer Graphics" is still widely regarded as a definitive text.
OK, so you know and I know that PC-Week got hoisted by its own petard, but the marketing spin received by the PHB's is "Linux was cracked, NT is secure". Or indeed the not so PHB's - on the strength of this and otehr similar articles I was told by the highly experienced CTO of a local internet startup that "Linux is less secure than NT is less secure than Unix".
The same startup is running their web site in three tier mode, with NT4 web and app servers, and a Solaris/Oracle back end database. All configured for 100% hot failover to guarantee uptime.
I think Microsoft invented it, but IIRC it's now in the standard RFC. I think the "pump" DHCP client for *ix seems to pull down this info and build an/etc/resolv.conf from it - I know "rrdhcpcd" does. Also, the stock IANA version of dhcp seems to serve DNS info to clients which will listen; I have this on my IP Masq server and Windoze clients have no trouble automagically divining DNS setups.
In a dialup / laptop situation, it's worthwhile improvement IMHO. Not EVERYTHING from Redmond sucks.
For those who take a passing interest in the history of computing, or who find people like Richard Stallman entertaining, the story of Seymour Cray the man is quite interesting. His methods of designing hardware (consulting the elves) were definitely unique.
I don't think we'll see anyone quite like that again.
It was always said in the supercomputing community that the US government would never let Cray die. Buying in supercomputers from Japan, the only other source of big iron, just wouldn't wash with the likes of the NSA.
First it was blocking the NCAR deal, and now this.
Actually, I think the vector pipes on a Y/MP are something like 8 or 10 units deep.
These computers are designed for one type of calculation - matrix algebra, which requires simple processing (multiply, add, invert) on enormous 2D arrays of numbers. The important point: the working set of these problems is often the size of the matrices, so caches are ineffective. Cray vector machines do not have ANY data cache between the vector units and main memory.
The feature of most vector machines that no-one has really pointed out yet is the way the memory system keeps those vector units fed. Unlike a microporcessor which relies on 2 or more layers of cache, the vector machine is quite capable of streaming data from memory fast enough to keep the processor 100% busy.
The vector instruction results in a number of vector fetches being issued to the memory controller, which is told to fetch a strided vector from memory (start at address x, every ith word, n words in total). The memory controller issues requests to individual banks in an overlapping fashion. Like the vector FPU, after it gets over its latency it starts banging the words out once per clock cycle.
The way this is done is to have a huge interleave in the memory - Cray T90's use either 1024 or 2048 banks. So long as any one bank is not hit more than one per 100ns or so (the cycle time of the memory) the memory controller is capable of delivering multiple streams of 64 bit words at full clock speed (T90's can have up to 32 CPU's). Typically, to ensure this, arrays in programs are structured to stride along the first dimension (FORTRAN remember) or where this isn't possible, the array dimensions are chosen to be prime numbers.
The thing that sets these machines apart is not processor speed - the peak speed in MFlops on an NEC SX-5 is only about 2-3 times that of an Alpha AXP. The thing that makes them special is the memory bandwidth to sustain that performance.
To use my favourite automotive analogy, if a PC is a small hatchback, then a supercomputer is an 18-wheeler, not a Ferrari.
Linux advocates - please refrain from posting things which are utter nonsense. You just make the rest of us look bad.
The original Cray 1 and 1/S were like this, being parasitic on an IBM or VAX host. Modern supercomputers (Cray, Fujitsu, NEC,...) all run a Unix OS natively. Cray's Unicos is in version *10*
Similarly, the first Cray parallel machine, the T3D, parasited - off the back of a Cray vector machine, J90 or C90. The T3E however devotes some of its 21264's to being I/O processors.
Actually, I think you've got the wrong war - there was no overt US involvement in the Falklands due to the Americas Treaty.
However, the US Navy airbase at Kindley Field, Bermuda (British soil on loan) did give a few Harrier pilots a helping hand and a bit of fuel on their way from Farnborough to Ascencion.
This is surely a huge waste of time - unless they find some way of forcing it on a significant proportion of the user community (examples: a deal with AOL, a built-in feature in IE) then it is doomed to failure. It's also somewhat unscaleable in its present form.
Basically, for Joe Public, the web is the Internet, and he knows that all website URL's start with www. and end in.com and that is the driving force. Don't expect to see any volumes of eCommerce websites with.shop any time soon.
Merced will succeed if and only if it gets real backing from Microsoft as the "main" platform for Win2K, and the software comes out for it. Distasteful as it may be in this community, this is the reality, and all else is secondary. Without this level of support from Microsoft, IA-64 is just an also-ran to Alpha; indeed, if the performance of initial Merced releases is not up to scratch it may require that Microsoft actively backs away from Alpha to help Merced succeed.
It's interesting to note that HP is carefully hedging its own bets - all of its new HP-UX server line (Dome series) originally slated for Merced have been (re-)architected to take both PA-RISC and IA64 processors, and the extended delays in Merced have caused them to plan one and then two additional revs of the 64-bit PA-RISC architecture (PA-8700 and now PA-8900) which has always been slated for termination once IA-64 is fully available.
The good news for IA-64 is that McKinley development is rumoured to be catching up with Merced and it should be ready to ship more or less immediately afterwards. I wouldn't be surprised to see McKinley shipping simultaneously as the high end version, c.f. Xeon's and P3's in the x86 world.
Seems like a sensible business decision on Compaq's part to me.
- They have their own 64-bit architecture that is well established - When you're offering a proprietary OS it makes sense to keep down the number of platforms you support
The more interesting decisions for them are:
1. Should they continue to push NT on Alpha? 2. Should they sell and support NT on IA64?
To a large extent these depend on which way Microsoft and the PC software industry jumps - you don't buy software to fit the hardware, you do it the other way. If Microsoft pushes IA64 as the main platform, then that will force Compaq's hand as far as NT goes. However, the widespread use of NT on non-x86 platforms which was touted when NT was new has failed to materialise, with the excpetion of a small Alpha following, and I think x86 will be with us for a while yet.
What I'd be interested to know is how the memory bus and cache coherency work on multi-cpu IA64 machines intended for the NT server market. If they are not significantly better than the current abysmal Pentium architecture offerings then in conjunction with the porting/emulation issue and general teething troubles there is a big incentive just to stay with x86 based hardware, which is what many shops will do.
AMD is a small but significant wildcard here - I guess they'll be forced to bet the farm in the short to medium term on the x86 architecture, which Intel will leave open to them only when the pickings become slim. If Athlon's bus lives up to its server performance promises, there is even the possibility of Microsoft and Intel both wearing big albumen face packs, with a lot of NT shops opting for NT4 on Athlon and bypassing IA64 and Win2K for the time being.
Basically you can't do this yourself (just you and the bank) as you need to interface to their TP systems, but there are a number of intermediary companies which provide the service. They have secure servers on the internet which have backend access direct into the banks' TP systems.
What you need on your systems ranges from SSL and a few hundred Kb of interface code (which they provide) to just hyperlinks; in the latter case they will host the "enter payment details" page for you.
You will also need a normal merchant account, of the same type you would use if taking cards over the phone. The intermediaries all offer sign-up services for this.
Check out VeriSign, CyberCash and their friends on-line, or do a web search for "credit card processing services" or something similar. They will also handle on-line cheque verfication and debit cards.
There are alos "digital cash" type services but these are all proprietary (requires customers to have an account with that vendor) but have the advantage that they handle small payments (sub-$5) much more economically. For larger payments the credit card mechanism is the way to go.
For 'merkins, PC-World is the UK's equivalent of Comp USA, i.e. overpriced, ubiquitous and aimed at the unwashed and ignorant masses. The difference is that PC-World is owned by Dixons, the UK's equivalent of Circuit City - overpriced, etc. etc.
PC-World has been offering Red Hat and Caldera for years, but they haven't exactly been selling it. They also offer Lotus products:-) The fact that they are shipping a Linux machine is news, but I'd be interested to know (a) how "up front" the advertising is (tried to find Linux on Dell's or Sun's websites lately??) and (b) whether you are paying for Win98 with it (I expect you are).
As far as Java preloads go, you are quite incorrect: apart from being pedantic and pointing out the little Linux vendors like VA and others (my PC came with RH6 preloaded, including kaffe et al.) Sun has been shipping Ultra's with Solaris 7 and the JDK preloaded for some time. I'm sure there are other examples.
What Linux needs is a point and click installer that is comparable to "Install Shield" on Windows. It should be pre-loaded on all distros, should know where to put system files, where to update *all* the popular window manager menus, etc. It should be setuid root by default so the average idiot can run it.
Don't know about the latest Alpha based systems, but by the terms of some supercomputer apps, such as matrix algebra stuff (FE, CFD, etc.) the bigger DEC servers were nothing to right home about around 18-24 months ago when I was doing a lot of benchmarking.
The peak total memory bandwidth available then was 2.4Gb/sec in the AlphaServer 8400, and it really had an impact on big calcs - can't speak for SPECfp, but for a big matrix algebra calc you need (asymptotically approaching) 4 bytes/sec per "flop", and these systems just didn't cut it.
I won't even speak about 32-bit Intel boxes - the 100MHz cache bus sucks enormous rocks, and the 4Gb memory limit (3Gb with NT, less with Linux IIRC) cuts it out of the big job league anyway. This is maybe OK if it's a node in a large MPP system, but these days you want to be able to bring 64Gb or more of RAM to bear on a single problem.
The question we used to hear from our engineering staff was along the lines of: "Hey, my desktop PC is n-zillion MHz, and it runs this tiny test calc almost as fast as the big machine, why don't we just get a lot of big twin Xeon PC's with XYZ graphics cards?". Or occaisonally, the same thing in favour of SGI workstations - engineers love toys just like the rest of us.
This is the classic misconception caused by benchmarks in the FE industry; a lot of test calcs will fit in the cache on a Xeon PC or an R10k or UltraSparc workstation, and show pretty acceptable performance, but the dropoff when you move to a larger problem size and start hitting RAM is sudden and dramatic.
By comparison, if you look at real supercomputers, like the high end Crays or NEC SX series, memory bandwidths of 2 to 4 Gb/sec *per processor* are the norm.
The machine we ended up buying to replace a low-end vector Cray was - an HP V-Class.
The PA-RISC has excellent scoreboarding and memory bus, and the Convex architecture keeps it well fed. We tested on the Convex S-Class hardware running at 180MHz with SPP-UX, and HP guaranteed that the delivered system running HP-UX would meet the clock over clock speedup ratio, which it did with room to spare. We saw well over 700 MFlops *sustained* per CPU on a 200MHz PA-8200 using rather nondescript FORTRAN, against a theoretical peak of 800.
The picture with the newer PA-8500 machines is not so rosy, as the memory bandwidth does not seem to have been scaled up with the capabilties of the new CPUs, especially with double the number of CPUs per board. Nevertheless, as the previous posters' figures would indicate, I believe the sustained throughput still exceeds that of the latest Alpha based systems for certain types of job, and the price/performance is very good.
Of course, for the rabidly religious, Linux is still not well supported on PA-RISC, and doesn't handle the high end hardware.
Since WW2 it has been standard practice for field operatives sending and receiving traffic over totally insecure channels in this manner to use one time pads.
In the days of pencil and paper, a one-time pad was easier to apply (usually simple addition) than an algorithmic cypher, and of course infinitely more secure. I can't see that the computer era would do anything but facilitate it.
Nuclear submarines at sea still receive VLF carrier modulated (morse code style) transmissions for low volume traffic as they are one of the few things that penetrate easily to patrol depths. The Royal Navy still uses Rugby WT for this purpose, and I know there is a US equivalent.
The chip referred to in 2 was a software programmable array, and when you say "environment sensitive" what actually happened was the circuit design only worked on one particular chip (not one part number, one physical chip).
When the virtual digital circuit design was examined, it made no sense at all.
The guy had worked it up by using genetic algorithms to "breed" the bit strings representing the virtual circuit. He was only using Darwinian selection as a success criterion, and what happened was he bred a design which happened to cause the right analogue effects on that particular chip to make it resonate at the target frequency (I thought it was higher than 100Hz) and thus generate a result which was spurious at a digital level, but nevertheless correct.
There was a big piece about it in either SA or Nature about a year ago.
Outside Uncle Sam country, in the rest of the known universe, they have this funky digital mobile phone technology that actually *works*, and is too secure for the FBI/NSA to like it, which is why most of y'all don't have it (though there are fledgling networks in MA, NY, VA, WA and CA). It goes by the name of GSM.
Unlike all the US systems (TDMA, CDMA, IS-136), your phone number isn't tied to the handset, it goes to a little 1/2" chip which you put in the handset, called a Subscriber Identity Module (SIM). Apart from the convenience of being able to choose a handset separately from service, this has huge security benefits.
A curious fact about SIM's is they actually contain not only a private key, but an active CPU and EEPROM. The challenge-response is two way, and they are very difficult to "clone" even WITH physical access to the chip. No-one has *EVER* cloned a GSM SIM using the air interface.
For the disbelieving, I repeat - no-one has EVER cloned a GSM SIM over the air.
So, you ask, WTF does this have to do with this Amex chip?
If Amex have half a brain, they will have adopted this technology - it can be secure even over something insecure like SSL, and could avoid a lot of potential risks in online credit card handling, including replay. Because of the proliferation of GSM, these chips can be mass produced for around $1 each.
Of course, around here (I now live in the US, for my sins) this probably counts as strong crypto technology and would not be allowed to be exported, for fear the North Koreans might use the smart chips configured in a Beowulf cluster to design the next anti-McCarthy bomb.
No, to keep with the current trend, the captain in the next Star Trek will have to be an ethnic minority*, bisexual, disabled single parent in order for it to be PC enough.
Star Trek and its derivatives are merely a sitcom / soap with a pseudo - scifi backdrop, and are no less myopically American than Happy Days.
From the original series, the Klingons are the Russians, geddit? And why does a galaxy-wide organisation like the Federation, with long established spacefaring species like the Vulcans (think - First Contact) locate its headquarters within 300 miles of Hollywood, and use the same designations for its vessels as the US Navy? Because the USA is the centre of the universe.
Of course Paramount don't care about inconsistencies in the ST universe, or how plausible the stuff is. There is no science, it's not sci-fi. If you want sci-fi, read a good novel. And keep Hollywood away from it - look at the travesty that they have made of epic works like Dune.
Let's hope they keep their claws off of Known Space and all the other untarnished universes out there.
* minority in the sense of the US term, i.e. non-white.
The problem with the x86 architecture is not being big-endian (several RISC chips do both) it's the fact that's it's a crappy asymmetric*, CISC, strictly 32-bit and below design. Current Pentiums and friends use a 32-bit RISC core, with microcode to implement the x86 instruction set, bringing them full circle to the early 1970's and things like IBM 370 and VAX. Yuck.
The only reason self-respecting Linux / *BSD / Be fans dirty their desks with such badly architected technology is that the Windows PC revolution has made the price/performance ratio of the hardware second to none. Architecturally nice though UltraSparc might be, I'm fscked if I'll pay US$3.5K for a 350MHz Ultra 5 with IDE, SDRAM and other PC-component technology when I can get a 500MHz Pentium for $1.2K (and falling) that is more or less the same performance. It's all about mass production.
Yes, Sun have missed the point with their latest workstation offerings.
Despite the design effort being poured in by Intel, AMD and others, I expect the gap between Intel x86 and RISC to widen as x86 becomes increasingly crippled by backward compatibility.
Panic not though - Linux is already up and running on all the major RISC architectures, including the much delayed IA-64. With multi-platform use well established, it is well poised to take advantage of any new CPU that comes along.
I too would like to see an increase in the availability of RISC cpu's on PC ATX form factor motherboards, with PCI and AGP, etc.
* in the use of registers - each of the 16 registers in the x86 works with a different subset of the instructions, in contrast to typical modern CPU's where there are typically 32 registers, all fully interchangeable. This feature makes it easier to write good optimising compilers.
Slashdot Mirror
If it's graphics you're into, most of the algorithm stuff (other than some 3D games rendering) is very much in the public domain. Get one of the many excellent books and implement the algorithms therein, you'll learn a lot more.
Foley & Van Dam's "The Art of Computer Graphics" is still widely regarded as a definitive text.
OK, so you know and I know that PC-Week got hoisted by its own petard, but the marketing spin received by the PHB's is "Linux was cracked, NT is secure". Or indeed the not so PHB's - on the strength of this and otehr similar articles I was told by the highly experienced CTO of a local internet startup that "Linux is less secure than NT is less secure than Unix".
The same startup is running their web site in three tier mode, with NT4 web and app servers, and a Solaris/Oracle back end database. All configured for 100% hot failover to guarantee uptime.
They have one DNS server.
OK, call off the dogs....
/etc/resolv.conf from it - I know "rrdhcpcd" does. Also, the stock IANA version of dhcp seems to serve DNS info to clients which will listen; I have this on my IP Masq server and Windoze clients have no trouble automagically divining DNS setups.
I think Microsoft invented it, but IIRC it's now in the standard RFC. I think the "pump" DHCP client for *ix seems to pull down this info and build an
In a dialup / laptop situation, it's worthwhile improvement IMHO. Not EVERYTHING from Redmond sucks.
What's wrong with Logan, or do they want one down the street? :-)
Most of those are already in ACC's book "3001: The Final Odyssey" - though the source of low gravity is different.
For those who take a passing interest in the history of computing, or who find people like Richard Stallman entertaining, the story of Seymour Cray the man is quite interesting. His methods of designing hardware (consulting the elves) were definitely unique.
I don't think we'll see anyone quite like that again.
It was always said in the supercomputing community that the US government would never let Cray die. Buying in supercomputers from Japan, the only other source of big iron, just wouldn't wash with the likes of the NSA.
First it was blocking the NCAR deal, and now this.
Actually, I think the vector pipes on a Y/MP are something like 8 or 10 units deep.
These computers are designed for one type of calculation - matrix algebra, which requires simple processing (multiply, add, invert) on enormous 2D arrays of numbers. The important point: the working set of these problems is often the size of the matrices, so caches are ineffective. Cray vector machines do not have ANY data cache between the vector units and main memory.
The feature of most vector machines that no-one has really pointed out yet is the way the memory system keeps those vector units fed. Unlike a microporcessor which relies on 2 or more layers of cache, the vector machine is quite capable of streaming data from memory fast enough to keep the processor 100% busy.
The vector instruction results in a number of vector fetches being issued to the memory controller, which is told to fetch a strided vector from memory (start at address x, every ith word, n words in total). The memory controller issues requests to individual banks in an overlapping fashion. Like the vector FPU, after it gets over its latency it starts banging the words out once per clock cycle.
The way this is done is to have a huge interleave in the memory - Cray T90's use either 1024 or 2048 banks. So long as any one bank is not hit more than one per 100ns or so (the cycle time of the memory) the memory controller is capable of delivering multiple streams of 64 bit words at full clock speed (T90's can have up to 32 CPU's). Typically, to ensure this, arrays in programs are structured to stride along the first dimension (FORTRAN remember) or where this isn't possible, the array dimensions are chosen to be prime numbers.
The thing that sets these machines apart is not processor speed - the peak speed in MFlops on an NEC SX-5 is only about 2-3 times that of an Alpha AXP. The thing that makes them special is the memory bandwidth to sustain that performance.
To use my favourite automotive analogy, if a PC is a small hatchback, then a supercomputer is an 18-wheeler, not a Ferrari.
Linux advocates - please refrain from posting things which are utter nonsense. You just make the rest of us look bad.
...) all run a Unix OS natively. Cray's Unicos is in version *10*
The original Cray 1 and 1/S were like this, being parasitic on an IBM or VAX host. Modern supercomputers (Cray, Fujitsu, NEC,
Similarly, the first Cray parallel machine, the T3D, parasited - off the back of a Cray vector machine, J90 or C90. The T3E however devotes some of its 21264's to being I/O processors.
Actually, I think you've got the wrong war - there was no overt US involvement in the Falklands due to the Americas Treaty.
However, the US Navy airbase at Kindley Field, Bermuda (British soil on loan) did give a few Harrier pilots a helping hand and a bit of fuel on their way from Farnborough to Ascencion.
This is surely a huge waste of time - unless they find some way of forcing it on a significant proportion of the user community (examples: a deal with AOL, a built-in feature in IE) then it is doomed to failure. It's also somewhat unscaleable in its present form.
.com and that is the driving force. Don't expect to see any volumes of eCommerce websites with .shop any time soon.
Basically, for Joe Public, the web is the Internet, and he knows that all website URL's start with www. and end in
Merced will succeed if and only if it gets real backing from Microsoft as the "main" platform for Win2K, and the software comes out for it. Distasteful as it may be in this community, this is the reality, and all else is secondary. Without this level of support from Microsoft, IA-64 is just an also-ran to Alpha; indeed, if the performance of initial Merced releases is not up to scratch it may require that Microsoft actively backs away from Alpha to help Merced succeed.
It's interesting to note that HP is carefully hedging its own bets - all of its new HP-UX server line (Dome series) originally slated for Merced have been (re-)architected to take both PA-RISC and IA64 processors, and the extended delays in Merced have caused them to plan one and then two additional revs of the 64-bit PA-RISC architecture (PA-8700 and now PA-8900) which has always been slated for termination once IA-64 is fully available.
The good news for IA-64 is that McKinley development is rumoured to be catching up with Merced and it should be ready to ship more or less immediately afterwards. I wouldn't be surprised to see McKinley shipping simultaneously as the high end version, c.f. Xeon's and P3's in the x86 world.
Seems like a sensible business decision on Compaq's part to me.
- They have their own 64-bit architecture that is well established
- When you're offering a proprietary OS it makes sense to keep down the number of platforms you support
The more interesting decisions for them are:
1. Should they continue to push NT on Alpha?
2. Should they sell and support NT on IA64?
To a large extent these depend on which way Microsoft and the PC software industry jumps - you don't buy software to fit the hardware, you do it the other way. If Microsoft pushes IA64 as the main platform, then that will force Compaq's hand as far as NT goes. However, the widespread use of NT on non-x86 platforms which was touted when NT was new has failed to materialise, with the excpetion of a small Alpha following, and I think x86 will be with us for a while yet.
What I'd be interested to know is how the memory bus and cache coherency work on multi-cpu IA64 machines intended for the NT server market. If they are not significantly better than the current abysmal Pentium architecture offerings then in conjunction with the porting/emulation issue and general teething troubles there is a big incentive just to stay with x86 based hardware, which is what many shops will do.
AMD is a small but significant wildcard here - I guess they'll be forced to bet the farm in the short to medium term on the x86 architecture, which Intel will leave open to them only when the pickings become slim. If Athlon's bus lives up to its server performance promises, there is even the possibility of Microsoft and Intel both wearing big albumen face packs, with a lot of NT shops opting for NT4 on Athlon and bypassing IA64 and Win2K for the time being.
And also: Unicos, Unicos/Mk, Super-UX, SPP-UX
Basically you can't do this yourself (just you and the bank) as you need to interface to their TP systems, but there are a number of intermediary companies which provide the service. They have secure servers on the internet which have backend access direct into the banks' TP systems.
What you need on your systems ranges from SSL and a few hundred Kb of interface code (which they provide) to just hyperlinks; in the latter case they will host the "enter payment details" page for you.
You will also need a normal merchant account, of the same type you would use if taking cards over the phone. The intermediaries all offer sign-up services for this.
Check out VeriSign, CyberCash and their friends on-line, or do a web search for "credit card processing services" or something similar. They will also handle on-line cheque verfication and debit cards.
There are alos "digital cash" type services but these are all proprietary (requires customers to have an account with that vendor) but have the advantage that they handle small payments (sub-$5) much more economically. For larger payments the credit card mechanism is the way to go.
For 'merkins, PC-World is the UK's equivalent of Comp USA, i.e. overpriced, ubiquitous and aimed at the unwashed and ignorant masses. The difference is that PC-World is owned by Dixons, the UK's equivalent of Circuit City - overpriced, etc. etc.
:-) The fact that they are shipping a Linux machine is news, but I'd be interested to know (a) how "up front" the advertising is (tried to find Linux on Dell's or Sun's websites lately??) and (b) whether you are paying for Win98 with it (I expect you are).
PC-World has been offering Red Hat and Caldera for years, but they haven't exactly been selling it. They also offer Lotus products
As far as Java preloads go, you are quite incorrect: apart from being pedantic and pointing out the little Linux vendors like VA and others (my PC came with RH6 preloaded, including kaffe et al.) Sun has been shipping Ultra's with Solaris 7 and the JDK preloaded for some time. I'm sure there are other examples.
What Linux needs is a point and click installer that is comparable to "Install Shield" on Windows. It should be pre-loaded on all distros, should know where to put system files, where to update *all* the popular window manager menus, etc. It should be setuid root by default so the average idiot can run it.
Don't know about the latest Alpha based systems, but by the terms of some supercomputer apps, such as matrix algebra stuff (FE, CFD, etc.) the bigger DEC servers were nothing to right home about around 18-24 months ago when I was doing a lot of benchmarking.
The peak total memory bandwidth available then was 2.4Gb/sec in the AlphaServer 8400, and it really had an impact on big calcs - can't speak for SPECfp, but for a big matrix algebra calc you need (asymptotically approaching) 4 bytes/sec per "flop", and these systems just didn't cut it.
I won't even speak about 32-bit Intel boxes - the 100MHz cache bus sucks enormous rocks, and the 4Gb memory limit (3Gb with NT, less with Linux IIRC) cuts it out of the big job league anyway. This is maybe OK if it's a node in a large MPP system, but these days you want to be able to bring 64Gb or more of RAM to bear on a single problem.
The question we used to hear from our engineering staff was along the lines of: "Hey, my desktop PC is n-zillion MHz, and it runs this tiny test calc almost as fast as the big machine, why don't we just get a lot of big twin Xeon PC's with XYZ graphics cards?". Or occaisonally, the same thing in favour of SGI workstations - engineers love toys just like the rest of us.
This is the classic misconception caused by benchmarks in the FE industry; a lot of test calcs will fit in the cache on a Xeon PC or an R10k or UltraSparc workstation, and show pretty acceptable performance, but the dropoff when you move to a larger problem size and start hitting RAM is sudden and dramatic.
By comparison, if you look at real supercomputers, like the high end Crays or NEC SX series, memory bandwidths of 2 to 4 Gb/sec *per processor* are the norm.
The machine we ended up buying to replace a low-end vector Cray was - an HP V-Class.
The PA-RISC has excellent scoreboarding and memory bus, and the Convex architecture keeps it well fed. We tested on the Convex S-Class hardware running at 180MHz with SPP-UX, and HP guaranteed that the delivered system running HP-UX would meet the clock over clock speedup ratio, which it did with room to spare. We saw well over 700 MFlops *sustained* per CPU on a 200MHz PA-8200 using rather nondescript FORTRAN, against a theoretical peak of 800.
The picture with the newer PA-8500 machines is not so rosy, as the memory bandwidth does not seem to have been scaled up with the capabilties of the new CPUs, especially with double the number of CPUs per board. Nevertheless, as the previous posters' figures would indicate, I believe the sustained throughput still exceeds that of the latest Alpha based systems for certain types of job, and the price/performance is very good.
Of course, for the rabidly religious, Linux is still not well supported on PA-RISC, and doesn't handle the high end hardware.
Since WW2 it has been standard practice for field operatives sending and receiving traffic over totally insecure channels in this manner to use one time pads.
In the days of pencil and paper, a one-time pad was easier to apply (usually simple addition) than an algorithmic cypher, and of course infinitely more secure. I can't see that the computer era would do anything but facilitate it.
Nuclear submarines at sea still receive VLF carrier modulated (morse code style) transmissions for low volume traffic as they are one of the few things that penetrate easily to patrol depths. The Royal Navy still uses Rugby WT for this purpose, and I know there is a US equivalent.
The chip referred to in 2 was a software programmable array, and when you say "environment sensitive" what actually happened was the circuit design only worked on one particular chip (not one part number, one physical chip).
When the virtual digital circuit design was examined, it made no sense at all.
The guy had worked it up by using genetic algorithms to "breed" the bit strings representing the virtual circuit. He was only using Darwinian selection as a success criterion, and what happened was he bred a design which happened to cause the right analogue effects on that particular chip to make it resonate at the target frequency (I thought it was higher than 100Hz) and thus generate a result which was spurious at a digital level, but nevertheless correct.
There was a big piece about it in either SA or Nature about a year ago.
The POT submitter does not bowdlerise HTML, it just keeps line breaks: s/\\n/
/ I guess
But then it could be just another Tera MTA...
I can't be the only one who finds irony in the fact that the banner ad on ComputerWorld is, in over 25% of impressions, for NT Server?
If it's targeted, maybe they're picking up my browser ident (Mozilla 4.51 Linux i686)?
;-)
Outside Uncle Sam country, in the rest of the known universe, they have this funky digital mobile phone technology that actually *works*, and is too secure for the FBI/NSA to like it, which is why most of y'all don't have it (though there are fledgling networks in MA, NY, VA, WA and CA). It goes by the name of GSM.
Unlike all the US systems (TDMA, CDMA, IS-136), your phone number isn't tied to the handset, it goes to a little 1/2" chip which you put in the handset, called a Subscriber Identity Module (SIM). Apart from the convenience of being able to choose a handset separately from service, this has huge security benefits.
A curious fact about SIM's is they actually contain not only a private key, but an active CPU and EEPROM. The challenge-response is two way, and they are very difficult to "clone" even WITH physical access to the chip. No-one has *EVER* cloned a GSM SIM using the air interface.
For the disbelieving, I repeat - no-one has EVER cloned a GSM SIM over the air.
So, you ask, WTF does this have to do with this Amex chip?
If Amex have half a brain, they will have adopted this technology - it can be secure even over something insecure like SSL, and could avoid a lot of potential risks in online credit card handling, including replay. Because of the proliferation of GSM, these chips can be mass produced for around $1 each.
Of course, around here (I now live in the US, for my sins) this probably counts as strong crypto technology and would not be allowed to be exported, for fear the North Koreans might use the smart chips configured in a Beowulf cluster to design the next anti-McCarthy bomb.
No, to keep with the current trend, the captain in the next Star Trek will have to be an ethnic minority*, bisexual, disabled single parent in order for it to be PC enough.
Star Trek and its derivatives are merely a sitcom / soap with a pseudo - scifi backdrop, and are no less myopically American than Happy Days.
From the original series, the Klingons are the Russians, geddit? And why does a galaxy-wide organisation like the Federation, with long established spacefaring species like the Vulcans (think - First Contact) locate its headquarters within 300 miles of Hollywood, and use the same designations for its vessels as the US Navy? Because the USA is the centre of the universe.
Of course Paramount don't care about inconsistencies in the ST universe, or how plausible the stuff is. There is no science, it's not sci-fi. If you want sci-fi, read a good novel. And keep Hollywood away from it - look at the travesty that they have made of epic works like Dune.
Let's hope they keep their claws off of Known Space and all the other untarnished universes out there.
* minority in the sense of the US term, i.e. non-white.
The problem with the x86 architecture is not being big-endian (several RISC chips do both) it's the fact that's it's a crappy asymmetric*, CISC, strictly 32-bit and below design. Current Pentiums and friends use a 32-bit RISC core, with microcode to implement the x86 instruction set, bringing them full circle to the early 1970's and things like IBM 370 and VAX. Yuck.
The only reason self-respecting Linux / *BSD / Be fans dirty their desks with such badly architected technology is that the Windows PC revolution has made the price/performance ratio of the hardware second to none. Architecturally nice though UltraSparc might be, I'm fscked if I'll pay US$3.5K for a 350MHz Ultra 5 with IDE, SDRAM and other PC-component technology when I can get a 500MHz Pentium for $1.2K (and falling) that is more or less the same performance. It's all about mass production.
Yes, Sun have missed the point with their latest workstation offerings.
Despite the design effort being poured in by Intel, AMD and others, I expect the gap between Intel x86 and RISC to widen as x86 becomes increasingly crippled by backward compatibility.
Panic not though - Linux is already up and running on all the major RISC architectures, including the much delayed IA-64. With multi-platform use well established, it is well poised to take advantage of any new CPU that comes along.
I too would like to see an increase in the availability of RISC cpu's on PC ATX form factor motherboards, with PCI and AGP, etc.
* in the use of registers - each of the 16 registers in the x86 works with a different subset of the instructions, in contrast to typical modern CPU's where there are typically 32 registers, all fully interchangeable. This feature makes it easier to write good optimising compilers.