To quote Tom's Hardware Guide: "While the code also includes an early look at the new user-interface design, the majority of end-user features in Windows Vista will not be included until Beta 2."
So it's not even feature-complete, and this is a wide beta? Beta's are supposed to be feature and code complete and frozen; the purpose of beta being to find last minute interaction with customer setups.
It would be more honest to call it "preview" or something.
If you think about it, houses like that *could* be built but then anyone buying such a house will sue and (almost certainly) win. Consumers have a certain level of expectation and it is backed by law as well as market force; so architects and builders meet that expection.
Software can be built that shoddy way, but we (the techies of the world) also know how to build software better. It is just that the current expection of software is different. Consumers get the level of quality they demand.
Until either the law, or the market, or both changes to a new expectation, the quality will not go up.
This is basically a good idea (as others have pointed out).
Note that this goodness is totally dependent on who controlls your computer. If you stay in control, then things are good (at least in theory it will be your fault if you give away the info). With things like "Trusted Computing", this can turn into a really bad idea really fast. Think about it, if Microsoft controls what programs can run you computer, they control everything. If Bill doesn't like someone, he tells your computer to refuse to deal. (More accurately, he tells his program to refuse, and also tells your computer to refuse to run any other program).
Also, think about the privacy issues - any program that is signed by Microsoft will be able to rummage through all your stuff. Do you trust Microsoft (or anyone) to have that power and never make any mistake?
Note that what cryptographers consider a "break" is not necessarily the same as what users consider a break. (Neither is more strict, they are just different criteria for different people).
In this case, the researchers from Shandong University (supposedly) reduced the work required to find a collision from 2**80 to 2**69; this is a major cryptographic result. It is major because SHA-1, as a "cryptographically strong hash", is not supposed to have any attacks better then random. A factor of 2**11 reduction shows SHA-1 to be very far from ideal; and since lots of clever people have tried to show this, the research team should be proud.
Does this mean the bad-guy-of-your-choice can now start forging digital contracts? Not yet - there is no guarantee that the collision will be meaningful (as least their earlier papers didn't show that result). For a forgery to be useful, the forger needs to make the fake message say something useful - may be change the $1 to $1 million, or change the name, or something. A collision at a random place (or a non-sensical string) is essentially useless as a forgery (there may be some interested DOS attacks, but I am talking about outright forgery which is the point of the hash functions).
And lastly, 2**69 (roughly 10**21) is still a big number! Assume that some clever people wrote a super-duper hand-optimized code that does a whole SHA-1 in a micro-second on a late model 4 Ghz PC, that is 10**6 hashes/sec. A grad-student using all the PC's on a campus, say ten thousand, that's another 10**4. This would take 10**11 seconds (or roughly 20K years). Note that for SHA-0, their break is 2**39 operations, which *is* practical - it would take the grad student only a minute, or a single PC a week.
This break is yet *practical* for *most* people. (Would I still use SHA-1? Not in new application, and I make sure that existing applications get changed over eventually.)
Lest I be accused of ignoring the big boys, the equation changes for them. If a Three Letter Agency is willing to invest a lot of money and design some cool chips that has awsome parallelism and everything, then each break may take only a week. For example, assume these chips has a bunch of pipes that can do a hash every nano-second (or 10**9 hash/second). Further, say there are 100 of these pipes per chip, 100 chips per board, 100 board per rack (or 10**6 pipes/rack). Each rack can then do 10**15 hash/sec, With such a magical rack, it would take 10**6 seconds (or just under two weeks) to find a collision. This would cost Some Real Dollars, but is it within the budget of some three letter agency? You bet. Hack, I would be willing to sell you one for under a billion dollar US. On the other hand, for that kind of money, cryptanalysis takes on different textures - why spend a billion to crack SHA-1 when you can buy the right wet-ware unit for a million?
Of course, the Amiga 1000 was twice the chroma carrier. My nurons are mis-firing.
I worked on the BLink linker with a 512K dual floppy machine. I could run (micro)emacs. These days, just starting X needs more; and then you have to add on the actual GUI. Heck, there is probably more CPU and memory on a low-end harddisk.
In the old days, things were done with only a few cycles:
Apple II (1 MHz 6502) did animated graphics with sound and controlled floppy access while polling the keyboard (The Bard's Tale)
Amiga (14 MHz 68000) had complete GUI, multi-tasking, on 256K RAM.
The old saying that "Intel giveth, Microsoft taketh" is about right. The CPU's have gotten faster, with the Microsoft O/S taking more and more cycles to do the same thing.
In theory, it may be possible for someone to hide some trap-door function that allows some un-authorized access.
Before lecturing me on the "many-eyes" theory of code inspection, recall that some cases take a LOT of work to decided. In fact, many people are probably familiar with a famous instance of this problem - DES. For a quarter-century, the debate has raged on whether NSA selected the S-Boxes to have an unknown weakness, AKA private back-door. Many clever cryptographers have spent many man-years and there is still no conclusive statement. (I happen to agree with the majority view that there is probably no such weakness but I wouldn't bet my life on it.)
So, the question is: can someone put in a bunch of clever code in appearantly unrelated places that happens to create a security hole? Emperically, this happens accidentally quite often (just go through the CERT security advisories for examples) so it is at least possible that someone could deliberately put one in.
There is no theoretical reason nor practical experience to say that "many-eyes" will catch all of these traps (even if we assume there are many eyes actually looking). Indeed, even concerted detailed code-inspection may not find them all.
Having raised this question, I like to state that I believe that this is most likely a theoretical concern as long as there are "owners" of each piece of code who pay long-term attention to their charges and that we can assume the owners are not colluding. This first condition pretty much eliminates any "simple" holes that are localised in a single component, the second condition makes it very difficult to have multi-component holes. Forturnately, most open-source software, including Linux, meet these conditions; so I am not too worried.
Is it right for national agencies to be worried? Of course they should! But it is also relatively easy to just have their own "shadow owner" for each module. So it is possible for the agencies to gain confidence at low cost (not cheap, just low cost relatively speaking).
You actually think OEM's pay Microsoft $1 per machine? And you actually think Microsoft has $61 billion in cash by collecting $1 per machine?
The WSJ numbers are OEM quantity numbers. MSRP for Windows is a lot higher (same for all the other components as well). It is true that Microsoft will massively discount for their friends; but $45 is the DISCOUNTED price.
I have often wanted the same thing, kind of like RAID on files, call it RARF (Redundant Array of Remote Files). I was thinking along the line of a device driver that presents an ATA/IDE interface to the file system on one side and passes the requests to multiple copies of virtual disks. The virtual disks would be like VMWare disks, and potentially each on a different machine/location. Each virtual disk could even be encrypted differently.
This would be really useful for SOHO type places to allow me to have a hot offsite backup at multiple friends (and vise versa).
If you look at the news release, Verisign is being paid US$100 million (in cash plus debt). They bought NSI in March 200 for $21 billion (in stock).
The most intersting thing is that Verisign may actually be profiting from this deal!!!
The $21 billion is stock priced at around $200 each (according to my guess from Yahoo stock chart), so they gave out 10 million shares. Currently VRSN shares are about $15, so they are getting 2/3 of the purchase price back. But they are only selling the "public facing" side of NSI, the actual registry backbone still belongs to VRSN.
So, overall, I would say VRSN did well on this deal. Amazing how stock markets work.
If you do a detailed business-case, I think you will find that Microsoft should be willing to charge nothing.
Recall that if Microsoft loses the account, they get ZERO dollars. On the other hand, per-license cost (to Microsoft) is essentially ZERO as well. So whatever they can charge is extra profit. All of the talk of slush fund to pay for the discount is just accounting wool to pull over people's eyes (and may be keep bonuses straight).
Also, if you look at the Market Share or Network Effect, that also argues for "do not lose". Indeed, as Microsoft (and other companies) has demonstrated, it is often worthwhile to pay a customer to take it.
Even then, they understood that bugs should be published openly. To quote section 1.3.1 "Concealment of such penetrations does nothing to deter a sophisticated penetrator and can in fact impede technical interchange and delay the development of a proper solutions. A system which contains nulnerabilities cannot be protected by keeping those vulnerabilities secret. It can only be protected by the constraining (sic) of physical access to the system."
New Scientist also has an article on this, see http://www.newscientist.com/news/news.jsp?id= ns999 92628
The MSNBC report is misleading - the measurement (by satellites)is of gravity, but the conclusion is about the shape of the planet. The prime suspect, currently, is ocean currents.
It seems to me LSM (Linux Security Module) is the former SELinux (Security Enhanced Linux) from NSA. The LIDS (Linux IDS) is totally independent. The news is that LSM has been accepted into the development kernel tree.
Let me start by saying that I have nothing to do with the company - I only heard of them this morning.
The claims are quite bold, so it is natural to be skeptical. Someone provided a link to their patents page http://www.borealis.com/technology/patents.shtml which has a lot of issued patents. If this is a scam, then at minimum they started it a few years ago and probably poured over a million dollars into patent fees.
I picked two patents at random, one is by Avto Tavkhelidze of High Energy Physics Institue in Tbilisi in Georgia. Another is by Isaiah Cox of England, which was first applied for in 1996. At a very quick glance, these patents are not nutty crank patents.
Do I think this is real? May be the science works, or may be it does not; but that's just one of their worries. Is the production cost low enough, will the thing be robust enough, how easy will it be to install and use.
First of all, let me state that my day job is CTO of Cloakware (as mentioned in the post - the leader in Tamper-Resistant SOftware, along with some other 2-bit companies:-) This is actually jumpping the gun on some announcement that we are about to make (but those will be mostly PR pieces that are of less interest to this audience).
I like to make several points:
- what the "(im)possibility" paper says
- "we all know" does not mean its true
- lots of other published works
- resistance is not an absolute thing
timothy has mis-understood the importance of the "(im)possibility" paper. The breakthrough is that this is the first real theoretical treatment of obfuscation. They show that it is not possible to build a totally automated system that is Really Secure (to vastly over-simplify, they construct program that actively leaks a single bit and then show that no obfuscation program can protect this program against itself). This is really interesting but not directly applicable to what we do - we work with our OEM customers to help design the system, the protocol, the programs so that all the pieces are working together; then we "cloak" the critical pieces. (I spoke to some of the authors before the conference, and many Big Names during Crypto'01; I think it is fair to say that most knowledgable people have this view).
As to the "we all know" truism; it is clearly not true. Real life examples abound - any old, large software system is hard to fix since people don't understand the relations between modules (i.e., the market for reverse-engineering tools). These systems are Tamper-Resistant. The well know IOCC (International Obfuscated C Contest) is another good source of Tamper-Resistant programs. In a manner of speaking, the goal of Cloakware is to achieve this Tamper-Resistance on-demand, for easily maintained code.
The "(im)possiblity" paper is breakthrough on the theory side, but many other people (including us) have published on the practical problems. Some names include Cohen, Collberg, Forest, Wang, Knight. There are many schemes that are reducible to various complexity classes, usually NP-complete and we have one that is PSPACE-hard. All of these papers are correct, there is no conflict.
Lastly, "security" is not binary and has many different attributes. Each application has its unique requirements. For example, diplomatic files are protected for many decades or centuries; a Britney Spear song probably needs only a few months; real-time stock market quotes for 15 minutes. Factors like Usability, Speed, Deployment are often more important than raw security.
Okay, so they (finally) nailed CSFB. How about the other side of that transaction? All those clients that made all those millions - they just live happily after? From the news releases, CSFB was stupid enough to keep records in nice spreadsheets, so it should be easy to identify and fine the clients too.
The cynical view says it won't happen - the brokers like to keep the clients happy.
200 boxes at $3000 is not cheaper than big iron
on
Common Lisp: Inside Sabre
·
· Score: 2, Interesting
Just to point out that this is another case of the mainframe big iron being more cost effective. Take 200 boxes, add networking, admin cost, and the mainframe looks pretty cheap.
Also, ignoring whether Lisp may or may not be better suited for this problem, the algorithms described can be implemented in many languages with. Indeed, many program use all those tricks.
The Yahoo article is fairly content-free (and take a lot of space doing it). Here is the link to the the Weismann Institue abstract. http://www.weizmann.ac.il/math/users/lbn/public_ht ml/new_pages/Abstract.html
Note that the 99.8% is what the abstract calls "Transition Fidelity" and is unclear what it means. I take it to mean that from input to output, the answer as read, is corret 99.8% of the time.
It is interesting that they claim to be implementing a Turing machine. Previous uses of DNA has been mostly for the Travelling Salesman Problem with has a (more or less) natural mapping to DNA.
The original owner of the work can grant multiple licenses, including GPL, SPL, whatever. The GPL is "viral" only in that any work you *get* from GPL stays GPL forever. The original owner is different - they did not *get* from GPL. They have the right to grant any other license. For example, I believe Larry Wall grants the Artistic License for Perl in addition to the GPL.
Botton line, the original owner can do anything, other people are "infected" by the GPL. So any public forks of 4.1.1 (say) will has to stay GPL.
Note that this deal is going for something like
NEGATIVE 50% premium over market price (stock
fell 50%). Also that Be had something like 5
million in cash (as of last quarter). So the Be
management/owner must have been really pessimistic. Palm bought it really cheap.
The article is very misleading. For example, it says MIT researchers built a quantum computer in 1998, which is correct as far as it goes. It would be useful to mention that the computer only have a few bits (4 if I recall correctly). The latest result from Chuang at IBM is a quantum computer with 6 bits running at 300 Hertz (again from my lossy memory). The cheapest el cheapo desktops are over a million times faster (with a million times more memory) than the latest state-of-the-art quantum machine. The current "Next Big Goal" seems to be to factor the integer 6 using Shor's algorithm.
Fans of quantum computing seldom notice that Groover's theorem limits speed-up to AT MOST a
sqrt for a wide class of simultanous-search problems that seems ideal for quantum computers. There are also really challenging problems in the de-coherance time and error-rates.
I would love to see (or even own) a quantum computer, even playing with theory is fun. But
there is no evidence that quantum computing will become more cost-effective for ANY problem, even assuming that someone can actually build a useful one.
also see http://biz.yahoo.com/bw/001129/ca_transme_2.html
It is said to be limited to 300 chips from one specific batch. The problem only happens if there is a reinstall of the O/S. I would assume this is
a limited production bug (as opposed to design
bug).
Since Transmeta stock droped 17%, this is roughly
$1.5 million for each bad chip.
So, Douglas Adam is wrong and the StarTrek movies are right - it is not that we live in "the unfashionable arm of the galaxy"; any visitor needs Warp capability to get through the fungi.
Slashdot Mirror
To quote Tom's Hardware Guide: "While the code also includes an early look at the new user-interface design, the majority of end-user features in Windows Vista will not be included until Beta 2."
So it's not even feature-complete, and this is a wide beta? Beta's are supposed to be feature and code complete and frozen; the purpose of beta being to find last minute interaction with customer setups.
It would be more honest to call it "preview" or something.
If you think about it, houses like that *could* be built but then anyone buying such a house will sue and (almost certainly) win. Consumers have a certain level of expectation and it is backed by law as well as market force; so architects and builders meet that expection.
Software can be built that shoddy way, but we (the techies of the world) also know how to build software better. It is just that the current expection of software is different. Consumers get the level of quality they demand.
Until either the law, or the market, or both changes to a new expectation, the quality will not go up.
This is basically a good idea (as others have pointed out).
Note that this goodness is totally dependent on who controlls your computer. If you stay in control, then things are good (at least in theory it will be your fault if you give away the info). With things like "Trusted Computing", this can turn into a really bad idea really fast. Think about it, if Microsoft controls what programs can run you computer, they control everything. If Bill doesn't like someone, he tells your computer to refuse to deal. (More accurately, he tells his program to refuse, and also tells your computer to refuse to run any other program).
Also, think about the privacy issues - any program that is signed by Microsoft will be able to rummage through all your stuff. Do you trust Microsoft (or anyone) to have that power and never make any mistake?
Note that what cryptographers consider a "break" is not necessarily the same as what users consider a break. (Neither is more strict, they are just different criteria for different people).
In this case, the researchers from Shandong University (supposedly) reduced the work required to find a collision from 2**80 to 2**69; this is a major cryptographic result. It is major because SHA-1, as a "cryptographically strong hash", is not supposed to have any attacks better then random. A factor of 2**11 reduction shows SHA-1 to be very far from ideal; and since lots of clever people have tried to show this, the research team should be proud.
Does this mean the bad-guy-of-your-choice can now start forging digital contracts? Not yet - there is no guarantee that the collision will be meaningful (as least their earlier papers didn't show that result). For a forgery to be useful, the forger needs to make the fake message say something useful - may be change the $1 to $1 million, or change the name, or something. A collision at a random place (or a non-sensical string) is essentially useless as a forgery (there may be some interested DOS attacks, but I am talking about outright forgery which is the point of the hash functions).
And lastly, 2**69 (roughly 10**21) is still a big number! Assume that some clever people wrote a super-duper hand-optimized code that does a whole SHA-1 in a micro-second on a late model 4 Ghz PC, that is 10**6 hashes/sec. A grad-student using all the PC's on a campus, say ten thousand, that's another 10**4. This would take 10**11 seconds (or roughly 20K years). Note that for SHA-0, their break is 2**39 operations, which *is* practical - it would take the grad student only a minute, or a single PC a week.
This break is yet *practical* for *most* people. (Would I still use SHA-1? Not in new application, and I make sure that existing applications get changed over eventually.)
Lest I be accused of ignoring the big boys, the equation changes for them. If a Three Letter Agency is willing to invest a lot of money and design some cool chips that has awsome parallelism and everything, then each break may take only a week. For example, assume these chips has a bunch of pipes that can do a hash every nano-second (or 10**9 hash/second). Further, say there are 100 of these pipes per chip, 100 chips per board, 100 board per rack (or 10**6 pipes/rack). Each rack can then do 10**15 hash/sec, With such a magical rack, it would take 10**6 seconds (or just under two weeks) to find a collision. This would cost Some Real Dollars, but is it within the budget of some three letter agency? You bet. Hack, I would be willing to sell you one for under a billion dollar US. On the other hand, for that kind of money, cryptanalysis takes on different textures - why spend a billion to crack SHA-1 when you can buy the right wet-ware unit for a million?
Of course, the Amiga 1000 was twice the chroma carrier. My nurons are mis-firing.
I worked on the BLink linker with a 512K dual floppy machine. I could run (micro)emacs. These days, just starting X needs more; and then you have to add on the actual GUI. Heck, there is probably more CPU and memory on a low-end harddisk.
Apple II (1 MHz 6502) did animated graphics with sound and controlled floppy access while polling the keyboard (The Bard's Tale)
Amiga (14 MHz 68000) had complete GUI, multi-tasking, on 256K RAM.
The old saying that "Intel giveth, Microsoft taketh" is about right. The CPU's have gotten faster, with the Microsoft O/S taking more and more cycles to do the same thing.
In theory, it may be possible for someone to hide some trap-door function that allows some un-authorized access.
Before lecturing me on the "many-eyes" theory of code inspection, recall that some cases take a LOT of work to decided. In fact, many people are probably familiar with a famous instance of this problem - DES. For a quarter-century, the debate has raged on whether NSA selected the S-Boxes to have an unknown weakness, AKA private back-door. Many clever cryptographers have spent many man-years and there is still no conclusive statement. (I happen to agree with the majority view that there is probably no such weakness but I wouldn't bet my life on it.)
So, the question is: can someone put in a bunch of clever code in appearantly unrelated places that happens to create a security hole? Emperically, this happens accidentally quite often (just go through the CERT security advisories for examples) so it is at least possible that someone could deliberately put one in.
There is no theoretical reason nor practical experience to say that "many-eyes" will catch all of these traps (even if we assume there are many eyes actually looking). Indeed, even concerted detailed code-inspection may not find them all.
Having raised this question, I like to state that I believe that this is most likely a theoretical concern as long as there are "owners" of each piece of code who pay long-term attention to their charges and that we can assume the owners are not colluding. This first condition pretty much eliminates any "simple" holes that are localised in a single component, the second condition makes it very difficult to have multi-component holes. Forturnately, most open-source software, including Linux, meet these conditions; so I am not too worried.
Is it right for national agencies to be worried? Of course they should! But it is also relatively easy to just have their own "shadow owner" for each module. So it is possible for the agencies to gain confidence at low cost (not cheap, just low cost relatively speaking).
You actually think OEM's pay Microsoft $1 per machine? And you actually think Microsoft has $61 billion in cash by collecting $1 per machine?
The WSJ numbers are OEM quantity numbers. MSRP for Windows is a lot higher (same for all the other components as well). It is true that Microsoft will massively discount for their friends; but $45 is the DISCOUNTED price.
I have often wanted the same thing, kind of like RAID on files, call it RARF (Redundant Array of Remote Files). I was thinking along the line of a device driver that presents an ATA/IDE interface to the file system on one side and passes the requests to multiple copies of virtual disks. The virtual disks would be like VMWare disks, and potentially each on a different machine/location. Each virtual disk could even be encrypted differently.
This would be really useful for SOHO type places to allow me to have a hot offsite backup at multiple friends (and vise versa).
If you look at the news release, Verisign is being paid US$100 million (in cash plus debt). They bought NSI in March 200 for $21 billion (in stock).
The most intersting thing is that Verisign may actually be profiting from this deal!!!
The $21 billion is stock priced at around $200 each (according to my guess from Yahoo stock chart), so they gave out 10 million shares. Currently VRSN shares are about $15, so they are getting 2/3 of the purchase price back. But they are only selling the "public facing" side of NSI, the actual registry backbone still belongs to VRSN.
So, overall, I would say VRSN did well on this deal. Amazing how stock markets work.
If you do a detailed business-case, I think you will find that Microsoft should be willing to charge nothing.
Recall that if Microsoft loses the account, they get ZERO dollars. On the other hand, per-license cost (to Microsoft) is essentially ZERO as well. So whatever they can charge is extra profit. All of the talk of slush fund to pay for the discount is just accounting wool to pull over people's eyes (and may be keep bonuses straight).
Also, if you look at the Market Share or Network Effect, that also argues for "do not lose". Indeed, as Microsoft (and other companies) has demonstrated, it is often worthwhile to pay a customer to take it.
Even then, they understood that bugs should be published openly. To quote section 1.3.1 "Concealment of such penetrations does nothing to deter a sophisticated penetrator and can in fact impede technical interchange and delay the development of a proper solutions. A system which contains nulnerabilities cannot be protected by keeping those vulnerabilities secret. It can only be protected by the constraining (sic) of physical access to the system."
New Scientist also has an article on this, see= ns999 92628
http://www.newscientist.com/news/news.jsp?id
The MSNBC report is misleading - the measurement (by satellites)is of gravity, but the conclusion is about the shape of the planet. The prime suspect, currently, is ocean currents.
It seems to me LSM (Linux Security Module) is the former SELinux (Security Enhanced Linux) from NSA. The LIDS (Linux IDS) is totally independent. The news is that LSM has been accepted into the development kernel tree.
Let me start by saying that I have nothing to do with the company - I only heard of them this morning.
The claims are quite bold, so it is natural to be skeptical. Someone provided a link to their patents page http://www.borealis.com/technology/patents.shtml which has a lot of issued patents. If this is a scam, then at minimum they started it a few years ago and probably poured over a million dollars into patent fees.
I picked two patents at random, one is by Avto Tavkhelidze of High Energy Physics Institue in Tbilisi in Georgia. Another is by Isaiah Cox of England, which was first applied for in 1996. At a very quick glance, these patents are not nutty crank patents.
Do I think this is real? May be the science works, or may be it does not; but that's just one of their worries. Is the production cost low enough, will the thing be robust enough, how easy will it be to install and use.
First of all, let me state that my day job is CTO of Cloakware (as mentioned in the post - the leader in Tamper-Resistant SOftware, along with some other 2-bit companies :-) This is actually jumpping the gun on some announcement that we are about to make (but those will be mostly PR pieces that are of less interest to this audience).
I like to make several points:
- what the "(im)possibility" paper says
- "we all know" does not mean its true
- lots of other published works
- resistance is not an absolute thing
timothy has mis-understood the importance of the "(im)possibility" paper. The breakthrough is that this is the first real theoretical treatment of obfuscation. They show that it is not possible to build a totally automated system that is Really Secure (to vastly over-simplify, they construct program that actively leaks a single bit and then show that no obfuscation program can protect this program against itself). This is really interesting but not directly applicable to what we do - we work with our OEM customers to help design the system, the protocol, the programs so that all the pieces are working together; then we "cloak" the critical pieces. (I spoke to some of the authors before the conference, and many Big Names during Crypto'01; I think it is fair to say that most knowledgable people have this view).
As to the "we all know" truism; it is clearly not true. Real life examples abound - any old, large software system is hard to fix since people don't understand the relations between modules (i.e., the market for reverse-engineering tools). These systems are Tamper-Resistant. The well know IOCC (International Obfuscated C Contest) is another good source of Tamper-Resistant programs. In a manner of speaking, the goal of Cloakware is to achieve this Tamper-Resistance on-demand, for easily maintained code.
The "(im)possiblity" paper is breakthrough on the theory side, but many other people (including us) have published on the practical problems. Some names include Cohen, Collberg, Forest, Wang, Knight. There are many schemes that are reducible to various complexity classes, usually NP-complete and we have one that is PSPACE-hard. All of these papers are correct, there is no conflict.
Lastly, "security" is not binary and has many different attributes. Each application has its unique requirements. For example, diplomatic files are protected for many decades or centuries; a Britney Spear song probably needs only a few months; real-time stock market quotes for 15 minutes. Factors like Usability, Speed, Deployment are often more important than raw security.
Okay, so they (finally) nailed CSFB. How about the other side of that transaction? All those clients that made all those millions - they just live happily after? From the news releases, CSFB was stupid enough to keep records in nice spreadsheets, so it should be easy to identify and fine the clients too.
The cynical view says it won't happen - the brokers like to keep the clients happy.
Just to point out that this is another case of the mainframe big iron being more cost effective. Take 200 boxes, add networking, admin cost, and the mainframe looks pretty cheap.
Also, ignoring whether Lisp may or may not be better suited for this problem, the algorithms described can be implemented in many languages with. Indeed, many program use all those tricks.
see http://www.newscientist.com/news/news.jsp?id=ns999 91783
The Yahoo article is fairly content-free (and take a lot of space doing it). Here is the link to the the Weismann Institue abstract. http://www.weizmann.ac.il/math/users/lbn/public_ht ml/new_pages/Abstract.html
Note that the 99.8% is what the abstract calls "Transition Fidelity" and is unclear what it means. I take it to mean that from input to output, the answer as read, is corret 99.8% of the time.
It is interesting that they claim to be implementing a Turing machine. Previous uses of DNA has been mostly for the Travelling Salesman Problem with has a (more or less) natural mapping to DNA.
The original owner of the work can grant multiple licenses, including GPL, SPL, whatever. The GPL is "viral" only in that any work you *get* from GPL stays GPL forever. The original owner is different - they did not *get* from GPL. They have the right to grant any other license. For example, I believe Larry Wall grants the Artistic License for Perl in addition to the GPL.
Botton line, the original owner can do anything, other people are "infected" by the GPL. So any public forks of 4.1.1 (say) will has to stay GPL.
Note that this deal is going for something like NEGATIVE 50% premium over market price (stock fell 50%). Also that Be had something like 5 million in cash (as of last quarter). So the Be management/owner must have been really pessimistic. Palm bought it really cheap.
The article is very misleading. For example, it says MIT researchers built a quantum computer in 1998, which is correct as far as it goes. It would be useful to mention that the computer only have a few bits (4 if I recall correctly). The latest result from Chuang at IBM is a quantum computer with 6 bits running at 300 Hertz (again from my lossy memory). The cheapest el cheapo desktops are over a million times faster (with a million times more memory) than the latest state-of-the-art quantum machine. The current "Next Big Goal" seems to be to factor the integer 6 using Shor's algorithm. Fans of quantum computing seldom notice that Groover's theorem limits speed-up to AT MOST a sqrt for a wide class of simultanous-search problems that seems ideal for quantum computers. There are also really challenging problems in the de-coherance time and error-rates. I would love to see (or even own) a quantum computer, even playing with theory is fun. But there is no evidence that quantum computing will become more cost-effective for ANY problem, even assuming that someone can actually build a useful one.
also see http://biz.yahoo.com/bw/001129/ca_transme_2.html It is said to be limited to 300 chips from one specific batch. The problem only happens if there is a reinstall of the O/S. I would assume this is a limited production bug (as opposed to design bug). Since Transmeta stock droped 17%, this is roughly $1.5 million for each bad chip.
So, Douglas Adam is wrong and the StarTrek movies are right - it is not that we live in "the unfashionable arm of the galaxy"; any visitor needs Warp capability to get through the fungi.