I think grandma would get the gist of a picture showing a shitty pixelated image on one side and a smooth antialiased high res picture on the other. Other users would get the implication that a game would look better on a better card.
I think Ubisoft's problems are numerous but the two that spring to mind are a) they don't produce many good games and people know it, and b) PC gamers are averse to DRM at the best of times and inflicting a DRM which needs internet access is plain stupid.
The stupid part is the PC represents money for old rope. They already have probably 95% of the code and 99% of the assets required to make a PC port from the 360 & PS3 versions so it doesn't make any sense to ignore the market. Port the game, throw it up on steam for a reasonable price and it will happily sell with negligible piracy.
Perhaps the answer is a slider, a bit like the one in Google Earth. When you load a page there is a slider at the top pushed all the way to the right. Slide it left and you see previous revisions of the text with date & time information, and perhaps context against the change too.
Well it is a science resource so one would hope that it would be kept up to date with the latest scientific findings. I would be more worried that this "lifetime" resource ended up bitrotting, through lack of maintenance as time progressed. e.g. if they don't get enough subscribers to fund ongoing revision, what happens then?
I'd chalk it up to some poor web designer trying to produce a static image illustrating the difference between one card and another. A more accurate comparison would take a picture of a game running on high settings in high res and on low settings at a lower res and zoom in on a portion of the game to demonstrate the difference in resolution, texture, antialiasing.
I've had a fair share of crashes but usually due to hardware failures. I think I have had perhaps 2 or 3 panics that could not be accounted for through flakey hardware.
Convergence sounds close enough to what I suggested in another thread to make me think it's viable. But only if it becomes more than an extension - every modern browser needs to sign off on the concept and implement the core functionality as part of itself. I also wonder if notaries are enough, or whether it should be a bona fide web of trust. On another thread I suggested that trust for a company like Toys R Us would have more relevance to a visitor if it were signed by Lego, Hasbro, Microsoft, Visa etc. than some faceless CA. i.e. if two sites have a business relationship with each other they should solidify that by signing each other's root certs with some revocation mechanism baked in for when trust breaks down.
CAs are a racket and actually impede rather than enhance security on the web.
Big sites which can afford the $$$ can get a CA signature which is meaningfully secure and trustworthy. Which is great for them but not so good for the vast bulk of sites which might like to use encryption but don't because obtaining and maintaining a cert is a huge pain in the ass. So they continue with plaintext. And if we look at those big sites, surely a Toys R Us would find more worth in a cert which was signed by Lego, Microsoft, Visa, Mastercard and so on than by some obscure CA? Companies whom the visitor is likely to recognize and would have some kind of reciprocal business relationship.
So instead of a rigid CA signature it seems to me a lot better to implement a web of trust. Google could host a key signing party and get Microsoft, Amazon, PayPal, Mozilla to attend. Each in turn might hold some satellite key signing parties to sign more keys and keep going out until the top 500 or so sites are covered by each. Every signatory signs with an email address and puts their public key up on a well defined location on that domain, e.g. the public key for security@keys.google.com might be at keys.google.com/security. A browser is preloaded with public keys for the major sites and is capable of caching any it doesn't have. There would also be some kind of revocation model. Trust could be graded anywhere from ultimate to weak. When a browser visits a site it validates the site's signatories and their trust to the ones in its list and poses an appropriate form of information or error to the user depending on what it finds.
The point is that web of trust would allow sites to make their own trust in a manner that suits them and their visitors. And it doesn't stop CAs from selling their own signatures as part of the web of trust either much like some already do for PGP, or through the more rigid CA model. But what it does do is stop CAs being a mandatory part of the equation. People will be able to generating certs in an adhoc fashion. That to me is a far better model, and one which would stand a good chance of making security the default rather than an after thought that some sites practice and not others.
Not necessarily. The problem with DRM is the "rights" it protects are the content providers. My opinion is that once you purchase content it should become yours and DRM should protect your rights. i.e. if Amazon fucks up and discovers they sold 1984 when they weren't supposed to, tough they're going to have to settle a lawsuit with the providers since any content they sold no longer belongs to them to control. If Penguin sell some books to a library and doesn't like how the library lends their books then tough they'll have to go through whatever publisher / library arbitration mechanisms exist because they can't yank / revoke stuff out there already.
The best thing that could happen is if someone like the EU were to enshrine these rights in law and force providers to conform, i.e. that when you buy a book you are buying the book, not just a licence and that there is a mechanism to sell a book with a nominal processing fee. And also that all electronic content sold should be held with decryption keys in escrow in an open format so that subject to court order, or to platform collapse that the owner can retrieve it. Better yet if there were a single platform across all devices that managed the concept of ownership and transfer of ownership.
In browsers you would have to. Browsers are event based - GUI events and timers cause JS to be executed. The browser executes JS associated with an event and synchronously waits for it to complete before it can do anything else (e.g. update the DOM / layout). If the JS never returns the browser becomes unresponsive and eventually complains to the user about the JS and asks if it should be stopped. So if you were running a JVM in that environment you would most likely have to find some break point during JVM execution to halt execution, save state, set a timer and return to the browser. When the timer fired you would wake up again, restore state and continue for another timeslice.
I realise JS doesn't have to run in a browser, but I would argue that the most useful place for a JVM over JS would be in a browser. It doesn't make sense to me to want to run a JVM over JS on a server or in a standalone JS script because in either place it would be likely be easier to install and invoke a proper JVM which wouldn't suffer from any limitation or slowdown associated with running over JS.
So where do the keys get stored? If it's the HTML web storage, does that mean that you can only store keys per domain? Is that even advisable? And what stops a compromised site from lifting your keys while it's about encrypting or signing a message for you?
I think for reasons of trust that if you were to use js PGP that it should be from a browser extension that could be reviewed and be within your control to some extent. Or better yet if the js became a core part of a browser where the code could be implicitly trusted. I'd love to see something like Firefox support go further and use a lib like this so unsigned certs could instead describe a web of trust via PGP and modify the manner in which Firefox presents such certs to a user. CAs are the biggest racket on the web and are IMO the biggest impediment to https being the default protocol for web activity.
You'd have to use timers. The JS is running in a browser. If you let code for as long as it likes the browser won't be responsive and eventually will start complaining to the user about the fact. The JS would have to execute a bit of code, find some convenient point to halt, set a timer, drop out back to browser and then execute some more when the timer fired. Even if there was just one thread. When you have more than one thread you'd have to do the same for multiple threads via some kind of scheduler.
Well I suppose Java did come from that situation a long time ago - so called "green" threads. So I concede you could probably use some crappy timer / yield type model. The timeslice / yielding would be the issue and all the synchronization / deadlock issues would be fun too.
It is a compiled language. It's compiled into bytecode. Whether it's optimized or not is a function of the compiler implementation. It's true the default compiler doesn't do much optimization,but that doesn't mean it is not possible. The Eclipse compiler and Jikes have some optimization settings and you always run a file through proguard too.
It couldn't either. Stuff like threads would be virtually impossible to do on Javascript, even with web workers. I suppose what it might do in the dim and distant future is allow tools like GWT to deploy jar files straight to web sites without any of the usual nonsense of translating Java source into umpteen variations of JS to cope with browser quirks.
That's fair enough but you'd probably have to be sure not to leave other traces of your activity around, e.g. registry entries pointing at non-existent files on the mount point. Everything would have to be self contained. Just as important your shadow copy would have to be consistent with the known facts. e.g. if the cops know you were logged onto the internet on such and such a date and your shadow copy hasn't been used in 2 years they're going start threatening you with RIPA.
Re:The grass is greener on the other side
on
Occupy Flash?
·
· Score: 1
Flash has the potential to do anything it likes because it lives outside the browser and the DOM. Indeed many modern browsers host plugins in a separate process so it does run in a separate thread and the plugin can apply its own strategies in addition to that. When you implement everything in HTML then everything is in contention from the same presentation thread.
Re:The grass is greener on the other side
on
Occupy Flash?
·
· Score: 1
The DOM is single threaded. JS would be invoked from a timer and would have to tween a frame and completely render the new frame before returning. The JS calls are synchronous so the canvas implementation would have to either perform the drawing action or at least pretend to. If rendering was deferred it would still have to be rendered at some point. Control only returns to the page and other timers when JS completes. Then the browser has to figure out that the canvas has been invalidated and recompose it and any elements sitting over the top of it before repainting. And it has to do this 30 times a second. And it's in contention with possibly 3 or 4 other such canvases.
The grass is greener on the other side
on
Occupy Flash?
·
· Score: 4, Informative
Of course as soon as Flash goes everyone will suddenly realise how frigging awful the equivalent code in JS hooked up to a canvas is. At least with Flash the plugin had the potential to be rendering content on a separate thread and largely independent of anything else going on in a page. It was even better on Windows since a Flash anim could invalidate its plugin window and repaint without bothering the browser.
Now if you hit a page with a few Flash-like HTML animations, they'll all be in contention on the same thread, running off timers and generally chugging. And hardware accelerated video? Screw that, you're stuck with WebM or whatever else can be called the lowest common denominator.
Planted saboteurs! That's a tad paranoid to say the least. More likely it is an example of what happens your protest attracts large numbers from the lunatic fringes - socialists, anarchists, etc. Many of these people are probably veteran trouble makers from g8 conferences and OWS makes a great opportunity to cause trouble. OWS should have channeled its support into lobbying politicians and it wouldn't have attracted these people. Now politicians couldn't give a shit what OWS has to say. All they care about is tearing down their hobo camps and dispersing them.
My first point was that if Broadcom were to provide a proprietary SDK to access the h264 functionality, would a GPL application such as XBMC be able to link to and use those apis? It's a licencing issue. Would Broadcom even release the APIs at all except to specific licencees?
The second point is just a digression into how SoCs work. If you look through a chip's specsheet it will claim to support various techs in hardware. But to use them the chip must be loaded with a cryptographic token which unlocks the feature. Normally the STB manufacturer would buy the tokens and load them onto the box in the factory. No token = no access to the feature. So I expect Raspberry Pi will support h264 and HDMI because it's publicly said as much but there is no guarantee it will support other things the chip have the potential to do.
The third was just a throwaway comment but ties into XBMC again. These SoCs usually split the display into layers, e.g. 1 or 2 presentation layers, a subtitles layer, a video layer. So even if you could hardware accelerate the video playback, it would have to tie into the way XBMC or other media players composite their screen. I expect XBMC would probably just use a null video driver and would rely on the APIs to fill in the video layer. Perhaps it might even keep the video playback / trickplay functionality in a separate process to keep itself and the proprietary APIs separate from each other.
Most of these chips support in hardware the stuff your average blu ray player or satellite box has to support. But support doesn't mean make available. There are so many patents around these things that the tech is usally masked off and you have to load a token onto the chip at the factory to enable it. So the chip might be capable of a lot of things but you ain't going to be able to use them. I assume h264 is going to be enabled by a token but it would still need the APIs in order to make use of it in hardware. And that would raise some interesting questions about what happens if you invoke those APIs from GPL software, and aside from that how do you go about overlaying graphics over the video buffer while it is playing out.
I've only glanced over the code but it does appear to contain measures to detect tampering and to detect message forgery. For example pods talk with one another with the salmon protocol which was specifically designed for news aggregation sites to distribute comments back to the origin site and vice versa (i.e. the comments made on one site swim upstream to appear on another site). The protocol is designed to encrypt and sign comments so that the author of the comments is known and unique and provide all the data the origin needs to block / reject comments by spammers and so on.
Of course it's in alpha so what it might do in theory is not necessarily what it might do in practice.
Slashdot Mirror
You can be smart and yet incredibly dumb.
I think grandma would get the gist of a picture showing a shitty pixelated image on one side and a smooth antialiased high res picture on the other. Other users would get the implication that a game would look better on a better card.
The stupid part is the PC represents money for old rope. They already have probably 95% of the code and 99% of the assets required to make a PC port from the 360 & PS3 versions so it doesn't make any sense to ignore the market. Port the game, throw it up on steam for a reasonable price and it will happily sell with negligible piracy.
Perhaps the answer is a slider, a bit like the one in Google Earth. When you load a page there is a slider at the top pushed all the way to the right. Slide it left and you see previous revisions of the text with date & time information, and perhaps context against the change too.
Well it is a science resource so one would hope that it would be kept up to date with the latest scientific findings. I would be more worried that this "lifetime" resource ended up bitrotting, through lack of maintenance as time progressed. e.g. if they don't get enough subscribers to fund ongoing revision, what happens then?
I'd chalk it up to some poor web designer trying to produce a static image illustrating the difference between one card and another. A more accurate comparison would take a picture of a game running on high settings in high res and on low settings at a lower res and zoom in on a portion of the game to demonstrate the difference in resolution, texture, antialiasing.
I've had a fair share of crashes but usually due to hardware failures. I think I have had perhaps 2 or 3 panics that could not be accounted for through flakey hardware.
Convergence sounds close enough to what I suggested in another thread to make me think it's viable. But only if it becomes more than an extension - every modern browser needs to sign off on the concept and implement the core functionality as part of itself. I also wonder if notaries are enough, or whether it should be a bona fide web of trust. On another thread I suggested that trust for a company like Toys R Us would have more relevance to a visitor if it were signed by Lego, Hasbro, Microsoft, Visa etc. than some faceless CA. i.e. if two sites have a business relationship with each other they should solidify that by signing each other's root certs with some revocation mechanism baked in for when trust breaks down.
Big sites which can afford the $$$ can get a CA signature which is meaningfully secure and trustworthy. Which is great for them but not so good for the vast bulk of sites which might like to use encryption but don't because obtaining and maintaining a cert is a huge pain in the ass. So they continue with plaintext. And if we look at those big sites, surely a Toys R Us would find more worth in a cert which was signed by Lego, Microsoft, Visa, Mastercard and so on than by some obscure CA? Companies whom the visitor is likely to recognize and would have some kind of reciprocal business relationship.
So instead of a rigid CA signature it seems to me a lot better to implement a web of trust. Google could host a key signing party and get Microsoft, Amazon, PayPal, Mozilla to attend. Each in turn might hold some satellite key signing parties to sign more keys and keep going out until the top 500 or so sites are covered by each. Every signatory signs with an email address and puts their public key up on a well defined location on that domain, e.g. the public key for security@keys.google.com might be at keys.google.com/security. A browser is preloaded with public keys for the major sites and is capable of caching any it doesn't have. There would also be some kind of revocation model. Trust could be graded anywhere from ultimate to weak. When a browser visits a site it validates the site's signatories and their trust to the ones in its list and poses an appropriate form of information or error to the user depending on what it finds.
The point is that web of trust would allow sites to make their own trust in a manner that suits them and their visitors. And it doesn't stop CAs from selling their own signatures as part of the web of trust either much like some already do for PGP, or through the more rigid CA model. But what it does do is stop CAs being a mandatory part of the equation. People will be able to generating certs in an adhoc fashion. That to me is a far better model, and one which would stand a good chance of making security the default rather than an after thought that some sites practice and not others.
The best thing that could happen is if someone like the EU were to enshrine these rights in law and force providers to conform, i.e. that when you buy a book you are buying the book, not just a licence and that there is a mechanism to sell a book with a nominal processing fee. And also that all electronic content sold should be held with decryption keys in escrow in an open format so that subject to court order, or to platform collapse that the owner can retrieve it. Better yet if there were a single platform across all devices that managed the concept of ownership and transfer of ownership.
I realise JS doesn't have to run in a browser, but I would argue that the most useful place for a JVM over JS would be in a browser. It doesn't make sense to me to want to run a JVM over JS on a server or in a standalone JS script because in either place it would be likely be easier to install and invoke a proper JVM which wouldn't suffer from any limitation or slowdown associated with running over JS.
I think for reasons of trust that if you were to use js PGP that it should be from a browser extension that could be reviewed and be within your control to some extent. Or better yet if the js became a core part of a browser where the code could be implicitly trusted. I'd love to see something like Firefox support go further and use a lib like this so unsigned certs could instead describe a web of trust via PGP and modify the manner in which Firefox presents such certs to a user. CAs are the biggest racket on the web and are IMO the biggest impediment to https being the default protocol for web activity.
I never said you needed a browser to run JS, but that is where it is typically run.
You'd have to use timers. The JS is running in a browser. If you let code for as long as it likes the browser won't be responsive and eventually will start complaining to the user about the fact. The JS would have to execute a bit of code, find some convenient point to halt, set a timer, drop out back to browser and then execute some more when the timer fired. Even if there was just one thread. When you have more than one thread you'd have to do the same for multiple threads via some kind of scheduler.
Well I suppose Java did come from that situation a long time ago - so called "green" threads. So I concede you could probably use some crappy timer / yield type model. The timeslice / yielding would be the issue and all the synchronization / deadlock issues would be fun too.
It is a compiled language. It's compiled into bytecode. Whether it's optimized or not is a function of the compiler implementation. It's true the default compiler doesn't do much optimization,but that doesn't mean it is not possible. The Eclipse compiler and Jikes have some optimization settings and you always run a file through proguard too.
It couldn't either. Stuff like threads would be virtually impossible to do on Javascript, even with web workers. I suppose what it might do in the dim and distant future is allow tools like GWT to deploy jar files straight to web sites without any of the usual nonsense of translating Java source into umpteen variations of JS to cope with browser quirks.
That's fair enough but you'd probably have to be sure not to leave other traces of your activity around, e.g. registry entries pointing at non-existent files on the mount point. Everything would have to be self contained. Just as important your shadow copy would have to be consistent with the known facts. e.g. if the cops know you were logged onto the internet on such and such a date and your shadow copy hasn't been used in 2 years they're going start threatening you with RIPA.
Flash has the potential to do anything it likes because it lives outside the browser and the DOM. Indeed many modern browsers host plugins in a separate process so it does run in a separate thread and the plugin can apply its own strategies in addition to that. When you implement everything in HTML then everything is in contention from the same presentation thread.
The DOM is single threaded. JS would be invoked from a timer and would have to tween a frame and completely render the new frame before returning. The JS calls are synchronous so the canvas implementation would have to either perform the drawing action or at least pretend to. If rendering was deferred it would still have to be rendered at some point. Control only returns to the page and other timers when JS completes. Then the browser has to figure out that the canvas has been invalidated and recompose it and any elements sitting over the top of it before repainting. And it has to do this 30 times a second. And it's in contention with possibly 3 or 4 other such canvases.
Now if you hit a page with a few Flash-like HTML animations, they'll all be in contention on the same thread, running off timers and generally chugging. And hardware accelerated video? Screw that, you're stuck with WebM or whatever else can be called the lowest common denominator.
Planted saboteurs! That's a tad paranoid to say the least. More likely it is an example of what happens your protest attracts large numbers from the lunatic fringes - socialists, anarchists, etc. Many of these people are probably veteran trouble makers from g8 conferences and OWS makes a great opportunity to cause trouble. OWS should have channeled its support into lobbying politicians and it wouldn't have attracted these people. Now politicians couldn't give a shit what OWS has to say. All they care about is tearing down their hobo camps and dispersing them.
The second point is just a digression into how SoCs work. If you look through a chip's specsheet it will claim to support various techs in hardware. But to use them the chip must be loaded with a cryptographic token which unlocks the feature. Normally the STB manufacturer would buy the tokens and load them onto the box in the factory. No token = no access to the feature. So I expect Raspberry Pi will support h264 and HDMI because it's publicly said as much but there is no guarantee it will support other things the chip have the potential to do.
The third was just a throwaway comment but ties into XBMC again. These SoCs usually split the display into layers, e.g. 1 or 2 presentation layers, a subtitles layer, a video layer. So even if you could hardware accelerate the video playback, it would have to tie into the way XBMC or other media players composite their screen. I expect XBMC would probably just use a null video driver and would rely on the APIs to fill in the video layer. Perhaps it might even keep the video playback / trickplay functionality in a separate process to keep itself and the proprietary APIs separate from each other.
Most of these chips support in hardware the stuff your average blu ray player or satellite box has to support. But support doesn't mean make available. There are so many patents around these things that the tech is usally masked off and you have to load a token onto the chip at the factory to enable it. So the chip might be capable of a lot of things but you ain't going to be able to use them. I assume h264 is going to be enabled by a token but it would still need the APIs in order to make use of it in hardware. And that would raise some interesting questions about what happens if you invoke those APIs from GPL software, and aside from that how do you go about overlaying graphics over the video buffer while it is playing out.
Of course it's in alpha so what it might do in theory is not necessarily what it might do in practice.