Not sure I'd consider them "world-class", but for most purposes kdenlive is pretty good for video editing under Linux, Eagle is a very popular PCB layout tool that runs on Linux, Windows, and Mac OS.
Unless games are exploiting security bugs in the software upgrade process to force downgrades to vulnerable versions these days, I'm pretty sure no games depend on it. It's a security exploit, not a security design flaw. You can't depend on it without wanting to break into the system.
I can pretty much guarantee that either they haven't figured it out or they don't care.
I'm perfectly up to date on the homebrew scene, thanks, and I'm still fully convinced that Nintendo is either too stupid to go after piracy and not homebrew, or just doesn't want to.
Nintendo has ignored underlying security issues that enable piracy and instead focused on closing throwaway homebrew exploits
This started even before there were warez loaders anyway
When we tried to contact them about the software trick that would later be abused to create the first DVD warez launcher, they harassed us instead of taking our information.
Current homebrew exploits do not enable warez anyway. The only way you can go from homebrew to warez is to chainload via BootMii at the lowest level (since BootMii lets you run any code on the security processor, but you need to bootstrap yourself into a fully working patched IOS system in order to run warez, and most people don't do this). Nonetheless, the tmd version downgrade exploit which is NOT used for homebrew at all remains unfixed after 3 software updates, and it remains the most popular tool used to enable warez.
Before the release of BootMii (and the aforementioned ability to run low level code on the Starlet), homebrew did NOT enable warez in any way whatsoever. During the timeframe between the original fakesigning fix (October 23rd, 2008) and the release of BootMii (May 13th, 2009), the only way to get warez was the tmd bug mentioned above, and they still haven't fixed the damn thing. Homebrew does not imply warez without low level access to Starlet, because IOS homebrew runs under control of the Starlet, as a game, and with the same security sandboxing that games get. Warez requires modifying system firmware (IOSes), and doing that requires some sort of IOS exploit. Read that again: for 7 months, warez depended on an exploit that was totally unrelated to homebrew, you couldn't pirate games given a homebrew install without that exploit, homebrew did not use that exploit for installation, and not only did they not fix it, it remains unfixed to this date, after 16 months!.
I'd also like to take this opportunity to remind you that the idiots behind warez software are behild hundreds of bricked Wiis thanks to the pathetic quality of warez tools, because the people who cobble together homebrew tools and libraries to make them rarely know how to write a decent program.
Ironically, hardware mods are actually safer than software loaders - they rarely fuck up if you do them right, they won't randomly kill your Wii with an update, and if you really screw up you only have to replace the drive board (cheap) instead of the entire Wii. This is not to say that decent software mods are impossible, just that current ones are written by idiots.
The Linux b43 driver uses the standard Linux wireless driver interface. I don't see it hooking into that many places in the kernel. There also appears to be a driver in OpenBSD for the same hardware.
It's obviously not trivial, but I don't see why it would have to be a huge effort.
Linux has some extra overheads, which is why I suggested eCos, althought the kernel does boot in a of couple seconds and the userspace framework could be very thin. USB, Bluetooth, Wi-Fi are already supported by Linux (they're standard chips/interfaces). Mini doesn't have to support anything, as it can just enable direct access by the PPC by flipping some bits in a register (this is how Linux works), and the advantage of offloading driver support to the Starlet CPU isn't much (the main purpose of Starlet in the Wii architecture is security separation and WC24 mode, not offloading drivers). I have a feeling eCos should be able to support USB, Bluetooth, and SD with ease. Wi-Fi would need some porting of the Linux b43 driver.
It's worth noting that not running under IOS gains you 11MB of RAM. Linux already takes advantage of this when running under mini, not to mention that hardware support is a lot better, faster, and more featureful than when running legacy Linux under IOS. For example, Linux under mini has proper Wi-Fi support and the SD/USB transfer rates are much faster than under IOS.
NAND filesystem is pretty much useless and discouraged; it's a lot safer to live our homebrew lives inside an SD card or other external storage, unless you want to dedicate a Wii to Linux use or something like that (but in that case you might as well use JFFS2).
It's even worse - at least on my KDE system, the main GIMP toolbox window doesn't even show up in the task bar. I have no clue why, but this is the only program that has this issue. The net result is that I have to minimize other windows to get to it if I ever "lose" it.
I don't have a clue what point you're trying to express there. Of course Nintendo has no obligation to do anything. I'm just pointing out how simple and effective modchip detection would be against a large class of users who pirate.
It's mostly IRC logs, but I can put up a more detailed report if you're interested.
The gist is that libogc can be mostly broken down like this:
"Imported" libraries like lwip, lwbt, wiiuse, etc. that were developed separately and then merged into the tree. These should be OK
LWP threading system. I think a bit of this might have some remnants of the Nintendo stuff (maybe in exception handlers or the like), but most of it is shagkur's original work. As a threading system it totally sucks, but that's better than being illegal.
New Wii stuff to interface with IOS. This can be broken down into basically stuff shagkur (the "author" of libogc) "wrote" by decompiling the Wii SDK, and stuff that everyone else wrote. Thankfully the former isn't too much and could be replaced given some effort.
The old Gamecube drivers. This is where the huge problem lies. Stuff like handling of pads, memory cards, EXI/SPI devices (RTC, ROM, etc.), audio, DSP, video, graphics, and even the matrix math library. These are all inherited in Wii mode and required. The problems range from identical APIs but different code (not too common), through mostly manually decompiled code with the same APIs (most of it), to straight ripped assembly code (matrix math library and a few system tidbits) and at least one binary blob ripped verbatim from Nintendo (the DSP program to perform memory card unlocking).
The big fat problem is the GX driver (graphics). Everything else could be replaced with little to average effort, and the hardware is documented enough to get it to work.
Personally, though, once the large obstacle that is legal GX is overcome, I'd advocate developing an entirely new system from scratch, based on Linux or eCos or some other embedded OS, working on top of mini and ditching Nintendo's IOS. I've tried to get people interested in such a project for quite a while but haven't really found any significant support, and by now I've mostly move away from the Wii and on to other systems.
They could completely disable an entire generation of older non-upgradeable or crappily-upgradable modchips with a relatively simple update, permanently. Talk about low-hanging fruit.
Both the Xbox1 and the Wii can run Linux. On the Wii nowadays this means using BootMii + Mini, which is a completely new framework that has no relation to any Nintendo code (though strictly speaking it isn't cleanroom, as we didn't go through the cleanroom process which involves having separate teams write a spec and implement the software to it). This is a completely legal setup as far as we know.
"Native" Xbox1 homebrew (running on the Microsoft kernel) uses the Microsoft SDK, which makes binaries illegal to distribute. Most "Native" Wii homebrew (using Nintendo's IOS) uses a "homebrew" library (libogc) that is derived from a decompiled version of the Nintendo Gamecube SDK (exceptions: exploit stuff which is based on segher's Twilight Hack codebase, TinyLoad which also is, little else), so effectively most Wii homebrew binaries are also illegal. However, the author of this decompilation pretend the code was an original work of his for a long time, and by the time we found out just how ripped it was everyone and their mom was using this library, so the net result is that most know that the resulting Wii binaries are about as illegal as the Xbox1 ones, but everyone pretends they aren't and they are happily distributed through "official" channels.
95% of the modchips out there are trivial to detect. They'll have stupid stuff like custom commands that can be used to identify them, and broken or flat out incorrect implementations of standard commands. Seriously. They aren't even trying. This isn't even remotely in the same league as Xbox 360 hacks and the like, which have evolved to be quite a bit stealthier due to Microsoft's detection efforts.
As for the exploit, it's the downgrade hole originally used by Comex's DVDX34 installer (which was quickly abused for other means) and more recently still used by Trucha Bug Restorer. We refuse to use this for homebrew because it involves altering (downgrading) system software, which we consider harmful, but it's there and it acts as a convenient fast-track for piracy (downgrade system software to vulnerable version, use that to install your favorite warez-pack). The exploit itself is rather silly: start installing something, which causes the system to copy the signed metadata to a temporary location. The FS permissions are set wrong, so you can delete it, write your own version with an artificially low version number, and finish the install. Then the system thinks you have an older version and will let you install any random ancient vulnerable version, as they only check signatures initially, not once things are installed.
And yet they still don't give a damn about piracy, technologically speaking, or at least they care about it a lot less than they care to annoy homebrewers and importers.
Proof: the last three iterations of Wii System Updates closed exploits used to run homebrew, but an ancient exploit that is still being used for piracy has remained untouched for that long (and counting). More proof: it would be trivial for them to detect and block modchips at the system update level, but so far they haven't even tried. Even more proof: NIntendo seems to be happy deliberately bricking your Wii if you have imported it, but it certainly hasn't even crossed their mind to do that for people who pirate. Yes, System Update 4.2 deliberately bricked all Korean Wiis that had been switched to the USA or EUR region. And by this I mean an explicit if(korean_detected()) { show_error_code_on_boot(003); }.
PTP. PTP is a USB standard specific for picture transfer. iPhone OS devices support PTP just fine; this is a non-issue.
MTP. MTP is a newer USB standard specific for media transfer. Apple insists on locking users into iTunes and will never support MTP. They deserve any and all criticism for this. This isn't new, though - it has been Apple policy ever since the first iPod.
What the OP wants: to use iPhone OS devices for generic mass storage. There is no non-hacky way to accomplish this with current standards and a device like the iPhone. This is what I've been talking about. Apple isn't at fault here.
Other Apple lock-in tactics such as cryptographically authenticating -get this- video cables. This is ridiculous and they deserve to be bashed for it.
As I said, Apple is often evil (iTunes, cable auth) but not always (no mass storage). I just want people to get it straight when they are and aren't.
Don't be an idiot. Take the memory stick out of a PSP - it still works. Remove the data partition from an iPhone and it won't boot.
The PSP isn't a smartphone. It's a console bundled with a media player. It doesn't give a damn if you yank out its memory stick - all that happens is you won't be playing music or storing savegames. And it doesn't multitask.
Since you have a PSP, I'm going to assume you pirate games as it seems to be the only reason people have a PSP these days. Start a game from the MS. Now try to copy some music onto the memory stick using a computer. You can't. Put the PSP into USB mode. Now try to boot a game. You can't without stopping USB mode. THIS is what the iPhone can do - actively access data from its data partition (e.g. applications and their data) while communicating with a PC over USB. This is completely, utterly impossible to do with current standard (commonly implemented) USB protocols except for the specific case of media using MTP. The closest thing we have is USB networking plus some form of network file system, but it isn't ubiquitous or plug&play.
The design decision is to not cripple the device by making internal use of storage mutually exclusive with USB access. This is a perfectly rational design decision. Once you've established that, it turns out you can't do it using existing standards. When a perfectly rational, desirable design decision can not be implemented using existing standards, it means we need new standards, not that the company is actively trying to screw people over. You can blame them for not developing a standard and publishing it for others to use, but this isn't necessarily their responsibility.
The fact of the matter is that USB Mass Storage can only do what a USB memory card reader, memory cards, and a memory card-using device can do. You can bundle the reader and card (flash drives), or you can bundle the reader and the device (the PSP, most cellphones/players), or you can bundle all three (Android phones with internal storage, newer PSPs), but at the end of the day you're still swapping the card, physical or virtual, between the reader and the embedded device.
You'd have to unmount it locally first (and use the same filesystem). You can't "properly lock" things like FAT, only special cluster filesystems can be concurrently accessed. On top of that, Apple uses HFS (which is a proper UNIX filesystem, unlike FAT, and yes they do use UNIX features such as symlinks), so they can't really share it with Windows boxes. They also expose only a subdirectory over USB, which you wouldn't be able to do this way (for example, applications are stored on the data partition, but you can't see them over USB).
No one can do it. The PSP presents its MemoryStick card to the OS, and in USB mode it can't do anything with it anyway. Android phones do the same thing with an internal partition. There is no standard USB protocol that allows the sharing of a partition between a device and the host OS.
Using existing mass storage protocols requires that whatever storage exists be switched from the embedded OS to the host OS, because they're low-level protocols that are designed for raw storage. This is a significant drawback for multitasking devices (and the iPhone is multitasking - no App Store apps running at once is just a high-level decision imposed by Apple by choice, not a technical limitation). Don't confuse this with all sorts of devices out there, including PSPs and iPods (non-Touch) and tons of cellphones which can go into a dumb passthrough mode where they behave as a glorified card reader or USB storage device.
Apple is evil about lots of things, but this isn't one of them.
Keeping things clean with simultaneous access really isn't hard as long as your API is file-level, not block-level (block-level concurrency is just about impossible without specific filesystems designed for that). Network filesystems have other issues to deal with that can be simplified in this case (e.g. latency).
Of course you have to lock against opening the same file for writes from both sides, but these issues occur in multitasking OSes anyway and they're fairly well understood. For example, iTunes uses lockfiles to prevent these kinds of issues.
The problem is that no such standard file access protocol exists for USB.
The way the iPhone is architected this isn't really an option, because they don't hand over the entire data partition to the host (just the Media directory), and yet they need to be able to share free space and there are a few other issues. Not that I'm saying that it couldn't be reworked to work with this kind of scheme, but it's a hack and it doesn't really fit into the way iPhone OS handles user data at the moment.
I'd consider it a design choice - there's an important tradeoff here, and Apple chose one way.
MTP isn't a remote filesystem service, it's a much higher level "media transfer protocol" which is an extension of the already high level PTP. Read that page, there are a bunch of restrictions and limitations. Besides, it seems like Microsoft is behind most of it and full support is probably available on Windows thing, so that pretty much destroys any chances of Apple using it.
To replace USB Mass Storage for smart devices, you'd want a simple, file-based protocol that supports the usual filesystem semantics. At least open(), close(), read(), write(), seek(), unlink(), mkdir(), rmdir(), and friends. MTP transfers "media objects", it doesn't really work as a generic FS. It's attacking the issue from the wrong perspective. MTP will probably be good for "smart" media players, but only for the purposes of transfering, well, media. You still can't use it for mass storage, as the OP wants.
Apple still wants to lock people into iTunes, so the chances of them implementing MTP are nil. This iTunes crap (which affects every single iPod ever made; this isn't new) is irrelevant. The OP just wants to be able to mount his device and use it as a general file storage device, like a USB flash drive. MTP won't provide that.
And no OS supports it out of the box as far as I know, which negates the advantage. Networking is also more complicated to set up and there is some extra overhead involved. Basically, in its current state, USB networking could never work as seamlessly and universally as USB mass storage, which defeats the purpose.
Actually, iPhones use a really weird TCP-alike-over-USB protocol, which is why I mention their implementation is horrid (especially because it's completely messed up and can't actually be considered a valid networking device, so the host has to use custom APIs to access device services anyway). For all intents and purposes it can be considered a custom stream multiplex protocol, not a real networking device.
You can use libimobiledevice and ifuse to mount your iPod Touch under Linux, if that's all you need. You can use it as a generic mass storage device (no need to jailbreak either) as long as you have these tools.
For what it's worth, I understand Apple's decision on this regard. There is a void in USB regarding smart devices with onboard filesystem drivers which run an OS. Basically, there's no USB File Transfer Protocol, just raw block-device USB Mass Storage (which is useless for devices that run their own OS and can't just expose a block device - not to mention that iPhone OS devices use HFS, not FAT). There's a Picture Transfer Protocol for digital cameras, and Apple does support that, but only for pictures. They made their own protocol for the other stuff. Really, iPod Touch devices aren't music players, they're embedded computers with an OS which you just happen to be able to play music on, and there's no standard "USB file transfer between OSes" protocol.
What is inexcusable is their insistence in trying to cryptographically stop people from syncing their iPods and iPhones with third-party software. But this is one layer above, and it affects the music database. The underlying nonstandard USB protocol was a practical necessity (although, incidentally, their implementation is horrid).
You can. They tried really hard, not just by using proprietary everything but also using ridiculously obfuscated crypto, but we broke it again. No jailbreaking needed.
For those who love magic 16-byte keys, the magic "freedom for Apple music players" number this time around is 618ca10dc7f57fd3b4723e08157463d7;)
Yup, synchrotron radiation. This is significant with electron accelerators, but the LHC accelerates heavy ions where it isn't that much of a problem. The synchrotron power emitted is about 3.7kW in total.
The beam energy at 7TeV is 362 megajoules. This is about the energy that you could get by maxing out a household mains connection (230V 20A) for one day, or about the energy content of 11 liters of gasoline. Quite a bit, but not huge at energy scales.
Of course, the beauty of the LHC is that it accomplishes this energy in the form of a particle beam circling the collider at near the speed of light. This means that the power of the beam is about 4 terawatts if my math is right, so it could power about 3300 DeLorean time machines (not for very long, though). Keep in mind that this power is circling endlessly in the LHC, so it isn't being consumed - the actual electric power consumption to run the whole LHC is "only" about 120 megawatts.
Uhm, no, you can't do that. SSL is designed so that MITM is impossible by using public-key cryptography; the catch is that you need to trust the (cryptographic) identity of the other side. Self-signed certificates can be defeated because you can create your own identity that will have equivalent trust (unless the user has specifically placed trust only on a specific self-signed certificate) and then pretend to be the original identity.
CA certificates relate the cryptographic identity to the domain in a traceable manner, which would make this impossible (assuming there are no rogue CAs or CA policy issues).
Watching the key exchange does you no good because the public-key cryptography prevents you from obtaining the session key directly.
Slashdot Mirror
Not sure I'd consider them "world-class", but for most purposes kdenlive is pretty good for video editing under Linux, Eagle is a very popular PCB layout tool that runs on Linux, Windows, and Mac OS.
Unless games are exploiting security bugs in the software upgrade process to force downgrades to vulnerable versions these days, I'm pretty sure no games depend on it. It's a security exploit, not a security design flaw. You can't depend on it without wanting to break into the system.
I can pretty much guarantee that either they haven't figured it out or they don't care.
I'm perfectly up to date on the homebrew scene, thanks, and I'm still fully convinced that Nintendo is either too stupid to go after piracy and not homebrew, or just doesn't want to.
I'd also like to take this opportunity to remind you that the idiots behind warez software are behild hundreds of bricked Wiis thanks to the pathetic quality of warez tools, because the people who cobble together homebrew tools and libraries to make them rarely know how to write a decent program.
Ironically, hardware mods are actually safer than software loaders - they rarely fuck up if you do them right, they won't randomly kill your Wii with an update, and if you really screw up you only have to replace the drive board (cheap) instead of the entire Wii. This is not to say that decent software mods are impossible, just that current ones are written by idiots.
The Linux b43 driver uses the standard Linux wireless driver interface. I don't see it hooking into that many places in the kernel. There also appears to be a driver in OpenBSD for the same hardware.
It's obviously not trivial, but I don't see why it would have to be a huge effort.
I'll see what I can do about the report.
Linux has some extra overheads, which is why I suggested eCos, althought the kernel does boot in a of couple seconds and the userspace framework could be very thin. USB, Bluetooth, Wi-Fi are already supported by Linux (they're standard chips/interfaces). Mini doesn't have to support anything, as it can just enable direct access by the PPC by flipping some bits in a register (this is how Linux works), and the advantage of offloading driver support to the Starlet CPU isn't much (the main purpose of Starlet in the Wii architecture is security separation and WC24 mode, not offloading drivers). I have a feeling eCos should be able to support USB, Bluetooth, and SD with ease. Wi-Fi would need some porting of the Linux b43 driver.
It's worth noting that not running under IOS gains you 11MB of RAM. Linux already takes advantage of this when running under mini, not to mention that hardware support is a lot better, faster, and more featureful than when running legacy Linux under IOS. For example, Linux under mini has proper Wi-Fi support and the SD/USB transfer rates are much faster than under IOS.
NAND filesystem is pretty much useless and discouraged; it's a lot safer to live our homebrew lives inside an SD card or other external storage, unless you want to dedicate a Wii to Linux use or something like that (but in that case you might as well use JFFS2).
It's even worse - at least on my KDE system, the main GIMP toolbox window doesn't even show up in the task bar. I have no clue why, but this is the only program that has this issue. The net result is that I have to minimize other windows to get to it if I ever "lose" it.
Uhh, because ostensibly they don't want piracy?
I don't have a clue what point you're trying to express there. Of course Nintendo has no obligation to do anything. I'm just pointing out how simple and effective modchip detection would be against a large class of users who pirate.
It's mostly IRC logs, but I can put up a more detailed report if you're interested.
The gist is that libogc can be mostly broken down like this:
The big fat problem is the GX driver (graphics). Everything else could be replaced with little to average effort, and the hardware is documented enough to get it to work.
Personally, though, once the large obstacle that is legal GX is overcome, I'd advocate developing an entirely new system from scratch, based on Linux or eCos or some other embedded OS, working on top of mini and ditching Nintendo's IOS. I've tried to get people interested in such a project for quite a while but haven't really found any significant support, and by now I've mostly move away from the Wii and on to other systems.
They could completely disable an entire generation of older non-upgradeable or crappily-upgradable modchips with a relatively simple update, permanently. Talk about low-hanging fruit.
Both the Xbox1 and the Wii can run Linux. On the Wii nowadays this means using BootMii + Mini, which is a completely new framework that has no relation to any Nintendo code (though strictly speaking it isn't cleanroom, as we didn't go through the cleanroom process which involves having separate teams write a spec and implement the software to it). This is a completely legal setup as far as we know.
"Native" Xbox1 homebrew (running on the Microsoft kernel) uses the Microsoft SDK, which makes binaries illegal to distribute. Most "Native" Wii homebrew (using Nintendo's IOS) uses a "homebrew" library (libogc) that is derived from a decompiled version of the Nintendo Gamecube SDK (exceptions: exploit stuff which is based on segher's Twilight Hack codebase, TinyLoad which also is, little else), so effectively most Wii homebrew binaries are also illegal. However, the author of this decompilation pretend the code was an original work of his for a long time, and by the time we found out just how ripped it was everyone and their mom was using this library, so the net result is that most know that the resulting Wii binaries are about as illegal as the Xbox1 ones, but everyone pretends they aren't and they are happily distributed through "official" channels.
No, I don't approve of the latter.
95% of the modchips out there are trivial to detect. They'll have stupid stuff like custom commands that can be used to identify them, and broken or flat out incorrect implementations of standard commands. Seriously. They aren't even trying. This isn't even remotely in the same league as Xbox 360 hacks and the like, which have evolved to be quite a bit stealthier due to Microsoft's detection efforts.
As for the exploit, it's the downgrade hole originally used by Comex's DVDX34 installer (which was quickly abused for other means) and more recently still used by Trucha Bug Restorer. We refuse to use this for homebrew because it involves altering (downgrading) system software, which we consider harmful, but it's there and it acts as a convenient fast-track for piracy (downgrade system software to vulnerable version, use that to install your favorite warez-pack). The exploit itself is rather silly: start installing something, which causes the system to copy the signed metadata to a temporary location. The FS permissions are set wrong, so you can delete it, write your own version with an artificially low version number, and finish the install. Then the system thinks you have an older version and will let you install any random ancient vulnerable version, as they only check signatures initially, not once things are installed.
And yet they still don't give a damn about piracy, technologically speaking, or at least they care about it a lot less than they care to annoy homebrewers and importers.
Proof: the last three iterations of Wii System Updates closed exploits used to run homebrew, but an ancient exploit that is still being used for piracy has remained untouched for that long (and counting). More proof: it would be trivial for them to detect and block modchips at the system update level, but so far they haven't even tried. Even more proof: NIntendo seems to be happy deliberately bricking your Wii if you have imported it, but it certainly hasn't even crossed their mind to do that for people who pirate. Yes, System Update 4.2 deliberately bricked all Korean Wiis that had been switched to the USA or EUR region. And by this I mean an explicit if(korean_detected()) { show_error_code_on_boot(003); }.
There are several issues here.
As I said, Apple is often evil (iTunes, cable auth) but not always (no mass storage). I just want people to get it straight when they are and aren't.
Don't be an idiot. Take the memory stick out of a PSP - it still works. Remove the data partition from an iPhone and it won't boot.
The PSP isn't a smartphone. It's a console bundled with a media player. It doesn't give a damn if you yank out its memory stick - all that happens is you won't be playing music or storing savegames. And it doesn't multitask.
Since you have a PSP, I'm going to assume you pirate games as it seems to be the only reason people have a PSP these days. Start a game from the MS. Now try to copy some music onto the memory stick using a computer. You can't. Put the PSP into USB mode. Now try to boot a game. You can't without stopping USB mode. THIS is what the iPhone can do - actively access data from its data partition (e.g. applications and their data) while communicating with a PC over USB. This is completely, utterly impossible to do with current standard (commonly implemented) USB protocols except for the specific case of media using MTP. The closest thing we have is USB networking plus some form of network file system, but it isn't ubiquitous or plug&play.
The design decision is to not cripple the device by making internal use of storage mutually exclusive with USB access. This is a perfectly rational design decision. Once you've established that, it turns out you can't do it using existing standards. When a perfectly rational, desirable design decision can not be implemented using existing standards, it means we need new standards, not that the company is actively trying to screw people over. You can blame them for not developing a standard and publishing it for others to use, but this isn't necessarily their responsibility.
The fact of the matter is that USB Mass Storage can only do what a USB memory card reader, memory cards, and a memory card-using device can do. You can bundle the reader and card (flash drives), or you can bundle the reader and the device (the PSP, most cellphones/players), or you can bundle all three (Android phones with internal storage, newer PSPs), but at the end of the day you're still swapping the card, physical or virtual, between the reader and the embedded device.
You'd have to unmount it locally first (and use the same filesystem). You can't "properly lock" things like FAT, only special cluster filesystems can be concurrently accessed. On top of that, Apple uses HFS (which is a proper UNIX filesystem, unlike FAT, and yes they do use UNIX features such as symlinks), so they can't really share it with Windows boxes. They also expose only a subdirectory over USB, which you wouldn't be able to do this way (for example, applications are stored on the data partition, but you can't see them over USB).
No one can do it. The PSP presents its MemoryStick card to the OS, and in USB mode it can't do anything with it anyway. Android phones do the same thing with an internal partition. There is no standard USB protocol that allows the sharing of a partition between a device and the host OS.
Using existing mass storage protocols requires that whatever storage exists be switched from the embedded OS to the host OS, because they're low-level protocols that are designed for raw storage. This is a significant drawback for multitasking devices (and the iPhone is multitasking - no App Store apps running at once is just a high-level decision imposed by Apple by choice, not a technical limitation). Don't confuse this with all sorts of devices out there, including PSPs and iPods (non-Touch) and tons of cellphones which can go into a dumb passthrough mode where they behave as a glorified card reader or USB storage device.
Apple is evil about lots of things, but this isn't one of them.
Keeping things clean with simultaneous access really isn't hard as long as your API is file-level, not block-level (block-level concurrency is just about impossible without specific filesystems designed for that). Network filesystems have other issues to deal with that can be simplified in this case (e.g. latency).
Of course you have to lock against opening the same file for writes from both sides, but these issues occur in multitasking OSes anyway and they're fairly well understood. For example, iTunes uses lockfiles to prevent these kinds of issues.
The problem is that no such standard file access protocol exists for USB.
The way the iPhone is architected this isn't really an option, because they don't hand over the entire data partition to the host (just the Media directory), and yet they need to be able to share free space and there are a few other issues. Not that I'm saying that it couldn't be reworked to work with this kind of scheme, but it's a hack and it doesn't really fit into the way iPhone OS handles user data at the moment.
I'd consider it a design choice - there's an important tradeoff here, and Apple chose one way.
MTP isn't a remote filesystem service, it's a much higher level "media transfer protocol" which is an extension of the already high level PTP. Read that page, there are a bunch of restrictions and limitations. Besides, it seems like Microsoft is behind most of it and full support is probably available on Windows thing, so that pretty much destroys any chances of Apple using it.
To replace USB Mass Storage for smart devices, you'd want a simple, file-based protocol that supports the usual filesystem semantics. At least open(), close(), read(), write(), seek(), unlink(), mkdir(), rmdir(), and friends. MTP transfers "media objects", it doesn't really work as a generic FS. It's attacking the issue from the wrong perspective. MTP will probably be good for "smart" media players, but only for the purposes of transfering, well, media. You still can't use it for mass storage, as the OP wants.
Apple still wants to lock people into iTunes, so the chances of them implementing MTP are nil. This iTunes crap (which affects every single iPod ever made; this isn't new) is irrelevant. The OP just wants to be able to mount his device and use it as a general file storage device, like a USB flash drive. MTP won't provide that.
And no OS supports it out of the box as far as I know, which negates the advantage. Networking is also more complicated to set up and there is some extra overhead involved. Basically, in its current state, USB networking could never work as seamlessly and universally as USB mass storage, which defeats the purpose.
Actually, iPhones use a really weird TCP-alike-over-USB protocol, which is why I mention their implementation is horrid (especially because it's completely messed up and can't actually be considered a valid networking device, so the host has to use custom APIs to access device services anyway). For all intents and purposes it can be considered a custom stream multiplex protocol, not a real networking device.
You can use libimobiledevice and ifuse to mount your iPod Touch under Linux, if that's all you need. You can use it as a generic mass storage device (no need to jailbreak either) as long as you have these tools.
For what it's worth, I understand Apple's decision on this regard. There is a void in USB regarding smart devices with onboard filesystem drivers which run an OS. Basically, there's no USB File Transfer Protocol, just raw block-device USB Mass Storage (which is useless for devices that run their own OS and can't just expose a block device - not to mention that iPhone OS devices use HFS, not FAT). There's a Picture Transfer Protocol for digital cameras, and Apple does support that, but only for pictures. They made their own protocol for the other stuff. Really, iPod Touch devices aren't music players, they're embedded computers with an OS which you just happen to be able to play music on, and there's no standard "USB file transfer between OSes" protocol.
What is inexcusable is their insistence in trying to cryptographically stop people from syncing their iPods and iPhones with third-party software. But this is one layer above, and it affects the music database. The underlying nonstandard USB protocol was a practical necessity (although, incidentally, their implementation is horrid).
You can. They tried really hard, not just by using proprietary everything but also using ridiculously obfuscated crypto, but we broke it again. No jailbreaking needed.
For those who love magic 16-byte keys, the magic "freedom for Apple music players" number this time around is 618ca10dc7f57fd3b4723e08157463d7 ;)
Yup, synchrotron radiation. This is significant with electron accelerators, but the LHC accelerates heavy ions where it isn't that much of a problem. The synchrotron power emitted is about 3.7kW in total.
The beam energy at 7TeV is 362 megajoules. This is about the energy that you could get by maxing out a household mains connection (230V 20A) for one day, or about the energy content of 11 liters of gasoline. Quite a bit, but not huge at energy scales.
Of course, the beauty of the LHC is that it accomplishes this energy in the form of a particle beam circling the collider at near the speed of light. This means that the power of the beam is about 4 terawatts if my math is right, so it could power about 3300 DeLorean time machines (not for very long, though). Keep in mind that this power is circling endlessly in the LHC, so it isn't being consumed - the actual electric power consumption to run the whole LHC is "only" about 120 megawatts.
Uhm, no, you can't do that. SSL is designed so that MITM is impossible by using public-key cryptography; the catch is that you need to trust the (cryptographic) identity of the other side. Self-signed certificates can be defeated because you can create your own identity that will have equivalent trust (unless the user has specifically placed trust only on a specific self-signed certificate) and then pretend to be the original identity.
CA certificates relate the cryptographic identity to the domain in a traceable manner, which would make this impossible (assuming there are no rogue CAs or CA policy issues).
Watching the key exchange does you no good because the public-key cryptography prevents you from obtaining the session key directly.