Seagate has announced a laptop disk that does full disc encryption in hardware, without slowing down disc I/O at all. Seems like that makes software solutions (which are subject to reverse engineering, etc.) decidedly inferior.
According to this article in EETimes and this press release by Fujitsu, they have been producing their version ("FRAM") in volume since late 1999, and should be churning out 128KB parts even as we speak.
The cool part is that it works by wiggling atoms around in the crystal structure:
external electric field shifts Zr/Ti atoms in crystal to move away from electric neutrality
And don't forget the metadata! This aspect of.NET may prove more useful in the long run than the common runtime. After all, how many languages are ever really successful? But the ability (and requirement!) to package dependency information with the dependent code means some possibility of a reasonable, non-ad hoc (sorry OS X, but...) solution to DLL hell.
More to the point is that polarization is preserved. Polarization is the primary quantity which is "quantum entalgled" in most current efforts at quantum cryptography, so preserving it is of the utmost importance in making quantum crypto a reality in the near future.
Uh, yeah, sorry that wasn't clear. I'm one of the few people I know to program in both Algol 60 and Algol 68, the latter being my favorite procedural language. Not to mention the tastefully erudite von Wijngaarden two-level grammer used in the Algol 68 spec!
That's two different computer gods with that "ij" thing in their names. Hmmm...
Whoops, hit Submit instead of Preview before I was done. Anyway, here's most of the rest:
So, why did procedural languages win? I think it was really just a case of not adequately optimizing otu tail recursion in Pascal compilers. In the early days of the explosion of computer science, everybody learned Pascal, and if your recursion got too deep, the stack blew, so you were taught to think of recursion as an exotic technique to handle special problems. Of course, when it got around to establishing loop invariants so that iterative code could be proved correct, it was like pulling teeth, but who tried proving his programs correct, anyway?
And it probably didn't help that Edsger Dijkstra was the Goto Considered Harmful man, since everybody knew those Europeans didn't really know how to program real programs! Just look at Algol, compared to real languages like COBOL or FORTRAN for crissakes!
I guess my bottom line is that the prevalance of procedural programming over functional programming was sort of a cultural brain fart, a malignant meme which established itself as part of the global memone before anyone had a chance to fight it.
I have used functional languages since the 70s. I put together a more-or-less complete implementation of Backus' FP in Rosetta Smalltalk running on a Z-80 (64K RAM, CP/M OS) around 1980, programmed in Interlisp until '87, bogged down trying to implement Common Lisp (which can be procedural or not, your choice) in Windows 3.1 (got just about done, then Steele brought out version 2 -- ugh!) about 1992. Currently I just write one-liners in Perl. What happened?
Mostly, there were no implementations. Plus it's sort of like the Micro$oft dominance -- all the good stuff was written in procedural languages (primarily C/C++), so why fight it? But the real question is why did procedural languages win?
What I don't believe is that it is harder or less natural to think functionally than procedurally. It's just what one is taught.
Like recursion, for instance. In my small experience teaching, I saw the light go on with regularity -- you just chip away at the problem, deal with some part of it, and then (recursively!) deal with the remaining simpler problem. Hmm, that doesn't seem so hard.
Most people don't think about transactional database programming as being like FP, but just think about it -- it's just like Backus' Applicative State Transitions, where one computes the proposed new state, validates it so far as possible, and then installs it as the basis for more computation.
Another thing to think about is the long-standing tradition in math of "recurrence" relations, like the Fibonnaci series, or approximations to pi, or whatever. Those are clear examples of things which could be thought of as iterative or recursive, just depending on the color of the lightbulb.
Buried in one of the NSA's patents is the interesting note
The National Security Agency (NSA) specification for data erasures require that the file be written over seven times using an alternating byte write sequence of: 00, FF, 00, FF, 00, FF, F6. Normal commercially available Disk CleanUp erasures simply write the F6 character to deleted files.
The article doesn't address something which interests me. Aren't the copyrights on some of these games, especially the old arcade ones, about to expire? And, if there is no one willing to fork out the cash to renew them, that puts them in public domain, right?
Of course, overclockers in suits (the only kind that can afford a 2**N CPU AlphaServer) are a tad on the strange side....
But according to the Official Compaq Spec the 21264b can toot along at 940 MHz if you can cool the heat sink enough to keep the Operating Temperature at Heat Sink Center down to 83.8C.
So just a little push and you should have GHz 64-bit processors, scads of them!
Now this probably isn't the sort of thing you had in mind, but...
The last time AI was la mode, which was about 15-20 years ago, one of the computational walls AI hit was in computer vision. So, 10 Moore's Law cycles later,...
If a Web page knew you had a camera pointed at yourself, could it watch? As in, see what you're looking at, where you point (forget those mouses!), what you spend time reading?
When the Alto (the first personal computer) was invented at Xerox PARC (around 1974, I think) they tested lots of "pointing" devices with users. The programmers were favoring a "chord" device which had five electric organ keys, so that you could "chord" any of 31 different combinations. Imagine trying to convince users to memorize those!
The winners in the ease-of-use-with-real-users competition were the mouse and the trackball, with the mouse just slightly favored. You see the results of those tests today, where scratch-and-sniff pads, which work like flat trackballs, are common on laptops.
Those same programmers took over the Lisp Machine world in the eighties, which is why the Symbolics Lips machine had Shift-, Ctrl-, Meta- and Hyper- keys. I recall that at MIT Meta-Hyper-E (some combination involving E, anyway) would call the very slow elevator up to the AI Lab floor. Considerably more useful than a Web client in your refrigerator, IMO.
And what _was_ XEROX up to when Jobs & Co. came to visit?
When I visited PARC in the early eighties, the screens were still B/W and in portrait configuration. The Altos and 1100 series machines were mostly running Smalltalk-80 or Interlisp, both of which were pretty standard (for today) windowing systems: menu bars, pop-up right-button menus, etc. They were developing the icon interface which became the failed Lisa design, and were also programming in Mesa. Interlisp, Smalltalk and Mesa all had programming UIs similar to M$ofts Visual line.
The company I worked for (Schlumberger) took a flying leap at the Xerox Lisp machines. For a couple of years I programmed on 1132s (the Dorado, a $130,000 personal computer!) and 1100s (Dolphin) 1108/1109s (Dandelion). We were doing oil well log analysis; my bit was doing the graphics, scrolling the logs, picking features with mouse clicks, linking to the rest of the AI system.
I really don't know what the legally sanctioned "fair use" percentage is, so I can't say whether those messages which quoted Microsoft's spec addendum (the "PAC") exceeded that threshold. Seems likely they didn't, however.
The whole discussion has missed an important point, IMO. Just what is the nature of the extension? Exactly what incompatibility is introduced? My point being, if we discuss (in prose, not code) what Microsoft's extension does, we do not violate their copyright! Remember, copyright covers expression of ideas, not ideas themselves. This is the priciple whereby Phoenix was able to create a non-IBM BIOS, Gus Van Zant was able to remake Hitchcock's Psycho, etc.
So all we need here is enough detailed description of the ideas in the PAC that some industrious Linux coder who has never read Microsoft's document can code it up himself. Then the storm passes: no trade secrets remain, no copyrights violated, no one left on base.
Mostly that it is "consistent." That means, "it doesn't surprise me by not doing what I think it ought to, or by doing something I don't want it to." The interesting fact is, users get used to almost any kind of trash, so long as it doesn't startle them. I think that means some kind of contract on the part of the UI designer. One bit of the MS world worth preserving is COM (the original concept, not the COM+ metastatis), where interfaces are (1) simple, i.e. networkable and (2) immutable. An underemphasized part of a COM Interface is the "contract" part: what the interface needs and guarantees. That can't change, either! I think most users would rejoice if Version N+1 of MegaWidget just gave them the option of using the Version N UI they have managed to internalize. Of course, the Keep It Simple part is important, too. Running your UI past 3-5 uninitiated users should make that prescription pretty clear.
Slashdot Mirror
Seagate has announced a laptop disk that does full disc encryption in hardware, without slowing down disc I/O at all. Seems like that makes software solutions (which are subject to reverse engineering, etc.) decidedly inferior.
According to the NASA odds table, and the Torino scale rating 4, not 2, for that April 13, 2029 impact. Worrisome.
I think we should bomb the Sun in retaliation.
Nuke it 'til it glows.
The cool part is that it works by wiggling atoms around in the crystal structure:
And don't forget the metadata! This aspect of .NET may prove more useful in the long run than the common runtime. After all, how many languages are ever really successful? But the ability (and requirement!) to package dependency information with the dependent code means some possibility of a reasonable, non-ad hoc (sorry OS X, but ...) solution to DLL hell.
More to the point is that polarization is preserved. Polarization is the primary quantity which is "quantum entalgled" in most current efforts at quantum cryptography, so preserving it is of the utmost importance in making quantum crypto a reality in the near future.
That's two different computer gods with that "ij" thing in their names. Hmmm...
So, why did procedural languages win? I think it was really just a case of not adequately optimizing otu tail recursion in Pascal compilers. In the early days of the explosion of computer science, everybody learned Pascal, and if your recursion got too deep, the stack blew, so you were taught to think of recursion as an exotic technique to handle special problems. Of course, when it got around to establishing loop invariants so that iterative code could be proved correct, it was like pulling teeth, but who tried proving his programs correct, anyway?
And it probably didn't help that Edsger Dijkstra was the Goto Considered Harmful man, since everybody knew those Europeans didn't really know how to program real programs! Just look at Algol, compared to real languages like COBOL or FORTRAN for crissakes!
I guess my bottom line is that the prevalance of procedural programming over functional programming was sort of a cultural brain fart, a malignant meme which established itself as part of the global memone before anyone had a chance to fight it.
Mostly, there were no implementations. Plus it's sort of like the Micro$oft dominance -- all the good stuff was written in procedural languages (primarily C/C++), so why fight it? But the real question is why did procedural languages win?
What I don't believe is that it is harder or less natural to think functionally than procedurally. It's just what one is taught.
Like recursion, for instance. In my small experience teaching, I saw the light go on with regularity -- you just chip away at the problem, deal with some part of it, and then (recursively!) deal with the remaining simpler problem. Hmm, that doesn't seem so hard.
Most people don't think about transactional database programming as being like FP, but just think about it -- it's just like Backus' Applicative State Transitions, where one computes the proposed new state, validates it so far as possible, and then installs it as the basis for more computation.
Another thing to think about is the long-standing tradition in math of "recurrence" relations, like the Fibonnaci series, or approximations to pi, or whatever. Those are clear examples of things which could be thought of as iterative or recursive, just depending on the color of the lightbulb.
Hmm ... 240x320=76800 total visible pixels ... how many colors do you need?!
Check out Warren Robinett's description of his implementation of the first Atari game in about 4K, code, data, all in!
The article doesn't address something which interests me. Aren't the copyrights on some of these games, especially the old arcade ones, about to expire? And, if there is no one willing to fork out the cash to renew them, that puts them in public domain, right?
But according to the Official Compaq Spec the 21264b can toot along at 940 MHz if you can cool the heat sink enough to keep the Operating Temperature at Heat Sink Center down to 83.8C.
So just a little push and you should have GHz 64-bit processors, scads of them!
The last time AI was la mode, which was about 15-20 years ago, one of the computational walls AI hit was in computer vision. So, 10 Moore's Law cycles later, ...
If a Web page knew you had a camera pointed at yourself, could it watch? As in, see what you're looking at, where you point (forget those mouses!), what you spend time reading?
So instead of "Big Brother is watching you!" we'd have Tim Berners-Lee is watching you!"
When the Alto (the first personal computer) was invented at Xerox PARC (around 1974, I think) they tested lots of "pointing" devices with users. The programmers were favoring a "chord" device which had five electric organ keys, so that you could "chord" any of 31 different combinations. Imagine trying to convince users to memorize those!
The winners in the ease-of-use-with-real-users competition were the mouse and the trackball, with the mouse just slightly favored. You see the results of those tests today, where scratch-and-sniff pads, which work like flat trackballs, are common on laptops.
Those same programmers took over the Lisp Machine world in the eighties, which is why the Symbolics Lips machine had Shift-, Ctrl-, Meta- and Hyper- keys. I recall that at MIT Meta-Hyper-E (some combination involving E, anyway) would call the very slow elevator up to the AI Lab floor. Considerably more useful than a Web client in your refrigerator, IMO.
When I visited PARC in the early eighties, the screens were still B/W and in portrait configuration. The Altos and 1100 series machines were mostly running Smalltalk-80 or Interlisp, both of which were pretty standard (for today) windowing systems: menu bars, pop-up right-button menus, etc. They were developing the icon interface which became the failed Lisa design, and were also programming in Mesa. Interlisp, Smalltalk and Mesa all had programming UIs similar to M$ofts Visual line.
The company I worked for (Schlumberger) took a flying leap at the Xerox Lisp machines. For a couple of years I programmed on 1132s (the Dorado, a $130,000 personal computer!) and 1100s (Dolphin) 1108/1109s (Dandelion). We were doing oil well log analysis; my bit was doing the graphics, scrolling the logs, picking features with mouse clicks, linking to the rest of the AI system.
So I think all this makes me feel very old ...
The whole discussion has missed an important point, IMO. Just what is the nature of the extension? Exactly what incompatibility is introduced? My point being, if we discuss (in prose, not code) what Microsoft's extension does, we do not violate their copyright! Remember, copyright covers expression of ideas, not ideas themselves. This is the priciple whereby Phoenix was able to create a non-IBM BIOS, Gus Van Zant was able to remake Hitchcock's Psycho, etc.
So all we need here is enough detailed description of the ideas in the PAC that some industrious Linux coder who has never read Microsoft's document can code it up himself. Then the storm passes: no trade secrets remain, no copyrights violated, no one left on base.
Mostly that it is "consistent." That means, "it doesn't surprise me by not doing what I think it ought to, or by doing something I don't want it to." The interesting fact is, users get used to almost any kind of trash, so long as it doesn't startle them. I think that means some kind of contract on the part of the UI designer. One bit of the MS world worth preserving is COM (the original concept, not the COM+ metastatis), where interfaces are (1) simple, i.e. networkable and (2) immutable. An underemphasized part of a COM Interface is the "contract" part: what the interface needs and guarantees. That can't change, either! I think most users would rejoice if Version N+1 of MegaWidget just gave them the option of using the Version N UI they have managed to internalize. Of course, the Keep It Simple part is important, too. Running your UI past 3-5 uninitiated users should make that prescription pretty clear.