> did not have intent to commit a criminal offense by accessing the information,
When the computer hacking laws were introduced, that was one of the drawbacks: Intent does not matter, for the law. So in this case, it is just the law enforcement being nice in not pursuing the case while they are convinced there was no intent.
But according to the letter of the law, intent does not matter!
So when something unexpected happend, like a few years back in Japan, you don't have the waste slowly seeping through the ground possibliy a little bit leaking into the ocean, but when something bad happens, the all the radioactive stuff is immediately in the water and you have a global problem. Nothing to worry about. We've thought about everything.... Right!
Everybody is saying fine them. That may not be easy....
Normally you'd say: Mr Johnson, stop calling 911 unnecessarily. Then, Mr Johnson,/your/ phone called 911 again, next time you'll be fined. And the next time you slap the fine on the owner of the phone, a certain Mr Johnson. Mr Johnson says: "it wasn't me", but the authorities say: "its your phone, your responsibility".
But now you have a place that originates a bunch of those fake 911 calls, but every time it's a different phone. So now how do you get that fine in the right place?
Anyway... As the cause, I suspect two options. Either they are triggering the 911 calls accidentally. On the other hand, they might be doing a functionality test: Can this phone make calls after having been taken apart and reassembled? If they don't have the users finger for the fingerprint unlock and/or the unlock code, then how do you test "making a call"?
I read the doctorate thesis from a medical doctor. She is investigating an illness that is hard to measure. You can take a sample from a patient and look at it and say: yes he/she has the disease. If you guess wrong as to where to take that sample, you see nothing: normal tissue. But you still don't know if the patient has the disease. So there is a need for some "blood test" that says: "yes you have it" or "no you don't".
So she took a group of 200 patients and 200 healthy people, measured everything that could be measured and ran some regressions. With a 95% confidence interval, you should EXPECT 5% of the "has nothing to do with it" parameters to show a result.
These results are reported as: "We observed a significant correlation between the test of this parameter and having the disease or not". As if the correlation is proven. And that's what the statistics programs say when you put in the data: There is a significant correlation. But that's not what's going on.
If I ask 100 women and 100 men to roll dice. Once for each category numbered 1-1000. Put all the rolls in a statistics program and voila. With 95% confidence the program will say that category X correlates with being male or female. THATs what's going on.
Now with my doctored experiment, everybody knows the results are bogus. But when it is "things we measured in 100 patients and 100 healthy people", you cannot know offhand that the results are bogus.
So, the reporting party SHOULD realize that the correlations might be caused by statistical fluctuations. I seriously doubt that they realize. They are convinced by the statistics program reporting a significant difference between the groups.
So when such a "fluke" is reported, does the article need retraction? Afterwards, when that correlation is debunked, you say that you honestly reported the results from your study and no misconduct is found, right? And no retraction happens.
Lets do some calculations. Lets start with a 737 class plane. Empty I found figures of just less than 40 tonnes, the highest MTOW I could find was 70 tonnes. Probably not for the same plane, but lets just take the extremes. That leaves 30 tonnes of fuel or in this case batteries. We're neglecting the fact that we might want to take along some passengers and freight, but this is back-of-the-envelope....
Now I happen to have a few batteries that are not all bad at the energy density. 1.5kg for 800kJ So our electric plane can take along about 20000 of these batteries for about 16GJ of energy.
Now... in 1.5 hours of flight, for safety you really want for 2 hours worth of fuel. (regulations require more than 45 minutes of extra fuel, but back-of-the-envelope, remember?). In those two hours you'd normally fly about 1600km, but let us round that down to 600km/h, or 1200km. At a glide ratio of 20 (current planes reach about 18, so some improvement is required), that means you need to spend about 1200km/20 * 70 tonnes * G = 42GJ of energy. That's the prop-output energy, so prop-input energy is going to be more on the order of 60GJ. (props are max 70% efficient).
So there is a factor of 4 to 6 to gain in terms of energy density for LIPO batteries before you can fly a commercial plane for 2 hours on batteries. (the "6" there comes from the fact that the difference between MTOW and empty weight is not all batteries).
Such a big improvement of energy density sounds a bit far fetched to me.
The thing is that with nuclear power, all the people operating one say that the chances of their plant blowing up is on the order of 1 in a million per year or less. But over the past 5 decades we've seen WAY more bad mishaps happening causing damage to a very large area.... So the conclusion MUST be: We cannot safely use nuclear power on this planet.
I have programmed this type of learning algorithm in the past. About 30 years ago when computers were about 30000 times slower than now.
Anyway, you can have the program play itself for a while and it becomes quite good. But you won't know how it will perform against a human unless you try. It might be very good against those moves that the computer player will come up with, but very bad against moves thought up by a human.
A long time ago, I needed to develop something on an FPGA from Xilinx. Told them we needed the sofware to work by then-and-then (weeks in advance) and weeks past said date we still didn't have anything. So after some angry phone calls they agreed to send us a licence for the software on a Unix server for the time until our PC dongle would arrive. They planned a day overlap between our dongle arriving and the end of the unix-workstation-licence. With a week additional delay in the dongle I suddenly had nothing to do for a day except stare at the binary for the Xilinx software... Somehow the disk developed a few bit-errors. A couple of NOP instructions materialized where function calls used to be. The dongle was shoved in a closet when it finally came.
Not having read the whole technical article, just the summary here on slashdot....
The fact that YOU cannot find an algorithm that simulates something in linear time, that doesn't mean it's impossible.
Moreover, there are some things that you don't HAVE to be able to calculate. Say the multiple bodies in a gravitational field problem. We can't solve that for N>2 . Do I have to if I'm running a simulation? No! That "being able to solve" would mean that to find the position of Jupiter's moons 10000 years from now, you just put the number 10000 in some formula and out comes an accurate prediction of the positions of those moons. But if you're running a simulation you just have to extrapolate a small step from the current situation for the next time quantum. Even if it is (shown to be) fundamentally unsolvable, that does not hurt the ability to run a simulation.
The shuttle was throttled back to stay below 3G. This would do something similar.
Looking up the specs for Falcon 9 FT... It seems it gets about 770 tonnes of thrust for a mass of 550 tonnes. About 1.4G, or the same as what you get when an airplane accelerates at 1G across the runway.
For me 4G is uncomfortable, but manageable, 6G "lets get out of here". (seated, not reclined). recline the seats and most people will tolerate 2G or 3G for 2-3 minutes that it takes to get well on your way to orbit.
People are notably bad at correctly estimating risks.
If, once in a lifetime, you take a 1/100 risk of dying, that's an acceptable risk. Most of us had one of those moments: "phew that could've gone horribly wrong". But if you take such risks every day on your way to work, you're not going to last a year (about half a year on average and contrary to my statement there is about a 13% chance you will survive the whole first year).
To make a sensible decision about "risky" events, you need to overestimate the risk of doing it once. Even if spaceX would manage to get a 99% success rate, that remaining 1% would make it a fun thing to do "once in a lifetime", but foolish as an every day commute to work.
> With so few aircraft in production/operation, there was no economy of > scale in production or maintenance, making the planes incredibly > expensive to operate. That is probably not true. As soon as you need 1 full-time engineer to maintain a plane, you'll need two for two planes. It's like the one woman one baby in 9 months trick. You can't hire nine women to make a baby in one month. But "maintaining planes" operates at a scale where this does work.
I've been looking at the energy-balance of this project. Comparing it with the energy consumption of a transatlantic flight is the key insight!
An airplane has a "best glide" ratio of about 1:20. (that's optimistic by about 10%, but we're calculating order-of-magnitude here). This means that for traveling 200km, you need the energy to lift the whole thing 10km vertically. So, doing New York to London, 5500 km, you consume energy to bring the whole plane up 275 km into the air, or g.h = 2.7 MJ/kg. In practice this is a bit optimistic: during takeoff and landing the plane is not flying in best-glide configuration or at best-glide speed. Also in cruise, you want to expend some extra energy to get to the destination faster. At the optimum speed for best energy consumption, adding a tiny bit of extra speed will not influence fuel consumption much but it WILL get you to the destination faster. Less wages for the pilots and other crew, less write off on the plane. So that makes economic sense.
Now, it'd be nice if you could just go up (less than) 275km and come down anywhere on earth that you want. But to do that you have to reach orbital speed of almost 8km/s. This adds some energy requirements to the trip: 1/2 v^2 =.5*8*8*10^6 = 32MJ/kg..... I'm ignoring the amount of energy required to leave the atmosphere (100km up, about 1MJ/kg).
So.... in terms of required energy to make a trip like that, you're going to need about 10 times more than for a transatlantic trip. Because the energy requirements of the spaceship idea don't change (much) for how far you want to go, this gets 2x or even almost 4x better if you want to go to exactly the opposite side of the earth (20000km).
Now, if you are transporting 440 people in a 220 tonne 747-800, you're taking along half a tonne of airplane for each person aboard. If you can improve on that ratio, things may start to look promising for the rocket idea.
But probably not for the short haul Los Angeles to Toronto stretches but only for the long haul: more than 13000km trips.
And one more thing. Everybody likes to talk about the 30 minute flight time for this rocket thing. Or the say the 2 hour flight time from Houston Texas to Tallahassee Florida. But the hassle at the airport is slowing you down. Be there an hour before departure to check in your luggage, half an hour drive to the airport, half an hour waiting for your luggage to appear at the destination, so you're easily wasting 2 hours around a 2 hour flight. Even with a "short boat trip to the floating platform", this is not going to be less for a rocket trip. If you reduce the flight time to 30 minutes the "overhead percentage" will increase.
These algorithms that recognize faces, fingerprints or other "difficult" things are usually just doing binary comparisons: how likely is the subject the one from database-picture 1? 2? 3? There is a number from 0-1 that represents the likelihood of a match.
So when forced to make a decision, you take the one with the highest number, provided that numbers is larger than say 0.5 or 0.8 or whatever threshold you choose. These things work just fine with 100 or 300 subjects in the database, but once you actually start using this in real life you're going to fill up the database with thousands and then ten thousands of possible matches. That's when the reliability goes down enormously. False positives: I see subject X while that person is not in the database at all, or I see subject X when it's actually subject Y who is in the database as well.
To perform a valid test you should find 40000 other photos and put those in the database as well before you start testing....
They flagged my public wiki as falling under the new policy. So someone who posts something on this wiki runs the risk of having their contribution changed by a man-in-the middle. (besides running the risk of someone just going to the wiki and changing their contribution the proper way).
Just FYI: On Linux IRQ handlers can never be paged out on a very fundamental level.
You might think it's useful, but the thinking is that it just MIGHT be the IRQ (kernel memory) for the "get it back from disk" part. So in general stuff like that is never paged out. In modern systems you'll probably use maybe 3-10Mb of memory for kernel code. If you have little main memory (1GB) that's still less than 1%. So no reason at all to change this policy.
There MUST be some things in hardware to execute anything. While they (the chip manufacturers) have surprised me in the past, not all bugs CAN be fixed with a microcode update.
A long, long time ago, people wrote "self modifying code". Say for doing bit-operations on parts of the screen buffer, you might pass 1 for AND 2 for OR and 3 for XOR. The function could then place the AND/OR/XOR opcode in the middle of the doit loop and then perform the loop.... So one day the manufacturer guarantees that the new machine will execute everything the old one did. Bad move. Turns out the new machine is faster because it prefetches instructions. By the time the code has determined the opcode for inside the loop, the loop (with the last AND/OR/XOR opcode in place) has already been prefetched. This prefetching is at the core of why the machine is fast. Implemented in hardware. Can you fix that with a microcode update? Apparently in the case at hand (PR1ME9955): yes.
But I can easily see it happen that either you disable the whole prefetching stuff (slow everything down enormously) or you need say an extra comparator ("Is the store happening near my PC, possibly near my prefetch queue?") to allow for "normal" cases to use the prefetch queue, but this special case to flush the queue only when necessary. In any case, the microcode was updated and stuff worked properly again.
What is happening is that the CPU will mis-execute some instruction so that some "data" becomes invalid. When a compiler is running such data is often a pointer and the wrong pointer often results in a segfault.
But especially while we don't know what's going on exactly, this could also corrupt data. i.e. give the wrong results in a computation, or result in a bad binary when the running program is a compiler.
So you're suggesting I trust the resulting binaries when the compilation doesn't segfault? Even when I have to try several times? Ehh. not me!
The problem with current research in semi-soft sciences like biology and medicine is that the scientists use this p-value wrong.
If you suspect a glass of wine a day will lower chances of heart disease, take 1000 volunteers, roll a dice and half of them you tell to not have that wine-a-day and the other half you tell, please drink one glass of wine a day. Next you wait two years, and evaluate the incidence of heart problems in the two groups. That's where 0.05 P-value is acceptable. (in practice, telling people ot suddenly stop or start drinking is not going to go well).
Things become problematic when you suspect: "something we can measure may be related to this disease" (e.g. Sarcoidosis), you take 200 patients and 200 healthy people and then measure 200 parameters in each of the 400 blood samples... Provided there is little to measure, you'll find about 1/20th or about 10 parameters that DO seem to be (p=0.05) different between the two groups.
In the case at hand one or two measurable parameters ARE, different in the patient-group. So you'll have a better than 95% chance of finding those. Of the 198 other parameters you'll find 1/20th of false positives, for a total of almost 12 publishable results.
Should you want to increase your chances of finding these publishable results, the sample size needs to be relatively small. The group of 200 patients and 200 healthy people might already be too big to get enough spurious results. Even if they don't do this consciously, the scientists will quickly be able ot optimize their sample size to find publishable results.
When I was a freshman in 1985, some guy asked me to help him put his research in the computer. He had formulated 50 or so questions and predicted boys would answer differently than girls. So he went into a classroom, interviewed 30 boys and girls and put his results in the computer. Of course the computer told him there were several significant differences between boys and girls. Some of them real (do you like to play with trains? Dolls?) some of them not (I don't remember the example).
The other example is more recent. A Dutch Doctor got her PhD with (among others) the described sarcoidosis research. But my run-ins with subject are very limited simply because I don't move in those circles. This is way more widespread than just the few examples that I encounter personally.
Then people try to "fix" this by proposing the wrong solutions.
The research: "can we find a parameter that allows us to differentiate between the two groups" is very important as well. But you have to do your research in the right way. Take 100 patients and 100 healthy people and find the parameters that seem to make a difference. NOW you go into the second half of the research with a hypothesis: "this parameter is important" and verify your claim. Now the p=0.05 is acceptable. (a 5% chance that you're wrong, as opposed to a 95% chance your'e full of shit).
I used to take a drug where in the small print the expiration date was explained that at that date they guaranteed 99% of the active substance to be still present. With me being on a "high dosage" I took 3000mg/day. Lower dosage options were 1000mg/day and 2000mg/day. i.e. when the doctor wants you to take 2100mg (it's not that accurate), he'll have to prescribe 3000.
In short, it wouldn't even be all that bad if say 10% of the stuff was inactivated by a timed decay.
Slashdot Mirror
> did not have intent to commit a criminal offense by accessing the information,
When the computer hacking laws were introduced, that was one of the drawbacks: Intent does not matter, for the law. So in this case, it is just the law enforcement being nice in not pursuing the case while they are convinced there was no intent.
But according to the letter of the law, intent does not matter!
So when something unexpected happend, like a few years back in Japan, you don't have the waste slowly seeping through the ground possibliy a little bit leaking into the ocean, but when something bad happens, the all the radioactive stuff is immediately in the water and you have a global problem. Nothing to worry about. We've thought about everything.... Right!
Everybody is saying fine them. That may not be easy....
Normally you'd say: Mr Johnson, stop calling 911 unnecessarily. Then, Mr Johnson, /your/ phone called 911 again, next time you'll be fined. And the next time you slap the fine on the owner of the phone, a certain Mr Johnson. Mr Johnson says: "it wasn't me", but the authorities say: "its your phone, your responsibility".
But now you have a place that originates a bunch of those fake 911 calls, but every time it's a different phone. So now how do you get that fine in the right place?
Anyway... As the cause, I suspect two options. Either they are triggering the 911 calls accidentally. On the other hand, they might be doing a functionality test: Can this phone make calls after having been taken apart and reassembled? If they don't have the users finger for the fingerprint unlock and/or the unlock code, then how do you test "making a call"?
I read the doctorate thesis from a medical doctor. She is investigating an illness that is hard to measure. You can take a sample from a patient and look at it and say: yes he/she has the disease. If you guess wrong as to where to take that sample, you see nothing: normal tissue. But you still don't know if the patient has the disease. So there is a need for some "blood test" that says: "yes you have it" or "no you don't".
So she took a group of 200 patients and 200 healthy people, measured everything that could be measured and ran some regressions. With a 95% confidence interval, you should EXPECT 5% of the "has nothing to do with it" parameters to show a result.
These results are reported as: "We observed a significant correlation between the test of this parameter and having the disease or not". As if the correlation is proven. And that's what the statistics programs say when you put in the data: There is a significant correlation. But that's not what's going on.
If I ask 100 women and 100 men to roll dice. Once for each category numbered 1-1000. Put all the rolls in a statistics program and voila. With 95% confidence the program will say that category X correlates with being male or female. THATs what's going on.
Now with my doctored experiment, everybody knows the results are bogus. But when it is "things we measured in 100 patients and 100 healthy people", you cannot know offhand that the results are bogus.
So, the reporting party SHOULD realize that the correlations might be caused by statistical fluctuations. I seriously doubt that they realize. They are convinced by the statistics program reporting a significant difference between the groups.
So when such a "fluke" is reported, does the article need retraction? Afterwards, when that correlation is debunked, you say that you honestly reported the results from your study and no misconduct is found, right? And no retraction happens.
Lets do some calculations. Lets start with a 737 class plane. Empty I found figures of just less than 40 tonnes, the highest MTOW I could find was 70 tonnes. Probably not for the same plane, but lets just take the extremes. That leaves 30 tonnes of fuel or in this case batteries. We're neglecting the fact that we might want to take along some passengers and freight, but this is back-of-the-envelope....
Now I happen to have a few batteries that are not all bad at the energy density. 1.5kg for 800kJ
So our electric plane can take along about 20000 of these batteries for about 16GJ of energy.
Now... in 1.5 hours of flight, for safety you really want for 2 hours worth of fuel. (regulations require more than 45 minutes of extra fuel, but back-of-the-envelope, remember?). In those two hours you'd normally fly about 1600km, but let us round that down to 600km/h, or 1200km. At a glide ratio of 20 (current planes reach about 18, so some improvement is required), that means you need to spend about 1200km/20 * 70 tonnes * G = 42GJ of energy. That's the prop-output energy, so prop-input energy is going to be more on the order of 60GJ. (props are max 70% efficient).
So there is a factor of 4 to 6 to gain in terms of energy density for LIPO batteries before you can fly a commercial plane for 2 hours on batteries. (the "6" there comes from the fact that the difference between MTOW and empty weight is not all batteries).
Such a big improvement of energy density sounds a bit far fetched to me.
"Government officials confirm the mission was lost".
Now you might doubt the veracity of that statement and keep your tinfoil hat on, but it doesn't get more certain than that.
This: "rumors are going around that" story is simply a few hours older than the "it has been confirmed that"....
http://www.cbc.ca/news/technol...
http://money.cnn.com/2018/01/0...
The thing is that with nuclear power, all the people operating one say that the chances of their plant blowing up is on the order of 1 in a million per year or less. But over the past 5 decades we've seen WAY more bad mishaps happening causing damage to a very large area.... So the conclusion MUST be: We cannot safely use nuclear power on this planet.
I have programmed this type of learning algorithm in the past. About 30 years ago when computers were about 30000 times slower than now.
Anyway, you can have the program play itself for a while and it becomes quite good. But you won't know how it will perform against a human unless you try. It might be very good against those moves that the computer player will come up with, but very bad against moves thought up by a human.
30 years ago I tackled a simpler game than go.
A long time ago, I needed to develop something on an FPGA from Xilinx. Told them we needed the sofware to work by then-and-then (weeks in advance) and weeks past said date we still didn't have anything. So after some angry phone calls they agreed to send us a licence for the software on a Unix server for the time until our PC dongle would arrive. They planned a day overlap between our dongle arriving and the end of the unix-workstation-licence. With a week additional delay in the dongle I suddenly had nothing to do for a day except stare at the binary for the Xilinx software... Somehow the disk developed a few bit-errors. A couple of NOP instructions materialized where function calls used to be. The dongle was shoved in a closet when it finally came.
Not having read the whole technical article, just the summary here on slashdot....
The fact that YOU cannot find an algorithm that simulates something in linear time, that doesn't mean it's impossible.
Moreover, there are some things that you don't HAVE to be able to calculate. Say the multiple bodies in a gravitational field problem. We can't solve that for N>2 . Do I have to if I'm running a simulation? No! That "being able to solve" would mean that to find the position of Jupiter's moons 10000 years from now, you just put the number 10000 in some formula and out comes an accurate prediction of the positions of those moons. But if you're running a simulation you just have to extrapolate a small step from the current situation for the next time quantum. Even if it is (shown to be) fundamentally unsolvable, that does not hurt the ability to run a simulation.
The shuttle was throttled back to stay below 3G. This would do something similar.
Looking up the specs for Falcon 9 FT... It seems it gets about 770 tonnes of thrust for a mass of 550 tonnes. About 1.4G, or the same as what you get when an airplane accelerates at 1G across the runway.
For me 4G is uncomfortable, but manageable, 6G "lets get out of here". (seated, not reclined). recline the seats and most people will tolerate 2G or 3G for 2-3 minutes that it takes to get well on your way to orbit.
People are notably bad at correctly estimating risks.
If, once in a lifetime, you take a 1/100 risk of dying, that's an acceptable risk. Most of us had one of those moments: "phew that could've gone horribly wrong". But if you take such risks every day on your way to work, you're not going to last a year (about half a year on average and contrary to my statement there is about a 13% chance you will survive the whole first year).
To make a sensible decision about "risky" events, you need to overestimate the risk of doing it once.
Even if spaceX would manage to get a 99% success rate, that remaining 1% would make it a fun thing to do "once in a lifetime", but foolish as an every day commute to work.
> With so few aircraft in production/operation, there was no economy of
> scale in production or maintenance, making the planes incredibly
> expensive to operate.
That is probably not true. As soon as you need 1 full-time engineer to maintain a plane, you'll need two for two planes. It's like the one woman one baby in 9 months trick. You can't hire nine women to make a baby in one month. But "maintaining planes" operates at a scale where this does work.
I've been looking at the energy-balance of this project. Comparing it with the energy consumption of a transatlantic flight is the key insight!
An airplane has a "best glide" ratio of about 1:20. (that's optimistic by about 10%, but we're calculating order-of-magnitude here). This means that for traveling 200km, you need the energy to lift the whole thing 10km vertically. So, doing New York to London, 5500 km, you consume energy to bring the whole plane up 275 km into the air, or g.h = 2.7 MJ/kg. In practice this is a bit optimistic: during takeoff and landing the plane is not flying in best-glide configuration or at best-glide speed. Also in cruise, you want to expend some extra energy to get to the destination faster. At the optimum speed for best energy consumption, adding a tiny bit of extra speed will not influence fuel consumption much but it WILL get you to the destination faster. Less wages for the pilots and other crew, less write off on the plane. So that makes economic sense.
Now, it'd be nice if you could just go up (less than) 275km and come down anywhere on earth that you want. But to do that you have to reach orbital speed of almost 8km/s. This adds some energy requirements to the trip: 1/2 v^2 =.5*8*8*10^6 = 32MJ/kg..... I'm ignoring the amount of energy required to leave the atmosphere (100km up, about 1MJ/kg).
So.... in terms of required energy to make a trip like that, you're going to need about 10 times more than for a transatlantic trip. Because the energy requirements of the spaceship idea don't change (much) for how far you want to go, this gets 2x or even almost 4x better if you want to go to exactly the opposite side of the earth (20000km).
Now, if you are transporting 440 people in a 220 tonne 747-800, you're taking along half a tonne of airplane for each person aboard. If you can improve on that ratio, things may start to look promising for the rocket idea.
But probably not for the short haul Los Angeles to Toronto stretches but only for the long haul: more than 13000km trips.
And one more thing. Everybody likes to talk about the 30 minute flight time for this rocket thing. Or the say the 2 hour flight time from Houston Texas to Tallahassee Florida. But the hassle at the airport is slowing you down. Be there an hour before departure to check in your luggage, half an hour drive to the airport, half an hour waiting for your luggage to appear at the destination, so you're easily wasting 2 hours around a 2 hour flight. Even with a "short boat trip to the floating platform", this is not going to be less for a rocket trip. If you reduce the flight time to 30 minutes the "overhead percentage" will increase.
luckily the FAA mandated drone registration so it is easy to find the pilot, right?
These algorithms that recognize faces, fingerprints or other "difficult" things are usually just doing binary comparisons: how likely is the subject the one from database-picture 1? 2? 3? There is a number from 0-1 that represents the likelihood of a match.
So when forced to make a decision, you take the one with the highest number, provided that numbers is larger than say 0.5 or 0.8 or whatever threshold you choose. These things work just fine with 100 or 300 subjects in the database, but once you actually start using this in real life you're going to fill up the database with thousands and then ten thousands of possible matches. That's when the reliability goes down enormously. False positives: I see subject X while that person is not in the database at all, or I see subject X when it's actually subject Y who is in the database as well.
To perform a valid test you should find 40000 other photos and put those in the database as well before you start testing....
They flagged my public wiki as falling under the new policy. So someone who posts something on this wiki runs the risk of having their contribution changed by a man-in-the middle. (besides running the risk of someone just going to the wiki and changing their contribution the proper way).
Just FYI: On Linux IRQ handlers can never be paged out on a very fundamental level.
You might think it's useful, but the thinking is that it just MIGHT be the IRQ (kernel memory) for the "get it back from disk" part. So in general stuff like that is never paged out.
In modern systems you'll probably use maybe 3-10Mb of memory for kernel code. If you have little main memory (1GB) that's still less than 1%. So no reason at all to change this policy.
There MUST be some things in hardware to execute anything. While they (the chip manufacturers) have surprised me in the past, not all bugs CAN be fixed with a microcode update.
A long, long time ago, people wrote "self modifying code". Say for doing bit-operations on parts of the screen buffer, you might pass 1 for AND 2 for OR and 3 for XOR. The function could then place the AND/OR/XOR opcode in the middle of the doit loop and then perform the loop.... So one day the manufacturer guarantees that the new machine will execute everything the old one did. Bad move. Turns out the new machine is faster because it prefetches instructions. By the time the code has determined the opcode for inside the loop, the loop (with the last AND/OR/XOR opcode in place) has already been prefetched. This prefetching is at the core of why the machine is fast. Implemented in hardware. Can you fix that with a microcode update? Apparently in the case at hand (PR1ME9955): yes.
But I can easily see it happen that either you disable the whole prefetching stuff (slow everything down enormously) or you need say an extra comparator ("Is the store happening near my PC, possibly near my prefetch queue?") to allow for "normal" cases to use the prefetch queue, but this special case to flush the queue only when necessary. In any case, the microcode was updated and stuff worked properly again.
Wait!
What is happening is that the CPU will mis-execute some instruction so that some "data" becomes invalid. When a compiler is running such data is often a pointer and the wrong pointer often results in a segfault.
But especially while we don't know what's going on exactly, this could also corrupt data. i.e. give the wrong results in a computation, or result in a bad binary when the running program is a compiler.
So you're suggesting I trust the resulting binaries when the compilation doesn't segfault? Even when I have to try several times? Ehh. not me!
4.5GW is about 25% of the power-requirement of the Netherlands. That small country on the north sea....
The problem with current research in semi-soft sciences like biology and medicine is that the scientists use this p-value wrong.
If you suspect a glass of wine a day will lower chances of heart disease, take 1000 volunteers, roll a dice and half of them you tell to not have that wine-a-day and the other half you tell, please drink one glass of wine a day. Next you wait two years, and evaluate the incidence of heart problems in the two groups. That's where 0.05 P-value is acceptable. (in practice, telling people ot suddenly stop or start drinking is not going to go well).
Things become problematic when you suspect: "something we can measure may be related to this disease" (e.g. Sarcoidosis), you take 200 patients and 200 healthy people and then measure 200 parameters in each of the 400 blood samples... Provided there is little to measure, you'll find about 1/20th or about 10 parameters that DO seem to be (p=0.05) different between the two groups.
In the case at hand one or two measurable parameters ARE, different in the patient-group. So you'll have a better than 95% chance of finding those. Of the 198 other parameters you'll find 1/20th of false positives, for a total of almost 12 publishable results.
Should you want to increase your chances of finding these publishable results, the sample size needs to be relatively small. The group of 200 patients and 200 healthy people might already be too big to get enough spurious results. Even if they don't do this consciously, the scientists will quickly be able ot optimize their sample size to find publishable results.
When I was a freshman in 1985, some guy asked me to help him put his research in the computer. He had formulated 50 or so questions and predicted boys would answer differently than girls. So he went into a classroom, interviewed 30 boys and girls and put his results in the computer. Of course the computer told him there were several significant differences between boys and girls. Some of them real (do you like to play with trains? Dolls?) some of them not (I don't remember the example).
The other example is more recent. A Dutch Doctor got her PhD with (among others) the described sarcoidosis research. But my run-ins with subject are very limited simply because I don't move in those circles. This is way more widespread than just the few examples that I encounter personally.
Then people try to "fix" this by proposing the wrong solutions.
The research: "can we find a parameter that allows us to differentiate between the two groups" is very important as well. But you have to do your research in the right way. Take 100 patients and 100 healthy people and find the parameters that seem to make a difference. NOW you go into the second half of the research with a hypothesis: "this parameter is important" and verify your claim. Now the p=0.05 is acceptable. (a 5% chance that you're wrong, as opposed to a 95% chance your'e full of shit).
Living outside the USA, some sites want me to fill out my address including postal code. When they don't accept my real postal code, I fill you 90210.
I used to take a drug where in the small print the expiration date was explained that at that date they guaranteed 99% of the active substance to be still present. With me being on a "high dosage" I took 3000mg/day. Lower dosage options were 1000mg/day and 2000mg/day. i.e. when the doctor wants you to take 2100mg (it's not that accurate), he'll have to prescribe 3000.
In short, it wouldn't even be all that bad if say 10% of the stuff was inactivated by a timed decay.
Since when does moving the mouse involve closing a process? Oh wait! Microsoft Windows.