I agree with you right up to the point where you say "You can try to fight it, but this always comes back in the end."
That is something I found out when I bought into a condo complex. Where I live the ruling council has enormous powers and very little legal responsibility. What little responsibility assigned to them by the relevant legislation is ignored at will because the only way to make them responsible is to take them to court. If there are N units in the complex they have (N-1)X funds to draw on to fight and hire lawyers while you have X funds to fight and hire lawyers. Usually the ruling council has taken out an insurance policy that protects them from consequences for their misdeeds and so the insurance company will usually provide them a lawyer, at no cost. So it is really you against (N-1) people and an insurance company. If you lose you bear all the costs, if they lose the insurance company picks it up or they split it (N-1) ways. You can win but it's almost always going to be a pyrrhic victory. This is all obvious and serves to promote abuse.
Seriously, if you want to see mean spirited, petty, power mongering, dishonest behavior, where it doesn't all come back on them in the end, then you don't need to go to a third world country or see a war in some far off land... just buy a condo.
Burnout and boredom are, as you say, not the same thing. However let me add another: burnout and depression are not the same thing although one can easily accompany the other. One of the fundamental aspects of depression is this: you gradually/suddenly develop a highly unassailable internalized belief, about some or all of your life, that nothing you do can have any positive result. Eventually your mind concludes it is pointless to try and what do you know - all the joy is gone even if you used to be very happy with the way things were.
So yes it could be burnout - not hard to see given the conditions of work under which most IT is performed. But it could also be depression - very dangerous because often it doesn't just stay confined to the one area that may have sparked it.
I remember one place I did a contract. They needed someone for 1-2 months that they "could drop in the deep end and not worry about" so they could get the first version of their product out the door. Great - it was an interesting product and the area I would take was one I wanted to learn about. The design was finalized, the deadline was hard - yeehaw! But oops, the programming team, all quite young were focussing on coding styles wars (this was a long time ago) like whether to Hungarian or not. Meanwhile "marketing" (makes sign of cross) came along every couple of weeks and added whole rafts of changes - the management people in charge of implementation either couldn't or wouldn't insist that stop. I left two months later as I had prior commitments I had to honor - at that point they were no closer to having a product out the door but the design they then had was horribly horribly mangled. I think it was months before anything shipped. It must have been incredibly depressing for the people on the job.
Eons ago programming was fun: you were involved from requirements/analysis to design to implementation to testing to delivery etc. etc. And it was a respected activity. Programmers and computers were expensive and it was expected that programmers take the time necessary to write good quality code.
But it was a victim of its own success - the demand for programmers kept growing and growing. That had two effects. First more and more programmers were needed and as a result the IQ of the average programmer dropped, which in turn meant tools and techniques had to be developed to let the less talented contribute. Second as computers became more powerful the projects undertaken got larger and larger requiring more and more people which in turn meant developing techniques so that large numbers of people could work on one project - which had pretty much the same effect as the attempt to accommodate the less talented. The scope of the individual's job has become constantly diminished and the amount of intelligence and creativity required to do it has simultaneously diminished. At the same time the industry evolved to deal with competition so that rapid turnaround became paramount so even if everything else about the job were ok there was still the pressure to "just get it done" even if that meant producing a pile of crap in which you just couldn't have any pride, e.g. because you knew of the many bugs etc. it still contained.
With all that I'd be very surprised if many talented people weren't suffering from some level of depression after being in the business for a few years.
BTW a lot of this was predicted in the book "Programmers and Managers" by P. Kraft - short and worth a read to anyone working in IT.
Knuth pretty much is a super-genius so you can see why he might have the point of view attributed to him. It's informative to visit his home page... check out his CV http://www-cs-faculty.stanford.edu/~knuth/vita.html
Better yet start here http://www-cs-faculty.stanford.edu/~knuth/index.html Take a look at the number of refereed papers and unrefereed papers. Whatever you do don't click on the link labeled "(don't click here)"!!!
I very rarely write "me too" posts but in this case I can't resist.
Ultimately the failure of good comments and good documentation is because people are focussing on the code; as long as documentation and comments are an afterthought they will be forgotten or poorly written.
Yes! Unfortunately the end users, the very people who should most value good documentation, often support the "code first" approach... because they don't want to think/commit either! Or because they don't see the value of good documentation and don't want to pay for it. It's funny (sad) because I see this frequently with people who really ought to know better, having been badly burned by poor or non-existent documentation in the past, but they don't learn the lesson because the penalty is usually extracted from them a little bit at a time over prolonged periods while the costs of documentation are all up front.
It's the same same with code maintenance - pay more to write good maintainable code now, or "save" now and pay later to deal with the problems of the the cheap poorly written code. It's a problem at every level of the process and of the hierarchy of people involved. Personally I think it is a reflection of basic human nature and it takes some serious mental discipline to get one's head out of that pit.
The reason I think literate programming doesn't catch on has mostly to do with the fact that a great many programmers don't bother to think through what they want to do before they code it: they are doing precisely what Knuth mentions he does use unit testing for -- experimental feeling out of ideas
Yes! I like writing code to see how things pan out, it's one of my ways of thinking about what the problems and goals are. But I don't intend that to be the final code - make a cheap throwaway prototype, then make the final product, possibly salvaging bits of the prototype. In fact when you are using functional programming languages it is a very direct and productive way of figuring out the design of something because you continually decompose the problem in a relatively orderly and constrained way.
The "think first" school of programming is very out of favour (probably mostly because it actually involves thinking).
Yes! Up and down the whole food chain from the coders to the end users, getting people to think about what they actually want (to achieve, to use, to...) is amazingly difficult. The idea that one can take a problem that is moderately difficult, or worse, and solve it by just jumping on it and letting the "solution" grow organically as you figure it out.... is ludicrous, yet so very popular.
One reason this happens is because students are allowed to make changes to their code willy nilly to try and get it work - sometimes hundreds of times in a day - I've watched them and it is clear that for many it is pretty much a random process. Back in ancient days when you might get to run your program once an hour, or once a day, and the only tools you had to solve the problem were the input source code, the output results and your brain, then the only way you had a chance to solve the problem was to think first and act second.
My day job consists mostly of writing rendering code, although not in a gaming context. I am not at all "dissing" scan conversion. It's what I do every day. My point is, WHEN (and only when) the technology is fast enough for real time recursive ray tracing, it will be the end of rasterization in 3D applications.
If it isn't recursive then it's not ray tracing it's ray casting.
Wow, don't try and hold back that ageism so much - tell us what you really think!
Oh wait, I'm a dinosaur who advocates (and researches) ray tracing - damn blew that theory all to hell I guess.
And his post was ranked "4, Insightful" when I saw it - maybe understanding words like insightful should be required before people get to moderate. Yeah, yeah, I know... it's/.
Sorry but you are not part of the solution, you are part of the problem.
Having code testers is no excuse for the original programmer being sloppy.
What most applications do (if anything) is focus on input validation and then blindly throw the validated data at library calls or lower level parts of the application code.
Which you appear to endorse. And which is also the cause of the many buffer overflow bugs, exploits and fixes thereof.
What you were asking the students to do is...
What I was asking the students, and any programmer, to do is this: do not copy a block of memory to another block of memory unless you know the destination block is large enough to contain the data you are copying.
Anyone who does not get why that is necessary should not be allowed near a computer.
Asking them to write bullet proof (sloth like) code is a waste of time.
Claiming that code that doesn't make unsustainable assumptions is "sloth like" is just a straw man, and a rather tired one at that. It doesn't deserve to be taken seriously, and so I won't.
"well commeted and readable code that makes a decent attempt at the assigned problem and it's constraints is far more important than passing..."
Ummmm no. There is your problem right there - looking pretty is not more important than working properly.
and grades should reflect that.
What makes you think their grades didn't reflect "commenting and readable" as well as correctness? Sorry but in software, just as in horseshoes, "close" doesn't count. And one programmer spending one extra hour to make sure that 1,000 users don't each spend an hour dealing with a bug is a good investment by any sane standard.
"two years with several different explanations from different presenters using different programming languages
If after all that students didn't fully understand pointers then I suspect there is a more serious problem at the institution. The only thing necessary to get students to understand pointers is to teach them assembler for an architecture with indirect addressing, i.e. almost any modern cpu. Period. End of story.
Here's an exercise for you:
Repeat
Say "Do not copy a block of memory to another block of memory unless
you know the destination block is large enough to contain the data you are copying."
You could also go to PC (President's Choice/Loblaws) which is also $0.20/minute... the time only lasts 60 days which is not as good as 7-11 Speakout's 365 days but the phones have unlimited web access, including googlemaps, gmail etc. for a flat $5/month, run java etc. etc. The point is that, while I am definitely disappointed with the cell providers in Canada, your previous statement:
"We have a triumverate monopoly here that keeps you from walking out of the cell phone store without paying an average of $50-60 CAD ($50-60 USD or 1 Canadian dollar = 5.93180398 Swedish kronor,) per month. And thats without any support for data-If you want 3G data it will cost you another 50-60 on top of that. "
was, at best, a gross exaggeration. Really, the providers are bad enough, there's no need to exaggerate to make that point.
Mod parent up - this is a ridiculous way to get new code into software. Sheesh, no wonder half the bug/security fixes I see coming through Ubuntu updates are buffer overflow vulnerabilities.
keeps you from walking out of the cell phone store without paying an average of $50-60 CAD ($50-60 USD or 1 Canadian dollar = 5.93180398 Swedish kronor,) per month
Mmmmm - go to 7-11, buy a Speakout phone... $65-$100 for a phone (or free - sometimes they run a "buy $100 of airtime and the phone is free" offer), then buy some time - the time lasts for 365 days without expiring and air time runs at $0.20/minute. My average cost is $6/month.
Most of the patches I see popping up in Ubuntu's update notifier seem to involve buffer overflows. Now there is this exploit because someone didn't check a pointer (failed malloc()/new/etc?).
When I taught CS, back when dinosaurs ruled the earth, I would have given a homework assignment with anything like that a D or an F.
I mean WTF, fast forward a few eons and people are still writing code like this??? What do we have to do - shoot them???
A programmer not checking for a null pointer return or a buffer overflow is the equivalent of... geez, I don't know... a surgeon forgetting to wash his hands before operating?
The problem is you can drag that window as much as you want but the buttons may still not be visible because the window never sized correctly in the first place - you can argue about whether that is the developer's fault or the machine's limited resolution but the end result is a window that doesn't show buttons at the bottom of the window (try the print dialog on the organizer for an example) and no indication that there is more to find by resizing the window. Asus should have tested stuff like this.
I would be satisfied if the apps on the Linux version "just worked"...
They clearly have not been set up in advance for the size screen the eeepc uses - I know because of the many times my girlfriend has come over and said "why doesn't this work?" to me and I find that the window hasn't sized properly so a portion is cut off.
Last night it was the organizer... she couldn't send a page to the printer. Why? Well the print dialog had an option for configuring the printer but no "print" button so she just kept closing the dialog using the decoration. This is perfectly predictable for a normal person. She had in fact done what I'd shown her before and grabbed the window and moved it up so that the top moved off screen and the bottom became visible - something I guarantee most new users will not know how to do. But the button was still not visible - nothing looked especially wrong so she used the decoration to close. She was amazingly frustrated when she watched me grab the bottom of the window and resize it until the "print" button became visible.
There are lots of issues like this... the other one last night was that the default layout of the monthly view of the organizer prints outside the margins of letter size paper so even when she did get it to print some of the page was missing.... there are two icons on the network page to make a wireless connection and no explanation on when and why she would want to use one rather than the other... if somebody doesn't get their s*#t together and this continues to be what new users experience then they will run to the XP version.
Not only that but if you attach a Maxwell's Demon to the output you can get cooled water separated out from the hot and then feed that back in to the cooler while sending the separated hot water to the boiler!!!
Wouldn't "is a totally sealed system" take care of "evaporation issues, eliminating the need to refill the system" without requiring "plastic tubing and a non-toxic, non-flammable liquid"????
I'm just saying....
OTOH I would imagine Canada can afford to build quite a lot of mines that could be placed in the newly created channels... then they can just listen for the sound of the nuclear subs.
Actually I had fractals in mind when I made the comment in general reality does not tend to be very smooth and it does not tend to be very regular (at least not obviously so at the level we are usually watching)
Oh wait do I need to explain that? Well, for example, the person you responded to said:
The reason we have so much tech development in Raster is because processing was not sufficient to do ray.
Which is absolutely true. If, when rendering with ray-tracing was first tried, computers had been as powerful as today then it is very likely that much more technology would have been developed to exploit ray-tracing. Rasterizing became popular for one simple reason: you could render faster on the available equipment.
And actually ray tracing does magically get you better image quality (for at least some definitions of "magically").
Now the idea of speeding up ray tracing by using rasterizing to generate the primary rays has been around for, oh, a good 20 years I'd say. I've written both and the calculations are different but not particularly simpler. And there is no reason why ray tracing primary rays needs to be slower than calculating by rasterizing. Rasterizing and ray tracing perform exactly the same fundamental operation: they sort the model primitives by distance from a given point.
As someone active in the early years of movement animation research I don't think it (realistic movement) is that hard a problem.... however that's not what I want to quibble about;)
The realism of individual images/frames is getting pretty good but it is still a far cry from being convincing and the reason for that is that reality is very noisy and very rough, it is physically and visually complex. Take a look at someone's face...well at least one that hasn't been spackled over with make-up... craters, mountains, hairs and so on, all essentially randomly distributed and that is a very simple case. Clothing, bricks, rocks etc. - in general reality does not tend to be very smooth and it does not tend to be very regular (at least not obviously so at the level we are usually watching)... texture maps just don't go that far in dealing with such and generating a model with detail sufficient to be convincing involves huge amounts of data... rendering that data is only part of the problem - generating it in the first place is also a big problem.
IMHO creature movement is not a significant problem. OTOH I think modelling realistic movement of non-solid entities, for example smoke, waves etc., is going to continue to be quite difficult for some time to come and this is also, in part, a result of the visual complexity of reality.
in the worst cases, a ray can bounce along an infinite path, dividing into multiple segments as it goes, leading to infinitely branched recursion until some heuristic or another cuts it short. And as we all know, "heuristic" is a fancy word for "cheat".
If the algorithm determines the ray can no longer make a visually significant contribution to the final pixel value is ending the recursion a cheat or simply an optimization?
Further, raytracing cannot handle advanced refraction and reflection effects, like the surface of water causing uneven illumination at the bottom of a pool, or a bright red ball casting a red spot on a white piece of paper, without preemptive "photon mapping", which is another cheat.
Ummmm, yes it can.
In short, we have not been able improve upon the original raytracing algorithms without "cheating reality".
Ray tracing is "cheating reality" from the get go since it completely ignores the wave nature of light (and for that matter the wave nature of matter).
Ray tracing is, or was, usually seen as a more elegant solution to the problem than rasterization since ray tracing more closely models the problem itself (in an isomorphic kind of way). Rasterization was originally the easier of the two to implement in hardware while ray tracing was easier to implement in software. If that situation had been reversed, and the billions (when you include market spending) thrown at hardware rasterization had been thrown at hardware ray tracing then we might have real-time hardware ray tracing on a chip today. That's just not the way it went.
Slashdot Mirror
I agree with you right up to the point where you say "You can try to fight it, but this always comes back in the end."
That is something I found out when I bought into a condo complex. Where I live the ruling council has enormous powers and very little legal responsibility. What little responsibility assigned to them by the relevant legislation is ignored at will because the only way to make them responsible is to take them to court. If there are N units in the complex they have (N-1)X funds to draw on to fight and hire lawyers while you have X funds to fight and hire lawyers. Usually the ruling council has taken out an insurance policy that protects them from consequences for their misdeeds and so the insurance company will usually provide them a lawyer, at no cost. So it is really you against (N-1) people and an insurance company. If you lose you bear all the costs, if they lose the insurance company picks it up or they split it (N-1) ways. You can win but it's almost always going to be a pyrrhic victory. This is all obvious and serves to promote abuse.
Seriously, if you want to see mean spirited, petty, power mongering, dishonest behavior, where it doesn't all come back on them in the end, then you don't need to go to a third world country or see a war in some far off land... just buy a condo.
Wow. You really believe Wirth and Pascal, Modula etc. didn't make an enormous contribution to the development of modern computer languages???
Absolutely perfect advice if you believe that men are fundamentally less valuable that women and/or children.
Burnout and boredom are, as you say, not the same thing. However let me add another: burnout and depression are not the same thing although one can easily accompany the other. One of the fundamental aspects of depression is this: you gradually/suddenly develop a highly unassailable internalized belief, about some or all of your life, that nothing you do can have any positive result. Eventually your mind concludes it is pointless to try and what do you know - all the joy is gone even if you used to be very happy with the way things were.
So yes it could be burnout - not hard to see given the conditions of work under which most IT is performed. But it could also be depression - very dangerous because often it doesn't just stay confined to the one area that may have sparked it.
I remember one place I did a contract. They needed someone for 1-2 months that they "could drop in the deep end and not worry about" so they could get the first version of their product out the door. Great - it was an interesting product and the area I would take was one I wanted to learn about. The design was finalized, the deadline was hard - yeehaw! But oops, the programming team, all quite young were focussing on coding styles wars (this was a long time ago) like whether to Hungarian or not. Meanwhile "marketing" (makes sign of cross) came along every couple of weeks and added whole rafts of changes - the management people in charge of implementation either couldn't or wouldn't insist that stop. I left two months later as I had prior commitments I had to honor - at that point they were no closer to having a product out the door but the design they then had was horribly horribly mangled. I think it was months before anything shipped. It must have been incredibly depressing for the people on the job.
Eons ago programming was fun: you were involved from requirements/analysis to design to implementation to testing to delivery etc. etc. And it was a respected activity. Programmers and computers were expensive and it was expected that programmers take the time necessary to write good quality code.
But it was a victim of its own success - the demand for programmers kept growing and growing. That had two effects. First more and more programmers were needed and as a result the IQ of the average programmer dropped, which in turn meant tools and techniques had to be developed to let the less talented contribute. Second as computers became more powerful the projects undertaken got larger and larger requiring more and more people which in turn meant developing techniques so that large numbers of people could work on one project - which had pretty much the same effect as the attempt to accommodate the less talented. The scope of the individual's job has become constantly diminished and the amount of intelligence and creativity required to do it has simultaneously diminished. At the same time the industry evolved to deal with competition so that rapid turnaround became paramount so even if everything else about the job were ok there was still the pressure to "just get it done" even if that meant producing a pile of crap in which you just couldn't have any pride, e.g. because you knew of the many bugs etc. it still contained.
With all that I'd be very surprised if many talented people weren't suffering from some level of depression after being in the business for a few years.
BTW a lot of this was predicted in the book "Programmers and Managers" by P. Kraft - short and worth a read to anyone working in IT.
Is it possible lawyers bill by the hour and flying halfway around the world takes longer than installing PGP?
Knuth pretty much is a super-genius so you can see why he might have the point of view attributed to him. It's informative to visit his home page... check out his CV http://www-cs-faculty.stanford.edu/~knuth/vita.html
Better yet start here http://www-cs-faculty.stanford.edu/~knuth/index.html Take a look at the number of refereed papers and unrefereed papers. Whatever you do don't click on the link labeled "(don't click here)"!!!
I very rarely write "me too" posts but in this case I can't resist.
Ultimately the failure of good comments and good documentation is because people are focussing on the code; as long as documentation and comments are an afterthought they will be forgotten or poorly written.
Yes! Unfortunately the end users, the very people who should most value good documentation, often support the "code first" approach... because they don't want to think/commit either! Or because they don't see the value of good documentation and don't want to pay for it. It's funny (sad) because I see this frequently with people who really ought to know better, having been badly burned by poor or non-existent documentation in the past, but they don't learn the lesson because the penalty is usually extracted from them a little bit at a time over prolonged periods while the costs of documentation are all up front.
It's the same same with code maintenance - pay more to write good maintainable code now, or "save" now and pay later to deal with the problems of the the cheap poorly written code. It's a problem at every level of the process and of the hierarchy of people involved. Personally I think it is a reflection of basic human nature and it takes some serious mental discipline to get one's head out of that pit.
The reason I think literate programming doesn't catch on has mostly to do with the fact that a great many programmers don't bother to think through what they want to do before they code it: they are doing precisely what Knuth mentions he does use unit testing for -- experimental feeling out of ideas
Yes! I like writing code to see how things pan out, it's one of my ways of thinking about what the problems and goals are. But I don't intend that to be the final code - make a cheap throwaway prototype, then make the final product, possibly salvaging bits of the prototype. In fact when you are using functional programming languages it is a very direct and productive way of figuring out the design of something because you continually decompose the problem in a relatively orderly and constrained way.
The "think first" school of programming is very out of favour (probably mostly because it actually involves thinking).
Yes! Up and down the whole food chain from the coders to the end users, getting people to think about what they actually want (to achieve, to use, to...) is amazingly difficult. The idea that one can take a problem that is moderately difficult, or worse, and solve it by just jumping on it and letting the "solution" grow organically as you figure it out.... is ludicrous, yet so very popular.
One reason this happens is because students are allowed to make changes to their code willy nilly to try and get it work - sometimes hundreds of times in a day - I've watched them and it is clear that for many it is pretty much a random process. Back in ancient days when you might get to run your program once an hour, or once a day, and the only tools you had to solve the problem were the input source code, the output results and your brain, then the only way you had a chance to solve the problem was to think first and act second.
My day job consists mostly of writing rendering code, although not in a gaming context. I am not at all "dissing" scan conversion. It's what I do every day. My point is, WHEN (and only when) the technology is fast enough for real time recursive ray tracing, it will be the end of rasterization in 3D applications.
If it isn't recursive then it's not ray tracing it's ray casting.
Oh wait, I'm a dinosaur who advocates (and researches) ray tracing - damn blew that theory all to hell I guess.
And his post was ranked "4, Insightful" when I saw it - maybe understanding words like insightful should be required before people get to moderate. Yeah, yeah, I know... it'sSorry but you are not part of the solution, you are part of the problem.
Having code testers is no excuse for the original programmer being sloppy.
What most applications do (if anything) is focus on input validation and then blindly throw the validated data at library calls or lower level parts of the application code.
Which you appear to endorse. And which is also the cause of the many buffer overflow bugs, exploits and fixes thereof.
What you were asking the students to do is...
What I was asking the students, and any programmer, to do is this: do not copy a block of memory to another block of memory unless you know the destination block is large enough to contain the data you are copying.
Anyone who does not get why that is necessary should not be allowed near a computer.
Asking them to write bullet proof (sloth like) code is a waste of time.
Claiming that code that doesn't make unsustainable assumptions is "sloth like" is just a straw man, and a rather tired one at that. It doesn't deserve to be taken seriously, and so I won't.
"well commeted and readable code that makes a decent attempt at the assigned problem and it's constraints is far more important than passing..."
Ummmm no. There is your problem right there - looking pretty is not more important than working properly.
and grades should reflect that.
What makes you think their grades didn't reflect "commenting and readable" as well as correctness? Sorry but in software, just as in horseshoes, "close" doesn't count. And one programmer spending one extra hour to make sure that 1,000 users don't each spend an hour dealing with a bug is a good investment by any sane standard.
"two years with several different explanations from different presenters using different programming languagesIf after all that students didn't fully understand pointers then I suspect there is a more serious problem at the institution. The only thing necessary to get students to understand pointers is to teach them assembler for an architecture with indirect addressing, i.e. almost any modern cpu. Period. End of story.
Here's an exercise for you:
Until understood;Repeat
You could also go to PC (President's Choice /Loblaws) which is also $0.20/minute... the time only lasts 60 days which is not as good as 7-11 Speakout's 365 days but the phones have unlimited web access, including googlemaps, gmail etc. for a flat $5/month, run java etc. etc. The point is that, while I am definitely disappointed with the cell providers in Canada, your previous statement:
"We have a triumverate monopoly here that keeps you from walking out of the cell phone store without paying an average of $50-60 CAD ($50-60 USD or 1 Canadian dollar = 5.93180398 Swedish kronor,) per month. And thats without any support for data-If you want 3G data it will cost you another 50-60 on top of that. "
was, at best, a gross exaggeration. Really, the providers are bad enough, there's no need to exaggerate to make that point.
Mod parent up - this is a ridiculous way to get new code into software. Sheesh, no wonder half the bug/security fixes I see coming through Ubuntu updates are buffer overflow vulnerabilities.
keeps you from walking out of the cell phone store without paying an average of $50-60 CAD ($50-60 USD or 1 Canadian dollar = 5.93180398 Swedish kronor,) per month
Mmmmm - go to 7-11, buy a Speakout phone... $65-$100 for a phone (or free - sometimes they run a "buy $100 of airtime and the phone is free" offer), then buy some time - the time lasts for 365 days without expiring and air time runs at $0.20/minute. My average cost is $6/month.
I'm sorry but "I don't want... or a meat eating girl either"????? Are you crazy? (LOL - just in case)
Most of the patches I see popping up in Ubuntu's update notifier seem to involve buffer overflows. Now there is this exploit because someone didn't check a pointer (failed malloc()/new/etc?).
When I taught CS, back when dinosaurs ruled the earth, I would have given a homework assignment with anything like that a D or an F.
I mean WTF, fast forward a few eons and people are still writing code like this??? What do we have to do - shoot them???
A programmer not checking for a null pointer return or a buffer overflow is the equivalent of... geez, I don't know... a surgeon forgetting to wash his hands before operating?
The problem is you can drag that window as much as you want but the buttons may still not be visible because the window never sized correctly in the first place - you can argue about whether that is the developer's fault or the machine's limited resolution but the end result is a window that doesn't show buttons at the bottom of the window (try the print dialog on the organizer for an example) and no indication that there is more to find by resizing the window. Asus should have tested stuff like this.
I would be satisfied if the apps on the Linux version "just worked"...
They clearly have not been set up in advance for the size screen the eeepc uses - I know because of the many times my girlfriend has come over and said "why doesn't this work?" to me and I find that the window hasn't sized properly so a portion is cut off.
Last night it was the organizer... she couldn't send a page to the printer. Why? Well the print dialog had an option for configuring the printer but no "print" button so she just kept closing the dialog using the decoration. This is perfectly predictable for a normal person. She had in fact done what I'd shown her before and grabbed the window and moved it up so that the top moved off screen and the bottom became visible - something I guarantee most new users will not know how to do. But the button was still not visible - nothing looked especially wrong so she used the decoration to close. She was amazingly frustrated when she watched me grab the bottom of the window and resize it until the "print" button became visible.
There are lots of issues like this ... the other one last night was that the default layout of the monthly view of the organizer prints outside the margins of letter size paper so even when she did get it to print some of the page was missing.... there are two icons on the network page to make a wireless connection and no explanation on when and why she would want to use one rather than the other ... if somebody doesn't get their s*#t together and this continues to be what new users experience then they will run to the XP version.
Not only that but if you attach a Maxwell's Demon to the output you can get cooled water separated out from the hot and then feed that back in to the cooler while sending the separated hot water to the boiler!!!
As any scuba diver could have told him, water conducts heat far more efficiently than air. IIRC it is a factor of about 25.
Wouldn't "is a totally sealed system" take care of "evaporation issues, eliminating the need to refill the system" without requiring "plastic tubing and a non-toxic, non-flammable liquid"???? I'm just saying....
OTOH I would imagine Canada can afford to build quite a lot of mines that could be placed in the newly created channels... then they can just listen for the sound of the nuclear subs.
Actually I had fractals in mind when I made the comment in general reality does not tend to be very smooth and it does not tend to be very regular (at least not obviously so at the level we are usually watching)
Wrong.
Oh wait do I need to explain that? Well, for example, the person you responded to said:
The reason we have so much tech development in Raster is because processing was not sufficient to do ray.
Which is absolutely true. If, when rendering with ray-tracing was first tried, computers had been as powerful as today then it is very likely that much more technology would have been developed to exploit ray-tracing. Rasterizing became popular for one simple reason: you could render faster on the available equipment.
And actually ray tracing does magically get you better image quality (for at least some definitions of "magically").
Now the idea of speeding up ray tracing by using rasterizing to generate the primary rays has been around for, oh, a good 20 years I'd say. I've written both and the calculations are different but not particularly simpler. And there is no reason why ray tracing primary rays needs to be slower than calculating by rasterizing. Rasterizing and ray tracing perform exactly the same fundamental operation: they sort the model primitives by distance from a given point.
As someone active in the early years of movement animation research I don't think it (realistic movement) is that hard a problem.... however that's not what I want to quibble about ;)
The realism of individual images/frames is getting pretty good but it is still a far cry from being convincing and the reason for that is that reality is very noisy and very rough, it is physically and visually complex. Take a look at someone's face...well at least one that hasn't been spackled over with make-up... craters, mountains, hairs and so on, all essentially randomly distributed and that is a very simple case. Clothing, bricks, rocks etc. - in general reality does not tend to be very smooth and it does not tend to be very regular (at least not obviously so at the level we are usually watching)... texture maps just don't go that far in dealing with such and generating a model with detail sufficient to be convincing involves huge amounts of data... rendering that data is only part of the problem - generating it in the first place is also a big problem.
IMHO creature movement is not a significant problem. OTOH I think modelling realistic movement of non-solid entities, for example smoke, waves etc., is going to continue to be quite difficult for some time to come and this is also, in part, a result of the visual complexity of reality.
in the worst cases, a ray can bounce along an infinite path, dividing into multiple segments as it goes, leading to infinitely branched recursion until some heuristic or another cuts it short. And as we all know, "heuristic" is a fancy word for "cheat".
If the algorithm determines the ray can no longer make a visually significant contribution to the final pixel value is ending the recursion a cheat or simply an optimization?
Further, raytracing cannot handle advanced refraction and reflection effects, like the surface of water causing uneven illumination at the bottom of a pool, or a bright red ball casting a red spot on a white piece of paper, without preemptive "photon mapping", which is another cheat.
Ummmm, yes it can.
In short, we have not been able improve upon the original raytracing algorithms without "cheating reality".
Ray tracing is "cheating reality" from the get go since it completely ignores the wave nature of light (and for that matter the wave nature of matter).
Ray tracing is, or was, usually seen as a more elegant solution to the problem than rasterization since ray tracing more closely models the problem itself (in an isomorphic kind of way). Rasterization was originally the easier of the two to implement in hardware while ray tracing was easier to implement in software. If that situation had been reversed, and the billions (when you include market spending) thrown at hardware rasterization had been thrown at hardware ray tracing then we might have real-time hardware ray tracing on a chip today. That's just not the way it went.