Reading that wikipedia page, it's pretty clear that whoever wrote it has never been involved in military research, to the extent that they haven't even read most of the published work from the last 30 years. A few salient facts:
A nuclear EMP may be something like 0.1% of the energy yield of the bomb, but that 0.1% is the total EMP output, not the amount that will actually interact with electronics. The amount on the correct frequency for any given target is typically under 0.01% of that 0.1%, so you can use far less energy if you are wishing to limit your target.
EMPs are subject to the inverse square law. If you are using an airburst then you've already lost a lot of the power before you get close to the ground. Something with a 100m range detonated half way up a tower in the City of London would require far less power for the same effect.
Much of the effect of the pulse is related to the time in which it is delivered. If you generate the pulse faster, then you can use far less energy for the same effect. This has gone from being unfeasible to being trivial in the last few decades.
Pulses can be directional, when generated from other sources, and a simple sweep around a cone can deliver the equivalent of a spherical EMP but without the need to draw / deliver all of the power at once. Spread over a few seconds or even a minute, the load is quite different.
A typical school physics lab has the equipment required to build an EMP device with a relatively short range that can be powered from the mains. An EMP device is basically a radio transmitter, and we've known how to build those for a long time.
$100/hour? Maybe in the USA, but I know a very competent 3D artist who lives in Thailand and makes about $2/hour. The cost of getting a photographer on site, and then a day of his time will easily cost more than a month of his time. That's the point of TFA - a photographer in the USA isn't competing with 3D artists in his home town, he's competing with 3D artists in the whole world.
It's happening slowly, but on a per-field basis. JOT is a good example of this. It took over when JOOP was killed by the publisher, and began with largely the same editorial team and set of reviewers. The only difference in the transition was that all papers went online and there were no printed proceedings. I've just been working with another conference that is now going to be publishing its own proceedings rather than going through an existing publisher, using a print-on-demand service for the hard copies and just hosting the electronic versions on a university web server.
That's because Facebook's T&Cs explicitly say that they are going to take anything you upload and sell it to anyone who wants to buy it. Every single Facebook user has clicked on something saying that they have read and agree to these terms. If they didn't actually read it before agreeing, that's not Facebook's problem.
A whistleblower from DHS recently reported that there is a plan afoot by the Obama regime to pull a "Reichstag Event", which would allow him to declare martial law, postponing (or cancelling) the election
That's very interesting, because I recall exactly the same thing was going to happen at the end of George W Bush's presidency yet, oddly, didn't.
What's the prospect for Clang gaining in-tree support for OpenMP?
Last week, someone posted a set of patches that added OpenMP support to clang 2.9 and relicensed them under the UIUC license so that they can be included in clang once they've been brought up to date. So far, no one has done this, but if there is sufficient interest someone probably will.
Also for clang and fortran?
Clang is a front end for C-family languages. Fortran is not a C-family language. It will therefore not ever be supported by clang. Apparently some people are working on a Fortran front end for LLVM, but since I have no Fortran code I have not really been following their progress.
If you're interested, take a look at the talk by Hal Finkel at EuroLLVM a couple of weeks ago. I believe there are actually three vectorisers in progress for LLVM, but the one Hal works on is particularly interesting because it approaches the problem with a very general solution, while the GCC version just transforms hard-coded patterns. I'm not sure if this code made it into trunk just before or just after 3.1 was branched, but I believe the plan for 3.2 is to have it along with a pattern-matching approach, which should autovectorise a superset of the cases GCC handled (which isn't really anything to brag about - I can think of four C/C++ compilers off the top of my head that do a better job than GCC at this).
Oh, the other nice thing about this stuff in LLVM is that it's target-independent. LLVM supports arbitrary-sized vectors in the IR, along with a fairly rich set of operations, and target back ends just map these to real instructions. Once autovectorisation is done once, it can be used with AltiVec, SSE, NEON, and so on with some very minor tweaks (basically just adjusting some heuristics that decide when it's worth bothering with).
It's also worth noting that clang defines __GNUC__ (it is a drop-in replacement for GCC 4.2), so the #elif would not be reached even with correct syntax. Oh, and the return 0 is only implicit in C99 or later, or C++.
A lot of people avoided BSD in the early '90s for exactly this reason. It delayed the i386 port for long enough that Linux started to gain traction. It's not a problem I've seen in the last 10 years though.
At -O2 and -O3, clang and gcc are within 10% for the vast majority of code, with no overall winner. There are a few corner cases, however:
The autovectorisation support in LLVM is a very elegant design, but is very new code and so still performs worse than GCC in a lot of cases (about 70% of the autovectorisation test suite is faster with GCC).
Clang has no in-tree support for OpenMP, so anything using OpenMP (vaguely competently) will be faster with gcc because clang will fall back to the single-threaded version.
GCC's Objective-C support is just embarrassing, and (on non-Apple platforms) performance can be an order of magnitude better with clang, with a 20-50% speedup being pretty common.
I think it is more likely that they are worried about the patent grant implications of GPL 3.
There are two things in the GPL that make companies nervous. One is the patent grant, the other is the revocation clause. It is possible to discover that the product that you are selling 100,000 instances of a month violates the GPL, and have your license instantly revoked. Getting the license granted again requires explicit interaction with the copyright holder (just getting into compliance does not make the license valid again), so if you can't get hold of every copyright holder then you have to stop distributing your product or face massive liabilities.
It executes either gcc or clang as the compiler, it executes clang as the static analyser. The scan-build script is something that interposes a fake compiler script into your existing build system and allows you to run the analyser as a side effect of the build.
There are companies shipping FreeBSD-based products using MIPS, ARM, and PowerPC, as well as x86[-64]. ARM support in LLVM is good (ARM and Apple both work on it). MIPS support is mostly there if you use an external assembler, but the integrated assembler is broken - some MIPS people are working on it. PowerPC just has three guys working on it, but everything except some thread-local storage models and position-independet code on 32-bit work. We're probably going to flip the switch for x86[-64] to default to compiling the base system with clang this week (I meant to do it yesterday, but I was only near my computer at the same time as I was near beer, and thought that this was a commit that should be done sober). For other architectures, it may take a little bit longer.
I'm just on my way back from BSDCan and the FreeBSD DevSummit. At the DevSummit, there was a Vendor Summit, for companies that use FreeBSD in their products. Not all were there (Sony, for example, was absent), but companies like Fusion IO, Yahoo, IX Systems, Juniper, Apple, and so on all sent people. There were about 40 companies represented in total, for a developer meeting with about 70 attendees.
Have you read the GPLv3? It is a long and complex legal document. Are you certain that nothing that you are doing violates it? Want to bet your business on it?
In a couple of years time, there will be a proliferation of different, incompatible versions of CLang/LLVM that will be increasingly expensive to maintain.
It's already happened. This is why so many companies are now actively involved in the LLVM community: it's cheaper. I'm currently on my way back from BSDCan (where I was talking a bit about the progress in switching to clang) and I was at EuroLLVM a couple of weeks earlier. Both conferences were full of corporate contributors to LLVM and FreeBSD (two projects that I work on). They like the fact that the license means that they don't need to run everything that they possibly want to do past their legal team and, over the past decade, they've all discovered (at different speeds) that it's much cheaper to engage the community and push work upstream than it is to maintain a private fork.
You get much better support from companies that join your community because they regard it as being good for them than if they dump code on you because they are legally obliged to. We don't want drive-by code dumps, we want long-term commitments to maintenance.
If Bitcoin were a pump and dump don't you think it would have disappeared after the initial bubble?
Nope. I tracked a few stocks that I got spam about for a while. The scammers used the same things a few times. They pumped, dumped, sold, and then once the price collapsed they bought and repeated.
It's worse. They did some really stupid things in the new version. Consider the following code:
id a = @42; id b = @"42";
The first of these, every time this scope is entered, creates a new autoreleased NSNumber instance. The second creates a statically allocated instance. The syntax for 'static' (meaning a new autoreleased instance is allocated whenever it goes into scope) collections has no support for creating mutable instances, making it useless in at least half of the cases where we've wanted it.
Why? Anyone can look at that line and understand exactly what it does without any knowledge of the APIs (although those of us that are familiar with them will suspect that you probably meant +whitespaceAndNewlineCharacterSet). It's more to type, but given that even vim with the clang plugin can autocomplete from a couple of characters that's not really an issue. Most code spends a lot more time being read than being written, and Objective-C is very easy to read.
XCode 3 was. XCode 4 improved a lot of things on the back end (e.g. using libclang instead of some hacky stuff), but the number of UI regressions is quite amazing.
I'm working on a few aspects of the toolchain. It looks like we're going to turn on building the base system with clang by default Real Soon Now but still leave GCC in for ports until there is slightly better infrastructure available for selecting the compiler that various ports need. And fixing some ports that don't compile with clang. Many of these are for stupid reasons. I fixed binutils last night (which was blocking 561 other ports), where gold did some blatantly-not-valid-C++ things that clang rejected (moving a single brace down a bit made it valid). The gcc 4.2 port is still problematic because clang defaults to c99 mode and it will only build in c89 mode. Even if you specify -std=c89 to configure, it only bothers to pass this flag to some of the build. I have a clang patch that ensures that it defaults to c89 mode when invoked as c89, so hopefully that can be fixed soon too, simply by compiling it with c89, rather than cc / gcc / clang / whatever.
Well, speaking for FreeBSD, we use Clang/LLVM and are in the process of removing GCC. We're hoping to flip the switch to defaulting to Clang this weekend. OpenBSD is in the process of switching to PCC. NetBSD supports multiple compilers.
And who wrote that initially?
Chris Lattner and others at the UIUC.
Who wrote a number of utilities that went along with it?
Various people, including myself.
Who wrote the GPL?
Some guy who insists that the best way of getting companies involved in the community is to refuse to meet them half way so that they go and write their own proprietary versions of tools instead of contributing to open ones.
Slashdot Mirror
A typical school physics lab has the equipment required to build an EMP device with a relatively short range that can be powered from the mains. An EMP device is basically a radio transmitter, and we've known how to build those for a long time.
$100/hour? Maybe in the USA, but I know a very competent 3D artist who lives in Thailand and makes about $2/hour. The cost of getting a photographer on site, and then a day of his time will easily cost more than a month of his time. That's the point of TFA - a photographer in the USA isn't competing with 3D artists in his home town, he's competing with 3D artists in the whole world.
It's happening slowly, but on a per-field basis. JOT is a good example of this. It took over when JOOP was killed by the publisher, and began with largely the same editorial team and set of reviewers. The only difference in the transition was that all papers went online and there were no printed proceedings. I've just been working with another conference that is now going to be publishing its own proceedings rather than going through an existing publisher, using a print-on-demand service for the hard copies and just hosting the electronic versions on a university web server.
That's because Facebook's T&Cs explicitly say that they are going to take anything you upload and sell it to anyone who wants to buy it. Every single Facebook user has clicked on something saying that they have read and agree to these terms. If they didn't actually read it before agreeing, that's not Facebook's problem.
A whistleblower from DHS recently reported that there is a plan afoot by the Obama regime to pull a "Reichstag Event", which would allow him to declare martial law, postponing (or cancelling) the election
That's very interesting, because I recall exactly the same thing was going to happen at the end of George W Bush's presidency yet, oddly, didn't.
What's the prospect for Clang gaining in-tree support for OpenMP?
Last week, someone posted a set of patches that added OpenMP support to clang 2.9 and relicensed them under the UIUC license so that they can be included in clang once they've been brought up to date. So far, no one has done this, but if there is sufficient interest someone probably will.
Also for clang and fortran?
Clang is a front end for C-family languages. Fortran is not a C-family language. It will therefore not ever be supported by clang. Apparently some people are working on a Fortran front end for LLVM, but since I have no Fortran code I have not really been following their progress.
If you're interested, take a look at the talk by Hal Finkel at EuroLLVM a couple of weeks ago. I believe there are actually three vectorisers in progress for LLVM, but the one Hal works on is particularly interesting because it approaches the problem with a very general solution, while the GCC version just transforms hard-coded patterns. I'm not sure if this code made it into trunk just before or just after 3.1 was branched, but I believe the plan for 3.2 is to have it along with a pattern-matching approach, which should autovectorise a superset of the cases GCC handled (which isn't really anything to brag about - I can think of four C/C++ compilers off the top of my head that do a better job than GCC at this).
Oh, the other nice thing about this stuff in LLVM is that it's target-independent. LLVM supports arbitrary-sized vectors in the IR, along with a fairly rich set of operations, and target back ends just map these to real instructions. Once autovectorisation is done once, it can be used with AltiVec, SSE, NEON, and so on with some very minor tweaks (basically just adjusting some heuristics that decide when it's worth bothering with).
It's also worth noting that clang defines __GNUC__ (it is a drop-in replacement for GCC 4.2), so the #elif would not be reached even with correct syntax. Oh, and the return 0 is only implicit in C99 or later, or C++.
A lot of people avoided BSD in the early '90s for exactly this reason. It delayed the i386 port for long enough that Linux started to gain traction. It's not a problem I've seen in the last 10 years though.
So how do you use GCC for syntax highlighting in your non-shit IDE?
I think it is more likely that they are worried about the patent grant implications of GPL 3.
There are two things in the GPL that make companies nervous. One is the patent grant, the other is the revocation clause. It is possible to discover that the product that you are selling 100,000 instances of a month violates the GPL, and have your license instantly revoked. Getting the license granted again requires explicit interaction with the copyright holder (just getting into compliance does not make the license valid again), so if you can't get hold of every copyright holder then you have to stop distributing your product or face massive liabilities.
It executes either gcc or clang as the compiler, it executes clang as the static analyser. The scan-build script is something that interposes a fake compiler script into your existing build system and allows you to run the analyser as a side effect of the build.
Do they? Because at the BSD DevSummit last week there were a lot of guys who work at big companies, and all of them are contributing code...
There are companies shipping FreeBSD-based products using MIPS, ARM, and PowerPC, as well as x86[-64]. ARM support in LLVM is good (ARM and Apple both work on it). MIPS support is mostly there if you use an external assembler, but the integrated assembler is broken - some MIPS people are working on it. PowerPC just has three guys working on it, but everything except some thread-local storage models and position-independet code on 32-bit work. We're probably going to flip the switch for x86[-64] to default to compiling the base system with clang this week (I meant to do it yesterday, but I was only near my computer at the same time as I was near beer, and thought that this was a commit that should be done sober). For other architectures, it may take a little bit longer.
I'm just on my way back from BSDCan and the FreeBSD DevSummit. At the DevSummit, there was a Vendor Summit, for companies that use FreeBSD in their products. Not all were there (Sony, for example, was absent), but companies like Fusion IO, Yahoo, IX Systems, Juniper, Apple, and so on all sent people. There were about 40 companies represented in total, for a developer meeting with about 70 attendees.
Have you read the GPLv3? It is a long and complex legal document. Are you certain that nothing that you are doing violates it? Want to bet your business on it?
In a couple of years time, there will be a proliferation of different, incompatible versions of CLang/LLVM that will be increasingly expensive to maintain.
It's already happened. This is why so many companies are now actively involved in the LLVM community: it's cheaper. I'm currently on my way back from BSDCan (where I was talking a bit about the progress in switching to clang) and I was at EuroLLVM a couple of weeks earlier. Both conferences were full of corporate contributors to LLVM and FreeBSD (two projects that I work on). They like the fact that the license means that they don't need to run everything that they possibly want to do past their legal team and, over the past decade, they've all discovered (at different speeds) that it's much cheaper to engage the community and push work upstream than it is to maintain a private fork.
You get much better support from companies that join your community because they regard it as being good for them than if they dump code on you because they are legally obliged to. We don't want drive-by code dumps, we want long-term commitments to maintenance.
If Bitcoin were a pump and dump don't you think it would have disappeared after the initial bubble?
Nope. I tracked a few stocks that I got spam about for a while. The scammers used the same things a few times. They pumped, dumped, sold, and then once the price collapsed they bought and repeated.
The first of these, every time this scope is entered, creates a new autoreleased NSNumber instance. The second creates a statically allocated instance. The syntax for 'static' (meaning a new autoreleased instance is allocated whenever it goes into scope) collections has no support for creating mutable instances, making it useless in at least half of the cases where we've wanted it.
Why? Anyone can look at that line and understand exactly what it does without any knowledge of the APIs (although those of us that are familiar with them will suspect that you probably meant +whitespaceAndNewlineCharacterSet). It's more to type, but given that even vim with the clang plugin can autocomplete from a couple of characters that's not really an issue. Most code spends a lot more time being read than being written, and Objective-C is very easy to read.
XCode 3 was. XCode 4 improved a lot of things on the back end (e.g. using libclang instead of some hacky stuff), but the number of UI regressions is quite amazing.
I'm working on a few aspects of the toolchain. It looks like we're going to turn on building the base system with clang by default Real Soon Now but still leave GCC in for ports until there is slightly better infrastructure available for selecting the compiler that various ports need. And fixing some ports that don't compile with clang. Many of these are for stupid reasons. I fixed binutils last night (which was blocking 561 other ports), where gold did some blatantly-not-valid-C++ things that clang rejected (moving a single brace down a bit made it valid). The gcc 4.2 port is still problematic because clang defaults to c99 mode and it will only build in c89 mode. Even if you specify -std=c89 to configure, it only bothers to pass this flag to some of the build. I have a clang patch that ensures that it defaults to c89 mode when invoked as c89, so hopefully that can be fixed soon too, simply by compiling it with c89, rather than cc / gcc / clang / whatever.
Which compiler does BSD use for everything?
Well, speaking for FreeBSD, we use Clang/LLVM and are in the process of removing GCC. We're hoping to flip the switch to defaulting to Clang this weekend. OpenBSD is in the process of switching to PCC. NetBSD supports multiple compilers.
And who wrote that initially?
Chris Lattner and others at the UIUC.
Who wrote a number of utilities that went along with it?
Various people, including myself.
Who wrote the GPL?
Some guy who insists that the best way of getting companies involved in the community is to refuse to meet them half way so that they go and write their own proprietary versions of tools instead of contributing to open ones.