That were exactly my thoughts the other day as I was preparing a birthday gift for my mother. You can imagine the kind and multitude and last but not least, the kind of generics the applications she needs to run;-) Even two years ago, I could not with a confidence in my heart propose a Linux based desktop to her. Today I feel I can, given I run my desktop completely hassle free, and I do quite a lot more things on it than she will ever imagine. Even Skype, albeit proprietary, something she uses, exists on Linux. I am thinking she might like a Linux based netbook.
As to ARM, i think even if Nintendo DS ran its own bizarre set of instructions, CISC or RISC, ARM could handle an emulator, a re-compiler or something entirely different. RISC is also generic enough to be used for a whole multitude of applications. You write a piece of code that translates Nintendo DS code into ARM instruction set. Given enough time anything is possible, just take a look at the variety of SEGA Genesis, 3DO and Nindendo 64 emulators for Windows out there.
Basically you are proposing using the ARM chip as the C-P-U, and the other two as its slave PUs:-) Not a bad idea at all, in fact that is exactly how I would have built that tree.
The trouble with most modern laptops, is that even when completely unattended, doing no work that the user expects any results of anytime, just by being 'on', these seldom consume below 5 Watts of power, and in their factory config about usually 15 (nobody bothers with configuring power management). I am talking about a laptop that is lid-closed, radios (wifi, bluetooth) off, not doing ANYTHING for you.
It may be a small part of the CPU, but a very usable still. Very simple - throwing aside RISC vs CISC comparison, grouping several smaller instructions into a bigger specialized macro instruction that helps in certain cases is called optimization, and optimization gains even more when hard coded in silicon. That is why, RISC always makes sense ALONG CISC and vice versa. They complement each other, where a complex (CISC) instruction may be chosen away in favour of its (RISC) components (Think inline assembler in a C++ code), and also groups of RISC instructions can be substituted by a single specialized CISC call which will speed up the application. And since, as you say, the logic takes up small part of the die, let it sit there and be taken advantage of. A much better idea is instead to OPEN the RISC subset of an Intel/AMD CPU, provided it is standardised of course (you dont want at least two different RISC sets under a common CISC set, and they are different now, being hidden and proprietary and all). Seeing as it might never happen, ARM chips of the future seem like a much more realistic scenario, even more so if they add some CISC decoders for special common cases (the whole point and 'strength' of CISC). But I have to point out that optimizing by grouping RISC instructions into CISC macro ops is very very hard, because RISC instructions are so fast (by their very nature), even calling them in groups in memory is usually fast enough to not warrant a hardware CISC decoder on-die. That is one of the reasons Intel and AMD went RISC internally with their x86 designs a while ago too. RISC is FAST. CISC is fast only because it specializes, branches, decodes and optimizes RISC in hardware. All complex things can be split into smaller parts, why have access only to the engine, when you can use even the smallest gear, bolt and O-ring.
It just begs a question, for WHOM REALLY is Windows and its software a limiting factor? It looks now as if the only people who just would die from not having access to Windows are those who put their whole commerce on it and people who sit and play the latest games. ALMOST everyone else has had choice for at least a year now, and that choice is rapidly improving. Heck, I did not know what Linux really was a year ago, and now I do not see which things is it that it cannot do. I have my text input app, a media player, a web browser (albeit with Adobe's Flash player), and a usable desktop. I even have a video editing application (Avidemux) that actually works. Anyhow, all it takes is some faith. But sadly, that is something that comes only AFTER hope, not before, and right now Microsoft is feeding the world.
WINE is portable enough to build on ARM, I am pretty sure. This solves some of the Oh-What-About-Windows problem, does it not?
Also, if Wine wont do it, maybe, just MAYBE, QEMU/kvm/Xen will;-)
Really, Windows is just a stone, a stone so large nobody can seem to go around it anymore, but there are ways for those who wish strong enough. At least, why not try it? The whole x86 world is so boring. Even NASA uses ARM chips, and it seems to be good enough for them. What, it cannot decode an MP3?
RAM is for being used. Unused RAM is waste. Firefox gives up its allocations by the way at the request of the host system, a request both at least Windows kernels do when either real or virtual memory is close to running out, and also when minimizing application windows. Not sure if Linux does that though. If you want Firefox to take less space, take out a RAM module, that will force Firefox to be more modest. But it is pointless, is it not?
The real question is, does Firefox allocate as little memory as it can do with and provide exactly as much performance and features that the user requires?
As a programmer, I had plenty of occasions to version my algorithms into variants where one would work fast but cache stuff into memory, thus blowing up its commit charge (used memory), or work slower but use much less memory while working. I do not know how Firefox devs decided how much RAM is a good usage on average, but with the size of Firefox code, they, I am sure, had plenty of chances to version their algorithms too, and they decided to give it some good speeds AND ability to slow down the way I described. You can search Google for Firefox 3 memory optimization.
I do not understand which problem we are trying to solve by leaving out packages out of the distribution? Is it the fact that the system runs faster without MySQL, for instance? If that seems to be the problem, I assure you the real problem is not in the total size of the installed software, which is handled easily by large hard drives even netbooks these days have, but in the archaic rigid logic of todays software where unused features somehow still end up eating CPU cycles, getting in the way of user experience. The situation where unsuspecting novice laptop customers get SPAM loaded Windows systems that needs thorough cleaning before getting usable, is THE perfect example that illustrates the problem and its nuances.
How much effort (man-hours) has already been put into your project? It appears your whitepaper is hastily drafted, and so my conclusion is everything is pretty much in R&D stage, is it not?
Other then that, thanks for the read, if anything, it was informational. Good luck with the system, but I am sure you are undertaking a far bigger task on yourself than you think you are at present point. Linux is a much simpler (dinosaur, like you put it yourself) and straighter (compiled C code, no magic tricks, just platform and hardware reference programming -old school made for performance) system and you can see for yourself how many years it took for it to get even close to being broadly usable.
I would write a good deal more on the issues of your OS, but let us just wait and see how it all develops. Things have a tendency to change.
Do you have anything published? I am doing some heavy research into something perhaps similiar, and unless you are keeping a lid on it, I would be glad to exchange ideas. I am not expecting any practical implementations, even communicated theory would be nice. Take a look at www.tunes.org by the way, those guys are onto something too.
What do you care whether your app shares address space with every other one, or whether its address space is 'virtualized' (the way it mostly is these days)? It is not like you engage in pointer arithmetics is it? So whether your pointers are all sequential (and mapped to scattered real pointers) or are spread all over the RAM, means nothing to you as a programmer, unless you have a good reason to expect certain pointer 'demographics'.
Precise language semantics never hurt, and I do not believe it is all just to confuse people. On the contrary the general tendency (apart when coming from someone that needs to sell stuff) is to improve communication between parties, since this is one of the biggest problems in the programming field. Same things go by different names, and different things by same names. A persistent store is not a file, because it can be something else, and if someone mentions the former, he probably does not want to have it confused with latter. I am sorry you feel like you are constantly covered with terms, but frankly most of these terms keep their meaning since they are invented, and it does not change for the most part. 'Persistent object' is not an exception. A file has some properties of a stream, while an object is nothing like a stream, unless it is a stream object:-)
I do not like to waste my time learning useless crap either, and I do not like to talk geeky with anyone. I would much rather have people use computers intuitively without having to bother why their 'Spreadsheet document' does not open in OpenOffice but opens in Microsoft Word ("What is a 'file format' ?")
And I am sorry you feel like peeling an onion. I personally stopped feeling like that since I have learned the true properties of this field, and they go way back. Computers are our slaves and the only thing they can do essentially is traverse through a precise list of orders. It is truly simple, much like you see it probably, but it does not mean we like to complicate it. Nobody forces you to, but a file and a persistent object are not the same thing, and we need to at least know the meaning of the words that come out of the mouth, and trust that these are not perverted to another meaning at the other end of the conversation, if we ever are able to build something atop our social and communicative skills. To broadly assume 'techies' do this all the time would probably do them more harm than good, and that Dmitry guy, he just has subpar English skills, so he has at least one excuse to mess up the communication, which he does too. But there was a reason he called it a persistent object - it is not a stream of data.
Reading Dmitry's website www.dz.ru left me with mixed taste, and NOT because of his less than desired English skills, but rather because the concepts he is trying to outline and the FAQ do not rest well with my understanding of the problems todays OS's deal with. He just jumps to the other end of the computer science concepts scale, the one that has been collecting dust ever since the concept of computer 'files' has made it as far as Hollywood, and the other end is just as lonely as the one Linux and Windows sit at. Everything-is-objects is an overhead we can live without, because frankly it is debatable if everything is. An 'object' introduces a whole layer of functionality which some pieces of data just might never need or would want to circumvent, and in that sense it will suffer the same fate as everything-is-a-file concept in Unix, which we inherited from stone age of computing. Albeit a file being a simpler construct than an object, the performance issues he will encounter will be substantially higher than with files where files are not applicable. I wish him well, and especially so that he realizes what the true challenges of computer systems are today, which he sort of tries to address. The website is worth a read though, I guess, even though the concepts he tries to explain on his pages appear to be either at planning/infant stage or are just somewhat messily designed.
Exciting times. In my opinion electrical motor is the way to go though. The problem is the potential energy around us is not available as electrical power by itself, the latter needs to be produced and also stored. Which is where photovoltaics come in - given that Earth is radiated with about 50 - 250 watts of energy per square meter of land, our sun will give us all the power for electricity we need, even with our suboptimal solar panels of today. There is also hydrogen, the most abundand stuff in the Universe, and progress is being made there as well. The problem is our economy. Which slowly has to adjust, and that takes time. It takes time before the folks that profit from oil recovery collect enough money for their pension, and leave something for their sons and daughters and finally lay off that "gold mine" which is killing us slowly, and it takes time to collect the guts to start investing in something new and divorce our economy from oil, so that it does not collapse all too fast when oil is finally left alone where it rested for millions of years. It takes time to change the public perception of transport and consumption and the culture associated with it too. Speaking of the whatever non-scientific reasons for the slow change towards cleaner future, George Monbiots book "Heat" is a good read.
And just for some food for thought, Oslo where I happen to live, has bought two THiNK cars last year, the company behind these cars had to loan money from the government to make it to 2009. What I am trying to say is the mass of people is the last element you need to convince, and only after everything else is in place, do they start to think about alternatives to their combustion engine cars. And Oslo folks are really stubborn. They will not give up their family wagons all too easily or hastily.
"Good God! I've been sayin' it. I've been sayin' it for ten damn years. Ain't I been sayin' it, Miguel? Yeah, I've been sayin' it."
Re:Why people watch movies..
on
Daemon
·
· Score: 1
It all boils down to what an average sitcom/movie viewer wants - and after a hard day at work, asking for him/her to digest a picture of how things really are results in the viewer changing the channel in search of some mind numbing soothing action. We do not want truth, we want fantasy and escapism, which explains why we want to see technology on screen as IP adresses taking half the monitors space, and every action a character takes on the computer give off some cool sound effect. The true picture is true picture, but this is not what people want on average.
Ironically, the movie that concerned the issue of real life versus fantasy, truth versus illusion - The Matrix trilogy - had at least one scene that gave the true picture of what technology we ACTUALLY use - it was one where Trinity used a Unix command line terminal to access and disable parts of city power grid.
Also I do not understand what are you trying to say - first you mention render farms, which are for prerendering highest quality CG we enjoy today AND which do use raytracers to render in any resolution you want, albeit slower than realtime, and in the next paragraph you are talking about ETQW and a $100 video card. I was talking about 1280x720 being todays resolution for gaming, and I bet realtime raytracers rendering 1280x720 would win the hearts of ANY gamer over todays or tomorrows GPU assisted games running at 1920x1080 or even double that. I elaborated on the reasons (suspension of disbelief thing) in the previous post.
The visual quality ray traced renderers deliver (by their very nature) in my opinion more than makes up for the lack of resolution. I would much rather enjoy more complex scenes with different materials reacting to light than watch cartoonish simulations of physics of light running at 1920x1080 or even 19200x10800. I believe the brain suspends disbelief easier based on the complexity of the scene and realistic light interactions and even "forgets" how many pixels are in the scene, which explains why people instantly respond to 640x480 photos of beautiful scenery as being real versus looking at 1920x1080 screenshots of Crysis (computer game). I rest my case.
P.S. The render farms used by the movie industry still use ray tracers, albeit those which are tweaked to disregard certain effects of rendering that may be ignored by majority of audiences. Point is when you need quality, use raytracer. And they are getting faster and faster, so I do not see how and where exactly they may fail.
Then again, most of the most impressive game engines today blend the border between raytracing and rasterizing, to achive both visual quality and speed. So in essense, this debate is a bit too black and white.
1280x720 is pretty usable and popular resolution these days, it is used in everything from HD movies to Playstation 3 games, and nobody seems to be complaining of it being "terribly low".
Yes, you are absolutely right. Even when Edison died, Tesla was merciless to him, and spoke harshly of him. Tesla did also show streaks of cruelty occasionally, which he was rather infamous for. Tesla was aware of DC power though, without doubt, and my argument is that Tesla was undoubtfully aware wher DC could be used with clear advantage over AC. Even today I do not see how we can get rid of DC currents in fine electronic appliances such as DVD players, home stereo, TVs and last but not least computers. As far as I understand, switching to AC power in these would involve much more complicated electronics and materials. If anyone else could elaborate more on AC current powered fine electronics, please do, I am not what you can consider an expert in this.
Tesla was not discriminating against DC power in general, he was merely certain that it was AC electricity that was the winner for transporting electricity over long distances, to which Edison objected in favour of DC, but Tesla turned out to be right. To my knowledge, Tes;a never objected scientifically to DC being used in wherever else it was due - such as medium and shorter path interconnects and fine electronics where precise voltages were needed.
Slashdot Mirror
That were exactly my thoughts the other day as I was preparing a birthday gift for my mother. You can imagine the kind and multitude and last but not least, the kind of generics the applications she needs to run ;-) Even two years ago, I could not with a confidence in my heart propose a Linux based desktop to her. Today I feel I can, given I run my desktop completely hassle free, and I do quite a lot more things on it than she will ever imagine. Even Skype, albeit proprietary, something she uses, exists on Linux. I am thinking she might like a Linux based netbook.
As to ARM, i think even if Nintendo DS ran its own bizarre set of instructions, CISC or RISC, ARM could handle an emulator, a re-compiler or something entirely different. RISC is also generic enough to be used for a whole multitude of applications. You write a piece of code that translates Nintendo DS code into ARM instruction set. Given enough time anything is possible, just take a look at the variety of SEGA Genesis, 3DO and Nindendo 64 emulators for Windows out there.
Basically you are proposing using the ARM chip as the C-P-U, and the other two as its slave PUs :-) Not a bad idea at all, in fact that is exactly how I would have built that tree.
The trouble with most modern laptops, is that even when completely unattended, doing no work that the user expects any results of anytime, just by being 'on', these seldom consume below 5 Watts of power, and in their factory config about usually 15 (nobody bothers with configuring power management). I am talking about a laptop that is lid-closed, radios (wifi, bluetooth) off, not doing ANYTHING for you.
It may be a small part of the CPU, but a very usable still. Very simple - throwing aside RISC vs CISC comparison, grouping several smaller instructions into a bigger specialized macro instruction that helps in certain cases is called optimization, and optimization gains even more when hard coded in silicon. That is why, RISC always makes sense ALONG CISC and vice versa. They complement each other, where a complex (CISC) instruction may be chosen away in favour of its (RISC) components (Think inline assembler in a C++ code), and also groups of RISC instructions can be substituted by a single specialized CISC call which will speed up the application. And since, as you say, the logic takes up small part of the die, let it sit there and be taken advantage of. A much better idea is instead to OPEN the RISC subset of an Intel/AMD CPU, provided it is standardised of course (you dont want at least two different RISC sets under a common CISC set, and they are different now, being hidden and proprietary and all). Seeing as it might never happen, ARM chips of the future seem like a much more realistic scenario, even more so if they add some CISC decoders for special common cases (the whole point and 'strength' of CISC). But I have to point out that optimizing by grouping RISC instructions into CISC macro ops is very very hard, because RISC instructions are so fast (by their very nature), even calling them in groups in memory is usually fast enough to not warrant a hardware CISC decoder on-die. That is one of the reasons Intel and AMD went RISC internally with their x86 designs a while ago too. RISC is FAST. CISC is fast only because it specializes, branches, decodes and optimizes RISC in hardware. All complex things can be split into smaller parts, why have access only to the engine, when you can use even the smallest gear, bolt and O-ring.
It just begs a question, for WHOM REALLY is Windows and its software a limiting factor? It looks now as if the only people who just would die from not having access to Windows are those who put their whole commerce on it and people who sit and play the latest games. ALMOST everyone else has had choice for at least a year now, and that choice is rapidly improving. Heck, I did not know what Linux really was a year ago, and now I do not see which things is it that it cannot do. I have my text input app, a media player, a web browser (albeit with Adobe's Flash player), and a usable desktop. I even have a video editing application (Avidemux) that actually works. Anyhow, all it takes is some faith. But sadly, that is something that comes only AFTER hope, not before, and right now Microsoft is feeding the world.
WINE is portable enough to build on ARM, I am pretty sure. This solves some of the Oh-What-About-Windows problem, does it not?
Also, if Wine wont do it, maybe, just MAYBE, QEMU/kvm/Xen will ;-)
Really, Windows is just a stone, a stone so large nobody can seem to go around it anymore, but there are ways for those who wish strong enough. At least, why not try it? The whole x86 world is so boring. Even NASA uses ARM chips, and it seems to be good enough for them. What, it cannot decode an MP3?
RAM is for being used. Unused RAM is waste. Firefox gives up its allocations by the way at the request of the host system, a request both at least Windows kernels do when either real or virtual memory is close to running out, and also when minimizing application windows. Not sure if Linux does that though. If you want Firefox to take less space, take out a RAM module, that will force Firefox to be more modest. But it is pointless, is it not?
The real question is, does Firefox allocate as little memory as it can do with and provide exactly as much performance and features that the user requires?
As a programmer, I had plenty of occasions to version my algorithms into variants where one would work fast but cache stuff into memory, thus blowing up its commit charge (used memory), or work slower but use much less memory while working. I do not know how Firefox devs decided how much RAM is a good usage on average, but with the size of Firefox code, they, I am sure, had plenty of chances to version their algorithms too, and they decided to give it some good speeds AND ability to slow down the way I described. You can search Google for Firefox 3 memory optimization.
Are you talking about re-compiling things with leaving out features you do not use or like? Disabling unneeded functionality at the source code level?
I do not understand which problem we are trying to solve by leaving out packages out of the distribution? Is it the fact that the system runs faster without MySQL, for instance? If that seems to be the problem, I assure you the real problem is not in the total size of the installed software, which is handled easily by large hard drives even netbooks these days have, but in the archaic rigid logic of todays software where unused features somehow still end up eating CPU cycles, getting in the way of user experience. The situation where unsuspecting novice laptop customers get SPAM loaded Windows systems that needs thorough cleaning before getting usable, is THE perfect example that illustrates the problem and its nuances.
Dmitry,
How much effort (man-hours) has already been put into your project? It appears your whitepaper is hastily drafted, and so my conclusion is everything is pretty much in R&D stage, is it not?
Other then that, thanks for the read, if anything, it was informational. Good luck with the system, but I am sure you are undertaking a far bigger task on yourself than you think you are at present point. Linux is a much simpler (dinosaur, like you put it yourself) and straighter (compiled C code, no magic tricks, just platform and hardware reference programming -old school made for performance) system and you can see for yourself how many years it took for it to get even close to being broadly usable.
I would write a good deal more on the issues of your OS, but let us just wait and see how it all develops. Things have a tendency to change.
Do you have anything published? I am doing some heavy research into something perhaps similiar, and unless you are keeping a lid on it, I would be glad to exchange ideas. I am not expecting any practical implementations, even communicated theory would be nice. Take a look at www.tunes.org by the way, those guys are onto something too.
Very well formulated argument, and that is what counts.
What do you care whether your app shares address space with every other one, or whether its address space is 'virtualized' (the way it mostly is these days)? It is not like you engage in pointer arithmetics is it? So whether your pointers are all sequential (and mapped to scattered real pointers) or are spread all over the RAM, means nothing to you as a programmer, unless you have a good reason to expect certain pointer 'demographics'.
Precise language semantics never hurt, and I do not believe it is all just to confuse people. On the contrary the general tendency (apart when coming from someone that needs to sell stuff) is to improve communication between parties, since this is one of the biggest problems in the programming field. Same things go by different names, and different things by same names. A persistent store is not a file, because it can be something else, and if someone mentions the former, he probably does not want to have it confused with latter. I am sorry you feel like you are constantly covered with terms, but frankly most of these terms keep their meaning since they are invented, and it does not change for the most part. 'Persistent object' is not an exception. A file has some properties of a stream, while an object is nothing like a stream, unless it is a stream object :-)
I do not like to waste my time learning useless crap either, and I do not like to talk geeky with anyone. I would much rather have people use computers intuitively without having to bother why their 'Spreadsheet document' does not open in OpenOffice but opens in Microsoft Word ("What is a 'file format' ?")
And I am sorry you feel like peeling an onion. I personally stopped feeling like that since I have learned the true properties of this field, and they go way back. Computers are our slaves and the only thing they can do essentially is traverse through a precise list of orders. It is truly simple, much like you see it probably, but it does not mean we like to complicate it. Nobody forces you to, but a file and a persistent object are not the same thing, and we need to at least know the meaning of the words that come out of the mouth, and trust that these are not perverted to another meaning at the other end of the conversation, if we ever are able to build something atop our social and communicative skills. To broadly assume 'techies' do this all the time would probably do them more harm than good, and that Dmitry guy, he just has subpar English skills, so he has at least one excuse to mess up the communication, which he does too. But there was a reason he called it a persistent object - it is not a stream of data.
Very good point, sadly one that not many get.
Reading Dmitry's website www.dz.ru left me with mixed taste, and NOT because of his less than desired English skills, but rather because the concepts he is trying to outline and the FAQ do not rest well with my understanding of the problems todays OS's deal with. He just jumps to the other end of the computer science concepts scale, the one that has been collecting dust ever since the concept of computer 'files' has made it as far as Hollywood, and the other end is just as lonely as the one Linux and Windows sit at. Everything-is-objects is an overhead we can live without, because frankly it is debatable if everything is. An 'object' introduces a whole layer of functionality which some pieces of data just might never need or would want to circumvent, and in that sense it will suffer the same fate as everything-is-a-file concept in Unix, which we inherited from stone age of computing. Albeit a file being a simpler construct than an object, the performance issues he will encounter will be substantially higher than with files where files are not applicable. I wish him well, and especially so that he realizes what the true challenges of computer systems are today, which he sort of tries to address. The website is worth a read though, I guess, even though the concepts he tries to explain on his pages appear to be either at planning/infant stage or are just somewhat messily designed.
Exciting times. In my opinion electrical motor is the way to go though. The problem is the potential energy around us is not available as electrical power by itself, the latter needs to be produced and also stored. Which is where photovoltaics come in - given that Earth is radiated with about 50 - 250 watts of energy per square meter of land, our sun will give us all the power for electricity we need, even with our suboptimal solar panels of today. There is also hydrogen, the most abundand stuff in the Universe, and progress is being made there as well. The problem is our economy. Which slowly has to adjust, and that takes time. It takes time before the folks that profit from oil recovery collect enough money for their pension, and leave something for their sons and daughters and finally lay off that "gold mine" which is killing us slowly, and it takes time to collect the guts to start investing in something new and divorce our economy from oil, so that it does not collapse all too fast when oil is finally left alone where it rested for millions of years. It takes time to change the public perception of transport and consumption and the culture associated with it too. Speaking of the whatever non-scientific reasons for the slow change towards cleaner future, George Monbiots book "Heat" is a good read.
And just for some food for thought, Oslo where I happen to live, has bought two THiNK cars last year, the company behind these cars had to loan money from the government to make it to 2009. What I am trying to say is the mass of people is the last element you need to convince, and only after everything else is in place, do they start to think about alternatives to their combustion engine cars. And Oslo folks are really stubborn. They will not give up their family wagons all too easily or hastily.
"Good God! I've been sayin' it. I've been sayin' it for ten damn years. Ain't I been sayin' it, Miguel? Yeah, I've been sayin' it."
It all boils down to what an average sitcom/movie viewer wants - and after a hard day at work, asking for him/her to digest a picture of how things really are results in the viewer changing the channel in search of some mind numbing soothing action. We do not want truth, we want fantasy and escapism, which explains why we want to see technology on screen as IP adresses taking half the monitors space, and every action a character takes on the computer give off some cool sound effect. The true picture is true picture, but this is not what people want on average.
Ironically, the movie that concerned the issue of real life versus fantasy, truth versus illusion - The Matrix trilogy - had at least one scene that gave the true picture of what technology we ACTUALLY use - it was one where Trinity used a Unix command line terminal to access and disable parts of city power grid.
Also I do not understand what are you trying to say - first you mention render farms, which are for prerendering highest quality CG we enjoy today AND which do use raytracers to render in any resolution you want, albeit slower than realtime, and in the next paragraph you are talking about ETQW and a $100 video card. I was talking about 1280x720 being todays resolution for gaming, and I bet realtime raytracers rendering 1280x720 would win the hearts of ANY gamer over todays or tomorrows GPU assisted games running at 1920x1080 or even double that. I elaborated on the reasons (suspension of disbelief thing) in the previous post.
The visual quality ray traced renderers deliver (by their very nature) in my opinion more than makes up for the lack of resolution. I would much rather enjoy more complex scenes with different materials reacting to light than watch cartoonish simulations of physics of light running at 1920x1080 or even 19200x10800. I believe the brain suspends disbelief easier based on the complexity of the scene and realistic light interactions and even "forgets" how many pixels are in the scene, which explains why people instantly respond to 640x480 photos of beautiful scenery as being real versus looking at 1920x1080 screenshots of Crysis (computer game). I rest my case.
P.S. The render farms used by the movie industry still use ray tracers, albeit those which are tweaked to disregard certain effects of rendering that may be ignored by majority of audiences. Point is when you need quality, use raytracer. And they are getting faster and faster, so I do not see how and where exactly they may fail.
Then again, most of the most impressive game engines today blend the border between raytracing and rasterizing, to achive both visual quality and speed. So in essense, this debate is a bit too black and white.
1280x720 is pretty usable and popular resolution these days, it is used in everything from HD movies to Playstation 3 games, and nobody seems to be complaining of it being "terribly low".
Yes, you are absolutely right. Even when Edison died, Tesla was merciless to him, and spoke harshly of him. Tesla did also show streaks of cruelty occasionally, which he was rather infamous for. Tesla was aware of DC power though, without doubt, and my argument is that Tesla was undoubtfully aware wher DC could be used with clear advantage over AC. Even today I do not see how we can get rid of DC currents in fine electronic appliances such as DVD players, home stereo, TVs and last but not least computers. As far as I understand, switching to AC power in these would involve much more complicated electronics and materials. If anyone else could elaborate more on AC current powered fine electronics, please do, I am not what you can consider an expert in this.
Tesla was not discriminating against DC power in general, he was merely certain that it was AC electricity that was the winner for transporting electricity over long distances, to which Edison objected in favour of DC, but Tesla turned out to be right. To my knowledge, Tes;a never objected scientifically to DC being used in wherever else it was due - such as medium and shorter path interconnects and fine electronics where precise voltages were needed.
Nevermind, the article explains everything in detail. I was trigger happy there for a moment.