I take that back then. I hope Gnash makes significant improvement in the following years. Then again, if "it's not a huge deal" I wonder why they aren't progressing faster. I was under the impression that Gnash was moving slowly because the project had to be quite picky about developers to remain legal, since the existing spec was off-limits.
FLV is a flash video format. Mplayer already plays FLVs just fine. This has little to do with flash video sites, which use SWF to create their own players for FLV content (and often the FLV location is obfuscated and keyed, so you need to interpret the SWF to get to it). It is impossible to get YouTube to work with only an FLV player. Crude hacks like using Adobe's plugin to download the video to/tmp and then playing it with mplayer aren't really viable for end-users.
The SWF format was completely closed until May 1, 2008, and even now it's still missing bits and pieces. Gnash devs have had less than a year and a half to work with a real specification, so it's no surprise that they're still quite a ways behind the official Adobe Flash.
Gnash will never be finished because it relies on reverse engineering Flash files and the like. Gnash developers cannot see or use Adobe's specification, as doing so would be violating Adobe's terms.
Make no mistake, Adobe is trying to block any competing Flash players as much as the law will allow them to.
MP3 is an open format, just a patented one. Big difference. There are tons of MP3 implementations and they can talk to each other. And Fluendo makes a free-as-in-beer fully legal MP3 codec for Linux.
Some WinModems had drivers for Linux that worked decently. It varied from vendor to vendor. And you could always buy a real modem.
As far as I know, WiFi support for most chipsets is quite decent on Linux these days. But that's irrelevant, because you have a choice - you can buy another vendor's card, and they all interoperate with the same open WiFi specification. This is very different from the Flash issue.
NVidia has relatively great drivers for Linux, including multiple screens. I'm using xinerama right now and all I had to do was plug the second monitor in and open nvidia-settings to tell it how the monitors should be arranged. It was about the same, if not easier, than doing the same thing under Windows. And at least you get to pick between NVidia, Intel, or ATI
Users have a choice with every one of those 4 examples. They do not have a choice with Flash, as there is only one vendor with a half-decent implementation and they block any potential competitors from using their specification.
Slow fullscreen is still Flash's fault. It may be [i]tolerable[/i] with certain card drivers and if your screen resolution is low enough, but the bulk of the problem is still Adobe's. I have an Nvidia that works great for everything else, but fullscreen Flash is unwatchable at 1920x1080.
Linux isn't broken because Flash sucks, the "Ready For the Desktop" moniker is broken if people consider it to imply Flash support. Flash is a closed technology (the spec is only open if you're not writing a player), which puts any problems with Flash playback anywhere squarely into Adobe's hands. If being "ready for the desktop" implies "Adobe plays nice with you" and there is nothing you can do if they don't, something is really wrong. What is the Linux community supposed to do, hold Adobe at gunpoint until they fix Flash?
I'm not saying Linux is otherwise ready for the desktop (and complaints about issues with Linux desktops themselves are perfectly okay), but Flash brokenness is a silly example.
Whichever way you put it, the fact that this "basic thing that everyone else takes for granted" doesn't work is is Adobe's fault, not the Linux community's fault. It would have made a lot more sense if the complaint were about some actual bug in Linux distros, not a problem with a historically shoddy proprietary plugin.
That's one of the more annoying XKCDs as far as I'm concerned. It seems to imply that the full-screen Flash video woes are somehow the kernel's fault. I used to like XKCD, but it seems to be getting dumber and dumber each day.
To put things into perspective, you can factor RSA-384 in a few hours on a decent desktop computer. That's a number like 165375296535705386155571228848957419 6982006687461869497532793906938608837243 5801577531013884898737786797134855942291 (whose factors are 1845911360880639167287667999134101328853184774154263277561 and 8959005293559105489286020014804938358380924734239385853931, by the way). So although the algorithm is much more efficient in theory, they still have quite a ways to go before being an improvement over existing computers:)
Oh, and not just software ones. I randomly stumbled upon a patent for connecting invidual buttons to microcontroller pins (that is, without matrixing them) to allow any arbitrary combination of buttons to be pressed without the need for isolation diodes. In other words, it's a patent for not using a technique. I should patent "a display device containing an individual connection for each display element" and sue everyone who makes a device with one or two discrete non-matrixed LEDs. Or maybe patent "a digital communications technique involving the use of an individual electric current transport device for each individual bit of data to be transferred" and sue everyone who doesn't use some form of serial encoding to transfer data.,
It worked for the better for MP3 (Vorbis) and GIF (PNG), but we're still struggling to get Theora up to h.264's level. I'm personally not sure it's ever going to *quite* happen if they restrict themselves from using patented h.264 features. Nevermind that Theora might infringe on some patents (in fact, it almost certainly does). You can only be sure that something infringes on a patent once you find it, but you'll never know whether there are any patents that cover a portion of your algorithm until they show up trying to sue you.
The only reason why patents "drive" development is by forcing people to develop a non-infringing alternative, and they tend to improve upon it to drive users away from the patented version. A lot less time would be wasted if the open source community could just improve upon existing standards without having to reinvent everything from scratch.
This. Locking multiple groups of people out of your hardware with the same system is a great way to get it cracked faster. It's doubly stupid when the group that you've just locked out is the more technically capable one (Linux users and serious researchers), while the other group (piracy) tends to feed off of what other people have already done for them.
Just read this table. Let's see how long it takes for that black pair of boxes to become grey and red.
Wrong. The Homebrew Channel uses an undisclosed exploit to install itself that the warez people don't know about. Currenty they're using an older exploit that Nintendo failed to patch to install their stuff. The patch cycle for the past couple of updates has been like this:
- Nintendo releases update, breaks everything - We use an exploit that we developed to release a new version of HBC (this is useless for the pirates because they still can't use that to install their patched IOSes, it only lets you run homebrew without installing hacked versions of anything) - The pirates discover some complicated, dangerous, typically illegal trick to get their stuff to work anyway. The latest couple have been IOS16 (part of a leaked service center disc) and an older exploit that comex wrote which went largely unnoticed until someone realized that it still worked on the latest firmware.
The people behind warez utilities are quite incompetent and unable to come up with exploits of their own (or reverse engineer ours). However, they've been lucky enough / Nintendo has been stupid enough so far that they've found (crude) workarounds for the past couple of patch cycles.
However, since BootMii has been released now (which gives users full ARM code execution, no questions asked), the pirates will just use that next time Nintendo fixes their exploits, so they no longer have to come up with exploits of their own.
The issue isn't security through obscurity. It's just that Nintendo's security sucks. Examples: plaintext RAM with no checksums, no signature verification for already installed content, the strncmp() signature fiasco, not adding a dummy IOS16 the first time they tried to fix strncmp() across the board, duplicating production keys into the IOS binary code, no NX type protection, poor security practices for IOS drivers, blatantly exploitable system calls and IOS RPC calls, and the list goes on.
However, I am still tempted to get the backup stuff working on an old USB HDD and putting all of our games on it.
As one of the authors of the Homebrew Channel and someone who has spent way too much time analyzing the Wii software, I'll just say that installing any of the backup stuff is going straight into poorly coded dangerous software territory. Not to mention that most of it is illegal in and of itself (not in the DMCA circumvention device kind of way, which we all know about, but in the distributing leaked/modified/etc Nintendo software kind of way - the piracy tools themselves contain pirated bits and pieces of Nintendo software) You've been warned.
If you're concerned about your discs, just wait until they start to die. No one's going to blame you for downloading a game that you own and then thinking about installing the tools to run it,
Except for the fact that you have to use these tools to even be able to launch any homebrew application. The fact is that you can't run any homebrew on the Wii without first taking the risks you're talking about.
You do NOT need to take those risks just to run homebrew, and running homebrew is pretty much completely safe these days (there are always some theoretical risks risks, of course, but the practical incidence of issues is just about zero). If you disagree, please point me to a single report of someone having bricked their console by using our official installer (people who have previously applied warez hacks need not apply). Again, you're confusing the tools you need to just run applications (that is, Bannerbomb at a minimum, and then The Homebrew Channel if you want convenience) with the tools used to pirate games: not just the loaders - those are safe - but the system software (IOS) hacks and the extremely nasty exploits used to install them (because the people who write these things aren't real reverse engineers and don't know any better).
Piracy tools are extremely dangerous for two reasons: 1) you need to fundamentally patch the Wii software to run pirate games (so it'll read game data from another source), and 2) the people behind them are often highly incompetent. As a result, you get things like cIOScorp, which replaces every single version of IOS with a single patched version. That's the equivalent of taking a whole bunch of shared object sonames for a single library (each with different ABI quirks) and replacing them all with a single, patched version. Where this shared object is as critical as the C library.
Besides the actual insane hacks they use, their installers are almost universally crappy. They don't check return codes, so often they'll uninstall some critical piece of system software, then fail to install it again. Running any piracy tools while your internal storage is near full is almost a guaranteed recipe for a permanent brick. I also know this because I make a device to help repair issues generally caused by using out-of-region games and people often ask me if they can use it to repair their consoles after one of these accidents (the answer, invariably, is to send the Wii to Nintendo and pay their normal repair fee). I've had dozens and dozens of people tell me personally about having bricked their Wiis with piracy software, and none at all who have had any issues installing homebrew using our installer.
This despite the fact that I could no longer play my foreign games (like No More Heroes with blood instead of coins) if homebrew would no longer work.
You don't need nasty hacks to play imports. Playing imports with homebrew is perfectly safe, since it only involves a replacement game loader that doesn't check for the region (it's something optional, not enforced by the IOS security software). This is totally safe (and useless to warez games). The critical difference is that warez game loaders need to patch IOS so it can at game runtime continue to load data from whatever media the game is stored on. Region-free loaders are just disc loaders, you can write one in a couple hundred lines of code using the stock Wii software and without the need for any hacks beyond running PowerPC code. You don't even need to touch a single file on NAND - you could run a region-free disc loader from Bannerbomb, which is basically provably safe because it doesn't touch persistent storage. This is completely different from piracy tools, all of which need to permanently alter system software one way or another.
To debunk your specific claims:
It has been streamlined, but you're basically modifying the Wii's firmware, which is were the risk of bricking your console comes from.
The Homebrew Channel is an _installable_ application that makes _zero_ changes to your firmware. It installs itself exactly as a WiiWare channel would. Its installer perfor
The fact is that the only thing separating the homebrew tools from piracy tools is what the user deem moral or not. The exact same tools used for homebrew are used for piracy.
Ha ha no. A homebrew tool is one that takes an executable file and runs it. A piracy tool is an executable file that fucks up half of your system, has a 50% chance of bricking it, then plays pirated disc games or installs pirated VC games. Piracy apps are specific, considerably sleazier, lower quality, and more dangerous than most homebrew. They also tend to violate software licenses left and right. Not to mention that one of the main guys behind them has a habit of ripping off other people's work and releasing it as his own, adding his sponsor's banners and making a profit.
Tools to play copied games aren't "homebrew tools", they're piracy tools. You're confusing "backups" with homebrew. "Backup" tools were developed for and by pirates, and the "backup" argument is a thin screen that they hide behind. I'd say less than 1% of their users truly use the tools for only backing up games. VC piracy utilities have a 0% legitimate use rate, since VC games can already be backed up to an SD card using Nintendo's system menu.
As for modchips, consider this: they are hugely popular and there is a huge industry behind them (they are more popular than softmods), and yet all of them are trivially detectable by software. All Nintendo could do is push out a software update and instantly break every single modchip out there, causing mayhem among the piracy community. One little update. And yet they haven't done so.
No, really. The've shown that they believe that Wii homebrew == Wii piracy (having attacked generic homebrew almost exclusively, not just piracy tools, and considering that they harassed us when we attempted to notify them of a security issue), and yet it's been over 5 months since the latest security-related update. Somehow I don't get the felling that Nintendo is interested in combating Wii piracy very much (it's not like they've done a whole lot to stop modchips either).
I never said it didn't. The DS doesn't support WPA; the Wii does. I only mentioned the Wii in relation to the broader issue of hardcoding everything into games.
All current consoles use PowerPC. On a PC, you can use SSE if you want true single or double precision operations. But either way, the real fix is to make your game engine robust enough to tolerate minute differences due to rounding. It's not that hard. If you're comparing floating-point values for equality or relying on "dead reckoning" with no compensation to sync up online, then you're already doing it wrong.
Nintendo loves the ancient concept of having games statically link the system libraries and drivers (they still do that, even for the Wii). That's the reason - each WiFi-enabled game includes a copy of the WiFi setup screen and talks directly to the hardware. They've (shortsightedly) defined the DS hardware to support WEP only, and they can't change that now without breaking existing software.
I've already ranted about this before. Basically, Nintendo has locked themselves out of practically any update or improvement on both the DS and Wii fronts. For example, they will never be able to improve upon the Wii home menu, since a copy of it is bundled with every game and they can't replace it. The only exception to this rule are the IOS drivers for Wii titles, which are upgradable, but they make up for that by using retardedly low-level interfaces for them and apparently having policies in place of never touching existing versions of IOS except for security purposes (i.e. closing exploits). This is, say, why a system-level all-game background WiiSpeak VoIP will never, ever happen.
Uh, no, otherwise PowerPC Macs wouldn't be able to talk TCP/IP with Intel-based PCs. What you do is define the protocol to use one endian and the platforms that use the opposite just convert incoming data. Usually you'd define the on-wire protocol to use big-endian (also called "network endian" - it's also what TCP/IP uses). The same thing works for file formats, though there a third option that seems to be reasonably popular is to allow for both endiannesses in the format, using a magic word to distinguish between them. Then all ports of the software need to include the ability to swap bytes as they read a file.
IIRC both consoles have a fast instruction to swap the bytes of a word, so the overhead is trivial. Endianness is a complete non-issue regarding network interoperability.
Slashdot Mirror
Flash is by no means "simple". There are a bunch of different speficiations and sub-specifications to be implemented (ActionScript, FLV, RTMP, ...).
I take that back then. I hope Gnash makes significant improvement in the following years. Then again, if "it's not a huge deal" I wonder why they aren't progressing faster. I was under the impression that Gnash was moving slowly because the project had to be quite picky about developers to remain legal, since the existing spec was off-limits.
FLV is a flash video format. Mplayer already plays FLVs just fine. This has little to do with flash video sites, which use SWF to create their own players for FLV content (and often the FLV location is obfuscated and keyed, so you need to interpret the SWF to get to it). It is impossible to get YouTube to work with only an FLV player. Crude hacks like using Adobe's plugin to download the video to /tmp and then playing it with mplayer aren't really viable for end-users.
The SWF format was completely closed until May 1, 2008, and even now it's still missing bits and pieces. Gnash devs have had less than a year and a half to work with a real specification, so it's no surprise that they're still quite a ways behind the official Adobe Flash.
Gnash will never be finished because it relies on reverse engineering Flash files and the like. Gnash developers cannot see or use Adobe's specification, as doing so would be violating Adobe's terms.
Make no mistake, Adobe is trying to block any competing Flash players as much as the law will allow them to.
Users have a choice with every one of those 4 examples. They do not have a choice with Flash, as there is only one vendor with a half-decent implementation and they block any potential competitors from using their specification.
Damn, somehow my brain was in BBCode mode. My apologies for that.
Slow fullscreen is still Flash's fault. It may be [i]tolerable[/i] with certain card drivers and if your screen resolution is low enough, but the bulk of the problem is still Adobe's. I have an Nvidia that works great for everything else, but fullscreen Flash is unwatchable at 1920x1080.
Linux isn't broken because Flash sucks, the "Ready For the Desktop" moniker is broken if people consider it to imply Flash support. Flash is a closed technology (the spec is only open if you're not writing a player), which puts any problems with Flash playback anywhere squarely into Adobe's hands. If being "ready for the desktop" implies "Adobe plays nice with you" and there is nothing you can do if they don't, something is really wrong. What is the Linux community supposed to do, hold Adobe at gunpoint until they fix Flash?
I'm not saying Linux is otherwise ready for the desktop (and complaints about issues with Linux desktops themselves are perfectly okay), but Flash brokenness is a silly example.
Whichever way you put it, the fact that this "basic thing that everyone else takes for granted" doesn't work is is Adobe's fault, not the Linux community's fault. It would have made a lot more sense if the complaint were about some actual bug in Linux distros, not a problem with a historically shoddy proprietary plugin.
That's one of the more annoying XKCDs as far as I'm concerned. It seems to imply that the full-screen Flash video woes are somehow the kernel's fault. I used to like XKCD, but it seems to be getting dumber and dumber each day.
To put things into perspective, you can factor RSA-384 in a few hours on a decent desktop computer. That's a number like 165375296535705386155571228848957419 6982006687461869497532793906938608837243 5801577531013884898737786797134855942291 (whose factors are 1845911360880639167287667999134101328853184774154263277561 and 8959005293559105489286020014804938358380924734239385853931, by the way). So although the algorithm is much more efficient in theory, they still have quite a ways to go before being an improvement over existing computers :)
Oh, and not just software ones. I randomly stumbled upon a patent for connecting invidual buttons to microcontroller pins (that is, without matrixing them) to allow any arbitrary combination of buttons to be pressed without the need for isolation diodes. In other words, it's a patent for not using a technique. I should patent "a display device containing an individual connection for each display element" and sue everyone who makes a device with one or two discrete non-matrixed LEDs. Or maybe patent "a digital communications technique involving the use of an individual electric current transport device for each individual bit of data to be transferred" and sue everyone who doesn't use some form of serial encoding to transfer data.,
It worked for the better for MP3 (Vorbis) and GIF (PNG), but we're still struggling to get Theora up to h.264's level. I'm personally not sure it's ever going to *quite* happen if they restrict themselves from using patented h.264 features. Nevermind that Theora might infringe on some patents (in fact, it almost certainly does). You can only be sure that something infringes on a patent once you find it, but you'll never know whether there are any patents that cover a portion of your algorithm until they show up trying to sue you.
The only reason why patents "drive" development is by forcing people to develop a non-infringing alternative, and they tend to improve upon it to drive users away from the patented version. A lot less time would be wasted if the open source community could just improve upon existing standards without having to reinvent everything from scratch.
This. Locking multiple groups of people out of your hardware with the same system is a great way to get it cracked faster. It's doubly stupid when the group that you've just locked out is the more technically capable one (Linux users and serious researchers), while the other group (piracy) tends to feed off of what other people have already done for them.
Just read this table. Let's see how long it takes for that black pair of boxes to become grey and red.
Wrong. The Homebrew Channel uses an undisclosed exploit to install itself that the warez people don't know about. Currenty they're using an older exploit that Nintendo failed to patch to install their stuff. The patch cycle for the past couple of updates has been like this:
- Nintendo releases update, breaks everything
- We use an exploit that we developed to release a new version of HBC (this is useless for the pirates because they still can't use that to install their patched IOSes, it only lets you run homebrew without installing hacked versions of anything)
- The pirates discover some complicated, dangerous, typically illegal trick to get their stuff to work anyway. The latest couple have been IOS16 (part of a leaked service center disc) and an older exploit that comex wrote which went largely unnoticed until someone realized that it still worked on the latest firmware.
The people behind warez utilities are quite incompetent and unable to come up with exploits of their own (or reverse engineer ours). However, they've been lucky enough / Nintendo has been stupid enough so far that they've found (crude) workarounds for the past couple of patch cycles.
However, since BootMii has been released now (which gives users full ARM code execution, no questions asked), the pirates will just use that next time Nintendo fixes their exploits, so they no longer have to come up with exploits of their own.
The issue isn't security through obscurity. It's just that Nintendo's security sucks. Examples: plaintext RAM with no checksums, no signature verification for already installed content, the strncmp() signature fiasco, not adding a dummy IOS16 the first time they tried to fix strncmp() across the board, duplicating production keys into the IOS binary code, no NX type protection, poor security practices for IOS drivers, blatantly exploitable system calls and IOS RPC calls, and the list goes on.
As one of the authors of the Homebrew Channel and someone who has spent way too much time analyzing the Wii software, I'll just say that installing any of the backup stuff is going straight into poorly coded dangerous software territory. Not to mention that most of it is illegal in and of itself (not in the DMCA circumvention device kind of way, which we all know about, but in the distributing leaked/modified/etc Nintendo software kind of way - the piracy tools themselves contain pirated bits and pieces of Nintendo software) You've been warned.
If you're concerned about your discs, just wait until they start to die. No one's going to blame you for downloading a game that you own and then thinking about installing the tools to run it,
You do NOT need to take those risks just to run homebrew, and running homebrew is pretty much completely safe these days (there are always some theoretical risks risks, of course, but the practical incidence of issues is just about zero). If you disagree, please point me to a single report of someone having bricked their console by using our official installer (people who have previously applied warez hacks need not apply). Again, you're confusing the tools you need to just run applications (that is, Bannerbomb at a minimum, and then The Homebrew Channel if you want convenience) with the tools used to pirate games: not just the loaders - those are safe - but the system software (IOS) hacks and the extremely nasty exploits used to install them (because the people who write these things aren't real reverse engineers and don't know any better).
Piracy tools are extremely dangerous for two reasons: 1) you need to fundamentally patch the Wii software to run pirate games (so it'll read game data from another source), and 2) the people behind them are often highly incompetent. As a result, you get things like cIOScorp, which replaces every single version of IOS with a single patched version. That's the equivalent of taking a whole bunch of shared object sonames for a single library (each with different ABI quirks) and replacing them all with a single, patched version. Where this shared object is as critical as the C library.
Besides the actual insane hacks they use, their installers are almost universally crappy. They don't check return codes, so often they'll uninstall some critical piece of system software, then fail to install it again. Running any piracy tools while your internal storage is near full is almost a guaranteed recipe for a permanent brick. I also know this because I make a device to help repair issues generally caused by using out-of-region games and people often ask me if they can use it to repair their consoles after one of these accidents (the answer, invariably, is to send the Wii to Nintendo and pay their normal repair fee). I've had dozens and dozens of people tell me personally about having bricked their Wiis with piracy software, and none at all who have had any issues installing homebrew using our installer.
You don't need nasty hacks to play imports. Playing imports with homebrew is perfectly safe, since it only involves a replacement game loader that doesn't check for the region (it's something optional, not enforced by the IOS security software). This is totally safe (and useless to warez games). The critical difference is that warez game loaders need to patch IOS so it can at game runtime continue to load data from whatever media the game is stored on. Region-free loaders are just disc loaders, you can write one in a couple hundred lines of code using the stock Wii software and without the need for any hacks beyond running PowerPC code. You don't even need to touch a single file on NAND - you could run a region-free disc loader from Bannerbomb, which is basically provably safe because it doesn't touch persistent storage. This is completely different from piracy tools, all of which need to permanently alter system software one way or another.
To debunk your specific claims:
The Homebrew Channel is an _installable_ application that makes _zero_ changes to your firmware. It installs itself exactly as a WiiWare channel would. Its installer perfor
Ha ha no. A homebrew tool is one that takes an executable file and runs it. A piracy tool is an executable file that fucks up half of your system, has a 50% chance of bricking it, then plays pirated disc games or installs pirated VC games. Piracy apps are specific, considerably sleazier, lower quality, and more dangerous than most homebrew. They also tend to violate software licenses left and right. Not to mention that one of the main guys behind them has a habit of ripping off other people's work and releasing it as his own, adding his sponsor's banners and making a profit.
Tools to play copied games aren't "homebrew tools", they're piracy tools. You're confusing "backups" with homebrew. "Backup" tools were developed for and by pirates, and the "backup" argument is a thin screen that they hide behind. I'd say less than 1% of their users truly use the tools for only backing up games. VC piracy utilities have a 0% legitimate use rate, since VC games can already be backed up to an SD card using Nintendo's system menu.
As for modchips, consider this: they are hugely popular and there is a huge industry behind them (they are more popular than softmods), and yet all of them are trivially detectable by software. All Nintendo could do is push out a software update and instantly break every single modchip out there, causing mayhem among the piracy community. One little update. And yet they haven't done so.
The author would be a good idea. Or just use the talk page on the wiki.
"Piracy" is copyright infringement only to most people.
No, really. The've shown that they believe that Wii homebrew == Wii piracy (having attacked generic homebrew almost exclusively, not just piracy tools, and considering that they harassed us when we attempted to notify them of a security issue), and yet it's been over 5 months since the latest security-related update. Somehow I don't get the felling that Nintendo is interested in combating Wii piracy very much (it's not like they've done a whole lot to stop modchips either).
I never said it didn't. The DS doesn't support WPA; the Wii does. I only mentioned the Wii in relation to the broader issue of hardcoding everything into games.
All current consoles use PowerPC. On a PC, you can use SSE if you want true single or double precision operations. But either way, the real fix is to make your game engine robust enough to tolerate minute differences due to rounding. It's not that hard. If you're comparing floating-point values for equality or relying on "dead reckoning" with no compensation to sync up online, then you're already doing it wrong.
Nintendo loves the ancient concept of having games statically link the system libraries and drivers (they still do that, even for the Wii). That's the reason - each WiFi-enabled game includes a copy of the WiFi setup screen and talks directly to the hardware. They've (shortsightedly) defined the DS hardware to support WEP only, and they can't change that now without breaking existing software.
I've already ranted about this before. Basically, Nintendo has locked themselves out of practically any update or improvement on both the DS and Wii fronts. For example, they will never be able to improve upon the Wii home menu, since a copy of it is bundled with every game and they can't replace it. The only exception to this rule are the IOS drivers for Wii titles, which are upgradable, but they make up for that by using retardedly low-level interfaces for them and apparently having policies in place of never touching existing versions of IOS except for security purposes (i.e. closing exploits). This is, say, why a system-level all-game background WiiSpeak VoIP will never, ever happen.
Uh, no, otherwise PowerPC Macs wouldn't be able to talk TCP/IP with Intel-based PCs. What you do is define the protocol to use one endian and the platforms that use the opposite just convert incoming data. Usually you'd define the on-wire protocol to use big-endian (also called "network endian" - it's also what TCP/IP uses). The same thing works for file formats, though there a third option that seems to be reasonably popular is to allow for both endiannesses in the format, using a magic word to distinguish between them. Then all ports of the software need to include the ability to swap bytes as they read a file.
IIRC both consoles have a fast instruction to swap the bytes of a word, so the overhead is trivial. Endianness is a complete non-issue regarding network interoperability.