I think he meant to ask whether passengers be restricted from using their phones, not whether they shouldn't be allowed to talk to the driver. Although...
The problem they'll find is that it isn't really the geeks that'll be pissed off by this. This almost certainly won't apply to public transport (including, I would suspect, licensed public service taxis), so other than people who are actually driving (and therefore perhaps should be restricted from using their phones while the vehicle is in motion) it is the passengers in private vehicles who are most likely to be effected. Who are the people who are frequently passengers in private vehicles and who make above-average use of mobile phones? There are a couple of classes that spring to mind:
1. Business leaders (the kind who can pay for a chauffeur) 2. Politicians (the kind who can convince the state to pay for a chauffeur for them, usually on the premise that it leaves them free to attend to important business while in transit)
Why release POC for both platforms? The bug doesn't differentiate, but the exploit code would need to be different (it manipulates pointers to break a kernel-managed linked list), A POC is just used to demonstrate that the bug is real and leads to actual security violations; it's not intended to allow end users to run the exploit.
Don't assume that just because you're on 64-bit you'll be safe. The changes required to make it run on x64 are likely to be small.
The responsible thing to do when you find a bug is to inform those who are at risk from the bug. Any delay leaves those people at risk unnecessarily, and is irresponsible.
Public announcement of the bug increases the risk by a factor of thousands or more. Most people are not able to limit their exposure. The total amount of risk is therefore increased by the announcement.
If the package is something that can be trivially changed and the flaw is obvious enough that it's likely to be rediscovered quickly, I'd perhaps agree with you. But:
1) Risk of exploitation increases with the number of people aware of the flaw. Immediate public disclosure has ballooned this figure from a handful (most likely just 1) to hundreds of thousands. 2) Most people are not able to trivially switch operating systems. Changing from one OS to another without disrupting progress of essential work that a PC may be required for involves a large amount of planning, research to find acceptable alternative applications, and in some cases is simply not possible at all due to external constraints (e.g. requirement to use software that is only available on a single OS and which may not function adequately in a virtualised environment due to performance concerns and/or lack of required direct access to hardware). 3) This flaw had apparently existed for many years without discovery; the chance of additional discoveries of it being made within the timespan of a few months that MS would require to get a fix for the issue released is quite slim.
As for drivers even a kernel level exploit usually won't be able to install them these days. Drivers need to be signed before Windows will allow them to be installed. On Windows 7 you can installed unsigned code after the user gives permission, but Windows 8 flat out refuses to install unsigned binaries as drivers.
Which would (perhaps) be OK if it worked. Unfortunately, I recently came across an installer that purported to be able to install a patched driver by modifying the list of valid driver signing certificate authorities. If this technique actually works (and I see no reason to believe it wouldn't) I'm pretty sure it could be done by any code running with SYSTEM privileges.
Do you know if the 3 to 5 guys who own that codebase in MS read that site?
Probably not. But it's pretty-much a certainty that MS's security response team does. And that's the guys you'd notify, anyway... you don't send bug details directly to the owner of the code in question.
Measured over the last 10 years, oil has increased in value more than gold. Its 2008 price peak was probably an anomaly caused by market speculation, but other than that it has been increasing steadily.
The benefits it promises come only from the synthesis of ALL its components.
Yes, yes, we've heard it a thousand times, if an agile project fails, it must not have been truly agile. Probably isn't a true Scotsman, either.
There's a big difference here. The problem with the No True Scotsman fallacy is that there isn't an agreed-upon definition of a True Scotsman before you start. However, there is a widely agreed-upon definition of agile. The very first paragraph of the "principles" page behind that link reads:
We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
I would contend that software that does not perform a useful function by itself is not valuable. Therefore, this project which has never delivered software which is useful, is not following the "highest priority" of the most widely-cited description of Agile. It is therefore quite clearly not correctly following the requirements of an Agile project.
It may well be that it would have been impossible for this project to be Agile. This is not something new; it is widely known that not all project types are appropriate for Agile development. See for example this page, which states:
When You Should Not Use Agile Project Management... When the project cannot be broken down into components for the purposes of client, user or customer input and testing throughout the project i.e. a process that cannot be changed or implemented a piece at a time but must be changed in one go
Sure sounds like a description of this project to me.
I could have told you in advance, just from that list, that the project was going to fail.
Fail, that is, from the perspective of the agency and its taxpayers. From the perspective of the consulting companies, it worked just fine. They wanted big fees and got them.
Yup. Only surprised not to see Crapita on the list.
If this happens, it's because you aren't following a key agile principle, which is to deliver working *useful* software on a regular basis. It's the first damned paragraph of the "agile manifesto principles" document:
We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The software isn't valuable if it can't be used.
Now I'll happily admit that in some cases, this is impossible, but the point is that these cases are not examples of cases where agile has failed; they are examples of places where agile actually cannot be used, and therefore whoever has been running them has only partially implemented an agile process. Partial implementations of agile processes are, unfortunately, doomed to failure. The agile process consists of a set of mutually reinforcing practices that, if any are neglected, can all fall apart quite quickly. This says nothing about whether agile is realistic for the rest of us, because *most* software projects don't have constraints that mean a reasonably-sized team cannot have a working system that is doing something useful within 4 weeks (which is about the longest an agile process will usually let you go without delivering useful software).
I may be wrong here, but I get the impression that the MIPS architecture is much more power efficient than that of the ARM architecture
If they are going to talk about building up a big iron using CPUs which are of high power efficiency, I reckon the MIPS cpu might be more suitable for this task than one from the ARM camp
I don't think it is. Best figures (albeit somewhat out-of-date) I can find for a MIPS-based system is 2GFLOPS/W for a complete 6-core node including memory. ARM Cortex A15 power consumption is a little hard to track down, although it's suggested that a 4-core 1.8GHz configuration (eg Samsung Exynos 5) could run at full speed on 8W (if the power manager let it; the Exynos 5 throttles down when it consumes more than 4W). Performance per GHz/core is about 4GFLOPS, so this system should be able to pull in about 28.8GFLOPS (or twice that if using ARM's "NEON" SIMD system to full advantage). Add in ~2W for 1GB DDR3 SDRAM, and that's 2.9GFLOPS/W. Assuming that the MIPS system I found is not the best available (as the data was from 2009 it certainly seems likely better is available now), the two appear to be roughly comparable.
Wait a bit. See: http://olimex.wordpress.com/tag/a20/ - when these become available, they'll be about 4x the speed of a pi for about twice the money. Plus the olimex boards have a lot more GPIOs and useful stuff like that.:)
You can only really go up to 4Ghz with off-the-shelf parts - any higher than that and you're on to exotic cooling systems involving liquified gasses of one type or another. The record is 8.8GHz, but that took liquid nitrogen.
Of course, just measuring GHz isn't everything. As that's an AMD chip, you could probably get similar single-threaded performance by overclocking a recent Intel chip to about 6.6GHz (consensus seems to be that in computationally-intentensive tasks, sandy bridge is about 25% faster than bulldozer).
When they say it does not involve a security breach, what they mean is "it doesn't breach *our* security." Why do you think they give a shit about *your* security, exactly?
For the merchants accepting the payments, because they'll have to bear the cost of chargebacks on transactions that were otherwise perfectly valid but cannot be proven to have been authorised by the cardholder.
Hate those stupid gas pumps. Useless if your card is from outside the US.
Actually there is a way to use this even if your card is from outside the US. For example I have cards from Canada and the convention is to use the numbers from your postal code and add 00 at the end. It works well. If yours is from another country google around, they might have a convention on how to get the "ZIP" code you're supposed to use.
Yep; in the end, they're just checking AVS which just checks the numbers in your postal code. Same should work for at least UK-issued cards, and probably all major European issuers as well.
Someone must have gotten their units mixed up and used 4 inches.
So it turns out that like RFID tags, the assurances of limited range are absolute bullshit. A more powerful transmitter coupled with a more sensitive antenna than used in the reference design allow them to work from farther away. Who'd have thought it?
Some people believe the values of precious metals are being manipulated by either governments (who typically have large holdings of them) or mining cartels (who have obvious means to benefit). Others suggest increased industrial use coupled with a higher median income in the developed world versus cost of day-to-day living have driven demands higher and that production has lagged behind this. Whatever the reason, there is little doubt that the cost of both silver and gold has increased faster than that of most other goods.
If by "reasonably stable" you mean "daily fluctuations about 30%", right.
No, by "reasonably stable" I mean "there are indications of the kind of market support that would mean I could be reasonably confident of buying at this value and being able to sell at a similar or higher value at later time periods in the order of several months (although I may have to wait for appropriate market timing to do so)."
This is different from "stable" by which I would mean "there are strong indications that the market would support the value at or above the current level in the long term, i.e. over a period of years, and I would be unlikely to have to wait for market timing in order to avoid significant losses".
Note that I would not currently consider many currencies to be stable. USD is perhaps the only candidate.
When you compare Bitcoin fluctuations with 'real world' currency fluctuations as somewhat the same - which major currencies has recently lost 2/3rds of value overnight like Bitcoin did? If you had significant money in Bitcoin the sky was falling. Its value behaves exactly like very speculative stocks.
A couple of months back I posted that the value of BTC looked reasonably stable to me in the vicinity of $100. It's still in that vicinity. There may have been a bubble in the interim that has now burst, but anyone with sense should have seen that coming and avoided purchasing while it was overvalued.
When I tell people who area concerned about the poor that the 1964 minimum wage was just under an ounce of silver per hour (~$1.25) and that today's value would be around $25 per hour, their eyes glaze over in disbelief.
Or maybe it's just that they've realised that what's happened is actually that the real-terms value of silver has increased substantially over the last 50 years and that you're therefore talking bullshit.
Slashdot Mirror
I think he meant to ask whether passengers be restricted from using their phones, not whether they shouldn't be allowed to talk to the driver. Although...
Pissing off a few geeks is worth it.
The problem they'll find is that it isn't really the geeks that'll be pissed off by this. This almost certainly won't apply to public transport (including, I would suspect, licensed public service taxis), so other than people who are actually driving (and therefore perhaps should be restricted from using their phones while the vehicle is in motion) it is the passengers in private vehicles who are most likely to be effected. Who are the people who are frequently passengers in private vehicles and who make above-average use of mobile phones? There are a couple of classes that spring to mind:
1. Business leaders (the kind who can pay for a chauffeur)
2. Politicians (the kind who can convince the state to pay for a chauffeur for them, usually on the premise that it leaves them free to attend to important business while in transit)
This, therefore, is not going to happen.
Why release POC for both platforms? The bug doesn't differentiate, but the exploit code would need to be different (it manipulates pointers to break a kernel-managed linked list), A POC is just used to demonstrate that the bug is real and leads to actual security violations; it's not intended to allow end users to run the exploit.
Don't assume that just because you're on 64-bit you'll be safe. The changes required to make it run on x64 are likely to be small.
The responsible thing to do when you find a bug is to inform those who are at risk from the bug. Any delay leaves those people at risk unnecessarily, and is irresponsible.
Public announcement of the bug increases the risk by a factor of thousands or more. Most people are not able to limit their exposure. The total amount of risk is therefore increased by the announcement.
If the package is something that can be trivially changed and the flaw is obvious enough that it's likely to be rediscovered quickly, I'd perhaps agree with you. But:
1) Risk of exploitation increases with the number of people aware of the flaw. Immediate public disclosure has ballooned this figure from a handful (most likely just 1) to hundreds of thousands.
2) Most people are not able to trivially switch operating systems. Changing from one OS to another without disrupting progress of essential work that a PC may be required for involves a large amount of planning, research to find acceptable alternative applications, and in some cases is simply not possible at all due to external constraints (e.g. requirement to use software that is only available on a single OS and which may not function adequately in a virtualised environment due to performance concerns and/or lack of required direct access to hardware).
3) This flaw had apparently existed for many years without discovery; the chance of additional discoveries of it being made within the timespan of a few months that MS would require to get a fix for the issue released is quite slim.
As for drivers even a kernel level exploit usually won't be able to install them these days. Drivers need to be signed before Windows will allow them to be installed. On Windows 7 you can installed unsigned code after the user gives permission, but Windows 8 flat out refuses to install unsigned binaries as drivers.
Which would (perhaps) be OK if it worked. Unfortunately, I recently came across an installer that purported to be able to install a patched driver by modifying the list of valid driver signing certificate authorities. If this technique actually works (and I see no reason to believe it wouldn't) I'm pretty sure it could be done by any code running with SYSTEM privileges.
Umm. Many do.
Do you know if the 3 to 5 guys who own that codebase in MS read that site?
Probably not. But it's pretty-much a certainty that MS's security response team does. And that's the guys you'd notify, anyway... you don't send bug details directly to the owner of the code in question.
Perhaps that's how you pronounce it. It's spelled "you'd've", however.
(And it isn't confined to Texas... I've heard it used quite frequently in the UK.)
It puzzles me greatly why oil has not already become a currency and not running up in price far more than gold
http://www.macrotrends.net/1335/dollar-gold-and-oil-chart-last-ten-years
Measured over the last 10 years, oil has increased in value more than gold. Its 2008 price peak was probably an anomaly caused by market speculation, but other than that it has been increasing steadily.
The benefits it promises come only from the synthesis of ALL its components.
Yes, yes, we've heard it a thousand times, if an agile project fails, it must not have been truly agile. Probably isn't a true Scotsman, either.
There's a big difference here. The problem with the No True Scotsman fallacy is that there isn't an agreed-upon definition of a True Scotsman before you start. However, there is a widely agreed-upon definition of agile. The very first paragraph of the "principles" page behind that link reads:
I would contend that software that does not perform a useful function by itself is not valuable. Therefore, this project which has never delivered software which is useful, is not following the "highest priority" of the most widely-cited description of Agile. It is therefore quite clearly not correctly following the requirements of an Agile project.
It may well be that it would have been impossible for this project to be Agile. This is not something new; it is widely known that not all project types are appropriate for Agile development. See for example this page, which states:
Sure sounds like a description of this project to me.
I could have told you in advance, just from that list, that the project was going to fail.
Fail, that is, from the perspective of the agency and its taxpayers. From the perspective of the consulting companies, it worked just fine. They wanted big fees and got them.
Yup. Only surprised not to see Crapita on the list.
If this happens, it's because you aren't following a key agile principle, which is to deliver working *useful* software on a regular basis. It's the first damned paragraph of the "agile manifesto principles" document:
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The software isn't valuable if it can't be used.
Now I'll happily admit that in some cases, this is impossible, but the point is that these cases are not examples of cases where agile has failed; they are examples of places where agile actually cannot be used, and therefore whoever has been running them has only partially implemented an agile process. Partial implementations of agile processes are, unfortunately, doomed to failure. The agile process consists of a set of mutually reinforcing practices that, if any are neglected, can all fall apart quite quickly. This says nothing about whether agile is realistic for the rest of us, because *most* software projects don't have constraints that mean a reasonably-sized team cannot have a working system that is doing something useful within 4 weeks (which is about the longest an agile process will usually let you go without delivering useful software).
I may be wrong here, but I get the impression that the MIPS architecture is much more power efficient than that of the ARM architecture
If they are going to talk about building up a big iron using CPUs which are of high power efficiency, I reckon the MIPS cpu might be more suitable for this task than one from the ARM camp
I don't think it is. Best figures (albeit somewhat out-of-date) I can find for a MIPS-based system is 2GFLOPS/W for a complete 6-core node including memory. ARM Cortex A15 power consumption is a little hard to track down, although it's suggested that a 4-core 1.8GHz configuration (eg Samsung Exynos 5) could run at full speed on 8W (if the power manager let it; the Exynos 5 throttles down when it consumes more than 4W). Performance per GHz/core is about 4GFLOPS, so this system should be able to pull in about 28.8GFLOPS (or twice that if using ARM's "NEON" SIMD system to full advantage). Add in ~2W for 1GB DDR3 SDRAM, and that's 2.9GFLOPS/W. Assuming that the MIPS system I found is not the best available (as the data was from 2009 it certainly seems likely better is available now), the two appear to be roughly comparable.
Wait a bit. See: http://olimex.wordpress.com/tag/a20/ - when these become available, they'll be about 4x the speed of a pi for about twice the money. Plus the olimex boards have a lot more GPIOs and useful stuff like that. :)
You can only really go up to 4Ghz with off-the-shelf parts - any higher than that and you're on to exotic cooling systems involving liquified gasses of one type or another. The record is 8.8GHz, but that took liquid nitrogen.
Of course, just measuring GHz isn't everything. As that's an AMD chip, you could probably get similar single-threaded performance by overclocking a recent Intel chip to about 6.6GHz (consensus seems to be that in computationally-intentensive tasks, sandy bridge is about 25% faster than bulldozer).
Right, and why is a second payment then accepted in another way?
When they say it does not involve a security breach, what they mean is "it doesn't breach *our* security." Why do you think they give a shit about *your* security, exactly?
Bad idea for whom?
For the merchants accepting the payments, because they'll have to bear the cost of chargebacks on transactions that were otherwise perfectly valid but cannot be proven to have been authorised by the cardholder.
Hate those stupid gas pumps. Useless if your card is from outside the US.
Actually there is a way to use this even if your card is from outside the US. For example I have cards from Canada and the convention is to use the numbers from your postal code and add 00 at the end. It works well. If yours is from another country google around, they might have a convention on how to get the "ZIP" code you're supposed to use.
Yep; in the end, they're just checking AVS which just checks the numbers in your postal code. Same should work for at least UK-issued cards, and probably all major European issuers as well.
Someone must have gotten their units mixed up and used 4 inches.
So it turns out that like RFID tags, the assurances of limited range are absolute bullshit. A more powerful transmitter coupled with a more sensitive antenna than used in the reference design allow them to work from farther away. Who'd have thought it?
Mary Robinette Kowal has a book on the shortlist and I haven't read it yet. Must grab a copy... (quick note to self)
Some people believe the values of precious metals are being manipulated by either governments (who typically have large holdings of them) or mining cartels (who have obvious means to benefit). Others suggest increased industrial use coupled with a higher median income in the developed world versus cost of day-to-day living have driven demands higher and that production has lagged behind this. Whatever the reason, there is little doubt that the cost of both silver and gold has increased faster than that of most other goods.
If by "reasonably stable" you mean "daily fluctuations about 30%", right.
No, by "reasonably stable" I mean "there are indications of the kind of market support that would mean I could be reasonably confident of buying at this value and being able to sell at a similar or higher value at later time periods in the order of several months (although I may have to wait for appropriate market timing to do so)."
This is different from "stable" by which I would mean "there are strong indications that the market would support the value at or above the current level in the long term, i.e. over a period of years, and I would be unlikely to have to wait for market timing in order to avoid significant losses".
Note that I would not currently consider many currencies to be stable. USD is perhaps the only candidate.
When you compare Bitcoin fluctuations with 'real world' currency fluctuations as somewhat the same - which major currencies has recently lost 2/3rds of value overnight like Bitcoin did? If you had significant money in Bitcoin the sky was falling. Its value behaves exactly like very speculative stocks.
A couple of months back I posted that the value of BTC looked reasonably stable to me in the vicinity of $100. It's still in that vicinity. There may have been a bubble in the interim that has now burst, but anyone with sense should have seen that coming and avoided purchasing while it was overvalued.
When I tell people who area concerned about the poor that the 1964 minimum wage was just under an ounce of silver per hour (~$1.25) and that today's value would be around $25 per hour, their eyes glaze over in disbelief.
Or maybe it's just that they've realised that what's happened is actually that the real-terms value of silver has increased substantially over the last 50 years and that you're therefore talking bullshit.