They don't each have a full 16 lanes of signaling backing them up. There is probably 16 total lanes, so if both are in use they get 8 lanes per, despite being electrically 16x.
Actually, they mean that they do have a full 16 lanes. Compare to the 650i, which is at a similar price point, which only supports 8 as you describe, but has a slot designed for 16.
Manufacturer announces slightly different model of thing at lower price. How did this get in? Slow news day?
To be fair, this is a rather unexpected announcement. Usually new motherboards only come up when the chipset manufacturers release new chips. What Asus have done here is to use the existing chips in a way that they weren't originally designed for. And they've come up with a stunning offer: they're beating the price of the next cheapest motherboard on the market with the same feature set by nearly 50%. These things are available now for about £90+VAT; their closest competitor is £140+VAT. For a geek news site, I'd say that's a pretty important story.
If you are downloading more the 5GB then you are definitely a pirate.
Really?
This month I have downloaded (all sizes approximate and from memory):
* Visual C++ Express 2005 (300MB) * Eclipse and a few plugins (200MB) * The Windows Vista SDK (1.2GB) * The Direct X SDK (600MB) * A reasonably complete install of Cygwin (200MB) * Demo versions of Macromedia Flash Studio and Dreamweaver (Total approx 160MB) * Demo versions of Adobe Encore and Adobe Premiere (Total approx 900MB) * A trial version of Nero (300MB) * Microsoft Virtual Server (30MB) along with a VHD image of the evaluation version of Windows 2003 Server Enterprise Edition (1.3GB)
Total: 5.2GB. And that doesn't include web browsing, e-mail downloads, or any other activity I may have performed.
There are probably solutions to this as well (don't allow GET/POST of form variables on redirects, don't allow redirecting at all across domains, don't design web apps with such simple interfaces that can be guessed).
The solution to this requires steps on behalf of both app designers and browser designers:
* Pages that perform potentially harmful actions should only accept data that is POSTed, not URL parameters. Or require a two step process: first request displays a confirmation page, second page will only proceed with time-limited secure code from the first page as a parameter, but this is probably asking too much from most designers. * Pages that submit a form to a different domain than the one that loaded the form should display a warning. App designers who currently do this should stop doing it, so that the warning is rarely seen.
Then again, maybe Star Wars will decline over time?
Probably not. I think you're right that this reflects the badness of the SW prequels. But the truly outstanding (i.e. original SW) lasts a lot longer in the memory than the poor (the prequels), so it's probably only because the prequels are relatively recent additions to the series that this effect is noticeable. In 5 years, it would be as high as ever. Whereas Serenity, being merely in the "really good" category rather than "truly outstanding" will fade much more over time than the surrounding films on the list, many of which were outstanding.
I thought SciFi had something to do with Science in a fictional sense, not fantasy in space...
Well, yes, because of course Star Wars, Blade Runner, Planet of the Apes, The Matrix, etc. are all films that are about science in some way and are completely realistic in all respects.
While I completely agree that Serenity shouldn't have been at the top of that list, what exactly do you claim invalidates it from being science fiction?
Let's be realistic. Star Wars is popular to the point of becoming a cultural phenomenon, and there are more Star Wars fans that are completely obsessed with the franchise than there are people who even saw Serenity. Heck, more people dressed up as Wookies last Halloween than saw Serenity.
Yes, but what's the cross-section of those fans with SFX magazine's readers? My guess is that most of those fans are pretty-much exclusively star wars fans, and therefore likely wouldn't read a general scifi magazine like SFX.
Re:Executing 3rd party code by default is insecure
on
Web 2.0 Under Siege
·
· Score: 1
NoScript seems to be a reasonable compromise. No browser I'm aware of takes this approach by default.
IE7 on default install of Win2K3 with latest updates & service packs does this. Whenever you visit a web site that has javascript, it pops up asking whether you want to add it to the trusted sites list, and blocks the script if you don't.
Re:XML is so last week. What's really wrong.
on
Web 2.0 Under Siege
·
· Score: 3, Interesting
There are several security problems with JSON. First, some web apps parse JSON notation by feeding it into JavaScript's "eval". Now that was dumb.
You don't say. My first thought on hearing about the entire idea was "why would you want to let a foreign server run its code on your page?"
The real problem is JavaScript's excessive dynamism. Because you can redefine objects in one script and have that affect another script from a different source, the language is fundamentally vulnerable.
Err... if I don't let foreign code execute (e.g. by doing 'var e = document.createElement("script"); e.src = "http://www.someotherserver.com/potential-security -risk"; document.body.appendChild (e);', which I've seen many scripts do) how can another site redefine the objects in my script? I think the vulnerability is that most JS programmers are too willing to let other sites execute arbitrary code in their own context, which really ain't good.
The last attempt to fix this problem involved adding restrictions to XMLHttpRequest, but that only plugged some of the holes.
The fix seems obvious to me:
* cookies in subrequests must be tied to the domain of the page that initiated the request as well as the domain the request goes to; this reduces the possibility of CSRF. So if www.a.com has a web page that requests data from www.b.com, it will only send a cookie if www.b.com set one in response to a previous request from www.a.com. This applies to SCRIPT tags, to IFRAME tags, to IMG tags, to LINK tags, etc.
* XMLHttpRequest must not be tied to the same-domain policy. Attempts to access a different domain should result in a request for confirmation from the user for the first time any particular requester/receiver domain pair is used. This means mashups (and other applications that need cross-domain access) can be written that do not need to use JSON. JSON parsing through script insertion or eval() is insecure, and should be deprecated.
As a minimum, it's probably desirable to insist in the browser that, on secure pages, all Javascript and data must come from the main page of the domain. No "mashups" with secure pages.
Scripts, yes. I don't see the need to ensure that data originates in the same domain.
This just sounds like a fancy Cross-Site Request Forgery.
That'll be because it is. It's basically an observation that CSRF on a site which returns data in JSON format allows the attacker to read the content of the result. Well, duh. Of course that happens. It's one of the reasons I've always opposed JSON as a useful format.
The other reason is equally bad, but only applies to "mash up" type situations: the coder of the client has to trust the server with access to all data in the client. This makes it useless in many situations.
The best solution would be to scrap the current security system, make subrequest cookies (including XMLHttpRequests) dependent on both the domain the request goes to *and* the domain of the page that caused the request, and allow XMLHttpRequest to access servers other than the page source. This would both fix CSRF and eliminate the need for JSON. What more do you want?:)
Ignorant media people and unscrupulous "consultants".
My company lost a client last year, because we were realistic with telling him what we could achieve over his web site. Meanwhile a "Web 2.0 consultant" told him that using the power of Web 2.0 he could keep my client's web site in the top google spot for search terms of his choice. My client was gullible enough to believe him.
Even if the script produces an XML result, you can still make the request using the same technique. Thus, if you have a single step method for making some potentially dangerous transaction, that transaction can be performed by an attacker. What they can't do is extract meaningful data from the result.
All of these vulnerabilities show in my mind that the cookie model is fundamentally flawed. Cookies should not be associated with the domain of the server that set them, but the pair (, ). This would also incidentally stop cross-site "browser habit" tracking being performed by people who drop an ad banner on a page.
Eh, the chess programs are mostly just pattern matching against libraries of stored games and brute force projection of all possible moves from a given point. They rank the options and the top option always wins.
That's being rather unfair to chess computers. Yes, these things are involved, but by themselves they are not enough. An average chess game tree has a branching factor of approximately 30. That means when the computer is trying to determine its move there are 30 moves it can make, 900 responses to those moves, 27,000 second moves, ~900,000 responses to those moves, ~30,000,000 third moves... and it typically has to look at least twice as far down the tree as this, within 3 minutes. This isn't possible, unless you do some pretty smart stuff to prioritise branches of the tree that are likely to produce useful results.
Sorry, but I don't think UT's bots were particularly smart at all. They followed preprogrammed paths, and other than what was programmed into those seem totally unaware of concepts like cover, exposure to fire, or even potential obstructions to their own fire. The latter is most evident in the "tactial ops" mod: stand in front of your team mates when the enemy turns up in front of you and see what happens.
If you don't have Windows XP or anything newer, do you really need the newest one?
Yes. Some APIs are available in previous versions, but aren't in earlier PSDKs. The 2005 edition, for instance, doesn't include DirectShow because it was part of the DirectX SDK at the time. It is no longer part of the DirectX SDK, however, and only the last two versions of that SDK appear to be available for download.
You mean this documentation?
Yes, that documentation that should be linked somewhere under the visual studio documentation but isn't, and which MSDN's site search doesn't turn up with obvious seach keywords.;)
Most of my point still stands though: a resource editor is a basic requirement for a Windows IDE, and VS Express lacks one: you have to code the resources by hand. Other free IDEs, like Dev-C++, include this feature, so why have MS removed it?
As I understand it, this observation has already been made, such an effect has been noted, and is what provoked the development of the theory that this new experiment is designed to test.
Looks like you are forgetting to account for the UK VAT. 17.5% is a pretty big chunk of money, and nicely hidden from the consumer that thinks that the company gets all the money.
Well, yes, but they get to reclaim the VAT on the costs of the transaction. So you're probably only effectively paying VAT on 20% or so of the total cost of your tracks.
That said, it's not just 2% charge, it's the infrastructure to support the multiple currencies (now, I don't know, nor do I understand everything that would be required for that, is it as simple as getting payments into your account in Euros/Pounds/Lira/Peso's and having your bank run a batch conversion? Or is the bank taking a transaction fee each time?)
When I set up an e-commerce site that traded in multiple currencies, the way it worked was we sent the currency we wanted payment in along with the request to process a payment to the merchant account handler, and if it wasn't GBP (the primary currency of our account) we were charged a small extra fee. We implemented and tested the feature in less than a day. We didn't charge extra for it, the fee wasn't large enough to warrant it.
Slashdot Mirror
They don't each have a full 16 lanes of signaling backing them up. There is probably 16 total lanes, so if both are in use they get 8 lanes per, despite being electrically 16x.
Actually, they mean that they do have a full 16 lanes. Compare to the 650i, which is at a similar price point, which only supports 8 as you describe, but has a slot designed for 16.
It's hybrid because it uses the northbridge from one chipset and the southbridge from another. Sounds like a reasonable use of the word to me.
Manufacturer announces slightly different model of thing at lower price. How did this get in? Slow news day?
To be fair, this is a rather unexpected announcement. Usually new motherboards only come up when the chipset manufacturers release new chips. What Asus have done here is to use the existing chips in a way that they weren't originally designed for. And they've come up with a stunning offer: they're beating the price of the next cheapest motherboard on the market with the same feature set by nearly 50%. These things are available now for about £90+VAT; their closest competitor is £140+VAT. For a geek news site, I'd say that's a pretty important story.
Add a CPU with an "Eliza" program, a speech synthesizer, a text-to-speech analyser, and add robotic interfaces to the vehicle's motion controls.
I can see it now. "Why do you say let's so double killer delete select all?"
If you are downloading more the 5GB then you are definitely a pirate.
Really?
This month I have downloaded (all sizes approximate and from memory):
* Visual C++ Express 2005 (300MB)
* Eclipse and a few plugins (200MB)
* The Windows Vista SDK (1.2GB)
* The Direct X SDK (600MB)
* A reasonably complete install of Cygwin (200MB)
* Demo versions of Macromedia Flash Studio and Dreamweaver (Total approx 160MB)
* Demo versions of Adobe Encore and Adobe Premiere (Total approx 900MB)
* A trial version of Nero (300MB)
* Microsoft Virtual Server (30MB) along with a VHD image of the evaluation version of Windows 2003 Server Enterprise Edition (1.3GB)
Total: 5.2GB. And that doesn't include web browsing, e-mail downloads, or any other activity I may have performed.
There are probably solutions to this as well (don't allow GET/POST of form variables on redirects, don't allow redirecting at all across domains, don't design web apps with such simple interfaces that can be guessed).
The solution to this requires steps on behalf of both app designers and browser designers:
* Pages that perform potentially harmful actions should only accept data that is POSTed, not URL parameters. Or require a two step process: first request displays a confirmation page, second page will only proceed with time-limited secure code from the first page as a parameter, but this is probably asking too much from most designers.
* Pages that submit a form to a different domain than the one that loaded the form should display a warning. App designers who currently do this should stop doing it, so that the warning is rarely seen.
To be honest, I kind of stopped watching after Phantom Menace. It's been a while now, so maybe I could stomach watching the rest...
Then again, maybe Star Wars will decline over time?
Probably not. I think you're right that this reflects the badness of the SW prequels. But the truly outstanding (i.e. original SW) lasts a lot longer in the memory than the poor (the prequels), so it's probably only because the prequels are relatively recent additions to the series that this effect is noticeable. In 5 years, it would be as high as ever. Whereas Serenity, being merely in the "really good" category rather than "truly outstanding" will fade much more over time than the surrounding films on the list, many of which were outstanding.
I thought SciFi had something to do with Science in a fictional sense, not fantasy in space...
Well, yes, because of course Star Wars, Blade Runner, Planet of the Apes, The Matrix, etc. are all films that are about science in some way and are completely realistic in all respects.
While I completely agree that Serenity shouldn't have been at the top of that list, what exactly do you claim invalidates it from being science fiction?
Let's be realistic. Star Wars is popular to the point of becoming a cultural phenomenon, and there are more Star Wars fans that are completely obsessed with the franchise than there are people who even saw Serenity. Heck, more people dressed up as Wookies last Halloween than saw Serenity.
Yes, but what's the cross-section of those fans with SFX magazine's readers? My guess is that most of those fans are pretty-much exclusively star wars fans, and therefore likely wouldn't read a general scifi magazine like SFX.
NoScript seems to be a reasonable compromise. No browser I'm aware of takes this approach by default.
IE7 on default install of Win2K3 with latest updates & service packs does this. Whenever you visit a web site that has javascript, it pops up asking whether you want to add it to the trusted sites list, and blocks the script if you don't.
There are several security problems with JSON. First, some web apps parse JSON notation by feeding it into JavaScript's "eval". Now that was dumb.
y -risk"; document.body.appendChild (e);', which I've seen many scripts do) how can another site redefine the objects in my script? I think the vulnerability is that most JS programmers are too willing to let other sites execute arbitrary code in their own context, which really ain't good.
You don't say. My first thought on hearing about the entire idea was "why would you want to let a foreign server run its code on your page?"
The real problem is JavaScript's excessive dynamism. Because you can redefine objects in one script and have that affect another script from a different source, the language is fundamentally vulnerable.
Err... if I don't let foreign code execute (e.g. by doing 'var e = document.createElement("script"); e.src = "http://www.someotherserver.com/potential-securit
The last attempt to fix this problem involved adding restrictions to XMLHttpRequest, but that only plugged some of the holes.
The fix seems obvious to me:
* cookies in subrequests must be tied to the domain of the page that initiated the request as well as the domain the request goes to; this reduces the possibility of CSRF. So if www.a.com has a web page that requests data from www.b.com, it will only send a cookie if www.b.com set one in response to a previous request from www.a.com. This applies to SCRIPT tags, to IFRAME tags, to IMG tags, to LINK tags, etc.
* XMLHttpRequest must not be tied to the same-domain policy. Attempts to access a different domain should result in a request for confirmation from the user for the first time any particular requester/receiver domain pair is used. This means mashups (and other applications that need cross-domain access) can be written that do not need to use JSON. JSON parsing through script insertion or eval() is insecure, and should be deprecated.
As a minimum, it's probably desirable to insist in the browser that, on secure pages, all Javascript and data must come from the main page of the domain. No "mashups" with secure pages.
Scripts, yes. I don't see the need to ensure that data originates in the same domain.
This just sounds like a fancy Cross-Site Request Forgery.
:)
That'll be because it is. It's basically an observation that CSRF on a site which returns data in JSON format allows the attacker to read the content of the result. Well, duh. Of course that happens. It's one of the reasons I've always opposed JSON as a useful format.
The other reason is equally bad, but only applies to "mash up" type situations: the coder of the client has to trust the server with access to all data in the client. This makes it useless in many situations.
The best solution would be to scrap the current security system, make subrequest cookies (including XMLHttpRequests) dependent on both the domain the request goes to *and* the domain of the page that caused the request, and allow XMLHttpRequest to access servers other than the page source. This would both fix CSRF and eliminate the need for JSON. What more do you want?
Ignorant media people and unscrupulous "consultants".
My company lost a client last year, because we were realistic with telling him what we could achieve over his web site. Meanwhile a "Web 2.0 consultant" told him that using the power of Web 2.0 he could keep my client's web site in the top google spot for search terms of his choice. My client was gullible enough to believe him.
Even if the script produces an XML result, you can still make the request using the same technique. Thus, if you have a single step method for making some potentially dangerous transaction, that transaction can be performed by an attacker. What they can't do is extract meaningful data from the result.
All of these vulnerabilities show in my mind that the cookie model is fundamentally flawed. Cookies should not be associated with the domain of the server that set them, but the pair (, ). This would also incidentally stop cross-site "browser habit" tracking being performed by people who drop an ad banner on a page.
For an overview, see the Wikipedia article. That has references to some more detailed papers on the subject.
Assuming a strategy like copy-on-write ...
That's not how it works; in unused processor time it scans memory for pages that have identical content and merges them.
Eh, the chess programs are mostly just pattern matching against libraries of stored games and brute force projection of all possible moves from a given point. They rank the options and the top option always wins.
That's being rather unfair to chess computers. Yes, these things are involved, but by themselves they are not enough. An average chess game tree has a branching factor of approximately 30. That means when the computer is trying to determine its move there are 30 moves it can make, 900 responses to those moves, 27,000 second moves, ~900,000 responses to those moves, ~30,000,000 third moves... and it typically has to look at least twice as far down the tree as this, within 3 minutes. This isn't possible, unless you do some pretty smart stuff to prioritise branches of the tree that are likely to produce useful results.
Sorry, but I don't think UT's bots were particularly smart at all. They followed preprogrammed paths, and other than what was programmed into those seem totally unaware of concepts like cover, exposure to fire, or even potential obstructions to their own fire. The latter is most evident in the "tactial ops" mod: stand in front of your team mates when the enemy turns up in front of you and see what happens.
The best part of Google TiSP...
:)
"Insert the TiSP installation CD and run the setup utility to install the Google Toolbar (required)"
If you don't have Windows XP or anything newer, do you really need the newest one?
;)
Yes. Some APIs are available in previous versions, but aren't in earlier PSDKs. The 2005 edition, for instance, doesn't include DirectShow because it was part of the DirectX SDK at the time. It is no longer part of the DirectX SDK, however, and only the last two versions of that SDK appear to be available for download.
You mean this documentation?
Yes, that documentation that should be linked somewhere under the visual studio documentation but isn't, and which MSDN's site search doesn't turn up with obvious seach keywords.
Most of my point still stands though: a resource editor is a basic requirement for a Windows IDE, and VS Express lacks one: you have to code the resources by hand. Other free IDEs, like Dev-C++, include this feature, so why have MS removed it?
As I understand it, this observation has already been made, such an effect has been noted, and is what provoked the development of the theory that this new experiment is designed to test.
And like many X bashers, you are WRONG. Read the XTerm manual. You can configure keys to copy text in to any clipboard. So you can do it with xterm.
OK, so I have to read the manual of the terminal emulator to find out how to copy text in a useful way. That's hardly friendly...
Looks like you are forgetting to account for the UK VAT. 17.5% is a pretty big chunk of money, and nicely hidden from the consumer that thinks that the company gets all the money.
Well, yes, but they get to reclaim the VAT on the costs of the transaction. So you're probably only effectively paying VAT on 20% or so of the total cost of your tracks.
That said, it's not just 2% charge, it's the infrastructure to support the multiple currencies (now, I don't know, nor do I understand everything that would be required for that, is it as simple as getting payments into your account in Euros/Pounds/Lira/Peso's and having your bank run a batch conversion? Or is the bank taking a transaction fee each time?)
When I set up an e-commerce site that traded in multiple currencies, the way it worked was we sent the currency we wanted payment in along with the request to process a payment to the merchant account handler, and if it wasn't GBP (the primary currency of our account) we were charged a small extra fee. We implemented and tested the feature in less than a day. We didn't charge extra for it, the fee wasn't large enough to warrant it.