I don't think they make much economic sense with the moratorium on reprocessing, though. And they haven't had a very good safety record, either. Wikipedia has a pretty good article on the subject: http://en.wikipedia.org/wiki/Breeder_reactor
I doubt those numbers are worth the paper they're (virtually) printed on. For Google, their results are based on TEN responses, according to the article. That's not statistically meaningful for a population of several thousand.
In addition, they don't verify the information they're given (how could they, anyway?), nor do they have any idea who is actually posting those salaries. Interesting idea, but very suspect methodology.
I went through and read the whole report for the specific voting machines in San Mateo county (where I happen to live, too), and they're probably the best of a bad lot (Hart Intercivic eSlate). I'm still left wondering why we want to go through all this expense and difficulty to solve problems that don't even exist for paper ballots, marked by the individual voter.
Yes, yes, I know - it's all the fault of the Help America Vote Act. I really don't buy it that the level of technical work that went into all this precluded simply creating a human- and machine-readable voting record that the voter can drop in a ballot box.
I don't miund if the voting process is assisted by a computer, keeping people from spoiling their ballots by accidentally over-voting, or with stray marks on the ballot. I just want the end result (the thing that's counted) to be something that I can independently verify is correct, and that can be hand-counted.
I'd also argue that hand-counting should be the rule, rather than the error-recovery mechanism, but that idea seems to have remarkably little traction.
It's just great that California has instituted a requirement for a voter-verifiable paper trail for e-voting machines, but the fundamental problems still remain.
The problem with these machines is that there's no guarantee that the ballot that the voter verified actually matches what gets recorded in the memory of the machine, and what eventually gets transmitted upstream.
Yes, a manual recount based on the paper trail would catch massive vote fraud - but that's only going to happen if the results are obviously bogus.
Reading those reports is pretty scary. The state identified a bunch of weaknesses in the various systems, and imposed requirements on the vendors to plug the most egregious security holes. But there are literally DOZENS of operational requirements imposed to ensure that the voting is secure and that the privacy of voters is maintained.
That's not a very good example. Hacking a CVS repository and adding a relatively easy to detect root exploit isn't how you'd want to go about this. It's far too likely to get noticed.
As the parent poster mentioned, you'd ideally want to submit a fairly large patch that does something useful (fixes a bug, adds a minor feature), but whicvh itself contains an exploitable bug.
The trick would be in making the submission large enough and the bug subtle enough that it just skates past review. Of course, it'd be *much* easier to insert bugs into any other Linux project, rather than the kernel. Not as much exposure to ultimately exploit, but there are quite a few executables and libraries that nearly every Linux system uses.
The tungsten filament evaporates, plates out on the glass envelope, where it reacts with the Iodine or Bromine vapor in the lamp, forming a gas, which circulates around to the filament, where the heat breaks it back down into metal.
Unfortunately, this only works correctly if the bulb surface is really hot (250 degrees C, I think), which is why Halogen lamps have to be enclosed, or double-walled, to make them safe o use in the home.
For "regular", non-halogen lights, the tungsten does eventually end up evaporated out onto the glass of the bulb. Tungsten has the advantage of having the highest melting/boiling point of any metal.
It's electrically-driven, so you can easily limit the top speed with software. More to the point - this is a design concept, not a real product. Apparently the designer thought 3 seconds 0-60 would be useful, but that 75 MPH was a fast enough top speed. I'm guessing he's not a motorcycle rider:-)
It's obviously intended to change shape when in motion, hence the pneumatic actuators, etc. While you're racing down the street, it's change into a more-streamlined shape.
I'm not even going to go into the issue of whether it's a good idea to store a database in XML, but you're kind of proving the other guy's point for him when you call that "human readable".
The latest versions of XCode are more user-friendly than previous versions, but feature-wise, Visual Studio has XCode beat by a mile. On the other hand, I find the XCode has the major bases covered quite well, so I don't miss most of the omissions very much.
Young whippersnappers, you've probably never even heard of Turbo Pascal, the dominant development environment on PC's during the 1980's and early 90's. Not to mention the variants of UCSD pascal that were used to proiduce commercial software for other platforms (HP workstations, the Apple II, etc, etc.
For President, Vice President, and Congressional votes, it really should be as simple as counting up columns. For other kinds of races, including local and county offices, you'll often have choices like "choose up to three of the following", or "vote yes or no for each of these". Some are even more-complicated than that.
You also have to detect "invalid" vote combinations, of course - voting for two presidential candidates, for example. That's correspondingly more complicated for the less-straightforward ballots.
So far, the optical-scan ballots seem to be the most reliable method. You still have the complication of the programming electronic tabulators to apply the vote validity check, but that's at least a lot simpler code than a full-on GUI for touch-screen voting.
Having said all that - you're right, it shouldn't be all that hard.
If you're developing a library that other people depend on, then unit testing is invaluable. It's difficult to know in advance which ways other people will try to abuse your code. Unit testing (including all the obvious boundary cases) makes for much more reliable code. The unit tests are also handy when the code needs to be re-factored - which will happen eventually, to pretty much any code that is used for more than one application.
In the US, you can't be fired due to being called for Jury duty. Unfortunately, your employer isn't required to keep paying you (some will, some won't), and the government only pays a few dollars a day.
According to http://www.uscourts.gov/jury/jurypay.html Federal Jurors make $40 a day ($50/day if the trial goes over a month). That's less than the federally-mandated minimum wage for private employers, assuming an 8-hour day. Other types of courts can pay much less - the county court near me pays $15/day.
This is one of the major problems in our jury system, as far as I'm concerned. If I'm ever in serious trouble, I really don't want to be tried by a group of twelve people who either couldn't figure out how to get out of jury duty, or who actually think $40 a day is a good deal.
The idea is that you'd use unused capacity on existing machines. Their cost estimates are just for the additional equipment - it doesn't include the cost of the drives, since you'll have to buy them anyway...
Basically, that term is meant to tell you that a particular system can perform any calculation that you could perform on a Turing Machine, which is a minimalist calculating machine devised by Alan Turing, to explore what "computability" means, in a mathematical sense.
The Turing Machine is very simple, but given unbounded time and storage, it is believed to be able to calculate anything that can be described by a discrete set of steps (i.e. an algorithm).
Where this gets interesting for evaluating computer systems is that, if you can prove that it's possible to simulate a Turing Machine in a particular hardware/software system, that means that you can use that system to implement any algorithm that you can implement on any other deterministic computer system.
This doesn't say anything about the efficiency of that implementation. For example, it's easy to write a program that emulates an old 8-bit processor on a modern 32-bit CPU. It's nearly as easy to write a program that runs on an 8-bit CPU and emulates a Core2 Duo processor.
One key difference between those two emulators would be performance - you can easily emulate an 8-bit processor running at several megahertz on a 32-bit CPU, but emulating a 32-bit CPU on an 8-bit processor will be orders of magnitude slower than real time.
C++ is this massive, complex language. It's not at all unusual to take YEARS to get very proficient in C++.
By comparison, Objective-C is much simpler. Since all message dispatching is dynamic, you don't have the virtual/non-virtual distinction to deal with, there's only one "kind" of casting, there's no operator overloading, and no use of Templates to specialize collections for a particular type (collections are all heterogenous).
If you're targeting 64-bit exclusively, you can also count on all of the Objective-C 2.0 features being there, like garbage collection, Properties, Fast Enumeration, and non-fragile member access.
Most people can't drive in 2 Dimensions so I fail to see how adding a 3rd is going to help.
Obviously, the 3rd dimension would only be used by those of us that DO know how to drive, so that'd eliminate a lot of congestion right there.
I'm only half-kidding, here. If you set up your flying car to do a direct flight from home to work, with the minimal fuel use, and all of your neighbors do the same, how close do you think your car is going to get to theirs, on average? If you had a reliable plot of what path every car in the neighborhood was on, how hard would it be to assure a minimum safe distance between yours and the others?
Most people imagine flying cars running in lanes just like the 2D road grids we have now - you see that all the time in Sci-Fi movies. But the road grid is an artifact of the need to pave roads for cars to travel on. To a flying car, any airspace is just as good as any other.
Yes, there's no way that arbitrary flightplans would work in the city. Then again, driving a car in the city doesn't make much sense, either.
Super-strong electromagnets are one application of current superconductors. There are a number of uses for such magnets in space, from reaction engine control, to ion thrusters, to magnetic "sails", to gathering fuel for a Bussard ramjet.
Magnets can also be used to direct dangerous radiation away from ships and the crew, in a phenomenon similar to the cause of the auroras that light up the night skies here on earth.
The raytracing applications used for optical system design can do wavefront analysis, as well as wavelength-based dispersion measurements. Calculating the phase of a wavefront at a surface is basically just a distance measurement (taking into account refraction).
It's just a bit more work, and would be unnecessary for most "realistic" scenes, which is why raytracers designed to produce pretty pictures usually skip those features.
I see phase-based optical effects fairly rarely out in the real world (as opposed to in a lab), and I suspect most folks would have never even noticed them.
There are explosives that get some/most of their bang from Nitrogen - azides, hydrazines, maybe half a dozen or so more-exotic things. However, I was responding to someone who was saying that anything with enough nitrogen can be made into an explosive.
Not all liquid explosives are volatile, but it helps. Anything with enough nitrogen content is able to be turned into an explosive, it's just a matter of how much work is involved for each compound. I think you mean "anything with enough Oxygen content". Nitrogen doesn't contribute to explosive power. Many explosives are nitrates, but it's the Oxygen in the compound that makes them explosive, not the Nitrogen. Among the other explosive compounds they're looking for are chlorates and peroxides, neither of which contain Nitrogen.
Slashdot Mirror
I don't think they make much economic sense with the moratorium on reprocessing, though. And they haven't had a very good safety record, either. Wikipedia has a pretty good article on the subject:
http://en.wikipedia.org/wiki/Breeder_reactor
I doubt those numbers are worth the paper they're (virtually) printed on. For Google, their results are based on TEN responses, according to the article. That's not statistically meaningful for a population of several thousand.
In addition, they don't verify the information they're given (how could they, anyway?), nor do they have any idea who is actually posting those salaries. Interesting idea, but very suspect methodology.
I went through and read the whole report for the specific voting machines in San Mateo county (where I happen to live, too), and they're probably the best of a bad lot (Hart Intercivic eSlate). I'm still left wondering why we want to go through all this expense and difficulty to solve problems that don't even exist for paper ballots, marked by the individual voter.
Yes, yes, I know - it's all the fault of the Help America Vote Act. I really don't buy it that the level of technical work that went into all this precluded simply creating a human- and machine-readable voting record that the voter can drop in a ballot box.
I don't miund if the voting process is assisted by a computer, keeping people from spoiling their ballots by accidentally over-voting, or with stray marks on the ballot. I just want the end result (the thing that's counted) to be something that I can independently verify is correct, and that can be hand-counted.
I'd also argue that hand-counting should be the rule, rather than the error-recovery mechanism, but that idea seems to have remarkably little traction.
It's just great that California has instituted a requirement for a voter-verifiable paper trail for e-voting machines, but the fundamental problems still remain.
The problem with these machines is that there's no guarantee that the ballot that the voter verified actually matches what gets recorded in the memory of the machine, and what eventually gets transmitted upstream.
Yes, a manual recount based on the paper trail would catch massive vote fraud - but that's only going to happen if the results are obviously bogus.
The results of the voting machine review that the CA Secretary of State performed are here:
http://www.sos.ca.gov/elections/elections_vsr.htm
Reading those reports is pretty scary. The state identified a bunch of weaknesses in the various systems, and imposed requirements on the vendors to plug the most egregious security holes. But there are literally DOZENS of operational requirements imposed to ensure that the voting is secure and that the privacy of voters is maintained.
I was even going to call out the Debian OPENSSL debacle as an example, but I figured they'd had enough grief over it already.
That's not a very good example. Hacking a CVS repository and adding a relatively easy to detect root exploit isn't how you'd want to go about this. It's far too likely to get noticed.
As the parent poster mentioned, you'd ideally want to submit a fairly large patch that does something useful (fixes a bug, adds a minor feature), but whicvh itself contains an exploitable bug.
The trick would be in making the submission large enough and the bug subtle enough that it just skates past review. Of course, it'd be *much* easier to insert bugs into any other Linux project, rather than the kernel. Not as much exposure to ultimately exploit, but there are quite a few executables and libraries that nearly every Linux system uses.
The tungsten filament evaporates, plates out on the glass envelope, where it reacts with the Iodine or Bromine vapor in the lamp, forming a gas, which circulates around to the filament, where the heat breaks it back down into metal.
Unfortunately, this only works correctly if the bulb surface is really hot (250 degrees C, I think), which is why Halogen lamps have to be enclosed, or double-walled, to make them safe o use in the home.
For "regular", non-halogen lights, the tungsten does eventually end up evaporated out onto the glass of the bulb. Tungsten has the advantage of having the highest melting/boiling point of any metal.
It's electrically-driven, so you can easily limit the top speed with software. More to the point - this is a design concept, not a real product. Apparently the designer thought 3 seconds 0-60 would be useful, but that 75 MPH was a fast enough top speed. I'm guessing he's not a motorcycle rider :-)
It's obviously intended to change shape when in motion, hence the pneumatic actuators, etc. While you're racing down the street, it's change into a more-streamlined shape.
I'm not even going to go into the issue of whether it's a good idea to store a database in XML, but you're kind of proving the other guy's point for him when you call that "human readable".
The latest versions of XCode are more user-friendly than previous versions, but feature-wise, Visual Studio has XCode beat by a mile. On the other hand, I find the XCode has the major bases covered quite well, so I don't miss most of the omissions very much.
Young whippersnappers, you've probably never even heard of Turbo Pascal, the dominant development environment on PC's during the 1980's and early 90's. Not to mention the variants of UCSD pascal that were used to proiduce commercial software for other platforms (HP workstations, the Apple II, etc, etc.
For President, Vice President, and Congressional votes, it really should be as simple as counting up columns. For other kinds of races, including local and county offices, you'll often have choices like "choose up to three of the following", or "vote yes or no for each of these". Some are even more-complicated than that.
You also have to detect "invalid" vote combinations, of course - voting for two presidential candidates, for example. That's correspondingly more complicated for the less-straightforward ballots.
So far, the optical-scan ballots seem to be the most reliable method. You still have the complication of the programming electronic tabulators to apply the vote validity check, but that's at least a lot simpler code than a full-on GUI for touch-screen voting.
Having said all that - you're right, it shouldn't be all that hard.
If you're developing a library that other people depend on, then unit testing is invaluable. It's difficult to know in advance which ways other people will try to abuse your code. Unit testing (including all the obvious boundary cases) makes for much more reliable code. The unit tests are also handy when the code needs to be re-factored - which will happen eventually, to pretty much any code that is used for more than one application.
In the US, you can't be fired due to being called for Jury duty. Unfortunately, your employer isn't required to keep paying you (some will, some won't), and the government only pays a few dollars a day.
According to http://www.uscourts.gov/jury/jurypay.html Federal Jurors make $40 a day ($50/day if the trial goes over a month). That's less than the federally-mandated minimum wage for private employers, assuming an 8-hour day. Other types of courts can pay much less - the county court near me pays $15/day.
This is one of the major problems in our jury system, as far as I'm concerned. If I'm ever in serious trouble, I really don't want to be tried by a group of twelve people who either couldn't figure out how to get out of jury duty, or who actually think $40 a day is a good deal.
The idea is that you'd use unused capacity on existing machines. Their cost estimates are just for the additional equipment - it doesn't include the cost of the drives, since you'll have to buy them anyway...
Basically, that term is meant to tell you that a particular system can perform any calculation that you could perform on a Turing Machine, which is a minimalist calculating machine devised by Alan Turing, to explore what "computability" means, in a mathematical sense.
The Turing Machine is very simple, but given unbounded time and storage, it is believed to be able to calculate anything that can be described by a discrete set of steps (i.e. an algorithm).
Where this gets interesting for evaluating computer systems is that, if you can prove that it's possible to simulate a Turing Machine in a particular hardware/software system, that means that you can use that system to implement any algorithm that you can implement on any other deterministic computer system.
This doesn't say anything about the efficiency of that implementation. For example, it's easy to write a program that emulates an old 8-bit processor on a modern 32-bit CPU. It's nearly as easy to write a program that runs on an 8-bit CPU and emulates a Core2 Duo processor.
One key difference between those two emulators would be performance - you can easily emulate an 8-bit processor running at several megahertz on a 32-bit CPU, but emulating a 32-bit CPU on an 8-bit processor will be orders of magnitude slower than real time.
C++ is this massive, complex language. It's not at all unusual to take YEARS to get very proficient in C++.
By comparison, Objective-C is much simpler. Since all message dispatching is dynamic, you don't have the virtual/non-virtual distinction to deal with, there's only one "kind" of casting, there's no operator overloading, and no use of Templates to specialize collections for a particular type (collections are all heterogenous).
If you're targeting 64-bit exclusively, you can also count on all of the Objective-C 2.0 features being there, like garbage collection, Properties, Fast Enumeration, and non-fragile member access.
Obviously, the 3rd dimension would only be used by those of us that DO know how to drive, so that'd eliminate a lot of congestion right there.
I'm only half-kidding, here. If you set up your flying car to do a direct flight from home to work, with the minimal fuel use, and all of your neighbors do the same, how close do you think your car is going to get to theirs, on average? If you had a reliable plot of what path every car in the neighborhood was on, how hard would it be to assure a minimum safe distance between yours and the others?
Most people imagine flying cars running in lanes just like the 2D road grids we have now - you see that all the time in Sci-Fi movies. But the road grid is an artifact of the need to pave roads for cars to travel on. To a flying car, any airspace is just as good as any other.
Yes, there's no way that arbitrary flightplans would work in the city. Then again, driving a car in the city doesn't make much sense, either.
Super-strong electromagnets are one application of current superconductors. There are a number of uses for such magnets in space, from reaction engine control, to ion thrusters, to magnetic "sails", to gathering fuel for a Bussard ramjet.
Magnets can also be used to direct dangerous radiation away from ships and the crew, in a phenomenon similar to the cause of the auroras that light up the night skies here on earth.
The raytracing applications used for optical system design can do wavefront analysis, as well as wavelength-based dispersion measurements. Calculating the phase of a wavefront at a surface is basically just a distance measurement (taking into account refraction).
It's just a bit more work, and would be unnecessary for most "realistic" scenes, which is why raytracers designed to produce pretty pictures usually skip those features.
I see phase-based optical effects fairly rarely out in the real world (as opposed to in a lab), and I suspect most folks would have never even noticed them.
There are explosives that get some/most of their bang from Nitrogen - azides, hydrazines, maybe half a dozen or so more-exotic things. However, I was responding to someone who was saying that anything with enough nitrogen can be made into an explosive.
This has to have been accidentally published in the wrong month. It's clearly intended for April. What kind of Fools are running that magazine?
The XO touchpad seems to need recalibration from time to time. There's a magic key sequence to do that:
http://wiki.laptop.org/go/Recalibrating_Touchpad
I find this helps a lot when I'm having touchpad issues. Supposedly, the next revision of the hardware will fix this.