Of course they are sharing the raw data. But understanding the raw data means understanding a great deal about the physical structure of the detector. Basically, if you know enough about that, you are part of the CERN team, whether you are physically there or not. Relatively few of the thousands of scientists working "at" CERN are physically there at any time: most spend most of their time connected only electronically. Why do you think the WWW was invented there?
Because the greater energy of CERN is like shining a brighter light even at the lower energies where CERN overlaps with earlier accelerators. It is like a searchlight coming on after people have been searching with a hand torch: the searchlight will show ups instantly things which the hand torch would have taken a long time to find. CERN is going to start with a half power run-up, but even at that power is should easily see everything that others have struggled to see. Indeed, I would expect them to do that routinely as a method of validating the machine's operation: they should be able to "see" all the known particles at their appropriate energies, and they may well be able to refine the values for those energies.
You need to distinguish between sectors reallocated at manufacturing time, which are relatively benign, and those auto-replaced later. For the latter, I would mostly agree with you. One or two reallocations don't seem to be a problem, but as many as five have usually shown a drive on its last legs.
One drive I studied had a policy of one spare sector per track plus one spare track per cylinder (this was a while back, when disks often had five platters). Which meant that performance fell sharply as the number of faults passed one per track.
In a disk,the tracks have a physical size, and the heads don't always get to exactly the same position when they re-write the track. So if you write a data track, then overwrite it, the overwrite may be slightly to the left or right of the original, and a little bit of the original is not overwritten. If you then deliberately command the read to a small fraction out, you may get enough signal to pick up the deleted data.
To actually overwrite the data, I would guess you have to have one overwrite slightly to the left of the original write, and one slightly to the right. But since you cannot predict what is going to happen, because it is dues to minute and unrepeatable mechanical effects, you need to overwrite it multiple times using different patterns of seeks to get to the track.
I don't think you know what a "Gravity Tractor" is. It is about 20 tons (min) of rock. We have that. It is put close to the asteroid in the direction we want to pull it, and good ol' Newtonian gravity is allowed exert traction (mMG/d^2). Then thrusters on the lump of rock thrust to get rid of the "equal and opposite" reaction pulling the lump onto the asteroid. So, like the classic donkey with a carrot on a string, the asteroid is gently lead away from the collision with earth.
This is *much* safer than nukes, and *much* lower technology. We can do. No. For mere money.
The asteroid is almost certainly spinning to some extent, and not about an axis that you wnat to push on. For a "one big thump" impact that doesn't matter, but for a steady push you would have to kill the rotation, which would probably take much more energy. The gravity tractor hangs just out of the reach of any flailing "mountains" and pulls in a constant direction.
Th falling apart problem probably wouldn't matter for the tiny impulse suggested, but would for the "one bigh thump", whose consequences would be extremely unpredictable. By contrast, the gravity tractor is pretty precise to start with, and the longer it runs the better we know the asteroids mass and the prciser it becomes.
This is not new news - I first heard it about a year ago. But the idea is getting critical oversight, and standing up to it, which is promising. But basically, when I heard this idea, I stopped panicing about asteroids. If we get three years warning, we can fix it. It may take Apollo-scale expenditure, but it can be done. Actually, my estimate would be lower - range $10-40 billion. Which has to be a hell of a sight better cost/benefit ration than the Iraq war.
I didn't mod the comment "Troll", and I don't consider it so. You cannot moderate and comment in the same thread - when you comment, your mods are cancelled.
As for burying it, how else in Europe are you going to build something 27 km across and dead level, with mounting points for thousands of tons of equipment? It is not below a mountain, it is below farmland. Anywhere reasonably flat in Europe is covered with towns and villages and criss-crossed with roads. And the flatness requirement is *exact*, so if the ground is only fairly flat, you will have to have bits in tunnels and/or on stilts anyway. On stilts is bad for carrying heavy loads. And you don't want your hypersensitive particle detectors triggered by cosmic radiation, so they will have to be heavily shielded anyway. Since the equipment needs to be well protected from accidents and weather for purely engineering reasons (big magnets, huge currents, super-cooling, vacuum). I could see problems with those magnets distorting every CRT-based television for hundreds of yards. The reason for burying it is purely for experimental purposes rather than safety. It is re-using the tunnel dug for an earlier detector, decommissioned a few years ago.
Which is rather like worrying about recreating the conditions of the Dresden Firestorm when you light a match. The conditions created by this experiment are created many times a day when high energy cosmic rays hit the Earth. Unfortunately, they are not created in the middle of a multi-thousand-ton detector. The fears expressed are complete FUD.
It is a Pretty Big Thing to cool to 1.4C. Also it is a nice pun in the idea that the LHC is Kewl. Any excuse is a good excuse to publish a reasonably accurate and informative article about Big Science doing what it is meant to do. In a news stream full of doom and disaster, the LHC coming on line is a rare example of something that is both Good and News.
TFA has one of the few times when the adjective "cataclysmic" can be used with out accusations of hyperbole. If the Big bang isn't cataclysmic, it is difficult to see what is.
As I (and IANAL) understand it, no. Either someone who loans/gives money to the litigant, or someone who obtains a significant (but not necessarily controlling) interest in the litigant, if the effect is as described, can be regarded as a party to the case and thus civilly liable for the legal costs. Of course, there is a burden of proof: the backers could claim that they were buying into SCO's normal operations and not, intentionally, into the lawsuit. The burden of proof of this would be on the complainant wanting to reclaim costs. But I think that in this case, it would be reasonable to state that the lawsuit was SCO's principal asset, and anybody funding SCO either by debt or equity was making themselves a party to the lawsuit. (Of course, someone such as Microsoft, who funded them by making unusual purchases, would not be liable: you can hardly be expected to be liable for your supplier's lawsuits).
Of course, it would take the lawyers to decide, and I certainly claim no knowledge at all of US law. The situation came up when the company I worked for won a case against the another, whose owners had tried to isolate themselves from loss by sucking that company dry. The costs were ruled to be due from the owners: despite being a separate company, they had supported the subsidiary through the suit and were therefore liable for the costs. But this is anecdotal, from talking to the managers who talked to the lawyers.
Under UK law (and I realise that this is a US case), the claim for legal fees could be pursued back to SCO's backers. There is a concept of "constructive support". If A gives B a pile of money to legally harass C, and the court finds that B's claim is substantially without value (which seems to be the case here) and awards costs against B to C, then C can chase A for those costs if B cannot pay. There is an obvious reason for this: you should not be able use the law as weapon against others with a fall-guy in the middle to protect you from the consequences. It seems to me that US law should have some equivalent provision, which would allow Novell to go against SCO's financiers for those legal costs.
That might be overkill - putting the CEO of a major bank in prison could cause an collapse leading to a depression.
If the bank is that fragile it's doomed anyway. He could also get hit by a bus.
Getting hit by a bus does not imply criminality. It is the implication that the organisation has had a crook at its head which does the harm, not the departure of any single individual. Bankers work very hard to look respectable, hence the marble foyers and double breasted suits (not both worn at the same time).
Putting the CEO of the government into prison would cause major political upheavals would have massive knock-on effects, dependant upon political system.
It's about the smartest thing we could do in the USA, but we'd have to put the whole fucking cabinet in there with him.
That might be overkill - putting the CEO of a major bank in prison could cause an collapse leading to a depression. Putting the CEO of the government into prison would cause major political upheavals would have massive knock-on effects, dependant upon political system.
Most of the recent data losses in the UK have involved government data. One was for the agency paying support to poor families - they *need* that money and cannot go elsewhere. Another was the Army recruitment department: if you want to join the Army, there isn't another one you can choose because this one had poor data security.
It tells us that there are no benefits on a single core, or using threading models fundamentally designed for single cores and then bodged for small numbers of cores. Until all the randomly ordered lines can be executed simultaneously by multiple cores, such randomisation is all pain, no gain. (Except that top-end CPUS do that internally on a very fine grain with look-ahead execution etc.)
You also need to make mahomet come to the mountain. The current model is that the mountain (data) comes to mahomet (the processor, the active unit). If you have many cores, you put them "near" different address spaces, and the threads execute on a core "near" the data. If one area of memory gets overcrowded, the data migrates to a cooler area with more free cores. It may sound odd to bulk move the data, but if you are using small enough atoms, there will be fewer mcycles involved in a block copy that in accessing it many times over for processing.
No, it shows that there are no CPUs and accompanying execution environments capable of exploiting such techniques. It only becomes worthwhile when there are many cores capable of executing the randomly sorted code. Doing it on a single core, or any system with current inter-process communications models, would just introduce complexity for no gain.
The majority of code written in current programming languages does not parallelise well, because sequential execution is built into the structure of the language. The default operation is to execute instructions in sequence. But if the default were to execute all the commands in a block in parallel, unless instructed otherwise, there would be a lot more parallelism. And once people got used to this parallel thinking, they would design in more parallelism.
So you have to split the problem into an enormous number of pieces - much larger than the number of cores. Then you don't communicate explicitly, you just have a task queue. Each core does one micro-task, generating zero or more new microtasks which added to the task queue. In principle, after each task the core takes the next off the queue, but you might use the equivalent of tail-recursion: run the last-generated microtask, if any.
But such a system could never be written in C or other pure imperative languages. You need Functional Programming, or some other new paradigm, in which the order of execution is divorced from program layout. Which is what the Intel bods are talking about.
Well, for one possibility, quality voice recognition. Dozens of cores each parsing the sound stream to test a different hypothesis of what you said, using both phonic and semantic analysis. Somewehat similar to the way the brain works. And results wanted in real time.
But what they are saying is they have evidence rather than an idea. Not awfully strong evidence, buyt it adds weight to the idea, which was previously just hot air - interesting, but still hot mair.
I buy my hardware from dabs.com. Cheap, fast, good refund on faulty goods. But you ned to know what you are doing - they don't refund when you bought the wrong thing. For hardware compatibility, I am afraid I cannot help.
No, you will not be able to run Maya or Photoshop. I would hope that these would use GPU acceleration in their normal modes (either via DirectX or OpenGL) butthey are still going to run mostly on the main CPU.
If you don't already speak C, then (IMO) learning C is too much of a burden to add onto the norm,al burdens of a thesis. If you were that kind of a geek, you would be there already. But you definitely want to look at the available graphic tools, such as the ones you mentioned, and see which ones can best use the added power of a GPU. The oomph of one of these GPUs will go of the order of a hundred times faster than the same render in the general purpose CPU - once it gets started. So it would, aain IMP, be worth researching which animation package best exploits GPUs, and putting some effort into optimising that use. Starting "clean sheet" with C code is backing off too far to takea run at your target.
Slashdot Mirror
Of course they are sharing the raw data. But understanding the raw data means understanding a great deal about the physical structure of the detector. Basically, if you know enough about that, you are part of the CERN team, whether you are physically there or not. Relatively few of the thousands of scientists working "at" CERN are physically there at any time: most spend most of their time connected only electronically. Why do you think the WWW was invented there?
Because the greater energy of CERN is like shining a brighter light even at the lower energies where CERN overlaps with earlier accelerators. It is like a searchlight coming on after people have been searching with a hand torch: the searchlight will show ups instantly things which the hand torch would have taken a long time to find. CERN is going to start with a half power run-up, but even at that power is should easily see everything that others have struggled to see. Indeed, I would expect them to do that routinely as a method of validating the machine's operation: they should be able to "see" all the known particles at their appropriate energies, and they may well be able to refine the values for those energies.
You need to distinguish between sectors reallocated at manufacturing time, which are relatively benign, and those auto-replaced later. For the latter, I would mostly agree with you. One or two reallocations don't seem to be a problem, but as many as five have usually shown a drive on its last legs.
One drive I studied had a policy of one spare sector per track plus one spare track per cylinder (this was a while back, when disks often had five platters). Which meant that performance fell sharply as the number of faults passed one per track.
In a disk,the tracks have a physical size, and the heads don't always get to exactly the same position when they re-write the track. So if you write a data track, then overwrite it, the overwrite may be slightly to the left or right of the original, and a little bit of the original is not overwritten. If you then deliberately command the read to a small fraction out, you may get enough signal to pick up the deleted data.
To actually overwrite the data, I would guess you have to have one overwrite slightly to the left of the original write, and one slightly to the right. But since you cannot predict what is going to happen, because it is dues to minute and unrepeatable mechanical effects, you need to overwrite it multiple times using different patterns of seeks to get to the track.
I don't think you know what a "Gravity Tractor" is. It is about 20 tons (min) of rock. We have that. It is put close to the asteroid in the direction we want to pull it, and good ol' Newtonian gravity is allowed exert traction (mMG/d^2). Then thrusters on the lump of rock thrust to get rid of the "equal and opposite" reaction pulling the lump onto the asteroid. So, like the classic donkey with a carrot on a string, the asteroid is gently lead away from the collision with earth.
This is *much* safer than nukes, and *much* lower technology. We can do. No. For mere money.
The asteroid is almost certainly spinning to some extent, and not about an axis that you wnat to push on. For a "one big thump" impact that doesn't matter, but for a steady push you would have to kill the rotation, which would probably take much more energy. The gravity tractor hangs just out of the reach of any flailing "mountains" and pulls in a constant direction.
Th falling apart problem probably wouldn't matter for the tiny impulse suggested, but would for the "one bigh thump", whose consequences would be extremely unpredictable. By contrast, the gravity tractor is pretty precise to start with, and the longer it runs the better we know the asteroids mass and the prciser it becomes.
This is not new news - I first heard it about a year ago. But the idea is getting critical oversight, and standing up to it, which is promising. But basically, when I heard this idea, I stopped panicing about asteroids. If we get three years warning, we can fix it. It may take Apollo-scale expenditure, but it can be done. Actually, my estimate would be lower - range $10-40 billion. Which has to be a hell of a sight better cost/benefit ration than the Iraq war.
I didn't mod the comment "Troll", and I don't consider it so. You cannot moderate and comment in the same thread - when you comment, your mods are cancelled.
As for burying it, how else in Europe are you going to build something 27 km across and dead level, with mounting points for thousands of tons of equipment? It is not below a mountain, it is below farmland. Anywhere reasonably flat in Europe is covered with towns and villages and criss-crossed with roads. And the flatness requirement is *exact*, so if the ground is only fairly flat, you will have to have bits in tunnels and/or on stilts anyway. On stilts is bad for carrying heavy loads. And you don't want your hypersensitive particle detectors triggered by cosmic radiation, so they will have to be heavily shielded anyway. Since the equipment needs to be well protected from accidents and weather for purely engineering reasons (big magnets, huge currents, super-cooling, vacuum). I could see problems with those magnets distorting every CRT-based television for hundreds of yards. The reason for burying it is purely for experimental purposes rather than safety. It is re-using the tunnel dug for an earlier detector, decommissioned a few years ago.
Which is rather like worrying about recreating the conditions of the Dresden Firestorm when you light a match. The conditions created by this experiment are created many times a day when high energy cosmic rays hit the Earth. Unfortunately, they are not created in the middle of a multi-thousand-ton detector. The fears expressed are complete FUD.
It is a Pretty Big Thing to cool to 1.4C. Also it is a nice pun in the idea that the LHC is Kewl. Any excuse is a good excuse to publish a reasonably accurate and informative article about Big Science doing what it is meant to do. In a news stream full of doom and disaster, the LHC coming on line is a rare example of something that is both Good and News.
TFA has one of the few times when the adjective "cataclysmic" can be used with out accusations of hyperbole. If the Big bang isn't cataclysmic, it is difficult to see what is.
As I (and IANAL) understand it, no. Either someone who loans/gives money to the litigant, or someone who obtains a significant (but not necessarily controlling) interest in the litigant, if the effect is as described, can be regarded as a party to the case and thus civilly liable for the legal costs. Of course, there is a burden of proof: the backers could claim that they were buying into SCO's normal operations and not, intentionally, into the lawsuit. The burden of proof of this would be on the complainant wanting to reclaim costs. But I think that in this case, it would be reasonable to state that the lawsuit was SCO's principal asset, and anybody funding SCO either by debt or equity was making themselves a party to the lawsuit. (Of course, someone such as Microsoft, who funded them by making unusual purchases, would not be liable: you can hardly be expected to be liable for your supplier's lawsuits).
Of course, it would take the lawyers to decide, and I certainly claim no knowledge at all of US law. The situation came up when the company I worked for won a case against the another, whose owners had tried to isolate themselves from loss by sucking that company dry. The costs were ruled to be due from the owners: despite being a separate company, they had supported the subsidiary through the suit and were therefore liable for the costs. But this is anecdotal, from talking to the managers who talked to the lawyers.
Under UK law (and I realise that this is a US case), the claim for legal fees could be pursued back to SCO's backers. There is a concept of "constructive support". If A gives B a pile of money to legally harass C, and the court finds that B's claim is substantially without value (which seems to be the case here) and awards costs against B to C, then C can chase A for those costs if B cannot pay. There is an obvious reason for this: you should not be able use the law as weapon against others with a fall-guy in the middle to protect you from the consequences. It seems to me that US law should have some equivalent provision, which would allow Novell to go against SCO's financiers for those legal costs.
That might be overkill - putting the CEO of a major bank in prison could cause an collapse leading to a depression.
If the bank is that fragile it's doomed anyway. He could also get hit by a bus.
Getting hit by a bus does not imply criminality. It is the implication that the organisation has had a crook at its head which does the harm, not the departure of any single individual. Bankers work very hard to look respectable, hence the marble foyers and double breasted suits (not both worn at the same time).
Putting the CEO of the government into prison would cause major political upheavals would have massive knock-on effects, dependant upon political system.
It's about the smartest thing we could do in the USA, but we'd have to put the whole fucking cabinet in there with him.
Far be it from me to disagree..
That might be overkill - putting the CEO of a major bank in prison could cause an collapse leading to a depression. Putting the CEO of the government into prison would cause major political upheavals would have massive knock-on effects, dependant upon political system.
Most of the recent data losses in the UK have involved government data. One was for the agency paying support to poor families - they *need* that money and cannot go elsewhere. Another was the Army recruitment department: if you want to join the Army, there isn't another one you can choose because this one had poor data security.
It tells us that there are no benefits on a single core, or using threading models fundamentally designed for single cores and then bodged for small numbers of cores. Until all the randomly ordered lines can be executed simultaneously by multiple cores, such randomisation is all pain, no gain. (Except that top-end CPUS do that internally on a very fine grain with look-ahead execution etc.)
You also need to make mahomet come to the mountain. The current model is that the mountain (data) comes to mahomet (the processor, the active unit). If you have many cores, you put them "near" different address spaces, and the threads execute on a core "near" the data. If one area of memory gets overcrowded, the data migrates to a cooler area with more free cores. It may sound odd to bulk move the data, but if you are using small enough atoms, there will be fewer mcycles involved in a block copy that in accessing it many times over for processing.
No, it shows that there are no CPUs and accompanying execution environments capable of exploiting such techniques. It only becomes worthwhile when there are many cores capable of executing the randomly sorted code. Doing it on a single core, or any system with current inter-process communications models, would just introduce complexity for no gain.
The majority of code written in current programming languages does not parallelise well, because sequential execution is built into the structure of the language. The default operation is to execute instructions in sequence. But if the default were to execute all the commands in a block in parallel, unless instructed otherwise, there would be a lot more parallelism. And once people got used to this parallel thinking, they would design in more parallelism.
So you have to split the problem into an enormous number of pieces - much larger than the number of cores. Then you don't communicate explicitly, you just have a task queue. Each core does one micro-task, generating zero or more new microtasks which added to the task queue. In principle, after each task the core takes the next off the queue, but you might use the equivalent of tail-recursion: run the last-generated microtask, if any.
But such a system could never be written in C or other pure imperative languages. You need Functional Programming, or some other new paradigm, in which the order of execution is divorced from program layout. Which is what the Intel bods are talking about.
Well, for one possibility, quality voice recognition. Dozens of cores each parsing the sound stream to test a different hypothesis of what you said, using both phonic and semantic analysis. Somewehat similar to the way the brain works. And results wanted in real time.
But what they are saying is they have evidence rather than an idea. Not awfully strong evidence, buyt it adds weight to the idea, which was previously just hot air - interesting, but still hot mair.
I buy my hardware from dabs.com. Cheap, fast, good refund on faulty goods. But you ned to know what you are doing - they don't refund when you bought the wrong thing. For hardware compatibility, I am afraid I cannot help.
No, you will not be able to run Maya or Photoshop. I would hope that these would use GPU acceleration in their normal modes (either via DirectX or OpenGL) butthey are still going to run mostly on the main CPU.
If you don't already speak C, then (IMO) learning C is too much of a burden to add onto the norm,al burdens of a thesis. If you were that kind of a geek, you would be there already. But you definitely want to look at the available graphic tools, such as the ones you mentioned, and see which ones can best use the added power of a GPU. The oomph of one of these GPUs will go of the order of a hundred times faster than the same render in the general purpose CPU - once it gets started. So it would, aain IMP, be worth researching which animation package best exploits GPUs, and putting some effort into optimising that use. Starting "clean sheet" with C code is backing off too far to takea run at your target.