Indeed; SIRTF will be great in the short term, but for real longevity (including upgrades to the instrumentation as technology advances), it's going to be hard to beat SOFIA. The ability to service and upgrade a facility is what kept HST useful for so long. With SOFIA, we're effectively dealing with an observatory that lands every day. By comparison with space based observatories, improving and upgrading SOFIA will be a snap!
It's not so much that you're missing something, as it is that you've turned the problem around.:-)
Wind and distribution will be good. Movement will be good. Accurate location information isn't that far off, and then you'll want things to move around so as to better map out an area. For example, when something like this is deployed in water to provide ground truth for some airborne sensor, you count on drift and movement to spread over the target area.
HP has had to sell nothing about the Alpha processor to Intel; Intel's had that information for years.
You might recall that back in '98, Intel and Digital were involved in some heavy litigation; the short of was that they had agreed to share certain technologies with each other. Intel took the Alpha designs from Digital, but did not keep up their part of the contract. Digital sued for theft. Eventually, the case was settled out of court. (The link points to a c|net article detailing the settlement.)
So, don't for a second think that Intel hasn't had full access to Alpha chip designs.
I'm glad I'm using 1024bit encryption. They've worked so hard to do 64 bit. But each additional bit is a redoubling in the amount of computing power it's going to take to decrypt my packets. Good luck!
This is a good joke, but misleading to readers that might not know better.
For their sake: SSH uses both public key and private key (or symmetric) cryptography. Public key crypto uses keys with thousands of bits; private key crypto uses keys with hundreds of bits (older algorithms like DES used only 56). RSA, DSA, and so on are examples of public key crypto. RC5, Blowfish, and such are example of private key crypto.
Their key lengths aren't comparable at all. Whether or not RC5 is "secure" at 64 bits has absolutely nothing to do with using 1024 bits in authentication and session key negotiation.
VMS is not similar to DOS on steroids; maybe DCL looks like a DOS interpreter to you, but the underlying operating system is vastly different from that toy program loader called DOS. Calling them similar is just wrong. Besides, very few people have ever seen the aspects of Windows NT that resembled VMS; it most certainly isn't in the command line.
"It's C compiler sucks" You must be joking. DEC is famous for having some of the best compiler gurus; historically, their compilers have always been among the best, both in speed and code generation. Tartan was the only company I recall that could beat DEC on a VAX, and no one's yet matched them for code generation on Alpha. That VMS would somehow ship with inferior compilers doesn't make sense.
"It never overwrites old files..." Many like this feature: by putting those hooks in at the filesystem level, all commands automatically inherit file versioning. When you're certain you don't need the old versions any longer, you can clean up with a single command. And, finally, if you really don't like it, you can turn it off.
"It's memory manager is famous for being fairly slow..." I don't get this one at all. Are you referring to the system pager? Packet lists and non-dynamic pages? Page files? All of these size parameters are well-known (famous?), but more importantly, all can be tweaked via SYSGEN to your heart's delight. Nobody who can read a manual suffers from a slow memory subsystem on their VMS box.
"You can run quite a bit of Unix software on these things just fine..." It would be better to say that you can get POSIX compatibility under VMS. If you write for POSIX, yeah, you could get your code going under VMS. But many Linux/*BSD hackers these days neither know nor care about POSIX (not without good reason, I might add, POSIX.1 was seriously flawed in some respects), so I really have to question "quite a bit".
I don't like to nitpick, but your post does a real disservice to the VMS folks out there. I haven't seriously used VMS since the 4.x days, and am only marginally aware of the current state of OpenVMS, so I'm quite willing to be corrected. But, even older versions of VMS say otherwise about your comments.
(My apologies for the repost... wasn't logged in... argh!)
The performance difference between an optimal fortran program and an optimal C program I'd argue is nearly nil. Show me different, and explain why. Go on, try it.
Pointer aliasing.
The effort required to generate the "optimal" C/C++ program working with matrices or greater multidimensional arrays is nontrivially higher than the effort needed in FORTRAN.
Look, I'm not pro-FORTRAN. But credit where credit's due, people. C/C++ compilers worry about things that FORTRAN compilers don't, mostly because of the semantics of multidimensional arrays in each language (one should say the lack of multidimensional array semantics in C/C++). Why do you think Blitz is such a hit? Why do you think so many compilers have all sorts of non-standard ways of letting the user indicate that there's no aliasing on a given pointer in memory (remember noalias? what about those ugly restrict and unlikely_alias hacks?)?
You can make your number-crunching C/C++ code as fast as the FORTRAN folks' code, but it typically requires knowing more about your language tools than the aforementioned FORTRAN programmer worries about.
So, give them the nod on this one. You've got them beat on any number of other fronts.
Very true; it's commonly believed that the way that DES withstood differential encryption shows that the NSA knew about that technique in the '70s.
Also interesting, though, is the evidence that the NSA didn't know about linear cryptanalysis; DES was weakened quite a bit more under that method of attack.
That's not to insult IBM or the NSA; you can't predict what sort of an attack people are going to throw at you two decades in the future. That it stood up as well as it did is a monstrously huge accomplishment.
I'm just fascinated how we can deduce what the NSA knew and didn't know so many years ago, by judging how well things withstand attacks today.
Many of the more negative comments I'm seeing seem to be missing one or two points about the Forth programming environment (we call it that since it's more than just a language).
Since he lacks feature xxx his ideas aren't relevant: Many of the comments in this regard seem to stem from an assumption that unless a programming environment includes support for multiple protected users, protected memory, protected devices, protective APIs, and so on, it cannot be a relevant environment. What I'd like some of you to consider is that, on the contrary, there are many more programming applications which simply don't require those mechanisms. Sure, they're great to have, when you need them. Your microwave doesn't require multiuser support; your watch doesn't require protected memory; set-top boxes don't require CORBA bindings; CCD firmware doesn't; engine management, FedEx barcode scanners, and so on. The list is nearly infinite, and can extend all the way up to your desktop, if you want. Certainly, we all know many many environments where those tools help us get our work done, but that doesn't invalidate the environments where they aren't needed. Think beyond your desktop; every CPU in the world doesn't have to be running Netscape. Implement what you need or want, throw the rest away.
Progamming isn't for everyone: Some of you are turning this into a real strawman. Come on, you don't really believe Chuck is dissing someone who wants to program but has a challenge (such as blindness), do you? Re-reading the interview should show you that he has an interest in other representations of programming environments (other than text based ones). Furthermore, Chuck himself has poor eyesight. Thus, he's created his own programming environment that uses very large characters and uses color to replace punctuation, thus saving him precious screen real estate. If anything, you'd see he embodies the attitude, "Change the system to match your wants." I believe with a little thought that it should be obvious that he isn't seeking to exclude people with different abilities.
Slashdot Mirror
Indeed; SIRTF will be great in the short term, but for real longevity (including upgrades to the instrumentation as technology advances), it's going to be hard to beat SOFIA. The ability to service and upgrade a facility is what kept HST useful for so long. With SOFIA, we're effectively dealing with an observatory that lands every day. By comparison with space based observatories, improving and upgrading SOFIA will be a snap!
It's not so much that you're missing something, as it is that you've turned the problem around. :-)
Wind and distribution will be good. Movement will be good. Accurate location information isn't that far off, and then you'll want things to move around so as to better map out an area. For example, when something like this is deployed in water to provide ground truth for some airborne sensor, you count on drift and movement to spread over the target area.
If only, VLSI, Digital and later Intel would have allocated a few of their resources to reving [ARM] up...
Umm... wasn't Digital was a part of the team that developed StrongARM?
HP has had to sell nothing about the Alpha processor to Intel; Intel's had that information for years.
You might recall that back in '98, Intel and Digital were involved in some heavy litigation; the short of was that they had agreed to share certain technologies with each other. Intel took the Alpha designs from Digital, but did not keep up their part of the contract. Digital sued for theft. Eventually, the case was settled out of court. (The link points to a c|net article detailing the settlement.)
So, don't for a second think that Intel hasn't had full access to Alpha chip designs.
I'm glad I'm using 1024bit encryption. They've worked so hard to do 64 bit. But each additional bit is a redoubling in the amount of computing power it's going to take to decrypt my packets. Good luck!
This is a good joke, but misleading to readers that might not know better.
For their sake: SSH uses both public key and private key (or symmetric) cryptography. Public key crypto uses keys with thousands of bits; private key crypto uses keys with hundreds of bits (older algorithms like DES used only 56). RSA, DSA, and so on are examples of public key crypto. RC5, Blowfish, and such are example of private key crypto.
Their key lengths aren't comparable at all. Whether or not RC5 is "secure" at 64 bits has absolutely nothing to do with using 1024 bits in authentication and session key negotiation.
Umm... in a word, "no".
VMS is not similar to DOS on steroids; maybe DCL looks like a DOS interpreter to you, but the underlying operating system is vastly different from that toy program loader called DOS. Calling them similar is just wrong. Besides, very few people have ever seen the aspects of Windows NT that resembled VMS; it most certainly isn't in the command line.
"It's C compiler sucks" You must be joking. DEC is famous for having some of the best compiler gurus; historically, their compilers have always been among the best, both in speed and code generation. Tartan was the only company I recall that could beat DEC on a VAX, and no one's yet matched them for code generation on Alpha. That VMS would somehow ship with inferior compilers doesn't make sense.
"It never overwrites old files..." Many like this feature: by putting those hooks in at the filesystem level, all commands automatically inherit file versioning. When you're certain you don't need the old versions any longer, you can clean up with a single command. And, finally, if you really don't like it, you can turn it off.
"It's memory manager is famous for being fairly slow..." I don't get this one at all. Are you referring to the system pager? Packet lists and non-dynamic pages? Page files? All of these size parameters are well-known (famous?), but more importantly, all can be tweaked via SYSGEN to your heart's delight. Nobody who can read a manual suffers from a slow memory subsystem on their VMS box.
"You can run quite a bit of Unix software on these things just fine..." It would be better to say that you can get POSIX compatibility under VMS. If you write for POSIX, yeah, you could get your code going under VMS. But many Linux/*BSD hackers these days neither know nor care about POSIX (not without good reason, I might add, POSIX.1 was seriously flawed in some respects), so I really have to question "quite a bit".
I don't like to nitpick, but your post does a real disservice to the VMS folks out there. I haven't seriously used VMS since the 4.x days, and am only marginally aware of the current state of OpenVMS, so I'm quite willing to be corrected. But, even older versions of VMS say otherwise about your comments.
(My apologies for the repost... wasn't logged in... argh!)
The performance difference between an optimal fortran program and an optimal C program I'd argue is nearly nil. Show me different, and explain why. Go on, try it.
Pointer aliasing.
The effort required to generate the "optimal" C/C++ program working with matrices or greater multidimensional arrays is nontrivially higher than the effort needed in FORTRAN.
Look, I'm not pro-FORTRAN. But credit where credit's due, people. C/C++ compilers worry about things that FORTRAN compilers don't, mostly because of the semantics of multidimensional arrays in each language (one should say the lack of multidimensional array semantics in C/C++). Why do you think Blitz is such a hit? Why do you think so many compilers have all sorts of non-standard ways of letting the user indicate that there's no aliasing on a given pointer in memory (remember noalias? what about those ugly restrict and unlikely_alias hacks?)?
You can make your number-crunching C/C++ code as fast as the FORTRAN folks' code, but it typically requires knowing more about your language tools than the aforementioned FORTRAN programmer worries about.
So, give them the nod on this one. You've got them beat on any number of other fronts.
Very true; it's commonly believed that the way that DES withstood differential encryption shows that the NSA knew about that technique in the '70s.
Also interesting, though, is the evidence that the NSA didn't know about linear cryptanalysis; DES was weakened quite a bit more under that method of attack.
That's not to insult IBM or the NSA; you can't predict what sort of an attack people are going to throw at you two decades in the future. That it stood up as well as it did is a monstrously huge accomplishment.
I'm just fascinated how we can deduce what the NSA knew and didn't know so many years ago, by judging how well things withstand attacks today.
Many of the more negative comments I'm seeing seem to be missing one or two points about the Forth programming environment (we call it that since it's more than just a language).
Since he lacks feature xxx his ideas aren't relevant: Many of the comments in this regard seem to stem from an assumption that unless a programming environment includes support for multiple protected users, protected memory, protected devices, protective APIs, and so on, it cannot be a relevant environment. What I'd like some of you to consider is that, on the contrary, there are many more programming applications which simply don't require those mechanisms. Sure, they're great to have, when you need them. Your microwave doesn't require multiuser support; your watch doesn't require protected memory; set-top boxes don't require CORBA bindings; CCD firmware doesn't; engine management, FedEx barcode scanners, and so on. The list is nearly infinite, and can extend all the way up to your desktop, if you want. Certainly, we all know many many environments where those tools help us get our work done, but that doesn't invalidate the environments where they aren't needed. Think beyond your desktop; every CPU in the world doesn't have to be running Netscape. Implement what you need or want, throw the rest away.
Progamming isn't for everyone: Some of you are turning this into a real strawman. Come on, you don't really believe Chuck is dissing someone who wants to program but has a challenge (such as blindness), do you? Re-reading the interview should show you that he has an interest in other representations of programming environments (other than text based ones). Furthermore, Chuck himself has poor eyesight. Thus, he's created his own programming environment that uses very large characters and uses color to replace punctuation, thus saving him precious screen real estate. If anything, you'd see he embodies the attitude, "Change the system to match your wants." I believe with a little thought that it should be obvious that he isn't seeking to exclude people with different abilities.
// boba