This graphic is kinda dishonest, though. It excludes most of European Russia (by itself already about 13% the size of Africa and bigger then India) from Europe.
It also omits Alaska from the overlay. Alaska is the size of Spain, France, Germany, and the UK combined.
Hawaii's left out as well, but that's a much, er, smaller problem.
Perhaps you've never had to make revisions to something where you would want the original and new version side-by-side. Or wanted to keep an eye on a number of windows while still having enough space to work on a whole document.
To be fair, both are easy in 4:3 displays; I routinely have documents side-by-side on my 4:3 monitor, and with a taller display you can put your side-by-side code/documentation windows at the top and other windows at the bottom of the screen.
Having extra screen real estate is nice (and widescreen displays tend to have more pixels overall, hence are a big win in general), but the only time that having it in a widescreen ratio really matters is for movie viewing.
There's a reason that although you can hook up two monitors and line them up vertically, almost no one ever does.
The fact that most desks are a single horizontal surface rather than a tower of stacked platforms might play into this.
Yep. The north star changes identity fairly frequently--that's part of why I put that in there.
It just seems really odd for an article on this topic to omit discussions of many real changes in stars and constellations that people actually know about while dedicating time to a slight deformation of the Big Dipper (which at least is near the top of known constellations, but apparently isn't changing much) along with discourses on Hydra and one little star in Taurus drifting.
The conclusion is: not very much. The little dipper will become sort of triangular instead of rectangular. The Big Dipper and Orion will be mostly unchanged as far as anyone cares (Orion's shield will warp, but the belt--which is the only thing most people look at--will remain identical), and the only other changes discussed are to incredibly ancillary constellations like Hydra.
OTOH, there's absolutely zero discussion of a few of the stars most people have heard of and care about or any of the widely recognizable constellations outside of the big/little dippers. Will Polaris still be the North Star, or will it be replaced? Cassiopeia's Chair has famously become more and more W shaped--what will it look like as time passes? Will the Southern Cross--the flag of Australia, New Zealand, and several other southern hemisphere countries--remain the same?
Focusing on one small star in Taurus drifting slightly? Really?
Could you carry enough books with you to pass the bar exam?
Assuming you've done even a mediocre job in law school, it'd certainly help you pass the MBE portion of the bar. About 400 flash cards covering principles of common law and UCC2 would make that a breeze, which'd be easy to format into a pretty thin book with very fast reference. Throw in the BARBRI books and the degree of prep needed declines dramatically.
The vast majority of the study time in the couple of months leading up to the bar is rote memorization of a fairly limited set of facts; deeper legal thinking and writing ability are mostly things that you've either got by then through 3 years of school or aren't going to get (though a brush-up can be helpful).
The question is about web browser market share. That's a different number from the total installed OS base, as discussed upthread (a server-centric OS likely does less browsing per installed copy than a desktop-centric one). There are tons of sites and aggregates that show the same ballpark figures.
It's not a matter of English-centrism, either; Germany's certainly considered a Linux stronghold, but most German sites show the same numbers. See, e.g., http://www.webmasterpro.de/portal/webanalyse-systeme.html (which aggregates results from a number of German sites) shows 91.6% Windows, 5.1% Mac, and 1.5% Linux (.2% of which is Android).
There's another comparison chart here: http://en.wikipedia.org/wiki/Usage_share_of_operating_systems they have numbers from 12 sources ("All of these sources monitor a substantial number of web sites. Statistics that relate to a single web site are excluded.") and they also have a running average which comes out to 88.9% Windows, 6.2% Mac, and 1.3% Linux (.2% of which is Android).
Pretty much evey major source these days is showing numbers around the same ballpark.
Linux has a much higher installed base than that, but many of the platforms it's installed on are not desktops or handhelds that do a lot of browsing. If you look at servers, Linux pulls down somewhere from 20-40% according to most surveys. I wouldn't be surprised if the total OS installed base is closer to 10% than to 1% for Linux (as a percentage of all machines).
That figure's not really relevant to the issue at hand, though.
The numbers I posted are for web usage. If a significant number of people are spoofing their clients in non-standard ways, the numbers could be skewed; still, there are lots of different sites that show fairly similar distributions. Note that if someone has both a Linux desktop and a Windows desktop but for some reason uses the Linux desktop exclusively for browsing (or vice-versa) that will be reflected in the stats; that seems reasonable if you're discussing what percentage of the audience you're excluding with single-OS solutions.
Most estimates put Linux at around 1.5% of the web browser market (about 1.2% traditional and 0.3% Android usage), traditional Macs at around 6%, and iPhone/iPad/iTouch around 1%.
Windows (aggregated) is about 89% of the web browser market, with the difference being mostly other handheld/phone devices (Symbian and Blackberry being the next largest blocks after those mentioned).
That's just the straight usage numbers--it establishes an upper bound on your market. If you don't run on Linux/MacOs, you can't get that 8.5% of the market at all. Real-world factors push the exclusion higher (e.g. corporations that mostly run Windows, but only want to support one browser across all desktops and hence are limited to thinking about Firefox, Chrome, Opera, or some other non-IE browser).
Because the alcohol and tobacco lobbies, collectively known as "The partnership for a drug-free America", pay damn good money to buy the lawmakers opinions.
You can criticize the PDFA in a lot of ways, but this isn't one of them in recent years; they don't accept money from tobacco or alcohol companies (they quit allowing that over a decade ago) and they certainly run anti-alcohol campaigns--see, for instance, http://www.drugfree.org/Portal/Drug_Guide/Alcohol
So come up with a generic term that encompasses both PORT® wine and its imitators, and I'll deal.
That's not how it should work. Just like with trademarks, when a term is already generic (as is the case with champagne and port) then it should be up to the people who want a reserved term to come up with a new one. You can't just go around appropriating commonly used English words.
Miller Lite is a "golden beer" or "light pale lager beer" and not a PILSNER
Miller Lite actually says "True Pilsner Beer" right in the logo, which is fine since "pilsner" is a type of beer in English without regard to the city in Czech.
"Grown in Idaho" is different; it's a sentence with an English meaning that would be a lie if applied to something not grown in Idaho. Similarly, Napa valley champagnes shouldn't be allowed to advertise that they are "From Champagne", just as Vermont cheddar cheese shouldn't be allowed to advertise that it's from Cheddar and Oscar Meyer can't advertise that its wieners are from Wien.
They're there to help the artisan vintners, cheesemakers and other food manufacturers. It's to prevent the giant companies spotting a product is becoming popular and make their own version for half the price (and a quarter the quality) and giving it the same name.
Artisan vintners like Moet Hennessy Louis Vuitton?
Artisan vintners can easily trademark whatever name they're selling under as long as it hasn't already become genericized. This isn't about spotting new products on the rise, it's about redefining words that have already become well-established umbrella terms for certain styles, and it's pure protectionism.
Champagne and port have been in the dictionary as generic terms for centuries. Just from the standpoint of IP law, pulling them out of the public domain where they've safely landed and re-protecting them is even dumber than retroactive copyright extensions--and even worse (IMO) is the attempt to legally redefine words that have widely used English meanings.
well, Port is the name of the city from where Port wine comes from. And the same goes for many of those names. Of course it is wrong to call a wine Port when it doesn't come from where it says!
This is wrong. There is no city named "Port". Strict EU-controlled port comes from all over the Douro region of Portugal.
It's the same as if someone started labelling their products "proudly made in the US" when they weren't, as long it still "felt like a u.s. product" (which is basically your argument).
Do you refuse to eat sandwiches unless they're made in Sandwich, cheddar cheese that's not from Cheddar, or Belgian waffles that aren't from Belgium? Do you get really confused when your Russian or Italian dressing is made in the USA, or your Roman candles and Venetian blinds are made in China?
Are you outraged that most Brazil nuts come from Bolivia and confused about how a salon can offer a French manicure and a Brazilian wax when none of the employees are from France or Brazil?
Port, champagne, parmesan, and many other words that originated as geographic monikers have long since become English words with stylistic (rather than geographic) meanings.
I'm also disappointed at the ban on the name "port". I rarely drink but when I do it's usually port. Next time I feel like a bottle I won't know what to buy!
This is spot-on. The move to restrict names that originated as place names but have become style descriptors is ridiculous, IMO, and the decisions about what is protected and what isn't are purely political with no regard as to actual genericization.
It makes no sense that "Parmesan", "Sangria", and "Champagne" are geographically restricted but "Cheddar" and "Philadelphia cream cheese" aren't.
Champagne, Switzerland has been producing wine since before Dom Perignon came up with his method of making sparkling wine, but they're not allowed to label it as "Champagne"--that's because everyone knows "Champagne" is a word indicating a particular style, and calling the Swiss (non-sparkling) wine "Champagne" would confuse consumers.
Once you've recognized that, restricting the name by geography is ludicrous.
These laws actually serve to confuse consumers, not to help them--things like "port" are style descriptors in the English language. The right thing to do is to require actual claims of geography to be accurate (already the case) and let Duoro label their port as "Made in Duoro", Jerez label their Sherry as "Made in Jerez", etc.
Because any other value would be useless in resolving the question at hand.
The question was what the boolean behavior of the "=" operator was.
By setting true to 0, it's easy to illustrate that it is the final value of foo and not whether foo was successfully set that determines whether the "if" clause is executed.
Setting true to 1 would make the example ambiguous.
Very hard to find a main stream game that isn't written in C++
There are a whole heck of a lot that are written in C, and I suspect that a huge percentage of the engines that survive for a decade or more are written in C rather than C++.
It's very easy to find C programs in general that have been maintained successfully for 10, 20, or more years; it's much harder to find C++ programs with that pedigree, and that seems to have held true in about the same margins over the past 15+ years despite the ratio of C to C++ use for new programs changing significantly. Very complex languages aren't as amenable to long-term project maintenance as simpler ones (which is one of Pike's main points).
Since without mapping data a project like that cannot exist - it is unlikely there is a truly free alternative (and, as a consequence, not much open source - I suppose because open source developers don't really find a compelling reason to tie to a proprietary data set).
But there are non-proprietary mapping data sets available (e.g. openstreetmap.org)
A second good free compiler will be of tremendous use to the world. gcc is fine, but competition will make both better.
Definitely. The more options, the better.
It'll also make open source code better, as gccisms get cleaned out of code.
This I'm less sure on; clang goes out of its way to support a lot of gccisms (as do other compilers--e.g. the closed-source Intel compiler). It'll help some around the edges, for sure, but a lot of the most common gcc extensions are with us for the foreseeable future even with viable alternative compilers.
How often does debugging speed matter? That's like asking someone "How often does compiler speed matter?"
The answer is... depends on who you are. Many/most people simply don't care. To others, it's a key feature... Will I chose LLVM over GCC simply because of LLDB? Of course not! But for those times that LLVM is a good choice (and yes, I've used it before because it can be a better compiler suite), I'll be glad someone said "GDB is too slow. We can do better!"
I think we're in violent agreement there; my only objection was to positing LLDB as a possible killer feature that prompts mass switching away from GCC.
Clang is a front-end to LLVM, not a back-end. The LLVM embedded back-ends are still young, admittedly, but it's relatively easy to create new ones for the one-off embedded environments. And that can make it an ideal project for some developers.
Sure, but this is where GCC has a huge leg up--as the grey-bearded old project, it already has a ton of back-ends. If I'm working on a new embedded project and I have the choice of using GCC (where writing a back-end is painful, but it's already written) or LLVM (where it's comparatively easy, but needs to be done) I'm going to lean strongly toward GCC.
Now, LLVM's flexibility here means that hopefully it will catch up quickly, and with new platforms could easily garner support faster than GCC. Ultimately, barring a major GCC rearchitecture, ease of back-end development will be a big feather in LLVM's cap. But in the mid-term, the plethora of platforms GCC supports is still a check in its favor.
Debugger speed only matters whey you are debugging. Anything that significantly speeds up the edit/compile/debug cycle is very welcome.
Debugger speed barely matters for a lot of debugging, though. 85% of the time I run a debugger, gdb takes 1 second to start up and spends most of its time sitting waiting for input from me.
There are niches where a faster debugger matters, and if you're in one of those then it's very, very valuable, but it's hardly the sort of killer feature that's going to put LLVM over the top wrt GCC. There are a _ton_ of other LLVM features that are more important in that battle.
Slashdot Mirror
This graphic is kinda dishonest, though. It excludes most of European Russia (by itself already about 13% the size of Africa and bigger then India) from Europe.
It also omits Alaska from the overlay. Alaska is the size of Spain, France, Germany, and the UK combined.
Hawaii's left out as well, but that's a much, er, smaller problem.
Perhaps you've never had to make revisions to something where you would want the original and new version side-by-side. Or wanted to keep an eye on a number of windows while still having enough space to work on a whole document.
To be fair, both are easy in 4:3 displays; I routinely have documents side-by-side on my 4:3 monitor, and with a taller display you can put your side-by-side code/documentation windows at the top and other windows at the bottom of the screen.
Having extra screen real estate is nice (and widescreen displays tend to have more pixels overall, hence are a big win in general), but the only time that having it in a widescreen ratio really matters is for movie viewing.
There's a reason that although you can hook up two monitors and line them up vertically, almost no one ever does.
The fact that most desks are a single horizontal surface rather than a tower of stacked platforms might play into this.
Yep. The north star changes identity fairly frequently--that's part of why I put that in there.
It just seems really odd for an article on this topic to omit discussions of many real changes in stars and constellations that people actually know about while dedicating time to a slight deformation of the Big Dipper (which at least is near the top of known constellations, but apparently isn't changing much) along with discourses on Hydra and one little star in Taurus drifting.
The conclusion is: not very much. The little dipper will become sort of triangular instead of rectangular. The Big Dipper and Orion will be mostly unchanged as far as anyone cares (Orion's shield will warp, but the belt--which is the only thing most people look at--will remain identical), and the only other changes discussed are to incredibly ancillary constellations like Hydra.
OTOH, there's absolutely zero discussion of a few of the stars most people have heard of and care about or any of the widely recognizable constellations outside of the big/little dippers. Will Polaris still be the North Star, or will it be replaced? Cassiopeia's Chair has famously become more and more W shaped--what will it look like as time passes? Will the Southern Cross--the flag of Australia, New Zealand, and several other southern hemisphere countries--remain the same?
Focusing on one small star in Taurus drifting slightly? Really?
Could you carry enough books with you to pass the bar exam?
Assuming you've done even a mediocre job in law school, it'd certainly help you pass the MBE portion of the bar. About 400 flash cards covering principles of common law and UCC2 would make that a breeze, which'd be easy to format into a pretty thin book with very fast reference. Throw in the BARBRI books and the degree of prep needed declines dramatically.
The vast majority of the study time in the couple of months leading up to the bar is rote memorization of a fairly limited set of facts; deeper legal thinking and writing ability are mostly things that you've either got by then through 3 years of school or aren't going to get (though a brush-up can be helpful).
The question is about web browser market share. That's a different number from the total installed OS base, as discussed upthread (a server-centric OS likely does less browsing per installed copy than a desktop-centric one). There are tons of sites and aggregates that show the same ballpark figures.
It's not a matter of English-centrism, either; Germany's certainly considered a Linux stronghold, but most German sites show the same numbers. See, e.g., http://www.webmasterpro.de/portal/webanalyse-systeme.html (which aggregates results from a number of German sites) shows 91.6% Windows, 5.1% Mac, and 1.5% Linux (.2% of which is Android).
There's another comparison chart here:
http://en.wikipedia.org/wiki/Usage_share_of_operating_systems
they have numbers from 12 sources ("All of these sources monitor a substantial number of web sites. Statistics that relate to a single web site are excluded.") and they also have a running average which comes out to 88.9% Windows, 6.2% Mac, and 1.3% Linux (.2% of which is Android).
Pretty much evey major source these days is showing numbers around the same ballpark.
The numbers are for OS, not browser. Lots of people use Firefox, Chrome, etc on Windows.
Linux has a much higher installed base than that, but many of the platforms it's installed on are not desktops or handhelds that do a lot of browsing. If you look at servers, Linux pulls down somewhere from 20-40% according to most surveys. I wouldn't be surprised if the total OS installed base is closer to 10% than to 1% for Linux (as a percentage of all machines).
That figure's not really relevant to the issue at hand, though.
The numbers I posted are for web usage. If a significant number of people are spoofing their clients in non-standard ways, the numbers could be skewed; still, there are lots of different sites that show fairly similar distributions. Note that if someone has both a Linux desktop and a Windows desktop but for some reason uses the Linux desktop exclusively for browsing (or vice-versa) that will be reflected in the stats; that seems reasonable if you're discussing what percentage of the audience you're excluding with single-OS solutions.
http://www.atinternet-institute.com/en-us/internet-users-equipment/operating-systems-april-2010/index-1-2-7-197.html
http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm
http://getclicky.com/marketshare/global/operating-systems/
http://www.webmasterpro.de/portal/webanalyse-systeme.html
The exact numbers vary, but the ballpark seems relatively steady.
Closer to 10%.
Most estimates put Linux at around 1.5% of the web browser market (about 1.2% traditional and 0.3% Android usage), traditional Macs at around 6%, and iPhone/iPad/iTouch around 1%.
Windows (aggregated) is about 89% of the web browser market, with the difference being mostly other handheld/phone devices (Symbian and Blackberry being the next largest blocks after those mentioned).
That's just the straight usage numbers--it establishes an upper bound on your market. If you don't run on Linux/MacOs, you can't get that 8.5% of the market at all. Real-world factors push the exclusion higher (e.g. corporations that mostly run Windows, but only want to support one browser across all desktops and hence are limited to thinking about Firefox, Chrome, Opera, or some other non-IE browser).
Because the alcohol and tobacco lobbies, collectively known as "The partnership for a drug-free America", pay damn good money to buy the lawmakers opinions.
You can criticize the PDFA in a lot of ways, but this isn't one of them in recent years; they don't accept money from tobacco or alcohol companies (they quit allowing that over a decade ago) and they certainly run anti-alcohol campaigns--see, for instance, http://www.drugfree.org/Portal/Drug_Guide/Alcohol
He used "alumium" prior to isolating it. He was pretty consistent in using "aluminum" to refer to the metal after he'd isolated it. See, e.g.:
http://books.google.com/books?id=d6Y5AAAAcAAJ&pg=PA355&hl=en#v=onepage&q&f=false
and subsequent pages.
So come up with a generic term that encompasses both PORT® wine and its imitators, and I'll deal.
That's not how it should work. Just like with trademarks, when a term is already generic (as is the case with champagne and port) then it should be up to the people who want a reserved term to come up with a new one. You can't just go around appropriating commonly used English words.
Miller Lite is a "golden beer" or "light pale lager beer" and not a PILSNER
Miller Lite actually says "True Pilsner Beer" right in the logo, which is fine since "pilsner" is a type of beer in English without regard to the city in Czech.
"Grown in Idaho" is different; it's a sentence with an English meaning that would be a lie if applied to something not grown in Idaho. Similarly, Napa valley champagnes shouldn't be allowed to advertise that they are "From Champagne", just as Vermont cheddar cheese shouldn't be allowed to advertise that it's from Cheddar and Oscar Meyer can't advertise that its wieners are from Wien.
They're there to help the artisan vintners, cheesemakers and other food manufacturers. It's to prevent the giant companies spotting a product is becoming popular and make their own version for half the price (and a quarter the quality) and giving it the same name.
Artisan vintners like Moet Hennessy Louis Vuitton?
Artisan vintners can easily trademark whatever name they're selling under as long as it hasn't already become genericized. This isn't about spotting new products on the rise, it's about redefining words that have already become well-established umbrella terms for certain styles, and it's pure protectionism.
Champagne and port have been in the dictionary as generic terms for centuries. Just from the standpoint of IP law, pulling them out of the public domain where they've safely landed and re-protecting them is even dumber than retroactive copyright extensions--and even worse (IMO) is the attempt to legally redefine words that have widely used English meanings.
well, Port is the name of the city from where Port wine comes from. And the same goes for many of those names. Of course it is wrong to call a wine Port when it doesn't come from where it says!
This is wrong. There is no city named "Port". Strict EU-controlled port comes from all over the Douro region of Portugal.
It's the same as if someone started labelling their products "proudly made in the US" when they weren't, as long it still "felt like a u.s. product" (which is basically your argument).
Do you refuse to eat sandwiches unless they're made in Sandwich, cheddar cheese that's not from Cheddar, or Belgian waffles that aren't from Belgium? Do you get really confused when your Russian or Italian dressing is made in the USA, or your Roman candles and Venetian blinds are made in China?
Are you outraged that most Brazil nuts come from Bolivia and confused about how a salon can offer a French manicure and a Brazilian wax when none of the employees are from France or Brazil?
Port, champagne, parmesan, and many other words that originated as geographic monikers have long since become English words with stylistic (rather than geographic) meanings.
would you be happy if you ordered a scotch and instead got some $9/bottle shit whiskey like fleishmanns
I'd be happier if I ordered Scotch and got Yamazaki (or even Connemara) than Famous Grouse or J&B.
Funny that. When I download software with English, I expect it to default to use words like 'centre', 'colour', 'armour', 'aluminium' et al.
Humphrey Davy, the Englishman who discovered it, named it aluminum. It's not our fault the Brits screwed up the spelling on that one later on.
I'm also disappointed at the ban on the name "port". I rarely drink but when I do it's usually port. Next time I feel like a bottle I won't know what to buy!
This is spot-on. The move to restrict names that originated as place names but have become style descriptors is ridiculous, IMO, and the decisions about what is protected and what isn't are purely political with no regard as to actual genericization.
It makes no sense that "Parmesan", "Sangria", and "Champagne" are geographically restricted but "Cheddar" and "Philadelphia cream cheese" aren't.
Champagne, Switzerland has been producing wine since before Dom Perignon came up with his method of making sparkling wine, but they're not allowed to label it as "Champagne"--that's because everyone knows "Champagne" is a word indicating a particular style, and calling the Swiss (non-sparkling) wine "Champagne" would confuse consumers.
Once you've recognized that, restricting the name by geography is ludicrous.
These laws actually serve to confuse consumers, not to help them--things like "port" are style descriptors in the English language. The right thing to do is to require actual claims of geography to be accurate (already the case) and let Duoro label their port as "Made in Duoro", Jerez label their Sherry as "Made in Jerez", etc.
Why would you set true to 0?
Because any other value would be useless in resolving the question at hand.
The question was what the boolean behavior of the "=" operator was.
By setting true to 0, it's easy to illustrate that it is the final value of foo and not whether foo was successfully set that determines whether the "if" clause is executed.
Setting true to 1 would make the example ambiguous.
Set a to x if you succeeded in setting foo to true?
That's not how boolean evaluation of the = operator works, at least not in standard C.
For instance, this succeeds in setting foo to true but doesn't set a to x:
#include
int main(void)
{
int true = 0;
int foo=-1;
int a=1;
int x=2;
if (foo = true) a=x;
printf("a: %d\n", a);
printf("foo: %d\n", foo);
return 0;
}
Very hard to find a main stream game that isn't written in C++
There are a whole heck of a lot that are written in C, and I suspect that a huge percentage of the engines that survive for a decade or more are written in C rather than C++.
It's very easy to find C programs in general that have been maintained successfully for 10, 20, or more years; it's much harder to find C++ programs with that pedigree, and that seems to have held true in about the same margins over the past 15+ years despite the ratio of C to C++ use for new programs changing significantly. Very complex languages aren't as amenable to long-term project maintenance as simpler ones (which is one of Pike's main points).
1) You can't just add "-wise" to any word an make a new word out of it
"Movie-wise, there has never been anything like [the Apartment] - laugh-wise, love-wise, or otherwise-wise!"
Since without mapping data a project like that cannot exist - it is unlikely there is a truly free alternative (and, as a consequence, not much open source - I suppose because open source developers don't really find a compelling reason to tie to a proprietary data set).
But there are non-proprietary mapping data sets available (e.g. openstreetmap.org)
Definitely. The more options, the better.
This I'm less sure on; clang goes out of its way to support a lot of gccisms (as do other compilers--e.g. the closed-source Intel compiler). It'll help some around the edges, for sure, but a lot of the most common gcc extensions are with us for the foreseeable future even with viable alternative compilers.
I think we're in violent agreement there; my only objection was to positing LLDB as a possible killer feature that prompts mass switching away from GCC.
Sure, but this is where GCC has a huge leg up--as the grey-bearded old project, it already has a ton of back-ends. If I'm working on a new embedded project and I have the choice of using GCC (where writing a back-end is painful, but it's already written) or LLVM (where it's comparatively easy, but needs to be done) I'm going to lean strongly toward GCC.
Now, LLVM's flexibility here means that hopefully it will catch up quickly, and with new platforms could easily garner support faster than GCC. Ultimately, barring a major GCC rearchitecture, ease of back-end development will be a big feather in LLVM's cap. But in the mid-term, the plethora of platforms GCC supports is still a check in its favor.
Debugger speed barely matters for a lot of debugging, though. 85% of the time I run a debugger, gdb takes 1 second to start up and spends most of its time sitting waiting for input from me.
There are niches where a faster debugger matters, and if you're in one of those then it's very, very valuable, but it's hardly the sort of killer feature that's going to put LLVM over the top wrt GCC. There are a _ton_ of other LLVM features that are more important in that battle.