In other words, ODF [is bad] and nobody really wants to use it, but enough "activists" were able to convince those in government that it was a good idea.
Nope.
ODF is new and not yet widely deployed.
Just as you can't use television ads to sell televisions to people who only have radio, you can't use documents in ODF format to pitch the advantages of ODF to people who only have readers for.pdf and.doc.
Thanks, troll. If you didn't exist we'd have to invent you. B-)
If FSF and Cisco both agree that it is a donation, does it matter what anyone else thinks?
Make that "... and the IRS" and I'm with you.
If other people think it was a disguised damages award, so much the better - both for the EFF's bargaining position next time out and to promote a reduction of the number of infringers in the future. B-)
Sounds like Al Sharpton going after people, and settling for money.
If they'd come into compliance when they first got a nice letter from EFF they'd have been fine.
Instead they stonewalled. So EFF had to spend a lot of money and time to drag them to court.
They cost EFF a bunch of resources, so it's only appropriate that they make a donation to replenish them, keeping the EFF healthy and ready for the next fight.
If EFF runs SOLELY on free-will donations and doesn't go after additional funding in the settlements from people that forced them into expenditures to enforce the licenses, bad guys could grind them into bankruptcy, leave the FOSS with no effective defender (and perhaps cause the copyrights to a lot of FOSS software to be sold at the bankruptcy auction!).
So once the infringers have fought long enough that the EFF has to go to court I have no problem with EFF holding them up for a donation as part of the settlement.
I have no worries that the EFF will turn into a shakedown racket drumming up bogus claims, or that an infringer will be able to buy them off with JUST a donation and continue to infringe.
You're not trying to let them edit it. You're trying to influence them with a fixed document. So a display-only format is fine.
Further: You're trying to influence people who are NOT YET onboard with ODF. So you want a format that is viewable by as wide an audience as possible while displaying conveniently in an easy-on-the-eyes form. Right now that's PDF.
Putting it out in ODF means it's only viewable by people who already have ODF installed. That's mainly the people who are already onboard and don't need to be convinced. So it would be a case of "preaching to the choir" rather than "converting the heathen". Useful for giving your evangelists more talking points perhaps. But not all that useful for the purpose intended.
The posse comitatus act prohibits military cooperation with law enforcement fairly broadly, but additional laws passed in 1981 [allow] support roles [] when dealing with drug cases
Posse Comitatus clarifications emphasize supportive and technical assistance (e.g., use of facilities, vessels, and aircraft, as well as intelligence support, technological aid, and surveillance) while generally prohibiting direct participation of Department of Defense personnel in law enforcement (e.g., search, seizure, and arrests).
Sound like there's no problem AT ALL with Posse Comitatus.
There may be prior art for this in the mainframe or embedded-systems world.
The term of art is "feature protection". It's as old as mainframes.
(I believe it was a Univac where the difference between two models was a jumper that adjusted the clock rate. The info got out to the customers and one salesman was really embarrassed when he brought a prospective customer to an existing installation for a demo. The customer asked if he wanted to see it running as this model or that, pulling open a door and reaching for the jumper...)
One mainframe company I worked for put out a machine with multiple CPUs in it. The extras served as switch-in spares or for field upgrades if the customer paid to enable 'em.
It isn't just a "cheat" to get more money from the customers. On some devices (like printers) running at a higher speed increases the wear and the resulting maintenance requirements. Similarly, in the CPU case, running more CPUs increases the heating and shortens the life, while having less spares shortens the time until / increases the probability that you actually have to pull something out and replace it.
Making a single model and selling it as multiple levels using feature protection may be a lot less expensive (especially on high-dollar, low-volume products) than engineering multiple models. This benefit can be split between the manufacturer and the customers. It also makes upgrades a lot cheaper and less disruptive for both the customer and the company.
In software licensing it's been around since license manager software and dongles: Pay for more seats or more functions, they get turned on.
Interestingly: The more divergent the two (or more) expressions of the intent, the less likely it is that identical errors are made in both. Even if it's the same person creating both versions, working in the different languages (i.e. program vs. spec vs. comments vs. formal proof intput vs. constraint definition vs. etc.) provokes a different mindset. By thinking about each part of the program from different angles you have a good chance of getting at least one of the representations right. Once the tool rubs your nose in the problem it's easy to figure out which representation is the one you wanted.
So even though the formal tools can't prove CORRECTNESS but only MISMATCH, by pointing out the mismatch among the diverse expressions of the designers' intent they drastically reduce the bugs in the final product and increase the chances that it is either bug-free or significant-bug-free.
Your statements about only expressions being verifiable is just wrong.
I see where the confusion lies.
I'm not talking about only the expression part of a program being "provable".
I'm talking about an ENTIRE PROGRAM being an EXPRESSION OF THE INTENT of the designer.
I'm also talking about other expressions of this intent. Examples:
1) A specification document.
2) The input to software that attempts to do formal proofs of correctness.
What I'm saying about formal proof tools is that they requires both the program and item 2). But going from the internal intent of the designer to item 2) is also a job of programming, which can also introduce bugs. The formal proof tool can't tell you that the program did what the designer wanted. It can only tell you that the program code and item 2) matched.
Similarly a verification effort, human, automated, or a mix, can only tell you that the program matched item 1). It can't tell you if both the program and item 1) diverged from what the designer really wanted because the same mistake was made in both.
The same logic applies to any other "verification" / "proof of correctness" methodology you can apply to a program.
- All it can do is prove a match, not correctness.
- If both of the things being matched have the same error you get a false pass.
Does that make sense now?
Re:Did they publish the source?
on
Phoenix BIOSOS?
·
· Score: 1
They also harvest your name and physical address as required fields in the request that it be delivered by email.
I'd like to see what the EFF has to say about this.
You can hardly blame them for trying to test the limits. But it looks to me like they went far beyond them. (Unless they include the source in the distribution package, in which case {if I understand it correctly} the online download is "being nice guys" rather than required.)
Re:Did they publish the source?
on
Phoenix BIOSOS?
·
· Score: 1
Yes. But if they stored it in the same ROM with the rest of the BIOS they may have "linked" it with the BIOS for the purposes of the GPL. I'm not sure how that goes, leagalese-wise, but it might require them to publish the source to the BIOS as well.
I think it would make good sense to consider a ROM with a BIOS and a disk image to be treated the same as a ROM with a BIOS and a separate disk or flash with a disk image. To do otherwise would have a chilling effect on the likes of this very useful product. But what matters is what the documents say, not what I think would be a good idea.
(And the people who wrote the documents would no doubt want people who buy machines with the BIOS to have the source to the BIOS...)
Did they publish the source?
on
Phoenix BIOSOS?
·
· Score: 3, Interesting
Does this include Linux code in the BIOS itself, or only load it off disk and use it. If the former, did they publish the source?
Verification can prove that your code is correct but for most programs it is unfeasible.
Verification can prove two EXPRESSIONS of your intent MATCH. It can't prove they're CORRECT. A perfect implementation of "grep" is horribly buggy if what you wanted was "find".
Creating the second expression of your intent (counting the program as the first - though they usually are in the other order), in a form that can be used as an input to a piece of "correctness proof" software, is itself an act of programming, which may introduce errors.
Which is not to say that such tools aren't useful: The more divergent the two representations of intent are, the less likely they'll have identical errors. But it DOES say that they don't PROVE the program is CORRECT.
The first is that in incorrectly averages readings taken, assigning more weight to the first reading than the subsequent ones.
That is what the analysis claims. In fact the algorithm described assigns higher weight to the later, not the earlier readings - and is an (abrupt) approximation to a low-pass noise filter in the analog world. Weighting later values higher in an average is the appropriate sort of filter for a signal that's converging on a correct measurement but contains noise.
Similarly the thing with the "delays" being timed against a running periodic-interrupt clock. Maybe that's the RIGHT thing to do. (I know I'm working with a system RIGHT NOW where it is - and code that returned at a "correct" amount of time from the CALL to the delay routine rather than at the appropriate later clock tick would corrupt the measurement - stretching intervals by the time used in processing the previous tick.) To know if it's inducing errors or avoiding them you have to develop an understanding what the code is up to. If the coders picked the wrong sort of timing the "experts" should have been able to tell us why, and how it corrupted the data. They didn't do that.
There were several other items I take issue with in the analysis - like demanding a recognized programming methodology or claiming that it doesn't pass lint is necessarily bad.
Yes the code MAY be bad. (Those issues with the resolution an handling of out-of-limit values might be a problem. Pity they weren't described well enough to determine if they were.) And "bad" programming style is LIKELY to produce errors. But the issue here is whether the code gets the answer right enough to be used as evidence in a prosecution, not whether it meets an academic or industry programming fad or a style guideline. (Lint, for instance, gripes about a lot of "nits" that are not errors, merely coding issues that are often associated with errors. Nitpicking is why it's called "lint".)
This is not to say that other gripes in the report aren't real problems with the code examined. But those first items rang my bullshit detector. They make the rest of the "expert analysis" suspect. For something like this the experts' reports should focus on JUST things that they can SHOW corrupt the result and describe how. Waving their hands at everything that looks bad and might be a sign of error doesn't cut it.
This jeopardizes future attempts to knock down black box code that really DOES give bad evidence. And it provides a template for knocking down code that gives GOOD evidence that otherwise might be used by an innocent in his defense.
If you're going to do it in a court of law, do it RIGHT!
Which seems to be about giving the camera a wireless upload (and geo-tagging) feature, pluggable as if it were an ordinary memory card for recording pictures.
I don't understand why vendors stopped putting the switch on them. I guess they could break over time or been having issues with them getting stuck in a position...
They should use a hall sensor on the board and a magnet in the slider.
Or include the magnet in a double-cap connector cover set up so you have to leave the magnet ring on the drive to write it.
Magnetize the material in the ring as a Halbach array so it doesn't degauss any floppies if the key happens to be tossed in a container with them.
Downside of swiss army knife flash drive:
on
Flash Drive Roundup
·
· Score: 1
I remember being amazed and a bit amused when you could get a Swiss Army knife with a USB drive.
Can't use it with your laptop in an airplane, though.
I wonder what it costs to get a USB voltage tester.
Get a cheap -or free - USB cable (like the couple-inch cables that come with some unpowered hubs). Cut it in half. Strip back the cable's ourter armor. Separate the wires. Strip their ends. Hook the + and - wires to a cheap digital multimeter. (Use the ohmmeter function of the multimeter and a diagram of the USB pinout from the web.)
Check the calibration of your cheap digital multimeter by a) shorting the wires (should read 0 or no more than +- 0.02 volts) and b) hooking it across a friend's expensive digital voltmeter and measuring a couple batteries or other voltage sources that would use the same voltage scale on the cheap meter as the USB cable would, one higher and one lower than the USB's 5v spec.
Digital meter: Maybe 10 bux. Cable: Maybe free.
You also end up with a cheap digital multimeter to use for other stuff.
I understand that there was an additional import used to deal with Cane Toads that isn't in the wiki article. As I heard it:
There was a problem with cattle dung. The native dung beetles didn't dispose of it. So each cow flop would lie around for years, killing off a circle of grass several feet across. Cows make a LOT of flops, so this was a serious problem
So they imported dung beetles that WOULD break up and bury cow flops. But the Cane Toad would eat them, so they didn't take hold.
Finally they found a BIG dung beetle that would use cow flops. The cane toads would eat this one, too. But it was a big hardy bug. So it would dig its way out of the toad. Problem (and toad) solved. B-)
Unfortunately there apparently aren't enough cow flops to produce a big enough population of these booby-trap-beetles to wipe out the cane toads. So the toads are still a problem.
"Firstly, the only way to match altitudes is with speeds - the faster you go, the higher up you go...."
That's only an issue if your drift time between velocity adjustments is an appreciable fraction of a quarter-orbit. For significantly shorter times the orbital mechanics of the goofy accelerated reference frame is no big deal.
This was delicate because the instrument they're linking up with is massive and fragile. No hard bumps during grabbing or thruster exhaust spraying the device is acceptable.
... if there is some sort of 2nd Amendment reasoning that would make this cause of action more likely to prevail, I'd love to hear it.
There is.
The supreme court just explicitly recognized that the RKBA is both an individual right and a check on an overreaching federal government.
This is a case of the federal government using the convoluted logic of Wickard v. Filburn ("it might affect the price of other guns that are interstate commerce") to stretch the commerce clause into authorizing a suppression of a civil right that is an explicit check on the fed.
So the argument is much stronger in this case than in others (like medical marijuana or hotdog content standards). The supremes are more likely to reopen Wickard v. Filburn in this case because the conflict with an enumerated right is clear, despite the unpopularity of the RKBA among some of the justices.
I would not count on being able to pay debt in valueless dollars. The banks would never allow this. Instead, I would expect a new currency to be introduced, and old debts to be "re-valued" in the new currency...
Downside to this is, if the government does it for consumer debt, it does it for its OWN debt as well. This defeats much of the purpose of inflating the currency into oblivion. (If they try to zap the consumers and not themselves they open themselves to legal trouble from the holders of government bonds, who have pull too.)
I don't count on it, of course. But I want to be in a position to take advantage of it, rather than be taken advantage of, if it occurs as described.
It seems unlikely that this one was made in a lab, by accident or otherwise. Pigs, which swap Influenza both with humans and passing birds, are a natural place for this sort of mixing to occur. But given that it could have happened by a double accident in a sloppy lab (first getting two strains into the same egg, then getting a worker exposed to the result before it's harvested and killed to make vaccine material) it's worth checking.
But announcing it this way just broke security-by-obscurity on a way to make a pandemic on-the-cheap. Fertile eggs, samples of live viruses you want to hybridize, and a minimum of additional equipment and it's something virtually anybody with a spare room and a bit of time and effort could do. As a side-effect it gives them the material to make a vaccine for their own people in the process, long before the virus needs to be tried out on test subjects to test for virulence.
So while this one is no doubt an accident - most likely in the wild, MAYBE in a vaccine lab - don't be surprised if a later one is not. The press coverage of this speculation just showed the world how to replicate the first chapters of "The Stand" on a minimal budget.
Firefox is able to masquerade as IE. For some sites this has been necessary to view them. This results in Firefox being undercounted and IE being overcounted. (I haven't read TFA to see what, if any, mechanism they used to correct for that. Presuming they didn't...)
What this says to me is most of the interesting web sites have migrated to designs that don't reject Firefox (and perhaps other "standards compliant" browsers) and as a result more Firefox users are browsing without the masquerade.
Slashdot Mirror
In other words, ODF [is bad] and nobody really wants to use it, but enough "activists" were able to convince those in government that it was a good idea.
Nope.
ODF is new and not yet widely deployed.
Just as you can't use television ads to sell televisions to people who only have radio, you can't use documents in ODF format to pitch the advantages of ODF to people who only have readers for .pdf and .doc.
Thanks, troll. If you didn't exist we'd have to invent you. B-)
s/EFF/FSF/g;
Oops! Thanks!
If FSF and Cisco both agree that it is a donation, does it matter what anyone else thinks?
Make that "... and the IRS" and I'm with you.
If other people think it was a disguised damages award, so much the better - both for the EFF's bargaining position next time out and to promote a reduction of the number of infringers in the future. B-)
Sounds like Al Sharpton going after people, and settling for money.
If they'd come into compliance when they first got a nice letter from EFF they'd have been fine.
Instead they stonewalled. So EFF had to spend a lot of money and time to drag them to court.
They cost EFF a bunch of resources, so it's only appropriate that they make a donation to replenish them, keeping the EFF healthy and ready for the next fight.
If EFF runs SOLELY on free-will donations and doesn't go after additional funding in the settlements from people that forced them into expenditures to enforce the licenses, bad guys could grind them into bankruptcy, leave the FOSS with no effective defender (and perhaps cause the copyrights to a lot of FOSS software to be sold at the bankruptcy auction!).
So once the infringers have fought long enough that the EFF has to go to court I have no problem with EFF holding them up for a donation as part of the settlement.
I have no worries that the EFF will turn into a shakedown racket drumming up bogus claims, or that an infringer will be able to buy them off with JUST a donation and continue to infringe.
I'm sure that was the way that Cisco repaid the lawyer fees while getting a tax deduction out of it.
Unless I'm greatly mistaken they'd get to take a deduction on them anyhow, as a business expense.
If there are any tax advantages it's to FSF.
Shouldn't the file be an ODF format?
You're not trying to let them edit it. You're trying to influence them with a fixed document. So a display-only format is fine.
Further: You're trying to influence people who are NOT YET onboard with ODF. So you want a format that is viewable by as wide an audience as possible while displaying conveniently in an easy-on-the-eyes form. Right now that's PDF.
Putting it out in ODF means it's only viewable by people who already have ODF installed. That's mainly the people who are already onboard and don't need to be convinced. So it would be a case of "preaching to the choir" rather than "converting the heathen". Useful for giving your evangelists more talking points perhaps. But not all that useful for the purpose intended.
The posse comitatus act prohibits military cooperation with law enforcement fairly broadly, but additional laws passed in 1981 [allow] support roles [] when dealing with drug cases
And to quote the Wikipedia artical on Posse Comitatus:
Posse Comitatus clarifications emphasize supportive and technical assistance (e.g., use of facilities, vessels, and aircraft, as well as intelligence support, technological aid, and surveillance) while generally prohibiting direct participation of Department of Defense personnel in law enforcement (e.g., search, seizure, and arrests).
Sound like there's no problem AT ALL with Posse Comitatus.
There may be prior art for this in the mainframe or embedded-systems world.
The term of art is "feature protection". It's as old as mainframes.
(I believe it was a Univac where the difference between two models was a jumper that adjusted the clock rate. The info got out to the customers and one salesman was really embarrassed when he brought a prospective customer to an existing installation for a demo. The customer asked if he wanted to see it running as this model or that, pulling open a door and reaching for the jumper...)
One mainframe company I worked for put out a machine with multiple CPUs in it. The extras served as switch-in spares or for field upgrades if the customer paid to enable 'em.
It isn't just a "cheat" to get more money from the customers. On some devices (like printers) running at a higher speed increases the wear and the resulting maintenance requirements. Similarly, in the CPU case, running more CPUs increases the heating and shortens the life, while having less spares shortens the time until / increases the probability that you actually have to pull something out and replace it.
Making a single model and selling it as multiple levels using feature protection may be a lot less expensive (especially on high-dollar, low-volume products) than engineering multiple models. This benefit can be split between the manufacturer and the customers. It also makes upgrades a lot cheaper and less disruptive for both the customer and the company.
In software licensing it's been around since license manager software and dongles: Pay for more seats or more functions, they get turned on.
What's so special about doing it for OSes?
Great.
Interestingly: The more divergent the two (or more) expressions of the intent, the less likely it is that identical errors are made in both. Even if it's the same person creating both versions, working in the different languages (i.e. program vs. spec vs. comments vs. formal proof intput vs. constraint definition vs. etc.) provokes a different mindset. By thinking about each part of the program from different angles you have a good chance of getting at least one of the representations right. Once the tool rubs your nose in the problem it's easy to figure out which representation is the one you wanted.
So even though the formal tools can't prove CORRECTNESS but only MISMATCH, by pointing out the mismatch among the diverse expressions of the designers' intent they drastically reduce the bugs in the final product and increase the chances that it is either bug-free or significant-bug-free.
Your statements about only expressions being verifiable is just wrong.
I see where the confusion lies.
I'm not talking about only the expression part of a program being "provable".
I'm talking about an ENTIRE PROGRAM being an EXPRESSION OF THE INTENT of the designer.
I'm also talking about other expressions of this intent. Examples:
1) A specification document.
2) The input to software that attempts to do formal proofs of correctness.
What I'm saying about formal proof tools is that they requires both the program and item 2). But going from the internal intent of the designer to item 2) is also a job of programming, which can also introduce bugs. The formal proof tool can't tell you that the program did what the designer wanted. It can only tell you that the program code and item 2) matched.
Similarly a verification effort, human, automated, or a mix, can only tell you that the program matched item 1). It can't tell you if both the program and item 1) diverged from what the designer really wanted because the same mistake was made in both.
The same logic applies to any other "verification" / "proof of correctness" methodology you can apply to a program.
- All it can do is prove a match, not correctness.
- If both of the things being matched have the same error you get a false pass.
Does that make sense now?
They also harvest your name and physical address as required fields in the request that it be delivered by email.
I'd like to see what the EFF has to say about this.
You can hardly blame them for trying to test the limits. But it looks to me like they went far beyond them. (Unless they include the source in the distribution package, in which case {if I understand it correctly} the online download is "being nice guys" rather than required.)
Yes. But if they stored it in the same ROM with the rest of the BIOS they may have "linked" it with the BIOS for the purposes of the GPL. I'm not sure how that goes, leagalese-wise, but it might require them to publish the source to the BIOS as well.
I think it would make good sense to consider a ROM with a BIOS and a disk image to be treated the same as a ROM with a BIOS and a separate disk or flash with a disk image. To do otherwise would have a chilling effect on the likes of this very useful product. But what matters is what the documents say, not what I think would be a good idea.
(And the people who wrote the documents would no doubt want people who buy machines with the BIOS to have the source to the BIOS...)
Does this include Linux code in the BIOS itself, or only load it off disk and use it. If the former, did they publish the source?
Verification can prove that your code is correct but for most programs it is unfeasible.
Verification can prove two EXPRESSIONS of your intent MATCH. It can't prove they're CORRECT. A perfect implementation of "grep" is horribly buggy if what you wanted was "find".
Creating the second expression of your intent (counting the program as the first - though they usually are in the other order), in a form that can be used as an input to a piece of "correctness proof" software, is itself an act of programming, which may introduce errors.
Which is not to say that such tools aren't useful: The more divergent the two representations of intent are, the less likely they'll have identical errors. But it DOES say that they don't PROVE the program is CORRECT.
The first is that in incorrectly averages readings taken, assigning more weight to the first reading than the subsequent ones.
That is what the analysis claims. In fact the algorithm described assigns higher weight to the later, not the earlier readings - and is an (abrupt) approximation to a low-pass noise filter in the analog world. Weighting later values higher in an average is the appropriate sort of filter for a signal that's converging on a correct measurement but contains noise.
Similarly the thing with the "delays" being timed against a running periodic-interrupt clock. Maybe that's the RIGHT thing to do. (I know I'm working with a system RIGHT NOW where it is - and code that returned at a "correct" amount of time from the CALL to the delay routine rather than at the appropriate later clock tick would corrupt the measurement - stretching intervals by the time used in processing the previous tick.) To know if it's inducing errors or avoiding them you have to develop an understanding what the code is up to. If the coders picked the wrong sort of timing the "experts" should have been able to tell us why, and how it corrupted the data. They didn't do that.
There were several other items I take issue with in the analysis - like demanding a recognized programming methodology or claiming that it doesn't pass lint is necessarily bad.
Yes the code MAY be bad. (Those issues with the resolution an handling of out-of-limit values might be a problem. Pity they weren't described well enough to determine if they were.) And "bad" programming style is LIKELY to produce errors. But the issue here is whether the code gets the answer right enough to be used as evidence in a prosecution, not whether it meets an academic or industry programming fad or a style guideline. (Lint, for instance, gripes about a lot of "nits" that are not errors, merely coding issues that are often associated with errors. Nitpicking is why it's called "lint".)
This is not to say that other gripes in the report aren't real problems with the code examined. But those first items rang my bullshit detector. They make the rest of the "expert analysis" suspect. For something like this the experts' reports should focus on JUST things that they can SHOW corrupt the result and describe how. Waving their hands at everything that looks bad and might be a sign of error doesn't cut it.
This jeopardizes future attempts to knock down black box code that really DOES give bad evidence. And it provides a template for knocking down code that gives GOOD evidence that otherwise might be used by an innocent in his defense.
If you're going to do it in a court of law, do it RIGHT!
Which seems to be about giving the camera a wireless upload (and geo-tagging) feature, pluggable as if it were an ordinary memory card for recording pictures.
Cute device.
I don't understand why vendors stopped putting the switch on them. I guess they could break over time or been having issues with them getting stuck in a position ...
They should use a hall sensor on the board and a magnet in the slider.
Or include the magnet in a double-cap connector cover set up so you have to leave the magnet ring on the drive to write it.
Magnetize the material in the ring as a Halbach array so it doesn't degauss any floppies if the key happens to be tossed in a container with them.
I remember being amazed and a bit amused when you could get a Swiss Army knife with a USB drive.
Can't use it with your laptop in an airplane, though.
I wonder what it costs to get a USB voltage tester.
Get a cheap -or free - USB cable (like the couple-inch cables that come with some unpowered hubs). Cut it in half. Strip back the cable's ourter armor. Separate the wires. Strip their ends. Hook the + and - wires to a cheap digital multimeter. (Use the ohmmeter function of the multimeter and a diagram of the USB pinout from the web.)
Check the calibration of your cheap digital multimeter by a) shorting the wires (should read 0 or no more than +- 0.02 volts) and b) hooking it across a friend's expensive digital voltmeter and measuring a couple batteries or other voltage sources that would use the same voltage scale on the cheap meter as the USB cable would, one higher and one lower than the USB's 5v spec.
Digital meter: Maybe 10 bux.
Cable: Maybe free.
You also end up with a cheap digital multimeter to use for other stuff.
Reminds me of cane toads.
I understand that there was an additional import used to deal with Cane Toads that isn't in the wiki article. As I heard it:
There was a problem with cattle dung. The native dung beetles didn't dispose of it. So each cow flop would lie around for years, killing off a circle of grass several feet across. Cows make a LOT of flops, so this was a serious problem
So they imported dung beetles that WOULD break up and bury cow flops. But the Cane Toad would eat them, so they didn't take hold.
Finally they found a BIG dung beetle that would use cow flops. The cane toads would eat this one, too. But it was a big hardy bug. So it would dig its way out of the toad. Problem (and toad) solved. B-)
Unfortunately there apparently aren't enough cow flops to produce a big enough population of these booby-trap-beetles to wipe out the cane toads. So the toads are still a problem.
"Firstly, the only way to match altitudes is with speeds - the faster you go, the higher up you go. ..."
That's only an issue if your drift time between velocity adjustments is an appreciable fraction of a quarter-orbit. For significantly shorter times the orbital mechanics of the goofy accelerated reference frame is no big deal.
This was delicate because the instrument they're linking up with is massive and fragile. No hard bumps during grabbing or thruster exhaust spraying the device is acceptable.
... if there is some sort of 2nd Amendment reasoning that would make this cause of action more likely to prevail, I'd love to hear it.
There is.
The supreme court just explicitly recognized that the RKBA is both an individual right and a check on an overreaching federal government.
This is a case of the federal government using the convoluted logic of Wickard v. Filburn ("it might affect the price of other guns that are interstate commerce") to stretch the commerce clause into authorizing a suppression of a civil right that is an explicit check on the fed.
So the argument is much stronger in this case than in others (like medical marijuana or hotdog content standards). The supremes are more likely to reopen Wickard v. Filburn in this case because the conflict with an enumerated right is clear, despite the unpopularity of the RKBA among some of the justices.
Once it's reopened it's a whole new ballgame.
I would not count on being able to pay debt in valueless dollars. The banks would never allow this. Instead, I would expect a new currency to be introduced, and old debts to be "re-valued" in the new currency ...
Downside to this is, if the government does it for consumer debt, it does it for its OWN debt as well. This defeats much of the purpose of inflating the currency into oblivion. (If they try to zap the consumers and not themselves they open themselves to legal trouble from the holders of government bonds, who have pull too.)
I don't count on it, of course. But I want to be in a position to take advantage of it, rather than be taken advantage of, if it occurs as described.
It seems unlikely that this one was made in a lab, by accident or otherwise. Pigs, which swap Influenza both with humans and passing birds, are a natural place for this sort of mixing to occur. But given that it could have happened by a double accident in a sloppy lab (first getting two strains into the same egg, then getting a worker exposed to the result before it's harvested and killed to make vaccine material) it's worth checking.
But announcing it this way just broke security-by-obscurity on a way to make a pandemic on-the-cheap. Fertile eggs, samples of live viruses you want to hybridize, and a minimum of additional equipment and it's something virtually anybody with a spare room and a bit of time and effort could do. As a side-effect it gives them the material to make a vaccine for their own people in the process, long before the virus needs to be tried out on test subjects to test for virulence.
So while this one is no doubt an accident - most likely in the wild, MAYBE in a vaccine lab - don't be surprised if a later one is not. The press coverage of this speculation just showed the world how to replicate the first chapters of "The Stand" on a minimal budget.
Firefox is able to masquerade as IE. For some sites this has been necessary to view them. This results in Firefox being undercounted and IE being overcounted. (I haven't read TFA to see what, if any, mechanism they used to correct for that. Presuming they didn't...)
What this says to me is most of the interesting web sites have migrated to designs that don't reject Firefox (and perhaps other "standards compliant" browsers) and as a result more Firefox users are browsing without the masquerade.