All of them can support PhysX. They don't have to offer hardware acceleration, they don't even have to use PhysX for physics if they don't want to. This is critical, a lot of UE3 games are not supporting PhysX hardware acceleration. UT3 is still the only game.
The Twilight Hack was how pirated WADs got on there in the first place. Once the system is compromised in to running any and all code, it's trivial to upload WADs. You can't block VC titles and not block homebrew with the current implementation of the two.
While I'd love to love WINE, I'm absolutely dismayed at the status of the Mac OS X version of it. The basics work but currently OpenGL is completely and entirely busted. Due to some kind of linker error OpenGL doesn't work, which means Direct3D doesn't work and as a result you can't use WINE to play games.
Does anyone know what's going on? In spite of the main project having adopted the DarWINE fork back in to the main tree, it seems like the OS X version of WINE is getting the shaft here for no particularly good reason.
Ditto to this. Cider does a piss poor job of supporting EVE, when the "native" clients first shipped it was slow, crash happy, and prone to graphical corruption. Even today it's slow and prone to graphical corruption, it's just less crash happy. Meanwhile Windows users get to use EVE's "premium" graphics, a series of new models and lighting system requiring Shader Model 3 while Linux and Mac users are out of luck. The situation is so bad that the remaining Linux users have gone back to playing the regular client on WINE because it's faster and supports said premium graphics, Mac users are out of luck because DarWINE isn't quite up to speed with SM3.
It works only if your definition is "it executes" otherwise you're much better off playing it under Windows.
Unfortunately not. For starters, the base PS3 OS isn't Linux. On top of that you can't use the GPU (or rather its framebuffer) when running Linux. The only way to do any kind of real PS3 development is with a SDK. This is the one thing where Microsoft has Sony completely whipped and to a lesser degree Nintendo (their SDK is much cheaper at $2500, though still not dirt cheap by any means).
Snarky answers aside, MS is selling XP for miniature devices at a very, very low price, far lower than XP normally goes for. This allows OEMs to hit the low prices they want, as otherwise Windows would be a very big piece of the price. But Microsoft also had to keep the OEMs from installing this version of XP in place of a full version, so they set up fairly arbitrary limitations that ensure that it's only installed in such miniature (read: underpowered) devices. It's basically the same chain of logic as to why XP/Vista Starter Editions are so cheap; cheap Windows is for cheap devices, and hardware restrictions are a way to enforce that.
Also keep in mind that normal XP is also being retired (sales are ending) at the end of this month, MS doesn't want XP selling for so long that it's still in use in 2014 when long-term support ends, which might happen if it could be slapped on new high-powered computers after their cut-off date. This also spirals off in to the point that MS wants to retire XP sooner than later for API and security reasons.
Since we're on the subject of flash memory, I find this article confuses me a tad bit. I was reading an article yesterday that mentioned that the current iPhone has room for a single flash chip, which means the current 16GB variety has a 128Gbit chip in it. But then TFA implies that 32Gb chips are as big as flash memory comes right now, which leaves me at an impasse. How does a device like the iPhone fit 128Gbit as a single chip if chips only come up to 32Gb in size?
What anti-DRM practices? The PC version uses a online activation system almost exactly like Mass Effect's (after EA scaled it back a bit), which they were panning just a few weeks earlier. When their little anti-Steam service goes broke (it wouldn't be the first, see: Triton) there goes the game.
You're thinking of things the wrong way, this is a semi-dynamic encryption system that uses smart card technology, not something completely static like AACS. The best comparison is DirecTV's system, which in 3 years no one has broken their newest encryption system.
You want an HDHomeRun, it will tune unencrypted (ClearQAM) channels and works with MythTV. Keep in mind however that cable companies usually encrypt all but the national networks, you won't get anything besides what you can already get with an antenna or infomercial/shopping networks that pay for their placement.
There's nothing inherently evil about SDV. Going forward it is the future of cable systems, it saves a ton of bandwidth by not transmitting channels that no one is watching. Cable companies are already feeling the bandwidth pressure of HD and analog channels; they want to carry the former but can't afford to get rid of the latter (and the customer base it supplies) quite yet, which results in situations like Comcast stuffing 3 HD channels in to the space for 2. SDV is going to be rolled out as soon as the technology is ready, and probably before analog channels are widely discontinued at that.
The only problem right now is that there's no standard platform for the hardware yet, which is why you had problems. With this agreement, CE manufacturers and CableLabs should be able to get that sorted out. It's just like the first transition to digital cable, it'll suck but eventually it will get worked out as standards are agreed upon and devices manufactured.
The long answer: Devices that accept CableCards and their bi-directional successor must be certified/keyed by CableLabs, the cable industry's R&D house. Part of that certification process requires that the entire device chain meets their security and DRM requirements; it's very similar to how BluRay players require all devices in a digital connection chain to be HDCP compliant. Anyhow, a homebrew application like MythTV will never be certified because someone could just program MythTV to ignore the DRM, and I don't think I need to explain CableLabs' problem with this. Without certification you don't have a key, and without a key the next device in chain won't pass you the data.
Now this doesn't entirely preclude this from being used with Linux, someone like Motorola for example could build a set-top box using Linux that would run all of this, but that's as close to a "yes" answer as you'd get. Cable devices will need to be a Trusted Platform to be certified.
The parent really could use a bump to the top of the conversation. The bit about OCAP/tru2way is the critical bit of information out of this announcement.
When Comcast wins, we all lose. This agreement signifies that the CEA has gone ahead and finally agreed to CableLabs terms; compliant devices will have to run the local cable company's Java middleware. This severely limits what 3rd party cable tuners can do, it will allow manufacturers to add functionality that doesn't relate directly to manipulating the signal (e.g. playing back movies from a file server) but it will prevent manufacturers from offering anything that involves the signal (no custom guides, no additional recording options, no custom interface, etc). Basically cable TV is now a Java application in hardware enforced authentication chain - your cable company will dictate what you get to watch and how. If they (or the networks they partner with) decide you can't keep a recorded program forever for example, then their middleware can be set to enforce that, and there's nothing you can do.
Crappy middleware for all, freedom (both to record and to innovate) for none!
CoreCodec really does treat their customers like shit. It's rather obvious at times that they want to license out their technology rather than sell it directly to consumers, meanwhile no one of note has been licensing their stuff. They're competent coders, don't get me wrong, CoreAVC has amazingly low CPU usage, but they're completely unable to run a business that deals with consumers. I have little doubt that that this is both a "sorry we got caught" and "we're genuinely sorry" situation; the former because they really don't want anyone jeopardizing future products, and the latter because once again no one was thinking when they enacted this.
I can only hope someone that actually knows how to interact with customers buys out the whole damn company, they're not getting any better on their own.
Frankly the general idea is correct, the reasoning is not. MS (publicly) doesn't want Yahoo because they effectively loaded themselves with a poison pill to keep Microsoft from taking them over. They've done things like partnering with Google and giving executives very large golden parachutes that make it very unpalpable if not outright hard for Microsoft to acquire the company and not end up with a mess and/or FTC troubles.
It is bad news for Yahoo employees and shareholders though. The company really is going nowhere, it's going to limp on for years like AOL or get picked up for pennies by Google if it could be cleared by the FTC. The best deal for the shareholders would have been to approve a buyout, but Yahoo's poison pill plan did a pretty good job of stopping that.
HFMD usually affects infants and children, and is quite common. It is highly contagious and is spread through direct contact with the mucus, saliva, or feces of an infected person. It typically occurs in small epidemics in nursery schools or kindergartens, usually during the summer and autumn months. The usual incubation period is 3-7 days.
It is extremely uncommon in adults, however still a possibility. Most adults have strong enough immune systems to utterly defeat the virus...
And outbreaks in April alone:
1. Outbreak at Lebanon Valley College, Annville, PA, USA
2. Outbreak in South Portland, ME, USA Infection may have spread to an isolated section of Westbrook, ME, as well
3. Outbreak in Auckland, NZ.
4. Reported in Santa Clara County, California, USA
5. Late March - mid April: 2,600 cases reported in Singapore, no serious cases; 1000 cases reported in the week of 14 - 20 April.[1]
6. Late April: it is reported in the chinese website (sina.com.cn) that in Fuyan, Provinz Anhui, 19 dead.
7. Late April: San Francisco, CA nursery schools.
Now I'm not saying it's of absolutely no concern, but it's not as if there's some massive killer disease rampaging through China. The average adult has nothing to worry about, and even in children the effects are rather mild with appropriate medical care. This will burn itself out well before the Olympics, and in a year no one will remember it; use some common sense here. If you want to avoid the Olympics (or encourage others to do so) there are much better reasons than this.
Sure, Amazon has done it and in fact has done it well. But they're also a giant company with the kind of resources to do such a thing. Collecting sales tax for the buyer doesn't scale down well to smaller operations, the complexity remains but the resources to handle it doesn't. Unless the Feds want to provide a live database that companies can use to look up specific sales taxes, leaving the task in the hands of the seller is just going to make running a smaller business impractical.
I'm all for getting rid of threads, but what are you going to replace them with? Traditional functional languages may be the most obvious solution, but they're also among the most impractical of solutions. Is there anything else out there that can replace threading needs, without throwing out the book on programming? It seems like what we need hasn't been invented yet.
It would be easier just to allow the state the entity is shipping from to collect a sales tax, a closer parallel to the idea that you pay a sales tax to whatever state you (and the seller) are in when you purchase something in meatspace. Tracking sales taxes for all your buyers' states (and sometimes counties) is cumbersome, this is a far simplier option. And while it means NY doesn't get a sales tax immediately, it closes the loophole where no one pays a sales tax, a problem with all but a handful of states generate a significant part of their revenue from such a tax.
Ultimately this means the silly shell games that distributors do to avoid having to charge sales taxes ends, and larger retailers will set up shipping warehouses in more states (i.e. New York) to better serve their customers with the disincentive to do so removed.
Slashdot Mirror
Make Mac OS X like Windows Vista (64bit Vista has almost all of the things listed in his article).
If it does get implemented, it'll be interesting to see how Jobs talks it up since Apple wouldn't have been first.
Try an instant rimshot next time for added pizazz.
It allows you to do the following:
1) Play pure homebrew from SD/USB
2) Play games from other regions on legitimate (pressed) discs
3) Play pirated Virtual Console/WiiWare games
And with a ModChip to keep the DVD drive from telling the Wii that a burnt disc is inside:
4) Play homebrew from burnt discs
5) Play pirated games with modified files
For obvious reasons, Nintendo is worried about #3 and #5.
Boy I wish Slashdot had a "check for stupid" button, then I wouldn't have written down March 8th; the assumption was March 6th.
FYI, the date stamps were read backwards. It was June 3rd of 2008, not March 8th of 2008.
All of them can support PhysX. They don't have to offer hardware acceleration, they don't even have to use PhysX for physics if they don't want to. This is critical, a lot of UE3 games are not supporting PhysX hardware acceleration. UT3 is still the only game.
The Twilight Hack was how pirated WADs got on there in the first place. Once the system is compromised in to running any and all code, it's trivial to upload WADs. You can't block VC titles and not block homebrew with the current implementation of the two.
While I'd love to love WINE, I'm absolutely dismayed at the status of the Mac OS X version of it. The basics work but currently OpenGL is completely and entirely busted. Due to some kind of linker error OpenGL doesn't work, which means Direct3D doesn't work and as a result you can't use WINE to play games.
Does anyone know what's going on? In spite of the main project having adopted the DarWINE fork back in to the main tree, it seems like the OS X version of WINE is getting the shaft here for no particularly good reason.
Ditto to this. Cider does a piss poor job of supporting EVE, when the "native" clients first shipped it was slow, crash happy, and prone to graphical corruption. Even today it's slow and prone to graphical corruption, it's just less crash happy. Meanwhile Windows users get to use EVE's "premium" graphics, a series of new models and lighting system requiring Shader Model 3 while Linux and Mac users are out of luck. The situation is so bad that the remaining Linux users have gone back to playing the regular client on WINE because it's faster and supports said premium graphics, Mac users are out of luck because DarWINE isn't quite up to speed with SM3.
It works only if your definition is "it executes" otherwise you're much better off playing it under Windows.
Unfortunately not. For starters, the base PS3 OS isn't Linux. On top of that you can't use the GPU (or rather its framebuffer) when running Linux. The only way to do any kind of real PS3 development is with a SDK. This is the one thing where Microsoft has Sony completely whipped and to a lesser degree Nintendo (their SDK is much cheaper at $2500, though still not dirt cheap by any means).
A slightly outdated, moderately insecure operating system with support through the end of 2014.
Snarky answers aside, MS is selling XP for miniature devices at a very, very low price, far lower than XP normally goes for. This allows OEMs to hit the low prices they want, as otherwise Windows would be a very big piece of the price. But Microsoft also had to keep the OEMs from installing this version of XP in place of a full version, so they set up fairly arbitrary limitations that ensure that it's only installed in such miniature (read: underpowered) devices. It's basically the same chain of logic as to why XP/Vista Starter Editions are so cheap; cheap Windows is for cheap devices, and hardware restrictions are a way to enforce that.
Also keep in mind that normal XP is also being retired (sales are ending) at the end of this month, MS doesn't want XP selling for so long that it's still in use in 2014 when long-term support ends, which might happen if it could be slapped on new high-powered computers after their cut-off date. This also spirals off in to the point that MS wants to retire XP sooner than later for API and security reasons.
Since we're on the subject of flash memory, I find this article confuses me a tad bit. I was reading an article yesterday that mentioned that the current iPhone has room for a single flash chip, which means the current 16GB variety has a 128Gbit chip in it. But then TFA implies that 32Gb chips are as big as flash memory comes right now, which leaves me at an impasse. How does a device like the iPhone fit 128Gbit as a single chip if chips only come up to 32Gb in size?
What anti-DRM practices? The PC version uses a online activation system almost exactly like Mass Effect's (after EA scaled it back a bit), which they were panning just a few weeks earlier. When their little anti-Steam service goes broke (it wouldn't be the first, see: Triton) there goes the game.
You're thinking of things the wrong way, this is a semi-dynamic encryption system that uses smart card technology, not something completely static like AACS. The best comparison is DirecTV's system, which in 3 years no one has broken their newest encryption system.
You want an HDHomeRun, it will tune unencrypted (ClearQAM) channels and works with MythTV. Keep in mind however that cable companies usually encrypt all but the national networks, you won't get anything besides what you can already get with an antenna or infomercial/shopping networks that pay for their placement.
There's nothing inherently evil about SDV. Going forward it is the future of cable systems, it saves a ton of bandwidth by not transmitting channels that no one is watching. Cable companies are already feeling the bandwidth pressure of HD and analog channels; they want to carry the former but can't afford to get rid of the latter (and the customer base it supplies) quite yet, which results in situations like Comcast stuffing 3 HD channels in to the space for 2. SDV is going to be rolled out as soon as the technology is ready, and probably before analog channels are widely discontinued at that.
The only problem right now is that there's no standard platform for the hardware yet, which is why you had problems. With this agreement, CE manufacturers and CableLabs should be able to get that sorted out. It's just like the first transition to digital cable, it'll suck but eventually it will get worked out as standards are agreed upon and devices manufactured.
The short answer: No.
The long answer: Devices that accept CableCards and their bi-directional successor must be certified/keyed by CableLabs, the cable industry's R&D house. Part of that certification process requires that the entire device chain meets their security and DRM requirements; it's very similar to how BluRay players require all devices in a digital connection chain to be HDCP compliant. Anyhow, a homebrew application like MythTV will never be certified because someone could just program MythTV to ignore the DRM, and I don't think I need to explain CableLabs' problem with this. Without certification you don't have a key, and without a key the next device in chain won't pass you the data.
Now this doesn't entirely preclude this from being used with Linux, someone like Motorola for example could build a set-top box using Linux that would run all of this, but that's as close to a "yes" answer as you'd get. Cable devices will need to be a Trusted Platform to be certified.
The parent really could use a bump to the top of the conversation. The bit about OCAP/tru2way is the critical bit of information out of this announcement.
When Comcast wins, we all lose. This agreement signifies that the CEA has gone ahead and finally agreed to CableLabs terms; compliant devices will have to run the local cable company's Java middleware. This severely limits what 3rd party cable tuners can do, it will allow manufacturers to add functionality that doesn't relate directly to manipulating the signal (e.g. playing back movies from a file server) but it will prevent manufacturers from offering anything that involves the signal (no custom guides, no additional recording options, no custom interface, etc). Basically cable TV is now a Java application in hardware enforced authentication chain - your cable company will dictate what you get to watch and how. If they (or the networks they partner with) decide you can't keep a recorded program forever for example, then their middleware can be set to enforce that, and there's nothing you can do.
Crappy middleware for all, freedom (both to record and to innovate) for none!
CoreCodec really does treat their customers like shit. It's rather obvious at times that they want to license out their technology rather than sell it directly to consumers, meanwhile no one of note has been licensing their stuff. They're competent coders, don't get me wrong, CoreAVC has amazingly low CPU usage, but they're completely unable to run a business that deals with consumers. I have little doubt that that this is both a "sorry we got caught" and "we're genuinely sorry" situation; the former because they really don't want anyone jeopardizing future products, and the latter because once again no one was thinking when they enacted this.
I can only hope someone that actually knows how to interact with customers buys out the whole damn company, they're not getting any better on their own.
Frankly the general idea is correct, the reasoning is not. MS (publicly) doesn't want Yahoo because they effectively loaded themselves with a poison pill to keep Microsoft from taking them over. They've done things like partnering with Google and giving executives very large golden parachutes that make it very unpalpable if not outright hard for Microsoft to acquire the company and not end up with a mess and/or FTC troubles.
It is bad news for Yahoo employees and shareholders though. The company really is going nowhere, it's going to limp on for years like AOL or get picked up for pennies by Google if it could be cleared by the FTC. The best deal for the shareholders would have been to approve a buyout, but Yahoo's poison pill plan did a pretty good job of stopping that.
From Wikipedia, Hand, Foot, and Mouth Disease the disease that results from this virus:
And outbreaks in April alone:
Now I'm not saying it's of absolutely no concern, but it's not as if there's some massive killer disease rampaging through China. The average adult has nothing to worry about, and even in children the effects are rather mild with appropriate medical care. This will burn itself out well before the Olympics, and in a year no one will remember it; use some common sense here. If you want to avoid the Olympics (or encourage others to do so) there are much better reasons than this.
Sure, Amazon has done it and in fact has done it well. But they're also a giant company with the kind of resources to do such a thing. Collecting sales tax for the buyer doesn't scale down well to smaller operations, the complexity remains but the resources to handle it doesn't. Unless the Feds want to provide a live database that companies can use to look up specific sales taxes, leaving the task in the hands of the seller is just going to make running a smaller business impractical.
I'm all for getting rid of threads, but what are you going to replace them with? Traditional functional languages may be the most obvious solution, but they're also among the most impractical of solutions. Is there anything else out there that can replace threading needs, without throwing out the book on programming? It seems like what we need hasn't been invented yet.
It would be easier just to allow the state the entity is shipping from to collect a sales tax, a closer parallel to the idea that you pay a sales tax to whatever state you (and the seller) are in when you purchase something in meatspace. Tracking sales taxes for all your buyers' states (and sometimes counties) is cumbersome, this is a far simplier option. And while it means NY doesn't get a sales tax immediately, it closes the loophole where no one pays a sales tax, a problem with all but a handful of states generate a significant part of their revenue from such a tax.
Ultimately this means the silly shell games that distributors do to avoid having to charge sales taxes ends, and larger retailers will set up shipping warehouses in more states (i.e. New York) to better serve their customers with the disincentive to do so removed.