If you would have read the decision itself instead of letting some liberal blogger dissect the ruling to the bash Bush benefit
I did. You should try to understand it.
You should actually read it because the issues at hand in why the PAA was challenged are the exact same as with the TSP.
No, they aren't. The TSP is challenged as being illegal both as violation of the Fourth Amendment and as violation of the statute law at the time it was initiated, which expressly prohibits the conduct admittedly committed under the TSP (which the then-President claimed was legal anyway under independent authorities of the President.)
The case on the PAA never found any independent authority of the President, it found that the PAA was within the Constitutional authority of Congress and that executive action within its bounds was within an exception to the warrant requirement of the 4th Amendment and met the reasonableness requirement of the 4th amendment. This doesn't support the legality of the any TSP actions outside the bounds of the PAA, since those were not Congressionally authorized at all (and some were Congressionally prohibited), so the finding on the authority of Congress does not support them. But that finding is critical to the finding on Fourth Amendment reasonableness, since authorization by legislative authority is, while not on its own enough to make something reasonable, a factor in reasonableness.
BTW, if some of those statements I quoted from the court looks familiar, it's because it is the exact same line of reasoning given in support of the TSP.
The fact that the court echoed some of the arguments made by defenders of the TSP being within independent Presidential authority when it found that the PAA was within Congress's authority and that actions within the bounds of the PAA were within the President's authority given the existence of the PAA does not mean that the court found the TSP legal. It did not.
There are two Constitutional bases on which the TSP is commonly challenged: 1) That some of the actions known or believed to have been carried out under the TSP are outside the Constitutional power of the government, and 2) That some of the actions known or believed to have been carried out under the TSP were prohibited by statute at the time committed, and are therefore outside of the legal power of those committing them whether or not they would be within the power of government if the statute law were either silent or supportive.
Only #1 applies to the actions within the PAA that were challenged in the case at issue, and the ruling of the court only addresses #1 with regard to those issues. It does not address #2 with regard to the issues outside of the PAA. Defenders of the independent authority of the President, of course, have to address both #1 and #2, so its unsurprising that a court that found that the PAA was within the Constitutional power of government would echo some of their arguments on #1, but echoing those arguments says nothing about #2. There is a difference between the powers of government and the independent power of the President; that an something is within the former does not mean it is within the latter.
Funny, outside of Internet Exploder, I find the most problems, in actual day to day usage, in Webkit based browsers. Opera and Firefox each have problems, yes, but I find they perform better than the competition, in terms of actual day to day usage.
I find that, too; I don't think its really a problem with the browsers, per se, as the fact that because IE is so dominant and non-standards-compliant, most web sites don't design to standards and then plug holes for various browsers, but instead design for IE, and then tweak to work with Firefox.
Parent is missing the intended hyperlink to the earlier slashdot story (which was intended to be placed in the last sentence) on the Court of Review ruling: see here.
You do realize that the FISA court of review has stated that the TSP was legal
This is not accurate; the Foreign Intelligence Surveillance Court of Review held that the Protect America Act was within the Constitutional power of Congress, and, therefore, that the portion of the TSP conducted within the confines (temporal and legal) of the PAA was legal. The TSP began before the PAA was proposed, much less adopted (and, as far as I know, continued after the PAA sunsetted, but that's another issue.) So at least some of the TSP is outside the scope of the ruling, even before considering whether all actions conducted under the TSP while the PAA was in force were, in fact, compliant with the PAA.
I could say I don't know why this didn't make it onto the Slashdot site but then again I already know the answer to that.
It is impossible to "know" the reason why something didn't happen when, in fact, it did happen.
Sorry if that interferes with your fact-deficient rant.
What does it mean to be "equipped with a means" to do something?
Presumably, the CPSC would have to adopt regulations enforcing this law, which would address that and issues like what it means in concrete terms to be "audible at a reasonable distance", etc.
It's either going to be very hard for manufacturers to comply with it, or else very easy to circumvent for the consumer.
Since it only affects camera phones it will be easy to circumvent for the consumer whether or not it is very hard for manufacturers to comply with it, since all the consumer has to do is pick up a non-phone compact camera that isn't covered by the law. This might creat the gigantic burden of having to remove, say, the micro-SD card from the camera and putting it into your phone (or a computer, or...) in order to send the pictures.
It would take less than a sentence. Can the mods please wake up and at least require a bare minimum standard?
I think you should direct your comments to/.'s so-called "editors", not the "mods". Mods rate comments, they don't have any particular influence on the stories that get posted.
It's a good job that cameras are only available on phones then. I mean, hypothetically speaking of course, if there were some way to obtain a camera that wasn't attached to a phone then this law would be ludicrous.
Its only ludicrous if you assume that the short title has anything to do with the purpose of the law, instead of assuming its a subsidy to the camera industry, encouraging people to buy both a mobile phone and a standalone camera rather than just the former.
In the U.S., if they put encryption on the code that locks the clicking noise in place, then it would be a DMCA violation to hack the phone not to click.
Hacking around the encryption to change (copyright-protected) code might be. A hard hack which allowed you to disable the speaker entirely at will wouldn't be a DMCA violation, since it wouldn't circumvent a measure that protected copyrightable material.
But if the police catch you and you're Android doesn't 'click' - even if you don't have anything illegal on the phone - they have something to charge you with.
Except that this law is a product "safety" law that would regulate manufacturers, and does nothing to make it illegal for users to use phones that don't click.
Now that we finally have silent cameras those political hacks want to... ban them ?!?
Silent cameras are fine under the proposed law, so long as they aren't built into a phone.
The main effect of this bill would seem to be to subsidize manufacturers of compact cameras by forcing "photographic predators" to buy standalone cameras (presumably, they are going to still want cell phones, whether or not the cameras therein are useful for their hobby.)
For one thing, this law would do NOTHING to alert deaf victims they are being photographed!
This law would do nothing to alert any victims that they were being photographed; its a product safety standard which regulates manufacturers, not a law which would directly affect the supposed "camera phone predators" that its heavily-spun short title suggests it is directed at. Particularly, it wouldn't stop camera phone users from subverting the alert, and it wouldn't stop predatory photographers from using similarly compact (or even more compact) cameras that aren't embedded in phones, which wouldn't be required to have any kind of alert. Nor would it, as drafted, appear to have any effect on video features in with cell phones, only still photography. (Unless it is interpreted so as to view each frame as a "photograph", which would present its own set of problems.)
(From here, oddly, the bill text page on Thomas is not linked from the summary information page on Thomas, which was linked in TFS; this seems to be a pretty boneheaded way of designing a bill tracking system.)
A BILL
To require mobile phones containing digital cameras to make a sound when a photograph is taken.
SECTION 1. SHORT TITLE.
This Act may be cited as the `Camera Phone Predator Alert Act'.
SEC. 2. FINDING.
Congress finds that children and adolescents have been exploited by photographs taken in dressing rooms and public places with the use of a camera phone.
SEC. 3. AUDIBLE SOUND STANDARD.
(a) Requirement- Beginning 1 year after the date of enactment of this Act, any mobile phone containing a digital camera that is manufactured for sale in the United States shall sound a tone or other sound audible within a reasonable radius of the phone whenever a photograph is taken with the camera in such phone. A mobile phone manufactured after such date shall not be equipped with a means of disabling or silencing such tone or sound.
(b) Enforcement by Consumer Product Safety Commission- The requirement in subsection (a) shall be treated as a consumer product safety standard promulgated by the Consumer Product Safety Commission under section 7 of the Consumer Product Safety Act (15 U.S.C. 2056). A violation of subsection (a) shall be enforced by the Commission under section 19 of such Act (15 U.S.C. 2068).
Re:Why people watch movies..
on
Daemon
·
· Score: 1
Tech in movies has a role meant to captivate the layperson - to keep them hooked; it is of no consequence whether it is acurate - it SOUNDS cool, and thus grips the viewer.
Everything, tech or otherwise, in movies, TVs, most novels, and most other entertainment products has that purpose, but getting stuff blatantly and laughably wrong can break people's suspension of disbelief. For different people that happens at different points, but when it happens, it can ruin the views enjoyment of the product.
So, its pretty likely that many/. readers might prefer entertainment products where the tech isn't blatantly wrong.
"Over 90% of open source code is written in the major languages: C, C++, Java, Javascript and C#"
And on this page they say:
"47% of these newly created projects used the C language. Java came in as the number two language of choice at nearly 28%. Third was Javascript at over 20%."
Both your links went to the same page, which doesn't include the first quote. The first quote (which comes from this page, not the one you linked) refers to the percentage of lines of code in the 170,000 open source projects in Black Duck's database that are in one of the four languages listed in that quote, the second refers to the percentage of 17,000 newly created open source projects from 2008 that use one or more of the languages listed in that quote. They aren't measuring the same thing (one measures lines of code, the other measues projects using any code in the languages, not the lines of code used), and they aren't drawing from the same universe (one is 170,000 open source projects, most of which are not new; the other is the 17,000 of those projects that are new in 2008.) You are drawing an invalid conclusion by ignoring these differences.
Since, according to the info on the Black Duck Softwre website (which is more detailed than TFA), Python has 10% and Ruby 6% (for some reason TFA reports the Ruby number but not the Python number), no, Ruby isn't ahead of Python.
(As something of a Ruby fan, I'm cautiously optimistic that 2009 will be a good year for Ruby, once 1.9.1 is out, which I believe is still scheduled for this weekend.)
Roosevelt cut off several incipient recoveries at the knees by increasing government interference in the economy.
The problem with this theory is that it conflicts with the actual facts, which are that a strong aggregate recovery began in March of 1933 and continued until the recession of 1937-1938 and resumed thereafter. There's simply no place for the "several incipient recoveries" that Roosevelt supposedly "cut off at the knees".
We could have recovered in the early 1930s
By the usual definition of "recovery" (i.e., ending a recession) we did begin recovery within 3 months of Roosevelt taking office. The only reason the vast improvement under Roosevelt prior to the war is, nonetheless, classed as part of a "Great Depression" that started under Hoover is because Hoover made things so bad over the years between 1929 and Roosevelt taking office in 1933 that several years of strong GDP growth and a substantial cut in the unemployment rate still left most people worse off than they had been before Hoover drove the economy off a cliff.
Morgenthau knew that the new deal was a disaster. He said "I say after eight years of this Administration we have just as much unemployment as when we started.... And an enormous debt to boot!" Unemployment was higher in 1939 than it was when FDR took office.
Except, of course, in the real world, where 17% is less than 23%.
That's true. I can say, though, that languages other than C or Java which are in the !scripting category must take up at least (100 - $C - $JAVA) percent.
No, you can't, because the percentages aren't out of different universes for scripting and non-scripting. You can say that the total using any languages that aren't C or Java must be at least (100 - $C - $JAVA) percent, but so what?
But then again, I don't know what makes a project written in a particular language. If my C code compiles fine with g++, is it written in C++?
It seems they classified by what the project was written in and not what the target platform (VM) was.
I never said that they classified by the VM. It is quite clear that they counted how many projects used a particular language, and explicitly noted that most projects used more than one language. The only comment I made that referred to a VM was that it is particularly common for projects that use other languages (particularly the languages that tend to get called "scripting languages") to also use either C or the principal system programming language for the VM they target (Java for the JVM), and therefore it is not at all surprising that C and Java took the top two spots.
While other languages may run on the JVM, I don't think they counted. JRuby would probably count as Ruby, not Java.
A project that used JRuby exclusively would, presumably, only count as using Ruby. A project that used both JRuby and Java, which is one of the major reasons to use JRuby, would count as using Ruby and Java. A project that used Ruby and C -- which is quite common among Ruby extensions -- would count as using Ruby and C.
Seeing as one of the projects mentioned with the most releases was in C#, is it lumping C,C++,C#, etc all under one label?
Probably not. The language percentages are out of all projects tracked, not releases, the "most releases" is a separate ranking of projects done from the same survey. The fact that a project has lots of releases doesn't make it count for more than any other project in the language share percentages, its still one project.
The fact that they differentiate C++, C#, and C as different languages in the "languages used" column (one of the "Rookies of the Year" projects has C and C++ both listed) seems to indicate that they did not lump them under one label, and that C++ (and C#) weren't as popular as C and Java.
The percentages are the percentages of projects that used the language.
TFA notes that most projects used more than one language.
Ergo, if you add up the percentages of the projects that use each language for every language in the survey (not all are reported in TFA), you will get some number > 150% (since more than half of the projects used at least two languages) and possibly much greater than that.
Note that 47+28 = 75, so that leaves 25%. Is C++ really that small? And let's just conveniently forget about C#, Objective C, and the odd app here or there written in lisp/scheme, an ML-like language (SML, ocaml, haskell), ada, pascal, eiffel, fortran,...
Note that the survey counts the number of projects that use a language, and TFA explicitly notes that the survey found that most projects use more than one language, so that you can't say that the percent that use some language other than C or Java = 100% - (percent using C) - (percent using Java).
[Scripting: js=20, pl=18, php=11, rb=6]
That's 20+18+11+6 = 55 (percent), leaving 45 percent to be fought over by languages not attracting more than 6% of the projects. That takes at least eight languages.
Scripting and !Scripting do not appear to separate universes, looking both at TFA and the press release it is based on; they appear to be presenting the percentage of the total pool of ~17,000 new projects that use each language, and just grouping the numbers for the scripting and non-scripting languages (but not taking them out of separate pools). So this conclusion appears to be invalid as well.
Why throw JavaScript in there? The rest are server-side languages, while JavaScript is client-side.
JavaScript is used for scripting in several non-web application, is used as a server side language for web apps, and is used as the predominant client-side scripting language for the web. It is not even close to exclusively a "client-side language", though the use which has made it ubiquitous is its use in that role.
And most of the other languages there aren't exclusively "client-side" or "server-side", either (a distinction that would only makes sense in regard to their use in client-server applications, usually web apps, which, while popular, aren't the only kind of apps.) If I write a desktop GUI app that is neither a client or a server -- which can be done in most, if not all, of the languages listed -- it doesn't make sense to describe that use as "client-side" or "server-side".
I'd expect that the C family won because of Objective-C; there was a huge amount of iPhone development this year.
I read TFA but don't have it open, ISTR that there only a small number of mobile projects, and a smaller number of those for the iPhone, on the order of 40, out of the thousands of new projects, so I don't think that Objective-C for the iPhone tipped the balance for the C family, even if they did count the C family as one unit.
Slashdot Mirror
I did. You should try to understand it.
No, they aren't. The TSP is challenged as being illegal both as violation of the Fourth Amendment and as violation of the statute law at the time it was initiated, which expressly prohibits the conduct admittedly committed under the TSP (which the then-President claimed was legal anyway under independent authorities of the President.)
The case on the PAA never found any independent authority of the President, it found that the PAA was within the Constitutional authority of Congress and that executive action within its bounds was within an exception to the warrant requirement of the 4th Amendment and met the reasonableness requirement of the 4th amendment. This doesn't support the legality of the any TSP actions outside the bounds of the PAA, since those were not Congressionally authorized at all (and some were Congressionally prohibited), so the finding on the authority of Congress does not support them. But that finding is critical to the finding on Fourth Amendment reasonableness, since authorization by legislative authority is, while not on its own enough to make something reasonable, a factor in reasonableness.
The fact that the court echoed some of the arguments made by defenders of the TSP being within independent Presidential authority when it found that the PAA was within Congress's authority and that actions within the bounds of the PAA were within the President's authority given the existence of the PAA does not mean that the court found the TSP legal. It did not.
There are two Constitutional bases on which the TSP is commonly challenged:
1) That some of the actions known or believed to have been carried out under the TSP are outside the Constitutional power of the government, and
2) That some of the actions known or believed to have been carried out under the TSP were prohibited by statute at the time committed, and are therefore outside of the legal power of those committing them whether or not they would be within the power of government if the statute law were either silent or supportive.
Only #1 applies to the actions within the PAA that were challenged in the case at issue, and the ruling of the court only addresses #1 with regard to those issues. It does not address #2 with regard to the issues outside of the PAA. Defenders of the independent authority of the President, of course, have to address both #1 and #2, so its unsurprising that a court that found that the PAA was within the Constitutional power of government would echo some of their arguments on #1, but echoing those arguments says nothing about #2. There is a difference between the powers of government and the independent power of the President; that an something is within the former does not mean it is within the latter.
I find that, too; I don't think its really a problem with the browsers, per se, as the fact that because IE is so dominant and non-standards-compliant, most web sites don't design to standards and then plug holes for various browsers, but instead design for IE, and then tweak to work with Firefox.
Parent is missing the intended hyperlink to the earlier slashdot story (which was intended to be placed in the last sentence) on the Court of Review ruling: see here.
This is not accurate; the Foreign Intelligence Surveillance Court of Review held that the Protect America Act was within the Constitutional power of Congress, and, therefore, that the portion of the TSP conducted within the confines (temporal and legal) of the PAA was legal. The TSP began before the PAA was proposed, much less adopted (and, as far as I know, continued after the PAA sunsetted, but that's another issue.) So at least some of the TSP is outside the scope of the ruling, even before considering whether all actions conducted under the TSP while the PAA was in force were, in fact, compliant with the PAA.
It is impossible to "know" the reason why something didn't happen when, in fact, it did happen.
Sorry if that interferes with your fact-deficient rant.
Presumably, the CPSC would have to adopt regulations enforcing this law, which would address that and issues like what it means in concrete terms to be "audible at a reasonable distance", etc.
Since it only affects camera phones it will be easy to circumvent for the consumer whether or not it is very hard for manufacturers to comply with it, since all the consumer has to do is pick up a non-phone compact camera that isn't covered by the law. This might creat the gigantic burden of having to remove, say, the micro-SD card from the camera and putting it into your phone (or a computer, or...) in order to send the pictures.
I think you should direct your comments to /.'s so-called "editors", not the "mods". Mods rate comments, they don't have any particular influence on the stories that get posted.
Its only ludicrous if you assume that the short title has anything to do with the purpose of the law, instead of assuming its a subsidy to the camera industry, encouraging people to buy both a mobile phone and a standalone camera rather than just the former.
Hacking around the encryption to change (copyright-protected) code might be. A hard hack which allowed you to disable the speaker entirely at will wouldn't be a DMCA violation, since it wouldn't circumvent a measure that protected copyrightable material.
Except that this law is a product "safety" law that would regulate manufacturers, and does nothing to make it illegal for users to use phones that don't click.
Silent cameras are fine under the proposed law, so long as they aren't built into a phone.
The main effect of this bill would seem to be to subsidize manufacturers of compact cameras by forcing "photographic predators" to buy standalone cameras (presumably, they are going to still want cell phones, whether or not the cameras therein are useful for their hobby.)
This law would do nothing to alert any victims that they were being photographed; its a product safety standard which regulates manufacturers, not a law which would directly affect the supposed "camera phone predators" that its heavily-spun short title suggests it is directed at. Particularly, it wouldn't stop camera phone users from subverting the alert, and it wouldn't stop predatory photographers from using similarly compact (or even more compact) cameras that aren't embedded in phones, which wouldn't be required to have any kind of alert. Nor would it, as drafted, appear to have any effect on video features in with cell phones, only still photography. (Unless it is interpreted so as to view each frame as a "photograph", which would present its own set of problems.)
(From here, oddly, the bill text page on Thomas is not linked from the summary information page on Thomas, which was linked in TFS; this seems to be a pretty boneheaded way of designing a bill tracking system.)
A BILL
To require mobile phones containing digital cameras to make a sound when a photograph is taken.
SECTION 1. SHORT TITLE.
This Act may be cited as the `Camera Phone Predator Alert Act'.
SEC. 2. FINDING.
Congress finds that children and adolescents have been exploited by photographs taken in dressing rooms and public places with the use of a camera phone.
SEC. 3. AUDIBLE SOUND STANDARD.
(a) Requirement- Beginning 1 year after the date of enactment of this Act, any mobile phone containing a digital camera that is manufactured for sale in the United States shall sound a tone or other sound audible within a reasonable radius of the phone whenever a photograph is taken with the camera in such phone. A mobile phone manufactured after such date shall not be equipped with a means of disabling or silencing such tone or sound.
(b) Enforcement by Consumer Product Safety Commission- The requirement in subsection (a) shall be treated as a consumer product safety standard promulgated by the Consumer Product Safety Commission under section 7 of the Consumer Product Safety Act (15 U.S.C. 2056). A violation of subsection (a) shall be enforced by the Commission under section 19 of such Act (15 U.S.C. 2068).
Everything, tech or otherwise, in movies, TVs, most novels, and most other entertainment products has that purpose, but getting stuff blatantly and laughably wrong can break people's suspension of disbelief. For different people that happens at different points, but when it happens, it can ruin the views enjoyment of the product.
So, its pretty likely that many /. readers might prefer entertainment products where the tech isn't blatantly wrong.
It did make the list, at 10%. Its not in the Register article, but it is in the original report from Black Duck Software.
Take your own advice.
Both your links went to the same page, which doesn't include the first quote. The first quote (which comes from this page, not the one you linked) refers to the percentage of lines of code in the 170,000 open source projects in Black Duck's database that are in one of the four languages listed in that quote, the second refers to the percentage of 17,000 newly created open source projects from 2008 that use one or more of the languages listed in that quote. They aren't measuring the same thing (one measures lines of code, the other measues projects using any code in the languages, not the lines of code used), and they aren't drawing from the same universe (one is 170,000 open source projects, most of which are not new; the other is the 17,000 of those projects that are new in 2008.) You are drawing an invalid conclusion by ignoring these differences.
Since, according to the info on the Black Duck Softwre website (which is more detailed than TFA), Python has 10% and Ruby 6% (for some reason TFA reports the Ruby number but not the Python number), no, Ruby isn't ahead of Python.
(As something of a Ruby fan, I'm cautiously optimistic that 2009 will be a good year for Ruby, once 1.9.1 is out, which I believe is still scheduled for this weekend.)
Yeah, I didn't not use to many negatives there. My bad.
The problem with this theory is that it conflicts with the actual facts, which are that a strong aggregate recovery began in March of 1933 and continued until the recession of 1937-1938 and resumed thereafter. There's simply no place for the "several incipient recoveries" that Roosevelt supposedly "cut off at the knees".
By the usual definition of "recovery" (i.e., ending a recession) we did begin recovery within 3 months of Roosevelt taking office. The only reason the vast improvement under Roosevelt prior to the war is, nonetheless, classed as part of a "Great Depression" that started under Hoover is because Hoover made things so bad over the years between 1929 and Roosevelt taking office in 1933 that several years of strong GDP growth and a substantial cut in the unemployment rate still left most people worse off than they had been before Hoover drove the economy off a cliff.
Except, of course, in the real world, where 17% is less than 23%.
No, you can't, because the percentages aren't out of different universes for scripting and non-scripting. You can say that the total using any languages that aren't C or Java must be at least (100 - $C - $JAVA) percent, but so what?
Now, that's an interesting question.
I never said that they classified by the VM. It is quite clear that they counted how many projects used a particular language, and explicitly noted that most projects used more than one language. The only comment I made that referred to a VM was that it is particularly common for projects that use other languages (particularly the languages that tend to get called "scripting languages") to also use either C or the principal system programming language for the VM they target (Java for the JVM), and therefore it is not at all surprising that C and Java took the top two spots.
A project that used JRuby exclusively would, presumably, only count as using Ruby. A project that used both JRuby and Java, which is one of the major reasons to use JRuby, would count as using Ruby and Java. A project that used Ruby and C -- which is quite common among Ruby extensions -- would count as using Ruby and C.
Probably not. The language percentages are out of all projects tracked, not releases, the "most releases" is a separate ranking of projects done from the same survey. The fact that a project has lots of releases doesn't make it count for more than any other project in the language share percentages, its still one project.
The fact that they differentiate C++, C#, and C as different languages in the "languages used" column (one of the "Rookies of the Year" projects has C and C++ both listed) seems to indicate that they did not lump them under one label, and that C++ (and C#) weren't as popular as C and Java.
The percentages are the percentages of projects that used the language.
TFA notes that most projects used more than one language.
Ergo, if you add up the percentages of the projects that use each language for every language in the survey (not all are reported in TFA), you will get some number > 150% (since more than half of the projects used at least two languages) and possibly much greater than that.
Note that the survey counts the number of projects that use a language, and TFA explicitly notes that the survey found that most projects use more than one language, so that you can't say that the percent that use some language other than C or Java = 100% - (percent using C) - (percent using Java).
Scripting and !Scripting do not appear to separate universes, looking both at TFA and the press release it is based on; they appear to be presenting the percentage of the total pool of ~17,000 new projects that use each language, and just grouping the numbers for the scripting and non-scripting languages (but not taking them out of separate pools). So this conclusion appears to be invalid as well.
JavaScript is used for scripting in several non-web application, is used as a server side language for web apps, and is used as the predominant client-side scripting language for the web. It is not even close to exclusively a "client-side language", though the use which has made it ubiquitous is its use in that role.
And most of the other languages there aren't exclusively "client-side" or "server-side", either (a distinction that would only makes sense in regard to their use in client-server applications, usually web apps, which, while popular, aren't the only kind of apps.) If I write a desktop GUI app that is neither a client or a server -- which can be done in most, if not all, of the languages listed -- it doesn't make sense to describe that use as "client-side" or "server-side".
I read TFA but don't have it open, ISTR that there only a small number of mobile projects, and a smaller number of those for the iPhone, on the order of 40, out of the thousands of new projects, so I don't think that Objective-C for the iPhone tipped the balance for the C family, even if they did count the C family as one unit.