Yes, this is new. I got my first computer about 30 years ago. It is approximately a million times slower than the desktop I bought for less money this year. Admittedly, it uses about a quarter of the power.
Yes, each successive fab has been costly - with newer ones costing over a billion dollars. But, until relatively recently, you could go from 2x to x feature size, and get lower power consumption, and higher performance.
This simple geometrical scaling has broken down - narrower features may mean you need more power, not less, and though they may be able to run at a higher frequency, cooling becomes a major problem.
As the summary stated, you now can't make - for any amount of money spent on a new fab, a denser process simply by virtue of geometry that gets you better power and clock speed.
I feel I'm really unlikely to see another factor of a million increase in computation, barring mature nanotech.
You could in principle setup the maximum downhill speed with the smartphone - hit 20MPH and it regeneratively brakes you down to that speed. Basically stupid though not to have a little wireless thing triggered by a small press on the brakes.
While interesting, and some things might seem novel to the casual uninterested reader, I can see nothing truly novel - as in would not be thought of in a few days by an engineer skilled in the field facing the same problems. Aspects of this patent I've got prototype code somewhere (if I haven't thrown out the disk) around optimising fuel use of a hybrid car.
I've not found anything. Can anyone point to the actual patents involved? This seems to be a standard regenerative electric drive 'on a bike wheel', with nothing startlingly new.
Being a pro does not make you immune to making mistakes. If, for example, you go out every day with your full attention on the road at all times, well rested and prepared - great - you can handle it.
For a car you may have to drive in suboptimal conditions, or when tired, a car that requires 100% accurate flawless decisionmaking all the time is a bad idea.
Whatever the 'goal' - it has that function. The new play services APIs are not in the open-source code.
The only way as an OEM to get those APIs available, and to be able to run the increasing number of apps that require them is to either reimplement them - which may run into patent issues - or to comply with all of the google terms and conditions and get them to bless your device. Which means doing nothing that google does not like.
This _INCREASES_ fragmentation that vendors that choose not to, or are not legally able to install play services face.
The study involved 200 rats, half female, split into 10 groups. As I understand it, the greatest 'statistical significance' comes from the female rats.
Taking one part, and closely analysing it. 'Up to 14 months, no animals in the control groups showed any signs of tumors whilst 10–30% of treated females per group developed tumors, with the exception of one group (33% GMO + R). By the beginning of the 24th month, 50–80% of female animals had developed tumors in all treated groups, with up to 3 tumors per animal, whereas only 30% of controls were affected.'
Starting with the first statement. 'up to 14 months, 1-3 rats in some of the groups developed tumors, whereas no rats in the control group or the group fed GMO + roundup did' So, of 7 groups, 2 groups were cancer free.
Going onto the next part. 3 rats got cancer in the control group. 5-8 in the other 6 groups. But, half of those 6 groups were also fed roundup.
So, a total of between 9 and 15 extra rats got cancer, apparantly, if you multiply up the control group.
But - the whole basis of this paper now rests on two rats. If in the control group at the 24th month, 5 rats would normally have gotten cancer, and 2 happened to get lucky, the paper largely becomes non-statistically significant.
I am not a statistician.
If normally, half of rats get cancer at 24 months, then you would expect 5 rats, not 3 in the control group to have it. How likely is it that only three rats would die? Only if this chance is under 5% does the rest of the paper have any weight whatsoever.
This is unfortunately not relevant directly to the above.
It does make running an OS on an android system without having to rewrite your own low-level hardware drivers easier, as you can use the existing closed-source ones.
It does not implement the bits referred to above that are not part of the android platform as such - but are now 'Play Services'. These are not low-level hardware drivers, but middleware.
'just replicate the damn Android API, piece by piece, it is open is it not? ' The open parts of the API work.
The problem is that increasing parts of the android API are closed, being implemented not by open source code, but by closed source binaries with licences that do not permit redistribution by other manufacturers.
'Play Services is a closed source app owned by Google and licensed as part of the Google Apps package. Any feature you see move from "normal" Android to Google Play Services is also moving from open source to closed source. This app pulls off the neat trick of not only enticing users with exclusive, closed source features, but locking in third-party developers with Google's proprietary APIs as well.'
This is entirely by (googles) design, and for exactly this reason. To make it hard for third party vendors to release devices which run android apps because an increasing fraction of them won't work as time and increasing integration into Play Services happens.
I have not investigated, but would suspect that the various APIs were designed around patents google owns or controls, in order to make implementing the backend supporting the API legally impossible in many countries.
It's really not that rosy. http://www.wired.co.uk/news/archive/2013-10/21/googles-iron-grip-on-android for some context. 'For OEMs, this means they aren't allowed to slowly transition from Google's Android to a fork. The second they ship one device that runs a competing fork, they are given the kiss of death and booted out of the Android family -- it must be a clean break. This, by design, makes switching to forked Android a terrifying prospect to any established Android OEM. You must jump off the Google cliff, and there's no going back.'
There is _NO_ automated process for getting an android device appoved. Do one thing that google does not like, and you cannot legally ship any of the google apps - which as the above article explains - means many, or most apps on the google store break, even if you try to simply copy them over, as the platform services are not open source.
At least as far as I can tell without access to the paywalled concept. Important questions would be:
What is the maximum current that can be transported through strips of various widths? How sensitive to defects is the process?
Tin is going to be a major problem for much semiconductor processing - as it means you basically now can't solder the chip, or do any even 'low' temperature processing after it's deposited - it has to be the last layer.
More relevantly - what legally prevents them from doing so, and why would the state department have any influence? The state department cannot simply prohibit stuff that is legal, in general.
What prevents them from sticking 5 RF receivers in each of the russian consulates. Or indeed, paying for a couple of dozen boxes on roofs in the USA hooked to an internet connection. The equipment needed is approximately the size of a small suitcase, requiring only a few tens of watts of power.
There are many genetic conditions for which it's known beforehand. Two parents with the 'right' condition can lead to a child who is likely to go insane before age 30. (Huntingtons Disease, for example).
All sorts of in principle useful stuff for treatment can be pulled out of 'big data' like this. There was recent work tying in eye-gaze to caregivers reducing over time in infancy with severe autism. If children could be accurately diagnosed at age 1, treatments (in the form for example of guided play) concentrating on strengthening the weakening response may result in an adult who is a productive member of society. (Or at least one that can post on/.)
MRI will work just fine. However, it'll just tell you that it's not got cancer. It does not have resolution enough to resolve the perhaps.05mm thick annual rings. A number of obvious approaches occur - for example - cut a small plug of shell with a plug cutter. This is basically a drillbit with a hollow core, designed to remove a rod of material intact. Yes, this will somewhat injure the clam when the small plug is removed, but it can then be polished and examined microscopically to determine the age. My first thought would be to take this rod, and examine the composition in an appropriate electron microscope.
The clam would be slightly injured, but it's unlikely to be a clamity.
3DES - however - not DES. Are there any sensible (physically realisable) attacks that let you go from known plaintext to recover the key, if 3DES and a maximum length key has been used?
True - I assumed this was implied by the released results of some people saying 'password X has y frequency'. I am guilty of not checking those results, and had assumed that these were simply using several peoples shared passwords from other dumps, which encrypt to the same result and can be easily picked out as common crypted values. If this was a per-user password key - a salt in effect - this would not occur.
To expand on this - if the key doesn't leak, then Alice's password is 'safe' even if she reuses it on other sites only if nobody else in the Adobe dump has used her password, and that username is identifiable on other dumps of released passwords.
So, if Alice and Bob's passwords are identical, Bob's password has been recovered from elsewhere, you now know what Alice's password is, and password reuse becomes risky.
While poor practice as if the encryption key can be recovered _everyones_ password is now released - for 3DES as I understand it - if a long key has been used, there is no practical attack against it.
So, yes, if you have another list of passwords, you can go and say 'Bob used password 1223 on these two other releases, if he's used 1223 for Adobe - here are all the other people who've used that same password' - but you can't recover passwords not shared by other people who have not had their passwords leaked already.
Massive computation buys you nothing here, unless you can crack the key, which for a long random key is impractical.
In this case, 3DES may have leaked less data that is important.
In the case, for example of the 7/7 bombings, these were made of organic peroxides.
Nail varnish remover, hair bleach, limescale remover, and you're pretty much done.
(you can't make a bomb from these chemicals simply in the concentrations they are normally used at - but you can't tell from traces if peroxides are part of hair dye, or a bomb.)
The reagents used to make ricin are similarly problematic.
Also - it's important to note that once in solution, you can't go back to the original compound.
If you put Calcium hydroxide and Sodium chloride into the drain - you get a mix of ions. You can't tell if what went into a drain was Calcium Chloride or Calcium Hydroxide. This is clearly important if one is innocuous.
'I haven't heard of any compiler that removes code just because it contains undefined behavior.' Then your code may not be doing what you think it is. GCC, Clang, acc, armcc, icc, msvc, open64, pathcc, suncc, ti, windriver, xlc all do this.
Click on the PDF, and scroll to page 4 for a nice table of optimisations vs compiler and optimisation level.
_All_ modern compilers do this as part of optimisation.
GCC 4.2.1 for example, with -o0 (least optimisation) will eliminate if(p+100p)
C however says that an overflowed pointer is undefined, and this means the compiler is free to assume that it never occurs.
To quote wikipedia. "The study, the most comprehensive study of literacy ever commissioned by the U.S. government, was released in April 2002 and reapplied in 2003 giving trend data. It involved lengthy interviews of over 90,700 adults statistically balanced for age, gender, ethnicity, education level, and location (urban, suburban, or rural) in 12 states across the U.S. and was designed to represent the U.S. population as a whole. This government study showed that 21% to 23% of adult Americans were not "able to locate information in text", could not "make low-level inferences using printed materials", and were unable to "integrate easily identifiable pieces of information." Further, this study showed that 41% to 44% of U.S. adults in the lowest level on the literacy scale (literacy rate of 35 or below) were living in poverty.[2]
A follow-up study by the same group of researchers using a smaller database (19,714 interviewees) was released in 2006 that showed some upward movement of low end (basic and below to intermediate) in U.S. adult literacy levels and a decline in the full proficiency group.[3]"
The less literate seem likely to be over-represented in the users of these exchanges.
Slashdot Mirror
Yes, this is new.
I got my first computer about 30 years ago.
It is approximately a million times slower than the desktop I bought for less money this year. Admittedly, it uses about a quarter of the power.
Yes, each successive fab has been costly - with newer ones costing over a billion dollars.
But, until relatively recently, you could go from 2x to x feature size, and get lower power consumption, and higher performance.
This simple geometrical scaling has broken down - narrower features may mean you need more power, not less, and though they may be able to run at a higher frequency, cooling becomes a major problem.
As the summary stated, you now can't make - for any amount of money spent on a new fab, a denser process simply by virtue of geometry that gets you better power and clock speed.
I feel I'm really unlikely to see another factor of a million increase in computation, barring mature nanotech.
You could in principle setup the maximum downhill speed with the smartphone - hit 20MPH and it regeneratively brakes you down to that speed.
Basically stupid though not to have a little wireless thing triggered by a small press on the brakes.
http://www.google.com/patents/US20110133542
While interesting, and some things might seem novel to the casual uninterested reader, I can see nothing truly novel - as in would not be thought of in a few days by an engineer skilled in the field facing the same problems.
Aspects of this patent I've got prototype code somewhere (if I haven't thrown out the disk) around optimising fuel use of a hybrid car.
I've not found anything.
Can anyone point to the actual patents involved?
This seems to be a standard regenerative electric drive 'on a bike wheel', with nothing startlingly new.
Being a pro does not make you immune to making mistakes.
If, for example, you go out every day with your full attention on the road at all times, well rested and prepared - great - you can handle it.
For a car you may have to drive in suboptimal conditions, or when tired, a car that requires 100% accurate flawless decisionmaking all the time is a bad idea.
Whatever the 'goal' - it has that function.
The new play services APIs are not in the open-source code.
The only way as an OEM to get those APIs available, and to be able to run the increasing number of apps that require them is to either reimplement them - which may run into patent issues - or to comply with all of the google terms and conditions and get them to bless your device.
Which means doing nothing that google does not like.
This _INCREASES_ fragmentation that vendors that choose not to, or are not legally able to install play services face.
http://www.sciencedirect.com/science/article/pii/S0278691512005637
The study involved 200 rats, half female, split into 10 groups.
As I understand it, the greatest 'statistical significance' comes from the female rats.
Taking one part, and closely analysing it.
'Up to 14 months, no animals in the control groups showed any signs of tumors whilst 10–30% of treated females per group developed tumors, with the exception of one group (33% GMO + R). By the beginning of the 24th month, 50–80% of female animals had developed tumors in all treated groups, with up to 3 tumors per animal, whereas only 30% of controls were affected.'
Starting with the first statement. 'up to 14 months, 1-3 rats in some of the groups developed tumors, whereas no rats in the control group or the group fed GMO + roundup did' So, of 7 groups, 2 groups were cancer free.
Going onto the next part.
3 rats got cancer in the control group.
5-8 in the other 6 groups.
But, half of those 6 groups were also fed roundup.
So, a total of between 9 and 15 extra rats got cancer, apparantly, if you multiply up the control group.
But - the whole basis of this paper now rests on two rats.
If in the control group at the 24th month, 5 rats would normally have gotten cancer, and 2 happened to get lucky, the paper largely becomes non-statistically significant.
I am not a statistician.
If normally, half of rats get cancer at 24 months, then you would expect 5 rats, not 3 in the control group to have it.
How likely is it that only three rats would die?
Only if this chance is under 5% does the rest of the paper have any weight whatsoever.
I believe you're referring to hybris.
This is unfortunately not relevant directly to the above.
It does make running an OS on an android system without having to rewrite your own low-level hardware drivers easier, as you can use the existing closed-source ones.
It does not implement the bits referred to above that are not part of the android platform as such - but are now 'Play Services'.
These are not low-level hardware drivers, but middleware.
'just replicate the damn Android API, piece by piece, it is open is it not? '
The open parts of the API work.
The problem is that increasing parts of the android API are closed, being implemented not by open source code, but by closed source binaries with licences that do not permit redistribution by other manufacturers.
http://www.wired.co.uk/news/archive/2013-10/21/googles-iron-grip-on-android
'Play Services is a closed source app owned by Google and licensed as part of the Google Apps package. Any feature you see move from "normal" Android to Google Play Services is also moving from open source to closed source. This app pulls off the neat trick of not only enticing users with exclusive, closed source features, but locking in third-party developers with Google's proprietary APIs as well.'
This is entirely by (googles) design, and for exactly this reason.
To make it hard for third party vendors to release devices which run android apps because an increasing fraction of them won't work as time and increasing integration into Play Services happens.
I have not investigated, but would suspect that the various APIs were designed around patents google owns or controls, in order to make implementing the backend supporting the API legally impossible in many countries.
It's really not that rosy.
http://www.wired.co.uk/news/archive/2013-10/21/googles-iron-grip-on-android for some context.
'For OEMs, this means they aren't allowed to slowly transition from Google's Android to a fork. The second they ship one device that runs a competing fork, they are given the kiss of death and booted out of the Android family -- it must be a clean break. This, by design, makes switching to forked Android a terrifying prospect to any established Android OEM. You must jump off the Google cliff, and there's no going back.'
There is _NO_ automated process for getting an android device appoved.
Do one thing that google does not like, and you cannot legally ship any of the google apps - which as the above article explains - means many, or most apps on the google store break, even if you try to simply copy them over, as the platform services are not open source.
Chips are commonly assembled by soldering - using tin-based solder.
At least as far as I can tell without access to the paywalled concept.
Important questions would be:
What is the maximum current that can be transported through strips of various widths?
How sensitive to defects is the process?
Tin is going to be a major problem for much semiconductor processing - as it means you basically now can't solder the chip, or do any even 'low' temperature processing after it's deposited - it has to be the last layer.
Great!
If you have a really - really simple return, and you understand all tax laws which may apply.
There are good reasons why tubotax et al don't use software written in a couple of hours in excel.
More relevantly - what legally prevents them from doing so, and why would the state department have any influence?
The state department cannot simply prohibit stuff that is legal, in general.
What prevents them from sticking 5 RF receivers in each of the russian consulates.
Or indeed, paying for a couple of dozen boxes on roofs in the USA hooked to an internet connection.
The equipment needed is approximately the size of a small suitcase, requiring only a few tens of watts of power.
There are many genetic conditions for which it's known beforehand.
Two parents with the 'right' condition can lead to a child who is likely to go insane before age 30.
(Huntingtons Disease, for example).
All sorts of in principle useful stuff for treatment can be pulled out of 'big data' like this. /.)
There was recent work tying in eye-gaze to caregivers reducing over time in infancy with severe autism.
If children could be accurately diagnosed at age 1, treatments (in the form for example of guided play)
concentrating on strengthening the weakening response may result in an adult who is a productive member
of society.
(Or at least one that can post on
MRI will work just fine. .05mm thick annual rings.
However, it'll just tell you that it's not got cancer.
It does not have resolution enough to resolve the perhaps
A number of obvious approaches occur - for example - cut a small plug of shell with a plug cutter.
This is basically a drillbit with a hollow core, designed to remove a rod of material intact.
Yes, this will somewhat injure the clam when the small plug is removed, but it can then be polished and examined microscopically to determine the age.
My first thought would be to take this rod, and examine the composition in an appropriate electron microscope.
The clam would be slightly injured, but it's unlikely to be a clamity.
For example, YouTube downloaders-
3DES - however - not DES.
Are there any sensible (physically realisable) attacks that let you go from known plaintext to recover the key, if 3DES and a maximum length key has been used?
True - I assumed this was implied by the released results of some people saying 'password X has y frequency'.
I am guilty of not checking those results, and had assumed that these were simply using several peoples shared passwords from other dumps, which encrypt to the same result and can be easily picked out as common crypted values.
If this was a per-user password key - a salt in effect - this would not occur.
To expand on this - if the key doesn't leak, then Alice's password is 'safe' even if she reuses it on other sites only if nobody else in the Adobe dump has used her password, and that username is identifiable on other dumps of released passwords.
So, if Alice and Bob's passwords are identical, Bob's password has been recovered from elsewhere, you now know what Alice's password is, and password reuse becomes risky.
While poor practice as if the encryption key can be recovered _everyones_ password is now released - for 3DES as I understand it - if a long key has been used, there is no practical attack against it.
So, yes, if you have another list of passwords, you can go and say 'Bob used password 1223 on these two other releases, if he's used 1223 for Adobe - here are all the other people who've used that same password' - but you can't recover passwords not shared by other people who have not had their passwords leaked already.
Massive computation buys you nothing here, unless you can crack the key, which for a long random key is impractical.
In this case, 3DES may have leaked less data that is important.
The Scowge of Dewocracies.
In the case, for example of the 7/7 bombings, these were made of organic peroxides.
Nail varnish remover, hair bleach, limescale remover, and you're pretty much done.
(you can't make a bomb from these chemicals simply in the concentrations they are normally used at - but you can't tell from traces if peroxides are part of hair dye, or a bomb.)
The reagents used to make ricin are similarly problematic.
Also - it's important to note that once in solution, you can't go back to the original compound.
If you put Calcium hydroxide and Sodium chloride into the drain - you get a mix of ions.
You can't tell if what went into a drain was Calcium Chloride or Calcium Hydroxide.
This is clearly important if one is innocuous.
In practice, it seems likely that most of the 'unique' signatures will come from illicit drug use - NOT manufacture of drugs or explosives.
http://www.popsci.com/scitech/article/2008-02/your-sewer-drugs
'I haven't heard of any compiler that removes code just because it contains undefined behavior.'
Then your code may not be doing what you think it is.
GCC, Clang, acc, armcc, icc, msvc, open64, pathcc, suncc, ti, windriver, xlc all do this.
Click on the PDF, and scroll to page 4 for a nice table of optimisations vs compiler and optimisation level.
_All_ modern compilers do this as part of optimisation.
GCC 4.2.1 for example, with -o0 (least optimisation) will eliminate if(p+100p)
C however says that an overflowed pointer is undefined, and this means the compiler is free to assume that it never occurs.
To quote wikipedia.
"The study, the most comprehensive study of literacy ever commissioned by the U.S. government, was released in April 2002 and reapplied in 2003 giving trend data. It involved lengthy interviews of over 90,700 adults statistically balanced for age, gender, ethnicity, education level, and location (urban, suburban, or rural) in 12 states across the U.S. and was designed to represent the U.S. population as a whole. This government study showed that 21% to 23% of adult Americans were not "able to locate information in text", could not "make low-level inferences using printed materials", and were unable to "integrate easily identifiable pieces of information." Further, this study showed that 41% to 44% of U.S. adults in the lowest level on the literacy scale (literacy rate of 35 or below) were living in poverty.[2]
A follow-up study by the same group of researchers using a smaller database (19,714 interviewees) was released in 2006 that showed some upward movement of low end (basic and below to intermediate) in U.S. adult literacy levels and a decline in the full proficiency group.[3]"
The less literate seem likely to be over-represented in the users of these exchanges.
If the tablets never break.