"predetermined, randomly varying"--this doesn't make much sense. "Since the string is set on the server and is varying randomly, it is very difficult for B to calculate the string dynamically at runtime in the length of time allotted"--nor does this. The main delay will be network latency, as most hash functions are *very* fast and some special optimizations are possible that can probably compute Hash([modified client binary]|[Random string]) where | denotes concatenation in around 850 cycles (this is a back of the envelope calculation).
Re:Why is LISP superior?
on
RMS The Coder
·
· Score: 1
Arguably, since LISP, Perl, C, Basic, and about every other language in use today is Turing complete, no language is more powerful than any other, since all computable tasks can be done with any.;-)
To quote for the advisory: OpenSSL OpenSSL with RSAREF is not vulnerable. OpenBSD / OpenSSH and following the subsequent link to the OpenBSD page: "A buffer overflow in the RSAREF code included in the USA version of the libssl package (called sslUSA, is possibly exploitable in httpd, ssh, or isakmpd, if SSL/RSA features are enabled or used. NOTE: International users using the ssl26 package are not affected."
Honestly, the search engine is pretty poor in quality right now. It seems to have only indexed a small proportion of publicly accessable web pages. BUT, to paraphrase on another poster's idea, the open-source nature of the project can be profitably combined the whole Beowulf cluster and distributed computing concepts such that a far greater number of web sites could be indexed than previously possible. Moreover, with distributed spidering, more in-depth analysis can be run on the text contained in the pages. However, I do see 3 major problems with this:
-The bandwidth that most users have is not commiserate with their processing capability -The index might become stale if a site is not visited repeatedly, but in the distributed spidering case, this risks either duplication of work or gaps where nobody visited the pages in a large web site -The ability to rank pages based on "relevance" or "linkability" (ala Google) is decreased in this scenario
This is even a worse violation of civil liberties than the plan to install cameras to locate known criminals based on facial recognition. To quote the referenced article "Once connected to such intelligent systems, closed- circuit television (CCTV) will shift from being a mainly passive device for gathering evidence after a crime, to a tool for crime prevention. But not everyone welcomes the prospect. The technology would ensure that every security screen is closely watched, though not by human eyes. It would bring with it a host of sinister possibilities and fuel people's fears over privacy."
The issue is not about privacy, so much as the essential presumption of innocence that underlies our jurisprudence. To use this technology to prevent crimes before they occur appears to be a noble goal, but as in so many other situations, we must consider the costs of such an action. The ends of reducing crime or preventing suicide cannot justify or be reconciled with this trend toward proactively indentifying "troublesome" elements (as with the tests meant to locate potentially unstable students). From proactive location to preventive detention is but a small step on a slipperly slope away from the assumption of innocence to the assumption of guilt. What will occur next? Will there be facial emotion detectors that will sense discontent and alert authorities? It troubles me that so many people are willing to give up their freedom in exchange for the illusion of greater apparent security.
The fundemental principle underlying instant messaging schemes is identical to that underlying office productivity software. The software is *inherently* worthless and becomes worthwhile if and only if there is a critical mass of people who use it. Once the population using a particular incompatible with anything else software reaches this level, new users will tend to use this service as well, establishing a de facto standard that other providers must comply with if they want to reach the majority of users. Treat this as flamebait if you will, but I do not believe that establishing Yet Another Standard for Instant Messaging is the solution to these problems. As long as users have the freedom to switch from service to service, as they do now, the relative popularity of each service will fluctuate with respect to it's utility to the user. The real issue is not whether standards are neccesary (they aren't at this point and won't be beneficial until the technology matures) but whether companies have the right to use the networks of other companies. As I see it, creating artificial boundaries splinters the community and benefits nobody, neither the company that does the restriction, nor anybody else benefits. With bandwidth availability skyrocketing and new communications technologies being developed almost daily, does it truly make any sense to lock in an IM standard that will be obselete practically as it is approved? I would much rather have a de facto standard that is flexible than a rigid actual standard.
More precisely the language that someday will become C9x is being defined by the ISO/IEC JTC1/SC22/WG14 committee whose Final Committee Draft standard can be found at http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n84 3.htm. I don't know the equivalent specification for C++. The important thing to note is that these define the C/C++ *language*, not a standard operating environment.
This will hurt Java in the short-term since it will be more difficult to develope code that will be portable to [the now non-existent] Java 2 standardized platform. However, I don't think that this will negatively affect the Java language itself in the long run. Java as a language will live or die on its own merits, of which I believe that it has many. It is a type-safe language built from the ground up to support OOP. For thirty years, C has withstood the test of time despite not _ever_ having a standard platform; the same assessment applies to C++ as well. A careful programmer can exploit the benefits of the language while mantaining portability and efficiency using the same methods that he/she have always used. Sun's decision will probably help Java in the end because of this.
Ross Anderson and a team of other researchers wrote a white paper entitled "On The Limits of Steganography" published in the IEEE Journal on Selected Areas in Communications Special Issue on Copyright & Privacy Protection, vol. 16 no. 4, pp 474-481, May 1998 (it's available online at http://www.cl.cam.ac.uk/~rja14/ ) that deals with the issue of robustness of watermarks and other forms of information hiding. The overall conclusions are that: -Robustness decreases proportionally with the square of the information contained -Watermarks can almost always be either distorted beyond recognition (if the information content is high) or removed (if the information content is lwo) using a simple sequence of transformations, ranging from smearing spectral power peaks to scaling the image -It's almost always possible to determine that watermarks or steganography was used because the entropy of the bits affected is most probably higher than that of the surrounding message.
[yes, it's bad form to reply to your own comment] I also meant to add that the market system upon which the existence of CoSource is predicated is less than optimally efficient in the case of externalities, whether positive or negative, such as that presented by open-source software. The free market cannot acheive maximal allocative efficiency because the cost of the goods produced and the cost for producing the goods does not neccesarily correlate with the benefits and/or hinderances obtained by purchasing the product.
I think that the model for developement that CoSource can become a very viable template for *small-scale* open-source projects. It's really great for bringing together users who want a specific application built and developers who can receive financial compensation for their work, as well as contributing the code back to the public by open-sourcing it. The economics of open source software in general can be fairly accurately modeled as a "public good", or to use economic jargon, a product with zero marginal production cost. Much like building a dam or interstate highway system, developing software takes a great deal of work; at the same time, once the product becomes open source, people who did not directly pay to have the product constructed can still use it. Now this is a good thing, as it wouldn't make sense to restrict use of a public good when the ammount is practically unlimited.
CoSource allows people who have a pressing need for a product to explicitly finance the construction of the good, while benefiting every other use of open-source software at the same time. As good as this is, I can't help but think that CoSource is not neccesarily the best model for large-scale distributed developement of an application over a long period of time for the following reasons:
-The model does not faciliate interaction between developers in a public forum (as in a mailing list or newsgroup) -There is no official or centralized location for users to report bugs to -There is no method for coordinating the work of different groups that could potentially be working on similar projects -Oversight is limited in that I don't see any real mechanism to *force* a recalcitrant developer to fix a problem -The model does not facilitate the dialogue between users and developers that is particularly helpful in refining an open-source project -The model implicitly precludes long-term projects (ie. we met the objective to the letter, and now let's get our money and stop)
I don't think that CoSource can work for something like Apache or Mozilla, but it does have a lot of potential for less ambitious projects, such as a mail client or an addition to existing open-source software.
Slashdot Mirror
"predetermined, randomly varying"--this doesn't make much sense.
"Since the string is set on the server and is varying randomly, it is very difficult for B to calculate the string dynamically at runtime in the length of time allotted"--nor does this. The main delay will be network latency, as most hash functions are *very* fast and some special optimizations are possible that can probably compute Hash([modified client binary]|[Random string]) where | denotes concatenation in around 850 cycles (this is a back of the envelope calculation).
Arguably, since LISP, Perl, C, Basic, and about every other language in use today is Turing complete, no language is more powerful than any other, since all computable tasks can be done with any. ;-)
To quote for the advisory:
OpenSSL
OpenSSL with RSAREF is not vulnerable.
OpenBSD / OpenSSH
and following the subsequent link to the OpenBSD page:
"A buffer overflow in the RSAREF code included in the USA version of the libssl package (called sslUSA, is possibly exploitable in httpd, ssh, or isakmpd, if SSL/RSA features are enabled or used. NOTE: International users using the ssl26 package are not affected."
--
Flames? Think I'm a karma whore?
Honestly, the search engine is pretty poor in quality right now. It seems to have only indexed a small proportion of publicly accessable web pages. BUT, to paraphrase on another poster's idea, the open-source nature of the project can be profitably combined the whole Beowulf cluster and distributed computing concepts such that a far greater number of web sites could be indexed than previously possible. Moreover, with distributed spidering, more in-depth analysis can be run on the text contained in the pages. However, I do see 3 major problems with this:
-The bandwidth that most users have is not commiserate with their processing capability
-The index might become stale if a site is not visited repeatedly, but in the distributed spidering case, this risks either duplication of work or gaps where nobody visited the pages in a large web site
-The ability to rank pages based on "relevance" or "linkability" (ala Google) is decreased in this scenario
--
Flames? Think I'm a karma whore?
This is even a worse violation of civil liberties than the plan to install cameras to locate known criminals based on facial recognition. To quote the referenced article "Once connected to such intelligent systems, closed- circuit television (CCTV) will shift from being a mainly passive device for gathering evidence after a crime, to a tool for crime prevention. But not everyone welcomes the prospect. The technology would ensure that every security screen is closely watched, though not by human eyes. It would bring with it a host of sinister possibilities and fuel people's fears over privacy."
The issue is not about privacy, so much as the essential presumption of innocence that underlies our jurisprudence. To use this technology to prevent crimes before they occur appears to be a noble goal, but as in so many other situations, we must consider the costs of such an action. The ends of reducing crime or preventing suicide cannot justify or be reconciled with this trend toward proactively indentifying "troublesome" elements (as with the tests meant to locate potentially unstable students).
From proactive location to preventive detention is but a small step on a slipperly slope away from the assumption of innocence to the assumption of guilt. What will occur next? Will there be facial emotion detectors that will sense discontent and alert authorities? It troubles me that so many people are willing to give up their freedom in exchange for the illusion of greater apparent security.
--
Flames? Think I'm a karma whore?
The fundemental principle underlying instant messaging schemes is identical to that underlying office productivity software. The software is *inherently* worthless and becomes worthwhile if and only if there is a critical mass of people who use it. Once the population using a particular incompatible with anything else software reaches this level, new users will tend to use this service as well, establishing a de facto standard that other providers must comply with if they want to reach the majority of users.
Treat this as flamebait if you will, but I do not believe that establishing Yet Another Standard for Instant Messaging is the solution to these problems. As long as users have the freedom to switch from service to service, as they do now, the relative popularity of each service will fluctuate with respect to it's utility to the user. The real issue is not whether standards are neccesary (they aren't at this point and won't be beneficial until the technology matures) but whether companies have the right to use the networks of other companies. As I see it, creating artificial boundaries splinters the community and benefits nobody, neither the company that does the restriction, nor anybody else benefits. With bandwidth availability skyrocketing and new communications technologies being developed almost daily, does it truly make any sense to lock in an IM standard that will be obselete practically as it is approved? I would much rather have a de facto standard that is flexible than a rigid actual standard.
--
Flames? Think I'm a karma whore?
More precisely the language that someday will become C9x is being defined by the ISO/IEC JTC1/SC22/WG14 committee whose Final Committee Draft standard can be found at http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n84 3.htm. I don't know the equivalent specification for C++. The important thing to note is that these define the C/C++ *language*, not a standard operating environment.
--
Flames? Think I'm a karma whore?
"ground up" refers to Java not having been evolved from a previous non-OO language like the transition from C to C++ with all the cruft that entailed.
--
Flames? Think I'm a karma whore?
This will hurt Java in the short-term since it will be more difficult to develope code that will be portable to [the now non-existent] Java 2 standardized platform. However, I don't think that this will negatively affect the Java language itself in the long run. Java as a language will live or die on its own merits, of which I believe that it has many. It is a type-safe language built from the ground up to support OOP. For thirty years, C has withstood the test of time despite not _ever_ having a standard platform; the same assessment applies to C++ as well. A careful programmer can exploit the benefits of the language while mantaining portability and efficiency using the same methods that he/she have always used. Sun's decision will probably help Java in the end because of this.
--
Flames? Think I'm a karma whore?
Ross Anderson and a team of other researchers wrote a white paper entitled "On The Limits of Steganography" published in the IEEE Journal on Selected Areas in Communications Special Issue on Copyright & Privacy Protection, vol. 16 no. 4, pp 474-481, May 1998 (it's available online at http://www.cl.cam.ac.uk/~rja14/ ) that deals with the issue of robustness of watermarks and other forms of information hiding. The overall conclusions are that:
-Robustness decreases proportionally with the square of the information contained
-Watermarks can almost always be either distorted beyond recognition (if the information content is high) or removed (if the information content is lwo) using a simple sequence of transformations, ranging from smearing spectral power peaks to scaling the image
-It's almost always possible to determine that watermarks or steganography was used because the entropy of the bits affected is most probably higher than that of the surrounding message.
--
Flames? Think I'm a karma whore?
[yes, it's bad form to reply to your own comment]
I also meant to add that the market system upon which the existence of CoSource is predicated is less than optimally efficient in the case of externalities, whether positive or negative, such as that presented by open-source software. The free market cannot acheive maximal allocative efficiency because the cost of the goods produced and the cost for producing the goods does not neccesarily correlate with the benefits and/or hinderances obtained by purchasing the product.
--
Flames? Think I'm a karma whore?
I think that the model for developement that CoSource can become a very viable template for *small-scale* open-source projects. It's really great for bringing together users who want a specific application built and developers who can receive financial compensation for their work, as well as contributing the code back to the public by open-sourcing it.
The economics of open source software in general can be fairly accurately modeled as a "public good", or to use economic jargon, a product with zero marginal production cost. Much like building a dam or interstate highway system, developing software takes a great deal of work; at the same time, once the product becomes open source, people who did not directly pay to have the product constructed can still use it. Now this is a good thing, as it wouldn't make sense to restrict use of a public good when the ammount is practically unlimited.
CoSource allows people who have a pressing need for a product to explicitly finance the construction of the good, while benefiting every other use of open-source software at the same time. As good as this is, I can't help but think that CoSource is not neccesarily the best model for large-scale distributed developement of an application over a long period of time for the following reasons:
-The model does not faciliate interaction between developers in a public forum (as in a mailing list or newsgroup)
-There is no official or centralized location for users to report bugs to
-There is no method for coordinating the work of different groups that could potentially be working on similar projects
-Oversight is limited in that I don't see any real mechanism to *force* a recalcitrant developer to fix a problem
-The model does not facilitate the dialogue between users and developers that is particularly helpful in refining an open-source project
-The model implicitly precludes long-term projects (ie. we met the objective to the letter, and now let's get our money and stop)
I don't think that CoSource can work for something like Apache or Mozilla, but it does have a lot of potential for less ambitious projects, such as a mail client or an addition to existing open-source software.
--
Flames? Think I'm a karma whore?