2: Chip internally stores the last n random numbers that it has output. Later, the NSA can confiscate your computer, subject the chip to some undocumented state that causes it to barf up its secrets, and again all your keys are now utterly, hopelessly broken.
More likely its just going to get the random numbers generated for a video game.
ZFS has proven that a wide variety of chipset bugs, firmware bugs, actual mechanical failure, etc are still present and actively corrupting our data.
And I expect that defragging aggravates this. Read a perfectly good block of data from disk into flaky RAM, have a bit flip, and write out that corrupted data to its new location. Even if the software is verifying its likely to verify against RAM and it did successfully write what is in RAM.
And then there is over clocking. If a computer is just used for gaming, no problem. But if its used for more serious things or archiving things of value to you then you may want to pass on over clocking. Folks who say you can verify an over clocked CPU are mistaken. Its not a crash or no crash thing, at a certain unpredictable point in over clocking an unpredictable CPU instruction may simply give an incorrect result. This incorrect result could end up in your data or image. I've seen over clocked CPUs mess up a text string that is supplied by the CPU itself, CPUID's vendor string.
I am not saying that something like the Manhattan Project was wrong. I am merely saying that the deep ethical consideration suggested by the author isn't really warranted for mere "technology of violence", that its more appropriate for the WMD end of the spectrum. My understanding is that many of the scientists and engineers who knew the project's actual goal did consider what they were doing before taking the project to completion and I think that was a good thing. I've heard that some of the scientists working on Germany's bomb made some key errors that may not have been accidental. Maybe that's urban myth but If so they may have thought about what they were doing and made a good decision as well.
Its not the scalpel or the gun that is the problem, it is the mind and the intentions behind the hand holding the scalpel or gun.
Medical companies refuse to export drugs to the United States that they know are used in executions. But nobody will stop selling arms to someone else unless and until international law gets involved, and sometimes not even then. It seems pretty clear that those in the field of medicine have a higher moral standard.
I'm not sure things are clear on WMDs either. I firmly believe that the invention of the atomic bomb has saved the lives of millions of people over the decades.
I'm not saying that something like the Manhattan Project was wrong, just that I accept the idea that before working on something like the Manhattan Project a bit of thought and soul searching might be a good idea, assuming you knew what the goal actually was. Unlike working on the M1 Garand rifle design team.
Why short of WMD?
Presumably the reason we made it from 1945 to now without WW III is because our WMD engineers convinced the other side's engineers that our stuff would really work and vice versa.
*note this invovled rational actors and not third world nutcases
I'm not saying something like the Manhattan Project was wrong. However I do accept the idea that before working on something like the Manhattan Project (well, assuming you knew what the goal actually was) would and should require a bit of thought and soul searching. Unlike working on the M1 Garand rifle design team.
"when the rockets go up,
who cares where they come down?
it's not my department,
says Wernher Von Braun."
He didn't say that, but that summarizes the lives of thousands of people who make a living designing and building weapons (except a few fanatics who relish the though that their weapons kill $bad_guy)
That summarizes perhaps a small minority who design and build weapons. Lets consider the M1 Garand Rifle of the U.S. Army and Marine Corp. It was designed during peace time in the 1920s and 30s. It was used to destroy the Third Reich in Europe in the 1940s and in the 1960s it was used by some panicked National Guard to kill students at Kent State University in Ohio. Most of the engineers envisioned a use of the "destroy the Third Reich" type, not the students at Kent State type.
Probably because a Doctor helping torture someone is directly involved. The engineer's creation may be used in a way he/she never invisioned and with no involvement from him./her
Nor even with the knowledge of the ultimate use of his/her creation. Weapons can be used for good, its all about the intentions of those operating the weapons. For example those engineers who worked on weapons used to destroy the Third Reich, many of these were designed during peace time, ex M1 Garand Rifle of the US Army and Marine Corp. Short of WMD things are not so clear.
While it is hard to draw exact parallels, society already holds engineers to similar standards to doctors. The outrage over doctors experimenting on helpless test subjects is pretty similar to, say, when engineers use live subjects for testing weapons.
Yeah. The article's author is making a poor analogy. Blaming engineers would be more akin to blaming the scalpel designer for the doctor's experimentation. Its not the scalpel or the gun that is the problem, it is the mind and the intentions behind the hand holding the scalpel or gun. Both can be used for good or bad.
Short of WMD the issue is not as simple as the author suggests.
if the driver wants to drive a Carrera GT because he thinks it is "cool" then they should only hand them to you if you have the necessary training
This is what is done in aviation in the U.S. If a private pilot wants to fly a high performance aircraft then they need additional training and endorsements for their license. Keep in mind that in aviation high performance is an engine with more than 200 horsepower, we are *not* talking about racing or acrobatic aircraft, simply "excess" horsepower.
The basic idea being that with greater horsepower comes greater speed and with greater speed comes less time to fix a problem or mistake.
For example paired programming with constantly changing pairs, including pairs where a member is on unfamiliar ground.
Is there XP literature actually advocating that, with a theory behind why it's a good idea? Or is this some kind of DIY management innovation?
This is one of those things that will work for some projects and not others. It can be helpful with cross training and works better when the knowledge behind the various parts of the project is somewhat shallow. As it is in some books on Agile/XP where Agile/XP worked out brilliantly for the development team. Beware the manager reading such a book and believing they found the magic bullet.
It seems like agile would be good if you need something quick.
That is sort of the point, you get "something" in a short amount of time, then another "something" in another short amount of time. "Something" doesn't have to be complete and polished, just working so that it can be tried out and evaluated with respect to providing the desired benefit and doing so in a reasonable fashion. Ideally the people who will use the software will be trying these somethings and letting you know if its really heading in the right direction, working in a reasonable manner, etc.
So management hears "Oh it's quicker than what you're doing" and dive on that like a pigeon on a French fry. Honestly the agile I do currently should just be called "go fast, be stupid" because that's how it works out.
Regrettably I've also seen agile/xp go wrong and quality drop. It was more of a management problem, the number of tasks completed were pretty much the only metric devs were evaluated on. So management got what they rewarded, fast task completions. Quality dropped. Management didn't consider in dev evaluations tasks reappearing in future scrums because they were not done quite right the first time. It was quite Dilberte-sque.
Typically in the coastal plains (where a river would meet with saltwater), a river will widen up and it's current slows to a crawl (due to the lack of a "downhill" presence).
Sure, but we can put water wheels, turbines or something other than a dam up river a bit. Or many along the river. We don't need to be in the mixing zone.
Nothing in theory, **if** your project meets a certain profile. The real problem is that some people tend to implement an agile process in terrible ways, more so with "extreme programming" (XP). For example paired programming with constantly changing pairs, including pairs where a member is on unfamiliar ground. This may work for some projects or tasks but it is not going to work for others. Where agile/XP can go wrong is where management/leaders believes that this sort of paired programming is always of benefit.
Plus in the above example basic human psychology is ignored. Some people are most productive when they are not bouncing between different domains every day or two. Some people are wired to work in a more depth first manner, not so much breadth first. To force the later to constantly bounce between domains, well management/leadership is basically sabotaging their efficiency. Perhaps some people should only pair in a new domain every month or two.
Assuming a particular task should be paired at all.
Similar problems can be found in other aspects of agile/xp doctrine. Management/Leadership is hard. There is no magic bullet. Great ideas tend to work best under specific circumstances. Deciding when to stick with doctrine and when to deviate from doctrine, or to pick doctrine A over doctrine B, is what makes it so hard.
Whether its called a payment, tax, royalty or fee is just an accounting gimmick. Perhaps by calling the per barrel money transfer from the oil company to the state a tax there is a federal tax benefit, or some financial report benefit for wall street. Whatever the case, I'm sure the state would be accommodating in calling the per barrel money transfer whatever helps out the oil company. The state could thereby collect a little more than it otherwise could, a win/win for company and state.
Most rivers have little to no potential or kinetic energy. If you can build a dam in a delta you'd obviously do that.
You do not need a dam to harvest the kinetic energy of a river. Think of an old fashioned water wheel turned by small rivers and large streams. Or turbines submerged into a large river, as they are experimenting with in New York City.
Alaskan legislators and Alaskan newspapers seem to agree that oil companies are taxed:
"Kelly, like many lawmakers, believes Alaska's tax structure discourages oil companies from finding and developing more crude. That impacts the state because Alaska depends on oil taxes, royalties and fees to fund most of state government. Even though ACES has created billions of dollars in surplus funds, Parnell, some lawmakers and business leaders worry that the tax is so high that oil companies aren't investing in new production." http://www.alaskadispatch.com/article/20130409/fact-check-what-was-purpose-aces-oil-tax
Slashdot Mirror
... including text messages to those phones that are turned on ...
I think the point of the legislation is to get people to use text rather than voice, text having near zero impact on your fellow passengers.
Not cell phones, but there have definitely been phones available. Some planes even had handsets embedded in the back of the headrests.
And their high cost has moderated their usage. Cell phone usage would be quite different.
... Though many people who have upgraded from Mac OS 10.4 have started to disagree about it not hurting as much ...
Was there something other than Mac OS X 10.5's (2007) dropping of support for legacy Mac OS Classic (the 1984 - 2001 API) that was hurting them?
2: Chip internally stores the last n random numbers that it has output. Later, the NSA can confiscate your computer, subject the chip to some undocumented state that causes it to barf up its secrets, and again all your keys are now utterly, hopelessly broken.
More likely its just going to get the random numbers generated for a video game.
Keylog and steal their credentials and you've got a jumping off point to worm in to the rest of their network.
2-factor authentication helps, the key logger can only get one of the factors. The second, say a time based one time password (TOTP), is still secure.
ZFS has proven that a wide variety of chipset bugs, firmware bugs, actual mechanical failure, etc are still present and actively corrupting our data.
And I expect that defragging aggravates this. Read a perfectly good block of data from disk into flaky RAM, have a bit flip, and write out that corrupted data to its new location. Even if the software is verifying its likely to verify against RAM and it did successfully write what is in RAM.
And then there is over clocking. If a computer is just used for gaming, no problem. But if its used for more serious things or archiving things of value to you then you may want to pass on over clocking. Folks who say you can verify an over clocked CPU are mistaken. Its not a crash or no crash thing, at a certain unpredictable point in over clocking an unpredictable CPU instruction may simply give an incorrect result. This incorrect result could end up in your data or image. I've seen over clocked CPUs mess up a text string that is supplied by the CPU itself, CPUID's vendor string.
Code review is good, but a need to waste code-review time to whack DRM moles...
It could have just as easily been malware. Careful review of outside contributions is a good idea.
I am not saying that something like the Manhattan Project was wrong. I am merely saying that the deep ethical consideration suggested by the author isn't really warranted for mere "technology of violence", that its more appropriate for the WMD end of the spectrum. My understanding is that many of the scientists and engineers who knew the project's actual goal did consider what they were doing before taking the project to completion and I think that was a good thing. I've heard that some of the scientists working on Germany's bomb made some key errors that may not have been accidental. Maybe that's urban myth but If so they may have thought about what they were doing and made a good decision as well.
Its not the scalpel or the gun that is the problem, it is the mind and the intentions behind the hand holding the scalpel or gun.
Medical companies refuse to export drugs to the United States that they know are used in executions. But nobody will stop selling arms to someone else unless and until international law gets involved, and sometimes not even then. It seems pretty clear that those in the field of medicine have a higher moral standard.
You are mistaken. The law restricts both fields.
... The death penalty is banned in the European Union, and the 27-country bloc, of which Germany is a part, bans the export of drugs for use in executions."
"Drugmaker Fresenius Kabi said shipments of the anesthetic propofol were halted to a Louisiana distributor for 4 1/2 months through mid-March because the company feared the European Union would ban export of the drug altogether if it was used in executions
http://worldnews.nbcnews.com/_news/2013/10/11/20911326-german-drug-firm-halts-us-anesthetic-exports-after-finding-it-was-sent-for-executions
To avoid redundancy see http://slashdot.org/comments.pl?sid=4522905&cid=45610821
I'm not sure things are clear on WMDs either. I firmly believe that the invention of the atomic bomb has saved the lives of millions of people over the decades.
I'm not saying that something like the Manhattan Project was wrong, just that I accept the idea that before working on something like the Manhattan Project a bit of thought and soul searching might be a good idea, assuming you knew what the goal actually was. Unlike working on the M1 Garand rifle design team.
Why short of WMD? Presumably the reason we made it from 1945 to now without WW III is because our WMD engineers convinced the other side's engineers that our stuff would really work and vice versa. *note this invovled rational actors and not third world nutcases
I'm not saying something like the Manhattan Project was wrong. However I do accept the idea that before working on something like the Manhattan Project (well, assuming you knew what the goal actually was) would and should require a bit of thought and soul searching. Unlike working on the M1 Garand rifle design team.
"when the rockets go up, who cares where they come down? it's not my department, says Wernher Von Braun."
He didn't say that, but that summarizes the lives of thousands of people who make a living designing and building weapons (except a few fanatics who relish the though that their weapons kill $bad_guy)
That summarizes perhaps a small minority who design and build weapons. Lets consider the M1 Garand Rifle of the U.S. Army and Marine Corp. It was designed during peace time in the 1920s and 30s. It was used to destroy the Third Reich in Europe in the 1940s and in the 1960s it was used by some panicked National Guard to kill students at Kent State University in Ohio. Most of the engineers envisioned a use of the "destroy the Third Reich" type, not the students at Kent State type.
Probably because a Doctor helping torture someone is directly involved. The engineer's creation may be used in a way he/she never invisioned and with no involvement from him./her
Nor even with the knowledge of the ultimate use of his/her creation. Weapons can be used for good, its all about the intentions of those operating the weapons. For example those engineers who worked on weapons used to destroy the Third Reich, many of these were designed during peace time, ex M1 Garand Rifle of the US Army and Marine Corp. Short of WMD things are not so clear.
While it is hard to draw exact parallels, society already holds engineers to similar standards to doctors. The outrage over doctors experimenting on helpless test subjects is pretty similar to, say, when engineers use live subjects for testing weapons.
Yeah. The article's author is making a poor analogy. Blaming engineers would be more akin to blaming the scalpel designer for the doctor's experimentation. Its not the scalpel or the gun that is the problem, it is the mind and the intentions behind the hand holding the scalpel or gun. Both can be used for good or bad.
Short of WMD the issue is not as simple as the author suggests.
if the driver wants to drive a Carrera GT because he thinks it is "cool" then they should only hand them to you if you have the necessary training
This is what is done in aviation in the U.S. If a private pilot wants to fly a high performance aircraft then they need additional training and endorsements for their license. Keep in mind that in aviation high performance is an engine with more than 200 horsepower, we are *not* talking about racing or acrobatic aircraft, simply "excess" horsepower.
The basic idea being that with greater horsepower comes greater speed and with greater speed comes less time to fix a problem or mistake.
Except the driver was a professional who owned a race car shop and had raced many times before. So maybe it was the car.
Watch a professional race (ex. Indianapolis 500, Daytona 500, etc) and you will see experienced professionals make mistakes and crash.
Wow, this part sounds absurd:
For example paired programming with constantly changing pairs, including pairs where a member is on unfamiliar ground.
Is there XP literature actually advocating that, with a theory behind why it's a good idea? Or is this some kind of DIY management innovation?
This is one of those things that will work for some projects and not others. It can be helpful with cross training and works better when the knowledge behind the various parts of the project is somewhat shallow. As it is in some books on Agile/XP where Agile/XP worked out brilliantly for the development team. Beware the manager reading such a book and believing they found the magic bullet.
It seems like agile would be good if you need something quick.
That is sort of the point, you get "something" in a short amount of time, then another "something" in another short amount of time. "Something" doesn't have to be complete and polished, just working so that it can be tried out and evaluated with respect to providing the desired benefit and doing so in a reasonable fashion. Ideally the people who will use the software will be trying these somethings and letting you know if its really heading in the right direction, working in a reasonable manner, etc.
So management hears "Oh it's quicker than what you're doing" and dive on that like a pigeon on a French fry. Honestly the agile I do currently should just be called "go fast, be stupid" because that's how it works out.
Regrettably I've also seen agile/xp go wrong and quality drop. It was more of a management problem, the number of tasks completed were pretty much the only metric devs were evaluated on. So management got what they rewarded, fast task completions. Quality dropped. Management didn't consider in dev evaluations tasks reappearing in future scrums because they were not done quite right the first time. It was quite Dilberte-sque.
Why not just use the river to turn a turbine?
Typically in the coastal plains (where a river would meet with saltwater), a river will widen up and it's current slows to a crawl (due to the lack of a "downhill" presence).
Sure, but we can put water wheels, turbines or something other than a dam up river a bit. Or many along the river. We don't need to be in the mixing zone.
what's wrong with agile?
Nothing in theory, **if** your project meets a certain profile. The real problem is that some people tend to implement an agile process in terrible ways, more so with "extreme programming" (XP). For example paired programming with constantly changing pairs, including pairs where a member is on unfamiliar ground. This may work for some projects or tasks but it is not going to work for others. Where agile/XP can go wrong is where management/leaders believes that this sort of paired programming is always of benefit.
Plus in the above example basic human psychology is ignored. Some people are most productive when they are not bouncing between different domains every day or two. Some people are wired to work in a more depth first manner, not so much breadth first. To force the later to constantly bounce between domains, well management/leadership is basically sabotaging their efficiency. Perhaps some people should only pair in a new domain every month or two.
Assuming a particular task should be paired at all.
Similar problems can be found in other aspects of agile/xp doctrine. Management/Leadership is hard. There is no magic bullet. Great ideas tend to work best under specific circumstances. Deciding when to stick with doctrine and when to deviate from doctrine, or to pick doctrine A over doctrine B, is what makes it so hard.
The more interesting question is "why".
Whether its called a payment, tax, royalty or fee is just an accounting gimmick. Perhaps by calling the per barrel money transfer from the oil company to the state a tax there is a federal tax benefit, or some financial report benefit for wall street. Whatever the case, I'm sure the state would be accommodating in calling the per barrel money transfer whatever helps out the oil company. The state could thereby collect a little more than it otherwise could, a win/win for company and state.
Most rivers have little to no potential or kinetic energy. If you can build a dam in a delta you'd obviously do that.
You do not need a dam to harvest the kinetic energy of a river. Think of an old fashioned water wheel turned by small rivers and large streams. Or turbines submerged into a large river, as they are experimenting with in New York City.
Alaskan legislators and Alaskan newspapers seem to agree that oil companies are taxed:
"Kelly, like many lawmakers, believes Alaska's tax structure discourages oil companies from finding and developing more crude. That impacts the state because Alaska depends on oil taxes, royalties and fees to fund most of state government. Even though ACES has created billions of dollars in surplus funds, Parnell, some lawmakers and business leaders worry that the tax is so high that oil companies aren't investing in new production."
http://www.alaskadispatch.com/article/20130409/fact-check-what-was-purpose-aces-oil-tax
Why not just use the river to turn a turbine?