I have gotten practically inaudible latencies from jack. The critical detail is to make it output directly to the ALSA hardware device (hw:0, usually). Having it go through dmix (which tends to be the default ALSA output device) kills your latency because it has to go through the mixing buffer.
Half the time it's the chipset manufacturer's fault, too. For example, Realtek pretends to support Linux and even has public datasheets (to some extent), but some of their chips only half-work or don't work at all if you stick to the published specifications. Turns out you need to perform some magical undocumented actions to get them to behave correctly. Don't bother asking their "linux guy" (he's even listed at the top of the driver in the Linux kernel), he'll just waste your time.
I had an issue with their ALC889 chipset, which I described to him in technical detail (such and such portions of the chip don't work, even when there's no way this could happen going by the spec, which I can prove because I've tested this and this). He wasted two weeks of my time throwing random revisions of the driver.c file at me that just added pin-configuration support for other motherboards and laptops (none of which were my laptop, and which is totally irrelevant to the issue as I described it, as I know how to test and determine the platform-specific pinouts and had already nailed mine). Eventually I gave up and manually brute-forced every single bit of their proprietary registers until I came up with the magic ones to make the chip behave.
Problems getting *any* sound to come out are quite often the result of proprietary platforms and chipsets with poor support. Software issues with mixing and incompatibilities with applications are an entirely different issue - those can indeed be attributed to the rather crazy state of linux audio.
Oh, chinese-designed devices. The really scary part about those is the charging electronics, if they even deserve to be called "electronics". Last one I tore apart had a diode and a resistor as the "charging circuit". For a li-ion battery. For the non-initiated: li-ion batteries require a smart charger for any kind of safe, reliable charging.
The only reason that thing didn't blow up on every charge was because of the protection chip built into the battery. They were relying on it consistently tripping on every charge to avoid disaster.
The Wiki pages were about getting ANY music to play at all on a device without using iTunes. They had nothing to do with DRM; it's a separate crypto hash that Apple added to their iTunesDB files for the sole purpose of locking out third party syncing apps. Apple's FairPlay claims stem from the fact that the latest versions are obfuscated using the same obfuscator used for FairPlay and there may or may not be some code shared between the DRM scheme and the hashing scheme.
I think it remains to be seen just how common this sort of optimization is. I'd say it's worth a shot - if there turn out to be hundreds of warnings then oh, well. I'm not sure how smart GCC's optimizer is, but maybe it can be tuned to at least restrict the warning to cases where there's a NULL check after a dereference of the same variable it's NOT wrapped in another NULL check (so the code path through that function, at least to within GCC's optimizer's limits, can indeed apparently hit the dereference if the pointer is NULL).
Sure it does - GCC knows at compile time that if the if() condition were true, we're already in the "undefined behavior" realm and all bets are off. So it gets rid of it. The code is broken: it's not the compiler's job to compile for the maximum defensiveness of the resulting machine code, otherwise we'd all be using bounds-checking compilers. If the compiler realizes that a certain runtime value will lead to undefined results (because the programmer chose to do so), it is free to break the execution as much as it wants in that case for code that runs afterwards. Essentially, undefined behavior is a contract signed by the programmer that says "I certify that this will never happen", which is why the compiler chose to perform this optimization.
Even though the real bug is clearly in the code, moving on to the realm of what's desirable from a compiler, I think it's clear that this behavior can make some problems worse (to the compiler, problems are binary - if there's a problem all bets are off - but not to us). This is fine in the name of optimization, but I think in this particular instance either a) kernel developers should opt to turn this optimization off, or b) (better) make GCC warn when this kind of optimization happens, because it's quite likely a bug.
In effect, the code is a form of broken defensive programming (you check after the fact whether you've screwed up). It's wrong, but we still wouldn't want the compiler to silently remove the check. So I think the ideal solution (besides fixing the code) is to add a warning to the compiler. NULL pointer dereferences are a bug in the vast majority of cases, and checking for a NULL pointer after dereferencing it (in such a way that the compiler recognizes it and is about to remove the check) is at best redundant and more likely a bug.
There's still the issue of the page 0 fuckery. If someone can make page 0 accesses not crash the kernel then that's also a bug - there are good reason why we want NULL and neal-NULL pointer accesses to always crash.
The GTK file picker is quite possibly the worst file picker I have ever seen. Even Windows 3.1's crappy stuff was better - it might not support long filenames, but at least it didn't require one extra click in order to do anything useful.
Seriously, "browse for other folders"? I still maintain that the genius who thought that up needs to be shot.
I get that in Spain, but that's okay, since you can change the Google preferences to English easily enough.
However, what I don't get is the non-advertised, hidden, mandatory biasing of search results based on the Google UI language. Results vary depending on what language is picked for the Google UI (and no, this isn't the "show only results in such and such language" feature, as it still shows results in multiple languages - it's just biased in preference of the UI language). Why isn't there a checkbox to turn it off, and why is it hardcoded to use the UI language? Very often, if I'm using Google in spanish I find that the most relevant results for obvious queries (say, some well-known open source software) are in 4th or worse place, and the first few spots are occupied by some random sites about it that happen to be in Spanish. I get the idea and why some people might like it, but I don't see why they will not explain it or offer an option to turn it off.
Sure, all-8.3 filesystems will work, but the following two will break: SFN implementations that need to support people who use long file names (e.g. a whole bunch of chinese MP3s that don't do LFNs), and any LFN FAT implementation that chokes on the invalid SFN.
There's also the annoyance of case preservation loss on SFNs. And I hope they've correctly handled the case of invalid SFN characters appearing on a name that otherwise fits into the 8.3 scheme (in this case it should switch to LFN mode and generate an invalid SFN).
There are hundreds of FAT implementations out there and most of them are incorrect in several ways. Throwing bogus SFN data on the filesystem doesn't help make them play smoothly with Linux. After all, it's breaking the (de facto, at least) standard that the SFN should be valid and unique when there's an LFN. Linux will be blamed for the ensuing breakage, so popular distributions won't adopt this option (I hope it's a non-default kernel or mount-time option).
This will break the myriad of read-only implementations out there that only use short names, which is a lot more than you'd think. This means this can't be enabled by default on your average Linux.
It might help TomTom and the like, but it's not a cure for the patented portions of FAT. It's just a hack that might help some specific implementors. Kudos to the kernel developers for doing their best, but the real solution is to get the bogus patents invalidated.
Pointers? Yes. Integers? Not a chance. Under Windows, only pointers are 64-bits under the P64 model The integer types don't change, and long and int are still 32 bis
Linux uses LP64 which makes longs 64-bit, but not ints.
I don't know about you but I don't particularly enjoy it when scammers earn a pretty penny by selling software that I've helped write and there is just about nothing I can do about it. Worse, piracy utilities which themselves mostly consist of abused homebrew code and often don't follow licenses themselves are even used by them to better get away with selling the software.
It's not just the scammers - that's just part of it. At some point all the negative factors - scammers, people abusing any and every homebrew development for piracy, invasion of homebrew sites by people only interested in warez, the rants and drama, etc - just ended up outweighing any interest I had in developing.
I came up with a way of tying the install to a particular console, so the latest version won't work with their new channel-rip scheme. But these cycles last a long time and somehow they always come up with some kind of work around. I highly doubt they'll be able to bypass this latest trick (the scammers themselves have no development or reverse engineering skill whatsoever, so it won't happen unless someone helps them), but there are better chances that someone will figure out a way to make things work on newer consoles without using our installer, and then the scammers will just use that to install older versions of HBC.
Last time they were supposed to be forced to use our installer since the older versions wouldn't install on newer consoles. But unfortunately another developer had come up with a rather dodgy exploit and released it for a different purpose, thinking they'd never think about abusing it for other means. Guess what happened. We've all gone through that phase, "how could this possibly be abused; none of this is ever going to happen to me". Even after that, the same guy came up with a very clever way of getting code to run using an exploit in SD channel banners. I told him to include a scam warning screen, so he added some text which is displayed using the standard System Menu dialog box thing. I told him no one would read that since it wasn't forced to display for a set time and it just looked like yet another lame confirmation dialog. He figured it was okay. Now the scammers are happily bundling his exploit which explicitly warns you about being scammed, and none of their moronic customers read it because, of course, they all just go straight for the "OK" button. It's bad: you need to have in-your-face warning screens, scary looking text on a black background, forced 20-second read times, and use an unconventional "OK" button on the controller. Otherwise the scammers sell it and most of their customers don't even notice.
There are all kinds of unscrupulous people who will happily take other people's work and pass it as their own. For example, there's an entire bunch of websites devoted to bundling free Wii homebrew utilities with warez-loading apps and a torrent client and selling it as the ultimate Wii softmod get-all-your-games-for-free package. Examples: homebreware.com, playbreware.com, homebrewinstaller.com, mywiidownloads.com... the list goes on. They have sales numbers that are a sizable chunk of total homebrew users and mainly cater to the clueless, earning large amounts of cash for basically nothing.
Our "core" software (specifically, the Twilight Hack, Homebrew Channel, DVDX, BootMii, HackMii Installer, etc) is mostly distributed under a closed-source restrictive "download it from our site and use it, don't redistribute it" license precisely due to these kinds of websites. For example, ordinarily we wouldn't care at all about people mirroring these apps, but one of the favorite excuses from the aforementioned scamsites is that "they're just linking to some third-party mirror". the I've tried to get some of them taken down but it's damn near impossible and their payment processors (Plimus and ClickBank typically) move very slowly and do nothing at all (which is not surprising; after all, they get a cut of the profits). These sites tend to work on affiliate programs and therefore there are dozens of "affiliates" happily buying Google Ads and setting up spam blogs just to promote the scams.
What's even worse is that the warez utilities work backwards too - they let the scammers "pirate" our freeware and sell it for money. For example, our installer includes a large full-screen "if you paid for this you were scammed" warning, but the scammers have now used tools for Wii Channel piracy to distribute the Homebrew Channel without the installer, bypassing that screen. Every time this happens they get a nice 3-6 months until Nintendo puts out another update that would force them to use updated hacks and tools.
This is one of the reasons why I gave up on Wii development. And I don't have plans to touch any console or system where piracy might become a big incentive to run homebrew. Piracy brings in hordes of clueless idiots who just want free games, generally poisons the homebrew community, divides it due to the differing opinions on it, and also comes with dollar-eyed scammers who want to make a quick buck of it all.
It's pretty obvious. The people looking at app store submissions likely have only a very basic understanding of the issues involved, and the SDK agreement isn't very precise as to what falls and doesn't fall under this rule. So the results basically depend on the guy's gut feeling when he checks out the app. For example, I'm pretty sure the vast majority of them would consider a SID player a simple music player, even though it actually runs C64 machine code, just as they would probably accept a game with downloadable levels which include some form of built-in scripting as OK, as long as that part isn't explicitly pointed out somewhere.
No part of this is surprising. It's a crappy technical rule, and crappy technical rules don't work well when more than one person is supposed to enforce them.
Any sane upstream provider should be able to add a block for you on their end if someone (say, china) is flooding your connection with packets beyond capacity.
Warezed games can be run from DVD-Rs and USB drives. Sure, you run the loader from an SD card, but that's a few kilobytes. My point is that the only way to run Wii warez without a modchip is via loaders installed using/via homebrew, and the most popular way of launching homebrew to date is the Twilight Hack. Every single person out there who pirates Wii games without a modchip (a number much larger than the people purely using homebrew for legal purposes) has used either the Twilight Hack or Bannerbomb.
The Twilight Hack is an entry vector - a way of loading your own code on the system to begin with. You need one of those to run the tools necessary to set up, install, and run copied games. Therefore, and taking into account that many more people using homebrew applications to run warez than not, and that the Twilight Hack is one of two available ones at this time and clearly the all-time most popular one to date (since the newer one, bannerbomb, is very recent), most users of the Twilight Hack have used it with the ultimate goal of running warezed games.
None of those tools is useful in and of itself; they all enable other things to run or work. Twilight Hack is an exploit, PatchMii is a system patcher, DVDX is a DVD-Video mode enable hack that doesn't require patching. But even so:
Since most users of "homebrew-enabled" Wiis are using it to pirate games, and the Twilight Hack is the most popular game exploit entry point and, until recently, the only one, most of its users are certainly using it with the end goal of piracy in mind.
PatchMii was some code developed to download an IOS from nintendo's update servers, patch it on the fly, and install it (enabling legal IOS patching). Its original use is also practically obsolete - originally it was released as a platform to experiment with IOS patches, and then it was used to enable DVD-Video mode on users with modchips (ironically, good modchips tend to actually break the use of DVDs for homebrew because they make them appear as game discs, which are subject to heavier restrictions). This restriction is now circumvented and PatchMii is no longer necessary (or supported for current DVDX versions). The only real improvement to homebrew from patched IOSes is the USB 2.0 driver, which, guess what, was actually developed for piracy, and is also obsolete or should become such for homebrew, since MINI (a true homebrew replacement for IOS which enables a truly 100% nintendo-free environment) plus Linux yields ridiculously higher performance than the crappy IOS-based USB EHCI driver (the latter doesn't even use IRQs). Given that PatchMii serves a limited purpose for homebrew these days, and that it is, on the other hand, the base for all of the warez-enabled modified IOS installers, we can also certainly say that most of the users of the PatchMii codebase are also using it with the end goal of piracy in mind.
Finally, even though DVDX serves a very specific purpose (trick IOS into turning on DVD mode for the user without having to patch it, so homebrew can read from DVDVideo or DVDR discs for data), and even though it's quite simple code, and even though warez loaders need to patch IOS anyway (since pure DVD mode isn't compatible with games), the very first DVD warez loader (which, by the way, sucked very badly) used it because the developer was too incompetent to figure out what bit to flip inside the IOS that he was already patching. So even DVDX, a tool that couldn't possibly be useful for piracy, indeed was used for that, although we can't speak of a majority of users here (the guy eventually figured out what he had to patch and it is no longer required).
We can't have nice things - anything and everything that homebrew developers make will be abused by much larger numbers of warez users. I say this as a former developer of all three of the tools mentioned. It's rather depressing that, say, the software installation interface that I reverse engineered and then added support for in libogc (originally used to install The Homebrew Channel, DVDX, etc) is now mostly used to install warez-patched IOSes and VC/WiIWare warez, and that even the libogc library that I developed it for turned out to contain a large steaming pile of code copied straight from the Nintendo SDK.
Glossary for those not familiar with Wii homebrew stuff: IOS - an OS that runs on the Wii's "Starlet" ARM sub-CPU that contains security features and drivers for most wii-exclusive functionality that wasn't present in the GameCube. Unrelated to Cisco IOS. Twilight Hack - exploit in Zelda: Twilight Princess that lets you run a homebrew executable. Recently open-sourced. PatchMii - downloads and patches an IOS from Nintendo's servers and installs it, all on the fly and automatically. Originally released as an open-source platform for IOS experimentation. DVDX - a trick using a hidden channel and some context save code. Basically it has a flag set that makes the Wii consider it the "DVD Player Channel", for which support officially exists and for which there's a special DVD drive mode, even tho
As a prior Wii homebrew developer, I have absolutely no doubt that 99% of its users are just doing it to run crappy piracy tools. It's one of the reasons why I gave up on console homebrew and Wii homebrew in particular.
Then there's the thing where the main Wii homebrew library largely consists of code ripped straight out of the Nintendo SDK (most of the drivers and frameworks have the same API with the same code, just manually translated line by line from assembler to C - the only decent documentation for the "homebrew" graphics API is the SDK documentation itself). Nobody knew at first, since the guy responsible conveniently forgot to tell anyone. Now everyone just pretends the problem doesn't exist. No one dares to work on an alternative - even people who otherwise hate the library due to its failures. So in the end just about every homebrew binary for the Wii is a big SDK copyright violation. Kind of like the Xbox 1 situation where everyone used the SDK, except people there knew it was illegal and distributed the binaries underground, whereas here everyone just plugs their ears when the libogc issue is mentioned.
And people wonder why console homebrew has so much trouble attracting sane good developers.
Slashdot Mirror
I have gotten practically inaudible latencies from jack. The critical detail is to make it output directly to the ALSA hardware device (hw:0, usually). Having it go through dmix (which tends to be the default ALSA output device) kills your latency because it has to go through the mixing buffer.
I blogged about it and submitted the patches to the ALSA tree. It should hit mainline eventually (I'm not sure how often they sync up with ALSA).
Half the time it's the chipset manufacturer's fault, too. For example, Realtek pretends to support Linux and even has public datasheets (to some extent), but some of their chips only half-work or don't work at all if you stick to the published specifications. Turns out you need to perform some magical undocumented actions to get them to behave correctly. Don't bother asking their "linux guy" (he's even listed at the top of the driver in the Linux kernel), he'll just waste your time.
I had an issue with their ALC889 chipset, which I described to him in technical detail (such and such portions of the chip don't work, even when there's no way this could happen going by the spec, which I can prove because I've tested this and this). He wasted two weeks of my time throwing random revisions of the driver .c file at me that just added pin-configuration support for other motherboards and laptops (none of which were my laptop, and which is totally irrelevant to the issue as I described it, as I know how to test and determine the platform-specific pinouts and had already nailed mine). Eventually I gave up and manually brute-forced every single bit of their proprietary registers until I came up with the magic ones to make the chip behave.
Problems getting *any* sound to come out are quite often the result of proprietary platforms and chipsets with poor support. Software issues with mixing and incompatibilities with applications are an entirely different issue - those can indeed be attributed to the rather crazy state of linux audio.
Last I checked the date and time are anything but random.
ISO 216 A4 is 210x297 mm, not 210x279 mm. DIN called, they want their 18mm back.
Oh, chinese-designed devices. The really scary part about those is the charging electronics, if they even deserve to be called "electronics". Last one I tore apart had a diode and a resistor as the "charging circuit". For a li-ion battery. For the non-initiated: li-ion batteries require a smart charger for any kind of safe, reliable charging.
The only reason that thing didn't blow up on every charge was because of the protection chip built into the battery. They were relying on it consistently tripping on every charge to avoid disaster.
The Wiki pages were about getting ANY music to play at all on a device without using iTunes. They had nothing to do with DRM; it's a separate crypto hash that Apple added to their iTunesDB files for the sole purpose of locking out third party syncing apps. Apple's FairPlay claims stem from the fact that the latest versions are obfuscated using the same obfuscator used for FairPlay and there may or may not be some code shared between the DRM scheme and the hashing scheme.
I think it remains to be seen just how common this sort of optimization is. I'd say it's worth a shot - if there turn out to be hundreds of warnings then oh, well. I'm not sure how smart GCC's optimizer is, but maybe it can be tuned to at least restrict the warning to cases where there's a NULL check after a dereference of the same variable it's NOT wrapped in another NULL check (so the code path through that function, at least to within GCC's optimizer's limits, can indeed apparently hit the dereference if the pointer is NULL).
Sure it does - GCC knows at compile time that if the if() condition were true, we're already in the "undefined behavior" realm and all bets are off. So it gets rid of it. The code is broken: it's not the compiler's job to compile for the maximum defensiveness of the resulting machine code, otherwise we'd all be using bounds-checking compilers. If the compiler realizes that a certain runtime value will lead to undefined results (because the programmer chose to do so), it is free to break the execution as much as it wants in that case for code that runs afterwards. Essentially, undefined behavior is a contract signed by the programmer that says "I certify that this will never happen", which is why the compiler chose to perform this optimization.
Even though the real bug is clearly in the code, moving on to the realm of what's desirable from a compiler, I think it's clear that this behavior can make some problems worse (to the compiler, problems are binary - if there's a problem all bets are off - but not to us). This is fine in the name of optimization, but I think in this particular instance either a) kernel developers should opt to turn this optimization off, or b) (better) make GCC warn when this kind of optimization happens, because it's quite likely a bug.
In effect, the code is a form of broken defensive programming (you check after the fact whether you've screwed up). It's wrong, but we still wouldn't want the compiler to silently remove the check. So I think the ideal solution (besides fixing the code) is to add a warning to the compiler. NULL pointer dereferences are a bug in the vast majority of cases, and checking for a NULL pointer after dereferencing it (in such a way that the compiler recognizes it and is about to remove the check) is at best redundant and more likely a bug.
There's still the issue of the page 0 fuckery. If someone can make page 0 accesses not crash the kernel then that's also a bug - there are good reason why we want NULL and neal-NULL pointer accesses to always crash.
The GTK file picker is quite possibly the worst file picker I have ever seen. Even Windows 3.1's crappy stuff was better - it might not support long filenames, but at least it didn't require one extra click in order to do anything useful.
Seriously, "browse for other folders"? I still maintain that the genius who thought that up needs to be shot.
I get that in Spain, but that's okay, since you can change the Google preferences to English easily enough.
However, what I don't get is the non-advertised, hidden, mandatory biasing of search results based on the Google UI language. Results vary depending on what language is picked for the Google UI (and no, this isn't the "show only results in such and such language" feature, as it still shows results in multiple languages - it's just biased in preference of the UI language). Why isn't there a checkbox to turn it off, and why is it hardcoded to use the UI language? Very often, if I'm using Google in spanish I find that the most relevant results for obvious queries (say, some well-known open source software) are in 4th or worse place, and the first few spots are occupied by some random sites about it that happen to be in Spanish. I get the idea and why some people might like it, but I don't see why they will not explain it or offer an option to turn it off.
Sure, all-8.3 filesystems will work, but the following two will break: SFN implementations that need to support people who use long file names (e.g. a whole bunch of chinese MP3s that don't do LFNs), and any LFN FAT implementation that chokes on the invalid SFN.
There's also the annoyance of case preservation loss on SFNs. And I hope they've correctly handled the case of invalid SFN characters appearing on a name that otherwise fits into the 8.3 scheme (in this case it should switch to LFN mode and generate an invalid SFN).
There are hundreds of FAT implementations out there and most of them are incorrect in several ways. Throwing bogus SFN data on the filesystem doesn't help make them play smoothly with Linux. After all, it's breaking the (de facto, at least) standard that the SFN should be valid and unique when there's an LFN. Linux will be blamed for the ensuing breakage, so popular distributions won't adopt this option (I hope it's a non-default kernel or mount-time option).
This will break the myriad of read-only implementations out there that only use short names, which is a lot more than you'd think. This means this can't be enabled by default on your average Linux.
It might help TomTom and the like, but it's not a cure for the patented portions of FAT. It's just a hack that might help some specific implementors. Kudos to the kernel developers for doing their best, but the real solution is to get the bogus patents invalidated.
Pointers? Yes. Integers? Not a chance. Under Windows, only pointers are 64-bits under the P64 model The integer types don't change, and long and int are still 32 bis
Linux uses LP64 which makes longs 64-bit, but not ints.
I don't know about you but I don't particularly enjoy it when scammers earn a pretty penny by selling software that I've helped write and there is just about nothing I can do about it. Worse, piracy utilities which themselves mostly consist of abused homebrew code and often don't follow licenses themselves are even used by them to better get away with selling the software.
It's not just the scammers - that's just part of it. At some point all the negative factors - scammers, people abusing any and every homebrew development for piracy, invasion of homebrew sites by people only interested in warez, the rants and drama, etc - just ended up outweighing any interest I had in developing.
I came up with a way of tying the install to a particular console, so the latest version won't work with their new channel-rip scheme. But these cycles last a long time and somehow they always come up with some kind of work around. I highly doubt they'll be able to bypass this latest trick (the scammers themselves have no development or reverse engineering skill whatsoever, so it won't happen unless someone helps them), but there are better chances that someone will figure out a way to make things work on newer consoles without using our installer, and then the scammers will just use that to install older versions of HBC.
Last time they were supposed to be forced to use our installer since the older versions wouldn't install on newer consoles. But unfortunately another developer had come up with a rather dodgy exploit and released it for a different purpose, thinking they'd never think about abusing it for other means. Guess what happened. We've all gone through that phase, "how could this possibly be abused; none of this is ever going to happen to me". Even after that, the same guy came up with a very clever way of getting code to run using an exploit in SD channel banners. I told him to include a scam warning screen, so he added some text which is displayed using the standard System Menu dialog box thing. I told him no one would read that since it wasn't forced to display for a set time and it just looked like yet another lame confirmation dialog. He figured it was okay. Now the scammers are happily bundling his exploit which explicitly warns you about being scammed, and none of their moronic customers read it because, of course, they all just go straight for the "OK" button. It's bad: you need to have in-your-face warning screens, scary looking text on a black background, forced 20-second read times, and use an unconventional "OK" button on the controller. Otherwise the scammers sell it and most of their customers don't even notice.
There are all kinds of unscrupulous people who will happily take other people's work and pass it as their own. For example, there's an entire bunch of websites devoted to bundling free Wii homebrew utilities with warez-loading apps and a torrent client and selling it as the ultimate Wii softmod get-all-your-games-for-free package. Examples: homebreware.com, playbreware.com, homebrewinstaller.com, mywiidownloads.com... the list goes on. They have sales numbers that are a sizable chunk of total homebrew users and mainly cater to the clueless, earning large amounts of cash for basically nothing.
Our "core" software (specifically, the Twilight Hack, Homebrew Channel, DVDX, BootMii, HackMii Installer, etc) is mostly distributed under a closed-source restrictive "download it from our site and use it, don't redistribute it" license precisely due to these kinds of websites. For example, ordinarily we wouldn't care at all about people mirroring these apps, but one of the favorite excuses from the aforementioned scamsites is that "they're just linking to some third-party mirror". the I've tried to get some of them taken down but it's damn near impossible and their payment processors (Plimus and ClickBank typically) move very slowly and do nothing at all (which is not surprising; after all, they get a cut of the profits). These sites tend to work on affiliate programs and therefore there are dozens of "affiliates" happily buying Google Ads and setting up spam blogs just to promote the scams.
What's even worse is that the warez utilities work backwards too - they let the scammers "pirate" our freeware and sell it for money. For example, our installer includes a large full-screen "if you paid for this you were scammed" warning, but the scammers have now used tools for Wii Channel piracy to distribute the Homebrew Channel without the installer, bypassing that screen. Every time this happens they get a nice 3-6 months until Nintendo puts out another update that would force them to use updated hacks and tools.
This is one of the reasons why I gave up on Wii development. And I don't have plans to touch any console or system where piracy might become a big incentive to run homebrew. Piracy brings in hordes of clueless idiots who just want free games, generally poisons the homebrew community, divides it due to the differing opinions on it, and also comes with dollar-eyed scammers who want to make a quick buck of it all.
It's pretty obvious. The people looking at app store submissions likely have only a very basic understanding of the issues involved, and the SDK agreement isn't very precise as to what falls and doesn't fall under this rule. So the results basically depend on the guy's gut feeling when he checks out the app. For example, I'm pretty sure the vast majority of them would consider a SID player a simple music player, even though it actually runs C64 machine code, just as they would probably accept a game with downloadable levels which include some form of built-in scripting as OK, as long as that part isn't explicitly pointed out somewhere.
No part of this is surprising. It's a crappy technical rule, and crappy technical rules don't work well when more than one person is supposed to enforce them.
Any sane upstream provider should be able to add a block for you on their end if someone (say, china) is flooding your connection with packets beyond capacity.
Warezed games can be run from DVD-Rs and USB drives. Sure, you run the loader from an SD card, but that's a few kilobytes. My point is that the only way to run Wii warez without a modchip is via loaders installed using/via homebrew, and the most popular way of launching homebrew to date is the Twilight Hack. Every single person out there who pirates Wii games without a modchip (a number much larger than the people purely using homebrew for legal purposes) has used either the Twilight Hack or Bannerbomb.
The Twilight Hack is an entry vector - a way of loading your own code on the system to begin with. You need one of those to run the tools necessary to set up, install, and run copied games. Therefore, and taking into account that many more people using homebrew applications to run warez than not, and that the Twilight Hack is one of two available ones at this time and clearly the all-time most popular one to date (since the newer one, bannerbomb, is very recent), most users of the Twilight Hack have used it with the ultimate goal of running warezed games.
What's so special about 98.01%?
None of those tools is useful in and of itself; they all enable other things to run or work. Twilight Hack is an exploit, PatchMii is a system patcher, DVDX is a DVD-Video mode enable hack that doesn't require patching. But even so:
Since most users of "homebrew-enabled" Wiis are using it to pirate games, and the Twilight Hack is the most popular game exploit entry point and, until recently, the only one, most of its users are certainly using it with the end goal of piracy in mind.
PatchMii was some code developed to download an IOS from nintendo's update servers, patch it on the fly, and install it (enabling legal IOS patching). Its original use is also practically obsolete - originally it was released as a platform to experiment with IOS patches, and then it was used to enable DVD-Video mode on users with modchips (ironically, good modchips tend to actually break the use of DVDs for homebrew because they make them appear as game discs, which are subject to heavier restrictions). This restriction is now circumvented and PatchMii is no longer necessary (or supported for current DVDX versions). The only real improvement to homebrew from patched IOSes is the USB 2.0 driver, which, guess what, was actually developed for piracy, and is also obsolete or should become such for homebrew, since MINI (a true homebrew replacement for IOS which enables a truly 100% nintendo-free environment) plus Linux yields ridiculously higher performance than the crappy IOS-based USB EHCI driver (the latter doesn't even use IRQs). Given that PatchMii serves a limited purpose for homebrew these days, and that it is, on the other hand, the base for all of the warez-enabled modified IOS installers, we can also certainly say that most of the users of the PatchMii codebase are also using it with the end goal of piracy in mind.
Finally, even though DVDX serves a very specific purpose (trick IOS into turning on DVD mode for the user without having to patch it, so homebrew can read from DVDVideo or DVDR discs for data), and even though it's quite simple code, and even though warez loaders need to patch IOS anyway (since pure DVD mode isn't compatible with games), the very first DVD warez loader (which, by the way, sucked very badly) used it because the developer was too incompetent to figure out what bit to flip inside the IOS that he was already patching. So even DVDX, a tool that couldn't possibly be useful for piracy, indeed was used for that, although we can't speak of a majority of users here (the guy eventually figured out what he had to patch and it is no longer required).
We can't have nice things - anything and everything that homebrew developers make will be abused by much larger numbers of warez users. I say this as a former developer of all three of the tools mentioned. It's rather depressing that, say, the software installation interface that I reverse engineered and then added support for in libogc (originally used to install The Homebrew Channel, DVDX, etc) is now mostly used to install warez-patched IOSes and VC/WiIWare warez, and that even the libogc library that I developed it for turned out to contain a large steaming pile of code copied straight from the Nintendo SDK.
Glossary for those not familiar with Wii homebrew stuff:
IOS - an OS that runs on the Wii's "Starlet" ARM sub-CPU that contains security features and drivers for most wii-exclusive functionality that wasn't present in the GameCube. Unrelated to Cisco IOS.
Twilight Hack - exploit in Zelda: Twilight Princess that lets you run a homebrew executable. Recently open-sourced.
PatchMii - downloads and patches an IOS from Nintendo's servers and installs it, all on the fly and automatically. Originally released as an open-source platform for IOS experimentation.
DVDX - a trick using a hidden channel and some context save code. Basically it has a flag set that makes the Wii consider it the "DVD Player Channel", for which support officially exists and for which there's a special DVD drive mode, even tho
As a prior Wii homebrew developer, I have absolutely no doubt that 99% of its users are just doing it to run crappy piracy tools. It's one of the reasons why I gave up on console homebrew and Wii homebrew in particular.
Then there's the thing where the main Wii homebrew library largely consists of code ripped straight out of the Nintendo SDK (most of the drivers and frameworks have the same API with the same code, just manually translated line by line from assembler to C - the only decent documentation for the "homebrew" graphics API is the SDK documentation itself). Nobody knew at first, since the guy responsible conveniently forgot to tell anyone. Now everyone just pretends the problem doesn't exist. No one dares to work on an alternative - even people who otherwise hate the library due to its failures. So in the end just about every homebrew binary for the Wii is a big SDK copyright violation. Kind of like the Xbox 1 situation where everyone used the SDK, except people there knew it was illegal and distributed the binaries underground, whereas here everyone just plugs their ears when the libogc issue is mentioned.
And people wonder why console homebrew has so much trouble attracting sane good developers.
Yup. But of course nobody actually RTFA.