That's certainly a big part of it. The Linux kernel is moderately mature, so there's not a lot of low hanging fruit for a new developer to pick. Things like embedded hardware drivers require special hardware that most people don't have/want/need, which tends to put a damper on people doing work in that space (again, unless they work for Montavista or somebody). The graphics subsystem requires fairly specialized knowledge that most new devs (and most old devs who don't work for ATI, NVIDIA, or Intel) don't have and can't feasibly get, so that's not likely to be a big draw. And so on. It's all about working on a small niche of a niche, which is fine as long as you care about that particular niche, but most people aren't particularly into making Linux run on a toaster or microwave, so....
Another big reason is that Mac OS X took a lot of the wind out of Linux's sails. In years past, most of the laptops I saw at geek conferences were random PCs running Linux. These days, though their server boxes still run Linux, their development laptops are often Macs running Mac OS X, maybe with Linux in a VM, but usually not. A lot of those same sorts of people used to be occasional Linux kernel dabblers back when they ran Linux. Now, not so much. Similarly, a lot of the young CS students are often running Mac OS X in their dorm rooms instead of Linux, which means there's less exposure. Fewer geek users = fewer new potential developers.
Depends on which one line of code. Add one line in a ubiquitously included header file along the lines of "#define int uint64_t" and see how many of those four million lines expect an int to be 4 bytes long. Sure, that's an extreme example, but you get the idea.
If you're doing actual development work, what difference does another 100MB make?
The average Linux 2.2 kernel patch was somewhere around 5kB compressed. The average 2.6 patch is somewhere around 150kB compressed. If you were doing development back in 2.2, when you pulled an update, you got a handful of files and a couple of k in lots of little high latency pieces. Half a minute later and you were patched. With 2.6, do the math.
Now imagine in a couple of years when the drivers have bloated that up to 2GB and the patch sets are measured in megabytes, or worse, tens of megs. Just the computing time to perform the diff operation or even gather the diffs from the backing store starts to become painfully expensive.
C++ has never been shown to be a very good language for writing kernels. There's a reason that every kernel I've know of is written in C.
The entire driver stack of the Mac OS X kernel is written in C++. I'd say that's pretty good proof that it works. Perfect, no, but is has done a pretty decent job.
Odd, I'm looking at http://www.kernel.org/pub/linux/kernel/v2.6/ and the latest kernel I see is 2.6.33, and that comes in at a whopping 81 megabytes for the compressed tarball. Extracted, it takes almost 434 megabytes. That's over twelve minutes of DVD-quality video. That's two-thirds of a CD-R. That's ten times the size of the Mac OS X kernel. That's two months of bandwidth at the lowest tier of cell phone service.... You get the idea. It's freaking huge. The kernel sources were too big way back in 2.2. Now, they're just pure comedy.
Also, remember that source control systems add a significant performance penalty that is also proportional to the number of files, not just the number of bytes. So although the giant compressed tarball may take only five minutes to download from kernel.org (which is an eternity), I'd expect a source checkout to take a good bit longer.
But doesn't "just overriding one method in a class" mean changing a function pointer?
The point wasn't that there's an underlying difference, but rather that the syntax of a class hierarchy tends to result in design patterns in which the things that need to be part of the class are part of the class and not part of some giant library of functions. The result is that instead of the semi-OO design pattern of using pointers for only the functions that you already know will need to be replaced, you have a true OO design pattern where any of them can be replaced without having to push for changes to thousands of lines of code all over the place that refer to that function.
It's not that if you use a derived class for your driver, all the other drivers will magically use the derived class instead of the one they were designed and compiled for.
I never suggested that they would. Why would they need to? There should be no accidental interaction between drivers. Any instances of variables shared between two unrelated drivers should be deliberate and rare. I should be able to make changes to my copy of the ATA core code without breaking your driver. That said, if you want the ability to do things like that, Objective-C categories would work....:-D
Also consider that C++ is less supported on embedded systems, and has a much more complex (and changing) ABI than C.
All the more reason to use a limited subset of C++ (no exceptions, no templates, etc.) and to freeze the parts of the ABI that the kernel uses. Apple has managed to write their driver stack in C++ with AFAIK no binary compatibility breakage since they switched from GCC 2.95 to GCC 3 way back in 2003.... (Okay, so the CPU architecture change was something of a binary compatibility breakage, but you know what I mean.)
Wrong, absolutely wrong. Greg K-H himself has explicitly said that he WANTS people with drivers for even highly obscure devices to merge them into the mainline kernel. It doesn't matter if your capacitive multi-touch screen is only used in one phone; the code is useful to have publicly available in the kernel as a reference. Furthermore, as more drivers for similar devices are merged into the kernel, commonalities between them can be found, and more generic drivers can be created.
Based on what I've seen over the years (as a developer on a project that never made it back into the mainstream kernel), the problems with this approach are threefold:
Nobody maintains most of them. Most of the 5% of drivers that everybody uses are already in the kernel tree. Of the remaining 95%, half of the drivers don't build at all, and most of the other half don't work. If they're barely maintained now, you can bet money that they won't be maintained at all when some kernel tree maintainer gets a hair up his/her backside and decides that a particular fix isn't elegant enough and won't take the changes....
The tree is already too large. If every driver out there were in the tree, checking out an update to the tree would be horribly painful, the source packages that distributions include would become huge, etc. The bigger it gets, the fewer people are going to be willing to maintain their drivers inside that tree, so in the long run, encouraging people to put their drivers in the tree is just going to cause other drivers to move back out of the tree, eliminating any real benefit.
Many such drivers are outside the tree because they require substantial changes to some subsystem in order to build them. Now one could argue that these changes should be made to those subsystems to make them more general, or one could argue that those drivers are so specialized that nothing else will use them, so there's no reason to bother. That's often not an easy question to answer, and tends to result in highly political shouting matches, with the end result being that the driver never goes in, which is usually why those drivers got published outside the kernel tree to begin with.
There are ways to solve these problems, of course; IMHO, they basically amount to:
Design a kernel build infrastructure that can easily bring in driver sources from third-party sites (like a ports collection, but for kernel drivers). With proper categorization, this can provide all the same benefits as having the drivers in the main tree, but also allows for a richer tagging scheme instead of a simple filesystem hierarchy, which should actually make it significantly easier to spot patterns (for example, seeing that there are now eighty-seven different drivers for capacitive touchscreens, or whatever), all without bloating the tree that everybody has to download.
Subject all kernel API changes to a formal API review process in which no API change can go in unless the owners of all drivers in that area agree that the design is acceptable and will meet with their needs. Set up a reasonable set of rules of engagement (e.g. A. don't shoot down the idea just because you don't need it, B. don't shoot down an idea without proposing an alternative). And so on.
Redesign the kernel interfaces in an object-oriented language. Such designs make it more likely that drivers can extend the interfaces without requiring major changes to the core code. The Linux kernel sort of halfway adopts this approach insofar as code reuse is concerned, but does so in ways that aren't particularly clean and neat.
For example, if I were writing an ATA driver and needed to do almost everything the same way but change the behavior of one function in some other library... say down at the block device layer, I'd either have to make a change to the block device layer with some special case detection code or I'd have to copy entire swaths of code at the ATA device layer and c
In practice, though, no portable device transmits anywhere near a watt. The only way you get close to 1W ERP is if you're using a base station with a directional aerial. AFAIK, most laptops are capped somewhere around 50 mW, well below the ERP limits of any country, with typical transmit power more on the order of 10-30 mW.
Either way, it sounds like this isn't so much about the actual power, but rather about the lack of certification.
If you don't hear the word subluxation, you're not dealing with a chiropractor. The entire point of chiropractic care is to adjust the position of spinal vertebrae, which is what subluxation refers to. That said, if they throw the word around a lot, that may well be a clue that they are abusing the term.
Ear aches are actually a really bad example. A lot of ear aches are really muscle knots in the SCM (sternocleidomastoid) muscle.
And even when you have a real ear ache with a bacterial causes, chronic ear aches can be the result of excessive tension in certain neck muscles causing insufficient eustachian tube drainage. When the ears don't drain properly, they are more prone to infection. That's not saying chiropractic care can fix the infection, but it can reduce the incidence of it.
That's actually quite common. The suboccipital muscles (the ones that attach across the base of your skull along the back of your head) are frequently the cause of headaches. I'm not certain why this is the case, but I think it's probably because the nerves for your head come out near the top of the spine, passing very close to these muscles, so any muscle knots could potentially apply pressure to the facial nerves and other cranial nerves.
Either way, massaging the suboccipital muscles can often relieve both headaches and sinus pressure. Chiropractic adjustments to the neck could easily reduce cramping in those muscles, which in turn would also reduce the rate of headaches.
Actually, I probably shouldn't say that misaligned spinal vertebrae cause the muscle tension; correlation is not causation, and it's equally possible that the muscle tension causes the misalignment. Either way, cracking the spine forces those muscles to relax.
Whoa, there. There are two different schools of thought in Chiropractic care. It's important not to lump them together.
The first school of thought, which Wikipedia refers to as "straight" chiropractors, is an untestable pile of gibberish in which the spine and nerves cause everything that's wrong with the human body. I wouldn't disagree with your description of that as quackery, but that's not an accurate description of what most chiropractors believe.
The second school of thought (and the predominant theory among modern chiropractors) is scientific in nature and is fairly sound. In this school of thought, misaligned spinal vertebrae cause muscles in the back and neck to tighten up to prevent injury (trivially provable). The result of this is cramping, pain, and reduced flexibility in the neck and spine (also trivially provable). This, in turn, can cause or contribute to a number of other musculoskeletal problems such as sciatica, arthritic pain in the knees, stress headaches, etc. Spinal adjustments (particularly when followed by additional muscle work) allows the muscles in the back and neck to relax, reducing pain caused by muscle stiffness, allowing greater freedom of motion. This, in turn, allows the person to use better posture without pain, which reduces the rate of damage in other places.
Can people be injured by chiropractic care? Sure. Can people be injured by botched spinal surgery? Also yes. Is spinal surgery quackery? No, and neither is most chiropractic care.
I have the same attitude with all products: if I can't figure it out in 30 minutes, without consulting a manual (see below), I just give up.
Incidentally, I can't read, write, swim, drive or ride a bicycle. I assume none of those things is any good.
That's not really a fair analogy. It's probably more like, "I've been driving a car for twenty years. If I get into your car and can't figure out how to turn it on, pull out of the parking place and drive somewhere within thirty minutes, I conclude that the car is no good."
Basic cut-and-splice video editing is a very simple process. In a good user interface, the actions a user must take to perform any simple and common task should be both discoverable and simple. Any software in which such functionality is difficult or undiscoverable is badly written software, period. You really should not need to read a manual for such basic usage unless the UI is unintuitive, which makes it, by definition, bad software. That's not saying that you should be able to be a power user in thirty minutes. You might not figure out every esoteric feature in thirty minutes, but you should be able to at least get most of the basics.
To go back to your bicycle example, this is like not being able to figure out how to raise the kickstand in the first thirty minutes. If you find that this is the case, something is massively wrong, and unless the user is a complete and total idiot, it's probably the UI.
You're probably right about MS. And they would be a few million dollars poorer, which sounds like a lot until you realize that it's on the order of 0.001% of their market cap.... In short, nothing would be substantially different in the grand scheme of things. It's neither a gain nor a loss. However when you factor in all the other companies that used the same stack and *did* push changes back, it's pretty clear that the BSD license was a net win.
Corporations for the most part don't care about open source software. If they can use it, great, they'll use it. If they can't, they'll rewrite it. The only real difference as far as open source projects are concerned is that if they are able to use the open source code, there's at least some possibility that they will care enough to give back improvements that everyone benefits from, whereas if they have to rewrite it, there's no possibility of that happening.
Sure, the BSD license promotes the freedom of companies to close up code you wrote and it sell back to you.
Ah, but in practice, most of the time, either A. the company keeps it open source anyway (e.g. Apple with most of the lower half of Mac OS X), B. the company builds a closed source version but regularly pushes fixes upstream, or C. the software is in a device where changing out parts of the software is well beyond the skills of a typical user (e.g. your microwave oven). Most of the exceptions to that statement never gained any real traction in the marketplace.
Sure, you can point out a few prominent exceptions, e.g. Microsoft using BSD's TCP/IP stack in Windows, but do you honestly expect anybody to believe that anyone would have been served by the original stack being under the GPL? Microsoft would never have made their kernel open source anyway, so they either would have rewritten it or worse, developed a competing network standard. Either of those would have resulted in further fragmentation of the market, more bugs that users have to suffer through, and in general a worse perception of computing by the public as a whole. The only way you could reasonably argue that anyone would have benefitted from this is if you honestly believe that Windows (already the dominant platform by this time) would have lost its dominance due to Linux having a better TCP/IP stack sooner. That's a pretty big stretch of the imagination, to say the least.
Chrome is also a bad example. It's based on WebKit, and portions of WebKit are under the LGPL. I doubt they've stripped out and rewritten all of WebCore.
I'll go one step further and say that statistically speaking, the majority of the criminals will be poor (or in the case of drug dealers, moderately wealthy, but from poor families), and most will be members of a repressed minority in the country in question.
Nah. They just turn sideways with their left arms pointed outwards. And in this particular picture, they also bent their elbows sideways, though this is optional.
What I don't envy is the person on top of the ladder taking the photo....
In other news, 100% of [insert site here]'s passwords were compromised when someone realized that no human alive can remember such gibberish without writing it down and sticking it on a post-it note under the keyboard.
Nope. Technically data is a plural noun, datum is singular, so "are" is the correct word. In modern usage, however, data is often considered a collective noun, which can take either a singular or plural verb, depending on whether you're talking about British or American English.
Right. The difference is that with the glossy screen, you can adjust it until the reflection of the light source is no longer uncomfortable (or even visible). With the matte screen, it doesn't matter which direction you point it; if the light source is behind you at all, you're going to get unacceptable washout.
Slashdot Mirror
That's certainly a big part of it. The Linux kernel is moderately mature, so there's not a lot of low hanging fruit for a new developer to pick. Things like embedded hardware drivers require special hardware that most people don't have/want/need, which tends to put a damper on people doing work in that space (again, unless they work for Montavista or somebody). The graphics subsystem requires fairly specialized knowledge that most new devs (and most old devs who don't work for ATI, NVIDIA, or Intel) don't have and can't feasibly get, so that's not likely to be a big draw. And so on. It's all about working on a small niche of a niche, which is fine as long as you care about that particular niche, but most people aren't particularly into making Linux run on a toaster or microwave, so....
Another big reason is that Mac OS X took a lot of the wind out of Linux's sails. In years past, most of the laptops I saw at geek conferences were random PCs running Linux. These days, though their server boxes still run Linux, their development laptops are often Macs running Mac OS X, maybe with Linux in a VM, but usually not. A lot of those same sorts of people used to be occasional Linux kernel dabblers back when they ran Linux. Now, not so much. Similarly, a lot of the young CS students are often running Mac OS X in their dorm rooms instead of Linux, which means there's less exposure. Fewer geek users = fewer new potential developers.
Depends on which one line of code. Add one line in a ubiquitously included header file along the lines of "#define int uint64_t" and see how many of those four million lines expect an int to be 4 bytes long. Sure, that's an extreme example, but you get the idea.
The average Linux 2.2 kernel patch was somewhere around 5kB compressed. The average 2.6 patch is somewhere around 150kB compressed. If you were doing development back in 2.2, when you pulled an update, you got a handful of files and a couple of k in lots of little high latency pieces. Half a minute later and you were patched. With 2.6, do the math.
Now imagine in a couple of years when the drivers have bloated that up to 2GB and the patch sets are measured in megabytes, or worse, tens of megs. Just the computing time to perform the diff operation or even gather the diffs from the backing store starts to become painfully expensive.
The entire driver stack of the Mac OS X kernel is written in C++. I'd say that's pretty good proof that it works. Perfect, no, but is has done a pretty decent job.
Odd, I'm looking at http://www.kernel.org/pub/linux/kernel/v2.6/ and the latest kernel I see is 2.6.33, and that comes in at a whopping 81 megabytes for the compressed tarball. Extracted, it takes almost 434 megabytes. That's over twelve minutes of DVD-quality video. That's two-thirds of a CD-R. That's ten times the size of the Mac OS X kernel. That's two months of bandwidth at the lowest tier of cell phone service.... You get the idea. It's freaking huge. The kernel sources were too big way back in 2.2. Now, they're just pure comedy.
Also, remember that source control systems add a significant performance penalty that is also proportional to the number of files, not just the number of bytes. So although the giant compressed tarball may take only five minutes to download from kernel.org (which is an eternity), I'd expect a source checkout to take a good bit longer.
The point wasn't that there's an underlying difference, but rather that the syntax of a class hierarchy tends to result in design patterns in which the things that need to be part of the class are part of the class and not part of some giant library of functions. The result is that instead of the semi-OO design pattern of using pointers for only the functions that you already know will need to be replaced, you have a true OO design pattern where any of them can be replaced without having to push for changes to thousands of lines of code all over the place that refer to that function.
I never suggested that they would. Why would they need to? There should be no accidental interaction between drivers. Any instances of variables shared between two unrelated drivers should be deliberate and rare. I should be able to make changes to my copy of the ATA core code without breaking your driver. That said, if you want the ability to do things like that, Objective-C categories would work.... :-D
All the more reason to use a limited subset of C++ (no exceptions, no templates, etc.) and to freeze the parts of the ABI that the kernel uses. Apple has managed to write their driver stack in C++ with AFAIK no binary compatibility breakage since they switched from GCC 2.95 to GCC 3 way back in 2003.... (Okay, so the CPU architecture change was something of a binary compatibility breakage, but you know what I mean.)
Based on what I've seen over the years (as a developer on a project that never made it back into the mainstream kernel), the problems with this approach are threefold:
There are ways to solve these problems, of course; IMHO, they basically amount to:
Design a kernel build infrastructure that can easily bring in driver sources from third-party sites (like a ports collection, but for kernel drivers). With proper categorization, this can provide all the same benefits as having the drivers in the main tree, but also allows for a richer tagging scheme instead of a simple filesystem hierarchy, which should actually make it significantly easier to spot patterns (for example, seeing that there are now eighty-seven different drivers for capacitive touchscreens, or whatever), all without bloating the tree that everybody has to download.
Subject all kernel API changes to a formal API review process in which no API change can go in unless the owners of all drivers in that area agree that the design is acceptable and will meet with their needs. Set up a reasonable set of rules of engagement (e.g. A. don't shoot down the idea just because you don't need it, B. don't shoot down an idea without proposing an alternative). And so on.
Redesign the kernel interfaces in an object-oriented language. Such designs make it more likely that drivers can extend the interfaces without requiring major changes to the core code. The Linux kernel sort of halfway adopts this approach insofar as code reuse is concerned, but does so in ways that aren't particularly clean and neat.
For example, if I were writing an ATA driver and needed to do almost everything the same way but change the behavior of one function in some other library... say down at the block device layer, I'd either have to make a change to the block device layer with some special case detection code or I'd have to copy entire swaths of code at the ATA device layer and c
So you're saying that the first poster really would help her, just not in the way he intended.
In practice, though, no portable device transmits anywhere near a watt. The only way you get close to 1W ERP is if you're using a base station with a directional aerial. AFAIK, most laptops are capped somewhere around 50 mW, well below the ERP limits of any country, with typical transmit power more on the order of 10-30 mW.
Either way, it sounds like this isn't so much about the actual power, but rather about the lack of certification.
No, it's not an essential part of the theory. Some chiropractors believe that, but AFAIK, most do not....
If you don't hear the word subluxation, you're not dealing with a chiropractor. The entire point of chiropractic care is to adjust the position of spinal vertebrae, which is what subluxation refers to. That said, if they throw the word around a lot, that may well be a clue that they are abusing the term.
Ear aches are actually a really bad example. A lot of ear aches are really muscle knots in the SCM (sternocleidomastoid) muscle.
And even when you have a real ear ache with a bacterial causes, chronic ear aches can be the result of excessive tension in certain neck muscles causing insufficient eustachian tube drainage. When the ears don't drain properly, they are more prone to infection. That's not saying chiropractic care can fix the infection, but it can reduce the incidence of it.
That's actually quite common. The suboccipital muscles (the ones that attach across the base of your skull along the back of your head) are frequently the cause of headaches. I'm not certain why this is the case, but I think it's probably because the nerves for your head come out near the top of the spine, passing very close to these muscles, so any muscle knots could potentially apply pressure to the facial nerves and other cranial nerves.
Either way, massaging the suboccipital muscles can often relieve both headaches and sinus pressure. Chiropractic adjustments to the neck could easily reduce cramping in those muscles, which in turn would also reduce the rate of headaches.
Actually, I probably shouldn't say that misaligned spinal vertebrae cause the muscle tension; correlation is not causation, and it's equally possible that the muscle tension causes the misalignment. Either way, cracking the spine forces those muscles to relax.
Whoa, there. There are two different schools of thought in Chiropractic care. It's important not to lump them together.
The first school of thought, which Wikipedia refers to as "straight" chiropractors, is an untestable pile of gibberish in which the spine and nerves cause everything that's wrong with the human body. I wouldn't disagree with your description of that as quackery, but that's not an accurate description of what most chiropractors believe.
The second school of thought (and the predominant theory among modern chiropractors) is scientific in nature and is fairly sound. In this school of thought, misaligned spinal vertebrae cause muscles in the back and neck to tighten up to prevent injury (trivially provable). The result of this is cramping, pain, and reduced flexibility in the neck and spine (also trivially provable). This, in turn, can cause or contribute to a number of other musculoskeletal problems such as sciatica, arthritic pain in the knees, stress headaches, etc. Spinal adjustments (particularly when followed by additional muscle work) allows the muscles in the back and neck to relax, reducing pain caused by muscle stiffness, allowing greater freedom of motion. This, in turn, allows the person to use better posture without pain, which reduces the rate of damage in other places.
Can people be injured by chiropractic care? Sure. Can people be injured by botched spinal surgery? Also yes. Is spinal surgery quackery? No, and neither is most chiropractic care.
That's not really a fair analogy. It's probably more like, "I've been driving a car for twenty years. If I get into your car and can't figure out how to turn it on, pull out of the parking place and drive somewhere within thirty minutes, I conclude that the car is no good."
Basic cut-and-splice video editing is a very simple process. In a good user interface, the actions a user must take to perform any simple and common task should be both discoverable and simple. Any software in which such functionality is difficult or undiscoverable is badly written software, period. You really should not need to read a manual for such basic usage unless the UI is unintuitive, which makes it, by definition, bad software. That's not saying that you should be able to be a power user in thirty minutes. You might not figure out every esoteric feature in thirty minutes, but you should be able to at least get most of the basics.
To go back to your bicycle example, this is like not being able to figure out how to raise the kickstand in the first thirty minutes. If you find that this is the case, something is massively wrong, and unless the user is a complete and total idiot, it's probably the UI.
You're probably right about MS. And they would be a few million dollars poorer, which sounds like a lot until you realize that it's on the order of 0.001% of their market cap.... In short, nothing would be substantially different in the grand scheme of things. It's neither a gain nor a loss. However when you factor in all the other companies that used the same stack and *did* push changes back, it's pretty clear that the BSD license was a net win.
Corporations for the most part don't care about open source software. If they can use it, great, they'll use it. If they can't, they'll rewrite it. The only real difference as far as open source projects are concerned is that if they are able to use the open source code, there's at least some possibility that they will care enough to give back improvements that everyone benefits from, whereas if they have to rewrite it, there's no possibility of that happening.
Ah, but in practice, most of the time, either A. the company keeps it open source anyway (e.g. Apple with most of the lower half of Mac OS X), B. the company builds a closed source version but regularly pushes fixes upstream, or C. the software is in a device where changing out parts of the software is well beyond the skills of a typical user (e.g. your microwave oven). Most of the exceptions to that statement never gained any real traction in the marketplace.
Sure, you can point out a few prominent exceptions, e.g. Microsoft using BSD's TCP/IP stack in Windows, but do you honestly expect anybody to believe that anyone would have been served by the original stack being under the GPL? Microsoft would never have made their kernel open source anyway, so they either would have rewritten it or worse, developed a competing network standard. Either of those would have resulted in further fragmentation of the market, more bugs that users have to suffer through, and in general a worse perception of computing by the public as a whole. The only way you could reasonably argue that anyone would have benefitted from this is if you honestly believe that Windows (already the dominant platform by this time) would have lost its dominance due to Linux having a better TCP/IP stack sooner. That's a pretty big stretch of the imagination, to say the least.
Chrome is also a bad example. It's based on WebKit, and portions of WebKit are under the LGPL. I doubt they've stripped out and rewritten all of WebCore.
This is what date stamps and the way back machine are for.
You mean like an off-by one? :-)
(If I have to explain that there are only 168 hours in a week, then I guess it wasn't funny.)
I'll go one step further and say that statistically speaking, the majority of the criminals will be poor (or in the case of drug dealers, moderately wealthy, but from poor families), and most will be members of a repressed minority in the country in question.
Nah. They just turn sideways with their left arms pointed outwards. And in this particular picture, they also bent their elbows sideways, though this is optional.
What I don't envy is the person on top of the ladder taking the photo....
In other news, 100% of [insert site here]'s passwords were compromised when someone realized that no human alive can remember such gibberish without writing it down and sticking it on a post-it note under the keyboard.
Nope. Technically data is a plural noun, datum is singular, so "are" is the correct word. In modern usage, however, data is often considered a collective noun, which can take either a singular or plural verb, depending on whether you're talking about British or American English.
Apple != Adobe.... Unless you're saying that some Apple app doesn't work on case-sensitive HFS+, in which case please file a bug @bugreport.apple.com.
Right. The difference is that with the glossy screen, you can adjust it until the reflection of the light source is no longer uncomfortable (or even visible). With the matte screen, it doesn't matter which direction you point it; if the light source is behind you at all, you're going to get unacceptable washout.