Well, I have worked in the "security industry" here in NYC, quite a lot making secure banking/brokerage/insurance infosystems during the late 1990s, and helping the NYC legislature's tech policymaking committee oversee secure NYC's IT (both government and its neighbors in the Financial District). I know quite a lot about both secure technology and government security operations.
The FBI isn't nearly interested enough in these frauds. Despite how hard it is to find and bring these criminals to justice, that's the FBI's job, and it's good at it when it makes it a priority. Instead, under Bush, the priority has been "terrorism", which has been a cover for all kinds of wasted effort that hasn't secured us, but did help Bush keep going for 8 years. Even Bush's "CyberTerrorism Czars" have all quit in disgust, and Bush hasn't put a credible sheriff in charge of controlling this massive criminal activity.
There's a lot more ID theft and fraud in the past 8 years than when Clinton was president in the late 20th Century. It's like the presidents of the 1920s didn't make the FBI all use or at least understand automobiles, when they became a common tool for crimes, especially in escaping local jurisdictions.
So you can take your vague Bush apologies and dump them on that pile of crap you call "not much caring for the guy, either". The fact is that you voted for him twice, you and your Republican buddies are responsible for our lawless crises, and you have no credibility to bleat about how "this is hard work" like you do when Bush clears brush while the country gets looted. Your Bushy trolls are worse than worthless. You Republicans just aren't up to the job of securing anything, as much as you're constantly whining about how scary the bad guys are.
And stop whining to the mods, who apparently aren't stuck in the kind of Bushy denial you're stuck in.
I hate giving my PIN to vendors. I hate typing my PIN on random ATMs - and rarely do it. I hate typing my PIN into authorization keypads at stores, but what can I do?
Every transaction should have its own unique PIN attached to the transaction's amount and recipient. Credit cards with chips could do this right now, RSA-password style, generated against the one-time password from the vendor's machine for the transaction, in a data package with the vendor's invoice signed by the vendor's transaction password that my card keeps. In fact it should be transacted over my phone and archived in my personal DB.
This tech is here, and pretty cheap. Banks should pay for it. Their insurance corps should make them pay for it. Until they do, consumers like us will pay most of the costs, especially in a lifetime recovering from a "one-time" ID theft.
The FBI is in charge of protecting Americans from fraud and theft on that scale and across that national and global jurisdiction. But Bush's "Justice" Department isn't interested.
Face recognition is still too inaccurate for me to trust. Fingerprint recognition is also too inaccurate for me to trust. But the combination might increase ID precision so it's trustworthy in distinguishing me from 6-10 billion who aren't me. Like how 2 redundant cheap failurepoints can turn 99.9% (8.76 hours down per year) uptime into 99.9999% (31.57 seconds down per year).
But each/both of them are crackable if I'm coerced to login, perhaps even if my dead body is forced up against my ATM. (I know I wouldn't care by that point, but the utility of that crack is incentive to kill me.) Or if someone wears a masks (on face and fingertips) imprinted from video and surfaces recording my prior, unwitting presence somewhere.
The third factor would be voice recognition. It doesn't have to get the exact words correct; in fact it's better if it just recognizes the result among a few categories by what I'm saying: "unlock", or "PANIC" or "ignore this". That way if I'm coerced, I can signal for help without alerting the coercers, who won't know that "rosebud" means "PANIC". And if I'm dead, I can't say anything, so I'm no good to the coercers.
These ID technologies still won't work to find someone who isn't cooperating with the authenticator, like growing a beard (or wearing a mask), until every single person must be positively ID'ed all the time everywhere, just to spot the tiny few of interest. But when I'm trying to unlock something, and all I can remember is that I'm me, and I don't want to be chained to some hardware key that I won't have if I give it to someone, and can be duplicated by someone I don't authorize, they might be a lot better than a password (or a list of them).
No they're not - not immersed tube tunnels: just prefab segments floated out to the right spot, sunk to the bottom, then welded into place and unsealed against the existing tunnel. Not compared to drilling them through land. Not compared to the cost of the real estate and rights of way, and the disruption of the transit all along their construction route, especially though the cities they server. Especially throughout the busy corridors we're talking about uncongesting, like DC/NYC/Boston.
For long distances, the archimedes bridge design is cheap and effective, though it would require building further out from shore, lengthening the route, and still have to sit on or in the bottom when making land at the stations.
And all of it is cheaper than the alternative of clogging highways with cars, which then get under 20MPG, pumping pollution and hitting each other, while leaving road capacity unused just to compensate for human driving imprecision. And the alternative costs of adding so much more highway capacity.
I don't see why the wires have to appear at all. The tube train I propose is submerged under water, for cheapness/ease of construction on easily obtained rights of way, with little to no disruption of the areas it passes through (except a handful of terminals, which should use existing port or rail terminal infrastructure for intermodal transfer). All the wires should pass through the tube. In fact, the tube's capacity for long haul cables could be leased to network providers for even quicker payback (and eventual reduced train fares).
These tubes would have an express and a local track, which would also serve as maintenance, with "sidings" at the terminals. Perhaps with a few maintenance terminals along the way, as actual engineering requires, maybe in conjunction with ventilation/pressurization nodes and/or power plants, depending on the specific technologies employed. There might even be a case for hydropower using currents and tides in the waterways in which the tube runs. That infrastructure could deliver quite a lot of longterm benefits beyond transportation, especially as development fills in the corridor spreading between the stations, just as it already did with the rivers/canals, roads and indeed original railways between those points.
If the Feds and the states (NY is the obvious one) funded a $100B investment (about 9 months of the Iraq War) in this rail, using only US contractors employing permanent residents, prioritizing employment of people who've lived along the route for at least 5-10 years, the payoff in economic development would be vast. The Springfield Interchange outside DC carries over 430,000 vehicles per day alone; there's got to be at least 5-10 million vehicles a day on these routes (all of which seem to pass through NYC:). $100B is only 10,000x that amount, or something like 300 years at $1:vehicle:day. At an average $10, that is only a 30 year payback, for about 40 miles cost of gasoline. The current cost of a 150 mile drive between consecutive stations, including gas and tolls, is at least $35, so such a project could pay back in something like a decade or two, including cost overruns and deluxe features. Since it would probably take about 5-10 years to complete any segment (which should all be built in parallel, or at least several connecting segments like Philly/NYC, NYC / New London, NYC/Kingston), that means payback is on the timescale of construction, which is a perfectly reasonable investment term. When considering the payoff in energy, pollution, productive time, safety, employment, and all the saved expenses and increased taxes from that cleaned up transit, this is probably the best investment we could make outside healthcare and education.
We should make the Feds build a "car train" that people drive their cars onto at stations in Boston, NYC, DC, Albany, Buffalo and Champlain (NY, across the border from Montreal). We should put the train in a tube under the water in the Atlantic, Hudson/Champlain, Delaware/Chesapeake and Erie canal, which won't need rights of way or disruptive construction schedules. Linking together the Midatlantic, New England and Canadian transit points that carry so much of America's (and the world's) traffic.
There's a vast swarm of traffic on the highways (I-95, I-87 and I-90) that runs basically between those cities (really including Toronto and Montreal), pumping pollution and chewing up gas all along the way. Make stops at one point between each terminal and it will carry lots of subregional traffic, too. If the train goes 300MPH, the speed up/down between the stops would make NYC/DC a reliabe 90 minute trip, with a station between Philly and Wilmington only 45 minutes away. DC to Toronto only 4 hours, and you can drive off (or drive on) anywhere in the 5 stops between.
Fast, reliable, safe. Because the train's energy can be generated at large power plants near fuel ports and scrubbed centrally, energy efficient and much cleaner. These routes could haul cargo trailers most of the time, when not full of passenger/car trains.
The increased efficiency (in time, energy any pollution) should pay for the construction within a reasonable span of years, probably not much longer than the time to construct (which should happen simultaneously between the cities).
Or, we can leave the Northeast in the 20th Century, while the rest of the world passes us by.
Of course it is. These cablecos and telcos care most (and in fact, care only) about one thing: preserving their monopolies, or at worst, keeping their cartel defended against any new entrant, especially ones who aren't $billion network corporations, which have similar $billion interests and agendas.
A horde of independent YouTubers, whether at some new Google operation like YouTube or millions of independent video websites or P2P sessions, is a nightmare for them. Because they all want a free ride on the networks that have always been kicked off and subsidized by investments by the people, through the government, removing any risk. That's what they've always gotten, and that's what they demand.
They should just build out more capacity, instead of the more expensive and less effective content filtering. Then they'd have a lot more product to sell, even if they didn't control the market for it.
That note is describing constraints on the frame buffer as RAM hack that they've been working on, to use the framebuffer VRAM as extra app/OS RAM with some buffer overflow tricks through a cracked API. The constraints don't constrain the spu-medialib video driver, AFAIK.
I can tell you that 1080p/30fps (or maybe faster) looks sweet over HDMI from my PS3 to my 50" DLP.
The weakest possible use case I could think of for a PS3 right now is as a database server. It's got 256MB RAM for everything, including the OS, apps and data. DBs haven't been recoded to use the Cell's DSPs, and might not be for a long long time. And you'd be ignoring all the multimedia HW that the PS3 does offer.
For $400, nearly any i386/compatible PC will make a much better DB server than a PS3.
Actually, spu-medialib is a driver for ffmpeg, which lets MPlayer and other video apps (including, I think, vlc) do HD 1080p playback, and the X driver is of course even more general purpose.
What's the problem with the framebuffer -> HDMI? And what's stopping someone from adding codecs to the spu-medialib driver? What's stopping you from helping make the PS3 what you want it to be?
I'm going to repeat this one more time. Sony has been supporting Linux with continuous updates (including firmware support) for 2 years, and shows every indication that Linux is an essential part of its platform strategy. That is entirely different from "doing one little thing for the community".
This platform isn't about hating or loving Sony. It's about a clearly viable, officially supported Sony platform that's been steadily improving with Sony's help for the 2 years since it was released (just like Sony had announced for at least a year before that).
And as for adding memory or memory expansion in a future version, there's no reason why that would be "a whole new console", other than the memory - unless Sony wanted to change something else at that time. If you're really as eager a collector of these consoles as you say, you must know that the PS3 was released as more of a "final beta", with several HW upgrades already (mostly economic, like dropping PS1 & PS2 HW in favor of SW emulation).
And if you read all the answers on the Web, you'd have seen in this Slashdot story where I already described a way to get more RAM, either by Flash or even a SATA external i-RAM bank.
That's enough repetition from me. I use computers to do that.
Well, the best model right now is PS3 as a stream processor for tasks that require 200FLOPS:byte, and which benefit from HDMI display. PS3 as a media terminal for a PC server infrastructure is a good use case, especially with the introduction of the HES-V1000 media server, which itself looks like a PS3 turned into a server (to the network as well as to non-network multimedia appliances like TVs and stereos).
Would you like to spec out a $400 PC with 1080p HDMI and 7.1 analog + optical digital outputs, Gb-e, WiFi, Blu-Ray and a Bluetooth remote? With the PiP and other video effects that the PS3 will do as SW is written for it, like the X/MPlayer drivers already in late beta?
But you're saying that because you refuse to listen to what's wrong with your take on things. The PS3 isn't just "new", it's been out for 2 years, and Linux is proven an important official strategy by Sony. That's totally different from the Dreamcast, or PS2/Linux scenarios, as has been amply discussed in these threads.
And because you somehow think that the people who would develop PS3 Linux are at all the same people who then wouldn't develop Wine. They're not. Wine development isn't going to suffer any brain drain.
I don't know what you mean by "the memory of the PS3 becomes obsolete", but I do expect that soon enough (probably next year) Sony will release a PS3 with either more RAM, or expandable RAM. Because Sony is just getting around to supporting Sony Home and other Internet content/community apps, which will require more RAM.
But until then, the current PS3 HW is entirely suitable for an extraordinary media terminal running Linux. 256MB RAM is plenty for running multimedia apps that stream all their data from the network, which is clearly Sony's strategy for home entertainment (whether Linux or not), like DLNA.
I think that as long as you're questioning the platform, you should listen to the answers.
I think that the XMB itself is probably running on a Linux kernel. I don't know about the GameOS that the actual games run on, which might be something else entirely. But the OS the PS3 boots into that lets you choose games, surf the Web, and runs as a home media center shows all the signs of running under embedded Linux.
Sony has just released the HES-V1000, an embedded home media server (with 200-disc jukebox, BD, HD PVR, HD video/audio outs, ethernet) that is said to run embedded Linux. It's pretty new, but I'm waiting to see if someone can hack a Linux root (remote) shell into it.
Actually, that status is quite old. The drivers aren't finished, but they're more finished than that site (and others linked from it) suggest. The devs have moved to mainly IRC and a new CVS, because there is only a small group (hard) at work on the project. If there are more devs helping (c'mon, Slashdot!) then they'll publish a new formal release and the "bugs" (like other formats) will die off like any other FOSS project.
PS3 SATA appears to be only 1.5TB (SATA I), which is of course much slower than PS3 XDR main memory, and glacial compared to DMA on the Cell, which has (and depends on) onchip local storage in each SPE.
So the malloc() patches necessary are a lot more than I describe. But relying on swap across SATA means swapping the XDR data out across SATA to i-RAM, and i-RAM data back to XDR every time. That's going to suck compared to just addressing the i-RAM directly (1 SATA transit).
The real memory architecture is probably a series of SW caches, from SPU local to XDR via Cell DMA, then i-RAM "extended memory", with apps able to fetch specific data from a pointer that points at either the faster cache or the more latent storage. It's a pretty serious algorithm to keep several tiers of demand-degree in the right proximity cache, as well as the tag structure, but it would make the machine a very serious beast for the $400 price. The alternative is for each app to code directly in its own demand terms to each of those increasingly latent storage address ranges, but since i-RAM isn't standard, that's asking a lot. The right way is to somehow map these differently performant storage ranges into a kernel memory driver, for all apps to use transparently, some more effectively (when they map to the optimization strategy), but all with the RAM limit removed (or moved to a much higher limit, of the i-RAM capacity).
Does you Dell's HW play PS3 games right out of the box, as well as running Linux? Because that's what we're talking about (in reverse).
If you look at the dates of the old posts, you'll see that they're old. Look at some of the other posts in this thread to see that those problems are gone. There are still some problems left, but this is FOSS, so it's more productive to help than just to complain.
Dreamcast Linux wasn't officially supported by Sega, but Linux on PS3 is supported (and advertised) by Sony. In fact Linux seems to be an embedded OS that Sony's current generation is using to make all this PS3 and related gear into their home entertainment network. It's not going away, it's in its 2nd or 3rd generation on PS3, and PS3 itself is just at the start of at least a decade of being Sony's "current generation".
What matters most is whether the Linux community stays working on improving the Linux implementation. Which is how Linux works on any platform. Lend a hand!
The nVidia GPU is still mostly locked out of Linux, except for audio and framebuffer functions. There are some projects that are hacking the GPU to get at its OpenGL implementation (2D/3D), but Sony seems to be actively patching their successful hacks. However, there is also now a ball rolling on porting video to the Cell's SPEs, which is already playing HD video. It's part of a general purpose SPE framework the community has put together. Other people are working on porting OpenGL directly to the SPEs.
So 3D currently runs slowly on the PPC core, but the projects for fast 3D are promising. And they need your help.
That would be great. But meanwhile, people have had success using FlashROM drives in the USB ports mapped as swap. So I expect that mounting a SATA i-RAM drive as swap would work even better. If someone hacked malloc() to use that i-RAM over SATA as actual pageable memory, not just swap (with all its overhead, like swapping:), the RAM problems might be solvable.
Slashdot Mirror
Well, I have worked in the "security industry" here in NYC, quite a lot making secure banking/brokerage/insurance infosystems during the late 1990s, and helping the NYC legislature's tech policymaking committee oversee secure NYC's IT (both government and its neighbors in the Financial District). I know quite a lot about both secure technology and government security operations.
The FBI isn't nearly interested enough in these frauds. Despite how hard it is to find and bring these criminals to justice, that's the FBI's job, and it's good at it when it makes it a priority. Instead, under Bush, the priority has been "terrorism", which has been a cover for all kinds of wasted effort that hasn't secured us, but did help Bush keep going for 8 years. Even Bush's "CyberTerrorism Czars" have all quit in disgust, and Bush hasn't put a credible sheriff in charge of controlling this massive criminal activity.
There's a lot more ID theft and fraud in the past 8 years than when Clinton was president in the late 20th Century. It's like the presidents of the 1920s didn't make the FBI all use or at least understand automobiles, when they became a common tool for crimes, especially in escaping local jurisdictions.
So you can take your vague Bush apologies and dump them on that pile of crap you call "not much caring for the guy, either". The fact is that you voted for him twice , you and your Republican buddies are responsible for our lawless crises, and you have no credibility to bleat about how "this is hard work" like you do when Bush clears brush while the country gets looted. Your Bushy trolls are worse than worthless. You Republicans just aren't up to the job of securing anything, as much as you're constantly whining about how scary the bad guys are.
And stop whining to the mods, who apparently aren't stuck in the kind of Bushy denial you're stuck in.
I hate giving my PIN to vendors. I hate typing my PIN on random ATMs - and rarely do it. I hate typing my PIN into authorization keypads at stores, but what can I do?
Every transaction should have its own unique PIN attached to the transaction's amount and recipient. Credit cards with chips could do this right now, RSA-password style, generated against the one-time password from the vendor's machine for the transaction, in a data package with the vendor's invoice signed by the vendor's transaction password that my card keeps. In fact it should be transacted over my phone and archived in my personal DB.
This tech is here, and pretty cheap. Banks should pay for it. Their insurance corps should make them pay for it. Until they do, consumers like us will pay most of the costs, especially in a lifetime recovering from a "one-time" ID theft.
The FBI is in charge of protecting Americans from fraud and theft on that scale and across that national and global jurisdiction. But Bush's "Justice" Department isn't interested.
Feel safer?
Face recognition is still too inaccurate for me to trust. Fingerprint recognition is also too inaccurate for me to trust. But the combination might increase ID precision so it's trustworthy in distinguishing me from 6-10 billion who aren't me. Like how 2 redundant cheap failurepoints can turn 99.9% (8.76 hours down per year) uptime into 99.9999% (31.57 seconds down per year).
But each/both of them are crackable if I'm coerced to login, perhaps even if my dead body is forced up against my ATM. (I know I wouldn't care by that point, but the utility of that crack is incentive to kill me.) Or if someone wears a masks (on face and fingertips) imprinted from video and surfaces recording my prior, unwitting presence somewhere.
The third factor would be voice recognition. It doesn't have to get the exact words correct; in fact it's better if it just recognizes the result among a few categories by what I'm saying: "unlock", or "PANIC" or "ignore this". That way if I'm coerced, I can signal for help without alerting the coercers, who won't know that "rosebud" means "PANIC". And if I'm dead, I can't say anything, so I'm no good to the coercers.
These ID technologies still won't work to find someone who isn't cooperating with the authenticator, like growing a beard (or wearing a mask), until every single person must be positively ID'ed all the time everywhere, just to spot the tiny few of interest. But when I'm trying to unlock something, and all I can remember is that I'm me, and I don't want to be chained to some hardware key that I won't have if I give it to someone, and can be duplicated by someone I don't authorize, they might be a lot better than a password (or a list of them).
IRC #ps3dev, #ps3linux and #spu-medialib on Freenode. CVS (when it's ready) at http://git.spu-medialib.org/ .
No they're not - not immersed tube tunnels: just prefab segments floated out to the right spot, sunk to the bottom, then welded into place and unsealed against the existing tunnel. Not compared to drilling them through land. Not compared to the cost of the real estate and rights of way, and the disruption of the transit all along their construction route, especially though the cities they server. Especially throughout the busy corridors we're talking about uncongesting, like DC/NYC/Boston.
For long distances, the archimedes bridge design is cheap and effective, though it would require building further out from shore, lengthening the route, and still have to sit on or in the bottom when making land at the stations.
And all of it is cheaper than the alternative of clogging highways with cars, which then get under 20MPG, pumping pollution and hitting each other, while leaving road capacity unused just to compensate for human driving imprecision. And the alternative costs of adding so much more highway capacity.
I don't see why the wires have to appear at all. The tube train I propose is submerged under water, for cheapness/ease of construction on easily obtained rights of way, with little to no disruption of the areas it passes through (except a handful of terminals, which should use existing port or rail terminal infrastructure for intermodal transfer). All the wires should pass through the tube. In fact, the tube's capacity for long haul cables could be leased to network providers for even quicker payback (and eventual reduced train fares).
:). $100B is only 10,000x that amount, or something like 300 years at $1:vehicle:day. At an average $10, that is only a 30 year payback, for about 40 miles cost of gasoline. The current cost of a 150 mile drive between consecutive stations, including gas and tolls, is at least $35, so such a project could pay back in something like a decade or two, including cost overruns and deluxe features. Since it would probably take about 5-10 years to complete any segment (which should all be built in parallel, or at least several connecting segments like Philly/NYC, NYC / New London, NYC/Kingston), that means payback is on the timescale of construction, which is a perfectly reasonable investment term. When considering the payoff in energy, pollution, productive time, safety, employment, and all the saved expenses and increased taxes from that cleaned up transit, this is probably the best investment we could make outside healthcare and education.
These tubes would have an express and a local track, which would also serve as maintenance, with "sidings" at the terminals. Perhaps with a few maintenance terminals along the way, as actual engineering requires, maybe in conjunction with ventilation/pressurization nodes and/or power plants, depending on the specific technologies employed. There might even be a case for hydropower using currents and tides in the waterways in which the tube runs. That infrastructure could deliver quite a lot of longterm benefits beyond transportation, especially as development fills in the corridor spreading between the stations, just as it already did with the rivers/canals, roads and indeed original railways between those points.
If the Feds and the states (NY is the obvious one) funded a $100B investment (about 9 months of the Iraq War) in this rail, using only US contractors employing permanent residents, prioritizing employment of people who've lived along the route for at least 5-10 years, the payoff in economic development would be vast. The Springfield Interchange outside DC carries over 430,000 vehicles per day alone; there's got to be at least 5-10 million vehicles a day on these routes (all of which seem to pass through NYC
We should make the Feds build a "car train" that people drive their cars onto at stations in Boston, NYC, DC, Albany, Buffalo and Champlain (NY, across the border from Montreal). We should put the train in a tube under the water in the Atlantic, Hudson/Champlain, Delaware/Chesapeake and Erie canal, which won't need rights of way or disruptive construction schedules. Linking together the Midatlantic, New England and Canadian transit points that carry so much of America's (and the world's) traffic.
There's a vast swarm of traffic on the highways (I-95, I-87 and I-90) that runs basically between those cities (really including Toronto and Montreal), pumping pollution and chewing up gas all along the way. Make stops at one point between each terminal and it will carry lots of subregional traffic, too. If the train goes 300MPH, the speed up/down between the stops would make NYC/DC a reliabe 90 minute trip, with a station between Philly and Wilmington only 45 minutes away. DC to Toronto only 4 hours, and you can drive off (or drive on) anywhere in the 5 stops between.
Fast, reliable, safe. Because the train's energy can be generated at large power plants near fuel ports and scrubbed centrally, energy efficient and much cleaner. These routes could haul cargo trailers most of the time, when not full of passenger/car trains.
The increased efficiency (in time, energy any pollution) should pay for the construction within a reasonable span of years, probably not much longer than the time to construct (which should happen simultaneously between the cities).
Or, we can leave the Northeast in the 20th Century, while the rest of the world passes us by.
Of course it is. These cablecos and telcos care most (and in fact, care only) about one thing: preserving their monopolies, or at worst, keeping their cartel defended against any new entrant, especially ones who aren't $billion network corporations, which have similar $billion interests and agendas.
A horde of independent YouTubers, whether at some new Google operation like YouTube or millions of independent video websites or P2P sessions, is a nightmare for them. Because they all want a free ride on the networks that have always been kicked off and subsidized by investments by the people, through the government, removing any risk. That's what they've always gotten, and that's what they demand.
They should just build out more capacity, instead of the more expensive and less effective content filtering. Then they'd have a lot more product to sell, even if they didn't control the market for it.
That note is describing constraints on the frame buffer as RAM hack that they've been working on, to use the framebuffer VRAM as extra app/OS RAM with some buffer overflow tricks through a cracked API. The constraints don't constrain the spu-medialib video driver, AFAIK.
I can tell you that 1080p/30fps (or maybe faster) looks sweet over HDMI from my PS3 to my 50" DLP.
The weakest possible use case I could think of for a PS3 right now is as a database server. It's got 256MB RAM for everything, including the OS, apps and data. DBs haven't been recoded to use the Cell's DSPs, and might not be for a long long time. And you'd be ignoring all the multimedia HW that the PS3 does offer.
For $400, nearly any i386/compatible PC will make a much better DB server than a PS3.
Actually, spu-medialib is a driver for ffmpeg, which lets MPlayer and other video apps (including, I think, vlc) do HD 1080p playback, and the X driver is of course even more general purpose.
What's the problem with the framebuffer -> HDMI? And what's stopping someone from adding codecs to the spu-medialib driver? What's stopping you from helping make the PS3 what you want it to be?
I'm going to repeat this one more time. Sony has been supporting Linux with continuous updates (including firmware support) for 2 years, and shows every indication that Linux is an essential part of its platform strategy. That is entirely different from "doing one little thing for the community".
This platform isn't about hating or loving Sony. It's about a clearly viable, officially supported Sony platform that's been steadily improving with Sony's help for the 2 years since it was released (just like Sony had announced for at least a year before that).
And as for adding memory or memory expansion in a future version, there's no reason why that would be "a whole new console", other than the memory - unless Sony wanted to change something else at that time. If you're really as eager a collector of these consoles as you say, you must know that the PS3 was released as more of a "final beta", with several HW upgrades already (mostly economic, like dropping PS1 & PS2 HW in favor of SW emulation).
And if you read all the answers on the Web, you'd have seen in this Slashdot story where I already described a way to get more RAM, either by Flash or even a SATA external i-RAM bank.
That's enough repetition from me. I use computers to do that.
Actually, I think the LinuxMCE project is better suited to using PS3s as "Media Directors" (media terminals).
Well, the best model right now is PS3 as a stream processor for tasks that require 200FLOPS:byte, and which benefit from HDMI display. PS3 as a media terminal for a PC server infrastructure is a good use case, especially with the introduction of the HES-V1000 media server, which itself looks like a PS3 turned into a server (to the network as well as to non-network multimedia appliances like TVs and stereos).
Would you like to spec out a $400 PC with 1080p HDMI and 7.1 analog + optical digital outputs, Gb-e, WiFi, Blu-Ray and a Bluetooth remote? With the PiP and other video effects that the PS3 will do as SW is written for it, like the X/MPlayer drivers already in late beta?
But you're saying that because you refuse to listen to what's wrong with your take on things. The PS3 isn't just "new", it's been out for 2 years, and Linux is proven an important official strategy by Sony. That's totally different from the Dreamcast, or PS2/Linux scenarios, as has been amply discussed in these threads.
And because you somehow think that the people who would develop PS3 Linux are at all the same people who then wouldn't develop Wine. They're not. Wine development isn't going to suffer any brain drain.
I don't know what you mean by "the memory of the PS3 becomes obsolete", but I do expect that soon enough (probably next year) Sony will release a PS3 with either more RAM, or expandable RAM. Because Sony is just getting around to supporting Sony Home and other Internet content/community apps, which will require more RAM.
But until then, the current PS3 HW is entirely suitable for an extraordinary media terminal running Linux. 256MB RAM is plenty for running multimedia apps that stream all their data from the network, which is clearly Sony's strategy for home entertainment (whether Linux or not), like DLNA.
I think that as long as you're questioning the platform, you should listen to the answers.
It's open source, and an ongoing project. Don't just complain - test and patch it!
I don't know about your Xbox1/XMBC, but my PS3/Ubuntu plays 1080p MPG4s quite beautifully on my 50" HDMI DLP.
I think that the XMB itself is probably running on a Linux kernel. I don't know about the GameOS that the actual games run on, which might be something else entirely. But the OS the PS3 boots into that lets you choose games, surf the Web, and runs as a home media center shows all the signs of running under embedded Linux.
Sony has just released the HES-V1000, an embedded home media server (with 200-disc jukebox, BD, HD PVR, HD video/audio outs, ethernet) that is said to run embedded Linux. It's pretty new, but I'm waiting to see if someone can hack a Linux root (remote) shell into it.
Actually, that status is quite old. The drivers aren't finished, but they're more finished than that site (and others linked from it) suggest. The devs have moved to mainly IRC and a new CVS, because there is only a small group (hard) at work on the project. If there are more devs helping (c'mon, Slashdot!) then they'll publish a new formal release and the "bugs" (like other formats) will die off like any other FOSS project.
PS3 SATA appears to be only 1.5TB (SATA I), which is of course much slower than PS3 XDR main memory, and glacial compared to DMA on the Cell, which has (and depends on) onchip local storage in each SPE.
So the malloc() patches necessary are a lot more than I describe. But relying on swap across SATA means swapping the XDR data out across SATA to i-RAM, and i-RAM data back to XDR every time. That's going to suck compared to just addressing the i-RAM directly (1 SATA transit).
The real memory architecture is probably a series of SW caches, from SPU local to XDR via Cell DMA, then i-RAM "extended memory", with apps able to fetch specific data from a pointer that points at either the faster cache or the more latent storage. It's a pretty serious algorithm to keep several tiers of demand-degree in the right proximity cache, as well as the tag structure, but it would make the machine a very serious beast for the $400 price. The alternative is for each app to code directly in its own demand terms to each of those increasingly latent storage address ranges, but since i-RAM isn't standard, that's asking a lot. The right way is to somehow map these differently performant storage ranges into a kernel memory driver, for all apps to use transparently, some more effectively (when they map to the optimization strategy), but all with the RAM limit removed (or moved to a much higher limit, of the i-RAM capacity).
Does you Dell's HW play PS3 games right out of the box, as well as running Linux? Because that's what we're talking about (in reverse).
If you look at the dates of the old posts, you'll see that they're old. Look at some of the other posts in this thread to see that those problems are gone. There are still some problems left, but this is FOSS, so it's more productive to help than just to complain.
Dreamcast Linux wasn't officially supported by Sega, but Linux on PS3 is supported (and advertised) by Sony. In fact Linux seems to be an embedded OS that Sony's current generation is using to make all this PS3 and related gear into their home entertainment network. It's not going away, it's in its 2nd or 3rd generation on PS3, and PS3 itself is just at the start of at least a decade of being Sony's "current generation".
What matters most is whether the Linux community stays working on improving the Linux implementation. Which is how Linux works on any platform. Lend a hand!
The nVidia GPU is still mostly locked out of Linux, except for audio and framebuffer functions. There are some projects that are hacking the GPU to get at its OpenGL implementation (2D/3D), but Sony seems to be actively patching their successful hacks. However, there is also now a ball rolling on porting video to the Cell's SPEs, which is already playing HD video. It's part of a general purpose SPE framework the community has put together. Other people are working on porting OpenGL directly to the SPEs.
So 3D currently runs slowly on the PPC core, but the projects for fast 3D are promising. And they need your help.
That would be great. But meanwhile, people have had success using FlashROM drives in the USB ports mapped as swap. So I expect that mounting a SATA i-RAM drive as swap would work even better. If someone hacked malloc() to use that i-RAM over SATA as actual pageable memory, not just swap (with all its overhead, like swapping :), the RAM problems might be solvable.
There is already X/MPlayer video acceleration on the Cell's HW.
Yes, the X/MPlayer video driver works now, playing 1080p HD video right out of the builtin HDMI port.
You might find yourself leaving your PC on just to play a game once in a while.