Most NAND Flash chips are already defective - it's just that the defects are branded "factory bad blocks" and the chips get sold anyway. We're well past the point where 100% reliability is possible and well into the realm of using error correction and flash translation layers to mask an increasingly poor memory array.
MLC NAND Flash is already horribly unreliable. Manufacturers don't care about errors, quantum or not. The proper question to ask is when will quantum effects become dominant such that decreasing feature size loses more memory from failure than you gain from the reduced size. Until then, people will just slap on better ECC and nobody cares if a large number of bits are randomly flipping.
Re:Location without GPS
on
iPad Review
·
· Score: 1
I'm pretty sure they sniff AP locations on GPS-enabled phones and send them back to expand their database. I've had my iPhone put me right about at my house only from Wi-Fi data (GPS disabled and 3G location info is much worse). Now I moved, and it still thinks I'm at my old house because I relocated my AP. My old house was in a small village in Spain and I sincerely doubt someone from Skyhook drove through there.
Re:You don't need 3G for GPS.
on
iPad Review
·
· Score: 5, Insightful
You do on the iPad, as GPS and 3G go hand-in-hand in the still unavailable 3G model. But Taco was confused by the Wi-Fi location finding system that does work on his non-3G model.
They can't give people BC. PS2 backwards compatibility is hardware-based (first fully, then partially). Geohot doesn't know what the hell he's talking about; backwards compatibility went away when Sony removed the GS from newer PS3 models, and it's no software switch.
Overbearing and stupid? They're the only mainstream videogame console manufacturer so far to have embraced homebrew officially (XNA doesn't count, that's basically like the iPhone App Store only worse).
Sure, it could be better, but you can't say they haven't tried until now.
MAC addresses are _mostly_ unique, which is plenty to cause privacy concerns. The fact that some manufacturers use duplicate MACs isn't going to appease the tinfoil hatters.
RFC3041 will, but people have to actually implement it and use it by default.
Just wait until the tinfoil hatters realize that by default IPv6 stateless autoconfiguration puts your globally unique MAC address in the second half of your IPv6 address...
You're confusing multiple prefixes with actual real-world sizes. Prefixes are exponential (TB=1000 vs TiB=2). Base units and real-world sizes are not. How many of your files are a precise power of two size? Probably extremely few. Just because they're made of bytes doesn't mean their actual size has to look nice in power of two terms. Reality is that file sizes are usually totally arbitrary, and won't look any nicer using power of two units. Sure, underlying computer units are usually power of two multiples of some other smaller unit (8-bit bytes, 32/64-bit words, 4KiB OS RAM pages, 512B disk sectors, 2048B CD/DVD sectors), but those are just base multiples and they do not require the use of higher prefixes that are also binary. A byte might be 8 bits, but nobody says you need to have a power of two number of bytes. A disk sector might be 512 bytes, but 512 disk sectors are nothing practically interesting. An inch is 2.54cm, but 2.54 inches are useless. Besides, these power-of-two restrictions are being increasingly broken due to better optimization (e.g. filesystem tail packing to avoid having to round on-disk sizes to 512 bytes).
BTW, people care about how their RAM is measured, because no matter how you decide to measure it it will always come in power-of-two sizes. Therefore, using power-of-two prefixes results in convenient, precisely accurate numbers.
No, your files are sized in base-10 (as is your hard drive, as are network speeds), and nobody gives a crap what their size is as compared to the size of your RAM, which you can keep measuring in base-2.
No computer use-case (except for maybe hibernation, and only dumb forms of it anyway) involves loading the entire RAM from an HDD. Therefore, there is absolutely no problem with using SI prefixes for files and data (whether in an HDD or in RAM), and binary prefixes for the total size of RAM. No one cares what size their files are in relation to the size of their RAM (at least not to within the error caused by blindly switching between SI and binary prefixes).
On the other hand, people do care what sizes their files are in relation to network speeds, and guess what, the latter have always used true SI prefixes.
This "trick" would make your OS look like it's using more space (more space used on the HDD), and also make it look like it's using less space (more free space on the HDD). Proportionately, the OS still uses the same percentage of your hard drive, of course.
That's a myth. The chips in SSDs use sizes that are usually based on powers of two plus an extra 1/64th (or so) of spare data for error correction (so they aren't even a power of two size - they're slightly larger). For example, typical SLC flash has a power of two number of blocks, each being 64 pages, each page being 2KiB data plus 64 bytes of spare area.
Actual Flash storage devices with a controller (SSDs, SD cards, whatever) will have some bad blocks, and they also reserve more blocks for error correction, wear leveling, and future bad block relocation. In the end, manufacturers tend to match it up so that the actual usable data size is close to some common SI size. For example, a 4GB SD card probably uses a 4GiB Flash chip, which actually contains something like 4429185024 bytes of Flash cells (4.125GiB). 4GiB are used as the data area, and of that a portion is reserved for bad blocks and wear leveling, so in the end what your reader sees is more like 4GB (3.73GiB).
NOR Flash, on the other hand, typically guarantees a full binary-sized array, but that isn't used for consumer bulk storage. The only consumer product that physically comes in binary-sized units is RAM. And even then you always waste some of it, due to address space mapping issues.
Sounds like it's a CubeSat, a standardized tiny satellite that can be launched in large groups (relatively) cheaply. CubeSats are nominally 10x10x10, but you can have double width and triple width versions.
People will be looking through the binary for GPL violations.
Not if it's encrypted.
Second, what does DRM have to do with it? Unless the executable's encrypted (they're usually just signed, instead)
No, they're usually encrypted. DRM is security through obscurity, and a big part of the obscurity is not letting potential attackers see any of the code (lest they find vulnerabilities). Case in point: The Wii's security lasted until someone managed to get a RAM dump with decrypted code and keys. At that point you still couldn't run code (signed executables), but nonetheless the security quickly came crashing down as soon as bugs were found.
As far as the PS3 is concerned, look up their Secure ELF format. PS3 binaries are encrypted.
Sure they put wierd tracks and other crap to make it less easy, but it's not too difficult.
That was last generation. This generation, it's all about encrypting and signing the crap out of everything. They still like to futz around with the disc format, but that's just for physical anti-piracy.
You're free to buy the game on release, even if you don't have a PS3, stick it in a blu-ray drive and attempt to read it/dump it/etc.
As far as I know, blu-ray drives will not read PS3 games. You can dump them from PS3 Linux though (AFAIR), but that gains you little because the executable is still encrypted and signed.
Wii games are even worse - they encrypt and sign every single disc sector (they use a hash tree to do the signing efficiently). Wii piracy via modchips (drive exploits) came long before anyone was able to take a stab at the software architecture. People had been pirating Wii games for a year and you still wouldn't have been able to spot a GPL violation, because piracy consisted of passing around 4GB encrypted blobs with no ability to touch anything. Of course, after the keys were recovered, this all changed.
Third, GPL violations in closed source code has been spotted before. We had someone rip off PearPC. Microsoft ripped off that DVD library. And many others.
I'm not aware of GPL violations being ever spotted on a console title with encrypted executables.
It's too high profile for someone to steal GPL code in the re-implementation.
Maybe, but I bet the safety provided by the console DRM is tempting for those who might want to do it. At the very least, I wouldn't be surprised if some GPLed components made it in, due to carelessness if nothing else (and they may well be careless, knowing that they won't be caught easily).
Hell, if they did that, the company behind it will be in a LOT of hot water. Using open-source code violates many developer agreements for consoles, be it Nintendo, Sony or Microsoft. It's not that they don't understand the licenses or that "BSD is safe", but they don't want any unthinking developer from possibly compromising the entire system because some library had the AGPL or other "must be fully open" type license. At the very least, there'll be hefty fines for violations.
True, but this is a weird case where a GPLed game is being transmuted into a non-GPLed console game. It's easier not to touch GPLed code when you're writing a game from scratch; it's harder to ensure that you've taken all of the GPLed code out when you're reimplementing the GPLed bits from scratch.
I'm willing to bet they'll violate the GPL to some extent, and I'm willing to bet they won't get caught, at least the way things currently stand. Why? PS3 DRM. Theft of artwork is easy enough to prove on a closed console title, but good luck getting a decrypted binary and statically analyzing it to prove portions were taken from the GPLed code, when the platform hasn't been broken yet (no, geohot's partial hack doesn't qualify as a break).
Most Intel HDA codecs just treat all jacks the same, the only difference is the settings. If you want to play around, grab HDA Analyzer and tweak things to your heart's consent. For example, on my laptop (3 jacks), I can output 5.1 audio, or output 4.0 plus get one mic, or 4.0 plus one input, or output stereo cloned through two jacks (great for listening with a friend), or even make all jacks inputs, route them to the three stereo ADCs, and capture 5.1 analog audio. In fact, as far as I can tell, the only "special" jack is the headphones jack, which appears to go through some sort of extra amp to boost it as an output (more than the codec chip is documented to do, though strangely it still works as an input; it might just be another case of Realtek failing at documentation). Other than that, each jack has "in" and "out" options, a headphone boost option (this is the standard one built-in to the codec), a set of mic preamp settings, and a mic vref setting.
In other words, you just need the right software to do whatever you want with your audio jacks these days. Crappy drivers (both on Linux and Windows) will usually severely limit you, compared to the capabilities of the hardware. At least under Linux, you can always use HDA Analyzer to poke the real hardware settings (on Windows, you're probably SOL).
QA. New releases need to go through QA anyway to make sure they haven't botched anything up.
Usually the release process for a large piece of software requires a certain degree of human interaction (anywhere from light to extreme), and there's always the possibility that something will mess up, even if the bugfix itself is perfectly trivial or safe.
CHDK can add plenty of things, though of course if the code is physically missing then it would have to be reimplemented. Consider that CHDK allows RAW mode in cameras that don't originally support it, for example.
It's worth pointing out that CHDK isn't a hacked firmware (that would probably not be legally redistributable), nor is it an alternative firmware (that would be too much work). CHDK is an add-on to the existing firmware, that works by piggibacking on its OS, hooking functions, and spawning off extra processes on the camera's RTOS. This is what makes it so great: you get the original funcionality of the camera plus extra stuff, and you don't have to wait for the developers to add what already came with your camera anyway.
Slashdot Mirror
Most NAND Flash chips are already defective - it's just that the defects are branded "factory bad blocks" and the chips get sold anyway. We're well past the point where 100% reliability is possible and well into the realm of using error correction and flash translation layers to mask an increasingly poor memory array.
MLC NAND Flash is already horribly unreliable. Manufacturers don't care about errors, quantum or not. The proper question to ask is when will quantum effects become dominant such that decreasing feature size loses more memory from failure than you gain from the reduced size. Until then, people will just slap on better ECC and nobody cares if a large number of bits are randomly flipping.
I'm pretty sure they sniff AP locations on GPS-enabled phones and send them back to expand their database. I've had my iPhone put me right about at my house only from Wi-Fi data (GPS disabled and 3G location info is much worse). Now I moved, and it still thinks I'm at my old house because I relocated my AP. My old house was in a small village in Spain and I sincerely doubt someone from Skyhook drove through there.
You do on the iPad, as GPS and 3G go hand-in-hand in the still unavailable 3G model. But Taco was confused by the Wi-Fi location finding system that does work on his non-3G model.
They can't give people BC. PS2 backwards compatibility is hardware-based (first fully, then partially). Geohot doesn't know what the hell he's talking about; backwards compatibility went away when Sony removed the GS from newer PS3 models, and it's no software switch.
Overbearing and stupid? They're the only mainstream videogame console manufacturer so far to have embraced homebrew officially (XNA doesn't count, that's basically like the iPhone App Store only worse).
Sure, it could be better, but you can't say they haven't tried until now.
MAC addresses are _mostly_ unique, which is plenty to cause privacy concerns. The fact that some manufacturers use duplicate MACs isn't going to appease the tinfoil hatters.
RFC3041 will, but people have to actually implement it and use it by default.
Slashdot ate my UTF-8 (sigh). That was supposed to be 1000^4 and 2^40.
Just wait until the tinfoil hatters realize that by default IPv6 stateless autoconfiguration puts your globally unique MAC address in the second half of your IPv6 address...
You're confusing multiple prefixes with actual real-world sizes. Prefixes are exponential (TB=1000 vs TiB=2). Base units and real-world sizes are not. How many of your files are a precise power of two size? Probably extremely few. Just because they're made of bytes doesn't mean their actual size has to look nice in power of two terms. Reality is that file sizes are usually totally arbitrary, and won't look any nicer using power of two units. Sure, underlying computer units are usually power of two multiples of some other smaller unit (8-bit bytes, 32/64-bit words, 4KiB OS RAM pages, 512B disk sectors, 2048B CD/DVD sectors), but those are just base multiples and they do not require the use of higher prefixes that are also binary. A byte might be 8 bits, but nobody says you need to have a power of two number of bytes. A disk sector might be 512 bytes, but 512 disk sectors are nothing practically interesting. An inch is 2.54cm, but 2.54 inches are useless. Besides, these power-of-two restrictions are being increasingly broken due to better optimization (e.g. filesystem tail packing to avoid having to round on-disk sizes to 512 bytes).
BTW, people care about how their RAM is measured, because no matter how you decide to measure it it will always come in power-of-two sizes. Therefore, using power-of-two prefixes results in convenient, precisely accurate numbers.
No, your files are sized in base-10 (as is your hard drive, as are network speeds), and nobody gives a crap what their size is as compared to the size of your RAM, which you can keep measuring in base-2.
No computer use-case (except for maybe hibernation, and only dumb forms of it anyway) involves loading the entire RAM from an HDD. Therefore, there is absolutely no problem with using SI prefixes for files and data (whether in an HDD or in RAM), and binary prefixes for the total size of RAM. No one cares what size their files are in relation to the size of their RAM (at least not to within the error caused by blindly switching between SI and binary prefixes).
On the other hand, people do care what sizes their files are in relation to network speeds, and guess what, the latter have always used true SI prefixes.
This "trick" would make your OS look like it's using more space (more space used on the HDD), and also make it look like it's using less space (more free space on the HDD). Proportionately, the OS still uses the same percentage of your hard drive, of course.
That's a myth. The chips in SSDs use sizes that are usually based on powers of two plus an extra 1/64th (or so) of spare data for error correction (so they aren't even a power of two size - they're slightly larger). For example, typical SLC flash has a power of two number of blocks, each being 64 pages, each page being 2KiB data plus 64 bytes of spare area.
Actual Flash storage devices with a controller (SSDs, SD cards, whatever) will have some bad blocks, and they also reserve more blocks for error correction, wear leveling, and future bad block relocation. In the end, manufacturers tend to match it up so that the actual usable data size is close to some common SI size. For example, a 4GB SD card probably uses a 4GiB Flash chip, which actually contains something like 4429185024 bytes of Flash cells (4.125GiB). 4GiB are used as the data area, and of that a portion is reserved for bad blocks and wear leveling, so in the end what your reader sees is more like 4GB (3.73GiB).
NOR Flash, on the other hand, typically guarantees a full binary-sized array, but that isn't used for consumer bulk storage. The only consumer product that physically comes in binary-sized units is RAM. And even then you always waste some of it, due to address space mapping issues.
Apple started using SI prefixes half a year ago with Mac OS X Snow Leopard.
Sounds like it's a CubeSat, a standardized tiny satellite that can be launched in large groups (relatively) cheaply. CubeSats are nominally 10x10x10, but you can have double width and triple width versions.
Here's the paper, from a comment above.
Not if it's encrypted.
No, they're usually encrypted. DRM is security through obscurity, and a big part of the obscurity is not letting potential attackers see any of the code (lest they find vulnerabilities). Case in point: The Wii's security lasted until someone managed to get a RAM dump with decrypted code and keys. At that point you still couldn't run code (signed executables), but nonetheless the security quickly came crashing down as soon as bugs were found.
As far as the PS3 is concerned, look up their Secure ELF format. PS3 binaries are encrypted.
That was last generation. This generation, it's all about encrypting and signing the crap out of everything. They still like to futz around with the disc format, but that's just for physical anti-piracy.
As far as I know, blu-ray drives will not read PS3 games. You can dump them from PS3 Linux though (AFAIR), but that gains you little because the executable is still encrypted and signed.
Wii games are even worse - they encrypt and sign every single disc sector (they use a hash tree to do the signing efficiently). Wii piracy via modchips (drive exploits) came long before anyone was able to take a stab at the software architecture. People had been pirating Wii games for a year and you still wouldn't have been able to spot a GPL violation, because piracy consisted of passing around 4GB encrypted blobs with no ability to touch anything. Of course, after the keys were recovered, this all changed.
I'm not aware of GPL violations being ever spotted on a console title with encrypted executables.
Maybe, but I bet the safety provided by the console DRM is tempting for those who might want to do it. At the very least, I wouldn't be surprised if some GPLed components made it in, due to carelessness if nothing else (and they may well be careless, knowing that they won't be caught easily).
True, but this is a weird case where a GPLed game is being transmuted into a non-GPLed console game. It's easier not to touch GPLed code when you're writing a game from scratch; it's harder to ensure that you've taken all of the GPLed code out when you're reimplementing the GPLed bits from scratch.
I'm willing to bet they'll violate the GPL to some extent, and I'm willing to bet they won't get caught, at least the way things currently stand. Why? PS3 DRM. Theft of artwork is easy enough to prove on a closed console title, but good luck getting a decrypted binary and statically analyzing it to prove portions were taken from the GPLed code, when the platform hasn't been broken yet (no, geohot's partial hack doesn't qualify as a break).
I'm not aware of optical audio being in use for anything but consumer stuff. Optical audio works, but it's entirely unnecessary.
Professional gear still depends heavily on line-in style connections (unbalanced linelevel audio), so you won't find that going away any time soon.
Most Intel HDA codecs just treat all jacks the same, the only difference is the settings. If you want to play around, grab HDA Analyzer and tweak things to your heart's consent. For example, on my laptop (3 jacks), I can output 5.1 audio, or output 4.0 plus get one mic, or 4.0 plus one input, or output stereo cloned through two jacks (great for listening with a friend), or even make all jacks inputs, route them to the three stereo ADCs, and capture 5.1 analog audio. In fact, as far as I can tell, the only "special" jack is the headphones jack, which appears to go through some sort of extra amp to boost it as an output (more than the codec chip is documented to do, though strangely it still works as an input; it might just be another case of Realtek failing at documentation). Other than that, each jack has "in" and "out" options, a headphone boost option (this is the standard one built-in to the codec), a set of mic preamp settings, and a mic vref setting.
In other words, you just need the right software to do whatever you want with your audio jacks these days. Crappy drivers (both on Linux and Windows) will usually severely limit you, compared to the capabilities of the hardware. At least under Linux, you can always use HDA Analyzer to poke the real hardware settings (on Windows, you're probably SOL).
QA. New releases need to go through QA anyway to make sure they haven't botched anything up.
Usually the release process for a large piece of software requires a certain degree of human interaction (anywhere from light to extreme), and there's always the possibility that something will mess up, even if the bugfix itself is perfectly trivial or safe.
Optimus Maximus isn't vapourware these days, it's just unaffordableware.
CHDK can add plenty of things, though of course if the code is physically missing then it would have to be reimplemented. Consider that CHDK allows RAW mode in cameras that don't originally support it, for example.
It's worth pointing out that CHDK isn't a hacked firmware (that would probably not be legally redistributable), nor is it an alternative firmware (that would be too much work). CHDK is an add-on to the existing firmware, that works by piggibacking on its OS, hooking functions, and spawning off extra processes on the camera's RTOS. This is what makes it so great: you get the original funcionality of the camera plus extra stuff, and you don't have to wait for the developers to add what already came with your camera anyway.