AFAIK it's mostly so they can run the homescreen and let people use the browser at the same time as games. They could allow developers to disable the browser and use more RAM, I guess.

You're looking at it backwards. The PS2, the GC, the DS, and everything before them didn't *have* an OS you could use. They were also simple enough that bare metal software made sense. They also didn't have enough RAM or CPU oomph to make Linux usable, so people built bare-metal libraries for them.

The Wii is the middle step. It got lucky, because we had libogc from the GC days, and it still didn't have enough RAM to run Linux comfortably, though popular homebrew based on Linux does exist. It also didn't really have an OS either, just a built-in launcher.

The Wii U changes that. It uses bog standard hardware that *already* has Linux drivers. It has a truckload of RAM. And its native apps already use an OS that qualifies as a modern multitasking, protected memory OS. Running Linux on it will actually improve things (e.g. you get access to more RAM, since normally the system reserves half!)

Think of Linux as a homebrew SDK, nothing more. Just one that happens to have APIs that make porting existing games and apps way easier than it ever has been on any other console. Nobody's suggesting that we throw Ubuntu on people's consoles, just that the Homebrew Channel for Wii U might as well run a Linux kernel behind the scenes. Homebrew developers don't *actually* want to learn yet another proprietary graphics API when they can just use OpenGL. Make it easier to write homebrew without needing to use specific skills and undocumented APIs, and you'll get better homebrew.

The dynamic linking in Cafe OS makes writing homebrew easier since you don't need an SDK, but, for example, the Cafe OS NX enforcement would make a homebrew channel impossible (without a kernel exploit) since it wouldn't be able to boot other code. Personally, I think ignoring Cafe OS entirely and rolling our own Linux thing would be more productive, though higher initial effort.

We haven't looked into non-browser exploits. There probably are quite a few around though, subject to possible entry points (i.e. things the Wii U will do with storage - which seem to be fewer than the Wii!).

They can't fix the Espresso exploits, as those are in ROM code (and in hardware, for the HRESET hack).

They probably could've avoided the SRESET race conditions (I won't detail how to avoid giving them any ideas, just in case they really think this is worth fixing), but they'd need to spin new silicon for that, which is extremely unlikely - they'll only do it if they're doing a new silicon revision for some other reason.

1) Nintendo can fix all the bugs. Realistically, they never will, given the quality of the software. If the history of the Wii is any indication, we'll always be able to find new bugs. The cat is out of the bag (the software is accessible), so now all it takes is white-box reverse engineering, which makes it reasonably easy to find bugs. They don't have good mitigations; a bug in Cafe OS userspace, a bit of ROP (or not even that, for the browser), a kernel bug, an IOS bug, and you're in.
2) Meh, it was mostly an evolution of the Wii's. The Wii had a pretty decent (but simplistic) security design and a crappy/buggy implementation. The Wii U seems to be more of the same, though with some nonsense thrown in (the Espresso bootrom) and some obvious features added (verification on launch and hash trees for NAND titles). On the other hand, they finally have drive to console authentication, which was sorely needed (otherwise there would've been drive emulator piracy a month after the console's release). I suspect that bit was high priority for them.
3) Inkscape.

Sure, but to do that you need keys which are different for each console, which means you need a full Wii U mode exploit running on every console (you can't just dump the keys once and use them on other consoles).

Only for the System Menu and the NANDloaders.

Have you tried coding Wii homebrew (or most other console homebrew)? You get to deal with a buggy, incomplete, mostly undocumented set of libraries. It's fun from a hacker perspective (which is why I found the Wii interesting), but for actually developing apps? No, sorry - HBC, as polished and stable as it may look, has been a constant source of headaches and we've discovered (and fixed) dozens of framework bugs while developing it. Since there's no native GUI library, it evolved using a hacked up custom widged toolkit which is bizarre and confusing. The threading used for application uploading and loading triggered bugs in the libogc scheduler (which is a horrible turd). Memory management was a pain - I ended up having to write a custom MEM2 allocator to make it able to load large themes and apps, and whenever we had a buffer overflow bug, tracking it down was a horrid exercise in using gdb over usbgecko and staring at memory hex dumps, trying to guess what the garbage that had scribbled all over your data structure was (I ended up staring at -and reading!- hex dumps of grayscale font data until I figured out what set of circumstances broke the new font code).

It's cool that we can do these things, and messing with and reverse engineering the system is fun, but as an application development platform? No, sorry, console homebrew SDKs are a joke compared to something like Android (or Linux + the usual libraries, or OSX, or Windows + DirectX), as much as you may dislike it. Console homebrew is a niche market with niche tools.

OTOH, this is why, if there's interest, I still think the obvious direction for Wii U homebrew is to use Linux. At least then you'll get a mature set of development tools and a sane graphics API (OpenGL) plus all the usual libraries like libSDL. It'll still take a lot of effort to port, but at least it won't take as much effort to actually write apps once it's done.

Now, you may argue that the Android ecosystem is more annoying for users, but there are plenty of free, ad-free, useful Android apps. It's just that, because it's a much more successful platform, and it has legitimacy that console homebrew doesn't have, they're buried under all of the ad-supported crap. On the other hand, I personally have absolutely *no* problem paying a couple bucks for a polished, functional Android app that doesn't go overboard requesting permissions. I want to support application authors like that.

As for device locking, I've never bought an Android device that required an exploit. Oh, sure, there are plenty of locked devices out there, but there are many unlocked ones too. Pretty much all of the Chinese sticks come pre-rooted. All my portable Android devices are from the Nexus line with unlocked bootloaders. Ouya comes with an unlocked bootloader. Even on locked devices, the development effort is typically minimal compared to console homebrew: just find an exploit that lets you run code as root, throw /bin/su on there, and you're set. Yesterday I fixed the Japanese fonts on my phone and tablet by editing an .xml file - how is that not an open platform?

As a hacker, I find reverse engineering security systems interesting, but when it comes to app development, I stick to what makes sense. The last two big application projects that I've worked on have been developed to run on Linux systems (though mostly portable to OSX). One of them is designed to run as set-top-box type appliance. Could I have used a Wii U? Sure, it's actually an almost ideal system from a hardware perspective - I needed a touchscreen remote. But I went with a hacked chromebox running Ubuntu and a <$100 chinese android tablet as a remote. The development effort required to get all of this to run smoothly on a Wii U (i.e. porting Linux including all of the reverse engineering required) would've been astronomical compared to the ~4000 lines of application code involved. Total price - $450 compared to $300 for a Wii U. Well worth the extra $150 for having an open system (nevermind that the Chromebox CPU is quite a bit faster). With a bit of effort it could be optimized to run on something cheaper like the Ouya.

As I said, 31 people (many of them experienced homebrewers from the Wii community) have the info so far, yet nobody has started working on this. In order for homebrew to be successful on a console, there needs to be a critical mass of interested, experienced developers to bootstrap it. I don't see that critical mass being there for the Wii U.

I don't care about whether piracy happens - if the WiiKeyU guys work it out, so be it, that's for Nintendo to deal with. I care whether it happens in association with my work. Honestly, most of the time I hear from random people using HBC, it's to run some warez launcher, and that's depressing. I don't want to end up in the situation where we have warez kiddies running pirated games using a Wii U mode exploit a year before a homebrew SDK finally becomes useful.

This is pretty much what we're doing here, isn't it?

There have been several exploits on e.g. the banner parser of the Wii System Menu. Attempting to integrate Wii channels into the Wii U menu would greatly increase the attack surface for Wii U mode.

Doing it as a totally separate sandbox is kind of annoying for users, but from a security standpoint, it makes perfect sense.