Javascript already has the ability to read any file on your computer and send it to the server via the input type=file element. If you're OK with that, then this is no different. And it could be quite useful when paired with a GPS; imagine turn-by-turn directions with voice prompts in Google Maps, for instance.
Well, it displays the https, but in bright red with a huge strikeout line over it. Which is an interesting solution. It still doesn't address the problem that the security properties of the https url scheme will change if browsers start accepting self-signed certs. If you change the meaning of the "https" scheme, there will be no way to specify that a link should be protected against man-in-the-middle attacks. That's why you need to either introduce a new URL scheme that doesn't promise man-in-the-middle attack protection, or implement opportunistic encryption for http links like suggested in the article.
There are lots of situations where it makes sense to use a different url scheme for the same protocol. However, I think the method of certificate verification could legitimately be called part of the protocol.
There are certainly plenty of people who don't know what https is, but I believe there's a huge middle ground of people who don't have a cryptographer's understanding of man-in-the-middle attacks, but do know that "https" is supposed to be secure. It wasn't that long ago that secure sites were instructing people to look for "https" in their URLs; some still do. Further argument on this point is rather pointless without some actual data.
"httpi" wasn't a serious proposal anyway; I think we can all agree that the article proposed the best solution. If all traffic was encrypted by default, self-signed SSL (SSSSL?) would become irrelevant.
The problem is you can't not display the "https". Also, the security of existing links (bookmarks, for example) using the "https" scheme is affected. Right now if you have an https link you know before even clicking it that either it will be fully secure or rejected. Adding a third option that requires checking the lock icon and making a judgement about the likelihood of man-in-the-middle attacks is a non-starter for browser vendors. Educating everyone in the world about man-in-the-middle attacks and when to worry about them is simply not an option.
Maybe what is needed is a new URL scheme (httpi://?) for self-signed SSL. That way the security of existing https links is unaffected. It would be really nice, though, if you could just use "http" as the scheme and automatically get self-signed cert security when both the server and client support it. Hey! That's exactly what the article proposes! Imagine that!
I'd say you're vastly overestimating the expertise and professionalism of wireless mic users in general. I'm sure *you* do a great job, but these things are sold practically unrestricted to the general public. My high school and college's auditoriums didn't have any RF experts, and neither does my boss's conference room, but that doesn't stop them from using wireless mics. The *average* user of a wireless mic is hardly more likely to be an RF expert than the users of white space devices will be.
if their device decided to employ the same strategy, it would interfere with the operating microphone within the analog television channel.
But the Google device will *not* use the same strategy. If there is an operating analog or digital TV station, the device will *not* use that frequency. So it's irrelevant whether or not the device can detect mics on the same frequency as a TV channel. As long as it detects one or the other, it won't interfere with either.
Notably, Vimeo allows people to download the original uploaded video, not just the re-encoded Flash version (which is still much better than YouTube quality-wise).
Re:We need to go in the other direction
on
Chrome Vs. IE 8
·
· Score: 3, Interesting
Yes, it's completely open source. Mozilla takes the exact same approach of a "blessed" official binary compiled from the freely-available sources.
Chrome may not be worth booting Windows for, but there will be a Linux version as soon as some Linux people finish porting it, and if you are paranoid about Google's official version I'm sure the Debian folks will be happy to oblige with "Matte" or whatever they end up calling their rebranded Chrome builds (c.f. IceWeasel).
Fitts' law is hardly irrelevant; it's a very important UI design principle. Wikipedia is your friend. That isn't the only non-obvious improvement Google's made to tabbed browsing either. The subtle animations are cool but perhaps the nicest thing is the way tabs don't resize as you close them, until you mouse away. It's hard to describe but it fixes a major annoyance every other tabbed browser has when closing several tabs at once in a crowded window. The implementation of tab dragging is also quite nice, the popup blocker UI is unobtrusive, the status bar only appears when you need it. Overall, the minimalistic UI uses up the least space of any browser's UI (by far), leaving more screen real estate for pages.
Your only valid complaint is that there's no add-ons, so no noscript, flashblock, adblock, GreaseMonkey, etc. I feel confident that open-source hackers will fix this soon, though Google may decide not to include support in the official Google builds.
Re:We need to go in the other direction
on
Chrome Vs. IE 8
·
· Score: 5, Interesting
You don't see anything useful huh? Process separation improving security and responsiveness, UI improvements like Fitts'-law-obeying tabs, Incognito mode; those aren't useful to you?
Oh, and you do know that Chrome doesn't index your hard drive or send your browsing history to Google, right? It really doesn't have any more "integration" with Google Search (or GMail, or G-anything-else) than Firefox does. And you don't have to take Google's word for it because it's open source.
Interesting; I was under the impression that Mozilla used the Boehm conservative collector. I guess I was wrong. Can SpiderMonkey move objects to improve locality?
AppJet is pretty cool. It's a great way to write a little one-off web app. You don't have to worry about installing anything, getting hosting, etc etc. You just type some code into the browser-based IDE and you're done.
Yup, the Canvas element is a start, but it's pretty limited in its capabilities. I don't see much movement toward 3D. The demos are nice but at least in the case of Firefox, that's one guy's experiment. It's not being seriously considered for inclusion in any planned Firefox release that I know of, or for inclusion in any standard. Even the people writing the browsers and the standards still don't take the web seriously enough as a platform to advocate for good 3D graphics support to rival native apps. When the new JIT compilers come out and people start writing interesting apps that do client-side heavy-lifting computation and UI in Javascript, maybe that will change.
I completely agree that the potential for programming education in the browser is huge. We're already seeing some of that with Processing.js. Firebug is half an IDE already. Imagine if we could go back to the days when every computer came with programming tools pre-installed, only now it's all in the browser.
Sorry, I guess I'm shooting my mouth off, as I haven't read the paper you reference. My beef with reference counting is that every implementation I have ever seen royally sucked. What tends to happen is when C++ people realize that RAII isn't enough for everything, and plain malloc/free is too dangerous, they stubbornly refuse to even think about using a garbage collection library (or, heaven forfend, a language with garbage collection built in). Instead, for some reason they all get it in their heads to reinvent reference counting, poorly.
These terrible reference counting implementations don't include any of the features that make garbage collection good. It is still possible (sometimes easy) to mess up your reference counts and leak or prematurely free. They don't have cycle collectors. They can't move objects to improve locality. Their debugging support is terrible, so trying to find out why a reference count is not what you expect is painful.
So my comment is aimed at these common, terrible implementations of reference counting, not the ideal of a "perfect" reference counter (which includes so many features of a tracing collector that it might as well be called one anyway). Note that Mozilla uses reference counting, but didn't even have a cycle collector until sometime last year. As I understand it, IE used reference counting without a cycle collector for DOM objects for years as well; perhaps they still do. This, accessible to Javascript from any random website you happen to visit. It's a travesty.
There are no "capabilities" V8 will have that other Javascript engines don't. The multi-process thing is an implementation detail; processes aren't exposed to Javascript. It will just be faster and more reliable. And actually, it might not even be faster, as when it comes out it won't be the only Javascript JIT compiler around. Firefox 3.1 will have one, and you've gotta imagine that Apple is working on one too.
If anyone is likely to add new and incompatible features to Javascript, it's Mozilla. They are the most active in improving Javascript since their whole application is written in it; they tend to release new Javascript language features first. For example, Firefox 3.1 is going to expose a new threads API.
Actually, there are a lot of "big change" projects going on in Firefox right now, under the collective name "Mozilla 2". Mozilla is taking the smart approach and doing everything incrementally, so there's not going to be one day where "Mozilla 2" replaces "Mozilla 1", but there is a lot of development effort going on right now. It started with moving Mozilla development from CVS to Mercurial. Now, the recently announced TracingMonkey Javascript JIT compiler is part of Mozilla 2, and will be in Firefox 3.1. Further away are huge refactorings to address some of the shortcomings of Mozilla's legacy XPCOM architecture, done mechanically by automatic refactoring tools that are being written specifically for the task.
The V8 Javascript engine sounds like a huge improvement as well. Finally, precise, incremental garbage collection for Javascript! I'm hoping this is the beginning of the end for conservative garbage collection and (ugh!) reference counting. The JIT sounds good as well but there will be stiff competition in this area from Firefox 3.1 with TracingMonkey, and SquirrelFish is nothing to sneeze at either.
Now that Javascript performance is on its way to being solved, and local storage and offline mode are close to becoming standard, the last bastion of non-Web applications is graphics. Browsers still don't provide a graphics API that could seriously challenge native apps for things like image and video editing, 3D graphics and games. VRML and SVG don't work as graphics APIs. Some people have forgotten, but we learned long ago that immediate mode is the only way to do graphics; scene graphs/retained mode are a dead end. We need OpenGL ES in the browser.
Looking even further ahead: if OpenCL was exposed to web applications as well, there's practically nothing that couldn't be done in a web app. At that point, Windows becomes irrelevant, and Microsoft's monopoly is finally broken.
Hopefully Google Chrome can attack that problem too. Imagine what Google could do if they threw their entire weight behind replacing Internet Explorer. They could advertise prominently on the most valuable real estate on the Web: the Google home page. But perhaps more importantly, they could do deals with OEMs. If they got Dell and HP to make Google Chrome the default browser on their PCs, over half of the US PC market would be defaulting to something other than IE. Now wouldn't that be something...
Two problems there; firstly Larrabee will probably run closer to 1.5-2 GHz. Right now many GPUs run in the <1 GHz range, believe it or not. Secondly, performance may not scale linearly with GHz; other bottlenecks like memory bandwidth might get in the way.
I do agree that the potential for flexibility in the software rendering is very exciting, but Intel will have trouble getting people to write custom code to take full advantage of it. What Larrabee really needs is to be in XBox 720 or PS4. In that situation people could go crazy writing totally custom renderers and it could really change how graphics is done.
Intel *is* aiming at gamers. Why does everyone think otherwise? Intel has said *repeatedly* "We are in this to win the graphics card performance crown and dominate the graphics card market."
Why does Intel want the graphics card market now? It's because Intel is afraid of GPGPU. NVIDIA cards are now in the second fastest supercomputer in the world, doing jobs Intel's CPUs are supposed to be doing. That's scaring Intel, because they like their position as the top dog in the computer chip market.
So Intel needs a GPGPU chip. However, the GPGPU market isn't large enough, by itself, to support a gigantic development effort like Larrabee. In order to have a business case for developing Larrabee, it has to be able to sell in the gaming market, which is much larger. Larrabee is only viable as a business venture if Intel can sell enough of them to make a profit, and the gaming market is where that volume has to come from.
That debate has for the most part been confined to speculation in various media outlets. It is obvious to everyone in the graphics community that Larrabee will be optimized for rasterization. It would not be possible to sell a graphics card that did not get comparable performance to ATI/NVIDIA in today's games, which means DirectX/OpenGL, which means rasterization. Intel wants to sell Larrabee, so it will have to rasterize extremely well. If Intel has to make a decision between optimizing a piece for rasterization or ray tracing, rasterization is going to win.
That said, Intel is purposely taking the most general approach possible to the rasterization problem. They are attempting to avoid *having* to choose between optimizing for rasterization and optimizing for everything else. Thus Larabee will be better than any other GPU for raytracing. And not just raytracing either; Larrabee will be better than other GPUs at practically every task that is not rasterized 3D graphics.
Well it's really a little of both. The only piece of hardware on Larrabee which is *definitely* GPU-specific is the fixed-function texture sampling hardware (which implements trilinear sampling, anisotropic filtering, and texture decompression). The rest of it is basically just a multicore CPU, where each CPU has something like an expanded MMX/SSE unit (4x the size, with some new and interesting features), and all the 3D stuff (shaders, z-buffering, clipping, etc) is implemented in software on top of that.
Larrabee will be sold as a GPU, at least for the first few years. But there's really nothing stopping it from being used as a massively multicore main CPU and I'm sure that's the direction it will eventually take. You may see a Larrabee with one "big" core plus dozens of small cores, or it may turn out that the small cores are good enough and we'll just stop buying separate CPUs at all.
Larabee is not about winning the 3d performance crown
I beg to differ. Nobody will buy Larrabee unless there's software for it, but nobody will write the software until there's a large market of Larrabees out there to run it on. Luckily the entire library of PC games can be made to run on Larrabee via DirectX/OpenGL, and that's Intel's way around this problem. However, in order for this to work the price/performance has to be competitive. Intel's best bet is to use their superior fabrication facilities to produce a high-end part that AMD and NVIDIA just can't match in raw performance, instead of trying to compete on price in the middle of the market with their first product. So yes, Larrabee *is* about winning the 3D performance crown; at least in the short term.
Whoa there. Don't worry, I haven't made up my mind to agree with McDowell; I'm not arguing for or against him. As a Libertarian I do want to see as little regulation as possible, but the problem is the communications market is already hugely distorted by government involvement. As long as we continue to purposely grant regional monopolies to communications companies, we are going to need a bunch of additional regulations to rein them in; that's a fact. Regulation begets more regulation. I don't oppose network neutrality laws on principle just because they're regulations; I just think that curing the disease is more important than treating the symptoms.
I think a real cure would involve having the government install and maintain a fiber-optic cable infrastructure. It makes sense for the government to be involved here (even for a Libertarian) because communications infrastructure, much like transportation infrastructure, is a "natural monopoly". However, the government should have no role in providing services or content. Instead, private ISPs would lease capacity to provide service to customers. Then, separately from your ISP, you would get your phone, TV, etc service, all over IP. With a market set up like this, ISPs and service providers could all compete on a level playing field, and competition could solve most of the market's problems, instead of regulation.
The only problem in this scheme would be the temptation for government to assert control over the Internet through its ownership of the wires. I'm sure the morality police would have a field day, and we'd see things analogous to how the "national" drinking age is enforced through federal highway fund appropriations today. You can never trust the government to leave power on the table...
It is literally true that having the government force ISPs to do something is "regulating" the Internet; saying this is not at all disingenuous. You can debate whether the regulation is good, but like it or not it *is* regulation. Let's call a spade a spade.
Personally, I think the root of the whole problem is that our communications companies are too vertically integrated. Today's communications behemoths (for example Time-Warner) own everything: the wires, the services, and the content. A more competitive market would see the wires owned by one set of companies, the services provided by another set, and the content owned by a third set.
It's easy to understand how things got this way; in the past the technology didn't allow for this kind of separation. When phone service needed a dedicated set of wires, separate from TV service wires, and when the TV service wires all had to meet at a central office that broadcast the same content to everyone, it made sense for the companies to be vertically integrated. Now that Internet Protocol allows every kind of communication service to share the same wires, regardless of the physical location of the endpoints, the structure of our communications marketplace no longer makes sense.
If there's any regulation the Internet needs, it is regulation to break up the vertically integrated communications companies. If you could choose your wire provider separately from your ISP, and again separately from your TV and phone service providers, then competition would actually be able to work.
No. The XNA store is the exclusive distribution channel for sandboxed programs written with a $99 subscription and free SDK on a DRM-locked architecture, where they can be distributed for a 30% fee provided they adhere to a raft of restrictions. But it doesn't allow free apps. You caught me; my analogy is flawed.
Slashdot Mirror
Javascript already has the ability to read any file on your computer and send it to the server via the input type=file element. If you're OK with that, then this is no different. And it could be quite useful when paired with a GPS; imagine turn-by-turn directions with voice prompts in Google Maps, for instance.
Well, it displays the https, but in bright red with a huge strikeout line over it. Which is an interesting solution. It still doesn't address the problem that the security properties of the https url scheme will change if browsers start accepting self-signed certs. If you change the meaning of the "https" scheme, there will be no way to specify that a link should be protected against man-in-the-middle attacks. That's why you need to either introduce a new URL scheme that doesn't promise man-in-the-middle attack protection, or implement opportunistic encryption for http links like suggested in the article.
There are lots of situations where it makes sense to use a different url scheme for the same protocol. However, I think the method of certificate verification could legitimately be called part of the protocol.
There are certainly plenty of people who don't know what https is, but I believe there's a huge middle ground of people who don't have a cryptographer's understanding of man-in-the-middle attacks, but do know that "https" is supposed to be secure. It wasn't that long ago that secure sites were instructing people to look for "https" in their URLs; some still do. Further argument on this point is rather pointless without some actual data.
"httpi" wasn't a serious proposal anyway; I think we can all agree that the article proposed the best solution. If all traffic was encrypted by default, self-signed SSL (SSSSL?) would become irrelevant.
The problem is you can't not display the "https". Also, the security of existing links (bookmarks, for example) using the "https" scheme is affected. Right now if you have an https link you know before even clicking it that either it will be fully secure or rejected. Adding a third option that requires checking the lock icon and making a judgement about the likelihood of man-in-the-middle attacks is a non-starter for browser vendors. Educating everyone in the world about man-in-the-middle attacks and when to worry about them is simply not an option.
Maybe what is needed is a new URL scheme (httpi://?) for self-signed SSL. That way the security of existing https links is unaffected. It would be really nice, though, if you could just use "http" as the scheme and automatically get self-signed cert security when both the server and client support it. Hey! That's exactly what the article proposes! Imagine that!
I'd say you're vastly overestimating the expertise and professionalism of wireless mic users in general. I'm sure *you* do a great job, but these things are sold practically unrestricted to the general public. My high school and college's auditoriums didn't have any RF experts, and neither does my boss's conference room, but that doesn't stop them from using wireless mics. The *average* user of a wireless mic is hardly more likely to be an RF expert than the users of white space devices will be.
But the Google device will *not* use the same strategy. If there is an operating analog or digital TV station, the device will *not* use that frequency. So it's irrelevant whether or not the device can detect mics on the same frequency as a TV channel. As long as it detects one or the other, it won't interfere with either.
I probably don't have to tell you this, but it's worth pointing out anyway that the *vast* majority of wireless microphones are actually technically illegal. Unless you have paid $75 to the FCC and been granted a license, you are using wireless microphones illegally. The fact that the FCC chooses not to enforce this, but comes down so hard on white space devices, is really a double standard.
Notably, Vimeo allows people to download the original uploaded video, not just the re-encoded Flash version (which is still much better than YouTube quality-wise).
Yes, it's completely open source. Mozilla takes the exact same approach of a "blessed" official binary compiled from the freely-available sources.
Chrome may not be worth booting Windows for, but there will be a Linux version as soon as some Linux people finish porting it, and if you are paranoid about Google's official version I'm sure the Debian folks will be happy to oblige with "Matte" or whatever they end up calling their rebranded Chrome builds (c.f. IceWeasel).
Fitts' law is hardly irrelevant; it's a very important UI design principle. Wikipedia is your friend. That isn't the only non-obvious improvement Google's made to tabbed browsing either. The subtle animations are cool but perhaps the nicest thing is the way tabs don't resize as you close them, until you mouse away. It's hard to describe but it fixes a major annoyance every other tabbed browser has when closing several tabs at once in a crowded window. The implementation of tab dragging is also quite nice, the popup blocker UI is unobtrusive, the status bar only appears when you need it. Overall, the minimalistic UI uses up the least space of any browser's UI (by far), leaving more screen real estate for pages.
Your only valid complaint is that there's no add-ons, so no noscript, flashblock, adblock, GreaseMonkey, etc. I feel confident that open-source hackers will fix this soon, though Google may decide not to include support in the official Google builds.
You don't see anything useful huh? Process separation improving security and responsiveness, UI improvements like Fitts'-law-obeying tabs, Incognito mode; those aren't useful to you?
Oh, and you do know that Chrome doesn't index your hard drive or send your browsing history to Google, right? It really doesn't have any more "integration" with Google Search (or GMail, or G-anything-else) than Firefox does. And you don't have to take Google's word for it because it's open source.
Interesting; I was under the impression that Mozilla used the Boehm conservative collector. I guess I was wrong. Can SpiderMonkey move objects to improve locality?
AppJet is pretty cool. It's a great way to write a little one-off web app. You don't have to worry about installing anything, getting hosting, etc etc. You just type some code into the browser-based IDE and you're done.
My sig in AppJet.
Yup, the Canvas element is a start, but it's pretty limited in its capabilities. I don't see much movement toward 3D. The demos are nice but at least in the case of Firefox, that's one guy's experiment. It's not being seriously considered for inclusion in any planned Firefox release that I know of, or for inclusion in any standard. Even the people writing the browsers and the standards still don't take the web seriously enough as a platform to advocate for good 3D graphics support to rival native apps. When the new JIT compilers come out and people start writing interesting apps that do client-side heavy-lifting computation and UI in Javascript, maybe that will change.
I completely agree that the potential for programming education in the browser is huge. We're already seeing some of that with Processing.js. Firebug is half an IDE already. Imagine if we could go back to the days when every computer came with programming tools pre-installed, only now it's all in the browser.
Sorry, I guess I'm shooting my mouth off, as I haven't read the paper you reference. My beef with reference counting is that every implementation I have ever seen royally sucked. What tends to happen is when C++ people realize that RAII isn't enough for everything, and plain malloc/free is too dangerous, they stubbornly refuse to even think about using a garbage collection library (or, heaven forfend, a language with garbage collection built in). Instead, for some reason they all get it in their heads to reinvent reference counting, poorly.
These terrible reference counting implementations don't include any of the features that make garbage collection good. It is still possible (sometimes easy) to mess up your reference counts and leak or prematurely free. They don't have cycle collectors. They can't move objects to improve locality. Their debugging support is terrible, so trying to find out why a reference count is not what you expect is painful.
So my comment is aimed at these common, terrible implementations of reference counting, not the ideal of a "perfect" reference counter (which includes so many features of a tracing collector that it might as well be called one anyway). Note that Mozilla uses reference counting, but didn't even have a cycle collector until sometime last year. As I understand it, IE used reference counting without a cycle collector for DOM objects for years as well; perhaps they still do. This, accessible to Javascript from any random website you happen to visit. It's a travesty.
There are no "capabilities" V8 will have that other Javascript engines don't. The multi-process thing is an implementation detail; processes aren't exposed to Javascript. It will just be faster and more reliable. And actually, it might not even be faster, as when it comes out it won't be the only Javascript JIT compiler around. Firefox 3.1 will have one, and you've gotta imagine that Apple is working on one too.
If anyone is likely to add new and incompatible features to Javascript, it's Mozilla. They are the most active in improving Javascript since their whole application is written in it; they tend to release new Javascript language features first. For example, Firefox 3.1 is going to expose a new threads API.
Actually, there are a lot of "big change" projects going on in Firefox right now, under the collective name "Mozilla 2". Mozilla is taking the smart approach and doing everything incrementally, so there's not going to be one day where "Mozilla 2" replaces "Mozilla 1", but there is a lot of development effort going on right now. It started with moving Mozilla development from CVS to Mercurial. Now, the recently announced TracingMonkey Javascript JIT compiler is part of Mozilla 2, and will be in Firefox 3.1. Further away are huge refactorings to address some of the shortcomings of Mozilla's legacy XPCOM architecture, done mechanically by automatic refactoring tools that are being written specifically for the task.
The V8 Javascript engine sounds like a huge improvement as well. Finally, precise, incremental garbage collection for Javascript! I'm hoping this is the beginning of the end for conservative garbage collection and (ugh!) reference counting. The JIT sounds good as well but there will be stiff competition in this area from Firefox 3.1 with TracingMonkey, and SquirrelFish is nothing to sneeze at either.
Now that Javascript performance is on its way to being solved, and local storage and offline mode are close to becoming standard, the last bastion of non-Web applications is graphics. Browsers still don't provide a graphics API that could seriously challenge native apps for things like image and video editing, 3D graphics and games. VRML and SVG don't work as graphics APIs. Some people have forgotten, but we learned long ago that immediate mode is the only way to do graphics; scene graphs/retained mode are a dead end. We need OpenGL ES in the browser.
Looking even further ahead: if OpenCL was exposed to web applications as well, there's practically nothing that couldn't be done in a web app. At that point, Windows becomes irrelevant, and Microsoft's monopoly is finally broken.
Hopefully Google Chrome can attack that problem too. Imagine what Google could do if they threw their entire weight behind replacing Internet Explorer. They could advertise prominently on the most valuable real estate on the Web: the Google home page. But perhaps more importantly, they could do deals with OEMs. If they got Dell and HP to make Google Chrome the default browser on their PCs, over half of the US PC market would be defaulting to something other than IE. Now wouldn't that be something...
Two problems there; firstly Larrabee will probably run closer to 1.5-2 GHz. Right now many GPUs run in the <1 GHz range, believe it or not. Secondly, performance may not scale linearly with GHz; other bottlenecks like memory bandwidth might get in the way.
I do agree that the potential for flexibility in the software rendering is very exciting, but Intel will have trouble getting people to write custom code to take full advantage of it. What Larrabee really needs is to be in XBox 720 or PS4. In that situation people could go crazy writing totally custom renderers and it could really change how graphics is done.
Intel *is* aiming at gamers. Why does everyone think otherwise? Intel has said *repeatedly* "We are in this to win the graphics card performance crown and dominate the graphics card market."
Why does Intel want the graphics card market now? It's because Intel is afraid of GPGPU. NVIDIA cards are now in the second fastest supercomputer in the world, doing jobs Intel's CPUs are supposed to be doing. That's scaring Intel, because they like their position as the top dog in the computer chip market.
So Intel needs a GPGPU chip. However, the GPGPU market isn't large enough, by itself, to support a gigantic development effort like Larrabee. In order to have a business case for developing Larrabee, it has to be able to sell in the gaming market, which is much larger. Larrabee is only viable as a business venture if Intel can sell enough of them to make a profit, and the gaming market is where that volume has to come from.
That debate has for the most part been confined to speculation in various media outlets. It is obvious to everyone in the graphics community that Larrabee will be optimized for rasterization. It would not be possible to sell a graphics card that did not get comparable performance to ATI/NVIDIA in today's games, which means DirectX/OpenGL, which means rasterization. Intel wants to sell Larrabee, so it will have to rasterize extremely well. If Intel has to make a decision between optimizing a piece for rasterization or ray tracing, rasterization is going to win.
That said, Intel is purposely taking the most general approach possible to the rasterization problem. They are attempting to avoid *having* to choose between optimizing for rasterization and optimizing for everything else. Thus Larabee will be better than any other GPU for raytracing. And not just raytracing either; Larrabee will be better than other GPUs at practically every task that is not rasterized 3D graphics.
Well it's really a little of both. The only piece of hardware on Larrabee which is *definitely* GPU-specific is the fixed-function texture sampling hardware (which implements trilinear sampling, anisotropic filtering, and texture decompression). The rest of it is basically just a multicore CPU, where each CPU has something like an expanded MMX/SSE unit (4x the size, with some new and interesting features), and all the 3D stuff (shaders, z-buffering, clipping, etc) is implemented in software on top of that.
Larrabee will be sold as a GPU, at least for the first few years. But there's really nothing stopping it from being used as a massively multicore main CPU and I'm sure that's the direction it will eventually take. You may see a Larrabee with one "big" core plus dozens of small cores, or it may turn out that the small cores are good enough and we'll just stop buying separate CPUs at all.
I beg to differ. Nobody will buy Larrabee unless there's software for it, but nobody will write the software until there's a large market of Larrabees out there to run it on. Luckily the entire library of PC games can be made to run on Larrabee via DirectX/OpenGL, and that's Intel's way around this problem. However, in order for this to work the price/performance has to be competitive. Intel's best bet is to use their superior fabrication facilities to produce a high-end part that AMD and NVIDIA just can't match in raw performance, instead of trying to compete on price in the middle of the market with their first product. So yes, Larrabee *is* about winning the 3D performance crown; at least in the short term.
Whoa there. Don't worry, I haven't made up my mind to agree with McDowell; I'm not arguing for or against him. As a Libertarian I do want to see as little regulation as possible, but the problem is the communications market is already hugely distorted by government involvement. As long as we continue to purposely grant regional monopolies to communications companies, we are going to need a bunch of additional regulations to rein them in; that's a fact. Regulation begets more regulation. I don't oppose network neutrality laws on principle just because they're regulations; I just think that curing the disease is more important than treating the symptoms.
I think a real cure would involve having the government install and maintain a fiber-optic cable infrastructure. It makes sense for the government to be involved here (even for a Libertarian) because communications infrastructure, much like transportation infrastructure, is a "natural monopoly". However, the government should have no role in providing services or content. Instead, private ISPs would lease capacity to provide service to customers. Then, separately from your ISP, you would get your phone, TV, etc service, all over IP. With a market set up like this, ISPs and service providers could all compete on a level playing field, and competition could solve most of the market's problems, instead of regulation.
The only problem in this scheme would be the temptation for government to assert control over the Internet through its ownership of the wires. I'm sure the morality police would have a field day, and we'd see things analogous to how the "national" drinking age is enforced through federal highway fund appropriations today. You can never trust the government to leave power on the table...
It is literally true that having the government force ISPs to do something is "regulating" the Internet; saying this is not at all disingenuous. You can debate whether the regulation is good, but like it or not it *is* regulation. Let's call a spade a spade.
Personally, I think the root of the whole problem is that our communications companies are too vertically integrated. Today's communications behemoths (for example Time-Warner) own everything: the wires, the services, and the content. A more competitive market would see the wires owned by one set of companies, the services provided by another set, and the content owned by a third set.
It's easy to understand how things got this way; in the past the technology didn't allow for this kind of separation. When phone service needed a dedicated set of wires, separate from TV service wires, and when the TV service wires all had to meet at a central office that broadcast the same content to everyone, it made sense for the companies to be vertically integrated. Now that Internet Protocol allows every kind of communication service to share the same wires, regardless of the physical location of the endpoints, the structure of our communications marketplace no longer makes sense.
If there's any regulation the Internet needs, it is regulation to break up the vertically integrated communications companies. If you could choose your wire provider separately from your ISP, and again separately from your TV and phone service providers, then competition would actually be able to work.
No. The XNA store is the exclusive distribution channel for sandboxed programs written with a $99 subscription and free SDK on a DRM-locked architecture, where they can be distributed for a 30% fee provided they adhere to a raft of restrictions. But it doesn't allow free apps. You caught me; my analogy is flawed.