Go to www.end6.org, download the little Javascript app, and apply it to your web site. Then, the first time the user goes to that site, they see a nag screen telling them to update their web browser. If they start seeing them on every site, they'll begin to get a clue.. while those whose companies will NOT allow change can at least get work done (it's not THEIR fault!). I installed in on my site, www.dwheeler.com, though in my case I complain about obsolete IE7 too.
The idea that "judges must not read blogs" is absurdly extreme. We don't forbid judges from reading newspapers; why are bloggers suddenly called out for special mistreatment?
It's true that we don't let juries look at stuff because they're not familiar with the details of what is or is not permissible evidence, but judges do have such training.
In fact, the article opens with Kennedy v. Louisiana, where blogging was a tremendous help. In this case, the Supreme Court's ruling was based on wrong information, and the bloggers pointed this mistake out. Kudos to the authors for being brave enough to point to this as an example. In any case, it shows that bloggers can have a very positive effect on court outcomes, by calling attention to critical mistakes in the court's information.
I want to see people more involved in political discourse. If they know that their discussions can't possibly have any effect, then they're less likely to have such discourse. Heck, I think that's why we have such low voter turnout... too many people think "my vote can't make any difference".
I do agree that there's a risk of hearing more of one side than another, but the direct presentations to judges along with research that the judges themselves do should help counter that. The other extremes seem worse than the problem they're trying to cure.
It handles texts, not audio, but Open Source Mission's Gospel Translations might be a useful model. They work with publishers/rights-holders (if any) to get the right to post works, then coordinate translations to a huge variety of languages. Once a translation is done, they post/host it for free. The translations are developed using a Wiki. Their focus is on Christian works, but I think the approach would work for any literature you want widely distributed in a variety of languages.
I wish TomTom had fought this; the FAT patents are utter nonsense. But patent fights are notoriously expensive, so I understand why TomTom did this instead.
In the long term, I hope that software patents get eliminated, but that will have to wait for another day.
Thanks for the plug for Secure Programming for Linux and Unix HOWTO. But I wrote it, not Bruce Schneier. Schneier has written other books, such as "Applied Cryptography" and "Schneier on Security".
I agree that a short list is important. I'd add "GPL version 2 or greater", "LGPL version 2 or greater", the BSD-new, and the MIT licenses to the short list of "reasonable licenses"; that list is still really short. I would recommend using the MIT license instead of the Apache 2.0 license; one problem with the Apache 2.0 license is that it's not compatible with the GPLv2 (though it is compatible with GPLv2 and GPL "version 2 or later"). In contrast, the BSD and MIT licenses are compatible with GPLv2.
It's particularly important to choose a license that's compatible with the GPL. The GPL is the most popular license, by far, so if every component is compatible with the GPL (of a specific version), then you can combine them all.
I go into this in
Make Your Open Source Software GPL-Compatible. Or Else.
You can see how that list of licenses (above) is compatible by examining my article,
"The Free-Libre / Open Source Software (FLOSS) License Slide". Bruce is right, life becomes too complicated by trying to handle 70+ licenses. A short list, which are mutually compatible (or nearly so), is far more reasonable.
If I understand you correctly, these are typically called "gated software" licenses. It's been discussed many times before.
Often the original developers try to get the customers to make improvements and contribute them back to the vendor. This sounds promising to vendors, but in practice it hasn't really worked out. Customers don't get excited about becoming unpaid workers without getting to share the fruits in some way. For open source software, it's easy to figure out how to share the results. But in a proprietary model, trying to figure out how to "share" the result is frustrating... it often costs more to figure out the value of a small change, than of the small change itself.
If you just use this as a proprietary business model, and treat the "ability to modify" as a competitive advantage over competing proprietary products, I can see this working. Assuming the product itself is good, of course. Though when a reasonable open source software product begins competing with the proprietary product (with sufficient functionality), there's a high risk that it'll each your lunch. An OSS product will give more rights to the end-users, and probably have a far lower total price, than yours.
Defining "open standards" is critical. Vendors with an open mouth will say they have an open standard. I'd go look at digistan.org for a more useful definition and justification.
If everyone could choose between hundreds of ISPs, this would be fine. But that's not the case; most people have only a very few rational options for ISPs (if you want reasonable bandwidth), i.e., monopolies, duopolies, etc. This is absurdly monopolistic.
This is a GOOD thing. DRM is a hideous disaster for end-users. When I buy music, I expect it to STAY bought, and to be able to use it on any device I have. DRM just guarantees that someone can take away my music with no judge and no jury.
But recording this information in the music file is a reasonable compromise. I can still play the music on any device I have. Yes, it's a bad idea to copy it to the world, but I never had the legal right to do that anyway. And yes, it'd be good if it were made clearer that this was happening... but this is NOT a big secret.
This isn't a perfect solution, of course. Even if someone has a copy of music originally bought by someone else, that does NOT mean the original buyer did anything illegal. Computers and networks get broken into all the time. Files can be modified to remove markings, or create bogus markings. Also, I believe people should continue to have the right to resell music, just like they can resell books (the "first sale" doctrine)... regardless of any nonsense spouted by the seller. But in the DRM system, a company operated as judge, jury, and executioner, and the company tended to act capriciously. At least with markings (or non-markings) in the file, a court can examine the evidence. It's not perfect, but it's better, and I can live with it better than the "everything's DRM'ed" world.
Now - where's my Ogg support in iTunes/iPods/iPhones? I'm not demanding that they only use Ogg, but they should be able to support Ogg formats (specifically Ogg Vorbis, Ogg FLAC, Ogg Speex, and Ogg Theora).
Neither MP3 nor AAC (.m4a) files are open standards. Wikipedia, for example,
provides audio files in Ogg and not in MP3 or AAC.
Have you been around kids?!? My experience (YMMV) is that yes, kids DO have to be taught to take a bath, speak clearly, and say please/thank you. It's hard for parents to get them to do that, and many of today's parents don't bother (perhaps because they incorrectly think that all kids will figure it out without being taught). The result is kids who are absolutely not ready for "real life". Forget the flirting; a class in the "basics of living in a society" (to raise your social IQ) is a really, really useful course. Stuff like bathing, having a brief conversation with someone you don't know, etc. Historically, the people who were getting ready to lead society went to finishing schools, took etiquette classes, etc. Some of it was bunk, but the basic idea that you need TRAINING to be able to work in a society is true enough. Self-taught can work, if you work at it... but too many people don't realize it's something that needs to be learned.
In Neal Stephenson's "The Diamond Age", a key part of the book was "A Young Lady's Illustrated Primer". Being able to work with others - instead of offending them before you meet them - is a good idea.
The CAN-SPAM law's purpose is to make it LEGAL to spam people. Which means that if you want to get rid of spam, the CAN-SPAM law is FUNDAMENTALLY flawed. Just read the CAN-SPAM law itself. CAN-SPAM says you can legally spam, as long as you follow some rules such as putting your "correct" header information on and including an opt-out clause message.
The primary failing with CAN-SPAM is an "opt-out" system, that is, it pretends that spam is okay as long as the sender includes an "opt out" address. That's fundamentally wrong; that means that senders can constantly create new shell organizations that send "one-time" messages every time they send something. If you're stupid enough to "opt out", you're immediately added to the "valid email" lists (aka a "sucker list").
Reputable articles about spam will SPECIFICALLY tell you to NEVER reply to a spam message, so the legislation requires law-abiding victims to do what they should absolutely NEVER do.
Legislation doesn't solve all problems; murder still happens, even though it's against the law. But the anti-fax-spam law, which is very similar, has been a resounding success. The difference is that the anti-fax-spam law made spam illegal, and required existing commercial ties or an opt-in into a list. Most companies still have and use fax machines, but spam is simply a non-problem for them.... in part because the legislation got this one right. So if you sent commercial spam by fax, then you ALREADY broke the law. Versus "CAN-SPAM", which is opt-out (not opt-in).
We need a law that makes spam ILLEGAL, not LEGAL. If you didn't EXPLICITLY opt into a list, and the message is sent to lots of people, then it needs to be illegal.
I would love to see that happen, and with some teeth; spam is making email systems really painful to use.
Then the U.S. can stop being one of the spam havens of the world, its current shameful position.
and replace "python" with whatever your script interpreter is, then you can have the script automatically use whatever interpreter is first on your PATH. This is especially nice if you're "not sure where the interpreter executable is", e.g., it might not be in "/usr/bin" - so this helps portability. (The POSIX standards GUARANTEE that "env" is in/bin, so this is VERY portable.) This also makes it easy to try out new interpreters (load a test version's binaries in ~/python-beta, add that first to that PATH, and now the test version's interpreter is used.) This does have the extra cost of starting up/bin/env first, but often that's not a big deal.
Yes, this is a bad idea if the attacker can control the PATH & this is security-relevant. But you can't securely run most interpreters directly anyway, so that's usually not relevant.
It wouldn't solve all ills, but I think it'd be valuable to encourage "Approval Voting". Third parties have basically no chance to get any traction under the current voting system. In approval voting, you can "vote for more than one candidate if you so choose. The winner is the candidate that collects the most votes."
It's not perfect, but it has lots of advantages. Existing voting equipment can be used (including paper counted by machine), and it's easy to understand. I think it's much better than our current system, while still being simple to understand and apply.
You don't get receipts, because that would invite fraud.
"Hi! If you vote for me, I'll pay you $20. If you pose as several other people, I'll pay $20 each. Just hand over your receipts when you're done, and once I've confirmed that you voted 'correctly', you get your $20".
This is one of the reasons why voting systems are harder to build than ATMs. With ATMs, you record who does what with a camera, and keep a strict log of every transaction. If there's funny business, you have a chance of convicting the user. In a voting system, you MUST NOT record who made which vote, and you MUST NOT give the voter any way to prove who they voted for. Voting systems are trickier than they appear, because they have really unusual security requirements... and because power is at stake, so people really DO attack security weak points.
We still use the wheel, and that's a pretty old invention. "Old" is not necessarily "bad", or "good". The question is, "is this the most appropriate way to solve the problem"?
The DRE equipment was NEVER appropriate for voting. Those kinds of things are just a magician's prop, and completely untrustworthy for voting purposes. If you want to make it easy for ONE person to steal an entire election, they're perfect. If your purpose is an honestly-counted election, such machines cannot be trusted. "There's nothing up this sleeve... nothing up the other sleeve... oh look, here's a fixed election!! Betcha can't tell how I did it!"
They're not IGNORING computer technology; they'll use computers to tally up the votes. The difference is, the information will be on a permanent record (paper) so that recounts and cross-checks can be done easily. You can use a computer well, or foolishly. The old systems used computers in a foolish way; now they're trying to fix that.
I think that the states should get their money back for many of the voting machines. Practically ALL computer-knowledgeable people understand that computers are easily rigged, and thus many of the existing systems are fundamentally untrustworthy. Quoting John Willis is unconvincing; he may say he's an "elections expert", but it's clear that he does not understand the fundamentals of these new voting systems.
Missing items: spam, public access, OSS, secure it
on
The First E-President
·
· Score: 1
If they really want to use the Internet to move us forward:
Make unsolicited bulk email (spam) a crime, and require that people OPT-IN to receive messages sent in bulk. The current 'opt-out' system in the U.S. is silly, and always was. Europeans have the more sensible opt-in system, so far more spam is U.S. in origin. It's not that hard to define; if more than 1000 people (say) receive it, and they didn't sign up for it (e.g., by signing up for a mailing list), it's spam. A law will not solve everything, but it would help. The current "CAN-SPAM" law is a joke - and aptly named.
Put all federally-funded unclassified research papers on the web, with no fees or sign-ins, so that a Google search can find it. NIH is already doing this, see its public access policy: http://publicaccess.nih.gov/ Why should the public pay for research, then pay again to read it?
By default, if the government funds unclassified software development (e.g., via research), that part should be released as open source software. Again, why should the public pay for software, then pay again to use it? Exceptions will be needed... but they should be exceptions, not the rule.
Increase funding on efforts to protect the network and network-connected components. Some is done now, but it pales compared to the problem.
These are nonsense numbers. Each major Linux distro will pull the OpenOffice.org source and put it in their own repository. So for Linux you'll see about 30 downloads (one per distro), plus a number of "early adopters" who don't mind doing the work themselves. Most Linux users will just wait til they're packaged, and pull from that. In other words: The Linux users are dreadfully undercounted by this count.
Wikipedia merely requires that something be VERIFIABLE; the "consensus" is not "the single truth". So if some people believe X, and others believe Y, it's typically not hard to provide evidence that there are some who believe in X, and others who believe in Y. In that case, a good Wikipedia article would state that there are two beliefs, X and Y, and explain each of them. Believers in X and Y may disagree, but they can typically come to an agreement on what X and Y _are_. This means that the reader will be told about both X and Y, but not told which one is the "objective truth". That is the limitation - and the advantage - of Wikipedia. This has its drawbacks, but it works "well enough".
As you already know, this claim that "anyone can edit the open source software" is nonsense. They're conflating editing a file with getting that file into the supply chain. Anyone can edit a proprietary program, too; just open up a hex editor and start modifying. The issue is, can a malicious attacker modify the program AND get their changes into the binary you end up with? This isn't easy at all in the major OSS projects (the kind your company is likely to consider). Any OSS project has some kind a "trusted repository", the "official" version that people pull from. For a change to get into your system, the trusted repository has to be subverted AND not detected later. We already know of an attempt to subvert Linux that failed, so it's not as easy as they think it is.
If they are REALLY concerned that they "don't know what the binary is", then get the source and recompile it.
Don't expert proprietariness to save you. Indeed, because the source code isn't being widely examined, any malicious code that gets in will be more difficult to find later.
If a company can't handle technological shifts in information technology, they risk their own long-term survival. OSS is now mainstream and widely used.
There is no single organization that everyone, worldwide, trusts. That's just the way it is.
So, let every country (or group of countries) sign it, and then let people decide which signature they'll accept. If you think there are a few non-national organizations that would make sense to sign, have them sign it too. Then the user can decide which signature they'll accept.. and the countries can decide which changes they'll sign.
I strongly believe that the DNS root needs to be signed by lots of organizations. Different countries don't fully trust each other, but by having multiple signatures, the problem disappears (a country only needs to sign if it believes in what it's signing).
The root (".") doesn't change every hour. It only stores information on how to _GET_ to.com,.us, and so on. Adding/removing those is relatively rare.
It's released as open source software - free as in speech, not just free as in beer. At least, that was the intent (I've had lengthy email conversations with Praxis about this). It's just that figuring that out is complicated; you have to seriously trudge through their docs to get the real licensing story.
The problem is that they (NSA/Praxis) didn't simply slap an open source software license on it. Instead, you have to hunt in Praxis' user's guide (section 2 on licensing), which says that you (the public) get all the rights that Praxis got from NSA. Then, you have to look at the NSA/Praxis contract, which says that you have the right to use, modify and redistribute (that's an imperfect quote from memory, see the files for the details).
I haven't analyzed this in great depth, but I can confirm (after several emails with Praxis) that the intent, at least, was to release Tokeneer as open source software.
I wish Praxis had just slapped a standard open source software license on the code. For the code they wrote themselves, Praxis simply applied the 2-clause BSD license, which is unambiguously open source software. Presumably their contracts made them release it in this unusual way.
Anyway, this is important and a good thing. In theory, if you could prove that any given program is correct, you'd eliminate or greatly reduce a lot of our problems with software. Currently, there are almost no published examples of formal methods applied to actual programs. And without examples, it's hard to make things better, improve on them, etc. This is not the end, but perhaps it's the glimmer of a beginning.
You're absolutely correct, the tools required to prove this are not open source software. Thus, I'd say this is not an "open proof" (an open proof is where the source code of the program, the proofs, and the required tools are all open source software). But it's a step forward from having almost no publicly-available examples of real programs where formal methods have been applied to this degree.
I disagree; this IS a strong precedence.
Even when courts are not REQUIRED (by law) to consider a ruling from a particular circuit, such rulings normally DO matter.
You say: "it is possible that district courts and other circuit courts will make use of the Federal Circuit opinion as persuasive authority in their own decision making. Just beware that there is no guarantee that will happen."
It's true that there's no guarantee, but the implication is overly pessimistic. It is highly likely that this ruling will influence other rulings, even if the court is not required to use it. Like any country based on common law, precedence matters in the United States. If there are no other countervailing rulings - and there are none - it's rather unlikely that this ruling would be ignored. Practically any judge will consider it very carefully if the conditions were similar.
Many courts aren't required to obey it, true, but it's MUCH easier for a judge to agree with an existing precedent, especially one that is well-reasoned (like this one is) and there are no countering rulings. Especially since this is, on its face, a pretty obvious result. I think that the lower court's ruling was wrong to start with, and this shows that the system really can correct egregious errors.
You can boot from a CD as well as a stick, if your system can't boot a USB device.
Go to http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Strawberry and look at "Boot it", where it says: "If your machine doesn't support that (booting from USB), download and burn: http://download.sugarlabs.org/soas/releases/soas-boot.iso". It's a small 8MB bootloader that easily fits on a CD.
Go to www.end6.org, download the little Javascript app, and apply it to your web site. Then, the first time the user goes to that site, they see a nag screen telling them to update their web browser. If they start seeing them on every site, they'll begin to get a clue.. while those whose companies will NOT allow change can at least get work done (it's not THEIR fault!). I installed in on my site, www.dwheeler.com, though in my case I complain about obsolete IE7 too.
The idea that "judges must not read blogs" is absurdly extreme. We don't forbid judges from reading newspapers; why are bloggers suddenly called out for special mistreatment? It's true that we don't let juries look at stuff because they're not familiar with the details of what is or is not permissible evidence, but judges do have such training.
In fact, the article opens with Kennedy v. Louisiana, where blogging was a tremendous help. In this case, the Supreme Court's ruling was based on wrong information, and the bloggers pointed this mistake out. Kudos to the authors for being brave enough to point to this as an example. In any case, it shows that bloggers can have a very positive effect on court outcomes, by calling attention to critical mistakes in the court's information.
I want to see people more involved in political discourse. If they know that their discussions can't possibly have any effect, then they're less likely to have such discourse. Heck, I think that's why we have such low voter turnout... too many people think "my vote can't make any difference".
I do agree that there's a risk of hearing more of one side than another, but the direct presentations to judges along with research that the judges themselves do should help counter that. The other extremes seem worse than the problem they're trying to cure.
It handles texts, not audio, but Open Source Mission's Gospel Translations might be a useful model. They work with publishers/rights-holders (if any) to get the right to post works, then coordinate translations to a huge variety of languages. Once a translation is done, they post/host it for free. The translations are developed using a Wiki. Their focus is on Christian works, but I think the approach would work for any literature you want widely distributed in a variety of languages.
I wish TomTom had fought this; the FAT patents are utter nonsense. But patent fights are notoriously expensive, so I understand why TomTom did this instead. In the long term, I hope that software patents get eliminated, but that will have to wait for another day.
Thanks for the plug for Secure Programming for Linux and Unix HOWTO. But I wrote it, not Bruce Schneier. Schneier has written other books, such as "Applied Cryptography" and "Schneier on Security".
I agree that a short list is important. I'd add "GPL version 2 or greater", "LGPL version 2 or greater", the BSD-new, and the MIT licenses to the short list of "reasonable licenses"; that list is still really short. I would recommend using the MIT license instead of the Apache 2.0 license; one problem with the Apache 2.0 license is that it's not compatible with the GPLv2 (though it is compatible with GPLv2 and GPL "version 2 or later"). In contrast, the BSD and MIT licenses are compatible with GPLv2.
It's particularly important to choose a license that's compatible with the GPL. The GPL is the most popular license, by far, so if every component is compatible with the GPL (of a specific version), then you can combine them all. I go into this in Make Your Open Source Software GPL-Compatible. Or Else.
You can see how that list of licenses (above) is compatible by examining my article, "The Free-Libre / Open Source Software (FLOSS) License Slide". Bruce is right, life becomes too complicated by trying to handle 70+ licenses. A short list, which are mutually compatible (or nearly so), is far more reasonable.
If I understand you correctly, these are typically called "gated software" licenses. It's been discussed many times before.
Often the original developers try to get the customers to make improvements and contribute them back to the vendor. This sounds promising to vendors, but in practice it hasn't really worked out. Customers don't get excited about becoming unpaid workers without getting to share the fruits in some way. For open source software, it's easy to figure out how to share the results. But in a proprietary model, trying to figure out how to "share" the result is frustrating... it often costs more to figure out the value of a small change, than of the small change itself.
If you just use this as a proprietary business model, and treat the "ability to modify" as a competitive advantage over competing proprietary products, I can see this working. Assuming the product itself is good, of course. Though when a reasonable open source software product begins competing with the proprietary product (with sufficient functionality), there's a high risk that it'll each your lunch. An OSS product will give more rights to the end-users, and probably have a far lower total price, than yours.
The U.S. Department of Defense's "Open Systems Joint Task Force" has some material.
Defining "open standards" is critical. Vendors with an open mouth will say they have an open standard. I'd go look at digistan.org for a more useful definition and justification.
European Interoperability Framework for pan-European eGovernment Services might help, too.
For statistics on why use open source software, see: Why FLOSS? Look at the Numbers!
If everyone could choose between hundreds of ISPs, this would be fine. But that's not the case; most people have only a very few rational options for ISPs (if you want reasonable bandwidth), i.e., monopolies, duopolies, etc. This is absurdly monopolistic.
This is a GOOD thing. DRM is a hideous disaster for end-users. When I buy music, I expect it to STAY bought, and to be able to use it on any device I have. DRM just guarantees that someone can take away my music with no judge and no jury.
But recording this information in the music file is a reasonable compromise. I can still play the music on any device I have. Yes, it's a bad idea to copy it to the world, but I never had the legal right to do that anyway. And yes, it'd be good if it were made clearer that this was happening... but this is NOT a big secret.
This isn't a perfect solution, of course. Even if someone has a copy of music originally bought by someone else, that does NOT mean the original buyer did anything illegal. Computers and networks get broken into all the time. Files can be modified to remove markings, or create bogus markings. Also, I believe people should continue to have the right to resell music, just like they can resell books (the "first sale" doctrine)... regardless of any nonsense spouted by the seller. But in the DRM system, a company operated as judge, jury, and executioner, and the company tended to act capriciously. At least with markings (or non-markings) in the file, a court can examine the evidence. It's not perfect, but it's better, and I can live with it better than the "everything's DRM'ed" world.
Now - where's my Ogg support in iTunes/iPods/iPhones? I'm not demanding that they only use Ogg, but they should be able to support Ogg formats (specifically Ogg Vorbis, Ogg FLAC, Ogg Speex, and Ogg Theora). Neither MP3 nor AAC (.m4a) files are open standards. Wikipedia, for example, provides audio files in Ogg and not in MP3 or AAC.
Please tell Apple to add support for Ogg; here's more info about why Apple should support Ogg.
Have you been around kids?!? My experience (YMMV) is that yes, kids DO have to be taught to take a bath, speak clearly, and say please/thank you. It's hard for parents to get them to do that, and many of today's parents don't bother (perhaps because they incorrectly think that all kids will figure it out without being taught). The result is kids who are absolutely not ready for "real life". Forget the flirting; a class in the "basics of living in a society" (to raise your social IQ) is a really, really useful course. Stuff like bathing, having a brief conversation with someone you don't know, etc. Historically, the people who were getting ready to lead society went to finishing schools, took etiquette classes, etc. Some of it was bunk, but the basic idea that you need TRAINING to be able to work in a society is true enough. Self-taught can work, if you work at it... but too many people don't realize it's something that needs to be learned.
In Neal Stephenson's "The Diamond Age", a key part of the book was "A Young Lady's Illustrated Primer". Being able to work with others - instead of offending them before you meet them - is a good idea.
The CAN-SPAM law's purpose is to make it LEGAL to spam people. Which means that if you want to get rid of spam, the CAN-SPAM law is FUNDAMENTALLY flawed. Just read the CAN-SPAM law itself. CAN-SPAM says you can legally spam, as long as you follow some rules such as putting your "correct" header information on and including an opt-out clause message.
The primary failing with CAN-SPAM is an "opt-out" system, that is, it pretends that spam is okay as long as the sender includes an "opt out" address. That's fundamentally wrong; that means that senders can constantly create new shell organizations that send "one-time" messages every time they send something. If you're stupid enough to "opt out", you're immediately added to the "valid email" lists (aka a "sucker list"). Reputable articles about spam will SPECIFICALLY tell you to NEVER reply to a spam message, so the legislation requires law-abiding victims to do what they should absolutely NEVER do.
Legislation doesn't solve all problems; murder still happens, even though it's against the law. But the anti-fax-spam law, which is very similar, has been a resounding success. The difference is that the anti-fax-spam law made spam illegal, and required existing commercial ties or an opt-in into a list. Most companies still have and use fax machines, but spam is simply a non-problem for them.... in part because the legislation got this one right. So if you sent commercial spam by fax, then you ALREADY broke the law. Versus "CAN-SPAM", which is opt-out (not opt-in).
We need a law that makes spam ILLEGAL, not LEGAL. If you didn't EXPLICITLY opt into a list, and the message is sent to lots of people, then it needs to be illegal. I would love to see that happen, and with some teeth; spam is making email systems really painful to use. Then the U.S. can stop being one of the spam havens of the world, its current shameful position.
If you begin your scripts with:
/bin, so this is VERY portable.) This also makes it easy to try out new interpreters (load a test version's binaries in ~/python-beta, add that first to that PATH, and now the test version's interpreter is used.) This does have the extra cost of starting up /bin/env first, but often that's not a big deal.
#!/bin/env python
and replace "python" with whatever your script interpreter is, then you can have the script automatically use whatever interpreter is first on your PATH. This is especially nice if you're "not sure where the interpreter executable is", e.g., it might not be in "/usr/bin" - so this helps portability. (The POSIX standards GUARANTEE that "env" is in
Yes, this is a bad idea if the attacker can control the PATH & this is security-relevant. But you can't securely run most interpreters directly anyway, so that's usually not relevant.
It wouldn't solve all ills, but I think it'd be valuable to encourage "Approval Voting". Third parties have basically no chance to get any traction under the current voting system. In approval voting, you can "vote for more than one candidate if you so choose. The winner is the candidate that collects the most votes."
It's not perfect, but it has lots of advantages. Existing voting equipment can be used (including paper counted by machine), and it's easy to understand. I think it's much better than our current system, while still being simple to understand and apply.
Citizens for Approval Voting and Americans for Approval Voting have more info, if you're curious.
You don't get receipts, because that would invite fraud.
"Hi! If you vote for me, I'll pay you $20. If you pose as several other people, I'll pay $20 each. Just hand over your receipts when you're done, and once I've confirmed that you voted 'correctly', you get your $20".
This is one of the reasons why voting systems are harder to build than ATMs. With ATMs, you record who does what with a camera, and keep a strict log of every transaction. If there's funny business, you have a chance of convicting the user. In a voting system, you MUST NOT record who made which vote, and you MUST NOT give the voter any way to prove who they voted for. Voting systems are trickier than they appear, because they have really unusual security requirements... and because power is at stake, so people really DO attack security weak points.
We still use the wheel, and that's a pretty old invention. "Old" is not necessarily "bad", or "good". The question is, "is this the most appropriate way to solve the problem"?
The DRE equipment was NEVER appropriate for voting. Those kinds of things are just a magician's prop, and completely untrustworthy for voting purposes. If you want to make it easy for ONE person to steal an entire election, they're perfect. If your purpose is an honestly-counted election, such machines cannot be trusted. "There's nothing up this sleeve... nothing up the other sleeve... oh look, here's a fixed election!! Betcha can't tell how I did it!"
They're not IGNORING computer technology; they'll use computers to tally up the votes. The difference is, the information will be on a permanent record (paper) so that recounts and cross-checks can be done easily. You can use a computer well, or foolishly. The old systems used computers in a foolish way; now they're trying to fix that.
I think that the states should get their money back for many of the voting machines. Practically ALL computer-knowledgeable people understand that computers are easily rigged, and thus many of the existing systems are fundamentally untrustworthy. Quoting John Willis is unconvincing; he may say he's an "elections expert", but it's clear that he does not understand the fundamentals of these new voting systems.
These are nonsense numbers. Each major Linux distro will pull the OpenOffice.org source and put it in their own repository. So for Linux you'll see about 30 downloads (one per distro), plus a number of "early adopters" who don't mind doing the work themselves. Most Linux users will just wait til they're packaged, and pull from that. In other words: The Linux users are dreadfully undercounted by this count.
Wikipedia merely requires that something be VERIFIABLE; the "consensus" is not "the single truth". So if some people believe X, and others believe Y, it's typically not hard to provide evidence that there are some who believe in X, and others who believe in Y. In that case, a good Wikipedia article would state that there are two beliefs, X and Y, and explain each of them. Believers in X and Y may disagree, but they can typically come to an agreement on what X and Y _are_. This means that the reader will be told about both X and Y, but not told which one is the "objective truth". That is the limitation - and the advantage - of Wikipedia. This has its drawbacks, but it works "well enough".
Take a look at http://www.dwheeler.com - in particular, Open Source Software and Software Assurance (Security) and Why OSS/FS? Look at the Numbers!.
As you already know, this claim that "anyone can edit the open source software" is nonsense. They're conflating editing a file with getting that file into the supply chain. Anyone can edit a proprietary program, too; just open up a hex editor and start modifying. The issue is, can a malicious attacker modify the program AND get their changes into the binary you end up with? This isn't easy at all in the major OSS projects (the kind your company is likely to consider). Any OSS project has some kind a "trusted repository", the "official" version that people pull from. For a change to get into your system, the trusted repository has to be subverted AND not detected later. We already know of an attempt to subvert Linux that failed, so it's not as easy as they think it is. If they are REALLY concerned that they "don't know what the binary is", then get the source and recompile it.
Don't expert proprietariness to save you. Indeed, because the source code isn't being widely examined, any malicious code that gets in will be more difficult to find later.
The U.S. Department of Defense's policy is consider OSS equally with proprietary software, as does the entire U.S. government. In fact, the U.S. Department of Defense heavily depends on open source software, and they almost certainly have more stringent security requirements than your company.
If a company can't handle technological shifts in information technology, they risk their own long-term survival. OSS is now mainstream and widely used.
There is no single organization that everyone, worldwide, trusts. That's just the way it is.
So, let every country (or group of countries) sign it, and then let people decide which signature they'll accept. If you think there are a few non-national organizations that would make sense to sign, have them sign it too. Then the user can decide which signature they'll accept.. and the countries can decide which changes they'll sign.
Problem solved.
I strongly believe that the DNS root needs to be signed by lots of organizations. Different countries don't fully trust each other, but by having multiple signatures, the problem disappears (a country only needs to sign if it believes in what it's signing).
.com, .us, and so on. Adding/removing those is relatively rare.
The root (".") doesn't change every hour. It only stores information on how to _GET_ to
It's released as open source software - free as in speech, not just free as in beer. At least, that was the intent (I've had lengthy email conversations with Praxis about this). It's just that figuring that out is complicated; you have to seriously trudge through their docs to get the real licensing story.
The problem is that they (NSA/Praxis) didn't simply slap an open source software license on it. Instead, you have to hunt in Praxis' user's guide (section 2 on licensing), which says that you (the public) get all the rights that Praxis got from NSA. Then, you have to look at the NSA/Praxis contract, which says that you have the right to use, modify and redistribute (that's an imperfect quote from memory, see the files for the details). I haven't analyzed this in great depth, but I can confirm (after several emails with Praxis) that the intent, at least, was to release Tokeneer as open source software.
I wish Praxis had just slapped a standard open source software license on the code. For the code they wrote themselves, Praxis simply applied the 2-clause BSD license, which is unambiguously open source software. Presumably their contracts made them release it in this unusual way.
Anyway, this is important and a good thing. In theory, if you could prove that any given program is correct, you'd eliminate or greatly reduce a lot of our problems with software. Currently, there are almost no published examples of formal methods applied to actual programs. And without examples, it's hard to make things better, improve on them, etc. This is not the end, but perhaps it's the glimmer of a beginning.
You're absolutely correct, the tools required to prove this are not open source software. Thus, I'd say this is not an "open proof" (an open proof is where the source code of the program, the proofs, and the required tools are all open source software). But it's a step forward from having almost no publicly-available examples of real programs where formal methods have been applied to this degree.
I disagree; this IS a strong precedence. Even when courts are not REQUIRED (by law) to consider a ruling from a particular circuit, such rulings normally DO matter.
You say: "it is possible that district courts and other circuit courts will make use of the Federal Circuit opinion as persuasive authority in their own decision making. Just beware that there is no guarantee that will happen." It's true that there's no guarantee, but the implication is overly pessimistic. It is highly likely that this ruling will influence other rulings, even if the court is not required to use it. Like any country based on common law, precedence matters in the United States. If there are no other countervailing rulings - and there are none - it's rather unlikely that this ruling would be ignored. Practically any judge will consider it very carefully if the conditions were similar.
Many courts aren't required to obey it, true, but it's MUCH easier for a judge to agree with an existing precedent, especially one that is well-reasoned (like this one is) and there are no countering rulings. Especially since this is, on its face, a pretty obvious result. I think that the lower court's ruling was wrong to start with, and this shows that the system really can correct egregious errors.