This Black Box is similar to stuff that's already IN your car, and airplanes, etc. Here is the legislature that will be revised to *require* the devices, so you can look at the details of what's being required.
Particularly, check the latter sections. "Each vehicle equipped with an EDR must meet the requirements specified in 563.7 for data elements, 563.8 for data format, 563.9 for data capture, 563.10 for crash test performance and survivability, and 563.11 for information in owner's manual."
That's called parenting. Until your kids reach the age of majority or are otherwise emancipated, you have to make these decisions for them. You're legally obligated to do so, in fact.
You're probably running into big-box warehouse merchandise handling here. If you buy them somewhere else, where they treat the merchandise with more respect, do you have better results?
I propose that some defective products are also a result of mishandling before you bought them. You're totally right about the low end brands, too. They aren't built well, nor are they packaged well enough to withstand the abuse they suffer at the hands of those stores!
Having the combination of good packaging, better-than-absolute-minimum product, and a good store, that's the real trick.
Some chain stores are better than others, as you say. Find out about the store, check out the workers handling the merchandise. If you're shopping somewhere where they get paid so little that they don't care and just kick all the merchandise around when it comes off the truck, then you're probably going to get poor results because it's all beat up. You can see it without much work if you find out when truck day is, and shop on that day. It's really easy to see how much they care when they're wheeling carts around.
I have a Wii from three weeks after U.S. release, with the old lasers and the old wrist straps and everything, and I've never had to send it in. I guess YMMV?
I recall that Microsoft did everything they could to deny the issue (including telling retailers not to process returns) until the magnitude of the problem became so obviously large that a hardware redesign and recall was required. Were you around Slashdot back then? It was full of stories about that. I do think we are partly to blame for them finally owning up to it, quietly though that was.
As for the PS3, I have no idea how Sony handles it, but that may be because I don't purchase Sony products anymore. Nintendo has excellent customer service according to the reviews I've seen, although I nor nobody I know ever had to send their Wii in for service - even after blatant abuse by children, animals, drunk roommates etc.
My point is that it's hard to build that critical mass of "want" when the product isn't available to the people who would actually advocate for the product.
I want Windows, several of my friends want Windows. We can't get a good Windows phone on Verizon. There's the biggest problem, our provider doesn't sell what we want, and the other providers in the area have spotty coverage.
They did open the lines up for suggestions, and some community members suggested that it looked like OO C. How did they know? They probably had experience using and debugging OO C, if I had to guess. There were also plenty of people who said that it definitely wasn't compiler X or language Y from their own experiences. The article links to this discussion: http://www.securelist.com/en/blog/677/The_mystery_of_Duqu_Framework_solved
But about discovering the specifics of the truth? It's probably like you alluded to in your comment - fingerprinting the machine code. It would take a while, but you could come up with fingerprints for a great many various compilers and features. You could do that for Common Lisp, too. (In fact, someone DID suggest for them to look at various LISP dialects.) It has taken long enough that such a scenario - having a good library of fingerprints - is believable. Given a scanner with a dictionary of fingerprints, one could reasonably say that you either have hand-assembled machine code made to mimic another language, or that you have code generated by a very specific language and compiler. If nothing in your library of fingerprints matched, assuming you had a good handle on hand-assembling machine code, you could look and see if it smells like such a beast. It would be tremendously laborious to hand-assemble code to make it look like a specific compiler generated it, and why would you do that in the first place? I fail to see the benefit when you could just use that compiler. If you were trying to throw off the analysts with a false positive match, there would still be a ton of mysterious data that still needs examination.
Think about DNA analysis. We can look at our DNA and determine some chunks of it came from virus, and that some of it is "junk" that serves no purpose.
Also think about image analysis like OCR or various captcha-breaking software. You can map images to characters with a program, and detect anomalies and known signatures.
Then there is heuristic antivirus scanning. It knows enough to find some previously unthought-of malicious code, even if it does sometimes generate false positives.
So why not apply those techniques to machine code, and see what you get? If multiple methods give you similar results, you would be onto something, I imagine.
Just maybe, though, those nations were already on that path, and someone in the media got the idea to explore the idea and found out that hey, there IS something going on there after all! And our president just called them evil! How perfect! That wouldn't be good for business, no sir! I exaggerate a little, but... maybe some of this was already going on.
PNG uses the same compression as the Minecraft chunk data, actually.
It's stored via ZLIB (DEFLATE algorithm). The "damage/data/etc values" are 4-bit arrays, and the chunks are split into 16x16x16 slices that are only stored if there is any meaningful data within.
I am working on a home-grown Anvil map tool, so I have some insight into how the world is stored.
Chunks are stored as 1D columns of 16x16x16 3D slices, of which there may be up to 16 vertical slices per chunk, and each slice has several additional 3D blocks of data representing 4 bit data values such as sky/torch lighting, enhanced block IDs (those extra 4 bits that get you from 256-4096), damage values, entities, etc. Some of these additional data blocks are only stored if they contain anything. Each chunk also has a 2D 16x16 array for biomes. The game does not store empty vertical slices.
The chunks are individually stored within their containing Region file as a GZipped (using the DEFLATE algorithm) NBT entity. The Region file itself is not compressed, but each chunk is. Think of each region file as a self-contained file system with an allocation table and everything.
Each Region file represents a 32x32 chunk area, which may or may not be fully populated. This represents a 512x256x512 world coordinate area.
When things are in memory, I believe the tradeoff has been made such that things are stored uncompressed in memory for the benefit of low-latency access.
You can check out the data for yourself with a tool called NBTEdit. It's pretty slick. (It's also not the tool I'm working on.)
Slashdot Mirror
Agreed, this is going to be totally obnoxious when used in the vicinity of anyone whose hearing is reasonably good.
High-end recording studio monitors work pretty well, too.
That's an interesting thought... Who owns SQL, though?
This Black Box is similar to stuff that's already IN your car, and airplanes, etc. Here is the legislature that will be revised to *require* the devices, so you can look at the details of what's being required.
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=adfa70d7fb0603db957cef53e728148f&rgn=div5&view=text&node=49:6.1.2.3.31&idno=49
Particularly, check the latter sections. "Each vehicle equipped with an EDR must meet the requirements specified in 563.7 for data elements, 563.8 for data format, 563.9 for data capture, 563.10 for crash test performance and survivability, and 563.11 for information in owner's manual."
That's called parenting. Until your kids reach the age of majority or are otherwise emancipated, you have to make these decisions for them. You're legally obligated to do so, in fact.
I replaced all of my light bulbs with CFLs in 2007, and none of them have gone out yet. So far so good for me.
You're probably running into big-box warehouse merchandise handling here. If you buy them somewhere else, where they treat the merchandise with more respect, do you have better results?
Hey, you could probably return them, if she just bought them.
Might want to bring home a box of chocolates though.
I propose that some defective products are also a result of mishandling before you bought them. You're totally right about the low end brands, too. They aren't built well, nor are they packaged well enough to withstand the abuse they suffer at the hands of those stores!
Having the combination of good packaging, better-than-absolute-minimum product, and a good store, that's the real trick.
Some chain stores are better than others, as you say. Find out about the store, check out the workers handling the merchandise. If you're shopping somewhere where they get paid so little that they don't care and just kick all the merchandise around when it comes off the truck, then you're probably going to get poor results because it's all beat up. You can see it without much work if you find out when truck day is, and shop on that day. It's really easy to see how much they care when they're wheeling carts around.
Instant democracy! Just add laser!
BZAAP!
And we can finally be rid of the riddle about the guy stuck on a boat, who needed to light a smoke.
Exactly... I administer a few dozen Windows servers (which run web apps) and I am so glad they changed that in IE9
I have a Wii from three weeks after U.S. release, with the old lasers and the old wrist straps and everything, and I've never had to send it in. I guess YMMV?
...or other countries that China may or may not have in their back pocket!
I recall that Microsoft did everything they could to deny the issue (including telling retailers not to process returns) until the magnitude of the problem became so obviously large that a hardware redesign and recall was required. Were you around Slashdot back then? It was full of stories about that. I do think we are partly to blame for them finally owning up to it, quietly though that was.
As for the PS3, I have no idea how Sony handles it, but that may be because I don't purchase Sony products anymore. Nintendo has excellent customer service according to the reviews I've seen, although I nor nobody I know ever had to send their Wii in for service - even after blatant abuse by children, animals, drunk roommates etc.
My point is that it's hard to build that critical mass of "want" when the product isn't available to the people who would actually advocate for the product.
I want Windows, several of my friends want Windows. We can't get a good Windows phone on Verizon. There's the biggest problem, our provider doesn't sell what we want, and the other providers in the area have spotty coverage.
They did open the lines up for suggestions, and some community members suggested that it looked like OO C. How did they know? They probably had experience using and debugging OO C, if I had to guess. There were also plenty of people who said that it definitely wasn't compiler X or language Y from their own experiences. The article links to this discussion: http://www.securelist.com/en/blog/677/The_mystery_of_Duqu_Framework_solved
But about discovering the specifics of the truth? It's probably like you alluded to in your comment - fingerprinting the machine code. It would take a while, but you could come up with fingerprints for a great many various compilers and features. You could do that for Common Lisp, too. (In fact, someone DID suggest for them to look at various LISP dialects.) It has taken long enough that such a scenario - having a good library of fingerprints - is believable. Given a scanner with a dictionary of fingerprints, one could reasonably say that you either have hand-assembled machine code made to mimic another language, or that you have code generated by a very specific language and compiler. If nothing in your library of fingerprints matched, assuming you had a good handle on hand-assembling machine code, you could look and see if it smells like such a beast. It would be tremendously laborious to hand-assemble code to make it look like a specific compiler generated it, and why would you do that in the first place? I fail to see the benefit when you could just use that compiler. If you were trying to throw off the analysts with a false positive match, there would still be a ton of mysterious data that still needs examination.
Think about DNA analysis. We can look at our DNA and determine some chunks of it came from virus, and that some of it is "junk" that serves no purpose.
Also think about image analysis like OCR or various captcha-breaking software. You can map images to characters with a program, and detect anomalies and known signatures.
Then there is heuristic antivirus scanning. It knows enough to find some previously unthought-of malicious code, even if it does sometimes generate false positives.
So why not apply those techniques to machine code, and see what you get? If multiple methods give you similar results, you would be onto something, I imagine.
Wow, that was a well-written post on the subject. I hope you're working for the good guys.
It was pretty bad, I can agree with that.
Just maybe, though, those nations were already on that path, and someone in the media got the idea to explore the idea and found out that hey, there IS something going on there after all! And our president just called them evil! How perfect! That wouldn't be good for business, no sir! I exaggerate a little, but... maybe some of this was already going on.
Shoot, I meant to say ZLIB, not GZip.
PNG uses the same compression as the Minecraft chunk data, actually.
It's stored via ZLIB (DEFLATE algorithm). The "damage/data/etc values" are 4-bit arrays, and the chunks are split into 16x16x16 slices that are only stored if there is any meaningful data within.
Pretty good ideas - that's why they used them!
I am working on a home-grown Anvil map tool, so I have some insight into how the world is stored.
Chunks are stored as 1D columns of 16x16x16 3D slices, of which there may be up to 16 vertical slices per chunk, and each slice has several additional 3D blocks of data representing 4 bit data values such as sky/torch lighting, enhanced block IDs (those extra 4 bits that get you from 256-4096), damage values, entities, etc. Some of these additional data blocks are only stored if they contain anything. Each chunk also has a 2D 16x16 array for biomes. The game does not store empty vertical slices.
The chunks are individually stored within their containing Region file as a GZipped (using the DEFLATE algorithm) NBT entity. The Region file itself is not compressed, but each chunk is. Think of each region file as a self-contained file system with an allocation table and everything.
Each Region file represents a 32x32 chunk area, which may or may not be fully populated. This represents a 512x256x512 world coordinate area.
When things are in memory, I believe the tradeoff has been made such that things are stored uncompressed in memory for the benefit of low-latency access.
You can check out the data for yourself with a tool called NBTEdit. It's pretty slick. (It's also not the tool I'm working on.)
I love Slashdot.
Wow, I just found out that I'm better at something than the government.