Where are you going to back up all this data? That's what these big ass DVDs are for.
No, that's what tapes are for. Writable optical random-access media happen to do well for short-term backups (they don't have the shelf-life for long-term) but it's not really what they're *for*.
What is being presented is the fact the Microsoft enjoys abnormally high profit margins
What is being presented is a claim that Microsoft enjoys abnormally high profit margins, and the question has been raised is whether those margins are, in fact, abnormally high. Maybe they are, but it's a valid question. Clearly, at least part of that margin is perfectly normal business, and michael's characterization of the entire margin as "monopoly rent" is just spew.
As a nursing student I will be trying to bring this into any hospital I eventually work for.
Doing your part to increase antibiotic resistance in the hospitals, eh? You do realize that some organisms will resist the GSE's effects, and then transfer that resistance to nastier bugs, right? Right? IMO doing what you suggest should be a firing offense.
Please take a couple more microbiology and public-health classes before you leave nursing school...and before you start killing people.
core clock speeds are getting faster and faster...Suppose you have two processors that are 6 centimeters apart...[lots of other irrelevant drivel deleted]
Gee, maybe all that's why people are going to things like multiple cores on one die, hyperthreading, etc. Programming-wise, these present the same interface as multiple physical CPUs, but they also ameliorate many of the problems you mention...speaking of which, everything you're presenting as a "killer" for multithreading is even worse for your multi-process model.
A two microsecond RTT (e.g., Myrinet)
As a former Dolphin employee, I have to point out that Myrinet was never that fast.
Dependence on round-trip latency implies that the program is I/O bound.
You remember that little thing about using parallelism to mask latency? Most serious programs outside of the scientific community are I/O bound anyway and the whole point of multithreading is to increase parallelism.
Obviously the communication/networking hardware will have to be built directly into the CPU core.
Getting rather far afield here, aren't you?
I wasn't bitching about [context switching]. I was correcting the misstatement that its influence on performance was zero
You're forgetting that an operation's effect on performance is a product of its cost and frequency. Go read H&P; it'll spell this out for you much better than I can.
I was pointing out that all applications that want maximum performance will be designed that way.
What about those that can't? That's a lot of applications, including important ones like databases which must preserve operation ordering across however many threads/processes/nodes are in use. You can't just point to some exceptional cases that are amenable to a particular approach, and then wave your hands about the others. Well, you can - you just did - but it doesn't convince anyone.
Take a look at what the Linux kernel is doing sometime.
Since you're practically an AC I can't be sure, but odds are pretty good that I know more about what the Linux kernel is doing and excellent that I know more about what kernels in general are doing. Your appeal to (anonymous) authority won't get you anywhere.
The real point that we started with is your claim that any multithreaded application will "suck". That statement only has meaning relative to other approaches that accomplish the same goals. Are you ever going to get around to backing that up, or will you just keep going around and around the issue in ever-widening circles hoping I'll get nauseous and quit?
No, you're looking toward the past. In the future, multi-CPU machines will become more common, not less, and learning to use them efficiently will also become more important. Within the box, multithreading will perform better than alternatives, even if there's message passing going on between boxes.
These processors will use asynchronous message-passing logic at the very core, and farther out the system will be entirely based on messages. HyperTransport is the writing on the wall.
Yes, I'm somewhat familiar with transitions between message passing and shared memory. Remember that fast interconnect I mentioned, from five years ago? It was at Dolphin. On the wire, it was message passing. Above that, it presented a shared-memory interface. Above that, I personally implemented DLPI/NDIS message-passing drivers because that's what some customers wanted.
The fact is that whatever's happening down below, at the programming-model level it's still more efficient to have multiple tasks coordinate by running in the same address space than by having them spend all their time packing and unpacking messages. The lower-level message-passing works precisely because it's very task-specific and carefully optimized to do particular things, but that all falls down when the messages have to be manipulated by the very same processors you were hoping to use for your real work.
The future of high-performance computing is message passing
...between nodes that are internally multi-processor.
The request-producer doesn't have to block waiting for the first response: it can keep queueing requests.
Yes, yes, using parallelism to mask latency. Yawn. Irrelevant.
Every screen update requires at least one context switch. Does it suck? Not at all.
If context switches aren't all that bad, why were you bitching about context switching in multithreaded applications? Hm. The fact is, a context switch is less expensive that a context switch plus packing/unpacking plus address manipulation plus (often) a data copy. Your proposal is to use multiple processes instead of threads, even within one box. When are you going to start explaining how that will perform better, or even as well? When it won't "suck", to use your own charming phrase.
What about Monte Carlo simulations? Losing the occassional random process is irrelevant. What about artificial intelligences running on really big machines?
Please try to pay attention. I already referred to regularly decomposable applications with high compute-to-communicate ratios, and that's exactly what you're talking about. Yes, what you say is true for some applications, but does it work in general? No. As I said, I've worked in high availability. I've seen database app after database app, all based on message passing between nodes, lock up because one node froze but didn't crash. Everyone's familiar with applications hanging when the file server goes out, and that's not shared memory either. Message passing doesn't make causal dependencies go away.
If the system is built on a foundation of multithreading, the only failure mode is a total crash.
Simply untrue. I've seen (and written) plenty of multithreaded applications that could survive an abnormal thread exit better than most IPC-based apps could survive an abnormal process exit.
For lots of applications the slowdown will be lost in the noise.
It isn't zero, though.
No, it's not zero but (as I said; *sigh*) it's a small price to pay to get multiprocessor scalability.
If you have a few million tasks to do, pretty much any threading system is going to suck.
On the contrary, a threading system is highly likely to be the only way you'll meet your cost/performance goals, because a well-written multithreaded server running on a 4-way server will get you nearly 4 CPUs worth of performance. One written your way will require a rack full of machines and fast switches plus some custom state-management code, and might still thrash itself to death no matter how much hardware you throw at it. Please, educate yourself. Do some reading, run some tests, get some experience...then come back and we can talk about which approaches can handle millions of requests per minute.
Every context switch burns hundreds, if not tens of thousands, of clock cycles.
A well-designed multi-threaded implemention will organize its thread usage in such a way that under light load and/or on a single processor it will not have significantly more context switches than a single-threaded equivalent. Under such conditions it will exhibit the same performance characteristics as that single-threaded version, and yet it will also be able to take advantage of inherent parallelism and multiple processors when they exist. Been there.
Bad multithreaded implementations schedule so many computationally active threads that TSE switches are inevitable. Bad multithreaded implementations force two context switches per request as work is handed off between "listener" and "worker" threads. Bad multithreaded implementations do lots of stupid things, but not all multithreaded implementations are bad. The main overhead involved in running a well-designed multithreaded program on a uniprocessor is not context switches but locking, and that will be buried in the noise. Done that.
A handful of extra context switches per second and a fraction of a percent of extra locking overhead are a small price to pay for multiprocessor scalability.
It's trivial to run multiple copies of a single-threaded program on the different CPUs, and let them interact over IPC.
Trivial, but stupid. You really will context-switch yourself to death that way, as every occasion where you need to coordinate between processes generates at least one IPC and every IPC generates at least one context switch (usually two or more)...and those are complete process/address-space switches, not relatively lightweight thread switches. That's how to build a really slow application.
this approach scales trivially to large numbers of networked processors.
No, it doesn't. There's simply no comparison between the speed of using the same memory - often the same cache on the same processor, if you do things right - and shipping stuff across the network...any network, and I was working on 1.6Gb/s full-duplex 2us app-to-app round-trip interconnects five years ago. Writing software to run efficiently on even the best-provisioned loosely-coupled system is even more difficult than writing a good multithreaded program. That's why people only bother for the most regularly decomposable problems with very high compute-to-communicate ratios.
catastrophic failure of one process does not necessarily corrupt the state of another process. (While one thread crashing is almost certain to bring down an entire multi-threaded program.)
Using separate processes instead of threads on a single machine might allow your other processes to stay alive if one dies, but your application will almost certainly be just as dead. The causal dependencies don't go away just because you're using processes instead of threads. In many ways having the entire application go down is better, because at least then it can be restarted. When I used to work in high availability, a hung node was considered much worse than a crash, and the same applies to indefinite waits when part of a complex application craps out.
anyone who runs more than about 4*NCPUS threads in a program is an idiot
I'd look at it a different way, and count likely-to-be-active threads. If that number's much greater than NCPUS you're probably hurting yourself, but threads that are certain or almost certain to be sleeping (e.g. periodic tasks that are between invocations) don't really count. I discuss this issue more in an article on my website about avoiding context switches (part of a larger article about server design) if you're interested.
There are definitely cases where using multiple threads on a single-processor system can degrade performance (switching, locking, etc.).
This is only a factor with a poor multithreaded design. By contrast, single-threaded programs always fail to take advantage of multiple processors, no matter how well they're designed otherwise.
applications where deadlocks or race conditions would be an integral problem in a multithreaded implementation whilst a single thread has none of these problems.
That's a common myth. In fact, there are some kinds of deadlock that do go away, but there are also some kinds that merely change their shape. For example, the need to lock a data structure to guarantee consistent updates goes away, and so do deadlocks related to locking multiple data structures. OTOH, resource-contention deadlocks don't go away. You might still have two "tasks" contending for resources A and B, except that in the non-threaded model the tasks might be chained event handlers for some sort of state machine instead of threads. If task1 tries to get A then B, and task2 tries to get B then A, then task1's "B_READY" and task2's "A_READY" events will never fire and you're still deadlocked. Sure, you can solve it by requiring that resources be taken in order, but you can do that with threads too; the problem's solvable, but isn't solved by some kind of single-threading magic.
I've written several articles on this topic for my website in the past. In case anyone's interested...
I totally agree. My wife got a standalone device for this from eBay, but it came without a manual and we never figured out how to do anything but set the clock. I tried a D-Link USB Radio, but it couldn't pull in anything and the user interface was unusable (custom controls that hung the system). If I could find a card or USB device that actually worked I'd be happy; ideal would be something that I could program via the computer or network but that then ran by itself.
such a display could be run native in a HSB (hue-saturation-brightness) mode
...only without control over saturation and brightness.;-) The ability (in theory, not current practice) to vary hue is kind of cool, but without the other two axes it's not going to be all that practical.
With this technology, I can get any color I want by varying the plate distance continuously!
What, were you asleep when we went over that? A single subpixel can only be a pure hue or black. Right now that subpixel is limited to a single hue, on or off. Maybe - maybe - some day a single subpixel can vary its hue by varying the gap, but there'll still be no way to vary its intensity. You have one axis of variation (the gap); varying both hue and intensity would require two axes.
I can just dither between pixels of that hue and black pixels. This doesn't require many bits.
Do the math. I just did, and another poster did, and we both came to the exact same conclusion, and yes it does require a lot of bits if you're dithering between pure hues and black. If you could vary a subpixel's hue and you were willing to display only darker shades but not lighter, you could make do with a lot fewer pixels, but that's simply not going to be satisfactory for general use.
When these are all at full brightness, it looks white.
Yeah, that's great when you can control brightness.
As for intensity. Here's a simple method.
Have you done the math on this? If you want 24-bit color you'll need 768 subpixels per pixel (256 for each of red, green and blue). That drives up the manufacturing cost and drives down yield (as allowable stuck-pixel counts are exceeded, and there will be stuck pixels just as there are in LCDs) but that doesn't even matter. Those 768 subpixels will form a square 28 pixels on a side; at the stated (minimum) size of 25 microns that's a pixel 0.7mm across - a.k.a. 36dpi. Besides being a generally crappy resolution, that's coarse enough that the color variation within the pixel will be visible to the human eye. Dropping down to 16-bit color gets the pixel size to reasonable (though still not particularly good) levels, so it's possible to have a display that's fine for regular use but will still be shunned by many users. There's also no mention of color-change latency, which might also be a concern for many users.
I don't mean to be a nay-sayer. Personally I'd be happy with 12-bit color and a pretty high color-change latency. My point is really that taking full advantage of this technology will require a fundamentally different approach to color and not just a naive "throw more subpixels at the problem" approach.
It used to be called LEP (Light Emitting Polymers); now the favored term seems to be OLED (Organic Light Emitting Diode). Cambridge Display Technologies in the UK has really been driving this technology, and I'm pretty sure it's been written up at least once or twice before here on Slashdot.
Well if you had looked at the technology at their web site, the subpixels CAN'T be White
That makes it even more limiting, doesn't it?
The technology has the color of each subpixel fixed by it's physical properties. (ie. it's digital, not analog)
If you had read the web site, you'd know that the color of each pixel is determined by the size of the gap (that's why blue has a smaller gap than red) and the resulting interference. I'm also making an optimistic assumption that they'll figure out a way to make the gaps variable rather than strict on/off.
Sadly, no mention on the site of how they think they play to provide any INTENSITY information.
...which was exactly my point. Thanks for playing.
You bring up an interesting point: it's not clear how a device like this can produce different saturation levels for a pure hue. In other systems, a single subpixel has a single color but variable intensity, and subpixels of different colors can be combined to produce a range of colors. In this system, each subpixel is capable of producing any color, but only at an intensity defined by ambient light. Consider a three-subpixel unit where each subpixel can be either white, red, or black. This gives only the following possibilities: white, black, two shades of grey (BBW, BWW), and six kinds of red (RRR, RRB, RRW, RBB, RBW, RWW). Now, a single subpixel could be cyan or indigo all by itself, creating a different kind of flexibility, but I'm not sure if that's as useful as what we get with variable-intensity RGB subpixels.
Yes, I've seen definitions in books too, and that's precisely why I took you to task. When you do get around to checking the book, you'll find that PHP fits the definition better than you seem to think. For example, it does have object polymorphism; I've used it. It does not have function polymorphism, but that has fuck-all to do with OOP anyway and IMO its absence is a good thing. PHP is not C++, it's not Java, it's not Smalltalk, it doesn't have specific features that those do, but anyone who can see beyond mere prejudice would see that it does support OOP in a meaningful way.
So, what exactly does a language need to count as "object oriented" in your book, that PHP doesn't have? This should be interesting; there's a difference between not supporting your style of OOP (probably based in having learned OOP in some other language and gotten used to its warts) and not supporting OOP at all.
There are a lot of traps and pitfalls in OO PHP that most people would call all-out bugs.
You could replace "PHP" in the above with the name of just about any other language (that supports any kind of OO) and it would be (at least) equally true. Most OO models take some getting used to, and PHP's model is less troublesome than some of the common alternatives.
repeated logic must be maintained across all pages
That's a problem with crappy programming in any language, not specifically PHP. I've seen plenty of cut 'n' paste FORTRAN, C/C++, Java, Perl, and Python before.
php is a flat procedural-like language
Wrong. It's practically true of Perl with bolt-on OO bits, but has never been true of PHP.
Slashdot Mirror
No, that's what tapes are for. Writable optical random-access media happen to do well for short-term backups (they don't have the shelf-life for long-term) but it's not really what they're *for*.
See also my recently-posted list of links to articles on my own website discussing these very matters.
I wouldn't. Any halon system capable of doing that would literally be a killer in its own right.
What is being presented is a claim that Microsoft enjoys abnormally high profit margins, and the question has been raised is whether those margins are, in fact, abnormally high. Maybe they are, but it's a valid question. Clearly, at least part of that margin is perfectly normal business, and michael's characterization of the entire margin as "monopoly rent" is just spew.
Doing your part to increase antibiotic resistance in the hospitals, eh? You do realize that some organisms will resist the GSE's effects, and then transfer that resistance to nastier bugs, right? Right? IMO doing what you suggest should be a firing offense.
Please take a couple more microbiology and public-health classes before you leave nursing school...and before you start killing people.
...and anything else - most especially the approach you espouse - will truly and royally suck more. Life just sucks sometimes; too bad, you lose.
Gee, maybe all that's why people are going to things like multiple cores on one die, hyperthreading, etc. Programming-wise, these present the same interface as multiple physical CPUs, but they also ameliorate many of the problems you mention...speaking of which, everything you're presenting as a "killer" for multithreading is even worse for your multi-process model.
As a former Dolphin employee, I have to point out that Myrinet was never that fast.
You remember that little thing about using parallelism to mask latency? Most serious programs outside of the scientific community are I/O bound anyway and the whole point of multithreading is to increase parallelism.
Getting rather far afield here, aren't you?
You're forgetting that an operation's effect on performance is a product of its cost and frequency. Go read H&P; it'll spell this out for you much better than I can.
What about those that can't? That's a lot of applications, including important ones like databases which must preserve operation ordering across however many threads/processes/nodes are in use. You can't just point to some exceptional cases that are amenable to a particular approach, and then wave your hands about the others. Well, you can - you just did - but it doesn't convince anyone.
Since you're practically an AC I can't be sure, but odds are pretty good that I know more about what the Linux kernel is doing and excellent that I know more about what kernels in general are doing. Your appeal to (anonymous) authority won't get you anywhere.
The real point that we started with is your claim that any multithreaded application will "suck". That statement only has meaning relative to other approaches that accomplish the same goals. Are you ever going to get around to backing that up, or will you just keep going around and around the issue in ever-widening circles hoping I'll get nauseous and quit?
No, you're looking toward the past. In the future, multi-CPU machines will become more common, not less, and learning to use them efficiently will also become more important. Within the box, multithreading will perform better than alternatives, even if there's message passing going on between boxes.
Yes, I'm somewhat familiar with transitions between message passing and shared memory. Remember that fast interconnect I mentioned, from five years ago? It was at Dolphin. On the wire, it was message passing. Above that, it presented a shared-memory interface. Above that, I personally implemented DLPI/NDIS message-passing drivers because that's what some customers wanted.
The fact is that whatever's happening down below, at the programming-model level it's still more efficient to have multiple tasks coordinate by running in the same address space than by having them spend all their time packing and unpacking messages. The lower-level message-passing works precisely because it's very task-specific and carefully optimized to do particular things, but that all falls down when the messages have to be manipulated by the very same processors you were hoping to use for your real work.
...between nodes that are internally multi-processor.
Yes, yes, using parallelism to mask latency. Yawn. Irrelevant.
If context switches aren't all that bad, why were you bitching about context switching in multithreaded applications? Hm. The fact is, a context switch is less expensive that a context switch plus packing/unpacking plus address manipulation plus (often) a data copy. Your proposal is to use multiple processes instead of threads, even within one box. When are you going to start explaining how that will perform better, or even as well? When it won't "suck", to use your own charming phrase.
Please try to pay attention. I already referred to regularly decomposable applications with high compute-to-communicate ratios, and that's exactly what you're talking about. Yes, what you say is true for some applications, but does it work in general? No. As I said, I've worked in high availability. I've seen database app after database app, all based on message passing between nodes, lock up because one node froze but didn't crash. Everyone's familiar with applications hanging when the file server goes out, and that's not shared memory either. Message passing doesn't make causal dependencies go away.
Simply untrue. I've seen (and written) plenty of multithreaded applications that could survive an abnormal thread exit better than most IPC-based apps could survive an abnormal process exit.
No, it's not zero but (as I said; *sigh*) it's a small price to pay to get multiprocessor scalability.
On the contrary, a threading system is highly likely to be the only way you'll meet your cost/performance goals, because a well-written multithreaded server running on a 4-way server will get you nearly 4 CPUs worth of performance. One written your way will require a rack full of machines and fast switches plus some custom state-management code, and might still thrash itself to death no matter how much hardware you throw at it. Please, educate yourself. Do some reading, run some tests, get some experience...then come back and we can talk about which approaches can handle millions of requests per minute.
BTW, thanks for visiting my site. Where's yours?
A well-designed multi-threaded implemention will organize its thread usage in such a way that under light load and/or on a single processor it will not have significantly more context switches than a single-threaded equivalent. Under such conditions it will exhibit the same performance characteristics as that single-threaded version, and yet it will also be able to take advantage of inherent parallelism and multiple processors when they exist. Been there.
Bad multithreaded implementations schedule so many computationally active threads that TSE switches are inevitable. Bad multithreaded implementations force two context switches per request as work is handed off between "listener" and "worker" threads. Bad multithreaded implementations do lots of stupid things, but not all multithreaded implementations are bad. The main overhead involved in running a well-designed multithreaded program on a uniprocessor is not context switches but locking, and that will be buried in the noise. Done that.
A handful of extra context switches per second and a fraction of a percent of extra locking overhead are a small price to pay for multiprocessor scalability.
Trivial, but stupid. You really will context-switch yourself to death that way, as every occasion where you need to coordinate between processes generates at least one IPC and every IPC generates at least one context switch (usually two or more)...and those are complete process/address-space switches, not relatively lightweight thread switches. That's how to build a really slow application.
No, it doesn't. There's simply no comparison between the speed of using the same memory - often the same cache on the same processor, if you do things right - and shipping stuff across the network...any network, and I was working on 1.6Gb/s full-duplex 2us app-to-app round-trip interconnects five years ago. Writing software to run efficiently on even the best-provisioned loosely-coupled system is even more difficult than writing a good multithreaded program. That's why people only bother for the most regularly decomposable problems with very high compute-to-communicate ratios.
Using separate processes instead of threads on a single machine might allow your other processes to stay alive if one dies, but your application will almost certainly be just as dead. The causal dependencies don't go away just because you're using processes instead of threads. In many ways having the entire application go down is better, because at least then it can be restarted. When I used to work in high availability, a hung node was considered much worse than a crash, and the same applies to indefinite waits when part of a complex application craps out.
Neither. ;-) Listener/worker separation is a fundamentally flawed model; try symmetric multithreading instead.
I'd look at it a different way, and count likely-to-be-active threads. If that number's much greater than NCPUS you're probably hurting yourself, but threads that are certain or almost certain to be sleeping (e.g. periodic tasks that are between invocations) don't really count. I discuss this issue more in an article on my website about avoiding context switches (part of a larger article about server design) if you're interested.
This is only a factor with a poor multithreaded design. By contrast, single-threaded programs always fail to take advantage of multiple processors, no matter how well they're designed otherwise.
That's a common myth. In fact, there are some kinds of deadlock that do go away, but there are also some kinds that merely change their shape. For example, the need to lock a data structure to guarantee consistent updates goes away, and so do deadlocks related to locking multiple data structures. OTOH, resource-contention deadlocks don't go away. You might still have two "tasks" contending for resources A and B, except that in the non-threaded model the tasks might be chained event handlers for some sort of state machine instead of threads. If task1 tries to get A then B, and task2 tries to get B then A, then task1's "B_READY" and task2's "A_READY" events will never fire and you're still deadlocked. Sure, you can solve it by requiring that resources be taken in order, but you can do that with threads too; the problem's solvable, but isn't solved by some kind of single-threading magic.
I've written several articles on this topic for my website in the past. In case anyone's interested...
I totally agree. My wife got a standalone device for this from eBay, but it came without a manual and we never figured out how to do anything but set the clock. I tried a D-Link USB Radio, but it couldn't pull in anything and the user interface was unusable (custom controls that hung the system). If I could find a card or USB device that actually worked I'd be happy; ideal would be something that I could program via the computer or network but that then ran by itself.
...only without control over saturation and brightness. ;-) The ability (in theory, not current practice) to vary hue is kind of cool, but without the other two axes it's not going to be all that practical.
What, were you asleep when we went over that? A single subpixel can only be a pure hue or black. Right now that subpixel is limited to a single hue, on or off. Maybe - maybe - some day a single subpixel can vary its hue by varying the gap, but there'll still be no way to vary its intensity. You have one axis of variation (the gap); varying both hue and intensity would require two axes.
Do the math. I just did, and another poster did, and we both came to the exact same conclusion, and yes it does require a lot of bits if you're dithering between pure hues and black. If you could vary a subpixel's hue and you were willing to display only darker shades but not lighter, you could make do with a lot fewer pixels, but that's simply not going to be satisfactory for general use.
Yeah, that's great when you can control brightness.
Have you done the math on this? If you want 24-bit color you'll need 768 subpixels per pixel (256 for each of red, green and blue). That drives up the manufacturing cost and drives down yield (as allowable stuck-pixel counts are exceeded, and there will be stuck pixels just as there are in LCDs) but that doesn't even matter. Those 768 subpixels will form a square 28 pixels on a side; at the stated (minimum) size of 25 microns that's a pixel 0.7mm across - a.k.a. 36dpi. Besides being a generally crappy resolution, that's coarse enough that the color variation within the pixel will be visible to the human eye. Dropping down to 16-bit color gets the pixel size to reasonable (though still not particularly good) levels, so it's possible to have a display that's fine for regular use but will still be shunned by many users. There's also no mention of color-change latency, which might also be a concern for many users.
I don't mean to be a nay-sayer. Personally I'd be happy with 12-bit color and a pretty high color-change latency. My point is really that taking full advantage of this technology will require a fundamentally different approach to color and not just a naive "throw more subpixels at the problem" approach.
It used to be called LEP (Light Emitting Polymers); now the favored term seems to be OLED (Organic Light Emitting Diode). Cambridge Display Technologies in the UK has really been driving this technology, and I'm pretty sure it's been written up at least once or twice before here on Slashdot.
That makes it even more limiting, doesn't it?
If you had read the web site, you'd know that the color of each pixel is determined by the size of the gap (that's why blue has a smaller gap than red) and the resulting interference. I'm also making an optimistic assumption that they'll figure out a way to make the gaps variable rather than strict on/off.
...which was exactly my point. Thanks for playing.
You bring up an interesting point: it's not clear how a device like this can produce different saturation levels for a pure hue. In other systems, a single subpixel has a single color but variable intensity, and subpixels of different colors can be combined to produce a range of colors. In this system, each subpixel is capable of producing any color, but only at an intensity defined by ambient light. Consider a three-subpixel unit where each subpixel can be either white, red, or black. This gives only the following possibilities: white, black, two shades of grey (BBW, BWW), and six kinds of red (RRR, RRB, RRW, RBB, RBW, RWW). Now, a single subpixel could be cyan or indigo all by itself, creating a different kind of flexibility, but I'm not sure if that's as useful as what we get with variable-intensity RGB subpixels.
Yes, I've seen definitions in books too, and that's precisely why I took you to task. When you do get around to checking the book, you'll find that PHP fits the definition better than you seem to think. For example, it does have object polymorphism; I've used it. It does not have function polymorphism, but that has fuck-all to do with OOP anyway and IMO its absence is a good thing. PHP is not C++, it's not Java, it's not Smalltalk, it doesn't have specific features that those do, but anyone who can see beyond mere prejudice would see that it does support OOP in a meaningful way.
So, what exactly does a language need to count as "object oriented" in your book, that PHP doesn't have? This should be interesting; there's a difference between not supporting your style of OOP (probably based in having learned OOP in some other language and gotten used to its warts) and not supporting OOP at all.
You could replace "PHP" in the above with the name of just about any other language (that supports any kind of OO) and it would be (at least) equally true. Most OO models take some getting used to, and PHP's model is less troublesome than some of the common alternatives.
That's a problem with crappy programming in any language, not specifically PHP. I've seen plenty of cut 'n' paste FORTRAN, C/C++, Java, Perl, and Python before.
Wrong. It's practically true of Perl with bolt-on OO bits, but has never been true of PHP.