You can be sure that the original arcade versions were written in assembly language not that different from what you see here. As a rule, nobody wrote video games in C until the mid 1980s. Assembly language was king.
I worked at a game software developer in the late 1980s, and all of the 2600 games, all of the 7800 games, all of the C-64 games, all of the Atari 800 games we developed or ported during the period were written in native assembly language. Only the Amiga, Atari ST, Macintosh, and the later PC games were written in C. NES and SuperNES games were written in assembly as well.
SQL injection is universally due to a web development problem. The others you mention are either system administration or development problems as well. If you have someone injecting arbitrary SQL, script injection is the least of your problems.
I agree that if you employ lots of inexperienced developers who can't follow documented security practices or have no higher level code reviews, and you are working on a new application, this might be worth it despite the enormous performance penalties and development difficulties.
Normal applications format all text as HTML on generation - script injections are impossible. The *only* people who have a problem are those who display arbitrary user submitted HTML without validation. And how many applications do that? Web logs?
It is not "just a tag" - it is a header that enables a mandatory restriction on inline scripts in addition to selective restrictions on other elements. And if you have incompetent web developers for a public facing site, you are likely to have much more serious problems than unfiltered user content.
One of the serious problems with this is many applications dynamically generate javascript on the fly. The only way to handle that under this specification would be to generate lots of little temporary files that the browser requests on the second pass. Besides the bizarre devlopment style this requires, the performance problem with such secondary requests is a serious problem, due to turnaround latency.
Speaking of which, HTTP should be extended to allow web servers to push expected inline requests for script files, images, and frames (up to a reasonable limit and under reasonable constraints) into the web browser in-memory cache to eliminate the turnaround latency associated with such follow on requests. i.e. the browser in such cases would be able to fulfil such requests immediately from the cache because they would already be there by the time the web browser had finished parsing the page. [Note: portions of this posted as AC below]
This proposal looks like massive overkill to me. Implementing the restriction on inline script tags is equivalent to saying - our web developers are incompetent and naive and cannot be trusted to take basic security measures, so we feel making our web development practices more cumbersome and inefficient (if not impossible) is a healthy trade off.
A more effective program would be to develop and promote standardized html sanitization routines for popular web development languages, so that user entered html could easily be accepted under certain restrictions. Most web logs do this already.
Alternatively a less draconian solution would be to allow inline scripts to execute if the script tag includes a response specific serialization value that is also present in the HTTP headers. 64 bit values would make forging a inline script essentially impossible, because there would only be a 1/2^64 probability of a subsequent accidental match.
The regular line voltage makes little more than a tingle when you hold the bare ends in your hands. However, if the phone rings (90-120 VAC, enough to power a mechanical ringer) it is rather a different story. Learned that the hard way. Never tried the tongue thing though.
Also, don't accidentally hook up wall outlet power to your Amiga +12V power output. The consequences are not pretty...
I hesitate to break it to you, but *the* distinguishing characteristic of Marxism is the advocacy of the *violent* overthrow of the bourgoisie. Marx would be a footnote in history if he did not advocate that course of action and have half the world take him up on it.
I never took any vocational education classes, because I was self taught in basic carpentry, electronics, circuit design, wiring, and so on. But it would have been much more difficult to acquire many of those skills growing up in a small urban apartment or in a pristine and untouchable house. The arguments for providing preparatory vocational education for such students in particular is compelling. Sometimes we graduate electrical engineers who have never soldered a connection in their life. I never thought about the problem because I started soldering many years prior.
The main thing that I think would be helpful, however, is to take the depth of preparatory vocational educational classes up a notch, so there is a greater balance between academic and hands on content. They should more closely resemble practical pre-engineering classes, so that eventual 2 year vocational school graduates leave having skills preparing them for work as independent designers and craftsmen not just entry level apprentices. Legal, regulatory, and business issues should be included.
There are a number of other factors that have a greater effect on U.S. per capita GDP than employment in white collar service industries. In particular U.S. legal and economic institutions are far more mature and stable than in most third world countries - in particular the property rights and contract enforcement necessary to make long term private investment possible.
That said, I think it is amusing that you picked finance and law rather than engineering and technology as examples given the ridiculous excesses in both of the latter fields as of late. During the last boom Wall Street was making 40% of all corporate profits in the United States. Think there is even the remotest justification for that kind of imbalance?
Such grammar understates how formal and regularized the Japanese feudal system was. These were formal government maps.
In addition, no one needs a map to discriminate on the basis of race - the map is controversial because it expedites discovering a likely lower class heritage that would otherwise be lost to history. The equivalent in the U.S. would be discrimination against whites based on birth or heritage in rural and undeveloped areas of the South, or to a lesser degree what is often termed "flyover country".
Oracle and Ingres were serious competitors about 25 years ago. However, Oracle quickly adopted a significantly better design that put Ingres-like databases (Ingres, Informix, Illustra, the original Postgres, etc.) virtually out of business.
Not only that, the internal MVCC architecture of PostgreSQL is *much* closer to Oracle than any of the other Ingres derivatives - including Postgres itself. The original Ingres hit the wall in large part due to the lack of multiversion concurrency control and row level locking (among many other things). In other words, it was practically useless for running large transactions concurrent with other activity, an area where Oracle shines.
Page level locking and no MVCC means that writers block readers (and other writers) until the first transaction to lock the page commits. Page level locking means that which rows will be incidentally locked up by a transaction is essentially random.
Such databases worked well if you were read mostly, and ran small quick transactions during the day, and large long running transactions in appropriately scheduled batch jobs at night. Unfortunately, technologically speaking, MySQL is about to catch up to where Ingres was just prior to entering its terminal decline twenty years ago. The InnoDB engine is the only major exception. Of course people typically use MySQL for rather different applications than they use Oracle for, and MySQL is radically less expensive.
Assuming your std::vector implementation doesn't slow your compile times down by a factor of ten and your run times by a factor of three, of course. The last time I tried GCC's C++ library, admittedly several years ago, things like basic_string were abysmally slow - so I wrote my own copy-on-write string library and have used it ever since. Perhaps the state of C++ standard library implementations has improved since then, but I have a twenty year history of writing my own class libraries that run circles around anything I have ever seen an out-of-the-box C++ standard library do.
In my experience the world would be better off without the C++ standard library at all. In practice it is major step backward, to be avoided at all costs, a primary reason why C++ is relatively unpopular for general purpose programming, and so on.
"The legitimate, if somewhat carebearish, reason they do that, whether they know it or not, is that if someone reasonably believes you're offering legal advice, and she follows your advice and loses some legal right or money, she can sue you for legal malpractice"
If that is the precedent, it ought to be changed. The rational rule is the same as contract law - if there is a contract (money changes hands etc.) then liability for faulty advice is created. Otherwise what is to prevent half of the world for suing the other half of the world for bad medical, dietary, parenting, car maintenance, gardening, etc advice?
Suppose I write a blog and say that this homeopathic remedy works really well and everyone should try it. Someone tries it and suffers an allergic reaction, or loses her money or whatever. Can they recover from the blogger for bad medical advice if no money changed hands?
The idea that one should have to put a disclaimer on any opinion about anything in any subject that might have any real world consequences regardless of nature of the relationship is the one of the most ridiculous ideas ever devised. It is for practices (and precedents) like that lawyers are rightly ridiculed as parasites on productive society.
Hardly. ZFS and btrfs use a copy on write design that is decidely non-optimal for database usage. Both work best when files are completely rewritten or only appended to. Partial writes to files cause them to get fragmented. This problem is severe enough that btrfs at least is planning special options so that the performance of large databases doesn't go downhill. How they plan on integrating that with a copy on write design is an interesting question.
Any inductor with sufficiently high impedance at such a low frequency would almost certainly cost *far* more and be significantly larger than the equivalent resistor setup. If the connection point was a line designed to carry 60 Hz an inductor would be the only way to go, however here the connection point is a neutral, so an inductor that filters out 60 Hz signals is overkill.
I believe that a copyright case would likely be decided differently. Copyright licenses have radically different characteristics than licenses to use real property. Open source licenses, for example, are adopted with the intent that people create derivative works. If the license necessary to distribute those derivatives may become null and void at any time, no one would ever create them. Most courts tend to be rather pragmatic about that sort of thing. If a rational legal defense of the irrevocability of GPL type licenses can be made, I suspect most courts would be inclined to adopt it. On the other hand, if you are right, at some point the only viable open source "license" will be *public domain*.
If someone creates a significant business infrastructure around an open source software package that has no viable replacement, and in particular makes a significant investment in enhancing it, a revocation contrary to the license's own terms is a perfect setup for the doctrine of promissory estoppel to be applied.
"Certain elements must be established to invoke promissory estoppel. A promisor--one who makes a promise--makes a gratuitous promise that he should reasonably have expected to induce action or forbearance of a definite and substantial character on the part of the promisee--one to whom a promise has been made. The promisee justifiably relies on the promise. A substantial detriment--that is, an economic loss--ensues to the promisee from action or forbearance. Injustice can be avoided only by enforcing the promise.
A majority of courts apply the doctrine to any situation in which all of these elements are present. A minority, however, still restrict its applicability to one or more specific situations from which the doctrine emanated, such as when a donor promises to transfer real property as a gift and the donee spends money on the property in reliance on the promise." (West's Encyclopedia of American Law, 2008)
I say "all the more so" in the case of copyright licenses, because unlike a gratuitous license to cross one's real property, a gratuitous copyright license does not create an ongoing economic or physical burden on the part of the licensor. The very reason software is licensed under such terms in the first place (in most cases) is to get an economic benefit from the enhancements of others to the same software package.
"A similar basis is to be found for the doctrine of an early Pennsylvania decision, which held that a license, in terms permanent, to divert a watercourse, could not be revoke after the licensee had made improvements and invested capital in consequence of it. This decision has been followed by other cases holding that a license cannot be revoked in violation of its terms after the licensee has seriously changed his position on the faith of it." (Samuel Willston, The Law of Contracts, 1920)
The Pennsylvania case is "Rerick v. Kern, 14 S & R 267".
Even when (as is usually the case), a license is revocable at common law contrary to its terms, the doctrine of promissory estoppel may allow the license to be enforce in equity.
i.e. "in the law of contracts, the doctrine that provides that if a party changes his or her position substantially either by acting or forbearing from acting in reliance upon a gratuitous promise, then that party can enforce the promise although the essential elements of a contract are not present." (West Encyclopedia of American Law, 2008)
Just because a license is considered technically "revocable" at law contrary to its own terms does not mean it won't be enforced. A copyright license all the more so.
The problem is that "gratuitous license" is a somewhat ambiguous term. If you have a citation for a case where a copyright license was held to be revocable contrary to its own text, please post.
SQL*Plus needs some improvements, definitely. If you want a small (4GB) database, you can just install Oracle Express RPM and it will run immediately. Otherwise, unless you have a critical application, just choose "default database install" and the Oracle installer will do almost everything for you. I haven't created a database using anything other than the Oracle database installer (or RPM as of late) for more than a decade. Then I add new tablespaces after the fact, if necessary.
A competent Oracle DBA could easily maintain hundreds of Oracle database servers, so I don't know what you are talking about there. Small shops only really need a DBA for custom development (database design), if that. Oracle is a very straightforward database to develop for and administer if you stick to the basics. The actual pain level of developing a serious application for MySQL instead of Oracle is much worse. Oracle's only serious downside is that it is rather expensive. Oracle Express removes that argument for small (4GB) databases, however.
Slashdot Mirror
You can be sure that the original arcade versions were written in assembly language not that different from what you see here. As a rule, nobody wrote video games in C until the mid 1980s. Assembly language was king.
I worked at a game software developer in the late 1980s, and all of the 2600 games, all of the 7800 games, all of the C-64 games, all of the Atari 800 games we developed or ported during the period were written in native assembly language. Only the Amiga, Atari ST, Macintosh, and the later PC games were written in C. NES and SuperNES games were written in assembly as well.
DEC (now Oracle) RDB is an SQL database. A pretty nice one, actually.
SQL injection is universally due to a web development problem. The others you mention are either system administration or development problems as well. If you have someone injecting arbitrary SQL, script injection is the least of your problems.
I agree that if you employ lots of inexperienced developers who can't follow documented security practices or have no higher level code reviews, and you are working on a new application, this might be worth it despite the enormous performance penalties and development difficulties.
Normal applications format all text as HTML on generation - script injections are impossible. The *only* people who have a problem are those who display arbitrary user submitted HTML without validation. And how many applications do that? Web logs?
That is the problem - a mandatory restriction that amounts to "we don't trust the html generated from our own domain".
It is not "just a tag" - it is a header that enables a mandatory restriction on inline scripts in addition to selective restrictions on other elements. And if you have incompetent web developers for a public facing site, you are likely to have much more serious problems than unfiltered user content.
One of the serious problems with this is many applications dynamically generate javascript on the fly. The only way to handle that under this specification would be to generate lots of little temporary files that the browser requests on the second pass. Besides the bizarre devlopment style this requires, the performance problem with such secondary requests is a serious problem, due to turnaround latency.
Speaking of which, HTTP should be extended to allow web servers to push expected inline requests for script files, images, and frames (up to a reasonable limit and under reasonable constraints) into the web browser in-memory cache to eliminate the turnaround latency associated with such follow on requests. i.e. the browser in such cases would be able to fulfil such requests immediately from the cache because they would already be there by the time the web browser had finished parsing the page. [Note: portions of this posted as AC below]
This proposal looks like massive overkill to me. Implementing the restriction on inline script tags is equivalent to saying - our web developers are incompetent and naive and cannot be trusted to take basic security measures, so we feel making our web development practices more cumbersome and inefficient (if not impossible) is a healthy trade off.
A more effective program would be to develop and promote standardized html sanitization routines for popular web development languages, so that user entered html could easily be accepted under certain restrictions. Most web logs do this already.
Alternatively a less draconian solution would be to allow inline scripts to execute if the script tag includes a response specific serialization value that is also present in the HTTP headers. 64 bit values would make forging a inline script essentially impossible, because there would only be a 1/2^64 probability of a subsequent accidental match.
The regular line voltage makes little more than a tingle when you hold the bare ends in your hands. However, if the phone rings (90-120 VAC, enough to power a mechanical ringer) it is rather a different story. Learned that the hard way. Never tried the tongue thing though.
Also, don't accidentally hook up wall outlet power to your Amiga +12V power output. The consequences are not pretty...
I hesitate to break it to you, but *the* distinguishing characteristic of Marxism is the advocacy of the *violent* overthrow of the bourgoisie. Marx would be a footnote in history if he did not advocate that course of action and have half the world take him up on it.
I never took any vocational education classes, because I was self taught in basic carpentry, electronics, circuit design, wiring, and so on. But it would have been much more difficult to acquire many of those skills growing up in a small urban apartment or in a pristine and untouchable house. The arguments for providing preparatory vocational education for such students in particular is compelling. Sometimes we graduate electrical engineers who have never soldered a connection in their life. I never thought about the problem because I started soldering many years prior.
The main thing that I think would be helpful, however, is to take the depth of preparatory vocational educational classes up a notch, so there is a greater balance between academic and hands on content. They should more closely resemble practical pre-engineering classes, so that eventual 2 year vocational school graduates leave having skills preparing them for work as independent designers and craftsmen not just entry level apprentices. Legal, regulatory, and business issues should be included.
There are a number of other factors that have a greater effect on U.S. per capita GDP than employment in white collar service industries. In particular U.S. legal and economic institutions are far more mature and stable than in most third world countries - in particular the property rights and contract enforcement necessary to make long term private investment possible.
That said, I think it is amusing that you picked finance and law rather than engineering and technology as examples given the ridiculous excesses in both of the latter fields as of late. During the last boom Wall Street was making 40% of all corporate profits in the United States. Think there is even the remotest justification for that kind of imbalance?
Such grammar understates how formal and regularized the Japanese feudal system was. These were formal government maps.
In addition, no one needs a map to discriminate on the basis of race - the map is controversial because it expedites discovering a likely lower class heritage that would otherwise be lost to history. The equivalent in the U.S. would be discrimination against whites based on birth or heritage in rural and undeveloped areas of the South, or to a lesser degree what is often termed "flyover country".
In the contemporary world, "discrimination" is short hand for what was once known as "unjustified discrimination".
Oracle and Ingres were serious competitors about 25 years ago. However, Oracle quickly adopted a significantly better design that put Ingres-like databases (Ingres, Informix, Illustra, the original Postgres, etc.) virtually out of business.
Not only that, the internal MVCC architecture of PostgreSQL is *much* closer to Oracle than any of the other Ingres derivatives - including Postgres itself. The original Ingres hit the wall in large part due to the lack of multiversion concurrency control and row level locking (among many other things). In other words, it was practically useless for running large transactions concurrent with other activity, an area where Oracle shines.
Page level locking and no MVCC means that writers block readers (and other writers) until the first transaction to lock the page commits. Page level locking means that which rows will be incidentally locked up by a transaction is essentially random.
Such databases worked well if you were read mostly, and ran small quick transactions during the day, and large long running transactions in appropriately scheduled batch jobs at night. Unfortunately, technologically speaking, MySQL is about to catch up to where Ingres was just prior to entering its terminal decline twenty years ago. The InnoDB engine is the only major exception. Of course people typically use MySQL for rather different applications than they use Oracle for, and MySQL is radically less expensive.
Assuming your std::vector implementation doesn't slow your compile times down by a factor of ten and your run times by a factor of three, of course. The last time I tried GCC's C++ library, admittedly several years ago, things like basic_string were abysmally slow - so I wrote my own copy-on-write string library and have used it ever since. Perhaps the state of C++ standard library implementations has improved since then, but I have a twenty year history of writing my own class libraries that run circles around anything I have ever seen an out-of-the-box C++ standard library do.
In my experience the world would be better off without the C++ standard library at all. In practice it is major step backward, to be avoided at all costs, a primary reason why C++ is relatively unpopular for general purpose programming, and so on.
Killing a branch through nutrition would be quite a feat. Want some fries with that?
"The legitimate, if somewhat carebearish, reason they do that, whether they know it or not, is that if someone reasonably believes you're offering legal advice, and she follows your advice and loses some legal right or money, she can sue you for legal malpractice"
If that is the precedent, it ought to be changed. The rational rule is the same as contract law - if there is a contract (money changes hands etc.) then liability for faulty advice is created. Otherwise what is to prevent half of the world for suing the other half of the world for bad medical, dietary, parenting, car maintenance, gardening, etc advice?
Suppose I write a blog and say that this homeopathic remedy works really well and everyone should try it. Someone tries it and suffers an allergic reaction, or loses her money or whatever. Can they recover from the blogger for bad medical advice if no money changed hands?
The idea that one should have to put a disclaimer on any opinion about anything in any subject that might have any real world consequences regardless of nature of the relationship is the one of the most ridiculous ideas ever devised. It is for practices (and precedents) like that lawyers are rightly ridiculed as parasites on productive society.
I take a hammer to all my old drives...who wants a five year old drive anyways?
Hardly. ZFS and btrfs use a copy on write design that is decidely non-optimal for database usage. Both work best when files are completely rewritten or only appended to. Partial writes to files cause them to get fragmented. This problem is severe enough that btrfs at least is planning special options so that the performance of large databases doesn't go downhill. How they plan on integrating that with a copy on write design is an interesting question.
Apparently, the opposite of what you want too...
Any inductor with sufficiently high impedance at such a low frequency would almost certainly cost *far* more and be significantly larger than the equivalent resistor setup. If the connection point was a line designed to carry 60 Hz an inductor would be the only way to go, however here the connection point is a neutral, so an inductor that filters out 60 Hz signals is overkill.
I believe that a copyright case would likely be decided differently. Copyright licenses have radically different characteristics than licenses to use real property. Open source licenses, for example, are adopted with the intent that people create derivative works. If the license necessary to distribute those derivatives may become null and void at any time, no one would ever create them. Most courts tend to be rather pragmatic about that sort of thing. If a rational legal defense of the irrevocability of GPL type licenses can be made, I suspect most courts would be inclined to adopt it. On the other hand, if you are right, at some point the only viable open source "license" will be *public domain*.
If someone creates a significant business infrastructure around an open source software package that has no viable replacement, and in particular makes a significant investment in enhancing it, a revocation contrary to the license's own terms is a perfect setup for the doctrine of promissory estoppel to be applied.
"Certain elements must be established to invoke promissory estoppel. A promisor--one who makes a promise--makes a gratuitous promise that he should reasonably have expected to induce action or forbearance of a definite and substantial character on the part of the promisee--one to whom a promise has been made. The promisee justifiably relies on the promise. A substantial detriment--that is, an economic loss--ensues to the promisee from action or forbearance. Injustice can be avoided only by enforcing the promise.
A majority of courts apply the doctrine to any situation in which all of these elements are present. A minority, however, still restrict its applicability to one or more specific situations from which the doctrine emanated, such as when a donor promises to transfer real property as a gift and the donee spends money on the property in reliance on the promise." (West's Encyclopedia of American Law, 2008)
I say "all the more so" in the case of copyright licenses, because unlike a gratuitous license to cross one's real property, a gratuitous copyright license does not create an ongoing economic or physical burden on the part of the licensor. The very reason software is licensed under such terms in the first place (in most cases) is to get an economic benefit from the enhancements of others to the same software package.
"A similar basis is to be found for the doctrine of an early Pennsylvania decision, which held that a license, in terms permanent, to divert a watercourse, could not be revoke after the licensee had made improvements and invested capital in consequence of it. This decision has been followed by other cases holding that a license cannot be revoked in violation of its terms after the licensee has seriously changed his position on the faith of it." (Samuel Willston, The Law of Contracts, 1920)
The Pennsylvania case is "Rerick v. Kern, 14 S & R 267".
Even when (as is usually the case), a license is revocable at common law contrary to its terms, the doctrine of promissory estoppel may allow the license to be enforce in equity.
i.e. "in the law of contracts, the doctrine that provides that if a party changes his or her position substantially either by acting or forbearing from acting in reliance upon a gratuitous promise, then that party can enforce the promise although the essential elements of a contract are not present." (West Encyclopedia of American Law, 2008)
Just because a license is considered technically "revocable" at law contrary to its own terms does not mean it won't be enforced. A copyright license all the more so.
The problem is that "gratuitous license" is a somewhat ambiguous term. If you have a citation for a case where a copyright license was held to be revocable contrary to its own text, please post.
SQL*Plus needs some improvements, definitely. If you want a small (4GB) database, you can just install Oracle Express RPM and it will run immediately. Otherwise, unless you have a critical application, just choose "default database install" and the Oracle installer will do almost everything for you. I haven't created a database using anything other than the Oracle database installer (or RPM as of late) for more than a decade. Then I add new tablespaces after the fact, if necessary.
A competent Oracle DBA could easily maintain hundreds of Oracle database servers, so I don't know what you are talking about there. Small shops only really need a DBA for custom development (database design), if that. Oracle is a very straightforward database to develop for and administer if you stick to the basics. The actual pain level of developing a serious application for MySQL instead of Oracle is much worse. Oracle's only serious downside is that it is rather expensive. Oracle Express removes that argument for small (4GB) databases, however.