Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
PlayStation (Games) Games Hardware Linux

Gitbrew Releases OtherOS++ PS3 Linux Dual Boot 240

An anonymous reader writes "Gitbrew has proudly released otherOS++ Linux Dual Boot v1.0b1, enabling PS3 users to install an alternative OS to their console with full access to all system hardware, including all 8 CELL cores (making the PS3 the world's most affordable supercomputer). For more information check out the installation instructions and source code."
This discussion has been archived. No new comments can be posted.

Gitbrew Releases OtherOS++ PS3 Linux Dual Boot

Comments Filter:
  • Re:Benchmarks! (Score:5, Informative)

    by houstonbofh ( 602064 ) on Thursday May 05, 2011 @07:59AM (#36033712)
    Sounds right. Until you think again. There was a second rootkit with the microvault thumb drive and they were another division as well. (Why do people keep forgetting this one?) Then the subpoenas of people who visited a web site, or watched a video, which was still yet another division. Sony sees the customer as the enemy. I do not want to do business with my enemy.
  • by neokushan ( 932374 ) on Thursday May 05, 2011 @09:52AM (#36034568)

    Why don't you check YOUR facts?
    Sony had already released the PS3 Slims WITHOUT OtherOS support when Geohot decided to take a look. Sure, he used OtherOS as the attack vector, but surely that just points out that removing OtherOS wouldn't accomplish anything as the hackers can just not update and continue exploring?

    Furthermore, the actual "hack" was nontrivial - it invovled a bit of soldering and require precise timing. Because of this, it wasn't easy to pull off and worked maybe 1/3 of the time. Not only that, but it wasn't even remotely permanent and it couldn't be used for piracy or anything. In fact, interest in this hack was more or less gone by the time OtherOS was removed, if Sony had just ignored it until there was actually an issue, then it would have just went away. But then again, Maybe Sony realised how weak their security was.

  • by Rogerborg ( 306625 ) on Thursday May 05, 2011 @10:11AM (#36034766) Homepage

    nobody needs OtherOS, it's just a excuse to enabling piracy

    The United States Air Force [physorg.com] are "nobody"? ZOMG teh USAF r haxxor u gays uze aimbotz!!!!!!!eleven!!!!

  • Re:Benchmarks! (Score:3, Informative)

    by mcgrew ( 92797 ) * on Thursday May 05, 2011 @10:42AM (#36035180) Homepage Journal

    I doubt a fanboy would say "If Sony do keep shitting all over us". A fanboy wouldn't even notice he was knee deep in manure.

  • by dvdkhlng ( 1803364 ) on Thursday May 05, 2011 @10:46AM (#36035236)

    The best they claim is 25.6 GFLOPS per cell in theoretical performance, so 205 GFLOPS is the best you theoretically get, if there are no bandwidth constraints (which there are on a PS3) for single precision math. Ok well testing my actual Radeon 5870, I get 800 GFLOPS for single precision, 227 for double precision. That is an actual benchmark of the card running on my desktop.

    As somebody who programmed Cell CPUs for signal processing (including to, but not limited to PS3s), let me tell you that the PS3's memory bandwidth is so close to unlimited, that you usually don't have to think about it. At least as long as you move data only on the Element Interconnect Bus, between the 256KB local SRAMs of each CELL core, which is sufficient for most of what I did. It moves up to 200 giga bytes per second, maximum 16 bytes per 2 cycles in and out per core. The DMA engines that do those transfer have their own 1024bit (!) read/write port into the SRAM, so they burst 128 bytes per cycle into the SRAM, and don't have to steel many RAM cycles. The wikidedia article has more details.

    In my experience, you can usually come pretty close to the 200 GFLOP/s of the Cell-CPU. When relying on C-Compiler with SIMD intrinsics, you usually manage 100 GPFOP/s for algorithms that have as many read/write opcodes as arithmetic opcodes. Smaller problems can mostly be handled on registers only (per CPU we have 128 16-byte registers!) and will run even faster.

    Also note that many algorithms nowadays are not bandwidth but memory latency limited. Having the Cell's per-core DMA engines do background transfers to large local S-RAMs, mostly eliminates these latency problems and is much cleaner than relying on CPU caches guessing what parts of RAM to prefetch next. BTW these are user-space DMA engines that undergo page translation and are fully compatible to unix vm concepts. Still programming directly accesses DMA registers and doesn't need any kernel calls.

    Try to do that with your GPU!

To the systems programmer, users and applications serve only to provide a test load.

Working...