Sega v. Accolade didn't make a distinction based on the type or quantity of content.
Sure it did. As I said, there are two parts to the lawsuit: reverse engineering SEGA games in order to write your own, and copying the SEGA trademark as required for the console to boot. Part 1 doesn't apply here, because the game's code was not copied in order to write the ARDSi code - rather, it was copied because it's essentially a requirement for the console to boot. The distinction is that the lawsuit only relates to trademark law as it relates to getting consoles to boot, not copyright law.
In other words, the lawsuit said: (1) You can reverse engineer game code, copy it internally, use it to learn the underlying operation of the hardware, and write your own game from the knowledge learned (containing little to none of the original code) (2) If the console forces you to include a trademark in order to boot, you may do so, even if you're not actually licensed to use the trademark.
It did not say: (3) You can copy almost an entire game verbatim in order to exploit it to run your own code
The intent is the same - to run your own unlicensed code - but the means are totally different. (3) is not (1) because (1) is about copying code for reverse engineering, but then distributing a final game that includes little to none of the original code. (2) is not (3) because (2) concerns trademarks, and (3) concerns copyright.
This isn't a case of "magical secret code" - there is no magical secret code, Nintendo simply uses cryptographic techniques in order to completely block third-party software. There is, simply put, no way of actually booting third-party software on a DSi without first making use of an exploit or hacked version of original software. The console won't boot your code, it'll only boot a complete, verbatim, unmodified copy of a licensed game executable, so you have to include the entire thing and then work on tricking it into subsequently loading your stuff. And the only reason this works is because Nintendo isn't also signing data. For example, the Wii signs all data, and there you're completely screwed: you can't run original code at all (from a disc).
IANAL either, but; I agree that a whole different case would be needed, but there's already ample provocation to bring one if "they" think they can win. This hasn't happened, so I suspect that the lawyers don't agree with your assessment that it's clear infringement.
DSi carts are relatively recent. The gears of lawyers and the legal system move slowly.
The trademark was included in the code, not shown.
The trademark SEGA string caused the Genesis III to display the "licensed by SEGA" screen. Same thing, effectively speaking.
Not necessarily. Sega v. Accolade was about copying code for reverse engineering (which is an entirely separate issue, and something that plenty of people are "guilty" of these days), and the trademark issue for consoles that require a trademark to boot (like the Nintendo logo required for GB/GBC/GBA games to boot). The only code copied in the end product was that required to show the trademark, which can probably be regarded as non-copyrightable or fair use (the only issue being the actual trademark display). What the case established was that showing this trademark (even though it didn't apply) was fine since it was a technical requirement.
This is different, as the end product doesn't just incorporate a trademark or code that shows a trademark, but rather almost a megabyte of a game. That falls under copyright infringement, not trademark misuse. IANAL, but in my opinion a whole different case would be needed to establish whether copying a large amount of code/assets/whatever can be regarded as fair use if it is a requirement to be able to run unlicensed original code. This is a long way from just showing a SEGA or Nintendo trademark.
The AR DSi comes with the ROM (obfuscated inside internal flash), presumably because they don't expect users of a cheating device to go out hunting for warez. The makers of piracy cartridges probably assume their users are capable of such a feat - ironically, rendering the piracy carts more legal than the AR DSi, since they don't actually come with the ROM.
Every single DSi-compatible DS cart, including Datel's Action Replay DSi, includes portions of a pirated cart ROM. Nintendo started signing all executables and retroactively signing the existing library of DS games (they include the hashes built in to the DSi firmware), so the only way you can get an unofficial DS cart to run on the DSi is by pirating a game's executable/header and partial data and then using a data file exploit (data files aren't signed) to make it bootstrap your code. These DSi-compatible cartridges even show up with the game icon of a real game in the menu, since that part is also signed.
If that isn't a lawsuit in the making then I don't know what is.
No, they're unconditionally crippling themselves in detriment to the OSes that actually could support the newer technology. What WD isn't doing isn't just backwards compatibility, it's decreasing the value of a new feature and increasing confusion by pretending not to have that feature while having hidden performance issues when OSes (rightly) treat it like a normal drive.
The Right Way to do it would be to have a jumper to enable and disable the emulation. Failing that, just default to 4KB mode and let the market come up with 4K -> 512byte emulation adapters if people truly demand them.
That's weird. I do know that non-SDHC cards can have larger sectors, but I didn't expect it to be a requirement for the 1GB-4GB range. Non-SDHC SD card addressing works on byte offsets (so effectively all block addressing it multiplied by the block size, even though it has to be block aligned anyway), so using larger blocks provides no benefit (it's not like ATA/SATA HDDs where blocks are addressed in units of, well, blocks). In fact, all SDHC did was change the addressing to block units and fix the block size at 512 bytes (besides some initialization sequence changes), so SDHC cards can handle up to 512B x 4G = 2TiB (they currently limit it at 32GiB per spec, but that's not a technical limit).
To answer your question, whether it's visible to the OS would definitely depend on the card reader. It will definitely be visible with raw SD Host Controllers (built-in PCI readers and the like), but USB readers can do all sorts of weird stuff.
All CD-ROM drives use 2K sectors, but the issue is mitigated because people don't use regular HDD filesystems on CD-ROMs. DVD drives actually use 64K sectors or something along those lines, but they emulate 2K sectors for legacy reasons (though at least here you don't have read-modify-write issues).
That's a nice idea. You know, some drives already do this for 128GiB limiting and SATA 1.5Gbps mode forcing, but even there some crappy Western Digital drives have ditched jumpers: they'll let you force 1.5Gbps SATA speed mode, but you have to use a program to change the mode! That means if you don't have a supported motherboard you need to find another computer, plug in the drive, boot into DOS from a CD, and hope their crappy DOS tool supports your SATA hardware.
The MBR is the DOS partition table. The BIOS has nothing to do with partitions, as it just launches the code located in the MBR (which is in charge of deciding which partition to boot). GUID Partition Tables are supported by Linux, which is what we're talking about here, so there's no reason not to use them unless you also require a legacy OS.
You seem to think that DOS has some sort of underlying level of partitioning that we no longer use. That's not the case - the MBR partitions used today are still the same old craptacular DOS partitions (with LBA extensions tacked on), and they are managed by fdisk.
If you ever want to use a hard drive over 2TB, the DOS MBR partition table format will not work. You'll have to use GPT or you'll lose all capacity above 2TB. Well, maybe with some hacks (which no doubt will not be well supported by some/most OSes due to 32bit math issues) you'll be able to cram in two partitions of 2TB size each (maximum), but I doubt that'll catch on due to the aforementioned OS support problem, and there's no way of breaking the 4TB barrier with the current format.
An antique system is going to run into several other issues if you try to drop in a newer HDD, among them CHS->LBA, LBA->LBA48, and IDE->SATA. Not to mention that we're talking about new drives here - starting to manufacture 4KB drives doesn't mean ceasing to manufacture 512-byte drives. Right now the Windows XP issue means no one can get any true 4KB drives at all.
By the time replacement components are no longer available at all, the remaining die-hard users of antique hardware will be creating adapter hardware that can do the necessary conversion and 512-byte-sector emulation. And since this antique hardware will invariably be much slower than the drive anyway, the speed overhead will be negligible.
Bad example. Pin spacing in multiples of 1/10th of an inch was the standard for through-hole electronics components, but with the switch to surface mount everything is being switched over to mm. The first and largest surface mount packages (SOIC, PLCC, etc) used 1/200 in spacing, but pretty much everything smaller is using fractions of a mm. And connectors smaller than your standard humongous (these days) pin headers are also done in mm: flat flexible cables, tighter pitch connectors (e.g. the pin headers on laptop IDE HDDs are 2mm), etc.
I'm European and I was initially annoyed when I started using SMT components and things wouldn't match up on my grid (since I was used to a grid in mils from through-hole design), but these days I just default to a metric grid and use the relevant auto-snap features of layout programs to make traces seamlessly switch from the metric grid to being aligned to a one-off through-hole component. It's really just a base unit change, as the old "imperial" components were just measured in mils (thousandths of an inch), which is already a metric-style subdivision applied to an imperial base unit.
We (the Spanish) didn't have a truly terrible time with it, because 6 Euro happened to be damn near 1000 Pesetas (it's actually €6.01, but no one cares), so we were saved by the inverse relationship. That was the reference point that everyone used during the transition, and in fact most people still think of large amounts of money in terms of millions of pesetas. This is why you'll often hear people calling €6000 "un kilo" (1 million pesetas used to be called a "kilo" - no, it doesn't make sense).
That was exactly my point - I was referring to SD and other Flash memory external interface standards, not the underlying NAND chips. At the SD interface level, sectors are 512b most of the time (or always, for SDHC), but the physical NAND devices are 2K/4K, so the interface would benefit from using the native sector size.
I was referring to Windows XP - I should've mentioned it explicitly. Nonetheless,
There's a lot of old stuff, including Windows XP that can't deal with 4K sectors.
There's exactly one old thing used in any significant quantity and liable to have to work with these drives, and it's Windows XP. Everything else either isn't in any significant use any more, or will never be seeing one of these drives.
One potential concern would be USB enclosures which have to work with older OSes / devices. To that, I would say it should be the enclosure's job to do the 512-byte sector emulator, not the drive's.
Windows XP has been updated over the years (via service packs and the like) to handle hardware that didn't exist at the time of its release, including things like SATA. They could do the same for 4k sector disks, but they aren't going to do it because they want people to move to Win7. Therefore, Microsoft is still to blame for neither 1) providing a solution for XP, nor 2) providing enough compelling reasons to migrate to Win7. Heck, Vista was a trainwreck and it doesn't really count, so (proper) Windows is actually 3 years late to the 4k party, as Windows 7 was only released in 2009. Effectively, they've spent those three years scaling down support for XP while providing no viable alternative, and now the rest of the world has to deal with a significant amount of people still using a 9-year-old OS.
In short: the fact that people are sticking to 9-year-old XP and making hardware companies break or slow down improvements means Microsoft did something terribly wrong.
There are no hard drives with logical 4k sector sizes out there, as they all emulate 512-byte sectors for compatibility, so your point is moot. However, if they did exist, they would theoretically work with Windows 7. I was talking about Windows XP.
What the GP is advocating is not using a partition table, instead of partitioning drives into one partition. This doesn't cause the issue mentioned in the article. This isn't a novel idea - there are some USB drives that do this already, and even Windows seems to cope fine.
The beauty isn't Closed Source, it's Market Monopoly. You know, the one guaranteeing that device manufacturers make up for your failures by deviating from standards in order to make sure that their devices work out of the box with your broken OS.
Unless your BIOS is trying to be too smart and peeking into your partitions instead of launching the MBR (sadly, some do), it won't matter. It's the MBR's job to boot your system after the BIOS hands off control to it, and on most Linux systems the bootloader is installed straight into the MBR.
fdisk doesn't need to be fixed, it needs to be deprecated. DOS partition tables are a ridiculously bad artifact of the past. We won't be using them for much longer anyway; they're limited to 2TB for 512-byte-sector drives (or 4K drives with 512-byte emulation).
Exactly. Drives are pretending to have 512-byte sectors because Windows can't deal with 4k sectors, and then silently reducing performance when you believe them and use 512-byte sector sizes. Had the drives reported 4k sector sizes, they'd work great under Linux and not at all under Windows.
This isn't a Linux problem, it's a drive problem caused by Windows. The solution is to implement yet another workaround for stupid devices, and start aligning partitions to 4k by default.
Nitpick: SDHC card sectors are always 512 bytes, and most SD card sectors are 512 bytes too. Flash memory would benefit from larger sector sizes too, but they've probably stuck to 512 bytes for Windows compatibility.
There are plenty of 2cm 2.4Ghz antennas - see 90% of the Bluetooth dongles out there. They may not be the most efficient antennas in the world, but they do work.
Exactly. Any Wi-Fi card these days can work in AP mode, so any cellphone with Wi-Fi can potentially do this already. Manufacturers just don't care to do it and/or telcos don't care to allow it.
On an unrelated note, how on earth are they pulling this off? As far as I know, at least regular SIMs are limited to pretty low power, the data rate is really low, and they don't have access to the cellphone's data connection. I can't see this working unless USIM was expressly designed to support this kind of usage; it certainly requires a lot of cooperation from the phone, it would have to be part of the standard to begin with.
Now if only mencoder didn't suck... mplayer is great at playing all sorts of files, broken or not, but mencoder's muxer seems to have some real issues. I was completely unable to get a properly muxed h.264 HD file out of mencoder. Having an "all-in-one" tool for video processing defeats the purpose if you end up having to use a separate tool to do the final mux.
Slashdot Mirror
Sure it did. As I said, there are two parts to the lawsuit: reverse engineering SEGA games in order to write your own, and copying the SEGA trademark as required for the console to boot. Part 1 doesn't apply here, because the game's code was not copied in order to write the ARDSi code - rather, it was copied because it's essentially a requirement for the console to boot. The distinction is that the lawsuit only relates to trademark law as it relates to getting consoles to boot, not copyright law.
In other words, the lawsuit said:
(1) You can reverse engineer game code, copy it internally, use it to learn the underlying operation of the hardware, and write your own game from the knowledge learned (containing little to none of the original code)
(2) If the console forces you to include a trademark in order to boot, you may do so, even if you're not actually licensed to use the trademark.
It did not say:
(3) You can copy almost an entire game verbatim in order to exploit it to run your own code
The intent is the same - to run your own unlicensed code - but the means are totally different. (3) is not (1) because (1) is about copying code for reverse engineering, but then distributing a final game that includes little to none of the original code. (2) is not (3) because (2) concerns trademarks, and (3) concerns copyright.
This isn't a case of "magical secret code" - there is no magical secret code, Nintendo simply uses cryptographic techniques in order to completely block third-party software. There is, simply put, no way of actually booting third-party software on a DSi without first making use of an exploit or hacked version of original software. The console won't boot your code, it'll only boot a complete, verbatim, unmodified copy of a licensed game executable, so you have to include the entire thing and then work on tricking it into subsequently loading your stuff. And the only reason this works is because Nintendo isn't also signing data. For example, the Wii signs all data, and there you're completely screwed: you can't run original code at all (from a disc).
DSi carts are relatively recent. The gears of lawyers and the legal system move slowly.
The trademark SEGA string caused the Genesis III to display the "licensed by SEGA" screen. Same thing, effectively speaking.
Not necessarily. Sega v. Accolade was about copying code for reverse engineering (which is an entirely separate issue, and something that plenty of people are "guilty" of these days), and the trademark issue for consoles that require a trademark to boot (like the Nintendo logo required for GB/GBC/GBA games to boot). The only code copied in the end product was that required to show the trademark, which can probably be regarded as non-copyrightable or fair use (the only issue being the actual trademark display). What the case established was that showing this trademark (even though it didn't apply) was fine since it was a technical requirement.
This is different, as the end product doesn't just incorporate a trademark or code that shows a trademark, but rather almost a megabyte of a game. That falls under copyright infringement, not trademark misuse. IANAL, but in my opinion a whole different case would be needed to establish whether copying a large amount of code/assets/whatever can be regarded as fair use if it is a requirement to be able to run unlicensed original code. This is a long way from just showing a SEGA or Nintendo trademark.
The AR DSi comes with the ROM (obfuscated inside internal flash), presumably because they don't expect users of a cheating device to go out hunting for warez. The makers of piracy cartridges probably assume their users are capable of such a feat - ironically, rendering the piracy carts more legal than the AR DSi, since they don't actually come with the ROM.
Every single DSi-compatible DS cart, including Datel's Action Replay DSi, includes portions of a pirated cart ROM. Nintendo started signing all executables and retroactively signing the existing library of DS games (they include the hashes built in to the DSi firmware), so the only way you can get an unofficial DS cart to run on the DSi is by pirating a game's executable/header and partial data and then using a data file exploit (data files aren't signed) to make it bootstrap your code. These DSi-compatible cartridges even show up with the game icon of a real game in the menu, since that part is also signed.
If that isn't a lawsuit in the making then I don't know what is.
Because they'd love to be able to work on improving the existing wheel instead, but, unfortunately, they can't.
No, they're unconditionally crippling themselves in detriment to the OSes that actually could support the newer technology. What WD isn't doing isn't just backwards compatibility, it's decreasing the value of a new feature and increasing confusion by pretending not to have that feature while having hidden performance issues when OSes (rightly) treat it like a normal drive.
The Right Way to do it would be to have a jumper to enable and disable the emulation. Failing that, just default to 4KB mode and let the market come up with 4K -> 512byte emulation adapters if people truly demand them.
That's weird. I do know that non-SDHC cards can have larger sectors, but I didn't expect it to be a requirement for the 1GB-4GB range. Non-SDHC SD card addressing works on byte offsets (so effectively all block addressing it multiplied by the block size, even though it has to be block aligned anyway), so using larger blocks provides no benefit (it's not like ATA/SATA HDDs where blocks are addressed in units of, well, blocks). In fact, all SDHC did was change the addressing to block units and fix the block size at 512 bytes (besides some initialization sequence changes), so SDHC cards can handle up to 512B x 4G = 2TiB (they currently limit it at 32GiB per spec, but that's not a technical limit).
To answer your question, whether it's visible to the OS would definitely depend on the card reader. It will definitely be visible with raw SD Host Controllers (built-in PCI readers and the like), but USB readers can do all sorts of weird stuff.
All CD-ROM drives use 2K sectors, but the issue is mitigated because people don't use regular HDD filesystems on CD-ROMs. DVD drives actually use 64K sectors or something along those lines, but they emulate 2K sectors for legacy reasons (though at least here you don't have read-modify-write issues).
That's a nice idea. You know, some drives already do this for 128GiB limiting and SATA 1.5Gbps mode forcing, but even there some crappy Western Digital drives have ditched jumpers: they'll let you force 1.5Gbps SATA speed mode, but you have to use a program to change the mode! That means if you don't have a supported motherboard you need to find another computer, plug in the drive, boot into DOS from a CD, and hope their crappy DOS tool supports your SATA hardware.
I fully agree, I liked jumpers too.
The MBR is the DOS partition table. The BIOS has nothing to do with partitions, as it just launches the code located in the MBR (which is in charge of deciding which partition to boot). GUID Partition Tables are supported by Linux, which is what we're talking about here, so there's no reason not to use them unless you also require a legacy OS.
You seem to think that DOS has some sort of underlying level of partitioning that we no longer use. That's not the case - the MBR partitions used today are still the same old craptacular DOS partitions (with LBA extensions tacked on), and they are managed by fdisk.
If you ever want to use a hard drive over 2TB, the DOS MBR partition table format will not work. You'll have to use GPT or you'll lose all capacity above 2TB. Well, maybe with some hacks (which no doubt will not be well supported by some/most OSes due to 32bit math issues) you'll be able to cram in two partitions of 2TB size each (maximum), but I doubt that'll catch on due to the aforementioned OS support problem, and there's no way of breaking the 4TB barrier with the current format.
An antique system is going to run into several other issues if you try to drop in a newer HDD, among them CHS->LBA, LBA->LBA48, and IDE->SATA. Not to mention that we're talking about new drives here - starting to manufacture 4KB drives doesn't mean ceasing to manufacture 512-byte drives. Right now the Windows XP issue means no one can get any true 4KB drives at all.
By the time replacement components are no longer available at all, the remaining die-hard users of antique hardware will be creating adapter hardware that can do the necessary conversion and 512-byte-sector emulation. And since this antique hardware will invariably be much slower than the drive anyway, the speed overhead will be negligible.
That should be 1/20 in spacing, not 1/200.
Bad example. Pin spacing in multiples of 1/10th of an inch was the standard for through-hole electronics components, but with the switch to surface mount everything is being switched over to mm. The first and largest surface mount packages (SOIC, PLCC, etc) used 1/200 in spacing, but pretty much everything smaller is using fractions of a mm. And connectors smaller than your standard humongous (these days) pin headers are also done in mm: flat flexible cables, tighter pitch connectors (e.g. the pin headers on laptop IDE HDDs are 2mm), etc.
I'm European and I was initially annoyed when I started using SMT components and things wouldn't match up on my grid (since I was used to a grid in mils from through-hole design), but these days I just default to a metric grid and use the relevant auto-snap features of layout programs to make traces seamlessly switch from the metric grid to being aligned to a one-off through-hole component. It's really just a base unit change, as the old "imperial" components were just measured in mils (thousandths of an inch), which is already a metric-style subdivision applied to an imperial base unit.
We (the Spanish) didn't have a truly terrible time with it, because 6 Euro happened to be damn near 1000 Pesetas (it's actually €6.01, but no one cares), so we were saved by the inverse relationship. That was the reference point that everyone used during the transition, and in fact most people still think of large amounts of money in terms of millions of pesetas. This is why you'll often hear people calling €6000 "un kilo" (1 million pesetas used to be called a "kilo" - no, it doesn't make sense).
That was exactly my point - I was referring to SD and other Flash memory external interface standards, not the underlying NAND chips. At the SD interface level, sectors are 512b most of the time (or always, for SDHC), but the physical NAND devices are 2K/4K, so the interface would benefit from using the native sector size.
I was referring to Windows XP - I should've mentioned it explicitly. Nonetheless,
There's exactly one old thing used in any significant quantity and liable to have to work with these drives, and it's Windows XP. Everything else either isn't in any significant use any more, or will never be seeing one of these drives.
One potential concern would be USB enclosures which have to work with older OSes / devices. To that, I would say it should be the enclosure's job to do the 512-byte sector emulator, not the drive's.
Windows XP has been updated over the years (via service packs and the like) to handle hardware that didn't exist at the time of its release, including things like SATA. They could do the same for 4k sector disks, but they aren't going to do it because they want people to move to Win7. Therefore, Microsoft is still to blame for neither 1) providing a solution for XP, nor 2) providing enough compelling reasons to migrate to Win7. Heck, Vista was a trainwreck and it doesn't really count, so (proper) Windows is actually 3 years late to the 4k party, as Windows 7 was only released in 2009. Effectively, they've spent those three years scaling down support for XP while providing no viable alternative, and now the rest of the world has to deal with a significant amount of people still using a 9-year-old OS.
In short: the fact that people are sticking to 9-year-old XP and making hardware companies break or slow down improvements means Microsoft did something terribly wrong.
There are no hard drives with logical 4k sector sizes out there, as they all emulate 512-byte sectors for compatibility, so your point is moot. However, if they did exist, they would theoretically work with Windows 7. I was talking about Windows XP.
What the GP is advocating is not using a partition table, instead of partitioning drives into one partition. This doesn't cause the issue mentioned in the article. This isn't a novel idea - there are some USB drives that do this already, and even Windows seems to cope fine.
The beauty isn't Closed Source, it's Market Monopoly. You know, the one guaranteeing that device manufacturers make up for your failures by deviating from standards in order to make sure that their devices work out of the box with your broken OS.
Unless your BIOS is trying to be too smart and peeking into your partitions instead of launching the MBR (sadly, some do), it won't matter. It's the MBR's job to boot your system after the BIOS hands off control to it, and on most Linux systems the bootloader is installed straight into the MBR.
fdisk doesn't need to be fixed, it needs to be deprecated. DOS partition tables are a ridiculously bad artifact of the past. We won't be using them for much longer anyway; they're limited to 2TB for 512-byte-sector drives (or 4K drives with 512-byte emulation).
Exactly. Drives are pretending to have 512-byte sectors because Windows can't deal with 4k sectors, and then silently reducing performance when you believe them and use 512-byte sector sizes. Had the drives reported 4k sector sizes, they'd work great under Linux and not at all under Windows.
This isn't a Linux problem, it's a drive problem caused by Windows. The solution is to implement yet another workaround for stupid devices, and start aligning partitions to 4k by default.
Nitpick: SDHC card sectors are always 512 bytes, and most SD card sectors are 512 bytes too. Flash memory would benefit from larger sector sizes too, but they've probably stuck to 512 bytes for Windows compatibility.
There are plenty of 2cm 2.4Ghz antennas - see 90% of the Bluetooth dongles out there. They may not be the most efficient antennas in the world, but they do work.
Exactly. Any Wi-Fi card these days can work in AP mode, so any cellphone with Wi-Fi can potentially do this already. Manufacturers just don't care to do it and/or telcos don't care to allow it.
On an unrelated note, how on earth are they pulling this off? As far as I know, at least regular SIMs are limited to pretty low power, the data rate is really low, and they don't have access to the cellphone's data connection. I can't see this working unless USIM was expressly designed to support this kind of usage; it certainly requires a lot of cooperation from the phone, it would have to be part of the standard to begin with.
Now if only mencoder didn't suck... mplayer is great at playing all sorts of files, broken or not, but mencoder's muxer seems to have some real issues. I was completely unable to get a properly muxed h.264 HD file out of mencoder. Having an "all-in-one" tool for video processing defeats the purpose if you end up having to use a separate tool to do the final mux.