The idea behind the Range object is the right one, when there is a common task the language should support it. For example having to type:
for(int i = 0; i < length; ++i)
do_stuff(arr[i])
in C is pretty annoying, because it simply expresses:
foreach(v in arr)
do_stuff(v)
in a complicated way. Where the Range object however fails is in syntax, the abstracted concept of a Range should make the task easier, but in the given case it makes it harder. Instead of checking a value against a Range, you are forced to take care of allocating a Range object first. Introducing another point of failure where there wasn't one before. In Ruby the problem is solved better, since a Range object has syntax support, so you write
if (startDate..endDate).includes?(entered_date) then
Another alternative that might be nice would be:
if (startDate <= enteredDate <= endDate)
but that of course clashes with the normal use of the "=" operator and also has the disadvantage that you no longer have an obvious way to store a Range object in a varibale.
Anyway, the idea to simplify common task itself is a good one, because it allows to remove possible points of failure, i.e. in the simple version:
if (EnteredDate >= StartDate) and (EnteredDate <= EndDate)
you have to type EnteredDate twice, not a big thing, but a little annoying and also a possible cause of failure that would be preferable to avoid if possible.
Some programming techniques can be programmed much more elegantly without compile time typing. Could you name some examples? I basically only know three common use cases for mixing types and all of them could also be done via compile time checking:
1) Out-of-Band Error Values:
def do_something():
if blabla:
return 10
else:
return None
So instead of returning a magic value of some sort, the dynamic language gives you the option to return a different type that clearly signals that the return value is not to be meant as a value. But that could be checked statically, since you don't want to return any type, but just int and None. Some people use a templates that wrapper a value in C++ to get a similar effect (i.e. Value foo = 5; if (foo.is_valid()) foo.get();...)
2) Duck Typing:
def draw_object(obj):
obj.draw()
Here you call a draw() method, any object that has a draw method could be used with this one. This is basically the same thing you can do with templates or by declaring a Base class in C++ and while it saves you some typing in Python or Ruby, it is again something that could be checked statically, i.e. obj must be an object that has a draw() method, else the function is going to fail.
This however isn't an advantage, but a downside, since you can express stuff like that much more clearly when you can just indicate that there is a do_stuff(int foo) and a do_stuff(string foo)
The main advantage I see in dynamic languages is that duck-typing allows you to save some typing, since you don't have to write down a base class to define an interface, you simply call the methods. However that isn't really an advantage of the dynamic typing since you can have similar effects in a static language. And of course none of this justifies why there isn't a typed variable. Would it hurt so much to have a any foo; and a int foo; instead of being forced to always use the any type?
Microsoft has no obvious counter at this point. Actually Microsoft has one: a price drop. In Germany the XBox360 Arcade is currently at 200EUR, thats 50EUR less then the Wii and half as much as a PS3. That makes the console look quite attractive. On the other side you are of course right that the XBox360 has plenty of issues. If it wouldn't be for Microsofts own stupidity the XBox360 could have been a great product, but crappy hardware design and totally overprices accessories (WiFi, harddisk,...) steal quite a lot of its attractiveness.
How do I execute your 'fix' without a time machine? 'A' already happened and there is nothing I can do to undo it, other then just accept that it happened and reboot. Even worse, there is also *nothing* I can do to make sure that 'A' never happens again. I can try to remember it, teach others about it, but as long as human do it, they will forget it sooner or later.
Now you could of course argue that the fix with reboot isn't a true fix, but more workaround, and I could agree with that, since it only fixes the problem one has right now, but doesn't try to prevent future trouble. A true fix for this problem would be to fix the Linux kernel or LVM, because the issue at hand is a bug. A common human action shouldn't cause the Kernel to go into an 'confused' state.
You still completly miss my point.
And no, rebooting didn't fix the problem. Symptom: USB drive doesn't work after plugin it in Problem: Linux device names got messed up and LVM got stuck Cause: Me unpluging it without shuting down the VG Fix: Reboot
Now of course a patch to prevent Linux getting into a confused state might be nice or me just remember to shutdown the VG, but none of that will make my USB drive work again. Reboot is the only that will bring Linux out of the confused state again. Reboot fixes the problem, not rebooting leaves Linux in an unusable state. For some problems I can of course get things back to live without rebooting, but for some I can't.
Wii is basically last-gen hardware, meaning you can recycle the engines from the Gamecube and thus save a lot of cost on the coding side. Due to the much less powerful hardware you can also make the textures and models much less detailed then you would on the PS3 or XBox360, thus again you save a lot of cost. Research of course also is much cheaper for the Wii, since most of research in how to use the hardware was already done on the Gamecube, the only thing new is the controller, but other then a bit of waggling there really hasn't been much interesting on that side, so that can't have been very expensive.
Average game length: 30-50 hours. More like 10-20 hours, sometimes even less. The only thing that goes into the 30h are RPGs, everything with a bit of action can be happy to make it past the 10h mark.
Your car analogy misses the point, so here another one:
Your car runs out of fuel because you forget to refuel it. You already know that you should have refueled it earlier and your fuel indicator pointed out the lack of fuel correctly, but you forgot to do so for some reason. Now you can think about what that made you forget it, but none of that thinking will make your car drive again. The problem isn't that you forgot it, but that you are stuck with a car without fuel. You fix that problem by filling new fuel in the tank (reboot), not by thinking about its cause.
Not all problems are systematic and reproducible, something things just get screwed up, it shouldn't happen, but it does happen in any complexer system. Back to my USB drive problem: Yeah, I screwed up, I know why the problem happened, but knowing so won't make by USB drive usable again, rebooting however will. Knowing the cause is nice, but something it helps you nothing to fix the problem, because you can't undo the cause, since it already happened.
I imagine you would only have to wait a few minutes so as the mount process would time out. There was no mount process, because the drive was already unmounted long ago. It was LVM that still kept its old on the device and wouldn't want to let it go. And restarting that did to nothing to fix the problem. Might there be a way to fix it without the reboot? Maybe, but it simply wasn't worth to time to find out, because it was a clear problem with a clear solution: reboot.
rebooting only clears the symptoms No, it clears the *problem*. The problem is that Linux has gotten into a confused state, reboot puts things back into order. Sure, if you don't want to run into the problem again you have to shutdown the volume group properly, but that knowledge helps you nothing if you already messed up.
In the second example, having the right usb devices plug in the correct order seems to be the fix, And how exactly is crawling under the table easier then typing 'reboot'? Let alone that I would of course have to figure out the correct order first and I would have to restart Xorg anyway. It is just an example of Linux having gone into a wrong state, reboot clears that.
The idea that you think a reboot solves it also suggests that you think it is fine for X to freeze. I don't think it is fine, but there is nothing I can do to fix it without rebooting first. Software something screws up, some software more then other and restarting it helps, if it is some important piece of system software a reboot is required. Yeah, you might run into a similar lock situation again in some days/weeks/month, but so what? If it gets annoying enough I look into it, if it just happens once or twice I simply reboot and forget about it. Also there are plenty of ways on how Xorg can get unusable without letting you switch to a console and not always does one have a ssh at hand. And anyway, there really isn't much of a difference between restarting and rebooting anyway, both tasks will destroy all your unsaved work.
What you forget is that Linux isn't a static system and neither a bug free one. When you use it you change its state and sometimes things go wrong and get stuck, see for example processes hanging in 'uninterruptible sleep', you can't even 'kill -9' them and reboot fixes the issue.
Th problem with rebooting to solve problems is that it doesn't solve the problem, That depends on the problem, there are dozens of easy ways to mess Linux up in a way that a reboot will fix the problem.
Simple example, take a USB harddrive, make LVM on it and then unplug it and then try to plug it in again. LVM thinks the thing is still at/dev/sde and reports read errors when you try to access it and even when you try to deactivate the volume group, plugin it in doesn't fix the problem because it is now/dev/sdf, sde is busy with being a dead zombie in the kernel internals. How to fix the issue? Simple, you reboot. Maybe there are other alternatives on how to fix the problem, but reboot is by far the most obvious one and it also works perfectly. Next time one should of course remember to vgchange -a n the volume group before unplugging, but if shit has already happened a reboot fixes it.
Other example, every few dozens reboots my computer tends reorder the USB device names what was event1 before now is event2 and vice a verse, this in turn causes Xorg to fail to startup properly because xorg.conf now points to the wrong devices. Fix? Again, reboot. USB just happens to be not 100% deterministic and when it does something different, reboot can fix it. Sure, I can still take the man page and start to configure udev to assign proper names to the devices so that I don't depend on the order they are detected, but that isn't something I expect average Joe to do, because the problem just happens to seldomly and reboot just fixes it.
Yet another example: Xorg freezes, locks up or otherwise becomes unresponsive, even to console switching. Now I can of course boot another computer and try to ssh into the machine to fix it, but reboot again is the easier alternative.
All that said, if something goes wrong in Linux repeatably it can be worth to investigate, but if the computer just started to craze out a reboot is often the easier alternative.
Do you have a telephone? Do you mind if I call you around the clock to advertise some junk? It is in a open system after all...
Spam these days is nothing more then a denial of service attack on the SMTP network and should be punished as such. Just because it is on open system doesn't mean abuse shouldn't be punished, quite the opposite actually, since it is an option system abuse must be punished, since it is the only way to get rid of it.
The days where it was easy to filter it out by hand and spam was just a little annoyance are long long gone. Today I get around 600 spams per day, it is simply impossible to handle that by hand. Even doing it automatically is a hassle, spamassassin takes around 2 sec per Mail, at 600 spams thats 20 minutes my system is going at 100% CPU for doing exactly nothing and useless for most other things.
True, but using Cygwin under Windows feels like using Wine under Linux, you do it when you have to, but not when you can avoid it, it simply feels alien, not like "The Real Thing"[tm].
I wouldn't call it an 'entrance exam', since any real AI would fail the Turing Test. Simple example:
Questioner: "Calculate me 39^12" AI: "12381557655576425121" Questioner: "That answer came to fast, you are a computer" AI ":'("
You could construct plenty of other cases where a AI would be superior to a human and would fail the test because of that. You could of course also construct plenty of other cases where an AI would have to lie and make stuff up to pass it.
Questioner: "Where did you go to school?" AI: "Never did go to school" Questioner: "Why not?" AI: "Well, you know, not being human and such kinds of makes it hard to visit one"
An AI simply is no human and testing it if it talks and answers like a human is a rather pointless exercise, because you end up with lies and cheats that tell you how to fool a human, but not on how to create something intelligent.
This whole Turing Test thing reminds me of the chess AIs, people thought once they solved chess they would have AI, but what they ended up was a program that could play chess better then any human, but nothing else. Once the Turing Test is solved you will likely have a really elaborate, but also rather useless chat bot.
The thing is that when you build something artificial you don't end up with something that is a perfect replica of the natural thing, but something that solves a similar problem. Look at flight for example, none of our current planes fly like bird, but they do fly none the less and they are also bigger, faster, fly higher and do a multitude of things that real birds don't, but you wouldn't fool a bird watcher with any of them. With AI it will, or already is, pretty much the same, it does stuff that we want it to do, but it doesn't replace a human and it likely won't be for a long while.
Video would require many times more storage Is storage really a problem? You can have gigabytes of solid state memory these days without a problem and in the coming years even more so. Of course a blackbox will not run on of-the-selves memory, but even then a few hours of video don't sound all that tricky. Or for the same matter, why limit the audio to 2 hours? Why not mandate 10 hours so that you have the complete flight recorded, not just the last two hours? Is storage really that much a problem?
They know what the pilot is doing to the controls from the flight data recorder That of course requires that the instruments actually work as they should. More then one plane has gone down due to instruments displaying incorrect values or pilots reading them wrong. A few cameras that actually show what is going on could help clear up a lot in some cases were the audio recording leaves the investigators with a lot of guess work. See for example Helios Airways Flight 522. There also have been accidents where the pilot switched of the working engine, not the damaged one, a little external camera showing the engine would have helped a lot in that case to notice the error before it was to late, even without recording it to a black-box.
I really don't see a good reason to not have cameras, after all when you want to find out what went wrong it is best to have as much information as possible, limiting the recording to audio in times where storage really shouldn't be much of a problem seems rather counterproductive.
Re:Reading... actually reading
on
Reading Comics
·
· Score: 1
Try some earlier comics. When you compare a todays X-Men comic with one from 1975 you will find that a lot of text has gone missing in the years. Today it is mostly just pictures, while back then text and pictures where much more equally used and the pictures where more there to emphasis the text then standing completly on their own. Which is why I find those older comics much easier to read.
I don't believe anyone ever said games for linux had to be open source, or free of charge. I wouldn't say that either, but lack of source is a big problem under Linux. Due to the lack of stable ABIs in Linux it can get extremely complicated to get old binaries to run, it ends up being easier to use the Windows binary under Wine then the Linux one. In addition to that there is of course the problem with Linux often not getting patches, it is often only the Windows version that gets updated, while the Linux port is left in the cold.
It's API is only available on Windows, no other platforms, It is also available for Linux in the form of Wine, if it wouldn't be for nasty copy-protections quite a few games would run out of the box with it. Beside, the graphics API is close to being a non-issue, the PS3 (OpenGL ES) doesn't have DirectX and the Wii (GX) doesn't have it either, yet they get plenty of new games all the time.
The problem is simply that companies target the biggest market, not the niches.
The key point in raytracing vs rasterization is that in classic raytracing you shoot one ray per pixel and then look where it hits an object, while rasterization renders all the triangles in a scene to the screen, no matter if visible or not. This means that you have to process a lot of triangles in rasterization and get a lot of overdraw, so it gets slow with complex scenes, while in raytracing you have just one ray per pixel, no matter how complex the scene, i.e. rasterization scales with O(N) while raytracing is O(log(N)). For small scenes this means that rasterization is faster, while for large scenes it means raytracing is faster, in terms of actual graphics both algorithms so far are exactly the same. The way raytracing works allows you to do some effects that are much harder then rasterization (reflection, shadows, etc.), but that isn't really the main point to do it for realtime, since they all can be approximated "good enough" with normal rasterization.
All that said this is of course a drastic simplification, calculating the tree needed for fast ray/object intersection test takes plenty of time and can't be ignored for dynamic scenes, while rasterization does lots of tricks to render only a small subset of all polygons in a scene. And many current day graphic effects don't really work in either rasterization or raytracing domains, but in the shaders or as post-processing effects on the framebuffer, so you can't really make a clear cut 'rasterization' vs 'raytracing' differentiation when it comes to produce the complete image that you get to see in the end, since it involves a lot of extra tricks which might even come from both domains or none of them.
Very true. Quite a few of 'state of the arts' effects these days come from post-processing done on the color- and depthbuffer, not from anything that is either 'normal' rasterization or raytracing. And even ignoring that, advanced shaders aren't really all that clear cut either, relief mapping is basically raytracing done in the shape of a rasterized polygon. So saying that either rasterization or raytracing will win is quite misleadings, since the future will be a mix of whatever solves the problem at hand. And when it comes to true photorealism you need global illumination algorithms anyway and neither classic rasterization or simple raytracing can do it.
"It's an education project, not a laptop project." I hear that a lot, but for most part it really is a laptop project, a laptop to be used in education, sure, but the hardware and software is pretty much what OLPC is.
Truly, it is a brilliantly simple interface. I wouldn't call it brilliant, at least not right now, it is certainly not bad and having all applications run automatically in fullscreen is a big plus on a small screen, but it still has a long way to go.
Frankly, the Journal is one of the very best parts of the whole thing. In a few month/years, maybe. At the moment the Journal feels still very unfinished and broken. Hardly any Activities provides proper thumbnails or tags/names and thus limit its usefulness quite a bit. What is however worse is that some Activities integration into the Journal is simply completly broken and counter-intuitive. In the simplest case you have something like the Terminal app, which will just fill up your Journal with useless entries. In the worst case you have things like Browse, which will start with a completly empty bookmark collection each time you start it. Having the Bookmarks tied to a Journal entry instead of the Activity itself simply doesn't make much sense. The Journal really needs to keep Activities that create data and activities that just navigate through already existing data seperate, otherwise you just end up in a big mess.
The key point here is to remember that Sugar is for kids. I would disagree with that. There is really nothing in Sugar that is specifically 'for kids'. It is certainly a simplified interface, but that has more to do with the limitations of the hardware then being designed especially 'for kids'. What the Journal does is really not all that different from what Beagle or other Desktop search engines try to do, only that the Journal goes a step further and hides the underlying file-system completly instead of just adding stuff on top of it.
All that said, I like Sugar too, but it still has quite a while to go before it provides a fully smooth experience.
The image library can be constantly grown. So can the spammers database. Sure it will work for a small webpage with an individual database, but it would never work for Google or the rest of the world, since as soon as you start sharing the database you make it very easy for the spammers.
A few image alterations won't really help, sure they make the job a little harder, but just matching two fixed images is very easy.
A way that it could work is if you remove the image database and replace it with 3D models that are then rendered at random angles and with changes in texture, size and posture, so the spammer doesn't have anything fixed to match against, while it is trivial for the server to know what he is rendering.
KittenAuth seems to be trivial to crack, you simply download the images, categorize them by hand and then use a bot to do the matching against the set of current images. Since you don't have a unlimited supply of images you will quickly run into trouble.
Slashdot Mirror
The idea behind the Range object is the right one, when there is a common task the language should support it. For example having to type:
for(int i = 0; i < length; ++i)
do_stuff(arr[i])
in C is pretty annoying, because it simply expresses:
foreach(v in arr)
do_stuff(v)
in a complicated way. Where the Range object however fails is in syntax, the abstracted concept of a Range should make the task easier, but in the given case it makes it harder. Instead of checking a value against a Range, you are forced to take care of allocating a Range object first. Introducing another point of failure where there wasn't one before. In Ruby the problem is solved better, since a Range object has syntax support, so you write
if (startDate..endDate).includes?(entered_date) then
Another alternative that might be nice would be:
if (startDate <= enteredDate <= endDate)
but that of course clashes with the normal use of the "=" operator and also has the disadvantage that you no longer have an obvious way to store a Range object in a varibale.
Anyway, the idea to simplify common task itself is a good one, because it allows to remove possible points of failure, i.e. in the simple version:
if (EnteredDate >= StartDate) and (EnteredDate <= EndDate)
you have to type EnteredDate twice, not a big thing, but a little annoying and also a possible cause of failure that would be preferable to avoid if possible.
Erlang is one of the few languages that is build around concurrency.
1) Out-of-Band Error Values:
def do_something():
if blabla:
return 10
else:
return None
So instead of returning a magic value of some sort, the dynamic language gives you the option to return a different type that clearly signals that the return value is not to be meant as a value. But that could be checked statically, since you don't want to return any type, but just int and None. Some people use a templates that wrapper a value in C++ to get a similar effect (i.e. Value foo = 5; if (foo.is_valid()) foo.get();
2) Duck Typing:
def draw_object(obj):
obj.draw()
Here you call a draw() method, any object that has a draw method could be used with this one. This is basically the same thing you can do with templates or by declaring a Base class in C++ and while it saves you some typing in Python or Ruby, it is again something that could be checked statically, i.e. obj must be an object that has a draw() method, else the function is going to fail.
3) Function overloading:
def do_stuff(foo):
if type(foo) == int:
do_this()
elif type(foo) == str:
do_that()
This however isn't an advantage, but a downside, since you can express stuff like that much more clearly when you can just indicate that there is a do_stuff(int foo) and a do_stuff(string foo)
The main advantage I see in dynamic languages is that duck-typing allows you to save some typing, since you don't have to write down a base class to define an interface, you simply call the methods. However that isn't really an advantage of the dynamic typing since you can have similar effects in a static language. And of course none of this justifies why there isn't a typed variable. Would it hurt so much to have a any foo; and a int foo; instead of being forced to always use the any type?
This is also interesting Sir Arthur C Clarke: 90th Birthday Reflections
How do I execute your 'fix' without a time machine? 'A' already happened and there is nothing I can do to undo it, other then just accept that it happened and reboot. Even worse, there is also *nothing* I can do to make sure that 'A' never happens again. I can try to remember it, teach others about it, but as long as human do it, they will forget it sooner or later.
Now you could of course argue that the fix with reboot isn't a true fix, but more workaround, and I could agree with that, since it only fixes the problem one has right now, but doesn't try to prevent future trouble. A true fix for this problem would be to fix the Linux kernel or LVM, because the issue at hand is a bug. A common human action shouldn't cause the Kernel to go into an 'confused' state.
Problem: Linux device names got messed up and LVM got stuck
Cause: Me unpluging it without shuting down the VG
Fix: Reboot
Now of course a patch to prevent Linux getting into a confused state might be nice or me just remember to shutdown the VG, but none of that will make my USB drive work again. Reboot is the only that will bring Linux out of the confused state again. Reboot fixes the problem, not rebooting leaves Linux in an unusable state. For some problems I can of course get things back to live without rebooting, but for some I can't.
Wii is basically last-gen hardware, meaning you can recycle the engines from the Gamecube and thus save a lot of cost on the coding side. Due to the much less powerful hardware you can also make the textures and models much less detailed then you would on the PS3 or XBox360, thus again you save a lot of cost. Research of course also is much cheaper for the Wii, since most of research in how to use the hardware was already done on the Gamecube, the only thing new is the controller, but other then a bit of waggling there really hasn't been much interesting on that side, so that can't have been very expensive.
Your car analogy misses the point, so here another one:
Your car runs out of fuel because you forget to refuel it. You already know that you should have refueled it earlier and your fuel indicator pointed out the lack of fuel correctly, but you forgot to do so for some reason. Now you can think about what that made you forget it, but none of that thinking will make your car drive again. The problem isn't that you forgot it, but that you are stuck with a car without fuel. You fix that problem by filling new fuel in the tank (reboot), not by thinking about its cause.
Not all problems are systematic and reproducible, something things just get screwed up, it shouldn't happen, but it does happen in any complexer system. Back to my USB drive problem: Yeah, I screwed up, I know why the problem happened, but knowing so won't make by USB drive usable again, rebooting however will. Knowing the cause is nice, but something it helps you nothing to fix the problem, because you can't undo the cause, since it already happened.
What you forget is that Linux isn't a static system and neither a bug free one. When you use it you change its state and sometimes things go wrong and get stuck, see for example processes hanging in 'uninterruptible sleep', you can't even 'kill -9' them and reboot fixes the issue.
Simple example, take a USB harddrive, make LVM on it and then unplug it and then try to plug it in again. LVM thinks the thing is still at
Other example, every few dozens reboots my computer tends reorder the USB device names what was event1 before now is event2 and vice a verse, this in turn causes Xorg to fail to startup properly because xorg.conf now points to the wrong devices. Fix? Again, reboot. USB just happens to be not 100% deterministic and when it does something different, reboot can fix it. Sure, I can still take the man page and start to configure udev to assign proper names to the devices so that I don't depend on the order they are detected, but that isn't something I expect average Joe to do, because the problem just happens to seldomly and reboot just fixes it.
Yet another example: Xorg freezes, locks up or otherwise becomes unresponsive, even to console switching. Now I can of course boot another computer and try to ssh into the machine to fix it, but reboot again is the easier alternative.
All that said, if something goes wrong in Linux repeatably it can be worth to investigate, but if the computer just started to craze out a reboot is often the easier alternative.
Do you have a telephone? Do you mind if I call you around the clock to advertise some junk? It is in a open system after all...
Spam these days is nothing more then a denial of service attack on the SMTP network and should be punished as such. Just because it is on open system doesn't mean abuse shouldn't be punished, quite the opposite actually, since it is an option system abuse must be punished, since it is the only way to get rid of it.
The days where it was easy to filter it out by hand and spam was just a little annoyance are long long gone. Today I get around 600 spams per day, it is simply impossible to handle that by hand. Even doing it automatically is a hassle, spamassassin takes around 2 sec per Mail, at 600 spams thats 20 minutes my system is going at 100% CPU for doing exactly nothing and useless for most other things.
True, but using Cygwin under Windows feels like using Wine under Linux, you do it when you have to, but not when you can avoid it, it simply feels alien, not like "The Real Thing"[tm].
I wouldn't call it an 'entrance exam', since any real AI would fail the Turing Test. Simple example:
Questioner: "Calculate me 39^12"
AI: "12381557655576425121"
Questioner: "That answer came to fast, you are a computer"
AI ":'("
You could construct plenty of other cases where a AI would be superior to a human and would fail the test because of that. You could of course also construct plenty of other cases where an AI would have to lie and make stuff up to pass it.
Questioner: "Where did you go to school?"
AI: "Never did go to school"
Questioner: "Why not?"
AI: "Well, you know, not being human and such kinds of makes it hard to visit one"
An AI simply is no human and testing it if it talks and answers like a human is a rather pointless exercise, because you end up with lies and cheats that tell you how to fool a human, but not on how to create something intelligent.
This whole Turing Test thing reminds me of the chess AIs, people thought once they solved chess they would have AI, but what they ended up was a program that could play chess better then any human, but nothing else. Once the Turing Test is solved you will likely have a really elaborate, but also rather useless chat bot.
The thing is that when you build something artificial you don't end up with something that is a perfect replica of the natural thing, but something that solves a similar problem. Look at flight for example, none of our current planes fly like bird, but they do fly none the less and they are also bigger, faster, fly higher and do a multitude of things that real birds don't, but you wouldn't fool a bird watcher with any of them. With AI it will, or already is, pretty much the same, it does stuff that we want it to do, but it doesn't replace a human and it likely won't be for a long while.
I really don't see a good reason to not have cameras, after all when you want to find out what went wrong it is best to have as much information as possible, limiting the recording to audio in times where storage really shouldn't be much of a problem seems rather counterproductive.
Try some earlier comics. When you compare a todays X-Men comic with one from 1975 you will find that a lot of text has gone missing in the years. Today it is mostly just pictures, while back then text and pictures where much more equally used and the pictures where more there to emphasis the text then standing completly on their own. Which is why I find those older comics much easier to read.
The problem is simply that companies target the biggest market, not the niches.
The key point in raytracing vs rasterization is that in classic raytracing you shoot one ray per pixel and then look where it hits an object, while rasterization renders all the triangles in a scene to the screen, no matter if visible or not. This means that you have to process a lot of triangles in rasterization and get a lot of overdraw, so it gets slow with complex scenes, while in raytracing you have just one ray per pixel, no matter how complex the scene, i.e. rasterization scales with O(N) while raytracing is O(log(N)). For small scenes this means that rasterization is faster, while for large scenes it means raytracing is faster, in terms of actual graphics both algorithms so far are exactly the same. The way raytracing works allows you to do some effects that are much harder then rasterization (reflection, shadows, etc.), but that isn't really the main point to do it for realtime, since they all can be approximated "good enough" with normal rasterization.
All that said this is of course a drastic simplification, calculating the tree needed for fast ray/object intersection test takes plenty of time and can't be ignored for dynamic scenes, while rasterization does lots of tricks to render only a small subset of all polygons in a scene. And many current day graphic effects don't really work in either rasterization or raytracing domains, but in the shaders or as post-processing effects on the framebuffer, so you can't really make a clear cut 'rasterization' vs 'raytracing' differentiation when it comes to produce the complete image that you get to see in the end, since it involves a lot of extra tricks which might even come from both domains or none of them.
Very true. Quite a few of 'state of the arts' effects these days come from post-processing done on the color- and depthbuffer, not from anything that is either 'normal' rasterization or raytracing. And even ignoring that, advanced shaders aren't really all that clear cut either, relief mapping is basically raytracing done in the shape of a rasterized polygon. So saying that either rasterization or raytracing will win is quite misleadings, since the future will be a mix of whatever solves the problem at hand. And when it comes to true photorealism you need global illumination algorithms anyway and neither classic rasterization or simple raytracing can do it.
All that said, I like Sugar too, but it still has quite a while to go before it provides a fully smooth experience.
A few image alterations won't really help, sure they make the job a little harder, but just matching two fixed images is very easy.
A way that it could work is if you remove the image database and replace it with 3D models that are then rendered at random angles and with changes in texture, size and posture, so the spammer doesn't have anything fixed to match against, while it is trivial for the server to know what he is rendering.
KittenAuth seems to be trivial to crack, you simply download the images, categorize them by hand and then use a bot to do the matching against the set of current images. Since you don't have a unlimited supply of images you will quickly run into trouble.