What makes you say that?

Care to explain what PCB traces are shared between D+/D- on the USB and the RAM? And what this has to do with your TomTom?

You're also confusing the service mode jig used in Sony repair centers on retail consoles with debug consoles used for development. The two are unrelated.

It's also worth pointing out that Rigol apparently makes some of Agilent's low-end scopes for them, so the fact that they aren't a household name doesn't mean all that much.

The Rigol scope has a lot of nice features that you wouldn't expect to find on a cheap scope -- it can take screenshots and store them to a USB thumb drive or print them to a USB printer, you can connect it to your computer to control it or acquire data via USB or RS-232, etc. It actually oversamples at 1 Gigasample/second -- there have been a number of EEVblog shows about it, talking about its performance, the parts that go into it (and the corners they did cut to get the price down!), etc. Google "eevblog rigol" to find the rest of them.

They really haven't. Let's consider the timeline of updates to the Wii software since the first exploit was demonstrated. Note that there's no technical need to update the System Menu, any version of IOS (the invisible "firmware" that implements all of the interesting security features of the system), or any channel at the same time. IOS fixes can never add functionality by themselves, they can only work around some bugs in disc-based games. Any update that claims "behind the scenes updates" or "system improvements" refers to IOS updates, most of which are to patch exploits and very few of which actually impact performance, despite their claims.

• v3.3 June 17, 2008 -- No features, added code to the System Menu to block the Twilight Hack.
• v3.4 November 17, 2008 -- Fixed anti-Twilight Hack code. Updated Parental Controls, and added USB keyboard to the Mii Channel (?). Strange attempt to block the default slot number used by a code example I released.
• v4.0 March 25, 2009 -- Considerable update to the System Menu to add support for running channels that are stored on SD card.
• v4.1 July 2009 -- Fixes an obscure System Menu bug. Added code to better block copy-protected saves.
• v4.2 September 28, 2009 -- First attempt at blocking Bannerbomb.Also added code to delete the Homebrew Channel and DVDX. Added code to check to see if a console had its region altered, in some cases forcing a brick (!). Improved region-checking code for games. Forced a bootloader update (boot2v4) that didn't actually fix any bugs or exploits -- it just overwrote your bootloader "just in case" you had modified it, and caused a fair bit of collateral damage which Nintendo tried to blame on "hacking", even on virgin consoles. (There's a reason they tell you not to reflash your BIOS if you don't really need to...)
• v4.2 June 21, 2010 -- Second attempt at blocking Bannerbomb. Deletes (again!) the Homebrew Channel and BootMii(/IOS), and patches IOS exploits used to install them.

The only update Nintendo has done in the past 2 and a half years that has actually benefitted users was v4.0, which added the SD support (as crude as it was). All the others have just been ways to fix various exploits. They fail at using the carrot; their stick is the fact that the Shopping channel will break unless you update, and many games will force you to update before you can play them.

Untrue. Each firmware for each iPhone comes with a version of the baseband firmware that will work anywhere in the world; the only carrier-specific settings are SIM locking info (ugh), voicemail/MMS servers, etc.

You do realize that the company that is "allowing this" is Skype, not Apple, right? There was an Apple-imposed restriction on apps using VOIP over 3G, but that was lifted back in January -- hell, that's even in the summary of this article! Other apps that were released or updated since then have supported it.

The news here is that Skype finally updated their own app, and Skype may start charging for their service when used over 3G -- money that would go to them, not to Apple, AT&T or anyone else. That's the only "innovation" we're talking about here.

Sure; I wasn't disagreeing with you, I just didn't understand what you were saying and was asking for clarification.

When the parent poster said "You can develop however you like on OS X", I think they meant "You can write whatever programs you want on OS X" or perhaps "You can use whatever software tools you want to write programs that run on OS X". I don't think anyone ever said "Everyone who wants to develop for OS X will find hardware that fits their needs".

That being said ... coming back around (tangentially) to the world of gaming, I believe the Mac builds of ScummVM are actually built on Linux boxes using a cross-compiling toolchain (based on odcctools). That's more effort than I'd care to go to, but if you were dead-set on developing apps for the Mac using your Dell Mini 10, you could go that route.

Why do you need a "MacBook mini"?

You might want to weigh your own confidence against the authority of the person making claims you disagree with before launching into an attack.

I don't really understand your objection to a), and I think Marcan's claims about b) are justified but deserve a bit of clarification. It's not so simple; as Michael Steil discusses, the efforts (piracy vs homebrew) often leverage each others' work. The only reason you can "run homebrew [on the Wii] without modifying the DVD drive to accept pirated discs" is that ... we were able to bootstrap our efforts by using modified disc images, which requires modifying the DVD drive to accept burned discs. The first unsigned code execution we demonstrated used a patched Lego Star Wars disc with code injected into it. Later, we used the same technique to inject debugging code into a copy of Zelda, and then used that to facilitate making a save-game exploit that ultimately did not require hardware modification.

It might have been possible to reach that end goal in some different way, but it would have been much more difficult.