Fortunately, the DNS cache is only checked if VAC detects you USING a cheat. Furthermore, you can visit cheat sites all day, VAC doesn't care. What it does care about are whether your PC is talking to DRM auth servers used by some cheats... only the cheats are going to be connecting to those servers.
Chrome OS uses a special bootloader and some other stuff, but you can install a Linux-based OS on a separate partition (after resizing the partitions) and dual boot it, as long as you can enable "developer mode" on the box so it will boot unsigned code (there's a switch for it on my Chromebook behind the battery). Or you can install one right inside Chrome OS with a chroot, if that's sufficient, again it requires developer mode turned on.
You could probably just blow everything away and put Linux on it alone, but I dunno how you'd go about doing that.
It's all about bringing common, expected PC functionality to Steam OS... listen to music, browse the web, and perhaps more with time. Power users can drop to Gnome and do stuff but Valve likely does not find that acceptable for causal users I bet.
Only problem I have with MS' client is that you can't pinch zoom like you'd expect... you click on a "move" icon at the top which, for some reason, causes it to zoom in instead. Weird.
First of all, there was NO UI to activate this feature. The only access was through third-party apps that allow you to launch arbitrary activities (for those not familiar with Android, think application windows) in other apps.
So it was obviously unsupported by Google. The first thing I think of are Chrome's Labs at chrome://flags which carries this warning:
WARNING These experimental features may change, break, or disappear at any time. We make absolutely no guarantees about what may happen if you turn one of these experiments on, and your browser may even spontaneously combust. Jokes aside, your browser may delete all your data, or your security and privacy could be compromised in unexpected ways. Any experiments you enable will be enabled for all users of this browser. Please proceed with caution. Interested in cool new Chrome features? Try our beta channel at chrome.com/beta.
And THOSE are UI-exposed, unlike App Ops. The same warnings would apply to App Ops, if not worse.
Android permissions were built on the assumption that they were all-or-nothing: either the user would install the app and grant all permissions, or the user would deny the permissions and not install the app. It isn't like webpage permissions where the user may decline to allow a page to display desktop notifications or go fullscreen and the page can react to that.
Because apps expect permissions to always succeed, the common approach to making permission-limiting frameworks is to make the app think it still has permission by serving it dummy data, like an empty contacts list, or a blank image purportedly from the camera, so the app still operates.
Google is saying some apps were not compatible, which tells me App Ops still needs work, which explains why they have not formerly released it.
Some people have been using App Ops and now find the UI crashes when you load it, but the underlying feature is still applying the settings. Considering it was an unsupported and experimental feature this is not surprising, and it is not surprising Google removed access. Back when Google Chrome was brand new, occasionally Google would ship Dev builds that would crash on launch for a not insignificant portion of the user base. Such is the risk of alpha software (or in this case, an alpha feature).
It will NOT change the way the system handles PDF files.
It has NOTHING to do with how the browser views PDF files on the web (the Chrome PDF viewer is already the default).
It only affects how Chrome handles when you choose to open a downloaded PDF file.
Likely this was done to be consistent. Any security the Chrome PDF viewer could offer could be easily bypassed by an attacker forcing the file to download. If the user clicks it, it opens in the system PDF viewer.
I believe Adobe Reader has its own sandbox so this might seem a bit weird... but at least one thing Chrome has going for it that Reader has not is that Chrome is more likely to be up-to-date (I forget how Reader updates itself, if it does at all) AND it pulls the latest Chrome PDF plugin with it.
On a PC there's no pressing need since I have lots of disk space, and it's easy to keep apps from running in the background.
On Android is another story. Very limited space, and apps can run in the background very easily and are hard or impossible to kill in some cases. I recently uninstalled outlook.com app since I never used it (I installed it intending to, but never did) and it was sucking battery life. I also uninstall apps which provide duplicate functionality that I already have in an app I prefer. Large apps have to really be persuasive to stay as well.
AFAIK with server<-&grclient you have all clients doing physics calculations BUT they are only used for prediction; the server updates the final position and orientation using its own physical calculations (but since the clients are predicting it can do it with a low-resolution in terms of time).
I use an extension to download videos from YouTube. Those tend to be blocked from the Web Store, so you have to install them manually from other websites (this is the bit that is getting blocked). I hope there is at least a command line switch left in to disable this behavior! It's very "walled garden" and I don't like it.
BTW, the summary says "local extensions" but that is incorrect. It just blocks non-Chrome Web Store web extensions. Extensions you are actively developing and load via "Load unpacked extension" will still work.
Actually, that might have to be the fix for my YouTube extension I use. Oh well.
Chrome already blocks malicious downloads. Not sure how this is new. Maybe it's a more advanced version of the existing feature.
The existing feature already looks like the current screenshot, except the text might be different. And yes, you can allow downloads using the drop down on the right.
Possibly this is integration of anti-virus hooks? I think the existing version might just use a Google list of known safe and dangerous downloads.
Yeah Steam is pretty good at running even if you nuke its registry entries (or reinstall Windows) and nuke everything except Steam.exe. It'll redownload all of its missing components and regenerate its registry stuff (though you need to relogin and auth with Steam Guard).
I did have a bit of a hiccup with Steam yesterday when most of their servers seemed to go down for a bit but it was only for like 15 minutes, then they were back up. Though my TF2 hats took a bit longer to come back.
The funny part is the Navy runs Red Hat (and an embedded variant) on a bunch of systems on their ships... so they were already running Linux. Of the systems I'm familiar with only one runs Windows and they were phasing it out to replace it with Linux last I heard.
No marketspeak here, but if you're not familiar with the technical details you might be a bit lost. First of all, in order to understand the solution, you need to identify the problem.
The problem is that, currently, refresh rates are STATIC. For example, if I set mine to 60Hz, the screen redraws at 60fps. If I keep vsync disabled to allow my gfx card to push out frames as fast as it can, my screen still only draws 60fps, and screen "tearing" can result as the screen redraws in the middle of the gfx card pushing out a new frame (so I see half-and-half of two frames).
As described, let's say my gfx card is pushing out 25fps. Currently the optimal strategy is to keep vsync off, even though this can result in screen "tearing", because with low fps bigger problem emerges even though screen "tearing" is fixed, with vsync on.
Every time my gfx card pushes out a frame, since vsync is on, it waits to ensure it will not be drawing to the screen buffer while the screen is updating. Since it waits, the screen only draws complete frames. So at 60fps the screen updates in 1/60 second intervals, and the gfx card render at 1/25 second intervals. So, at the beginning of a frame render, the gfx card renders... and the screen redraws twice, and then the gfx card has to wait for the third opportunity to draw before syncing up again. Since it is waiting instead of rendering, I am now rendering at 20fps (since I lose 2/3 refresh opportunities) instead of the optimal 25fps. If I disable vsync, I get tearing, but now 25fps.
This "G-sync" claims to solve that issue by making refresh rates DYNAMIC. So if my gfx card renderas at 25fps, the screen will refresh at that rate. It will be synchronized. No tearing or gfx card waiting to draw.
Other than those two you have Microsoft's Virtual PC and HyperV. Then you have Qemu. For Linux users there are also a couple of Linux-only solutions I'm not familiar with like Xen. I think that covers all the major players.
Slashdot Mirror
Fortunately, the DNS cache is only checked if VAC detects you USING a cheat. Furthermore, you can visit cheat sites all day, VAC doesn't care. What it does care about are whether your PC is talking to DRM auth servers used by some cheats... only the cheats are going to be connecting to those servers.
Make an analogy about how politicians don't fix any of their problems and get paid to make more, and ask why you can't do that?
Chrome OS uses a special bootloader and some other stuff, but you can install a Linux-based OS on a separate partition (after resizing the partitions) and dual boot it, as long as you can enable "developer mode" on the box so it will boot unsigned code (there's a switch for it on my Chromebook behind the battery). Or you can install one right inside Chrome OS with a chroot, if that's sufficient, again it requires developer mode turned on.
You could probably just blow everything away and put Linux on it alone, but I dunno how you'd go about doing that.
Winamp can't run on Steam OS, it's Windows only.
It's all about bringing common, expected PC functionality to Steam OS... listen to music, browse the web, and perhaps more with time. Power users can drop to Gnome and do stuff but Valve likely does not find that acceptable for causal users I bet.
AFAIK Google Apps for Enterprises allows you to run Docs on your own server. Of course it costs money. That's the tradeoff of course.
Only thing it's missing, for me, is an Android client app, and that is coming. Until then TeamViewer works pretty good.
You enable javascript for the website, but not from the ad server.
Why not SQL injection?
Only problem I have with MS' client is that you can't pinch zoom like you'd expect... you click on a "move" icon at the top which, for some reason, causes it to zoom in instead. Weird.
SVCHost can host multiple services in one process. You probably killed Windows Audio in addition to Windows Update.
... We are turning into our parents.
"When I was your age, we DROVE to the store and used REAL MONEY and bought the DVD! And we LIKED IT THAT WAY!"
First of all, there was NO UI to activate this feature. The only access was through third-party apps that allow you to launch arbitrary activities (for those not familiar with Android, think application windows) in other apps.
So it was obviously unsupported by Google. The first thing I think of are Chrome's Labs at chrome://flags which carries this warning:
WARNING These experimental features may change, break, or disappear at any time. We make absolutely no guarantees about what may happen if you turn one of these experiments on, and your browser may even spontaneously combust. Jokes aside, your browser may delete all your data, or your security and privacy could be compromised in unexpected ways. Any experiments you enable will be enabled for all users of this browser. Please proceed with caution. Interested in cool new Chrome features? Try our beta channel at chrome.com/beta.
And THOSE are UI-exposed, unlike App Ops. The same warnings would apply to App Ops, if not worse.
Android permissions were built on the assumption that they were all-or-nothing: either the user would install the app and grant all permissions, or the user would deny the permissions and not install the app. It isn't like webpage permissions where the user may decline to allow a page to display desktop notifications or go fullscreen and the page can react to that.
Because apps expect permissions to always succeed, the common approach to making permission-limiting frameworks is to make the app think it still has permission by serving it dummy data, like an empty contacts list, or a blank image purportedly from the camera, so the app still operates.
Google is saying some apps were not compatible, which tells me App Ops still needs work, which explains why they have not formerly released it.
Some people have been using App Ops and now find the UI crashes when you load it, but the underlying feature is still applying the settings. Considering it was an unsupported and experimental feature this is not surprising, and it is not surprising Google removed access. Back when Google Chrome was brand new, occasionally Google would ship Dev builds that would crash on launch for a not insignificant portion of the user base. Such is the risk of alpha software (or in this case, an alpha feature).
Likely this was done to be consistent. Any security the Chrome PDF viewer could offer could be easily bypassed by an attacker forcing the file to download. If the user clicks it, it opens in the system PDF viewer.
I believe Adobe Reader has its own sandbox so this might seem a bit weird... but at least one thing Chrome has going for it that Reader has not is that Chrome is more likely to be up-to-date (I forget how Reader updates itself, if it does at all) AND it pulls the latest Chrome PDF plugin with it.
On a PC there's no pressing need since I have lots of disk space, and it's easy to keep apps from running in the background.
On Android is another story. Very limited space, and apps can run in the background very easily and are hard or impossible to kill in some cases. I recently uninstalled outlook.com app since I never used it (I installed it intending to, but never did) and it was sucking battery life. I also uninstall apps which provide duplicate functionality that I already have in an app I prefer. Large apps have to really be persuasive to stay as well.
AFAIK with server<-&grclient you have all clients doing physics calculations BUT they are only used for prediction; the server updates the final position and orientation using its own physical calculations (but since the clients are predicting it can do it with a low-resolution in terms of time).
The initial version of Chrome did not support addons. But Firefox was so slow at the time I gladly jumped ship and never looked back.
I use an extension to download videos from YouTube. Those tend to be blocked from the Web Store, so you have to install them manually from other websites (this is the bit that is getting blocked). I hope there is at least a command line switch left in to disable this behavior! It's very "walled garden" and I don't like it.
BTW, the summary says "local extensions" but that is incorrect. It just blocks non-Chrome Web Store web extensions. Extensions you are actively developing and load via "Load unpacked extension" will still work.
Actually, that might have to be the fix for my YouTube extension I use. Oh well.
Here in businessland they just block Gmail and Google Drive anyway...
I turn 28 this december. I grew up with MS-DOS and Windows 3.11, so yeah, I know what minesweeper is. :) Got to grow up with it.
Chrome already blocks malicious downloads. Not sure how this is new. Maybe it's a more advanced version of the existing feature.
The existing feature already looks like the current screenshot, except the text might be different. And yes, you can allow downloads using the drop down on the right.
Possibly this is integration of anti-virus hooks? I think the existing version might just use a Google list of known safe and dangerous downloads.
Yeah Steam is pretty good at running even if you nuke its registry entries (or reinstall Windows) and nuke everything except Steam.exe. It'll redownload all of its missing components and regenerate its registry stuff (though you need to relogin and auth with Steam Guard).
I did have a bit of a hiccup with Steam yesterday when most of their servers seemed to go down for a bit but it was only for like 15 minutes, then they were back up. Though my TF2 hats took a bit longer to come back.
The funny part is the Navy runs Red Hat (and an embedded variant) on a bunch of systems on their ships... so they were already running Linux. Of the systems I'm familiar with only one runs Windows and they were phasing it out to replace it with Linux last I heard.
No marketspeak here, but if you're not familiar with the technical details you might be a bit lost. First of all, in order to understand the solution, you need to identify the problem.
The problem is that, currently, refresh rates are STATIC. For example, if I set mine to 60Hz, the screen redraws at 60fps. If I keep vsync disabled to allow my gfx card to push out frames as fast as it can, my screen still only draws 60fps, and screen "tearing" can result as the screen redraws in the middle of the gfx card pushing out a new frame (so I see half-and-half of two frames).
As described, let's say my gfx card is pushing out 25fps. Currently the optimal strategy is to keep vsync off, even though this can result in screen "tearing", because with low fps bigger problem emerges even though screen "tearing" is fixed, with vsync on.
Every time my gfx card pushes out a frame, since vsync is on, it waits to ensure it will not be drawing to the screen buffer while the screen is updating. Since it waits, the screen only draws complete frames. So at 60fps the screen updates in 1/60 second intervals, and the gfx card render at 1/25 second intervals. So, at the beginning of a frame render, the gfx card renders... and the screen redraws twice, and then the gfx card has to wait for the third opportunity to draw before syncing up again. Since it is waiting instead of rendering, I am now rendering at 20fps (since I lose 2/3 refresh opportunities) instead of the optimal 25fps. If I disable vsync, I get tearing, but now 25fps.
This "G-sync" claims to solve that issue by making refresh rates DYNAMIC. So if my gfx card renderas at 25fps, the screen will refresh at that rate. It will be synchronized. No tearing or gfx card waiting to draw.
Other than those two you have Microsoft's Virtual PC and HyperV. Then you have Qemu. For Linux users there are also a couple of Linux-only solutions I'm not familiar with like Xen. I think that covers all the major players.
http://xkcd.com/221/