But not letting him trade, wouldn't that be an admission of security by obscurity?
What you call "security through obscurity" is what someone else calls "follow the policy or be fired". The guy didn't follow the rules, and the operating bank was held accountable to the rest of the world. It's a bit different than hardening a server against the public, which cannot be held accountable.
Except for the fact that the guy didn't plan on selling the stocks at this time.
The problem (which probably is what caused the bank to panic) was that the trader was trading on credit that the bank didn't have, and somehow managed to slip it by the various exchanges as well (the wonders of diversification). Essentially, he was gambling with the creditworthiness of an entire bank. If I were a bank, I would find it preferrable to eat a one-time loss than to potentially risk the financial reputation of the entire company. Put it Slashdot terms, it's as bad as an ISP telling customers that they all have super mega bandwidth, when it all falls apart if everyone tries to use that bandwidth at the same time.
But a shader is just a shader, it's not going to become anything more than that.
The recent trend has been to attempt to abuse shaders as much as possible... anything that benefits from shader ops running as parallel math co-processors (textures are arrays, shaders are map() or reduce() operations). It's an absolutely awful programming environment!
But were you to do it over, would you rather know the quirks of PHP, or of something else?
I don't know... I'd probably suck it up and learn Perl better. My current opinion is that reading sloppy perl is about two ticks better than getting whipped in the face with a leather belt... and I haven't seen very much clean Perl.
You see, what I meant was, if all PHP did was IO, that would be fine. But when people start using PHP as a general-purpose programming language, I call it a bad idea. It would be like writing a language in which OpenGL primitives were included—where you had a specific symbol and syntax for a triangle, or a quad...
Ok, I understand you now. Yeah, it is sort of a kludge to consider that a general-purpose programming language has special syntax for using stdout... but it's not uncommon. PHP's domain originated in producing HTML content, where such a syntax makes sense. It should be avoided in library files or command-line scripts where there isn't an expectation of producing "content" while executing. I don't see this as any different than Perl having built-in regular expressions or $_, or any shell using stdin/stdout as a value-passing mechanism. Heck, we could do away entirely with printf() and just use fprintf(stdout,...) for the C standard library. But people have decided that the special case is a common idiom, and worth keeping.
As to a language based around OpenGL/graphics primitives... the Alias|Wavefront OBJ file format is a declarative form of just that. It wouldn't suprise me to see someone use an embedded Lua interpreter to create a procedural "file format" for graphics primitives.
It's up to my own discipline to make sure that the "business logic" goes in the scripts, and the "display logic" goes into the templates.
But with that pattern, I honestly don't see the point of PHP over any other scripting language with strong template systems built on it.
You're right. But with PHP (where textual content is easy due to the special-case <?php= $stuff ?> syntax), I get a turing-complete templating system out-of-the-box. It does come with an added discipline cost on my part, because the templating system is the same as the programming language.
I'd hope that a better-designed framework—not necessarily more complex—would force people to think in a different way.
Probably. But that's not going to stop so many people from using existing systems that work, even if they're not optimal, such as PHP (with warnings turned off entirely, using gpc_magic_quotes, and all of the other "stupid programmer" features enabled) or Visual Basic scripts embedded in Office documents. It's hard to create something that meets both criteria:
usable by people who do not identify themselves as programmers
designed to facilitate creation of maintainable programs
...simply because in many cases, they are at odds with each other. HTML pages are easy to create, because parsers are soooo forgiving. PHP is easy to hack, because it allows for the presence of subtle bugs. If you took away the honestly godawful hodgepodge implementation that is PHP, people would just come up with something else and make it equally easy for non-programmers (and thus a godawful hodgepodge from the perspective of us programmers).
Now that I think about it more... the only real reasons why I still use PHP is because deployment is dirt simple and because I already know most the quirks and stumbling blocks that every programmer will eventually hit with it.
Stop hyping design patterns so much (you and the rest of the world, because I've been seeing it showing up on resumes more and more). The patterns themselves don't matter. Nobody cares if something uses 13 different design patterns to get a job done. They care about understanding how a system works, and design patterns provide the necessary vocabulary to talk about it, nothing more.
If you *want* to handle memory allocation - yeah - C/C++ is for you. But when you do that you're solving programming problems. You're not solving the customers problems.
Rhetorical question: What if the customer's problems are that the previous programmer solved everything with scripting languages, and the runtime performance is abysmal?
For example, a lot of PHP code still contains many SQL statements for inserting, finding, updating, and deleting data. Using Perl's DBIx::Class module for example, the programmer will probably not need to write any SQL statements in the program. The module will handle it all. Removing most of the SQL from the program means that a big source of bugs and other problems is gone.
My limited experience with DBIx was that it generated horrible SQL for large data listings, several orders of magnitude worse than basic SQL SELECT statements with joins... I don't know how it compares to other ORM tools like what Django or Ruby on Rails use, or Python's SQLAlchemy. It's possible that it wasn't DBIx, but the programmer using it incorrectly; enlighten me if I'm wrong. Myself, I tend to prefer using the database for more than "object persistence", so I use hand-crafted SQL for most cases. Of course, basic single-table CRUD isn't worth hand-crafting, but it takes 20 minutes to write a set of CRUD functions that convert between associative arrays and SQL statements. Using prepared statements, I've never found SQL to be a source of bugs. More often, it's something inane like a mistyped variable name, or actual incorrect logic, but not usually a mistyped SQL query (because they get copied and pasted from my psql prompt once I know they're correct).
And it removes the SQL injection attack problem too as a bonus.
SQL injection attacks are a non-issue with proper management of character encoding and something like Perl's DBI or PHP's PDO. You shouldn't need an ORM tool (which is what DBIx is) to protect yourself against SQL injection attacks.
Anyone who says PHP can't be used for functional programming is just not creative enough.
Yeah, another poster mentioned create_function. They also mentioned that it leaks memory.\
Sorry, I may not have expressed my opinion strongly enough with the tone of my voice. Functional programming in PHP sucks. create_functionsucks. The only saving grace for "decorate-sort-undecorate" in PHP is that it's significantly faster than the version with custom comparisons... because function calls are sooo slowwww in PHP.
I actually do have a beef with this. I find PHP's method of output more natural than something like a C or C++ program where you have to explicitly manage I/O.
And if all it did was IO, that would be fine.
I'm not sure I get you. What does ?>...stuff... <?php do besides I/O?
Do you cleanly separate your logic from your presentation, so your designers can tweak the template -- or swap it wholesale, or make your app skinnable -- without you having to lift a finger on the real code?...If you answered "no", you're probably one of the people abusing it.
Due to the nature of the projects where I use PHP, I am both the developer and the designer. So no, I don't use a separate "templating language", because I am comfortable using PHP for both "templates" and "programs". Yes, I do separate "skins" into separate PHP scripts, which are then include()ed with a distinct set of parameters. It's up to my own discipline to make sure that the "business logic" goes in the scripts, and the "display logic" goes into the templates. If you think it's abuse, you are misunderstanding what I am doing.
...that is why it has been criticized -- if you go from static pages to PHP, there's a chance your PHP scripts are horribly designed.
That statement is meaningless, because there's always a chance your script/program is horribly designed. I'm guessing you meant to say that a bad design is more likely via an evolutionary process like static HTML -> PHP. In that matter, the nature of PHP is both a strength and a weakness—People who suck at programming would be equally bad using a more complex framework. Your tool can't make people stop sucking, because you have to be smart enough to use it right. PHP does hit a power ceiling faster (it takes more effort and discipline to keep a large PHP project clean than a large Django/RoR/Java Servlet project), but that by itself doesn't deserve criticism. See Worse is Better for a better description of why the low power level provided by PHP is not a failure.
I'd also argue that even systems like CGI or mod_perl are about as easy, for the few places I need something dynamic. When it's just a template system, I'll use something like a Perl script and static files.
CGI and mod_perl fit on the same level as PHP, in my book. Choose whatever you're comfortable with; no one else cares, as long as you don't expose it in your URLs. I'll keep on using PHP, because I know how to write secure code with PHP, and I don't care to spend the time learning the equivalent in Perl (but maybe C++, now that you mention it).
No shit. But past performance does tend to give an indication of general market trends. And batting 10/10 is a pretty good average.
In the past 10 days I have not died. In fact, I will survive every day of my life except for one. That's a pretty good average, right? Too bad the average has no impact whatsoever on the worst-case. Past performance only gives an indication of what the general market trends used to be, not what they will be for the rest of 2008.
Please show me a single example in the domains mentioned.
You may disagree and vomit on me for saying this, but how about the OpenGL API? Even though it's all in C, it seems to me that it has a mixture of procedural and OO calls:
Texture, lighting, GLU quadrics, etc. all have sets of functions operate on objects. You can show an average developer a set of all texture-related functions and the concept is easy to grasp because the scope is very clear and limited.
Rendering operations affect the "current state", and generally aren't treated as acting on objects. You just select shape types and draw points until you're done. You can show someone the set of all functions available for rendering, and IMHO it's more daunting because there's no concept of scope. As soon as you wrap some direct rendering calls into a glDrawList, the notion of object scope comes into play again, and all of the rendering commands can be encapsulated into a single draw list.
I suppose I've cheated a bit... You asked for a demonstration of OO/procedural code, but my example is about an API. I conflate the two in my mind, though, because in my opinion, any well-written code is that way because of the internal interfaces and scoping constructs, whether they are procedural or OO.
And "coupling" is difficult to define and measure fairly.
The most natural definition of "coupling" I've seen is to imagine the set of all variables in a program as nodes in a graph. Any time two variables are referenced in the same function, there is an edge between those two variables. What you'll end up with in many cases is that sets of variables tend to get used together, and the whole graph looks like a lot of small clusters. A good OO design captures that clustering, so the end result is that within a single object many member variables get used in tandem, but between objects there is relatively little sharing. This applies to well-written C code, as well (sockets and pthreads are examples of OO designs implemented in procedural languages).
That may not be a fair measurement, but it's the best that I've seen. All it's really doing is putting up artificial walls between different parts (or layers) of a piece of software, so it's easy for a human to consume one chunk at a time. Of course, I'd argue that's what most of software development is about - implementing algorithms within the limitations of the human attention span (which is much smaller than a Turing machine).
I agree. Sucks. Also generally requires sysadmin-level permissions in order to change basic configuration such as error reporting, error level, magic quotes, etc. Starting from a stock OS install, it probably takes me about half an hour to get a PHP installation into a reasonable "default" state.
Come to think of it, reminds me of setting CXXFLAGS in my Makefile to include -Wall -Wextra -Wno-reorder -Werror -march=pentium4 -minline-all-stringops -ffast-math -O2 -ggdb. Even the Java JVM has fairly important tuning parameters (the most common solution to Eclipse performance problems back when I used it was "give it most of your system memory, and close it when you're done coding"). It's hard to create a flexible system without introducing bootstrapping complexity, and it requires up-front planning that simply wasn't a part of PHP's history.
lacking the basic capabilities of most other languages -- not just OOP, but things like anonymous subroutines
Take a look at the "decorate-sort-undecorate" idiom in PHP; it speaks for itself.
function functional_sort($array) { sort($array); return $array; }
function make_sort_key($datum) { return -$datum; }
$original = array(1, 2, 3, 4, 5, 6, 7);
$sorted = array_map( create_function('$tuple', 'return $tuple[0];'),
array_map( 'functional_sort',
array_map( create_function('$single', 'return array(make_sort_key($single), $single);'),
$original )));
Apologies for syntax errors, that's off the top of my head. Anyone who says PHP can't be used for functional programming is just not creative enough. The correct answer is that PHP can be used as a functional language, but it probably shouldn't be used that way (as you can clearly see).
being designed around the need to embed code in a template (not a good idea -- separate content from logic from presentation!)
I actually do have a beef with this. I find PHP's method of output more natural than something like a C or C++ program where you have to explicitly manage I/O. The fact that it can be horribly abused is no worse than the fact that any program in any other language can horribly abuse I/O. All of the (recent) PHP output I've written is as well-organized as any template-based system, thankyouverymuch.
having essentially nothing compelling to offer once other languages got said templating ability
PHP offered me something. Dirt simple installation and a very easy migration path from static HTML pages to something dynamic. That may not be much use for a lot of people, but I find it very natural for creating interfaces. While systems like Django are enticing, I'll probably stick with PHP for my small home-server apps just because of the learning curve.
Current GPU designs are very poor at branching; and the the geometry acceleration structures in ray tracing (which take a big part of the time) use lots of branches to traverse.
Second that. One of the big advantages of rasterization is the cache. Raytracing is notorious for locality of memory references.
You may still be able to use the GPU to accelerate some parts of the ray tracing pipeline.
Check out The Ray Engine. This uses the GPU to parallelize ray-triangle intersections.
...at any rate you should be able to use the GPU as a postprocessor to combine the rays into the final image.
Raytracing basically gives you point samples across a 2d plane. Rasterizing those point samples is a pretty straightforward task for the GPU. Not to mention all of the other rendering layers: someone mentioned caustics... you could dedicate one CPU to photon-mapping caustics and layer those on as a rasterized "onion skin".
Ok, so the toilet analogy is sunk. The underlying point still holds: provide users with an incentive to fix their problems, or they won't get fixed. The ISP for that same apartment complex would temporarily block users (via DNS poisoning) when virus or other "wtf" network behavior was detected. It sucked if it was a weekend (call center only had weekday hours), but it was pretty easy to deal with, and it provided the necessary incentive without pissing people off.
And over and over again those ads pay for the content and services that make that bandwidth worth having.
Not always. What about all of the sites that replicate Wikipedia's content and plaster ads all over it? They're not providing anything useful. In contrast, there's plenty of "old school" websites like The Krib that have content without ads. Just because ads sometimes provide the support for useful content does not make ads intrinsically worthwhile.
Or 4.) Use QoS (traffic shaping) to keep bandwidth usage as "fair" as possible with soft limits (so the P2P heavy user never gets fully cut-off, always gets whatever free traffic is available, and never gets to hog the pipes during peak times).
Or any combination of the above. Why is it always "increase capacity or limit users"? Why can't it be "increase capacity/and/ limit users"?
Your attitude is that users who aren't tech-savvy enough to prevent things like this from happening deserve to suffer
One apartment complex I used to live at in college gave us an allotment of $40/month for water. Anything beyond that, and we were required to pay for it. They used to provide water for free. What happened is that every once in a while, someone's toilet would get stuck running; but since it didn't have any impact on the resident, it wouldn't get fixed. After instating the $40/month cap, the running-toilet problem just went away, because people found the time to fix their toilets (or report it to the maintenance staff, who would then fix it).
While the exact overage fees may be ridiculous (witness the several-thousand-dollar AT&T bills for people who left their iPhones on when visiting Europe), the concept itself isn't a bad idea. In the water example, there was still a solution for people too clueless to fix the problem themselves - call maintenance. An ISP that charges overage fees should be notifying a user of "suspicious" bandwidth usage and providing support services to clean up infected computers.
It really doesn't have to be an argument about the elite vs. the lusers. There are non-BS reasons to provide an incentive to keep your sh*t in order.
Or maybe some employee might release the said trojan/virus and the company gets extra revenue from the virus hijaking your bandwidth.
Seriously? That's a bit of a stretch. It's not like the virus writers and the ISPs are scheming behind everyone's back. When a virus sweeps through a network...
The whole network gets saturated with virus traffic
tech support volume increases as people call to see what's wrong with the Internet
customer satisfaction goes down because of the degraded service and because everyone spent an hour waiting for tech support on the phone
people cancel their contracts and move to some other provider
Not to mention the legal ramifications if it were made public that an ISP released a virus on its customers to increase bandwidth-usage profits.
The problem is there has not been a properly mastered CD released for nearly a decade so most of you dont have a clue as to what a good one sounds like.
Check out All Is Full of Love (Bjork cover) on the soundtrack to Memento. It's only one track, but it's a very good indicator of the power available with good digital mastering (and a gateway drug to sound mass composition, to boot).
Slashdot Mirror
As a general rule, it's probably safe to assume that we are losing any war on an abstract noun, and that it will never truly be won—just ended.
And the sneak attack!
What you call "security through obscurity" is what someone else calls "follow the policy or be fired". The guy didn't follow the rules, and the operating bank was held accountable to the rest of the world. It's a bit different than hardening a server against the public, which cannot be held accountable.
The problem (which probably is what caused the bank to panic) was that the trader was trading on credit that the bank didn't have, and somehow managed to slip it by the various exchanges as well (the wonders of diversification). Essentially, he was gambling with the creditworthiness of an entire bank. If I were a bank, I would find it preferrable to eat a one-time loss than to potentially risk the financial reputation of the entire company. Put it Slashdot terms, it's as bad as an ISP telling customers that they all have super mega bandwidth, when it all falls apart if everyone tries to use that bandwidth at the same time.
Damn, I clicked the link and it wasn't a valid domain! I wanted to download whatever christmas present you had and unwrap it with strings.
The recent trend has been to attempt to abuse shaders as much as possible... anything that benefits from shader ops running as parallel math co-processors (textures are arrays, shaders are map() or reduce() operations). It's an absolutely awful programming environment!
I don't know... I'd probably suck it up and learn Perl better. My current opinion is that reading sloppy perl is about two ticks better than getting whipped in the face with a leather belt... and I haven't seen very much clean Perl.
Ok, I understand you now. Yeah, it is sort of a kludge to consider that a general-purpose programming language has special syntax for using stdout... but it's not uncommon. PHP's domain originated in producing HTML content, where such a syntax makes sense. It should be avoided in library files or command-line scripts where there isn't an expectation of producing "content" while executing. I don't see this as any different than Perl having built-in regular expressions or $_, or any shell using stdin/stdout as a value-passing mechanism. Heck, we could do away entirely with printf() and just use fprintf(stdout, ...) for the C standard library. But people have decided that the special case is a common idiom, and worth keeping.
As to a language based around OpenGL/graphics primitives... the Alias|Wavefront OBJ file format is a declarative form of just that. It wouldn't suprise me to see someone use an embedded Lua interpreter to create a procedural "file format" for graphics primitives.
You're right. But with PHP (where textual content is easy due to the special-case <?php= $stuff ?> syntax), I get a turing-complete templating system out-of-the-box. It does come with an added discipline cost on my part, because the templating system is the same as the programming language.
Probably. But that's not going to stop so many people from using existing systems that work, even if they're not optimal, such as PHP (with warnings turned off entirely, using gpc_magic_quotes, and all of the other "stupid programmer" features enabled) or Visual Basic scripts embedded in Office documents. It's hard to create something that meets both criteria:
Now that I think about it more... the only real reasons why I still use PHP is because deployment is dirt simple and because I already know most the quirks and stumbling blocks that every programmer will eventually hit with it.
Stop hyping design patterns so much (you and the rest of the world, because I've been seeing it showing up on resumes more and more). The patterns themselves don't matter. Nobody cares if something uses 13 different design patterns to get a job done. They care about understanding how a system works, and design patterns provide the necessary vocabulary to talk about it, nothing more.
Rhetorical question: What if the customer's problems are that the previous programmer solved everything with scripting languages, and the runtime performance is abysmal?
My limited experience with DBIx was that it generated horrible SQL for large data listings, several orders of magnitude worse than basic SQL SELECT statements with joins... I don't know how it compares to other ORM tools like what Django or Ruby on Rails use, or Python's SQLAlchemy. It's possible that it wasn't DBIx, but the programmer using it incorrectly; enlighten me if I'm wrong. Myself, I tend to prefer using the database for more than "object persistence", so I use hand-crafted SQL for most cases. Of course, basic single-table CRUD isn't worth hand-crafting, but it takes 20 minutes to write a set of CRUD functions that convert between associative arrays and SQL statements. Using prepared statements, I've never found SQL to be a source of bugs. More often, it's something inane like a mistyped variable name, or actual incorrect logic, but not usually a mistyped SQL query (because they get copied and pasted from my psql prompt once I know they're correct).
SQL injection attacks are a non-issue with proper management of character encoding and something like Perl's DBI or PHP's PDO. You shouldn't need an ORM tool (which is what DBIx is) to protect yourself against SQL injection attacks.
Sorry, I may not have expressed my opinion strongly enough with the tone of my voice. Functional programming in PHP sucks. create_function sucks. The only saving grace for "decorate-sort-undecorate" in PHP is that it's significantly faster than the version with custom comparisons... because function calls are sooo slowwww in PHP.
I'm not sure I get you. What does ?> ...stuff... <?php do besides I/O?
Due to the nature of the projects where I use PHP, I am both the developer and the designer. So no, I don't use a separate "templating language", because I am comfortable using PHP for both "templates" and "programs". Yes, I do separate "skins" into separate PHP scripts, which are then include()ed with a distinct set of parameters. It's up to my own discipline to make sure that the "business logic" goes in the scripts, and the "display logic" goes into the templates. If you think it's abuse, you are misunderstanding what I am doing.
That statement is meaningless, because there's always a chance your script/program is horribly designed. I'm guessing you meant to say that a bad design is more likely via an evolutionary process like static HTML -> PHP. In that matter, the nature of PHP is both a strength and a weakness—People who suck at programming would be equally bad using a more complex framework. Your tool can't make people stop sucking, because you have to be smart enough to use it right. PHP does hit a power ceiling faster (it takes more effort and discipline to keep a large PHP project clean than a large Django/RoR/Java Servlet project), but that by itself doesn't deserve criticism. See Worse is Better for a better description of why the low power level provided by PHP is not a failure.
CGI and mod_perl fit on the same level as PHP, in my book. Choose whatever you're comfortable with; no one else cares, as long as you don't expose it in your URLs. I'll keep on using PHP, because I know how to write secure code with PHP, and I don't care to spend the time learning the equivalent in Perl (but maybe C++, now that you mention it).
In the past 10 days I have not died. In fact, I will survive every day of my life except for one. That's a pretty good average, right? Too bad the average has no impact whatsoever on the worst-case. Past performance only gives an indication of what the general market trends used to be, not what they will be for the rest of 2008.
You may disagree and vomit on me for saying this, but how about the OpenGL API? Even though it's all in C, it seems to me that it has a mixture of procedural and OO calls:
I suppose I've cheated a bit... You asked for a demonstration of OO/procedural code, but my example is about an API. I conflate the two in my mind, though, because in my opinion, any well-written code is that way because of the internal interfaces and scoping constructs, whether they are procedural or OO.
The most natural definition of "coupling" I've seen is to imagine the set of all variables in a program as nodes in a graph. Any time two variables are referenced in the same function, there is an edge between those two variables. What you'll end up with in many cases is that sets of variables tend to get used together, and the whole graph looks like a lot of small clusters. A good OO design captures that clustering, so the end result is that within a single object many member variables get used in tandem, but between objects there is relatively little sharing. This applies to well-written C code, as well (sockets and pthreads are examples of OO designs implemented in procedural languages).
That may not be a fair measurement, but it's the best that I've seen. All it's really doing is putting up artificial walls between different parts (or layers) of a piece of software, so it's easy for a human to consume one chunk at a time. Of course, I'd argue that's what most of software development is about - implementing algorithms within the limitations of the human attention span (which is much smaller than a Turing machine).
I agree. Sucks. Also generally requires sysadmin-level permissions in order to change basic configuration such as error reporting, error level, magic quotes, etc. Starting from a stock OS install, it probably takes me about half an hour to get a PHP installation into a reasonable "default" state.
Come to think of it, reminds me of setting CXXFLAGS in my Makefile to include -Wall -Wextra -Wno-reorder -Werror -march=pentium4 -minline-all-stringops -ffast-math -O2 -ggdb. Even the Java JVM has fairly important tuning parameters (the most common solution to Eclipse performance problems back when I used it was "give it most of your system memory, and close it when you're done coding"). It's hard to create a flexible system without introducing bootstrapping complexity, and it requires up-front planning that simply wasn't a part of PHP's history.
Take a look at the "decorate-sort-undecorate" idiom in PHP; it speaks for itself.
function functional_sort($array) { sort($array); return $array; }
function make_sort_key($datum) { return -$datum; }
$original = array(1, 2, 3, 4, 5, 6, 7);
$sorted = array_map( create_function('$tuple', 'return $tuple[0];'),
array_map( 'functional_sort',
array_map( create_function('$single', 'return array(make_sort_key($single), $single);'),
$original )));
Apologies for syntax errors, that's off the top of my head. Anyone who says PHP can't be used for functional programming is just not creative enough. The correct answer is that PHP can be used as a functional language, but it probably shouldn't be used that way (as you can clearly see).
I actually do have a beef with this. I find PHP's method of output more natural than something like a C or C++ program where you have to explicitly manage I/O. The fact that it can be horribly abused is no worse than the fact that any program in any other language can horribly abuse I/O. All of the (recent) PHP output I've written is as well-organized as any template-based system, thankyouverymuch.
PHP offered me something. Dirt simple installation and a very easy migration path from static HTML pages to something dynamic. That may not be much use for a lot of people, but I find it very natural for creating interfaces. While systems like Django are enticing, I'll probably stick with PHP for my small home-server apps just because of the learning curve.
I haven't yet, but it's never too late to start! Gotta keep 'em on their toes...
Was that an errant "like"? Or did you really mean to say that a giant monster is going to befriend two farmers in the middle of Kansas?
Second that. One of the big advantages of rasterization is the cache. Raytracing is notorious for locality of memory references.
Check out The Ray Engine. This uses the GPU to parallelize ray-triangle intersections.
Raytracing basically gives you point samples across a 2d plane. Rasterizing those point samples is a pretty straightforward task for the GPU. Not to mention all of the other rendering layers: someone mentioned caustics... you could dedicate one CPU to photon-mapping caustics and layer those on as a rasterized "onion skin".
Ok, so the toilet analogy is sunk. The underlying point still holds: provide users with an incentive to fix their problems, or they won't get fixed. The ISP for that same apartment complex would temporarily block users (via DNS poisoning) when virus or other "wtf" network behavior was detected. It sucked if it was a weekend (call center only had weekday hours), but it was pretty easy to deal with, and it provided the necessary incentive without pissing people off.
Not always. What about all of the sites that replicate Wikipedia's content and plaster ads all over it? They're not providing anything useful. In contrast, there's plenty of "old school" websites like The Krib that have content without ads. Just because ads sometimes provide the support for useful content does not make ads intrinsically worthwhile.
Or 4.) Use QoS (traffic shaping) to keep bandwidth usage as "fair" as possible with soft limits (so the P2P heavy user never gets fully cut-off, always gets whatever free traffic is available, and never gets to hog the pipes during peak times). Or any combination of the above. Why is it always "increase capacity or limit users"? Why can't it be "increase capacity /and/ limit users"?
One apartment complex I used to live at in college gave us an allotment of $40/month for water. Anything beyond that, and we were required to pay for it. They used to provide water for free. What happened is that every once in a while, someone's toilet would get stuck running; but since it didn't have any impact on the resident, it wouldn't get fixed. After instating the $40/month cap, the running-toilet problem just went away, because people found the time to fix their toilets (or report it to the maintenance staff, who would then fix it).
While the exact overage fees may be ridiculous (witness the several-thousand-dollar AT&T bills for people who left their iPhones on when visiting Europe), the concept itself isn't a bad idea. In the water example, there was still a solution for people too clueless to fix the problem themselves - call maintenance. An ISP that charges overage fees should be notifying a user of "suspicious" bandwidth usage and providing support services to clean up infected computers.
It really doesn't have to be an argument about the elite vs. the lusers. There are non-BS reasons to provide an incentive to keep your sh*t in order.
Seriously? That's a bit of a stretch. It's not like the virus writers and the ISPs are scheming behind everyone's back. When a virus sweeps through a network...
- The whole network gets saturated with virus traffic
- tech support volume increases as people call to see what's wrong with the Internet
- customer satisfaction goes down because of the degraded service and because everyone spent an hour waiting for tech support on the phone
- people cancel their contracts and move to some other provider
Not to mention the legal ramifications if it were made public that an ISP released a virus on its customers to increase bandwidth-usage profits.