The NSA is responsible for advising the government and critical private-sector infrastructure on how to protect data. If there's a backdoor in an NSA-recommended standard, heads will roll (only figuratively, of course; they use the electric chair). Academic cryptography research is not believed to be too far behind the NSA, and it is reasonable to guess that the Chinese government is about even with the NSA. So a backdoor inserted by the NSA would probably be discovered by the Chinese within a year and academics worldwide within 5 years, at which point terrorists destroy the US economy and wipe out military deployments.
The NSA may not really want our private data to be kept secure, but they do want the banking network to be kept secure. In general, they prefer to get data by finding plaintext or keys on seized equipment, rather than breaking encryption, because anybody can break encryption about equally well, but the government has an advantage in seizing things. That's not to say that they don't insert backdoors in things they don't intend to be secure (like consumer operating systems), particularly in implementations (where the hole can easily involve use of a secret key). But such things don't get this sort of announcement.
Writing Linux device drivers in C# is merely pointless. It causes nowhere near the brain damage that would be caused by trying to maintain the yacc.NET version.
What the code happens to do is quite important; otherwise we wouldn't bother to fix bugs. What we want it to do is also important; otherwise we would be satisfied with programs doing whatever.
On the other hand, we don't really care about what the code used to do but doesn't any more (unless we're trying to figure out when it stopped doing that or how to make it do it again), and we really don't care about what we used to want the code to do but have since decided wasn't such a good idea.
The thing that can be bad about documentation, and especially documentation outside of the code, is that it doesn't automatically stay up to date. The code always documents what the code does now, but the documentation can still be documenting what we no longer want the code to do.
This is a way in which unit tests can be better documentation than plain text documentation; if the unit tests are out of date, the author will probably notice, whereas if the plain text is out of date, the author won't notice for a long time.
These representatives represent their countries, not the people of their countries directly, and they do answer to their governments. That's why the Danish representative is following the demands of the Danish parliament (in fact, a group of opponents of the minority government), which is elected by the Danish people. The fishy thing is that the leading commissioner for the Internal Markets DG is able to keep this from coming to a vote in the Commission by putting a contraversial directive on the list of uncontraversial directives to be accepted without discussion, and can get the president of the Commission to reject the request for restarting from scratch without input from the rest of the Commission.
Blame McCreevy, the leading commissioner for the DG that's doing all this. Also Barroso, somewhat, for deciding to reject the JURI request for starting from scratch based only on McCreevy's input.
Code is never incorrect as far as documenting what the code does. It may be non-functional, broken, or inapplicable, but the closest it can be to incorrect (in this sense) is to be misleading.
I'd guess that they'd do exactly what IBM did, since that seems to have gotten the sort of positive press that they'd want. That is, they will not sue anybody over using the patented processes in a way covered by an OSI-approved license, provided that whoever it is hasn't sued anyone over use of patents in OSI-licensed activities.
It only works for supercomputer clusters only in that, if you connect your computers with infiniband stuff, you might as well start calling them a supercomputer cluster.
Assuming you use the 1-bit fields with "if (field)" or "if (!field)", it doesn't matter if they're signed, except that you'll get a warning (but the desired effect) for "field = 1". Problems come up when you use the value as a larger type, but that's not a good idea for code clarity reasons anyway, when the field semantically stores either a true value or a false value (in the sense that "if" uses). This change is really for getting rid of warnings (and improving maintainability) not fixing bugs.
He's actually been using PPC for about a year now, IIRC; he mentioned on the mailing list that he had switched shortly after, when there were some x86 arch-specific changes that he couldn't test.
It's kind of amusing: he doesn't really get involved with the PPC arch, and continues to work on the x86 arch, just because he knows a lot of the low-level x86 stuff from before and hasn't bothered to learn the low-level PPC stuff.
But there's no substitute for writing the requirements, feature definitions, scopes and dependencies first, then the comments in the code blocks, then the code, and tar'ing those docs with the source code.
Those are the worst. You have the source, which seems to almost work. Then you've got the comments in the code, which are sort of relevant, but whenever the code gets sufficiently tricky that you'd have to read any of the comments, they're simply wrong. Then there are all the dependencies, which are incomplete and only include the obvious connections and not the ones which were added later. Finally, there are the requirements, which not only don't describe the actual program, but are simply impossible.
The best projects are ones where there's a bunch of code, which is written with names that suggest what things actually are and do, where everything is broken down into chunks which are sufficiently small to understand if you look at them, which has gotten arranged so that everything flows in accordance with the underlying problem being solved, and which is grouped logically, with related functions near each other within a file, in files, and in directories; and there is additional documentation, revised after the last change to anything it documents, which explains everything that isn't obvious from reading the code, as well as explaining where in the code to start reading.
The sole reason that code is the best documentation is that it is never incorrect. The program will definitely do what its source says it will. All other documentation must be held to the same standard, even though there is no automatic check for it. (One advantage of javadoc-style tools is that there are some automatic checks for accuracy; you can't have javadoc which gives the wrong name for a function). The worst thing is documentation which pretends to be authoritative, but which is out of date, and any document which predates the code is going to be out of date, unless the project is so trivial that someone with no experience could do it on the first try-- because that is what the original design documents are: the first try by people who do not yet have experience.
Personally, I think the best balance might be to start writing code with minimal planning (come up with the idea, divide the tasks, decree the coding style, arrange the process for adding tasks), but to have bitter and anal code reviews of everything that goes in. This requires the programmers to demonstrate that the code is clear enough to read and that the result including all additional documents is accurate and sufficient for someone who didn't write it to understand it based exclusively on the design.
The database is HSQLDB, which is a reasonable SQL database with the distinction of keeping the contents of the database in SQL scripts, and normally interacting with a file rather than with a service. It's essentially the right thing for cases where you want to have "your" database rather than "the" database. It's also easy to import on a database server, because you can just connect to the database and run the file as a script. It's quite a nice package, but it's not actually an OOo project at all.
The OOo project is a front-end, and can access various SQL databases. They just include HSQLDB so that people who want to stick some information in a database in an ad hoc fashion don't have to set up a database service.
The common examples of evil companies, at least in the computer business, were always that evil, but people were distracted by more evil companies or didn't care so much. IBM had quite a history of being closed and proprietary, but people expected that at the time. They won in that time period, so they were still around when closed and proprietary became unusual for their business, and then they were seen as evil. Microsoft similarly started out by eating up companies for their software, undercutting the competition, etc, and still does.
Maybe if Google wins, we'll wake up someday and find that everyone smart and good at computers is working on web applications and compiler research has completely died. But I think companies don't turn evil, in general, so much as less evil alternatives show up later.
First of all, software patents are not currently prohibited in the EU. The EU does not yet have a position on them, and the EU patent office grants them; they are valid in some countries and not in others, and they are effectively valid in some where they are not strictly valid, due to allowing patents on which don't specify what they apply to to apply to software, despite it not being allowed to specifically apply them to software. Obviously, the current situation is a complete mess, and the EU Commission has called for a directive to resolve it, since that's the Commission's job.
The process started with a directive that would permit software patents. After much discussion and popular outcry from individuals and small and medium-sized businesses, the Parliament amended the directive to prohibit software patents, and passed the resulting version.
The Council (which is composed of people appointed by the democratically-elected governments of the member countries, rather than directly elected individuals), on the other hand, set aside the amendments and passed the original version of the directive, and then claimed that they had reached agreement with the Parliament.
The Commission is supposed to determine what, exactly, the Council and the Parliament have done. They keep trying to sign off on the process without a vote, on the theory that the Council and Parliament agree (on the Council version). Various Commission members have kept this from happening. Meanwhile, various committees of the Parliament have been calling for the entire thing to start over, and the Commission has been ignoring them. Furthermore, the support in the Council for the version is eroding as national parliaments send instructions to their government's representatives not to support it.
So the current status is: the legality of SW patents in Europe is current ambiguous and nobody wants to leave it this way; the resolution currently on the table permits SW patents; the Council is refusing requests from the Parliament to restart the process from scratch, which would permit an anti-SW-patent result.
For that matter, Firefox is merely failing to grow exponentially. Considering that the browser market isn't growing significantly, it's not surprising that no segment of it is growing exponentially.
A more sensible model would be exponential decay, fitting with a constant portion of users of other browsers defecting to Firefox in each time period. This would fit the recent data, and only predicts that Firefox will stop getting new users when everyone is using Firefox.
Sure, you can have your code and data in separate spaces if you want. Atmel will sell you a very nice computer that works that way. Of course, you need to reprogram it externally if you want to run something different on it. The notion of running different programs without something external replacing the program memory doesn't work on a Harvard architecture.
And a Harvard architecture doesn't help, anyway, if your program contains routines that an attacker would like to run with chosen data, because the stack, which holds the return address of the current function, must be data memory. So the attacker can replace the return address with the address of the target function, arrange arguments appropriately, and return. The security advantages of a Harvard architecture does have are available already, with MMU flags which prevent instruction fetch from reading non-code pages; the issue is not treating code as data, but treating data as code (without some code telling the MMU that the pages should be code).
A more significant security improvement is disallowing pointers into the stack, and modifying it only with special stack instructions with constant offsets from the top of the stack. This forces people to put their buffers in heap, where overflows are much harder to exploit. (See, for example, the JVM.)
The simple fact of stock phrases being commonly used to express non-literal meanings indicates that a statistical approach is likely to do well. It probably wouldn't get "without bursting into flames", due to that actually being commonly applied to things actually involving fire. Of the top ten Google hits, 5 are completely literal (mostly vampires), 3 involve avoiding failures with literal fire or heat (some exaggerated), 1 involves a pun (on a person being "bright"), and 1 is completely metaphorical.
I'm not sure how bad it would be to translate this particular case literally, though, since there is a common concepts (in English, at least) for computers having heat problems due to overload, and the completely metaphorical Google citation seems to be Aussie. It would probably do better with less close idioms such as "the cat is out of the bag", (24K Google hits, and no felines or containers in the top ten) or "the shit hit the fan" (14K, no turbines or feces).
So I have some expectation that these programs may start to cut out the relatively boring parts of your work, where the translation simply has to convey the information idiomatically in the target language, and leave you just translating works of art. On the other hand, I'm not sure how close these programs are to actually putting sentences together correctly in the target language; they may well be generating a collection of the right words in the wrong places.
The big compromises haven't actually had anything to do with consumer online commerce. If you want to be safe, avoid having a credit rating or any income. Also, don't have a cell phone. But not much bad can happen if you use your credit card online (aside from the risk in having a credit card in the first place). Of course, the average user has no idea what the news is actually about, and probably doesn't understand what the survey questions actually are asking, either.
The only way to make identity checks more secure is to use a public/private key scheme. If everyone had a public key, which was a matter of public record, and where only the individual had the private key, and the necessary identification was the ability to decrypt a string of random digits, then we would have an improvement. It doesn't matter at all what the necessary identification is if anyone you identify yourself to or who is able to test whether you have identified yourself is able to steal your identity.
Doing the same thing for (!ptr) and (ptr == NULL) isn't an optimization; in either case, the compiler will almost certainly use a "branch if not zero" instruction. If it doesn't, it's an even chance which of the versions generates worse code.
The only consideration is which is the clearer code, and the answer to that one is whichever is used most in the surrounding code, or, if you're just starting, whichever the programmers are most accustomed to. In this case, "(!ptr)" is more clear than "(ptr == NULL)", because it's what you've been using.
Personally, I greatly prefer "!ptr", because I generally think about the code in terms of whether the pointer is valid. I tend to write "if (ptr) use(ptr);", and I find "if (ptr != NULL) use(ptr);" confusing, like saying, "if pointer isn't no good,..."
You have a very different idea of "non-offending" than I do. I personally find dhtml menus worse that floaters, because the ads at least provide revenue for the site, while the menus do nothing but obscure the content. I'd much rather sites use flash, because I don't have flash support, so I don't have to deal with them.
Also, turning off javascript is not necessarily sufficient, because the site can just use CSS to place the ad in your way and javascript to remove it, and javascript also has uses which don't involve messing up the page.
I suspect that the person not only has to be a competent translator, but also genuinely funny. I don't think coming up with an equivalent of "Time flies like an arrow; fruit flies like a banana" in a different language is any easier than coming up with the original was for Groucho Marx. So I don't expect to see a program that can come up with good translations of puns any sooner than the program is able to produce genuinely interesting original work.
It only took an hour and half, according to the site. The big thing you're lacking is probably 12 people interested in doing something really silly late at night. Also, 3800 post-it notes.
OSS doesn't necessarily lead to incompatibility; pretty much everything runs on X and POSIX, even when there are different implementations of various things (consider all the file systems that people use, all of which act the same with respect to programs storing files while being completely different in other ways.
Things work well when there is no choice in the standards and a lot of choice in the implementations. That's why GroupDAV is a good idea; a wide variety of implementations are agreeing to share a standard format. It doesn't really require forced regulation; it just requires a good solution that someone is willing to document independant of their implementation.
Microsoft applications are often not based on a standard independant of the application, which means that everything is interoperable as long as it is all the same version. As soon as someone gets a new version, things start breaking and needing to be upgraded.
So, in fact, a BDFL isn't sufficient. You need a king for a day, such that, the next day, nobody at all can change what was decreed.
Slashdot Mirror
The NSA is responsible for advising the government and critical private-sector infrastructure on how to protect data. If there's a backdoor in an NSA-recommended standard, heads will roll (only figuratively, of course; they use the electric chair). Academic cryptography research is not believed to be too far behind the NSA, and it is reasonable to guess that the Chinese government is about even with the NSA. So a backdoor inserted by the NSA would probably be discovered by the Chinese within a year and academics worldwide within 5 years, at which point terrorists destroy the US economy and wipe out military deployments.
The NSA may not really want our private data to be kept secure, but they do want the banking network to be kept secure. In general, they prefer to get data by finding plaintext or keys on seized equipment, rather than breaking encryption, because anybody can break encryption about equally well, but the government has an advantage in seizing things. That's not to say that they don't insert backdoors in things they don't intend to be secure (like consumer operating systems), particularly in implementations (where the hole can easily involve use of a secret key). But such things don't get this sort of announcement.
Writing Linux device drivers in C# is merely pointless. It causes nowhere near the brain damage that would be caused by trying to maintain the yacc.NET version.
What the code happens to do is quite important; otherwise we wouldn't bother to fix bugs. What we want it to do is also important; otherwise we would be satisfied with programs doing whatever.
On the other hand, we don't really care about what the code used to do but doesn't any more (unless we're trying to figure out when it stopped doing that or how to make it do it again), and we really don't care about what we used to want the code to do but have since decided wasn't such a good idea.
The thing that can be bad about documentation, and especially documentation outside of the code, is that it doesn't automatically stay up to date. The code always documents what the code does now, but the documentation can still be documenting what we no longer want the code to do.
This is a way in which unit tests can be better documentation than plain text documentation; if the unit tests are out of date, the author will probably notice, whereas if the plain text is out of date, the author won't notice for a long time.
These representatives represent their countries, not the people of their countries directly, and they do answer to their governments. That's why the Danish representative is following the demands of the Danish parliament (in fact, a group of opponents of the minority government), which is elected by the Danish people. The fishy thing is that the leading commissioner for the Internal Markets DG is able to keep this from coming to a vote in the Commission by putting a contraversial directive on the list of uncontraversial directives to be accepted without discussion, and can get the president of the Commission to reject the request for restarting from scratch without input from the rest of the Commission.
Blame McCreevy, the leading commissioner for the DG that's doing all this. Also Barroso, somewhat, for deciding to reject the JURI request for starting from scratch based only on McCreevy's input.
Code is never incorrect as far as documenting what the code does. It may be non-functional, broken, or inapplicable, but the closest it can be to incorrect (in this sense) is to be misleading.
I'd guess that they'd do exactly what IBM did, since that seems to have gotten the sort of positive press that they'd want. That is, they will not sue anybody over using the patented processes in a way covered by an OSI-approved license, provided that whoever it is hasn't sued anyone over use of patents in OSI-licensed activities.
It only works for supercomputer clusters only in that, if you connect your computers with infiniband stuff, you might as well start calling them a supercomputer cluster.
Assuming you use the 1-bit fields with "if (field)" or "if (!field)", it doesn't matter if they're signed, except that you'll get a warning (but the desired effect) for "field = 1". Problems come up when you use the value as a larger type, but that's not a good idea for code clarity reasons anyway, when the field semantically stores either a true value or a false value (in the sense that "if" uses). This change is really for getting rid of warnings (and improving maintainability) not fixing bugs.
He's actually been using PPC for about a year now, IIRC; he mentioned on the mailing list that he had switched shortly after, when there were some x86 arch-specific changes that he couldn't test.
It's kind of amusing: he doesn't really get involved with the PPC arch, and continues to work on the x86 arch, just because he knows a lot of the low-level x86 stuff from before and hasn't bothered to learn the low-level PPC stuff.
But there's no substitute for writing the requirements, feature definitions, scopes and dependencies first, then the comments in the code blocks, then the code, and tar'ing those docs with the source code.
Those are the worst. You have the source, which seems to almost work. Then you've got the comments in the code, which are sort of relevant, but whenever the code gets sufficiently tricky that you'd have to read any of the comments, they're simply wrong. Then there are all the dependencies, which are incomplete and only include the obvious connections and not the ones which were added later. Finally, there are the requirements, which not only don't describe the actual program, but are simply impossible.
The best projects are ones where there's a bunch of code, which is written with names that suggest what things actually are and do, where everything is broken down into chunks which are sufficiently small to understand if you look at them, which has gotten arranged so that everything flows in accordance with the underlying problem being solved, and which is grouped logically, with related functions near each other within a file, in files, and in directories; and there is additional documentation, revised after the last change to anything it documents, which explains everything that isn't obvious from reading the code, as well as explaining where in the code to start reading.
The sole reason that code is the best documentation is that it is never incorrect. The program will definitely do what its source says it will. All other documentation must be held to the same standard, even though there is no automatic check for it. (One advantage of javadoc-style tools is that there are some automatic checks for accuracy; you can't have javadoc which gives the wrong name for a function). The worst thing is documentation which pretends to be authoritative, but which is out of date, and any document which predates the code is going to be out of date, unless the project is so trivial that someone with no experience could do it on the first try-- because that is what the original design documents are: the first try by people who do not yet have experience.
Personally, I think the best balance might be to start writing code with minimal planning (come up with the idea, divide the tasks, decree the coding style, arrange the process for adding tasks), but to have bitter and anal code reviews of everything that goes in. This requires the programmers to demonstrate that the code is clear enough to read and that the result including all additional documents is accurate and sufficient for someone who didn't write it to understand it based exclusively on the design.
The database is HSQLDB, which is a reasonable SQL database with the distinction of keeping the contents of the database in SQL scripts, and normally interacting with a file rather than with a service. It's essentially the right thing for cases where you want to have "your" database rather than "the" database. It's also easy to import on a database server, because you can just connect to the database and run the file as a script. It's quite a nice package, but it's not actually an OOo project at all.
The OOo project is a front-end, and can access various SQL databases. They just include HSQLDB so that people who want to stick some information in a database in an ad hoc fashion don't have to set up a database service.
The common examples of evil companies, at least in the computer business, were always that evil, but people were distracted by more evil companies or didn't care so much. IBM had quite a history of being closed and proprietary, but people expected that at the time. They won in that time period, so they were still around when closed and proprietary became unusual for their business, and then they were seen as evil. Microsoft similarly started out by eating up companies for their software, undercutting the competition, etc, and still does.
Maybe if Google wins, we'll wake up someday and find that everyone smart and good at computers is working on web applications and compiler research has completely died. But I think companies don't turn evil, in general, so much as less evil alternatives show up later.
First of all, software patents are not currently prohibited in the EU. The EU does not yet have a position on them, and the EU patent office grants them; they are valid in some countries and not in others, and they are effectively valid in some where they are not strictly valid, due to allowing patents on which don't specify what they apply to to apply to software, despite it not being allowed to specifically apply them to software. Obviously, the current situation is a complete mess, and the EU Commission has called for a directive to resolve it, since that's the Commission's job.
The process started with a directive that would permit software patents. After much discussion and popular outcry from individuals and small and medium-sized businesses, the Parliament amended the directive to prohibit software patents, and passed the resulting version.
The Council (which is composed of people appointed by the democratically-elected governments of the member countries, rather than directly elected individuals), on the other hand, set aside the amendments and passed the original version of the directive, and then claimed that they had reached agreement with the Parliament.
The Commission is supposed to determine what, exactly, the Council and the Parliament have done. They keep trying to sign off on the process without a vote, on the theory that the Council and Parliament agree (on the Council version). Various Commission members have kept this from happening. Meanwhile, various committees of the Parliament have been calling for the entire thing to start over, and the Commission has been ignoring them. Furthermore, the support in the Council for the version is eroding as national parliaments send instructions to their government's representatives not to support it.
So the current status is: the legality of SW patents in Europe is current ambiguous and nobody wants to leave it this way; the resolution currently on the table permits SW patents; the Council is refusing requests from the Parliament to restart the process from scratch, which would permit an anti-SW-patent result.
For that matter, Firefox is merely failing to grow exponentially. Considering that the browser market isn't growing significantly, it's not surprising that no segment of it is growing exponentially.
A more sensible model would be exponential decay, fitting with a constant portion of users of other browsers defecting to Firefox in each time period. This would fit the recent data, and only predicts that Firefox will stop getting new users when everyone is using Firefox.
Sure, you can have your code and data in separate spaces if you want. Atmel will sell you a very nice computer that works that way. Of course, you need to reprogram it externally if you want to run something different on it. The notion of running different programs without something external replacing the program memory doesn't work on a Harvard architecture.
And a Harvard architecture doesn't help, anyway, if your program contains routines that an attacker would like to run with chosen data, because the stack, which holds the return address of the current function, must be data memory. So the attacker can replace the return address with the address of the target function, arrange arguments appropriately, and return. The security advantages of a Harvard architecture does have are available already, with MMU flags which prevent instruction fetch from reading non-code pages; the issue is not treating code as data, but treating data as code (without some code telling the MMU that the pages should be code).
A more significant security improvement is disallowing pointers into the stack, and modifying it only with special stack instructions with constant offsets from the top of the stack. This forces people to put their buffers in heap, where overflows are much harder to exploit. (See, for example, the JVM.)
The simple fact of stock phrases being commonly used to express non-literal meanings indicates that a statistical approach is likely to do well. It probably wouldn't get "without bursting into flames", due to that actually being commonly applied to things actually involving fire. Of the top ten Google hits, 5 are completely literal (mostly vampires), 3 involve avoiding failures with literal fire or heat (some exaggerated), 1 involves a pun (on a person being "bright"), and 1 is completely metaphorical.
I'm not sure how bad it would be to translate this particular case literally, though, since there is a common concepts (in English, at least) for computers having heat problems due to overload, and the completely metaphorical Google citation seems to be Aussie. It would probably do better with less close idioms such as "the cat is out of the bag", (24K Google hits, and no felines or containers in the top ten) or "the shit hit the fan" (14K, no turbines or feces).
So I have some expectation that these programs may start to cut out the relatively boring parts of your work, where the translation simply has to convey the information idiomatically in the target language, and leave you just translating works of art. On the other hand, I'm not sure how close these programs are to actually putting sentences together correctly in the target language; they may well be generating a collection of the right words in the wrong places.
The big compromises haven't actually had anything to do with consumer online commerce. If you want to be safe, avoid having a credit rating or any income. Also, don't have a cell phone. But not much bad can happen if you use your credit card online (aside from the risk in having a credit card in the first place). Of course, the average user has no idea what the news is actually about, and probably doesn't understand what the survey questions actually are asking, either.
The only way to make identity checks more secure is to use a public/private key scheme. If everyone had a public key, which was a matter of public record, and where only the individual had the private key, and the necessary identification was the ability to decrypt a string of random digits, then we would have an improvement. It doesn't matter at all what the necessary identification is if anyone you identify yourself to or who is able to test whether you have identified yourself is able to steal your identity.
Doing the same thing for (!ptr) and (ptr == NULL) isn't an optimization; in either case, the compiler will almost certainly use a "branch if not zero" instruction. If it doesn't, it's an even chance which of the versions generates worse code.
..."
The only consideration is which is the clearer code, and the answer to that one is whichever is used most in the surrounding code, or, if you're just starting, whichever the programmers are most accustomed to. In this case, "(!ptr)" is more clear than "(ptr == NULL)", because it's what you've been using.
Personally, I greatly prefer "!ptr", because I generally think about the code in terms of whether the pointer is valid. I tend to write "if (ptr) use(ptr);", and I find "if (ptr != NULL) use(ptr);" confusing, like saying, "if pointer isn't no good,
You have a very different idea of "non-offending" than I do. I personally find dhtml menus worse that floaters, because the ads at least provide revenue for the site, while the menus do nothing but obscure the content. I'd much rather sites use flash, because I don't have flash support, so I don't have to deal with them.
Also, turning off javascript is not necessarily sufficient, because the site can just use CSS to place the ad in your way and javascript to remove it, and javascript also has uses which don't involve messing up the page.
I suspect that the person not only has to be a competent translator, but also genuinely funny. I don't think coming up with an equivalent of "Time flies like an arrow; fruit flies like a banana" in a different language is any easier than coming up with the original was for Groucho Marx. So I don't expect to see a program that can come up with good translations of puns any sooner than the program is able to produce genuinely interesting original work.
It only took an hour and half, according to the site. The big thing you're lacking is probably 12 people interested in doing something really silly late at night. Also, 3800 post-it notes.
Probably not, but being twice as tall would probably have helped...
OSS doesn't necessarily lead to incompatibility; pretty much everything runs on X and POSIX, even when there are different implementations of various things (consider all the file systems that people use, all of which act the same with respect to programs storing files while being completely different in other ways.
Things work well when there is no choice in the standards and a lot of choice in the implementations. That's why GroupDAV is a good idea; a wide variety of implementations are agreeing to share a standard format. It doesn't really require forced regulation; it just requires a good solution that someone is willing to document independant of their implementation.
Microsoft applications are often not based on a standard independant of the application, which means that everything is interoperable as long as it is all the same version. As soon as someone gets a new version, things start breaking and needing to be upgraded.
So, in fact, a BDFL isn't sufficient. You need a king for a day, such that, the next day, nobody at all can change what was decreed.
From an alternate universe in which Microsoft got a judge who was a fan of Empire Strikes Back?