MS and Sony (and Nintendo) want you to use their respective online frameworks. They obviously aren't compatible or interoperable (different name/nick/whatever namespaces, different friends lists, different registration procedure, etc).
You can't have cross-platform online interoperation unless EA uses an entirely custom online framework that is identical among platforms. The console manufacturers wouldn't be too happy about that, and neither would gamers (who want to register once and maintain one friends list for all games, not once for each vendor or game).
The only sane solution would require heavy cooperation between all console vendors and standardizing quite a bit of the online experience, but that's never going to happen (at least not this generation).
Tell that to Nintendo, who thoughtfully decided not to implement WPA on the Nintendo DS. Even on the DSi WPA only works for DSi games (of which there are very few). It's ridiculous that WEP-only hardware is still being manufactured and sold to this day.
I doubt it. AES has been under attack ever since it showed up (that's the point). It's held up for 8 years so far and there are still no practical attacks, so it probably won't be practically broken for a long while.
There's a long road from the current attacks on AES to the practical exploitability of something like WEP. WPA TKIP is a hack on top of the WEP algorithm to let old devices get firmware updates to support WPA (it's really just WEP with different key mixing and some extra checks). It's never been a serious contender in my book, and it has already been deprecated for some time. Nothing more than a stopgap solution until devices with AES hardware showed up.
Timing buffered disk reads: 242 MB in 3.00 seconds = 80.65 MB/sec
And this is a *laptop* drive, and not a huge one at that (WD Scorpio Black 320 GB). Large desktop SATA drives average 100MB/s these days and can peak at over 120MB/s.
FAT*12* is still supported pretty much everywhere, and it's still in use for smallish SD cards and the like (~8MB). Not that I think the FAT variants are a great filesystem, but chances are you're going to be able to read them for many years. If you're concerned, stick a printout of the spec in there. FAT is simple enough to pick apart with a hex editor given some time, and it doesn't take very long to write a read-only implementation of it.
There's a big difference between broadcast networks and GSM. With GSM, networks can no doubt fix any loopholes soon after they are discovered.
Sure, of course people are interested in free phone calls, but what I mean is that I don't think it will be easy enough with GSM to make it worth their while.
Apple definitely likes C7/C8 for their smaller power supplies (laptop power supplies and stuff like iPod/iPhone chargers). However, the Mac Mini power brick and at least some iMacs use C5/C6.
Oh, and I forgot: homebrew/softmods rely on unsigned mode, while drivechips only require media detection trickery. This is why drivechip piracy existed on the Wii long before homebrew, and why getting a 360 to run pirated games is much easier than getting it to run homebrew. There is a huge technical split between drive modification-based piracy and firmware modifications (homebrew and softmod-based piracy) in this console generation.
Unfortunately, you're thoroughly confused. Modchips died with the last generation of consoles, there is no such thing any more. Modchips modify/replace system ROMs, while this generation uses Flash storage which defeats the purpose. There are two ways of warezing software on today's consoles:
- Drivechips, which modify/hack the drive's firmware to detect copies as originals. There is a large industry around these, and they are not what my argument was about. - Softmods, which either load warez from another location (USB) or simply change the way the console interprets what would normally be a non-game (writable) disc. These attack the system firmware (not the drive) and are used by the warez kids who are too cheap to get a modchip.
The drivechip industry has so far failed with the PS3 because it has a robust security system in place for the drive. Their loss. Not my point.
My comment was regarding system firmware hacking and, therefore, softmods, and the too-cheap-to-even-pay-for-the-ability-to-warez scene. These people are either a) the same people who hacked the system in the first place (i.e. people who willingly support both homebrew and warez) or b) clueless idiots who piggyback on homebrew efforts to develop (usually pretty crappy) piracy utilities. In the case of the Wii scene, the answer is B. I seem to recall that option A applies to the PSP scene, though someone might want to confirm that.
Big Piracy Tool Industry is interested in hardware modifications (drivechips), not system firmware exploits (which would involve no hardware whatsoever). Meanwhile, the people who are interested in homebrew already use Other OS. If Sony removes Other OS, then the homebrew enthusiasts will start applying more pressure onto the existing firmware security. And as soon as it cracks, the clueless warez kids will get their opportunity to write piracy utilities.
The Dell Inspiron 5000 already used the Mickey Mouse connector, and it's from way back in 2000/2001. I personally haven't a laptop that doesn't use this kind of connector.
The kind of people who want to tinker with their hardware out of passion would still push the envelope even if the Slim was Linux-friendly. People hack stuff that's completely open as well.
Ah, but there's a difference. With Other OS, people still want to hack out the GPU access restrictions (as has been done once or twice). With the facility removed entirely, people will attack the Native OS. Piracy shows up when you start messing with a console's native facilities, not a linux-specific mode that games can't run on anyway. I also learned this the hard way: software piracy on the Wii is possible (and popular) because we embraced the existing OS facilities and explored them, which then made it trivial for the warez kiddies to build launchers and whatnot. If we'd done something like BootMii to begin with (and ditched all of the existing proprietary code), they probably wouldn't have succeeded in creating piracy tools. (BootMii is a complete replacement of the Wii software starting at one of the early boot stages, including both the PowerPC code and the "security" ARM code).
Besides, I know a few hackers (including myself) who have chosen not to attack the PS3 because Sony actually made an effort to enable (some) open programming. People value the Other OS feature more than you'd think.
Sure, some people have been trying to hack the PS3 Native OS anyway already, but now you'll have a lot more people trying (those who wanted the Other OS feature as is, and those who were avoiding the PS3 due to Sony's attempt at being open).
Laptop power supplies rarely use "figure 8" connectors. Instead, most use "mickey mouse" connectors, which are similar but have an earth ground pin. The proper tems are IEC C7/C8 and IEC C5/C6, respectively, and your regular desktop power supply connector is IEC C13/C14 (there's two names for each connector, one for the male side and one for the female side).
- The PS3 slim will be hacked. Now that there is no Other OS support, there is the same incentive as there has been for running homebrew on every other console. - Said hacks will be used for warez, probably by people other than those who developed the hacks.
Linux hackers tend to be much more successful at system reverse engineering and exploitation than the kids who want warez. This is why Other OS is a Good Thing for Sony: it removes the incentive to bypass their security for a lot of people. By removing this option, they're setting themselves to have their security broken. And we all know how long it takes for "other" people to use these hacks for less than legal purposes (I learned this the hard way).
I firmly believe Other OS is one of the main reasons why there is no PS3 software piracy so far. Check out this table from our 25C3 presentation.
It doesn't. The network at HAR is isolated and only allowed internal calls (this is a requirement per the development license that was issued to them). However, I imagine you could do it through a VoIP provider given the right amount of code.
I'd be more worried about 'surprises' involving A5/1 cracking and the privacy implications. As they put it in the HAR talk, TCP/IP services have been analyzed all the way and back because anyone can get an Ethernet card, put it in promiscuous mode, and start sniffing/injecting packets. This hasn't been the case for GSM until recently. Nevermind that GSM is designed such that mobile equipment (cellphones) are authenticated, but networks aren't - you can set up a rogue network and any cell will happily connect to it automatically!
A5/1 has been shown to be vulnerable many years ago. There is now an A5/1 cracking project. If you have the resources (Nvidia CUDA graphics card) you should help them build rainbow tables, or just mirror the site and SVN in case bad things happen again like they have in the past (there's more than one government that would like to shut down such a project). A public demonstration of A5/1 cracking would do a lot towards debunking the myth of GSM security.
Free phone calls? I doubt people are *that* interested in them, nevermind that any issues people find are probably easily fixable at the operator's side anyway However, another issue that might arise is DoS attacks against cell networks. Apparently a lot of GSM expects the terminals to "play nice". Deliberately doing things outside the spec can cause an entire cell to deny service to all the other users.
Basically, GSM is a very large part security through obscurity these days, and its end security-wise is looming closer. Let's hope the newer standards (3G) have done things better.
The LGPL does require that you use dynamic linking, or that you offer the.o files to link to an alternative version of the LGPLed library. This is at least an annoyance for some uses, and a showstopper for others. For example, you can't use LGPLed code on proprietary closed systems like game consoles (the manufacturer wouldn't be very happy with a license that basically requires letting your users run arbitrary code on a closed and DRM'ed machine - not that I think such machines should be like that). I've seen lots of people miss this point though, I think quite a few people violate the LGPL on a regular basis by linking to an LGPLed library and failing to provide a way of relinking.
Another "interesting" point of the LGPL is that it effectively requires that the user be allowed to reverse engineer and modify a statically linked executable. That also goes against your typical EULA.
Personally, I think using LGPLed stuff in a proprietary application is a huge hassle and not worth it unless you fall into the specific case of being a dynamically linked userland application on a standard OS and the library is a dynamic object residing in a separate file.
The 8400GS is a great choice for a linux media center. I got an Asus EN8400GS Silent 512MB and highly recommend it. 512MB is required to decode some reference frame-heavy h.264, and the 512MB version seems to have a better heatsink (and it is, of course, fanless). There are also two versions of the 8400GS chip (one based on an older Gxx architecture - I forget the specific number), and the Asus card uses the newer one which has better VDPAU features.
Of note, although not advertised, the card does have an SPDIF header - so with a simple RCA to pin-header cable you can get HDMI audio out of it with any DVI->HDMI converter. I've been using this card to watch a lot of 1080p HDTV lately without any issues. If you're looking for a cheap Nvidia card to do 1080p h.264 decoding with VDPAU to an HDMI TV (with audio), it fits the bill perfectly.
Dated February 07, 2001. States that OpenOffice (its first release as open source) already uses the format and goes on to explain some of the XML used.
Slashdot Mirror
MS and Sony (and Nintendo) want you to use their respective online frameworks. They obviously aren't compatible or interoperable (different name/nick/whatever namespaces, different friends lists, different registration procedure, etc).
You can't have cross-platform online interoperation unless EA uses an entirely custom online framework that is identical among platforms. The console manufacturers wouldn't be too happy about that, and neither would gamers (who want to register once and maintain one friends list for all games, not once for each vendor or game).
The only sane solution would require heavy cooperation between all console vendors and standardizing quite a bit of the online experience, but that's never going to happen (at least not this generation).
Tell that to Nintendo, who thoughtfully decided not to implement WPA on the Nintendo DS. Even on the DSi WPA only works for DSi games (of which there are very few). It's ridiculous that WEP-only hardware is still being manufactured and sold to this day.
I doubt it. AES has been under attack ever since it showed up (that's the point). It's held up for 8 years so far and there are still no practical attacks, so it probably won't be practically broken for a long while.
There's a long road from the current attacks on AES to the practical exploitability of something like WEP. WPA TKIP is a hack on top of the WEP algorithm to let old devices get firmware updates to support WPA (it's really just WEP with different key mixing and some extra checks). It's never been a serious contender in my book, and it has already been deprecated for some time. Nothing more than a stopgap solution until devices with AES hardware showed up.
Timing buffered disk reads: 242 MB in 3.00 seconds = 80.65 MB/sec
And this is a *laptop* drive, and not a huge one at that (WD Scorpio Black 320 GB). Large desktop SATA drives average 100MB/s these days and can peak at over 120MB/s.
FAT*12* is still supported pretty much everywhere, and it's still in use for smallish SD cards and the like (~8MB). Not that I think the FAT variants are a great filesystem, but chances are you're going to be able to read them for many years. If you're concerned, stick a printout of the spec in there. FAT is simple enough to pick apart with a hex editor given some time, and it doesn't take very long to write a read-only implementation of it.
There's a big difference between broadcast networks and GSM. With GSM, networks can no doubt fix any loopholes soon after they are discovered.
Sure, of course people are interested in free phone calls, but what I mean is that I don't think it will be easy enough with GSM to make it worth their while.
Yes, older iMacs (see here).
Apple definitely likes C7/C8 for their smaller power supplies (laptop power supplies and stuff like iPod/iPhone chargers). However, the Mac Mini power brick and at least some iMacs use C5/C6.
My point is that if Other OS is gone then more people will try to hack it, and will succeed sooner.
Oh, and I forgot: homebrew/softmods rely on unsigned mode, while drivechips only require media detection trickery. This is why drivechip piracy existed on the Wii long before homebrew, and why getting a 360 to run pirated games is much easier than getting it to run homebrew. There is a huge technical split between drive modification-based piracy and firmware modifications (homebrew and softmod-based piracy) in this console generation.
Unfortunately, you're thoroughly confused. Modchips died with the last generation of consoles, there is no such thing any more. Modchips modify/replace system ROMs, while this generation uses Flash storage which defeats the purpose. There are two ways of warezing software on today's consoles:
- Drivechips, which modify/hack the drive's firmware to detect copies as originals. There is a large industry around these, and they are not what my argument was about.
- Softmods, which either load warez from another location (USB) or simply change the way the console interprets what would normally be a non-game (writable) disc. These attack the system firmware (not the drive) and are used by the warez kids who are too cheap to get a modchip.
The drivechip industry has so far failed with the PS3 because it has a robust security system in place for the drive. Their loss. Not my point.
My comment was regarding system firmware hacking and, therefore, softmods, and the too-cheap-to-even-pay-for-the-ability-to-warez scene. These people are either a) the same people who hacked the system in the first place (i.e. people who willingly support both homebrew and warez) or b) clueless idiots who piggyback on homebrew efforts to develop (usually pretty crappy) piracy utilities. In the case of the Wii scene, the answer is B. I seem to recall that option A applies to the PSP scene, though someone might want to confirm that.
Big Piracy Tool Industry is interested in hardware modifications (drivechips), not system firmware exploits (which would involve no hardware whatsoever). Meanwhile, the people who are interested in homebrew already use Other OS. If Sony removes Other OS, then the homebrew enthusiasts will start applying more pressure onto the existing firmware security. And as soon as it cracks, the clueless warez kids will get their opportunity to write piracy utilities.
The Dell Inspiron 5000 already used the Mickey Mouse connector, and it's from way back in 2000/2001. I personally haven't a laptop that doesn't use this kind of connector.
Ah, but there's a difference. With Other OS, people still want to hack out the GPU access restrictions (as has been done once or twice). With the facility removed entirely, people will attack the Native OS. Piracy shows up when you start messing with a console's native facilities, not a linux-specific mode that games can't run on anyway. I also learned this the hard way: software piracy on the Wii is possible (and popular) because we embraced the existing OS facilities and explored them, which then made it trivial for the warez kiddies to build launchers and whatnot. If we'd done something like BootMii to begin with (and ditched all of the existing proprietary code), they probably wouldn't have succeeded in creating piracy tools. (BootMii is a complete replacement of the Wii software starting at one of the early boot stages, including both the PowerPC code and the "security" ARM code).
Besides, I know a few hackers (including myself) who have chosen not to attack the PS3 because Sony actually made an effort to enable (some) open programming. People value the Other OS feature more than you'd think.
Sure, some people have been trying to hack the PS3 Native OS anyway already, but now you'll have a lot more people trying (those who wanted the Other OS feature as is, and those who were avoiding the PS3 due to Sony's attempt at being open).
Laptop power supplies rarely use "figure 8" connectors. Instead, most use "mickey mouse" connectors, which are similar but have an earth ground pin. The proper tems are IEC C7/C8 and IEC C5/C6, respectively, and your regular desktop power supply connector is IEC C13/C14 (there's two names for each connector, one for the male side and one for the female side).
My prediction:
- The PS3 slim will be hacked. Now that there is no Other OS support, there is the same incentive as there has been for running homebrew on every other console.
- Said hacks will be used for warez, probably by people other than those who developed the hacks.
Linux hackers tend to be much more successful at system reverse engineering and exploitation than the kids who want warez. This is why Other OS is a Good Thing for Sony: it removes the incentive to bypass their security for a lot of people. By removing this option, they're setting themselves to have their security broken. And we all know how long it takes for "other" people to use these hacks for less than legal purposes (I learned this the hard way).
I firmly believe Other OS is one of the main reasons why there is no PS3 software piracy so far. Check out this table from our 25C3 presentation.
I believe their license specified that the test network may not be connected to any public network (without regard for the method used, I assume).
The E1 link is between the BTSes and the Linux box, not between the Linux box and the rest of the PSTN (there is no such link).
It doesn't. The network at HAR is isolated and only allowed internal calls (this is a requirement per the development license that was issued to them). However, I imagine you could do it through a VoIP provider given the right amount of code.
I'd be more worried about 'surprises' involving A5/1 cracking and the privacy implications. As they put it in the HAR talk, TCP/IP services have been analyzed all the way and back because anyone can get an Ethernet card, put it in promiscuous mode, and start sniffing/injecting packets. This hasn't been the case for GSM until recently. Nevermind that GSM is designed such that mobile equipment (cellphones) are authenticated, but networks aren't - you can set up a rogue network and any cell will happily connect to it automatically!
A5/1 has been shown to be vulnerable many years ago. There is now an A5/1 cracking project. If you have the resources (Nvidia CUDA graphics card) you should help them build rainbow tables, or just mirror the site and SVN in case bad things happen again like they have in the past (there's more than one government that would like to shut down such a project). A public demonstration of A5/1 cracking would do a lot towards debunking the myth of GSM security.
Free phone calls? I doubt people are *that* interested in them, nevermind that any issues people find are probably easily fixable at the operator's side anyway However, another issue that might arise is DoS attacks against cell networks. Apparently a lot of GSM expects the terminals to "play nice". Deliberately doing things outside the spec can cause an entire cell to deny service to all the other users.
Basically, GSM is a very large part security through obscurity these days, and its end security-wise is looming closer. Let's hope the newer standards (3G) have done things better.
Not in Sweden. A friend of mine has 1gbps fiber municipal Internet at his house (previously 100mbps twisted pair).
The LGPL does require that you use dynamic linking, or that you offer the .o files to link to an alternative version of the LGPLed library. This is at least an annoyance for some uses, and a showstopper for others. For example, you can't use LGPLed code on proprietary closed systems like game consoles (the manufacturer wouldn't be very happy with a license that basically requires letting your users run arbitrary code on a closed and DRM'ed machine - not that I think such machines should be like that). I've seen lots of people miss this point though, I think quite a few people violate the LGPL on a regular basis by linking to an LGPLed library and failing to provide a way of relinking.
Another "interesting" point of the LGPL is that it effectively requires that the user be allowed to reverse engineer and modify a statically linked executable. That also goes against your typical EULA.
Personally, I think using LGPLed stuff in a proprietary application is a huge hassle and not worth it unless you fall into the specific case of being a dynamically linked userland application on a standard OS and the library is a dynamic object residing in a separate file.
The 8400GS is a great choice for a linux media center. I got an Asus EN8400GS Silent 512MB and highly recommend it. 512MB is required to decode some reference frame-heavy h.264, and the 512MB version seems to have a better heatsink (and it is, of course, fanless). There are also two versions of the 8400GS chip (one based on an older Gxx architecture - I forget the specific number), and the Asus card uses the newer one which has better VDPAU features.
Of note, although not advertised, the card does have an SPDIF header - so with a simple RCA to pin-header cable you can get HDMI audio out of it with any DVI->HDMI converter. I've been using this card to watch a lot of 1080p HDTV lately without any issues. If you're looking for a cheap Nvidia card to do 1080p h.264 decoding with VDPAU to an HDMI TV (with audio), it fits the bill perfectly.
How about something like this?
http://www.xml.com/pub/a/2001/02/07/openoffice.html
Dated February 07, 2001. States that OpenOffice (its first release as open source) already uses the format and goes on to explain some of the XML used.
ODF descended from the older OpenOffice/StarOffice file format ("OpenOffice.org XML"), which was already XML-based (it's very similar to ODF).
OpenOffice 1.0 used that format. It was released on May 1, 2002. Boom, obvious prior art.
Samna/Lotus Ami Pro used a text-based markup language for documents. It predated Word for Windows (aka Microsoft Word).