Alpha will never be revived, the internal engineering expertise is for all intents gone and HP has little intention rebuilding it. 64bit future is either x86-64 and/or Itanic, unless intel do an about face and create their own 64bit x86 ISA (in which case that ISA will no doubt win).
Not quite, the League of Nations collapsed after the US would not join it.
You are utterly misinformed.
Go and google and read up on the history of the LoN. Failure of the US to join the LoN did not prevent it being established or it operating, the US at that time was of little influence in world affairs (partly by choice). The LoN was not dissolved until 1948. However, it's widely accepted that the LoN lost some of its credibility when it failed to condemn Italy for invading Corfu in 1923. It then lost all credibility in 1935 when it failed to deal with Italy's invasion of Abyssinia.
There are no US peacekeepers in Cyprus AFAIK (mostly british).
The korean UN force was mostly american, but I'm pretty sure there were plenty of Brits and Canadians involved as well as several other countries. But it wasnt a peace keeping force was it?:) They merely had a UN mandate, (ditto for Kosovo i think).
There are no US peacekeepers in Liberia, Congo, Lebanon, etc.. Mostly done by smaller nations (eg Ireland, Netherlands, etc.. etc..). The US doesnt really get involved in UN peacekeeping that often TTBOMK.
You realise the UN provided a forum for the US and USSR to score political points against each other? Eg, Kruschov and Kennedy made use of the UN during the missile crisis.
Providing a public forum is precisely one of the reasons the UN exists, borne out of the lessons of the secret diplomacy which led to the first world war.
(League of Nations was setup - Woodrow Wilson played a major part in that, though US ended up not bothering, LoN collapsed because France and Britain decided not to do anything about infractions on Italy and Germany's part, out of self-interest. Another war, and the world decided to try again at LoN, but improved -> UN).
NetBSD is the furthest along in terms of AMD64 maturity
Just curious, but how do you figure that? SuSe was working with AMD to port Linux and indeed Linux was running on the x86-64 simulator quite early on. I cant find anything to support it, but I have a vague memory Linux was first to boot x86-64 (simulated). NetBSD port appears to have been done in 2001, cant find references to Linux, but the impression was that AMD were really keen to get Linux ported over as quick as possible.
The Java VM specifications are relatively open and available. There are several well-known VMs, at least one of which is opensource, and many other VM implementations. Many of these come with bytecode compilers, as does GCC.
The only difference is that you can't host services on your phone that are internet addressable.
And how exactly do you propose that 2 phones communicate with each other (eg videophone, and one day even will be packet switched over IP) if neither are publically addressable?
No, the StrongARM ISA derives from the ARM ISA, which DEC licensed from Acorn UK (or ARM UK, whoever). AXP being DECs other modern CPU, yes, they would have applied lessons learnt in its design to the design of AXP, but the architecture is otherwise not really related to AXP (other than both being RISC), SA-110 was designed to be a simple, low-power CPU, at the expense of some speed, while AXP never had the power constraints.
There's a good paper on the StrongARM SA-110 in the DEC Technical Journal somewhere./me googles, see:
AXP was released in '92, long before PA8k. Indeed DEC gave Linus an Alpha in '94 for him so that he could port Linux to Alpha - AXP was the first non-i386 architecture Linux port, Linux was also a fully 64bit OS and userland well before most commercial Unix implementations.
After counting back through the years, I think it was actually late '98. But the merging process didnt really kick in until '99 - and even so, many DEC sites never had any compaq equivalent to merge with, DEC being vastly bigger than Compaq. Indeed, the merger changed Compaq far more than it did DEC.:)
That the lawsuit of a few years back with Intel and DEC resulted in Intel getting rights to the Alpha technology
Ironically, that was a lawsuit which/DEC/ won. As part of the settlement, DEC got ~$110m, intel got to buy:
- DEC's Hudson FAB - alpha rights (non-exclusive due to FTC ruling, hence reason why Samsung made alphas too) - rights to just about every design in DEC Semiconductor's portfolio.
And more no doubt.
To this day, if you buy a generic multi-port NIC (eg D-Link), it likely has an intel 21174 PCI bridge with multiple intel 21143 NIC ASICs behind it - both ASICs are DEC Semiconductor designs. If you buy a PDA it likely has an Intel XScale or StrongARM CPU - another DEC Semiconductor design.
Yes, somehow this all came about from a lawsuit which/DEC/ *won*. I think in return DEC got the service contract for all of intel's IT.
Compaq acquired DEC late 98. However it was/DEC/ which squandered Alpha - the squandering of excellent DEC engineering by management was a long-standing DEC problem. (its precisely why Compaq were able to take over DEC in the first place).
Excellent and very informative post, however, that bit is wrong, the SA110 had nothing to do with AXP. Completely different processor, from instruction set to design goals.
at the time the Alpha was released, HP had another CPU that they liked a lot. It was the PA8000 family
At the time Alpha was released HP did not have the PA8000 family, that came out in 1996, Alpha was released in 1992 IIRC. HP at that time were using 32bit PA7000s, it seems. Further: "had another" -> HP had nothing to do with Alpha, it was DEC. HP only acquired the Alpha architecture recently after "merging" with Compaq who had acquired DEC in 1999.
Alpha's actually were cheaper than the competing Workstations chips. The Alpha 21164 workstations cost a few thousand, just above high-end PC workstations and/below/ the likes of SGI's and Sun's workstations. DEC did try to commoditise the AXP, eg the 21064 based DEC Multia wasnt too expensive and aimed at the corporate desktop market.
Further, you cant really compare Alpha to SPARC, it was 32 bit! Even Sun's UltraSPARC workstations did not support userland 64bit support until Solaris 8. SGI did not have 64bit support till R10k, and even then many of their workstations (eg O2?) could not run 64bit and it took SGI a while to actually introduce 64bit ABI support in IRIX. The RS6k, well correct me if I'm wrong, but most RS6k's are 32bit PPC. HP PA-RISC was 64bit, but i've no idea what 64bit support was like in HP-UX (but then/who/ ever bought HP-UX workstations?:) )
Essentially, for a long time Alpha was the only game in town if you needed 64bit support, the only arch and, more to the point, operating systems with 64bit support (digital Unix and Linux) for quite a few years (93 to late 90s when other vendors started to get their OSes into shape).
As for speed, Alpha for a long time/demolished/ the competition on floating point. Go have a look at the SPECfp95 benchmarks. Titanic was rendered on a cluster of Alpha 21164s because Alpha was the fastest thing out there. The 21264/really/ demolished the competition, but the 21264 was unfortunately far more expensive than the 21164 ever was.
You're not thinking of the K6 are you? That was actually a very good processor, it was faster than the Pentium. Unfortunately though for AMD, intel adapted the PPro for consumer use and called it the Pentium II, and suddenly the K6 had to compete with that. Even so, the K6 still compared favourably on integer operations, eg K6-2 and III's @ 450MHz both beat the faster clocked Celeron 500MHz and the K6 isnt that far off the Pentium II at SPECint95.
The K6 did suck a bit at floating point though, especially compared to the PII and even the Pentium MMX. But otherwise, for general purpose work, it was a fine CPU, especially the rare K6-III with its on board L2 cache.
You want kerberos V5 telnet/rcp, secure authentication, but without the overhead of encrypting the data stream:
[paul@fogarty paul]$ echo "kerberos is nifty" >/tmp/kfile [paul@fogarty paul]$ rcp/tmp/kfile hibernia:/tmp Trying krb4 rcp... trying normal rcp (/usr/bin/rcp) [paul@fogarty paul]$ telnet -a hibernia Trying 192.168.0.3... Connected to hibernia.somewhere (192.168.0.3). Escape character is '^]'. [ Kerberos V5 accepts you as ``paul@SOMEWHERE'' ] Last login: Wed Oct 15 03:38:04 from fogarty You have mail. [paul@hibernia paul]$ cat/tmp/kfile kerberos is nifty [paul@hibernia paul]$ logout
note that you still have the option of encrypting the data stream if you wish by specifying -x to either telnet or rcp. So next time someone tells you telnet, rcp are insecure you can tell them they are wrong!:)
Note there are is also a kerberos version of FTP server/client available.
Yeah, i did. Very strange, cause that's where i'm almost sure I posted it to. I didnt even open the "Geeks and motorheads" story, so i dont know how i could have accidently posted to it.
Actually, most processors have a HALT instruction, which the OS can issue, to be woken up at next interrupt (eg timer interrupt if nothing else).
It used to be that a PC would run noticeably cooler under linux than windows, because Linux would issue the halt instruction when idling, while Windows used a NOOP loop for its idle cycle. Dont know if Windows still 'burns' like this, I think it was fixed.
The variable is evaluated/before/ the post-increment operator is applied. The value of i inside the loop first time round OTOH/would/ be 1.
Also, just for the fun of it, change the declaration of i from 'double i=0' to 'int i=-1' and see what happens (at least on x86, alpha, usparc, ppc), find out why, and dont ever forget:)
[paul@fogarty paul]$ echo "kerberos is nifty" >/tmp/kfile [paul@fogarty paul]$ rcp/tmp/kfile hibernia:/tmp Trying krb4 rcp... trying normal rcp (/usr/bin/rcp) [paul@fogarty paul]$ telnet -a hibernia Trying 192.168.0.3... Connected to hibernia.somewhere (192.168.0.3). Escape character is '^]'. [ Kerberos V5 accepts you as ``paul@SOMEWHERE'' ] Last login: Wed Oct 15 03:38:04 from fogarty You have mail. [paul@hibernia paul]$ cat/tmp/kfile kerberos is nifty [paul@hibernia paul]$ logout
note that you can optionally encrypt the data stream too by specifying -x to either telnet or rcp. So next time someone tells you telnet, rcp are insecure you can tell them they are wrong!:)
Note there are is also a kerberos version of FTP server/client available.
Because he compares the FSF chasing GPL violators to people wanting to "burn your house down" - the house never belonged to the infringers in the first place.
"Stop tarring NFS with the Linux brush." Ahem... chill out.
Well, that is effectively what you did:)
but to the avg linux user NFSv3 is insecure
No... Linux's kernel RPC does not support any strong security mechanisms. Neither does glibc really, but I think it might now support AUTH_DES (shared key DES, not terribly secure, but better than AUTH_UNIX) to some extent. I dont think its really used anywhere.
Is the v3 spec abiguous
Nope. Again, RPC != NFS. NFS/uses/ RPC, RPC is the mechanism by which NFS clients and servers communicate. Just as how HTTP operates over SSL (if you want security) and you would not blame HTTP for problems or lack of support for strong security/auth mechs in SSL, you can not blame NFS too much for problems in security, as it relies on RPC to establish credentials (just as HTTP would with SSL). The major difference between v3 and v4 in terms of security is that v4 specifies that RPCSEC_GSS/will/ be available, whereas the lowest common denominator with v3 is plain AUTH_UNIX. So there is no choice but to implement secure RPC if you wish to support NFSv4. Hence the secure RPC mechanism will be guaranteed to be interoperable (Eg, only Sun supported AUTH_DSA iirc), eg these mech's presumably will have been tested at the NFS bake-athon's.
Was it hampered by export restrictions?
Probably, RPCSEC_GSS tends to be Kerberos v5 at the backend. Which was restricted. Sun's AUTH_DSA was similarly restricted as "ammunitions" for quite a while.
Anyway, go google for rpc_secure, RPCSEC, RPCSEC_GSS, AUTH_DSA, AUTH_DES and AUTH_UNIX!:)
Slashdot Mirror
Alpha will never be revived, the internal engineering expertise is for all intents gone and HP has little intention rebuilding it. 64bit future is either x86-64 and/or Itanic, unless intel do an about face and create their own 64bit x86 ISA (in which case that ISA will no doubt win).
If something is "perfectly normal and ok", then how is it wrong?
Not quite, the League of Nations collapsed after the US would not join it.
You are utterly misinformed.
Go and google and read up on the history of the LoN. Failure of the US to join the LoN did not prevent it being established or it operating, the US at that time was of little influence in world affairs (partly by choice). The LoN was not dissolved until 1948. However, it's widely accepted that the LoN lost some of its credibility when it failed to condemn Italy for invading Corfu in 1923. It then lost all credibility in 1935 when it failed to deal with Italy's invasion of Abyssinia.
There are no UN peacekeepers in Iraq.
:) They merely had a UN mandate, (ditto for Kosovo i think).
There are no US peacekeepers in Cyprus AFAIK (mostly british).
The korean UN force was mostly american, but I'm pretty sure there were plenty of Brits and Canadians involved as well as several other countries. But it wasnt a peace keeping force was it?
There are no US peacekeepers in Liberia, Congo, Lebanon, etc.. Mostly done by smaller nations (eg Ireland, Netherlands, etc.. etc..). The US doesnt really get involved in UN peacekeeping that often TTBOMK.
You realise the UN provided a forum for the US and USSR to score political points against each other? Eg, Kruschov and Kennedy made use of the UN during the missile crisis.
Providing a public forum is precisely one of the reasons the UN exists, borne out of the lessons of the secret diplomacy which led to the first world war.
(League of Nations was setup - Woodrow Wilson played a major part in that, though US ended up not bothering, LoN collapsed because France and Britain decided not to do anything about infractions on Italy and Germany's part, out of self-interest. Another war, and the world decided to try again at LoN, but improved -> UN).
IRIX is Unix(TM), so she was right.
NetBSD is the furthest along in terms of AMD64 maturity
Just curious, but how do you figure that? SuSe was working with AMD to port Linux and indeed Linux was running on the x86-64 simulator quite early on. I cant find anything to support it, but I have a vague memory Linux was first to boot x86-64 (simulated). NetBSD port appears to have been done in 2001, cant find references to Linux, but the impression was that AMD were really keen to get Linux ported over as quick as possible.
The Java VM specifications are relatively open and available. There are several well-known VMs, at least one of which is opensource, and many other VM implementations. Many of these come with bytecode compilers, as does GCC.
So, how exactly is it hypocrisy?
(still doesnt excuse Java's monstrous runtime resource needs though.)
The only difference is that you can't host services on your phone that are internet addressable.
And how exactly do you propose that 2 phones communicate with each other (eg videophone, and one day even will be packet switched over IP) if neither are publically addressable?
No, the StrongARM ISA derives from the ARM ISA, which DEC licensed from Acorn UK (or ARM UK, whoever). AXP being DECs other modern CPU, yes, they would have applied lessons learnt in its design to the design of AXP, but the architecture is otherwise not really related to AXP (other than both being RISC), SA-110 was designed to be a simple, low-power CPU, at the expense of some speed, while AXP never had the power constraints.
/me googles, see:
J P00/
There's a good paper on the StrongARM SA-110 in the DEC Technical Journal somewhere.
http://research.compaq.com/wrl/DECarchives/DTJ/DT
AXP was released in '92, long before PA8k. Indeed DEC gave Linus an Alpha in '94 for him so that he could port Linux to Alpha - AXP was the first non-i386 architecture Linux port, Linux was also a fully 64bit OS and userland well before most commercial Unix implementations.
Compaq who had acquired DEC in 1999
:)
After counting back through the years, I think it was actually late '98. But the merging process didnt really kick in until '99 - and even so, many DEC sites never had any compaq equivalent to merge with, DEC being vastly bigger than Compaq. Indeed, the merger changed Compaq far more than it did DEC.
All well and good but the K6 did not have 3DNow! support. (introduced with K6-2).
That the lawsuit of a few years back with Intel and DEC resulted in Intel getting rights to the Alpha technology
/DEC/ won. As part of the settlement, DEC got ~$110m, intel got to buy:
/DEC/ *won*. I think in return DEC got the service contract for all of intel's IT.
Ironically, that was a lawsuit which
- DEC's Hudson FAB
- alpha rights (non-exclusive due to FTC ruling, hence reason why Samsung made alphas too)
- rights to just about every design in DEC Semiconductor's portfolio.
And more no doubt.
To this day, if you buy a generic multi-port NIC (eg D-Link), it likely has an intel 21174 PCI bridge with multiple intel 21143 NIC ASICs behind it - both ASICs are DEC Semiconductor designs. If you buy a PDA it likely has an Intel XScale or StrongARM CPU - another DEC Semiconductor design.
Yes, somehow this all came about from a lawsuit which
Compaq acquired DEC late 98. However it was /DEC/ which squandered Alpha - the squandering of excellent DEC engineering by management was a long-standing DEC problem. (its precisely why Compaq were able to take over DEC in the first place).
or direct decendents (StrongARM).
Excellent and very informative post, however, that bit is wrong, the SA110 had nothing to do with AXP. Completely different processor, from instruction set to design goals.
at the time the Alpha was released, HP had another CPU that they liked a lot. It was the PA8000 family
At the time Alpha was released HP did not have the PA8000 family, that came out in 1996, Alpha was released in 1992 IIRC. HP at that time were using 32bit PA7000s, it seems. Further: "had another" -> HP had nothing to do with Alpha, it was DEC. HP only acquired the Alpha architecture recently after "merging" with Compaq who had acquired DEC in 1999.
Alpha's actually were cheaper than the competing Workstations chips. The Alpha 21164 workstations cost a few thousand, just above high-end PC workstations and /below/ the likes of SGI's and Sun's workstations. DEC did try to commoditise the AXP, eg the 21064 based DEC Multia wasnt too expensive and aimed at the corporate desktop market.
/who/ ever bought HP-UX workstations? :) )
/demolished/ the competition on floating point. Go have a look at the SPECfp95 benchmarks. Titanic was rendered on a cluster of Alpha 21164s because Alpha was the fastest thing out there. The 21264 /really/ demolished the competition, but the 21264 was unfortunately far more expensive than the 21164 ever was.
Further, you cant really compare Alpha to SPARC, it was 32 bit! Even Sun's UltraSPARC workstations did not support userland 64bit support until Solaris 8. SGI did not have 64bit support till R10k, and even then many of their workstations (eg O2?) could not run 64bit and it took SGI a while to actually introduce 64bit ABI support in IRIX. The RS6k, well correct me if I'm wrong, but most RS6k's are 32bit PPC. HP PA-RISC was 64bit, but i've no idea what 64bit support was like in HP-UX (but then
Essentially, for a long time Alpha was the only game in town if you needed 64bit support, the only arch and, more to the point, operating systems with 64bit support (digital Unix and Linux) for quite a few years (93 to late 90s when other vendors started to get their OSes into shape).
As for speed, Alpha for a long time
You're not thinking of the K6 are you? That was actually a very good processor, it was faster than the Pentium. Unfortunately though for AMD, intel adapted the PPro for consumer use and called it the Pentium II, and suddenly the K6 had to compete with that. Even so, the K6 still compared favourably on integer operations, eg K6-2 and III's @ 450MHz both beat the faster clocked Celeron 500MHz and the K6 isnt that far off the Pentium II at SPECint95.
The K6 did suck a bit at floating point though, especially compared to the PII and even the Pentium MMX. But otherwise, for general purpose work, it was a fine CPU, especially the rare K6-III with its on board L2 cache.
note that you still have the option of encrypting the data stream if you wish by specifying -x to either telnet or rcp. So next time someone tells you telnet, rcp are insecure you can tell them they are wrong!
Note there are is also a kerberos version of FTP server/client available.
Yeah, i did. Very strange, cause that's where i'm almost sure I posted it to. I didnt even open the "Geeks and motorheads" story, so i dont know how i could have accidently posted to it.
A strange slashbug perhaps?
weird...
Actually, most processors have a HALT instruction, which the OS can issue, to be woken up at next interrupt (eg timer interrupt if nothing else).
It used to be that a PC would run noticeably cooler under linux than windows, because Linux would issue the halt instruction when idling, while Windows used a NOOP loop for its idle cycle. Dont know if Windows still 'burns' like this, I think it was fixed.
actually... the first comparison would be of:
/before/ the post-increment operator is applied. The value of i inside the loop first time round OTOH /would/ be 1.
:)
0 != 0xFFFFFFFF
The variable is evaluated
Also, just for the fun of it, change the declaration of i from 'double i=0' to 'int i=-1' and see what happens (at least on x86, alpha, usparc, ppc), find out why, and dont ever forget
note that you can optionally encrypt the data stream too by specifying -x to either telnet or rcp. So next time someone tells you telnet, rcp are insecure you can tell them they are wrong!
Note there are is also a kerberos version of FTP server/client available.
Because he compares the FSF chasing GPL violators to people wanting to "burn your house down" - the house never belonged to the infringers in the first place.
"Stop tarring NFS with the Linux brush." Ahem... chill out.
:)
/uses/ RPC, RPC is the mechanism by which NFS clients and servers communicate. Just as how HTTP operates over SSL (if you want security) and you would not blame HTTP for problems or lack of support for strong security/auth mechs in SSL, you can not blame NFS too much for problems in security, as it relies on RPC to establish credentials (just as HTTP would with SSL). The major difference between v3 and v4 in terms of security is that v4 specifies that RPCSEC_GSS /will/ be available, whereas the lowest common denominator with v3 is plain AUTH_UNIX. So there is no choice but to implement secure RPC if you wish to support NFSv4. Hence the secure RPC mechanism will be guaranteed to be interoperable (Eg, only Sun supported AUTH_DSA iirc), eg these mech's presumably will have been tested at the NFS bake-athon's.
:)
Well, that is effectively what you did
but to the avg linux user NFSv3 is insecure
No... Linux's kernel RPC does not support any strong security mechanisms. Neither does glibc really, but I think it might now support AUTH_DES (shared key DES, not terribly secure, but better than AUTH_UNIX) to some extent. I dont think its really used anywhere.
Is the v3 spec abiguous
Nope. Again, RPC != NFS. NFS
Was it hampered by export restrictions?
Probably, RPCSEC_GSS tends to be Kerberos v5 at the backend. Which was restricted. Sun's AUTH_DSA was similarly restricted as "ammunitions" for quite a while.
Anyway, go google for rpc_secure, RPCSEC, RPCSEC_GSS, AUTH_DSA, AUTH_DES and AUTH_UNIX!