PPP is still in wide use for modern residential internet connections (ADSL uses PPPoEoA or PPPoA quite often, for example). Even 3G modems and the like emulate it to the PC side, unless they're the more recent kind with dedicated usb-ethernet-type protocols.
The bug is that ldd is trying to do the impossible: list dynamic dependencies for executables that it doesn't understand (more precisely: executables that don't use glibc and/or the standard linking mechanisms). The catch is that glibc's implementation offloads this task onto the dynamic linker, and whoever wrote ldd thought the rest of the world would be nice and follow ld-linux's environment variable convention with their dynamic loaders. And, of course, this completely violates the assumption that ldd treats its argument as data, and will not run code from it.
What ldd needs to do is realize that trying to be generic is futile, and either a) check for ld-linux and bail if otherwise, or b) become a real C app (using libbfd?) that can inspect the executable as data, which might gain it compatibility with other loaders if they follow the same ELF ABI for dependency specification. And under no circumstances actually call out to any untrusted code or libraries to do this.
These days the quality of memory is crap though. Just look at NAND flash: there are hundreds of failed blocks on most chips, and these days sectors with a bad bit or two are used and just error corrected. Same with hard disks. You work around this by shoving large amounts of error detection, correction, and relocation logic into the controller.
Let's say each individual bit (!) can be manufactured reliably 99.99% of the time. For a 2048-byte sector (typical for NAND flash), using sector-granularity remapping, there's a ~20% chance of a sector being good. That's not very good, but it still gives you 19% usable capacity. At a terabyte per chip, that's still 190GB of storage. If you add single-bit error correction, you'd get 500GB of storage. At 2-bit correction, 750GB. Current generation Flash memory already uses multiple-bit ECC for MLC level flash memory (where typically 2 bits will fail at once), and sectors with one bad bit(pair) are considered "good enough" and corrected away. If you can manufacture this 1TB storage chip at 99.99% per bit, and especially if most of the failures will happen at manufacture time and not develop later during use, I'll gladly take it given a reasonable amount of error correction wrapping it. It's not like we don't already rely on ECC for our day-to-day storage.
Yield issues affect mainly things like CPUs with no redundancy. With memory, you just lose the damaged parts. Even RAM these days is manufactured with spare blocks that can replace blocks that came out wrong, to increase yield (though it's usually only a few and the remapping is burned in at the factory).
RAM and solid state Flash memory, which is becoming increasingly popular. NOR flash comes in power-of-two sizes, and NAND flash comes in power-of-two main data areas plus some power-of-two over power-of-two fraction in out-of-band area (64 OOB bytes per 2048 data bytes is common). However, Flash wear-leveling by controllers reduces available size, and sometimes they are designed so it works out at closer to a power-of-ten size, but that's just a random target (and they never actually nail it). It's also worth noting that storage block sizes are powers of two (512 byte sectors for HDDs, 2048 bytes for DVDs, and in reality both formats tend to use larger physical sectors of a power-of-two size too). So, in reality, there is no such thing as a purely decimal round size hard disk: it's all crazy mixed multiples that round off to somewhere close to a decimal unit yet still a multiple of a smaller binary unit. People keep complaining about the weird 1000*1024 units used by floppies (an artifact of turning 1440KiB into "1.44MB"), but that's how modern storage sizes are built too (except you report them as real power-of-ten rounded sizes in the end).
Powers of two are still heavily used as base units in the computing world. You can aim for a target near a power of 10, but very rarely do you see actual precise powers of ten in use. The common exception is clock rates and, by extension, bandwidth.
One typical place where users will see power-of-two sizes is in hard disk allocation size ("actual size on disk"). It's very evident for small files.
Meh, where I live (Spain), the left wing is in bed with the (equivalents of the) *AAs and it's in fact the right wing which is promising to abolish compulsive levies on digital storage media (HDDs, cellphones, flash drives, you name it) if they get elected.
These days I find that "left" vs. "right" means pretty much squat. Just vote for the least evil.
Dimmer switches buzz at 50/60Hz (with lots of metallic-sounding harmonics). Everyone hears those. Better designed ones make less noise. Battery chargers and power adapters in general (of any kind) either buzz at 50/60Hz (transformer based) or at a higher frequency (switching type). Poorly designed switching converters might operate in the audible range - I have a few that can definitely be heard. Most good ones are well above 20Khz. CRT TVs operate at ~15Khz; I hear those too. CRT monitors operate well above 20Khz; ~30Khz for 640x480 VGA (horizontal frequency). I doubt you can hear those. Maybe some specific monitor that produces noise at a division of the frequency?
I tried this on my laptop and I couldn't hear anything (other than some clicks when it is enabled/disabled, due to poor switching). The debug log says it's generating 22Khz pulses. It didn't work too well on my machine though.
Yup. A good strategy is to keep 2nd for most of the race, then overtake the leader on the last lap. Chances are decent he'll get blue shelled anyway and you'll have to do no extra work.
As an aside, it actually is possible to avoid a blue shell with carefully timed turbos or even mini-boosts: you can sneak out of the shell's trajectory right as it shoots for you, near the end of the cycle. However, it requires extremely precise timing and I've never been able to pull it off myself.
The ARM926EJ-S vectors can either be at 0x00000000 or 0xFFFF0000, depending on the VINITHI configuration line for the processor. Obviously, it's set in this particular hardware implementation. This can be switched at runtime, but the vectors actually stay there on the Wii always, since this is an area of address space only accessible to the Starlet (0x00000000 is actually the beginning of MEM1 and PowerPC territory).
boot0 is read straight from ROM. When you set the boot0-enable bit, boot0 overlays a part of what normally is Starlet SRAM. You can't write to it. This is pretty typical embedded system behavior (ROM overlays RAM during boot, gets disabled later on). If you later disable boot0, whatever was in the RAM it overlayed is retained, so it isn't getting loaded into RAM. Boot0 is disabled by the boot2 ELF loader (strangely enough - boot1 could easily do that task), which is how it was originally dumped (modified boot2). Later we found out that you can just reenable the thing whenever you want later on.
Keep in mind that the bus master stuff is already used all over the place: the PPC bus bridge is an AHB master, and so are most peripherals, since they need to be able to DMA data to RAM. While it is possible for there to be some kind of debug master, there's still the issue of how it would talk to the outside world. It would indeed be possible to have some sort of sequencer able to talk to the NAND registers and RAM (to write to NAND), but it still needs to talk somehow.
Indeed, Hollywood has multiple power rails (of course). We haven't tried sequencing them in odd ways, so it might be something to watch. Still, I have a hard time believing they latch onto the chip for programming - especially since they have tons of testpoints! There are no testpoints for the NAND pins. There's still the issue of the NAND output drivers being just drivers. If they're plain CMOS outputs in the silicon (which would be the obvious way to implement drivers like this, since there's no need for tristating), then they simply will not have a tristate mode: as soon as 3.3V is up, they will drive either high or low.
That's for Xbox1 (and now Win/Mac/Linux), not the 360. The Xbox1 does make a great media center, but although some HD capability is claimed, it's damn near useless for anything above 480p. There are also legal issues with XBMC on an Xbox1 running natively (the native/original port is compiled with the Xbox SDK and therefore distributing or having binaries is copyright infringement). Running Linux on an Xbox1 is also pretty tight because it only has 64MB of RAM. I upgraded mine to 128MB and managed to get the MythTV frontend working very well, though.
Neither boot1 nor boot0 have such capability (yes, they've been dumped - in fact, you can turn on boot0 easily using a register, it isn't locked out). The only possibility that I can see is that there might be an hidden "alternative" boot0 ROM with the ability to load code from some external bus, and this special boot0 ROM is turned on by some specific hardware event during startup. However, USB/SD/anything like that is out, since it's too complicated, and GCN peripherals are out since, although they can be talked to from Starlet, they require an initialization sequence to turn on (boot2 does this normally, not boot0). It might be able to load code bitbanged over the GPIO port though, or something of that nature. I don't think this possibility is very likely, though.
If there's actually a method to program the flash in-system assuming it contains no vlaid data to begin with (that means no boot1 either), I'd say it would have to be one of these:
JTAG port able to take over Starlet execution at boot
Some form of direct hardware access to the NAND controller via some form of special I/O sequence
Some ability to power down the NAND outputs and then clip onto the chip (I don't think this is likely)
An alternate hidden boot0 capable of running external code
I had a RAM stick (256MB DDR I think) with a stuck bit once. At first I just noticed a few odd kernel panics, but then I got a syntax error in a system Perl script. One letter had changed from lowercase to uppercase. That's when I ran memtest86 and found the culprit.
At the time, a "mark pages of memory bad" patch for the kernel did the trick and I happily used that borked stick for a year or so.
What ever happened to random / gibberish passwords? pwgen is a pretty good tool for this. We all know pubkey authentication is a lot better, but sometimes I'd rather log on from some other box without having to carry around my private key. Pubkey authentication works when you have to manage many boxes from one or two specific boxes.
Password authentication is as secure as, well, your password. Good passwords are pretty damn secure. 'aiBea1su' is pretty hard to guess. 'sexy99', not so much.
Who said anything about users? Of course, if you're running a system for other untrusted users, then you've got a whole host of other problems that you need to deal with. If you're running a server for yourself and a few friends though, using strong passwords for SSH (and not using them for other stuff too) is a perfectly valid solution. "Outward facing system" does not imply "public, multi-user server".
And seriously, if anyone out there is still doing HTTP/FTP/SMTP/POP3/IMAP with system auth passwords which also work for SSH, or has rsh or telnet enabled, or don't require SSL for SMTP/POP3/IMAP login, they deserve to be shot. All of those should be a given in this day and age.
"Incompatible version of some subsystem"? Are you talking about the message from the HackMii installer that tells you that you have "no vulnerable version of IOS"? If that's the case, then it's almost certain that you installed one of those "piracy packages" that wreak havok on your system software, effectively making none of the internal IOS versions trustworthy, breaking some compatibility, and generally making a huge mess of your Wii. Since the HackMii installer is an installer, and we like to play it safe (unlike most of the people responsible for warez tools), it refuses to work unless it knows exactly what kind of environment it's running on. This works for the vast majority of people, since it is quite flexible as to what IOS it picks to work with, but some of the ridiculous warez packs out there patch all versions of IOS, making them all untrustworthy, and therefore the installer refuses to work.
Of note, downgraders are also stupid and dangerous and can cause some similar problems (as well as brick your Wii). If you don't want to update, don't update in the first place. The HackMii Installer is supported on all system software versions currently, but if you want to regain some kind of lost functionality of the Nintendo software that came with an update, you're really on your own. The only semi-supported downgrade mechanism is to make a full NAND backup with BootMii before the upgrade and then restoring it, but doing that often is not recommended because it isn't resistant to newly developed bad NAND sectors.
Honestly, if 4.0 permanently broke homebrew for you, you must have definitely done something unsafe. Safe things include installing HBC/BootMii/DVDX with the HackMii installer and running any standalone homebrew software from SD or USB. Unsafe things include any kind of warez/"backup" loaders, any kind of system patches, downgrades, installing "cIOS", etc. Unfortunately the unsafe things are all too popular, especially on piracy-oriented forums.
I think there's a significant difference between a tool that lets you play games on their native console using possibly slightly more convenient methods while enabling all sorts of piracy, and a tool that imperfectly emulates an older console and lets you play games that you may or may not own. I also consider that people should have the right to emulate their old, store-bought games on a Wii without having to rebuy them as Virtual Console. Being able to play older games on a Wii is a significantly larger advantage than being able to play Wii games (that already work) from DVD-R or USB.
It's a line, you have to draw it somewhere. Wiibrew draws it there.
At Wiibrew we usually use the term Homebrew for homebrew software, excluding tools developed by and for pirates. I am well aware that those tools can and are used by people with legitimate backups, but that is a minority usage and associating homebrew with those tools gives homebrew a bad name. This is why such tools are not allowed on Wiibrew.
By referring to software stability I was referring to stability affecting system safety. Sure, lots of homebrew is buggy, but it's safe. Piracy utilities on the other hand do nasty stuff to your system all the time, they're buggy, and they brick lots of people's Wiis. I'm talking about safety-critical bugs here.
Nintendo has been known to ask for 210 EUR (that's over current retail price now!) to repair a Wii that they've determined had homebrew installed, even if it was in warranty. They can't really tell if the console is completely bricked, though, only if enough of the software is functional to let their rescue discs boot.
I would like to remind people that by using and supporting game loading tools, you're supporting people who routinely steal from the homebrew community, do not contribute back, and add banners to their tools in order to earn a profit. Waninkoko has repeatedly violated licenses and stolen code from others (first me, then bushing, then kwiirk with the USB stuff, as well as lots of other random bits and pieces) all while doing an insignificant amount of research and actual work himself, and he is sponsored by a website associated with modchip sales, has worked for modchip manufacturers, and adds advertisement banners to all of his tools. In fact, his first release of game-loading tools came about as a way to hit the modchip guys he worked for back because he felt they weren't paying him enough. One of his tools (a completely useless sort of survey he came up with, which he asked everyone to run) actually went as far as to open up the Opera browser on the Wii (if it was installed) to his sponsor's site.
Although there have been endless debates about the true effect of piracy on sales, they're all irrelevant. Reality doesn't mater, coporate opinion matters, and coporate opinion is (of course) that piracy harms sales, and that piracy must be eliminated. Blatantly associating homebrew with piracy is a great way to get targeted more often. We're not out to help Nintendo or hurt them, we just want to do our thing and we don't want to have anything to do with warez.
Nevermind that the people behind piracy tools are freeloading idiots who love to violate source licenses and produce tools of incredibly poor quality. I wouldn't touch their tools with a 10 foot pole, and I certainly don't want to be associated with them.
And again, I'm saying we've looked for JTAG all over the place and can't find it. The Wii has a gazillion test points, yet none of them seem like candidates for JTAG. There's a set of 8 cutely arranged testpoints going straight to Hollywood, but those turned out to be a debug GPIO port (I've used it to drive an LCD display and the like). Everything else is spread around the board, and we've gone and mapped almost all of the Hollywood ball-out with no success. About the only thing I'd imagine they could have pulled off to throw us off would be to spread the JTAG testpoints around the board using traces buried into the inner layers, but I doubt they're that smart.
Slashdot Mirror
PPP is still in wide use for modern residential internet connections (ADSL uses PPPoEoA or PPPoA quite often, for example). Even 3G modems and the like emulate it to the PC side, unless they're the more recent kind with dedicated usb-ethernet-type protocols.
One wonders why no one thought to add that to the manpage.
The bug is that ldd is trying to do the impossible: list dynamic dependencies for executables that it doesn't understand (more precisely: executables that don't use glibc and/or the standard linking mechanisms). The catch is that glibc's implementation offloads this task onto the dynamic linker, and whoever wrote ldd thought the rest of the world would be nice and follow ld-linux's environment variable convention with their dynamic loaders. And, of course, this completely violates the assumption that ldd treats its argument as data, and will not run code from it.
What ldd needs to do is realize that trying to be generic is futile, and either a) check for ld-linux and bail if otherwise, or b) become a real C app (using libbfd?) that can inspect the executable as data, which might gain it compatibility with other loaders if they follow the same ELF ABI for dependency specification. And under no circumstances actually call out to any untrusted code or libraries to do this.
These days the quality of memory is crap though. Just look at NAND flash: there are hundreds of failed blocks on most chips, and these days sectors with a bad bit or two are used and just error corrected. Same with hard disks. You work around this by shoving large amounts of error detection, correction, and relocation logic into the controller.
Let's say each individual bit (!) can be manufactured reliably 99.99% of the time. For a 2048-byte sector (typical for NAND flash), using sector-granularity remapping, there's a ~20% chance of a sector being good. That's not very good, but it still gives you 19% usable capacity. At a terabyte per chip, that's still 190GB of storage. If you add single-bit error correction, you'd get 500GB of storage. At 2-bit correction, 750GB. Current generation Flash memory already uses multiple-bit ECC for MLC level flash memory (where typically 2 bits will fail at once), and sectors with one bad bit(pair) are considered "good enough" and corrected away. If you can manufacture this 1TB storage chip at 99.99% per bit, and especially if most of the failures will happen at manufacture time and not develop later during use, I'll gladly take it given a reasonable amount of error correction wrapping it. It's not like we don't already rely on ECC for our day-to-day storage.
Yield issues affect mainly things like CPUs with no redundancy. With memory, you just lose the damaged parts. Even RAM these days is manufactured with spare blocks that can replace blocks that came out wrong, to increase yield (though it's usually only a few and the remapping is burned in at the factory).
RAM and solid state Flash memory, which is becoming increasingly popular. NOR flash comes in power-of-two sizes, and NAND flash comes in power-of-two main data areas plus some power-of-two over power-of-two fraction in out-of-band area (64 OOB bytes per 2048 data bytes is common). However, Flash wear-leveling by controllers reduces available size, and sometimes they are designed so it works out at closer to a power-of-ten size, but that's just a random target (and they never actually nail it). It's also worth noting that storage block sizes are powers of two (512 byte sectors for HDDs, 2048 bytes for DVDs, and in reality both formats tend to use larger physical sectors of a power-of-two size too). So, in reality, there is no such thing as a purely decimal round size hard disk: it's all crazy mixed multiples that round off to somewhere close to a decimal unit yet still a multiple of a smaller binary unit. People keep complaining about the weird 1000*1024 units used by floppies (an artifact of turning 1440KiB into "1.44MB"), but that's how modern storage sizes are built too (except you report them as real power-of-ten rounded sizes in the end).
Powers of two are still heavily used as base units in the computing world. You can aim for a target near a power of 10, but very rarely do you see actual precise powers of ten in use. The common exception is clock rates and, by extension, bandwidth.
One typical place where users will see power-of-two sizes is in hard disk allocation size ("actual size on disk"). It's very evident for small files.
Meh, where I live (Spain), the left wing is in bed with the (equivalents of the) *AAs and it's in fact the right wing which is promising to abolish compulsive levies on digital storage media (HDDs, cellphones, flash drives, you name it) if they get elected.
These days I find that "left" vs. "right" means pretty much squat. Just vote for the least evil.
Dimmer switches buzz at 50/60Hz (with lots of metallic-sounding harmonics). Everyone hears those. Better designed ones make less noise. Battery chargers and power adapters in general (of any kind) either buzz at 50/60Hz (transformer based) or at a higher frequency (switching type). Poorly designed switching converters might operate in the audible range - I have a few that can definitely be heard. Most good ones are well above 20Khz. CRT TVs operate at ~15Khz; I hear those too. CRT monitors operate well above 20Khz; ~30Khz for 640x480 VGA (horizontal frequency). I doubt you can hear those. Maybe some specific monitor that produces noise at a division of the frequency?
I tried this on my laptop and I couldn't hear anything (other than some clicks when it is enabled/disabled, due to poor switching). The debug log says it's generating 22Khz pulses. It didn't work too well on my machine though.
Pretty close.
Yup. A good strategy is to keep 2nd for most of the race, then overtake the leader on the last lap. Chances are decent he'll get blue shelled anyway and you'll have to do no extra work.
As an aside, it actually is possible to avoid a blue shell with carefully timed turbos or even mini-boosts: you can sneak out of the shell's trajectory right as it shoots for you, near the end of the cycle. However, it requires extremely precise timing and I've never been able to pull it off myself.
The ARM926EJ-S vectors can either be at 0x00000000 or 0xFFFF0000, depending on the VINITHI configuration line for the processor. Obviously, it's set in this particular hardware implementation. This can be switched at runtime, but the vectors actually stay there on the Wii always, since this is an area of address space only accessible to the Starlet (0x00000000 is actually the beginning of MEM1 and PowerPC territory).
boot0 is read straight from ROM. When you set the boot0-enable bit, boot0 overlays a part of what normally is Starlet SRAM. You can't write to it. This is pretty typical embedded system behavior (ROM overlays RAM during boot, gets disabled later on). If you later disable boot0, whatever was in the RAM it overlayed is retained, so it isn't getting loaded into RAM. Boot0 is disabled by the boot2 ELF loader (strangely enough - boot1 could easily do that task), which is how it was originally dumped (modified boot2). Later we found out that you can just reenable the thing whenever you want later on.
Keep in mind that the bus master stuff is already used all over the place: the PPC bus bridge is an AHB master, and so are most peripherals, since they need to be able to DMA data to RAM. While it is possible for there to be some kind of debug master, there's still the issue of how it would talk to the outside world. It would indeed be possible to have some sort of sequencer able to talk to the NAND registers and RAM (to write to NAND), but it still needs to talk somehow.
Indeed, Hollywood has multiple power rails (of course). We haven't tried sequencing them in odd ways, so it might be something to watch. Still, I have a hard time believing they latch onto the chip for programming - especially since they have tons of testpoints! There are no testpoints for the NAND pins. There's still the issue of the NAND output drivers being just drivers. If they're plain CMOS outputs in the silicon (which would be the obvious way to implement drivers like this, since there's no need for tristating), then they simply will not have a tristate mode: as soon as 3.3V is up, they will drive either high or low.
That's for Xbox1 (and now Win/Mac/Linux), not the 360. The Xbox1 does make a great media center, but although some HD capability is claimed, it's damn near useless for anything above 480p. There are also legal issues with XBMC on an Xbox1 running natively (the native/original port is compiled with the Xbox SDK and therefore distributing or having binaries is copyright infringement). Running Linux on an Xbox1 is also pretty tight because it only has 64MB of RAM. I upgraded mine to 128MB and managed to get the MythTV frontend working very well, though.
Neither boot1 nor boot0 have such capability (yes, they've been dumped - in fact, you can turn on boot0 easily using a register, it isn't locked out). The only possibility that I can see is that there might be an hidden "alternative" boot0 ROM with the ability to load code from some external bus, and this special boot0 ROM is turned on by some specific hardware event during startup. However, USB/SD/anything like that is out, since it's too complicated, and GCN peripherals are out since, although they can be talked to from Starlet, they require an initialization sequence to turn on (boot2 does this normally, not boot0). It might be able to load code bitbanged over the GPIO port though, or something of that nature. I don't think this possibility is very likely, though.
If there's actually a method to program the flash in-system assuming it contains no vlaid data to begin with (that means no boot1 either), I'd say it would have to be one of these:
I had a RAM stick (256MB DDR I think) with a stuck bit once. At first I just noticed a few odd kernel panics, but then I got a syntax error in a system Perl script. One letter had changed from lowercase to uppercase. That's when I ran memtest86 and found the culprit.
At the time, a "mark pages of memory bad" patch for the kernel did the trick and I happily used that borked stick for a year or so.
What ever happened to random / gibberish passwords? pwgen is a pretty good tool for this. We all know pubkey authentication is a lot better, but sometimes I'd rather log on from some other box without having to carry around my private key. Pubkey authentication works when you have to manage many boxes from one or two specific boxes.
Password authentication is as secure as, well, your password. Good passwords are pretty damn secure. 'aiBea1su' is pretty hard to guess. 'sexy99', not so much.
Who said anything about users? Of course, if you're running a system for other untrusted users, then you've got a whole host of other problems that you need to deal with. If you're running a server for yourself and a few friends though, using strong passwords for SSH (and not using them for other stuff too) is a perfectly valid solution. "Outward facing system" does not imply "public, multi-user server".
And seriously, if anyone out there is still doing HTTP/FTP/SMTP/POP3/IMAP with system auth passwords which also work for SSH, or has rsh or telnet enabled, or don't require SSL for SMTP/POP3/IMAP login, they deserve to be shot. All of those should be a given in this day and age.
Or you could just not use weak passwords.
"Incompatible version of some subsystem"? Are you talking about the message from the HackMii installer that tells you that you have "no vulnerable version of IOS"? If that's the case, then it's almost certain that you installed one of those "piracy packages" that wreak havok on your system software, effectively making none of the internal IOS versions trustworthy, breaking some compatibility, and generally making a huge mess of your Wii. Since the HackMii installer is an installer, and we like to play it safe (unlike most of the people responsible for warez tools), it refuses to work unless it knows exactly what kind of environment it's running on. This works for the vast majority of people, since it is quite flexible as to what IOS it picks to work with, but some of the ridiculous warez packs out there patch all versions of IOS, making them all untrustworthy, and therefore the installer refuses to work.
Of note, downgraders are also stupid and dangerous and can cause some similar problems (as well as brick your Wii). If you don't want to update, don't update in the first place. The HackMii Installer is supported on all system software versions currently, but if you want to regain some kind of lost functionality of the Nintendo software that came with an update, you're really on your own. The only semi-supported downgrade mechanism is to make a full NAND backup with BootMii before the upgrade and then restoring it, but doing that often is not recommended because it isn't resistant to newly developed bad NAND sectors.
Honestly, if 4.0 permanently broke homebrew for you, you must have definitely done something unsafe. Safe things include installing HBC/BootMii/DVDX with the HackMii installer and running any standalone homebrew software from SD or USB. Unsafe things include any kind of warez/"backup" loaders, any kind of system patches, downgrades, installing "cIOS", etc. Unfortunately the unsafe things are all too popular, especially on piracy-oriented forums.
I think there's a significant difference between a tool that lets you play games on their native console using possibly slightly more convenient methods while enabling all sorts of piracy, and a tool that imperfectly emulates an older console and lets you play games that you may or may not own. I also consider that people should have the right to emulate their old, store-bought games on a Wii without having to rebuy them as Virtual Console. Being able to play older games on a Wii is a significantly larger advantage than being able to play Wii games (that already work) from DVD-R or USB.
It's a line, you have to draw it somewhere. Wiibrew draws it there.
At Wiibrew we usually use the term Homebrew for homebrew software, excluding tools developed by and for pirates. I am well aware that those tools can and are used by people with legitimate backups, but that is a minority usage and associating homebrew with those tools gives homebrew a bad name. This is why such tools are not allowed on Wiibrew.
By referring to software stability I was referring to stability affecting system safety. Sure, lots of homebrew is buggy, but it's safe. Piracy utilities on the other hand do nasty stuff to your system all the time, they're buggy, and they brick lots of people's Wiis. I'm talking about safety-critical bugs here.
Nintendo has been known to ask for 210 EUR (that's over current retail price now!) to repair a Wii that they've determined had homebrew installed, even if it was in warranty. They can't really tell if the console is completely bricked, though, only if enough of the software is functional to let their rescue discs boot.
I would like to remind people that by using and supporting game loading tools, you're supporting people who routinely steal from the homebrew community, do not contribute back, and add banners to their tools in order to earn a profit. Waninkoko has repeatedly violated licenses and stolen code from others (first me, then bushing, then kwiirk with the USB stuff, as well as lots of other random bits and pieces) all while doing an insignificant amount of research and actual work himself, and he is sponsored by a website associated with modchip sales, has worked for modchip manufacturers, and adds advertisement banners to all of his tools. In fact, his first release of game-loading tools came about as a way to hit the modchip guys he worked for back because he felt they weren't paying him enough. One of his tools (a completely useless sort of survey he came up with, which he asked everyone to run) actually went as far as to open up the Opera browser on the Wii (if it was installed) to his sponsor's site.
Although there have been endless debates about the true effect of piracy on sales, they're all irrelevant. Reality doesn't mater, coporate opinion matters, and coporate opinion is (of course) that piracy harms sales, and that piracy must be eliminated. Blatantly associating homebrew with piracy is a great way to get targeted more often. We're not out to help Nintendo or hurt them, we just want to do our thing and we don't want to have anything to do with warez.
Nevermind that the people behind piracy tools are freeloading idiots who love to violate source licenses and produce tools of incredibly poor quality. I wouldn't touch their tools with a 10 foot pole, and I certainly don't want to be associated with them.
And again, I'm saying we've looked for JTAG all over the place and can't find it. The Wii has a gazillion test points, yet none of them seem like candidates for JTAG. There's a set of 8 cutely arranged testpoints going straight to Hollywood, but those turned out to be a debug GPIO port (I've used it to drive an LCD display and the like). Everything else is spread around the board, and we've gone and mapped almost all of the Hollywood ball-out with no success. About the only thing I'd imagine they could have pulled off to throw us off would be to spread the JTAG testpoints around the board using traces buried into the inner layers, but I doubt they're that smart.
Good luck breaking the massive ground planes that connect every ground together.