You don't with a pre-pay phone, no. You can buy top-up cards (either with a credit card, in which case the merchant gets your details but not the phone ID, or with cash) and then just provide the number on the back to the phone and get the credit.
Re:Measured from where?
on
GCC Turns 25
·
· Score: 1
Gnu code would be code made by the Gnu project, not just code licensed under the Gnu license. Sorry.
Did you read the link? GNU project code include GRUB (the GNU bootloader), glibc (the GNU C standard library), bash (the GNU shell). If you used any C++ stuff during boot, it includes libstdc++ (the GNU C++ implementation).
As I said, by the time you finish the boot process in a typical Linux distribution and get the system in a state where it can launch programs, you're using more GNU code than Linux.
The iPlayer streaming quality is pretty nice, especially the iPlayer HD stuff. It's 720p at about 3.6Mb/s. It looks better than DVD quality, in spite of being smaller. The SD stuff is not as nice, but it's still better quality than some DVDs I have that come from from poor source material.
Well, not in so many words, but I've had companies respond well to 'I'm sorry, I consider those terms to be unacceptable' or 'I'm afraid I can't sign a contract with that clause in it' before. It takes a round trip via legal to get the new version approved, which can take a little while, but generally any company that I'd be comfortable working for is willing to make reasonable concessions.
I've had several job offers recently[1] and I don't have a Facebook account. Mind you, that might be because I actually talk to people, rather than using a large corporation as a proxy for social interaction.
[1] I actually just accepted one, which I wasn't planning on doing. I'm going to miss being freelance...
What platform are you running that doesn't handle the DRM? I'm on the Finance side of things, so I'm not too knowledgeable about the technical aspects, and I'd be interested in learning more about how your setup is impacted.
I used to use the streaming thing from two machines. My HP TouchPad, which has Flash, and so could stream with the old system. I also have a FreeBSD machine connected to my projector and surround sound system. This could also use Flash (although it was a little bit more effort), and so worked with the old system. Neither of these platforms works with Silverlight.
One of the advantages of a DRM-free implementation built on top of standards is that LoveFilm (or whoever) doesn't have to worry about supporting nonstandard clients - if there is any interest, then users can support it themselves. Another example is MythTV - a few people I know use Myth boxes connected to TVs or projectors for their movie watching, and Silverlight means that they can't use LoveFilm (or Netflix) with their setups either unless they do something like install Windows in a VM (seriously, that's the recommended way of making it work).
Of course, people using these operating systems are minority overall, but they tend to be right in the middle of the early adopter demographic.
I love how on the internet everyone takes a high and mighty moral view on DRM, and finds a ton of faults with anything that might use it, yet pretends like the reason ISN'T because they want to pirate
The DRM that LoveFilm has added to their streaming service means that I can no longer use it with a platform that they don't support. Unfortunately, the computer I have connected to my projector and surround sound system runs one such platform. If I went to the pirate bay or a similar site, I could get a much wider selection and it would all work with my system.
So, as a paying customer, the DRM means that I can't use the streaming part of the service that I'm paying for (and they don't offer a discount for people who only use the DVD rental part). If I were a pirate, the DRM would have no effect on me, because I'd be getting things from a higher quality source than their streaming service anyway (ripped DVDs or BluRays).
In fact, a quick search shows me that there are a lot of ripped BluRays available on torrent sites, so the DRM clearly isn't affecting the pirates at all, yet it is affecting legitimate customers.
The NAS I built has a BluRay burner, which cost about £65. Unfortunately, the CPU is a bit underpowered for decoding BluRay and there's no driver support for the latest Radeons in FreeBSD yet so I can't use it for movies (I got it for backups), but the drive wasn't expensive.
That's already happening. The price of some food commodities was subject to the same deregulation and jumped by a factor of 2-3 over the past decade. This has caused millions to starve, but it's made a lot of Goldman Sachs, so I guess that's okay...
The same way it was before the USA deregulated commodities speculation about 15 years ago. A limited number of speculators were allowed, but mostly the price was determined by supply and demand, i.e. most of the people buying commodities were people who actually needed them, not people who were hoping that they could sell them for a higher price.
Re:And now it's time to bow out gracefully
on
GCC Turns 25
·
· Score: 1
If it's really better then GCC will eventually fall out of development naturally
Eventually can be a long time. For C and C++, there's really not much in it. Clang is nicer to work with as a developer because it provides much better error messages and nicely integrates with your editor of choice (vim, emacs, and eclipse plugins exist) for code completion, but for code generation an end user is unlikely to notice the difference, and even someone running benchmarks is likely to conclude that there's rarely more than 5-10% in it either way.
For Objective-C, there is a massive difference. Clang generates much better code and supports a much newer version of the language. GCC's Objective-C support is positively archaic. It doesn't support (on non-Apple platforms), off the top of my head:
Blocks
Non-fragile instance variables
Instance variable definitions in implementation contexts
Automatic reference counting
New collections syntax
New number-object syntax
And yet people packaging GNUstep for Linux distributions still insist on compiling it with gcc, even though that disables a number of features that can't be correctly implemented with the old version of the language.
Re:And showing every bit of its age too, apparentl
on
GCC Turns 25
·
· Score: 2
Almost certainly. The big problem for compiler writers today is that measuring performance is insanely hard. Things that improve microbenchmarks will often make code slower overall. A simple example is inlining, which can come with some huge benefits. If you inline a function, then you can do more optimisations across the result, and you avoid the cost of the call, but you increase the code size. You run the result, and it's faster, but now it's using 20% of your instruction cache instead of 5%. Fine? Well, now you run it on the same system that's running some other things as well, and now it's getting an instruction cache miss 1% of the time, when previously it would have no cache misses. If your cache miss penalty is 100 cycles, then you're code is now half the speed it was (a 100 cycle penalty every 100 instructions, assuming an average of one instruction per clock, which is pretty pessimistic for a modern CPU) so those optimisations had better have been worth it...
Re:And showing every bit of its age too, apparentl
on
GCC Turns 25
·
· Score: 1
That said, it will only produce PE binaries for those platforms. If you want to produce ELF binaries... good luck.
The FreeBSD project has already declined to upgrade its GCC implementation to the GPL version 3 release.
With my FreeBSD developer hat on:
The reason that we have not upgraded to GCC 4.3 or later is not that we fear GPL contamination of resulting binaries. In fact, we're working on external toolchain support that will allow you to build FreeBSD with the gcc 4.7 from ports if you want. The problem is that FreeBSD ships a complete UNIX system, and the Single UNIX Specification requires a C and C++ compiler. Lots of downstream users want to take FreeBSD and distribute derivatives of it. Many of these have a no-GPLv3-anywhere-in-the-company policy. This is because distributing GPLv3 code may inadvertently license some of your patents. Even if you think abolishing software patents would be a good thing, just licensing yours to everyone while your competitors don't is not a very good strategy...
Two links, one of which is paywalled and the other doesn't support your claim - he's just saying that if you've got code that, for example, depends on GCC's buggy interpretation of C++ template expansion then it may not work with clang and so you need gcc installed too.
And I'm not sure what you mean by Apple propaganda. Apple is one of the companies that uses and contributes to LLVM, but others include Adobe, nVidia, Qualcomm, ARM, MIPS International, AMD, Cray, and a load of universities.
Re:Measured from where?
on
GCC Turns 25
·
· Score: 1
EGCS wasn't a new compiler, it was a fork and refactoring of GCC.
Re:And showing every bit of its age too, apparentl
on
GCC Turns 25
·
· Score: 1
GCC can't support SEH because it's patented (although I think the patent expires next year). Win64 supports a new exception model that isn't patented and is quite similar to the DWARF exceptions used on *NIX platforms (although just different enough to be irritating). Support for it is underway in LLVM, so I'd imagine GCC will support it eventually too.
Re:And showing every bit of its age too, apparentl
on
GCC Turns 25
·
· Score: 1
The depressing thing is that C99 support actually used to be better in the Microsoft compiler. Most of the C99 features that people want are also C++ features. Old versions of the compiler used to compile C as C++ with a few things disabled, so you got a fairly good approximation of C99 (BCPL comments, variables declared anywhere including for loops, inline, although with the Microsoft definition not the C99 definition).
Re:And showing every bit of its age too, apparentl
on
GCC Turns 25
·
· Score: 2
As the other poster pointed out, clang does not support OpenMP. If your code uses OpenMP, then this is a very serious limitation. It means that your code will execute on a single thread with clang, but on multiple concurrent threads with gcc. If your program doesn't make use of OpenMP, then this benchmark is highly misleading.
Oh, and if your code does use OpenMP, the odds are that Path64 will be significantly faster than gcc.
The other poster mentioned blocks. I just did some work on Solaris support in LLVM and clang for a customer for exactly this reason. They wanted to use blocks with libdispatch, because it lets them scale their code up very easily to a lot of cores. GCC doesn't support blocks at all. Clang didn't support Solaris at all. Getting clang, LLVM, and libc++ all working on Solaris was a lot easier than adding blocks support to GCC would have been, so now they're using this stack.
He's talking about the compiler. With GCC, target selection is a compile-time option, so if you want to target (for example) Linux on x86, ARM, and MIPS, you need to compile three different versions of GCC. With clang, you just provide a command-line option to your build and it will generate the code. This is even more important when coupled with something like distcc, which will run the preprocessor on the local machine so you don't need the include files everywhere else, and you can cross compile for any target architecture with a single clang binary connected to distcc on each of your build cluster machines.
Clang's also not nearly as full-featured as GCC. Cross-compiling is a good example
I'd have to disagree there. With clang 3.0, if you want to cross compile, you do -ccc-target-triple {whatever the target triple is} and maybe --sysroot= {wherever you've put the libraries, headers, and maybe ld and as if your host toolchain doesn't support cross compilation}. With gcc, you need to recompile the compiler for each target architecture you want to support.
On most of the platforms GCC supports, it's by far the best compiler available. In some cases, it's the only compiler available. Even if the Clang developers wanted to support such a wide variety of platforms (they don't), it would take years to even approach GCC.
That's certainly true. Adding a new back end to LLVM is easier than adding one to GCC, but GCC has the advantage of starting earlier. For example, I doubt that there will ever be a m68k back end for LLVM. Someone started one, but got bored and never committed it, and no one cares enough to implement one properly. With ARM and MIPS International both contributing to LLVM, however, it does look as if the common platforms are going to be pretty solid.
Even for things like C++11 support, GCC is still ahead
Having worked on a C++11 library implementation, I'd also disagree. Clang and GCC both support different subsets of the language, but they're pretty close.
Care to provide some specifics? Clang can compile the whole GCC base system, as well as itself. A few ports that use gcc-specific features or rely on GCC's buggy C++ template expansion don't work, but pretty much anything C99 or C++98 that we've thrown at it works, along with a lot of C11 and C++11 stuff. In terms of Objective-C support, it's not even worth comparing: Objective-C in gcc is a joke.
Really? Let's look at some fairly recent benchmarks (from a few months ago). Looks like clang wins some, gcc wins some. The only time the difference is more than a few percent either way is in a test that uses OpenMP, which clang doesn't support at all.
My favourite text editor (vim) actually does have a plugin that uses clang for code completion, which works very nicely (semantics-aware code completions in vim!). Of course, since vim is GPLv2 and this license is not GPLv3-compatible, then that would be impossible with gcc...
Slashdot Mirror
You don't with a pre-pay phone, no. You can buy top-up cards (either with a credit card, in which case the merchant gets your details but not the phone ID, or with cash) and then just provide the number on the back to the phone and get the credit.
Gnu code would be code made by the Gnu project, not just code licensed under the Gnu license. Sorry.
Did you read the link? GNU project code include GRUB (the GNU bootloader), glibc (the GNU C standard library), bash (the GNU shell). If you used any C++ stuff during boot, it includes libstdc++ (the GNU C++ implementation).
As I said, by the time you finish the boot process in a typical Linux distribution and get the system in a state where it can launch programs, you're using more GNU code than Linux.
The iPlayer streaming quality is pretty nice, especially the iPlayer HD stuff. It's 720p at about 3.6Mb/s. It looks better than DVD quality, in spite of being smaller. The SD stuff is not as nice, but it's still better quality than some DVDs I have that come from from poor source material.
Well, not in so many words, but I've had companies respond well to 'I'm sorry, I consider those terms to be unacceptable' or 'I'm afraid I can't sign a contract with that clause in it' before. It takes a round trip via legal to get the new version approved, which can take a little while, but generally any company that I'd be comfortable working for is willing to make reasonable concessions.
I've had several job offers recently[1] and I don't have a Facebook account. Mind you, that might be because I actually talk to people, rather than using a large corporation as a proxy for social interaction.
[1] I actually just accepted one, which I wasn't planning on doing. I'm going to miss being freelance...
I didn't realise there were large companies that didn't do this. It seems like common sense.
Expecting common sense from large companies is certainly one way of ensuring that your life is full of surprises...
What platform are you running that doesn't handle the DRM? I'm on the Finance side of things, so I'm not too knowledgeable about the technical aspects, and I'd be interested in learning more about how your setup is impacted.
I used to use the streaming thing from two machines. My HP TouchPad, which has Flash, and so could stream with the old system. I also have a FreeBSD machine connected to my projector and surround sound system. This could also use Flash (although it was a little bit more effort), and so worked with the old system. Neither of these platforms works with Silverlight.
One of the advantages of a DRM-free implementation built on top of standards is that LoveFilm (or whoever) doesn't have to worry about supporting nonstandard clients - if there is any interest, then users can support it themselves. Another example is MythTV - a few people I know use Myth boxes connected to TVs or projectors for their movie watching, and Silverlight means that they can't use LoveFilm (or Netflix) with their setups either unless they do something like install Windows in a VM (seriously, that's the recommended way of making it work).
Of course, people using these operating systems are minority overall, but they tend to be right in the middle of the early adopter demographic.
I love how on the internet everyone takes a high and mighty moral view on DRM, and finds a ton of faults with anything that might use it, yet pretends like the reason ISN'T because they want to pirate
The DRM that LoveFilm has added to their streaming service means that I can no longer use it with a platform that they don't support. Unfortunately, the computer I have connected to my projector and surround sound system runs one such platform. If I went to the pirate bay or a similar site, I could get a much wider selection and it would all work with my system.
So, as a paying customer, the DRM means that I can't use the streaming part of the service that I'm paying for (and they don't offer a discount for people who only use the DVD rental part). If I were a pirate, the DRM would have no effect on me, because I'd be getting things from a higher quality source than their streaming service anyway (ripped DVDs or BluRays).
In fact, a quick search shows me that there are a lot of ripped BluRays available on torrent sites, so the DRM clearly isn't affecting the pirates at all, yet it is affecting legitimate customers.
The NAS I built has a BluRay burner, which cost about £65. Unfortunately, the CPU is a bit underpowered for decoding BluRay and there's no driver support for the latest Radeons in FreeBSD yet so I can't use it for movies (I got it for backups), but the drive wasn't expensive.
That's already happening. The price of some food commodities was subject to the same deregulation and jumped by a factor of 2-3 over the past decade. This has caused millions to starve, but it's made a lot of Goldman Sachs, so I guess that's okay...
The same way it was before the USA deregulated commodities speculation about 15 years ago. A limited number of speculators were allowed, but mostly the price was determined by supply and demand, i.e. most of the people buying commodities were people who actually needed them, not people who were hoping that they could sell them for a higher price.
If it's really better then GCC will eventually fall out of development naturally
Eventually can be a long time. For C and C++, there's really not much in it. Clang is nicer to work with as a developer because it provides much better error messages and nicely integrates with your editor of choice (vim, emacs, and eclipse plugins exist) for code completion, but for code generation an end user is unlikely to notice the difference, and even someone running benchmarks is likely to conclude that there's rarely more than 5-10% in it either way.
For Objective-C, there is a massive difference. Clang generates much better code and supports a much newer version of the language. GCC's Objective-C support is positively archaic. It doesn't support (on non-Apple platforms), off the top of my head:
And yet people packaging GNUstep for Linux distributions still insist on compiling it with gcc, even though that disables a number of features that can't be correctly implemented with the old version of the language.
Almost certainly. The big problem for compiler writers today is that measuring performance is insanely hard. Things that improve microbenchmarks will often make code slower overall. A simple example is inlining, which can come with some huge benefits. If you inline a function, then you can do more optimisations across the result, and you avoid the cost of the call, but you increase the code size. You run the result, and it's faster, but now it's using 20% of your instruction cache instead of 5%. Fine? Well, now you run it on the same system that's running some other things as well, and now it's getting an instruction cache miss 1% of the time, when previously it would have no cache misses. If your cache miss penalty is 100 cycles, then you're code is now half the speed it was (a 100 cycle penalty every 100 instructions, assuming an average of one instruction per clock, which is pretty pessimistic for a modern CPU) so those optimisations had better have been worth it...
That said, it will only produce PE binaries for those platforms. If you want to produce ELF binaries... good luck.
The FreeBSD project has already declined to upgrade its GCC implementation to the GPL version 3 release.
With my FreeBSD developer hat on:
The reason that we have not upgraded to GCC 4.3 or later is not that we fear GPL contamination of resulting binaries. In fact, we're working on external toolchain support that will allow you to build FreeBSD with the gcc 4.7 from ports if you want. The problem is that FreeBSD ships a complete UNIX system, and the Single UNIX Specification requires a C and C++ compiler. Lots of downstream users want to take FreeBSD and distribute derivatives of it. Many of these have a no-GPLv3-anywhere-in-the-company policy. This is because distributing GPLv3 code may inadvertently license some of your patents. Even if you think abolishing software patents would be a good thing, just licensing yours to everyone while your competitors don't is not a very good strategy...
Two links, one of which is paywalled and the other doesn't support your claim - he's just saying that if you've got code that, for example, depends on GCC's buggy interpretation of C++ template expansion then it may not work with clang and so you need gcc installed too.
And I'm not sure what you mean by Apple propaganda. Apple is one of the companies that uses and contributes to LLVM, but others include Adobe, nVidia, Qualcomm, ARM, MIPS International, AMD, Cray, and a load of universities.
EGCS wasn't a new compiler, it was a fork and refactoring of GCC.
GCC can't support SEH because it's patented (although I think the patent expires next year). Win64 supports a new exception model that isn't patented and is quite similar to the DWARF exceptions used on *NIX platforms (although just different enough to be irritating). Support for it is underway in LLVM, so I'd imagine GCC will support it eventually too.
The depressing thing is that C99 support actually used to be better in the Microsoft compiler. Most of the C99 features that people want are also C++ features. Old versions of the compiler used to compile C as C++ with a few things disabled, so you got a fairly good approximation of C99 (BCPL comments, variables declared anywhere including for loops, inline, although with the Microsoft definition not the C99 definition).
As the other poster pointed out, clang does not support OpenMP. If your code uses OpenMP, then this is a very serious limitation. It means that your code will execute on a single thread with clang, but on multiple concurrent threads with gcc. If your program doesn't make use of OpenMP, then this benchmark is highly misleading.
Oh, and if your code does use OpenMP, the odds are that Path64 will be significantly faster than gcc.
The other poster mentioned blocks. I just did some work on Solaris support in LLVM and clang for a customer for exactly this reason. They wanted to use blocks with libdispatch, because it lets them scale their code up very easily to a lot of cores. GCC doesn't support blocks at all. Clang didn't support Solaris at all. Getting clang, LLVM, and libc++ all working on Solaris was a lot easier than adding blocks support to GCC would have been, so now they're using this stack.
He's talking about the compiler. With GCC, target selection is a compile-time option, so if you want to target (for example) Linux on x86, ARM, and MIPS, you need to compile three different versions of GCC. With clang, you just provide a command-line option to your build and it will generate the code. This is even more important when coupled with something like distcc, which will run the preprocessor on the local machine so you don't need the include files everywhere else, and you can cross compile for any target architecture with a single clang binary connected to distcc on each of your build cluster machines.
Clang's also not nearly as full-featured as GCC. Cross-compiling is a good example
I'd have to disagree there. With clang 3.0, if you want to cross compile, you do -ccc-target-triple {whatever the target triple is} and maybe --sysroot= {wherever you've put the libraries, headers, and maybe ld and as if your host toolchain doesn't support cross compilation}. With gcc, you need to recompile the compiler for each target architecture you want to support.
On most of the platforms GCC supports, it's by far the best compiler available. In some cases, it's the only compiler available. Even if the Clang developers wanted to support such a wide variety of platforms (they don't), it would take years to even approach GCC.
That's certainly true. Adding a new back end to LLVM is easier than adding one to GCC, but GCC has the advantage of starting earlier. For example, I doubt that there will ever be a m68k back end for LLVM. Someone started one, but got bored and never committed it, and no one cares enough to implement one properly. With ARM and MIPS International both contributing to LLVM, however, it does look as if the common platforms are going to be pretty solid.
Even for things like C++11 support, GCC is still ahead
Having worked on a C++11 library implementation, I'd also disagree. Clang and GCC both support different subsets of the language, but they're pretty close.
Care to provide some specifics? Clang can compile the whole GCC base system, as well as itself. A few ports that use gcc-specific features or rely on GCC's buggy C++ template expansion don't work, but pretty much anything C99 or C++98 that we've thrown at it works, along with a lot of C11 and C++11 stuff. In terms of Objective-C support, it's not even worth comparing: Objective-C in gcc is a joke.
clang never beat GCC.
Really? Let's look at some fairly recent benchmarks (from a few months ago). Looks like clang wins some, gcc wins some. The only time the difference is more than a few percent either way is in a test that uses OpenMP, which clang doesn't support at all.
My favourite text editor (vim) actually does have a plugin that uses clang for code completion, which works very nicely (semantics-aware code completions in vim!). Of course, since vim is GPLv2 and this license is not GPLv3-compatible, then that would be impossible with gcc...