Friend, I think you're confusing me with someone in another thread, because I haven't said anything about whether XUL or Objective J is "better", all I'm claiming is that they are "different". They address different solutions, serve different purposes, are not competing for the same market.
It doesn't matter whether the back end has to be built in ruby or not (and I suspect you're mixing up Objective J and SproutCore, there, but it doesn't matter whether you are or not because I'm not talking about the internal security of the application), if it doesn't run in a sandbox it can't be used as an embedded applet in an arbitrary web page, and if it does it can. Contrariwise, if it runs in a sandbox it can't be used to create a general purpose local application, and if it doesn't it can.
These are two completely separate roles. There is no relationship between them. Attempting to combine the two into a single framework has had such a poor security track record that I'm sure you're not proposing that either of these is suitable for that benighted role.
As for your five bucks, now I'm *sure* you're confusing me with someone else, because I don't bet.
My point is that it's solving a different problem than XUL, so it's not "reinventing XUL". For the things Objective-J is designed to do, you couldn't use XUL, and for the things XUL is designed to do, you couldn't use Objective-J. There's no point of contact, other than the fact that they're both using ECMAscript. You might as well compare Konfabulator and Flash, and complain that Flash isn't standalone and doesn't let you save local state, or that you can't embed Konfabulator widgets in a web page.
Hilarious! Nice try. No, their WinMob Treos sucked.
I'm not sure what you're talking about. Palm's decision to start selling the Windows Mobile platform happened long after the events I described.
Palm is a hardware company, first and foremost.
Palm's hardware is unexceptional. They were, like Cisco and Apple, a software company that books revenue through hardware sales. If Cisco started selling routers without IOS or Apple started selling iPods running Windows Mobile and Macs without Mac OS X, they would quickly find themselves in the same place as Palm... in a death spiral.
Palm may be able to reinvent themselves as a hardware company, but if so they will have to start making hardware that is a good deal better designed than what I've seen them ship. I have only bought one actual *Palm* running PalmOS, and *that* was used. My current handheld is a Clie SJ22, and when it dies I dare say I will probably have to buy another on eBay... I went through multiple handhelds before I settled on it (I think I still have a Visor and an iPaq somewhere, I've also had a Jornada and a Palm V), and I've seen nothing since to make me regret my purchase.
They may be able to put together a Linux-based platform that will work, but the overhead of Linux and WinCE are simply way disproportionate to the requirements of a handheld, and going up against Microsoft and HP and the rest of the well-funded companies that have been doing the same thing for longer is not going to pull them out of the hole unless they have something infinitely better than Android, Familiar, or the Zaurus suite... AND something mind-bogglingly great in the hardware department.
Never get involved in a land war in Asia, and never go up against Microsoft on their own ground.
Microsoft sucked them in to attacking Microsoft on their own ground, trying to turn the Palm organizer into a laptop replacement comparable in capabilities to the Pocket PC, instead of gradually expanding the Palm's capabilities as Moore's Law let it get cheaper and cheaper and sell to more and more people. The Zire should have been followed by more cheaper Dragonball-based devices pushing down to pocket-calculator prices, instead of sinking resources into a new operating system.
That's the tactic that HAD kept Microsoft's market share under 20% well after the "Pocket PC" was supposedly sweeping them aside. Abandoning PalmOS 4, getting sucked into the Second Coming of the BeOS Disaster, and bringing Hawkins and his corporate ADHD back in, completely blew any hope they had. They simply had no strategy and no hope of creating a new one.
If they'd stayed with PalmOS 4 they could have had Palms on an endcap in every supermarket in the country, with an effective monopoly in that market giving them decent margins even at calculator prices. That's a market that Microsoft has no hope of getting into... they have no OS that will run on hardware that cheap. Even if they only cleared 20% of the profit they got from each "T" they'd be selling 20 TIMES as many units.
But Microsoft sucked them in, they hitched a ride on a burned-out star, and they're done.
"But these data show that consciousness is just the tip of the iceberg. This doesn't rule out free will, but it does make it implausible."
Consciousness is not thought, or reasoning, it's the narrative that you tell yourself about yourself. It's not even the tip of the iceberg, it's a flashlight that turns itself on to reassure itself that the iceberg is still there, it's a model of the iceberg made of fog and seaspray and drifting snow. All this is doing is confirming what's been increasingly obvious for decades: you are not your conscious self, any more than a computer is its display, or a corporation its lobby, or a nation its flag and national bird.
So this says nothing about free will, because your will is not what you're thinking about, it's why you're thinking about it.
The fellow who wrote those words needs to meet Mister Volition.
With real geometry, you'll quickly run into memory bandwidth issues, as every single ray can potentially access any part of the geometry.
The available memory bandwidth on the RPU was less than the Rage II... to be precise, 350 MB/s (RPU, 2005) versus 480 MB/s on the Rage II.
The ATI v8650 has 111 GB/s, roughly 30 times the memory bandwidth on the RPU.
With that memory bandwidth, and a truncated version of the SaarCOR design to fit the constraints of the FPGA, the most complex scene in the SIGgraph paper was only using 60% of the available memory bandwidth with 200M polygons. It only got 4fps for that one, so it was probably bandwidth-constrained... but even assuming there's no other possible opportunities for speedups, I don't see any reason you shouldn't be able to beat 100 FPS on the SunCOR scene at a reasonable resolution, using an RPU built with 2008-quality hardware instead of 1997-quality hardware (yes, the RPU was built in 2005, the Rage II beats it in every spec).
Then you have to realize that people still tend to form groups, even if it's 5 people, or 50 or whatever. So the long tail pictured in all the literature is a smoothed out version of what's actually there. There's the exponential decay but if you zoom into that line, you'll have a series of peaks and valleys where groups form. If you sell to those groups, you can make money.
If you want to find the groups, last.fm is doing the research for you for free!
If you sell to those groups, you can make money. The spaces in between have no customers, and there are a lot of those spaces.
What if it doesn't cost you anything to keep the stuff that ends up in the spaces?
For instance, dogpoo.com is probably not going to sell too many units. However, tumbleweeds.com will.
There's plenty of sites making a steady income from hosting self-acknowledged horrible stuff just because people keep coming back to it.
In the "blockbuster" model you don't concentrate on "the top 10000" or even "the top 1000", you push very very few products... a dozen at most (the example they use of book publishing... they only pushed *two* blockbuster titles at a time).
The article is turning that over, and interpreting "the long tail" as being only the "anti blockbusters", the products selling a few copies a year. But once you have the product in your digital inventory you're paying virtually nothing to keep it alive, so instead of trying to figure out what the top forty next month is going to be so you can stock your stores with it, and shoveling albums out into the cold after six months on the shelves, you *can* keep it all available.
It's not a matter of "this end vs that end", it's "you don't need to worry about the ends".
Raytracing only costs less than what you have to do to get almost-as-good results with rasterizing because you've got a dedicated hardware rasterizer that cost more than your CPU doing the job for you.
Philipp Slusallek demonstrated a hardware raytracing engine in 2005 that was handling realtime raytracing despite being implemented on an FPGA with about as many gates as (and at a slower clock than) a Rage II... contemporary GPUs were running at 8x the clock and had 100 times the gates, not to mention more VRAM and memory bandwidth. And raytracing is embarrassingly parallelizable, so even if you couldn't do more than stamp that design out a few dozen times (and you could do a lot better than that, the RPU he demoed in 2005 had been severely cut back to fit in the constraints of the FPGA) we could have been handling the raytracing in hardware by now.
Kind of, though a restricted interpreter in Tcl is in some ways more secure than the Java sandbox because it doesn't just add checks blocking "dangerous" calls from the Safe interpreter. Instead it completely removes them from the interpreter's symbol table. Not only can't the interpreter "do" unsafe things, it can't even think about doing them.:)
Hey, I was all about opening up the TLDs back in the '80s, I worked on getting one of the first open TLDs (.dot) running under The Internet Namespace Cooperative (TINC). But it doesn't matter any more.
Because "COM" is "the" top level. Who the hell cares about "name" or "per" or the rest of the "we are not COM, but..." domains? It's too late, it's a done deal, "COM" is the top level, everything else is parochial.
So don't fight over who's going to be ".sex", people will still pay more for "sex.com", and when you say your email address is "you@yourname" you better make sure that "you@yourname.com" works as well.
What is traditionally referred to as raytracing would require immense numbers of rays to do caustics. To handle those, one needs to combine ray tracing with other methods, such as photon tracing.
"Photon tracing" is raytracing, starting from the light source. It's the same algorithm, so raytracing hardware (like an RPU) should also accelerate it.
[global illumination] just means taking indirect light into account.
Generating multiple secondary rays gets the same results, albeit at a higher cost. And to get correct indirect illumination you still need to generate many of those secondary rays to handle local shadowing. Again, raytracing hardware would come in handy.
And many of those work just as well for rasterizing.
So do addition and subtraction, indirection, and object-oriented programming, but you wouldn't argue that a raytracer that used these wasn't a raytracer.
most of the interesting features were only implemented in 1 browser or were implemented in multiple browsers in different ways.
Javascript's been unfairly tainted by the horrible class *libraries* thrown together for reasons both benign and malicious (or at least based on lock-in rather than portability) in browsers. The lack of a good standalone Javascript is a problem, but not a problem in the design of the language.
if you do enable variable to be any type and let the structure of your code be modified at runtime in the client browser this a big hole to security for web 2.0 applications
Javascript needs the ability to control secondary interpreters, like Tcl does, so you can create explicit sandboxes at the script level like SafeTcl does.
You wouldn't do this to Array, you'd do this to (for example) display widgets that you don't have the source to, so you can instrument or extend code in a library you don't have source to that uses the widgets you don't have source to...
Slashdot Mirror
Forth and Scheme can be impressively small and tight, and are about as far from C as anything you're likely to run into.
Friend, I think you're confusing me with someone in another thread, because I haven't said anything about whether XUL or Objective J is "better", all I'm claiming is that they are "different". They address different solutions, serve different purposes, are not competing for the same market.
It doesn't matter whether the back end has to be built in ruby or not (and I suspect you're mixing up Objective J and SproutCore, there, but it doesn't matter whether you are or not because I'm not talking about the internal security of the application), if it doesn't run in a sandbox it can't be used as an embedded applet in an arbitrary web page, and if it does it can. Contrariwise, if it runs in a sandbox it can't be used to create a general purpose local application, and if it doesn't it can.
These are two completely separate roles. There is no relationship between them. Attempting to combine the two into a single framework has had such a poor security track record that I'm sure you're not proposing that either of these is suitable for that benighted role.
As for your five bucks, now I'm *sure* you're confusing me with someone else, because I don't bet.
My point is that it's solving a different problem than XUL, so it's not "reinventing XUL". For the things Objective-J is designed to do, you couldn't use XUL, and for the things XUL is designed to do, you couldn't use Objective-J. There's no point of contact, other than the fact that they're both using ECMAscript. You might as well compare Konfabulator and Flash, and complain that Flash isn't standalone and doesn't let you save local state, or that you can't embed Konfabulator widgets in a web page.
XUL extensions can modify parts of the user interface outside the displayed window or website, access local files, even run local unsandboxed code.
This is implemented entirely in Javascript, so runs inside the sandbox.
Hilarious! Nice try. No, their WinMob Treos sucked.
I'm not sure what you're talking about. Palm's decision to start selling the Windows Mobile platform happened long after the events I described.
Palm is a hardware company, first and foremost.
Palm's hardware is unexceptional. They were, like Cisco and Apple, a software company that books revenue through hardware sales. If Cisco started selling routers without IOS or Apple started selling iPods running Windows Mobile and Macs without Mac OS X, they would quickly find themselves in the same place as Palm... in a death spiral.
Palm may be able to reinvent themselves as a hardware company, but if so they will have to start making hardware that is a good deal better designed than what I've seen them ship. I have only bought one actual *Palm* running PalmOS, and *that* was used. My current handheld is a Clie SJ22, and when it dies I dare say I will probably have to buy another on eBay... I went through multiple handhelds before I settled on it (I think I still have a Visor and an iPaq somewhere, I've also had a Jornada and a Palm V), and I've seen nothing since to make me regret my purchase.
They may be able to put together a Linux-based platform that will work, but the overhead of Linux and WinCE are simply way disproportionate to the requirements of a handheld, and going up against Microsoft and HP and the rest of the well-funded companies that have been doing the same thing for longer is not going to pull them out of the hole unless they have something infinitely better than Android, Familiar, or the Zaurus suite... AND something mind-bogglingly great in the hardware department.
And, frankly, I don't see that happening.
Never get involved in a land war in Asia, and never go up against Microsoft on their own ground.
Microsoft sucked them in to attacking Microsoft on their own ground, trying to turn the Palm organizer into a laptop replacement comparable in capabilities to the Pocket PC, instead of gradually expanding the Palm's capabilities as Moore's Law let it get cheaper and cheaper and sell to more and more people. The Zire should have been followed by more cheaper Dragonball-based devices pushing down to pocket-calculator prices, instead of sinking resources into a new operating system.
That's the tactic that HAD kept Microsoft's market share under 20% well after the "Pocket PC" was supposedly sweeping them aside. Abandoning PalmOS 4, getting sucked into the Second Coming of the BeOS Disaster, and bringing Hawkins and his corporate ADHD back in, completely blew any hope they had. They simply had no strategy and no hope of creating a new one.
If they'd stayed with PalmOS 4 they could have had Palms on an endcap in every supermarket in the country, with an effective monopoly in that market giving them decent margins even at calculator prices. That's a market that Microsoft has no hope of getting into... they have no OS that will run on hardware that cheap. Even if they only cleared 20% of the profit they got from each "T" they'd be selling 20 TIMES as many units.
But Microsoft sucked them in, they hitched a ride on a burned-out star, and they're done.
There's a reason they have higher insurance premiums.
"But these data show that consciousness is just the tip of the iceberg. This doesn't rule out free will, but it does make it implausible."
Consciousness is not thought, or reasoning, it's the narrative that you tell yourself about yourself. It's not even the tip of the iceberg, it's a flashlight that turns itself on to reassure itself that the iceberg is still there, it's a model of the iceberg made of fog and seaspray and drifting snow. All this is doing is confirming what's been increasingly obvious for decades: you are not your conscious self, any more than a computer is its display, or a corporation its lobby, or a nation its flag and national bird.
So this says nothing about free will, because your will is not what you're thinking about, it's why you're thinking about it.
The fellow who wrote those words needs to meet Mister Volition.
URL? Or did you hear this from Dr Evil?
With real geometry, you'll quickly run into memory bandwidth issues, as every single ray can potentially access any part of the geometry.
The available memory bandwidth on the RPU was less than the Rage II... to be precise, 350 MB/s (RPU, 2005) versus 480 MB/s on the Rage II.
The ATI v8650 has 111 GB/s, roughly 30 times the memory bandwidth on the RPU.
With that memory bandwidth, and a truncated version of the SaarCOR design to fit the constraints of the FPGA, the most complex scene in the SIGgraph paper was only using 60% of the available memory bandwidth with 200M polygons. It only got 4fps for that one, so it was probably bandwidth-constrained... but even assuming there's no other possible opportunities for speedups, I don't see any reason you shouldn't be able to beat 100 FPS on the SunCOR scene at a reasonable resolution, using an RPU built with 2008-quality hardware instead of 1997-quality hardware (yes, the RPU was built in 2005, the Rage II beats it in every spec).
Then you have to realize that people still tend to form groups, even if it's 5 people, or 50 or whatever. So the long tail pictured in all the literature is a smoothed out version of what's actually there. There's the exponential decay but if you zoom into that line, you'll have a series of peaks and valleys where groups form. If you sell to those groups, you can make money.
If you want to find the groups, last.fm is doing the research for you for free!
If you sell to those groups, you can make money. The spaces in between have no customers, and there are a lot of those spaces.
What if it doesn't cost you anything to keep the stuff that ends up in the spaces?
For instance, dogpoo.com is probably not going to sell too many units. However, tumbleweeds.com will.
There's plenty of sites making a steady income from hosting self-acknowledged horrible stuff just because people keep coming back to it.
In the "blockbuster" model you don't concentrate on "the top 10000" or even "the top 1000", you push very very few products... a dozen at most (the example they use of book publishing... they only pushed *two* blockbuster titles at a time).
The article is turning that over, and interpreting "the long tail" as being only the "anti blockbusters", the products selling a few copies a year. But once you have the product in your digital inventory you're paying virtually nothing to keep it alive, so instead of trying to figure out what the top forty next month is going to be so you can stock your stores with it, and shoveling albums out into the cold after six months on the shelves, you *can* keep it all available.
It's not a matter of "this end vs that end", it's "you don't need to worry about the ends".
Friend, if you were to rear-end a jet engine... that would be the least of your worries.
Raytracing costs a lot, and the payback small.
Raytracing only costs less than what you have to do to get almost-as-good results with rasterizing because you've got a dedicated hardware rasterizer that cost more than your CPU doing the job for you.
Philipp Slusallek demonstrated a hardware raytracing engine in 2005 that was handling realtime raytracing despite being implemented on an FPGA with about as many gates as (and at a slower clock than) a Rage II... contemporary GPUs were running at 8x the clock and had 100 times the gates, not to mention more VRAM and memory bandwidth. And raytracing is embarrassingly parallelizable, so even if you couldn't do more than stamp that design out a few dozen times (and you could do a lot better than that, the RPU he demoed in 2005 had been severely cut back to fit in the constraints of the FPGA) we could have been handling the raytracing in hardware by now.
In most other countries, the local ccTLD is the default where people look for company websites.
Granted, but that doesn't make a skerrick of difference to my point: you're still not going to look for www.at.google instead of google.co.at, yesno?
What, you mean like in your car's engine?
(yes, I know what a pulse jet is, I'm making fun of Fox News)
Kind of, though a restricted interpreter in Tcl is in some ways more secure than the Java sandbox because it doesn't just add checks blocking "dangerous" calls from the Safe interpreter. Instead it completely removes them from the interpreter's symbol table. Not only can't the interpreter "do" unsafe things, it can't even think about doing them. :)
20 years?
Ye Gods, I think if we "give it 20 years", anything could happen.
20 years ago the Internet was something only geeks knew about, and the closest thing to the world wide web was Hypercard.
Hey, I was all about opening up the TLDs back in the '80s, I worked on getting one of the first open TLDs (.dot) running under The Internet Namespace Cooperative (TINC). But it doesn't matter any more.
Because "COM" is "the" top level. Who the hell cares about "name" or "per" or the rest of the "we are not COM, but..." domains? It's too late, it's a done deal, "COM" is the top level, everything else is parochial.
So don't fight over who's going to be ".sex", people will still pay more for "sex.com", and when you say your email address is "you@yourname" you better make sure that "you@yourname.com" works as well.
What is traditionally referred to as raytracing would require immense numbers of rays to do caustics. To handle those, one needs to combine ray tracing with other methods, such as photon tracing.
"Photon tracing" is raytracing, starting from the light source. It's the same algorithm, so raytracing hardware (like an RPU) should also accelerate it.
[global illumination] just means taking indirect light into account.
Generating multiple secondary rays gets the same results, albeit at a higher cost. And to get correct indirect illumination you still need to generate many of those secondary rays to handle local shadowing. Again, raytracing hardware would come in handy.
And many of those work just as well for rasterizing.
So do addition and subtraction, indirection, and object-oriented programming, but you wouldn't argue that a raytracer that used these wasn't a raytracer.
I don't know if it's remotely obvious, but it's locally obvious.
most of the interesting features were only implemented in 1 browser or were implemented in multiple browsers in different ways.
Javascript's been unfairly tainted by the horrible class *libraries* thrown together for reasons both benign and malicious (or at least based on lock-in rather than portability) in browsers. The lack of a good standalone Javascript is a problem, but not a problem in the design of the language.
if you do enable variable to be any type and let the structure of your code be modified at runtime in the client browser this a big hole to security for web 2.0 applications
Javascript needs the ability to control secondary interpreters, like Tcl does, so you can create explicit sandboxes at the script level like SafeTcl does.
You wouldn't do this to Array, you'd do this to (for example) display widgets that you don't have the source to, so you can instrument or extend code in a library you don't have source to that uses the widgets you don't have source to...
Crikey, I thought I was joking.