A 128GB log device is almost certainly overkill, unless you have very fast storage. The recommended size for log devices is 10 times the maximum throughput rate of your pool, so unless your pool can write at 12.8GB/s you've just wasted a lot of space. Oh, and putting the ZIL on volatile storage is just asking for data loss. You're better off with a small (8GB is probably ample) SSD for the log device, two in a mirrored configuration if you're paranoid. Oh, and dedup tables use ARC, so 'de-dupe and ARC' is redundant.

Friend and foe are just annotations that give a user-defined bonus or penalty to the score. We don't know what you've set it to, but I think it defaults to -1, so if your settings result in it having a score above your threshold then you'll see it. And nothing says that you have to give positive scores to friends and fans and negative scores to foes and freaks: I set my freaks modifier to +5, because it's always interesting to read what people who strongly disagree with me think.

Even without the incentive not to check for prior art in patents (triple damages for infringement if it can be proven that you knew you were infringing), have you ever read a modern patent? Trying to implement something from a patent is harder than inventing it from scratch. Compare this with patents a hundred years ago, where even with the linguistic drift it's usually possible to work out what they were describing and how it worked.

Nope, most of the long-term studies judge success based on degree and employment. Try again.

Only two factors have consistently been shown to positively correlate with student performance: parental support and teacher enthusiasm. But, hey, throwing technology at the problem might work this time...

We only made the switch to remove gcc from the default install on amd64, i386 and ARMv6. ARM v6 is still compiled with gcc (clang probably should work okay on ARMv4 and ARMv5, but the people still using them tend to be conservative). It's not yet the default on MIPS, but since we're about to release an open source MIPS core at my day job that runs FreeBSD we're working on improving MIPS support. PC98 is i386. It currently does include gcc, because some oddity in its bootloader requires gcc (not sure what). XBox is also i386. PowerPC 32 is still a little way behind (no PIC support, some issues with TLS), but PowerPC64 is now working fine with clang so will make the switch fine. IA64 is basically dead and Oracle seems to be trying to kill SPARC64 as a platform for anything other than Oracle software, so we'll see if they're still around in a few years. There is a SPARC64 back end in LLVM, but it's not well maintained because no one cares.

You might want to look at the list of LLVM developers and see how many work at Sony some time. In particular, the LLVM Linker (lld) is lead by a Sony engineer. Now take a guess at which product group he works in...

Speaking as a member of the FreeBSD Core Team, who contributes code to a GNU project (GNUstep) and has signed an FSF copyright assignment for the purpose, and who was the one to make the disable-gcc-by-default commit, I have to say: What?

With my LLVM dev hat on, please can you point to some analyses that are implemented in GCC and not LLVM? I have some masters' students in need of interesting projects in a few months...

RDRAND is not used directly, it's 'whitened' by Yarrow or a similar algorithm (there are now a few pluggable options, although I'm not sure they made it into 10.0). It's one entropy source, and things like interrupt timings and so on are others. If RDRAND is produces non-deterministic data in a way that are easy for the NSA to predict then there are some possible network attacks involving TCP sequence numbers early on in the boot. After that, there are other entropy sources (e.g. interrupt timings) that make it much harder to predict the inputs to Yarrow (and, unless Yarrow is also broken, you need all of the inputs to be able to predict the output).

Why would you point to the tarball location, when the revision control system is online?

And (at least legally, there may be some exceptions), none of the code in these proprietary products was relicensed. It is built and shipped in accordance with the terms of the license, which permits redistribution in proprietary form as long as you provide attribution, don't sue the original developers if it doesn't work, and don't use their names to advertise your product. The fact that the overall work may have a different license from its components is a different issue. This is why detractors call the GPL 'viral', in that it (more or less) requires any work that contains GPL'd components to be GPL'd.

I'm a clang developer and you're a troll. Clang is faster than GCC on some benchmarks. GCC is faster than clang on others. The new autovectorisation code in Clang is usually faster than GCC, sometimes a lot faster, occasionally slower. Clang doesn't yet have the OpenMP support upstream. In most real-world code you won't see a difference of more than 10% between them, and even then you won't see a consistent winner.

I don't like GCC, and I don't use GCC (except on MIPS, where clang isn't quite ready), but GCC is not 'well behind the curve', it still gives acceptable performance. It was never the fastest player (ICC, XLC and Open64 were all faster), but it's pretty respectable.

I was a clang committer before I joined the FreeBSD project. I became a clang committer because I wanted an Objective-C compiler that supported a modern dialect of the language for non-Apple platforms. I took a look at the Objective-C code in gcc. It mingles parsing, semantic analysis and code generation in a convoluted knot. After a week of failing to understand it, I took at look at clang. At the time, Clang has parsing support for Objective-C, but no code generation support at all. Within a week, having never looked at the Clang codebase before, I had it generating code for a superset of the language that GCC supported.

I've also use clang to do syntax highlighting, to inspect files for type information for use in an FFI for a JIT-compiled language, and as a static analyser. How many tools have you seen that are based on GCC and aren't compilers?

Performance isn't the only metric by which you judge compilers, although I agree that it's an important one. OpenMP support affects a very small number of programs. Intel has just open sourced (BSDL) their OpenMP runtime and is pushing patches into clang, so that support should appear soon. The rest of the benchmarks show very little performance difference between clang 3.3 (which is in FreeBSD 10.0) and gcc 4.8, and neither is a clear winner in all cases. In comparison to the last GPLv2 GCC (4.2.1), which FreeBSD currently ships, both are significantly faster. If you need OpenMP today, gcc 4.8 is in ports, so just install the lang/gcc48 port and use it.

However, as I said, performance is not the only metric. Clang has full support for C++11 and supports more of C11 than GCC (for example, it correctly supports _Atomic and it supports _Generic). In FreeBSD, we're now using _Generic in a number of system headers and so you get better error reporting if your compiler supports them (fallback code exists if it doesn't). We found a few logic bugs in ports as a result of this, some of which have existed on other platforms and compiled without warnings for years. So, if you want to use the latest versions of C, C++, or Objective-C, clang is a better choice for you. We're also now shipping libc++ as the default C++ standard library, so we have a complete C++11 stack.

If you're developing C-family code and don't have a Coverity license, then having the clang static analyser around is also very helpful (it's built into clang, so you get it as part of the default install).