Don't know it this is a slashvertisement or not, but the original post on the Ksplice blog sounds much more adequate and calm to me. I wouldn't bet that the AC who posted this works for Ksplice.
Please keep in mind that usually such downgraded hardware is actually a top of the line CPU that has some defects and was unable to pass all the QA tests imposed on the flagship product. So while this stuff may be cracked, it is quite possible that people who do so will experience lots of bugs due to failing cache blocks and hyper-threading modules...
If that's the case, I don't see a problem here: Intel just charges more for a CPU that has all of its components working properly, and less for units that had high failure rates of the said components and had them disabled.
Wrong. Twitter doesn't treat the username as metadata - it's still limited by that SMS size. From the help center:
Your username can contain up to 15 characters. Why no more? Because we append your username to your 140 characters on outgoing SMS updates and IM messages. If your name is longer than 15 characters, your message would be too long to send in a single text message.
Your real name can be 20 characters long. Although your username may contain only 15 characters, many real names exceed 15 characters. Since we rarely send real name info via text message (except when using the WHO IS command) we added extra characters for folks (like Konstantin Gredeskoul) with longer names. Real names are also used in follow notification and request emails to help accurately identify folks with user names like cupcake25.
While theoretically it's definitely possible, I'm not sure if storing BLOBs in a database is a good solution; at least none of our colleagues from other universities and agencies like ESA or NOAA that I personally know (or at least have some knowledge of how their systems are built) use this approach. All of them do exactly as GP said: store metadata and e.g. file paths in the database, and store tables, BLOBs etc in the file system. Since some of these projects have a huge amount of resources, I think that this approach may have more to it than it may seem.
And as far as backups and mirroring go, there are projects that use popular protocols like BitTorrent for mirroring and load balancing, and there are some that have built non-trivial custom data distribution systems (like the SDO guys).
Actually, these 85k rows represent only a day's worth of data from a single satellite instrument. We often operate on data sets tens of millions of rows large, and the general performance trend is nearly the same.
About scaling: as far as I understand, PyTables' main bottleneck is raw disk I/O. I think that applying a couple of primitive tricks like using memcached and a large amount of RAM will tip the scales in its favor even further, but that needs to be verified.
Hello, I'm a space research guy.
I've recently made a comparison of MySQL 5.0, Oracle 10i and HDF5 file based data storage for our space data. The results are amusing (the linked page contains charts and explanations; pay attention to the conclusive chart, it is the most informative one). In short (for those who don't want to look at the charts): using relational databases for pretty common scientific tasks sucks badly performance-wise.
Disclaimer: while I'm positively not a guru DBA and thus admit that both of the databases tested could be configured and optimized better, but the thing is that I am not supposed to. Neither is the OP. While we may do lots of programming work to accomplish our scientific tasks, being a qualified DBA is a completely separate challenge - an unwanted one, as well.
So far, PyTables/HDF5 FTW. Which brings us back to the OP's question about organizing these files...
In the US, maybe. In most other countries, not quite. E.g. in Russia you can get as much as 15% off the retail price, so most expensive and cutting-edge hardware is bought online. Last time I checked, Nexus one was both expensive and cutting-edge:)
I did follow the TFA to the origin of the story (MyDroidWorld forum), and I still don't see any code, captured data or even a photo of the said eFuse chip inside the DroidX. I understand that the original poster appears to be a reputable hacker, but come on, what kind of real reporting is this? Can anyone else verify these claims? More information needed, thank you very much whoever posts it, because if true, this is an outrage.
You can't have a lot of kids knowing how to program tomorrow if you don't spark their interest with such a tool today. And IMO this will be great not only for attracting and educating future software engineers, but also to tap into the pool of active talented kids who are not going to be software engineers, ever. The kids who will be nuclear physicists, radio geeks, astronomy fans, journalists will also acquire basic programming abilities without distracting from their main specialty to learn a programming language or two, dive into a complex SDK and constantly work to keep these skills up to date.
In short, I think that App Inventor is pretty awesome.
I don't think I understand you correctly: nobody forces you to install those millions of fart-apps! If they find their audience among the teens, why not? Do you really notice that the whole web is literally overwhelmed by pages of similar (i.e. non-existent) quality?
The problem is not that Android Market will be flooded by low-quality apps. The problem is that Android Market has pretty rudimentary app search and filtering capabilities to reduce signal to noise ratio. Sorry for the irony, but Google must build a decent search engine for Android apps.
Yes, but this crap is reported on Slashdot, which is advertised to deliver news for nerds, not plumbers! Hell, this guy didn't even try to upload his exploit to the official extension repository because, as he claims, he "didn't want to exploit the vulnerability and harm end users". Remember when Google pulled a vulnerability exploit proof of concept app from the Android Market, and purged it from end-user phones? That was a security research project. And this is just an A-grade crap.
I can confirm that; a friend of my recently defended her PhD thesis describing the growth and development peculiarities of Brassica Chinensis when exposed to different combinations of LED lighting - blue, red, and both. Her research is a part of a big Russian space project; she works on problems of farming edible plants in spacecraft (with all the problems arising from that). Pretty awesome, if you ask me. An earlier paper of hers on the same subject can be found at Springerlink.
In case anyone got interested, the 1958 test was called Operation Argus.
By the way, despite what TFA says, there are two electron radiation belts, not just two of them at all; there's also a proton one. Wikipedia considers it to be a part of the inner radiation belt, but the accepted terminology says otherwise to the best of my knowledge.
That's the way the law is written. The problem is not that Google intercepted it, the problem is that Google saved their unencrypted transmissions to their hard drive while not being authorized to do so.
I condemn groups like Privacy International for using Google's screwup as a cheap PR resource to promote themselves. You want to claim that it was intentional, prove it in the court! Where's the libel law when you need it?
There is little to add. ...
I want to focus on a related problem that I’ll call privacy advocacy theater. This is a problem that my friends and colleagues are guilty of, and I’m sure I’m guilty of it at times, too. Privacy Advocacy Theater is the act of extreme criticism for an accidental data breach rather than a systemic privacy design flaw. Example: if you’re up in arms over the Google Street View privacy “fiasco” of the last few days, you’re guilty of Privacy Advocacy Theater. (If you’re generally worried about Google Street View, that’s a different problem, there are real concerns there, but I’m only talking about the collection of wifi network payload data Google performed by mistake.)
I’m looking at you, EU Privacy folks, who are investigating Google over accidental data collection. Where is your investigation of Opera, which provides Opera Mini, billed as “smarter web browsing”, smarter in the sense that it relays all data, including secure connections to your bank, through Opera’s servers? We should be much more concerned about designs that inherently create privacy risk. Oh sure, it’s easy political points to harp on accidental breaches for weeks, but it doesn’t help privacy much.
I also have to be harsh with people I respect deeply, like Kim Cameron who says that Google broke two of his very nicely crafted Laws of Identity. Come on, Kim, this was accidental data collection by code that the Google Street View folks didn’t even realize was running. (I’m giving them the benefit of the doubt. If they are lying, that’s a different problem, but no one’s claiming they’re lying, as far as I know.) The Laws of Identity apply predominantly to the systems that individuals choose to use to manage their data. If anyone is breaking the Laws of Identity, it’s the wifi access points that don’t actively nudge users towards encrypting their wifi network.
Another group I deeply admire and respect is EPIC. Here, they are also guilty of Privacy Advocacy Theater: they’re asking for an investigation into Google’s accidental wifi data collection. Now, I’m not a lawyer, and I certainly wouldn’t dare argue the law with Marc Rotenberg. But using common sense here, shouldn’t intent have something to do with this? Google did not intend to collect this data, didn’t even know they had it, and didn’t make any use of it. Shouldn’t we, instead of investigating them, help them define a process, maybe with third-party auditing from folks at EPIC, that helps them catalog what data they’re collecting, what data they’re using, etc? At the very least, can we stop the press releases that make no distinction between intentional and unintentional data collection?
I’m getting worked up about this Privacy Advocacy Theater because, in the end, I believe it hurts privacy. Google is spending large amounts of time and money on this issue which is, as I’ve described previously, an inevitability in computer systems: accidental breaches happen all the time. We should be mostly commending them for revealing this flaw, and working with them to continue regular disclosure so that, with public oversight, these mistakes are discovered and addressed. Google has zero interest in making these mistakes. Slapping them on the wrist and having them feel some pain may be appropriate, but too much pain and too much focus on this non-issue is akin to a full-on criminal trial for driving 10 miles per hour over the speed limit: everyone’s doing it. Just fine them and move on. Then spend your time going after the folks who, by design, are endangering millions of users’ privacy.
There are plenty of real, systemic privacy issues: Facebook’s data sharing and privacy controls, Opera Mini’s design (tens of millions of users relaying all of their data to Opera, by design), Google’s intentional data retention practices, web-based ad networks, We have enough real issues to deal with, who needs the advocacy theater?
Even according to RMS, AdSense and Google search cannot be considered proprietary in the same sense as e.g. Photoshop since they are not distributed (JavaScript notwithstanding). Google runs them on their servers, not you. And it is popular knowledge that Google started based on Linux, MySQL, Apache and many other open-source projects. Without them, there would be no Google, at least not in the past decade.
-1, Wrong. Google does accept quite a lot of third-party ad providers on their network, and any website owner can choose if to opt in those alternative providers or not. Google search engine's webmaster, apparently, chose not to opt it. Would you deny him that right? Once again: you can serve third-party ads via AdSense on your site, if you want to. I do not, so I don't opt in - the possibility is nevertheless there. That is not the case with Apple.
Slashdot Mirror
Don't know it this is a slashvertisement or not, but the original post on the Ksplice blog sounds much more adequate and calm to me. I wouldn't bet that the AC who posted this works for Ksplice.
Oh. I see. They're going to lock down fully capable CPUs. Now that's a shame.
Please keep in mind that usually such downgraded hardware is actually a top of the line CPU that has some defects and was unable to pass all the QA tests imposed on the flagship product. So while this stuff may be cracked, it is quite possible that people who do so will experience lots of bugs due to failing cache blocks and hyper-threading modules...
If that's the case, I don't see a problem here: Intel just charges more for a CPU that has all of its components working properly, and less for units that had high failure rates of the said components and had them disabled.
Your username can contain up to 15 characters. Why no more? Because we append your username to your 140 characters on outgoing SMS updates and IM messages. If your name is longer than 15 characters, your message would be too long to send in a single text message.
Your real name can be 20 characters long. Although your username may contain only 15 characters, many real names exceed 15 characters. Since we rarely send real name info via text message (except when using the WHO IS command) we added extra characters for folks (like Konstantin Gredeskoul) with longer names. Real names are also used in follow notification and request emails to help accurately identify folks with user names like cupcake25.
While theoretically it's definitely possible, I'm not sure if storing BLOBs in a database is a good solution; at least none of our colleagues from other universities and agencies like ESA or NOAA that I personally know (or at least have some knowledge of how their systems are built) use this approach. All of them do exactly as GP said: store metadata and e.g. file paths in the database, and store tables, BLOBs etc in the file system. Since some of these projects have a huge amount of resources, I think that this approach may have more to it than it may seem.
And as far as backups and mirroring go, there are projects that use popular protocols like BitTorrent for mirroring and load balancing, and there are some that have built non-trivial custom data distribution systems (like the SDO guys).
Actually, these 85k rows represent only a day's worth of data from a single satellite instrument. We often operate on data sets tens of millions of rows large, and the general performance trend is nearly the same.
About scaling: as far as I understand, PyTables' main bottleneck is raw disk I/O. I think that applying a couple of primitive tricks like using memcached and a large amount of RAM will tip the scales in its favor even further, but that needs to be verified.
I've recently made a comparison of MySQL 5.0, Oracle 10i and HDF5 file based data storage for our space data. The results are amusing (the linked page contains charts and explanations; pay attention to the conclusive chart, it is the most informative one). In short (for those who don't want to look at the charts): using relational databases for pretty common scientific tasks sucks badly performance-wise.
Disclaimer: while I'm positively not a guru DBA and thus admit that both of the databases tested could be configured and optimized better, but the thing is that I am not supposed to. Neither is the OP. While we may do lots of programming work to accomplish our scientific tasks, being a qualified DBA is a completely separate challenge - an unwanted one, as well.
So far, PyTables/HDF5 FTW. Which brings us back to the OP's question about organizing these files...
Hell, it's about time!
In the US, maybe. In most other countries, not quite. E.g. in Russia you can get as much as 15% off the retail price, so most expensive and cutting-edge hardware is bought online. Last time I checked, Nexus one was both expensive and cutting-edge :)
Now people's heads will hurt. Great Jobs!
FTFY :)
I did follow the TFA to the origin of the story (MyDroidWorld forum), and I still don't see any code, captured data or even a photo of the said eFuse chip inside the DroidX. I understand that the original poster appears to be a reputable hacker, but come on, what kind of real reporting is this? Can anyone else verify these claims? More information needed, thank you very much whoever posts it, because if true, this is an outrage.
You can't have a lot of kids knowing how to program tomorrow if you don't spark their interest with such a tool today. And IMO this will be great not only for attracting and educating future software engineers, but also to tap into the pool of active talented kids who are not going to be software engineers, ever. The kids who will be nuclear physicists, radio geeks, astronomy fans, journalists will also acquire basic programming abilities without distracting from their main specialty to learn a programming language or two, dive into a complex SDK and constantly work to keep these skills up to date.
In short, I think that App Inventor is pretty awesome.
I don't think I understand you correctly: nobody forces you to install those millions of fart-apps! If they find their audience among the teens, why not? Do you really notice that the whole web is literally overwhelmed by pages of similar (i.e. non-existent) quality?
The problem is not that Android Market will be flooded by low-quality apps. The problem is that Android Market has pretty rudimentary app search and filtering capabilities to reduce signal to noise ratio. Sorry for the irony, but Google must build a decent search engine for Android apps.
Yes, but this crap is reported on Slashdot, which is advertised to deliver news for nerds, not plumbers! Hell, this guy didn't even try to upload his exploit to the official extension repository because, as he claims, he "didn't want to exploit the vulnerability and harm end users".
Remember when Google pulled a vulnerability exploit proof of concept app from the Android Market, and purged it from end-user phones? That was a security research project. And this is just an A-grade crap.
I can confirm that; a friend of my recently defended her PhD thesis describing the growth and development peculiarities of Brassica Chinensis when exposed to different combinations of LED lighting - blue, red, and both.
Her research is a part of a big Russian space project; she works on problems of farming edible plants in spacecraft (with all the problems arising from that). Pretty awesome, if you ask me. An earlier paper of hers on the same subject can be found at Springerlink.
What gives US the right
Its might. "Because we can" is a very unethical but a pretty much incontrovertible argument.
In case anyone got interested, the 1958 test was called Operation Argus.
By the way, despite what TFA says, there are two electron radiation belts, not just two of them at all; there's also a proton one. Wikipedia considers it to be a part of the inner radiation belt, but the accepted terminology says otherwise to the best of my knowledge.
That's the way the law is written. The problem is not that Google intercepted it, the problem is that Google saved their unencrypted transmissions to their hard drive while not being authorized to do so.
I condemn groups like Privacy International for using Google's screwup as a cheap PR resource to promote themselves. You want to claim that it was intentional, prove it in the court! Where's the libel law when you need it?
There is little to add.
...
I want to focus on a related problem that I’ll call privacy advocacy theater. This is a problem that my friends and colleagues are guilty of, and I’m sure I’m guilty of it at times, too. Privacy Advocacy Theater is the act of extreme criticism for an accidental data breach rather than a systemic privacy design flaw. Example: if you’re up in arms over the Google Street View privacy “fiasco” of the last few days, you’re guilty of Privacy Advocacy Theater. (If you’re generally worried about Google Street View, that’s a different problem, there are real concerns there, but I’m only talking about the collection of wifi network payload data Google performed by mistake.)
I’m looking at you, EU Privacy folks, who are investigating Google over accidental data collection. Where is your investigation of Opera, which provides Opera Mini, billed as “smarter web browsing”, smarter in the sense that it relays all data, including secure connections to your bank, through Opera’s servers? We should be much more concerned about designs that inherently create privacy risk. Oh sure, it’s easy political points to harp on accidental breaches for weeks, but it doesn’t help privacy much.
I also have to be harsh with people I respect deeply, like Kim Cameron who says that Google broke two of his very nicely crafted Laws of Identity. Come on, Kim, this was accidental data collection by code that the Google Street View folks didn’t even realize was running. (I’m giving them the benefit of the doubt. If they are lying, that’s a different problem, but no one’s claiming they’re lying, as far as I know.) The Laws of Identity apply predominantly to the systems that individuals choose to use to manage their data. If anyone is breaking the Laws of Identity, it’s the wifi access points that don’t actively nudge users towards encrypting their wifi network.
Another group I deeply admire and respect is EPIC. Here, they are also guilty of Privacy Advocacy Theater: they’re asking for an investigation into Google’s accidental wifi data collection. Now, I’m not a lawyer, and I certainly wouldn’t dare argue the law with Marc Rotenberg. But using common sense here, shouldn’t intent have something to do with this? Google did not intend to collect this data, didn’t even know they had it, and didn’t make any use of it. Shouldn’t we, instead of investigating them, help them define a process, maybe with third-party auditing from folks at EPIC, that helps them catalog what data they’re collecting, what data they’re using, etc? At the very least, can we stop the press releases that make no distinction between intentional and unintentional data collection?
I’m getting worked up about this Privacy Advocacy Theater because, in the end, I believe it hurts privacy. Google is spending large amounts of time and money on this issue which is, as I’ve described previously, an inevitability in computer systems: accidental breaches happen all the time. We should be mostly commending them for revealing this flaw, and working with them to continue regular disclosure so that, with public oversight, these mistakes are discovered and addressed. Google has zero interest in making these mistakes. Slapping them on the wrist and having them feel some pain may be appropriate, but too much pain and too much focus on this non-issue is akin to a full-on criminal trial for driving 10 miles per hour over the speed limit: everyone’s doing it. Just fine them and move on. Then spend your time going after the folks who, by design, are endangering millions of users’ privacy.
There are plenty of real, systemic privacy issues: Facebook’s data sharing and privacy controls, Opera Mini’s design (tens of millions of users relaying all of their data to Opera, by design), Google’s intentional data retention practices, web-based ad networks, We have enough real issues to deal with, who needs the advocacy theater?
Even according to RMS, AdSense and Google search cannot be considered proprietary in the same sense as e.g. Photoshop since they are not distributed (JavaScript notwithstanding). Google runs them on their servers, not you. And it is popular knowledge that Google started based on Linux, MySQL, Apache and many other open-source projects. Without them, there would be no Google, at least not in the past decade.
Google recently began shipping Chrome with Flash preinstalled. I wonder if they'll pull the plug as well?
...For everything else, there's SmokeScreen.
-1, Wrong.
Google does accept quite a lot of third-party ad providers on their network, and any website owner can choose if to opt in those alternative providers or not. Google search engine's webmaster, apparently, chose not to opt it. Would you deny him that right? Once again: you can serve third-party ads via AdSense on your site, if you want to. I do not, so I don't opt in - the possibility is nevertheless there. That is not the case with Apple.
'Tis one of the best comments I've ever come across on Slashdot :)
Google is doing what Tesla did when Edison prevented him from using his lightbulb design.
There, fixed that for you