I suppose lawyers have an ethical duty to argue every point that reasonably could help their client, but this is silly
That is certainly the stance most lawyers take, but I'd argue that lawyers actually have an ethical duty to argue the merits of their client's case, which is not the same thing. I think it fair to say that a merit would be a point where reasonable people could generally agree on the point being true whether or not they'd agree on the interpretation of that point. A court case is ultimately about interpretation of facts, but it is very dangerous ground when courts become interpreters of visions.
Oracle might like that sort of thing, they're named after women who interpreted visions after all, but it renders the entire concept of law into a matter of soothsaying and religion, whereas the entire purpose law was created in the first place - via the codes of Hammurabi, Aethelberht and Alfred - was to stop such practices.
Seriously, though, since there is no formal definition of what Elvish is and the "translations" of words differ between stories, I am not convinced Elvish is copyright. Trademarked, perhaps, since it would be legitimate for the Tolkien estate to claim that the word when associated with the Tolkien conlang has a definite meaning and is definitely a property of some sort of said estate. But copyright? Copyright implies a defined structure (which is why databases and books can be copyright but data elements and words cannot), but no such structure was ever developed for Elvish -EXCEPT- for the unofficial and incomplete Elvish Dictionary (which certainly does NOT belong to the estate).
Elvish is closer to Finnish than Dgèrnésiais (the native language of Guernsey) is to French, but the official French position is that Dgèrnésiais is a regional dialect and not an independent language. If we are to use that as a measure of how different something has to be to be a language and not a dialect, then Elvish would necessarily be a dialect too. Personally, I hold Dgèrnésiais and French to either be dialects of Norman or wholly distinct languages but that to call Dgèrnésiais a French dialect is linguistic incest. However, I'm not in government and those who are say otherwise.
An interesting argument, there are others that are perhaps better-suited to the courtroom. Java is an API, the implementation is in the JVM and not the language. APIs are not automatically copyright, since they are a meta-description. The -implementation- of those APIs is copyright, because it is a specific case. It's the same reason that a dictionary can be copyright but the words within it cannot.
Sun successfully argued in court that to call something Java it has to implement the Java API. That's fair enough. It would be deceptive if you implemented Basic and called it C and it would be maliciously deceptive if you did so for the purpose of damaging C (whether or not it had much impact in the end), so Microsoft's deliberate attempt to destroy Java by violating the standards was definitely in the wrong and enforcing those standards in court was an impressive feat by Sun.
Sun did NOT argue Microsoft could not implement Java, merely that if they wrote something they promoted as Java then it damn well should be Java.
Oracle's argument is significantly different. The enforcement of a standard by trademark is very different from the enforcement of using a specific implementation by saying that the standard is the work.
I can respect the former. I would have no difficulty with Oracle arguing that all trademarks and licenses involving Java require adherence to the official standard, that said licenses stipulate that there should be no fragmentation of that standard as a condition of use, and that the Android implementation cannot violate the licenses involved (for the trademarks or anything else) as per the Microsoft case.
I cannot, however, respect the idea that the standard IS the implementation. It patently isn't (pun not intended), since the standard implements nothing. To allow that argument would be extremely dangerous, as it would mean that Oracle could circumvent all analysis on the legality of patents on intangibles like business methods by simply claiming they're copyright instead. Indeed, because of international copyright agreements, it would mean that things which are NOT protected (for good reason) in the EU would suddenly become protected despite contrary rulings by the EU's courts. ie: it would allow Oracle to impose a law on Europe that Europe has rejected as unlawful. Complain about the EU being undemocratic all you like, but I sure as hell didn't elect Oracle as president of anything.
Privacy is just a variant on the same theme as physical property, copyright or trademarks - our right to give someone something of ours is NOT the same as someone else's right to give someone something of ours. If something belongs to you, then since the days of Hammurabi it truly belongs to you and you have final say on what happens to it.
Privacy is NOT, as this judge would have it, equatable to a trade secret - where, once it is known, it is no longer afforded the protection of being a secret. Well, ok, some people regard this as being the correct model but I (and most of Europe) dispute this and, frankly, I'd argue that Europe has had rather longer to debate the various models than the American judiciary.
Once all data in your life is reduced to mere secrets (rather than personal property) you run into the obvious problem that everything in your life is ultimately reducible to data. That includes physical property, since ownership is not conveyed by possession but by certification and certification is data.
I'm not saying loss of privacy necessarily means loss of any form of ownership, but since they stem from the same root principle and have the same ultimate objective (you control what you own) then damage to both ends of one chain must correspond to damage to both ends of both chains. The "slippery slope" argument is often abused, but here I think it is a very legitimate concern and should not be treated lightly.
Because it forced people to understand how to write programs, rather than how to hack something that worked in a specific language. Very few people used Pascal in the real world, but because Pascal was so rigid in style, the thinking that resulted would work with any language in any era of programming. That's exactly the approach that should be used in learning programming, since you don't know (and can't know) what will be used in a decade's time (assuming he goes on to take a 3-year degree followed by a career in something utilizing programming skills).
Pascal is not the correct choice for today, but the strategy is still sound. You want something that allows him to learn programming (the subject) with as few dependencies on the specific stylistic choices of any given era as possible. In other words, you don't want something that depends on templates, aspects, objects or other phenomena which may or may not even exist in later languages, in just the same way that you wouldn't teach a person to drive one specific make and model of car where you're guaranteed those skills won't transfer and that the model won't exist for 90-95% of the person's actual time behind the wheel.
Python or Ruby might be good choices - however I dislike modern interpreted languages as they don't have the immediacy of feedback of BBC Basic or PET Basic, and if you don't have immediacy you might as well use a compiled language and get the additional feedback of warning and error messages. I'm not impressed with their GUI support, either.
Tcl/Tk has a really ancient GUI design, but does give you a lot of useful core concepts. The syntax is horrible, though. It looks like a cross between LISP and line noise after being put through a blender. It makes a great second language, but probably not a good introductory one.
MARS D has the concepts, the syntax is good and in most respects it is exactly what you want for a teaching language. It lacks development and debug tools, though, which means it's harder than necessary to make the jump from theory to practice and then from cause to effect. However, if he's willing to put in the extra effort necessary to bridge the gap, I'd say D is the best teaching language currently out there. It's also distant enough from commercial languages that the inevitable bad habits picked up when first starting won't impact him later on, yet close enough that good habits can be adjusted and recycled.
Java is NOT suitable as an introductory teaching language, because it forces a particular methodology. That is absolutely the WORST thing you can possibly do at the start. Java IS correct for teaching OO design and OO methodology as aspects of programming, but should absolutely NOT be used to teach programming itself. Further, because it IS used in the real world, bad habits picked up at the start will be congealed and reinforced rather than eliminated - always a bad move in education, although you wouldn't know it in many modern schools.
The last time major figures signed a letter skeptical of global warming, it turned out that the letter they had actually signed was NOT the letter that their signatures ended up attached to. The letter they had actually signed was not skeptical of AGW but skeptical of the level of accuracy to which specific claims had been given - a very different thing.
I do not know if this is the case with the NASA letter, but "once bitten, twice shy" as they say. Now that there has been examples of outright forgery by climate cynics (they don't deserve the label of skeptic), absolutely no such letter should be considered credible or honest until the signatories confirm that that was indeed the letter signed and that they understood it to mean what it is taken to mean.
Until such time, there is an onus on the DOJ to investigate prior substantiated forgeries to determine if they constitute a criminal activity. Sure, they probably don't in America, but nonetheless it is NOT the function of law-enforcement and the justice department to avoid determinations with political implications, it is their job to ensure that the criminal law of the land is actually followed. And you can't ensure that by ignoring things that are "sensitive". (I'm actually thinking of Enron, Lehrman Brothers, etc, prior to their respective collapsees when they were popular but red-flagged by anyone looking at what was really happening. Feel free to substitute other attempts to evade responsibility if you like, though.)
You will find that inaccurate navigation was of the dead-reckoning kind. Homing in on a radio signal is a rather different story. The Marconi system used a combination of directional and omnidirectional aerials to produce multiple bearings, where the transmitter was guaranteed to be at the intersection of those bearings, with the output visual displayed in the form of needles on a meter that could overlap.
Typical usage would be a member of the Danish or French Resistance placing a transmitter at a known frequency in the target building. The Marconi R1155 was sensitive enough to pick up even relatively low-power transmissions from a few hundred miles away* (I have great fun with the one I got back into working condition) and home in on it as you could any VOR on a modern aircraft. The difference being that, because you've multiple bearings, you have range as well as direction once you're close enough for the needles to be visually something other than parallel.
Aircraft navigation of the 80s was not much more than a simple variant on the theme, using multiple VOR transmitters at well-known locations rather than significantly-offset aerials operating on a single VOR. Ultimately, though, you're still using multiple bearings, except here the point of overlap is the aircraft itself and not a homing beacon.
What do you do when VORs are out of range?
The R1155 was capable of picking up medium-power signals from London with the aircraft in North Africa. A modern receiver has vastly superior reception. Unless you're flying over one of the poles, it's very hard to imagine any place on Earth where you could be out of range given 1980s-era technology and be incapable of accurate positioning.
*The R1155 was rated at 10uV of transmission power to 50mW of usable signal.
It isn't clear to me that KAL-007 was a genuine navigational error. Marconi's RDF was good enough to do precision-bombing and instrument-only landing in the 1940s. It is entirely possible that navigational aids 40 years later were indeed inferior, but even if true that's not through a lack of capability but a lack of wit. I'm not inclined to believe the conspiracy theories that the pilot was paid by the CIA to trigger the USSR defenses (the CIA haven't been competent in anything else, so there's no reason to believe they'd be able to accomplish such a task). Nonetheless, staggering errors of judgement were made by the pilot, even given all the other staggering errors of judgement that had led to pathetically sub-standard navigational aids.
Ultimately, however, this is true of most other disasters - be it the R101, the Titanic, the current global economic meltdown, Fukoshima or any others you might care to name. The problem can almost always be traced to a string of errors, stupidities and absurdities, ALL of which had been known to be errors, stupidities and absurdities AT THE TIME. In other words, gross negligence -- usually, but not always, accompanied by bean-counting. The disasters do NOT lead to solutions, the solutions already existed. The disasters lead merely to the accountants being ordered to loosen the purse-strings. At least for that week.
(The recent sinking of a cruise ship with loss of life has led to the discovery that modern passenger ships also lack sufficient lifeboats - and are also horribly unstable once they start shipping water, leading to half the lifeboats they do have being unusable. This is a repeat of the situation leading up to the Titanic. It exists not because people don't know how to build lifeboats or count passengers, but because decisions are made according to profit margins and not according to rational examination of cause-and-effect.)
History does not repeat itself, but accountants do. You can't avoid making decisions based on some economic philosophy, but it is self-evident to anyone but the determinedly blind that none of the economic philosophies out there are very good at risk management.
Is the gas engine equivalent. It'll be interesting to see if/when anyone actually uses either project, versus the software merely being there. The world doesn't operate according to Field of Dreams, building it means nothing. What matters is not what is there, but what people find useful.
A CPU network/bus with a "delay tolerant protocol" layer and support for tunneling to other chips
An MTU-to-MTU network/bus which used a compatible protocol to the CPU network/bus
MTUs to cache results locally
If you were really clever, the MTU would become a CPU with a very limited instruction set (since there's no point re-inventing the rest of the architecture and external caching for CPUs is better developed than external caching for MTUs). In fact, you could slowly replace a lot of the chips in the system with highly specialized CPUs that could communicate with each other via a tunneled CPU network protocol.
The Transputer was a brilliant design. Intel came up with a next-gen variant, called the iWarp, but never did anything with it and eventually abandoned the concept.
IIRC, each Transputer had four serial lines where each could be in transmit or receive mode. They each had their own memory management (16K on-board, extendable up to 4 gigs - it was a true 32-bit architecture) so there was never any memory contention. Arrays of thousands of Transputers, arranged in a Hypercube topology, were developed and could out-perform the Cray X-MP at a fraction of the cost.
Having a similar communications system in modern CPUs would certainly be doable. It would have the major benefit over a bus in that it's a local communications channel so you always have maximum bandwidth. Having said that, a switched network would have fewer interconnects and be simpler to construct and scale since the switching logic is isolated and not part of the core. You can also multicast and anycast on a switched network - technically doable on the Transputer but not trivial. Multicasting is excellent for MISD-type problems (multi-instruction, single-data) since you can have the instructions in the L1 cache and then just deliver the data in a single burst to all applicable cores.
(Interestingly, although PVM and MPI support collective operations of this kind, they're usually done as for loops, which - by definition - means your network latency goes up with the number of processes you send to. Since collective operations usually end in a barrier, even the process you first send to has this extra latency built into it.)
It's also arguable that it would be better if the networking in the CPU was compatible with the networking on the main bus since this would mean core-to-core communications across SMP would not require any translation or any extra complexities in the support chips. It would also mean CPU-to-GPU communications would be greatly simplified.
Ultimately, if you are switching between tasks, you have the CPU and memory overhead of a task-switching mechanism plus the latency overhead. It makes no difference whether the mechanism is in the OS, the program or a tea cosy. If you have such a mechanism and it is already running and you are already paying the price for it, then provided the mechanism is implemented efficiently it will be cheaper to use what you're already paying for than to re-implement it in yet another layer.
Memory bandwidth is indeed a significant issue, but it's surely more expensive for task-switching (where you're pulling state data off a queue and pushing it back on) versus true parallel operation (where each task maintains its own state independently and the state is always resident). I'd frankly prefer a different architecture in the computer such that bottlenecks between the cores and memory were reduced through a better structure rather than a dependency on miniscule caches, but we have what we have. I'd also prefer network cards to be able to do DMA and bypass the kernel (since that would automatically halve the bus bandwidth consumed by network operations) - and some can, but it's not very common.
Destroying Java is easy, it uses lousy models. However, for any concurrent Lua program, I could write a parallel Occam program that could slaughter the Lua code.
That's a terminal barrier for synchronous chips, but it's not an obstacle at the puny 3GHz speeds we're currently operating with (especially as overclockers have already established the same chips are capable of 7GHz without issues).
By the time we get to 30 GHz, we may well be working with 3D chips. Furthermore, you don't need a standardized clock for asynchronous chips and async CPUs already exist. (There's even a program to help you design them listed on Freshmeat.)
For doubling, you're correct. But I'm talking a 25-33% increase in clock speeds, not a 100-200% increase. And there's a far worse increase in leakage dropping from 35nm to 22nm than going from 3GHz to 4GHz (the proof of which is that you CAN run a Core2Duo at 7GHz reliably - which would be absolutely impossible if leakage was causing significant errors at that speed).
Fabrication AS IT STANDS is capable of making a 7GHz chip - we know this because the chips they produce can be run at that speed. The problem is that you've got to have the chip sitting in a bath of liquid nitrogen to run that fast. This isn't practical for home computers (yet) and for laptops could pose certain reproductive health problems if the piping broke.
If, however, you could produce superior cooling with existing chip designs, then that isn't an issue. You can ramp up the clock speed such that you generated the same concentrations of heat after the additional cooling is applied. True, the speedup isn't linear (P=I^2/R) but there is some.
The consumer need for faster clocks I've already addressed -- the programmers simply don't exist to make use of the technology as implemented, so you've got to adapt the technology to make use of the programmers as they are.
That is perfectly true, but many algorithms can be (and aren't). Even when algorithms have to be serialized, those algorithms generally form a small part of the overall program. (If you were to draw out a timing diagram for a program after the fashion of critical path analysis, you'd see lots of bits of work that don't need to be done sequentially. There isn't a serial list of dependencies, in the general case, for a complete program from start to end.)
Even knowing where things can be done in parallel isn't enough. There are single-threaded webservers that are faster than Apache's multithreaded model because of the overheads incurred by Apache's approach and the communications overheads of some of the decisions. (A serial server simulating parallel activity should NEVER be faster than a natively parallel server, because simulation itself involves significant overheads.) Simply adding threads to a program isn't enough - they have to be the right threads, communicating in the right way (Ahmdal's Law).
You also need to look beyond the algorithm itself. In general, a program will have input, output, housekeeping and other activities. I'm sure you remember from SE that I/O should be independent of the algorithm. By making those distinct event-driven threads, you're not stuffing your program with conditional branches and that will make your program faster, smaller and more reliable.
The biggest obstacle to higher clock speeds has been getting rid of the heat (which is why supercooled processors can be overclocked to 7 GHz). This could potentially lead to adding another GHz to clock speeds of domestic computers, perhaps 2 per node for top-end supercomputers. That's valuable, for although multicores are good, there just aren't that many decent parallel programmers out there. I (and a few others) find parallel programming easy but the vast majority of coders in the world got into the field as a way to get rich quick and aren't adept at anything beyond Visual Basic or the most trivial aspects of Java.
Badly-coded programs won't run better on multi-way chips, but can be forced to run faster on faster chips, so the only way to compensate for the lack of skill is to crank up the clock, which is only possible if you can avoid the chip cooking itself.
Those are excellent links. Working my way through them. That's the sort of data that can be sensibly used to make a rational decision on whether the dental X-Ray issue is significant or not (and if significant, to what degree). Agreed that research and applied research are good. Agreed that how things are (in terms of actual impact) vs how things are (in terms of what action people take) is incredibly frustrating and desperately sad.
Although not to do with brain cancer, the following paper (disclaimer: my uncle is one of the authors) covers genetic variations in the repair mechanism in DNA and the impact this has on cancer susceptibility. It demonstrates the fragility of the linear exposure argument elsewhere (since it's safe to assume that we don't know all the genes involved, all the polymorphisms that impact repair capacity or whether all repair is equally impacted) and potentially alters the interpretation of the results in the cites you gave (we know genes are multi-role but we don't know all the roles of all the genes).
Because it's one specific type of exposure event (one large burst, with continual exposure at much lower levels until decontamination was complete), which may or may not map to "bursty" exposure events as happens with medical scans.
Even your other examples are sustained, not bursty.
A person might get a dental x-ray every 6 months, but if a person had a serious head injury every 6 months then they've bigger problems than brain cancer.
This matters.
You've also got to consider the radiation involved. Ionizing radiation of different frequencies won't have an equal probability of ionizing, and a higher frequency will only have a higher probability of ionizing SPECIFIC things (an electron cannot jump half an orbit, you cannot have half a quantum leap).
Finally, you declare that there is no evidence that CT scans cause cancer but you provide no cites to any studies showing this. Falsification of a hypothesis is 9/10ths of science (the other 1/10th being the generation of hypotheses) so if your declaration was indeed true there should be ample evidence for it. So where is it?
Sorry, but my main objection to both the claim and counter-claim is that this is journalism, not science. Can't someone provide links to PLoS One papers? Arxiv? Cancer research group websites? I'd ask my uncle, who was a statistician specializing in cancer research, but he's retired and won't be on the cutting edge any more. This needs to be answered by researchers who have that up-to-the-microsecond knowledge.
However, I'd also point out that the "dramatic reduction" you speak of is questionable. I've seen no reliable figures showing it is dramatically better (dentist offices don't have on-site engineers, won't maintain equipment any more than they have to and are unlikely to have staff highly trained in the use of systems - more likely they know how to press a button but don't know how to adjust settings according to any manual that may exist).
Further, 20-30 years ago, fewer people would have had "routine" X-Rays than today, so even if the per-session dosage is actually lower, the net dose over the year might actually be greater. Instantaneous dose isn't important.
You are correct, although the repair mechanism is not all that good and ONLY exists in nucleic DNA (there is no repair mechanism in mitochondrial DNA).
Dosage over time is important, which is why the maximum safe dose is given as a dose per unit of time. However, in the better tables, the maximum safe dose per year is NOT 365.25x the maximum safe dose per day. The calculations are not simple ones and are constantly under revision. I imagine that with this new data on dental X-Rays that the safe dosage calculations will be revised downwards - probably not by a lot, but by enough to keep the risk within acceptable bounds. A 90% increase in risk is unlikely to be acceptable to WHO or the radiological protection boards of many western nations.
(The US is less likely to pay attention, oddly enough. Although horribly risk-averse in most respects, it has largely ignored EU and WHO recommended safety limits in many areas, opting for conditions that would be considered dangerous hazards elsewhere.)
But it cannot be a linear effect. The ionizing events may be linear, but the body's ability to deal with damage will be non-linear -- approximating to linear only over a small enough number of events. It is also now known that the probability of mutation events in DNA differs substantially along its length - two or three orders of magnitude isn't unusual. Some areas of DNA are unimportant, others more so. Approximating everything to linear relationships doesn't work.
Also, the vast majority of what we know about radiation and cancer comes from Nagasaki and Hiroshima, those being the longest-term studies ever performed on significant populations. That simply isn't enough data points to work with. Our understanding of different types of exposure is much more restricted. Our understanding of repair mechanisms even more so (Selenium is known to play a part, but Selenium supplements do not appear to alter the mechanism's capacity to respond).
Slashdot Mirror
That is certainly the stance most lawyers take, but I'd argue that lawyers actually have an ethical duty to argue the merits of their client's case, which is not the same thing. I think it fair to say that a merit would be a point where reasonable people could generally agree on the point being true whether or not they'd agree on the interpretation of that point. A court case is ultimately about interpretation of facts, but it is very dangerous ground when courts become interpreters of visions.
Oracle might like that sort of thing, they're named after women who interpreted visions after all, but it renders the entire concept of law into a matter of soothsaying and religion, whereas the entire purpose law was created in the first place - via the codes of Hammurabi, Aethelberht and Alfred - was to stop such practices.
Depends on how the rings were implemented.
Seriously, though, since there is no formal definition of what Elvish is and the "translations" of words differ between stories, I am not convinced Elvish is copyright. Trademarked, perhaps, since it would be legitimate for the Tolkien estate to claim that the word when associated with the Tolkien conlang has a definite meaning and is definitely a property of some sort of said estate. But copyright? Copyright implies a defined structure (which is why databases and books can be copyright but data elements and words cannot), but no such structure was ever developed for Elvish -EXCEPT- for the unofficial and incomplete Elvish Dictionary (which certainly does NOT belong to the estate).
Elvish is closer to Finnish than Dgèrnésiais (the native language of Guernsey) is to French, but the official French position is that Dgèrnésiais is a regional dialect and not an independent language. If we are to use that as a measure of how different something has to be to be a language and not a dialect, then Elvish would necessarily be a dialect too. Personally, I hold Dgèrnésiais and French to either be dialects of Norman or wholly distinct languages but that to call Dgèrnésiais a French dialect is linguistic incest. However, I'm not in government and those who are say otherwise.
An interesting argument, there are others that are perhaps better-suited to the courtroom. Java is an API, the implementation is in the JVM and not the language. APIs are not automatically copyright, since they are a meta-description. The -implementation- of those APIs is copyright, because it is a specific case. It's the same reason that a dictionary can be copyright but the words within it cannot.
Sun successfully argued in court that to call something Java it has to implement the Java API. That's fair enough. It would be deceptive if you implemented Basic and called it C and it would be maliciously deceptive if you did so for the purpose of damaging C (whether or not it had much impact in the end), so Microsoft's deliberate attempt to destroy Java by violating the standards was definitely in the wrong and enforcing those standards in court was an impressive feat by Sun.
Sun did NOT argue Microsoft could not implement Java, merely that if they wrote something they promoted as Java then it damn well should be Java.
Oracle's argument is significantly different. The enforcement of a standard by trademark is very different from the enforcement of using a specific implementation by saying that the standard is the work.
I can respect the former. I would have no difficulty with Oracle arguing that all trademarks and licenses involving Java require adherence to the official standard, that said licenses stipulate that there should be no fragmentation of that standard as a condition of use, and that the Android implementation cannot violate the licenses involved (for the trademarks or anything else) as per the Microsoft case.
I cannot, however, respect the idea that the standard IS the implementation. It patently isn't (pun not intended), since the standard implements nothing. To allow that argument would be extremely dangerous, as it would mean that Oracle could circumvent all analysis on the legality of patents on intangibles like business methods by simply claiming they're copyright instead. Indeed, because of international copyright agreements, it would mean that things which are NOT protected (for good reason) in the EU would suddenly become protected despite contrary rulings by the EU's courts. ie: it would allow Oracle to impose a law on Europe that Europe has rejected as unlawful. Complain about the EU being undemocratic all you like, but I sure as hell didn't elect Oracle as president of anything.
Privacy is just a variant on the same theme as physical property, copyright or trademarks - our right to give someone something of ours is NOT the same as someone else's right to give someone something of ours. If something belongs to you, then since the days of Hammurabi it truly belongs to you and you have final say on what happens to it.
Privacy is NOT, as this judge would have it, equatable to a trade secret - where, once it is known, it is no longer afforded the protection of being a secret. Well, ok, some people regard this as being the correct model but I (and most of Europe) dispute this and, frankly, I'd argue that Europe has had rather longer to debate the various models than the American judiciary.
Once all data in your life is reduced to mere secrets (rather than personal property) you run into the obvious problem that everything in your life is ultimately reducible to data. That includes physical property, since ownership is not conveyed by possession but by certification and certification is data.
I'm not saying loss of privacy necessarily means loss of any form of ownership, but since they stem from the same root principle and have the same ultimate objective (you control what you own) then damage to both ends of one chain must correspond to damage to both ends of both chains. The "slippery slope" argument is often abused, but here I think it is a very legitimate concern and should not be treated lightly.
Because it forced people to understand how to write programs, rather than how to hack something that worked in a specific language. Very few people used Pascal in the real world, but because Pascal was so rigid in style, the thinking that resulted would work with any language in any era of programming. That's exactly the approach that should be used in learning programming, since you don't know (and can't know) what will be used in a decade's time (assuming he goes on to take a 3-year degree followed by a career in something utilizing programming skills).
Pascal is not the correct choice for today, but the strategy is still sound. You want something that allows him to learn programming (the subject) with as few dependencies on the specific stylistic choices of any given era as possible. In other words, you don't want something that depends on templates, aspects, objects or other phenomena which may or may not even exist in later languages, in just the same way that you wouldn't teach a person to drive one specific make and model of car where you're guaranteed those skills won't transfer and that the model won't exist for 90-95% of the person's actual time behind the wheel.
Python or Ruby might be good choices - however I dislike modern interpreted languages as they don't have the immediacy of feedback of BBC Basic or PET Basic, and if you don't have immediacy you might as well use a compiled language and get the additional feedback of warning and error messages. I'm not impressed with their GUI support, either.
Tcl/Tk has a really ancient GUI design, but does give you a lot of useful core concepts. The syntax is horrible, though. It looks like a cross between LISP and line noise after being put through a blender. It makes a great second language, but probably not a good introductory one.
MARS D has the concepts, the syntax is good and in most respects it is exactly what you want for a teaching language. It lacks development and debug tools, though, which means it's harder than necessary to make the jump from theory to practice and then from cause to effect. However, if he's willing to put in the extra effort necessary to bridge the gap, I'd say D is the best teaching language currently out there. It's also distant enough from commercial languages that the inevitable bad habits picked up when first starting won't impact him later on, yet close enough that good habits can be adjusted and recycled.
Java is NOT suitable as an introductory teaching language, because it forces a particular methodology. That is absolutely the WORST thing you can possibly do at the start. Java IS correct for teaching OO design and OO methodology as aspects of programming, but should absolutely NOT be used to teach programming itself. Further, because it IS used in the real world, bad habits picked up at the start will be congealed and reinforced rather than eliminated - always a bad move in education, although you wouldn't know it in many modern schools.
The last time major figures signed a letter skeptical of global warming, it turned out that the letter they had actually signed was NOT the letter that their signatures ended up attached to. The letter they had actually signed was not skeptical of AGW but skeptical of the level of accuracy to which specific claims had been given - a very different thing.
I do not know if this is the case with the NASA letter, but "once bitten, twice shy" as they say. Now that there has been examples of outright forgery by climate cynics (they don't deserve the label of skeptic), absolutely no such letter should be considered credible or honest until the signatories confirm that that was indeed the letter signed and that they understood it to mean what it is taken to mean.
Until such time, there is an onus on the DOJ to investigate prior substantiated forgeries to determine if they constitute a criminal activity. Sure, they probably don't in America, but nonetheless it is NOT the function of law-enforcement and the justice department to avoid determinations with political implications, it is their job to ensure that the criminal law of the land is actually followed. And you can't ensure that by ignoring things that are "sensitive". (I'm actually thinking of Enron, Lehrman Brothers, etc, prior to their respective collapsees when they were popular but red-flagged by anyone looking at what was really happening. Feel free to substitute other attempts to evade responsibility if you like, though.)
You will find that inaccurate navigation was of the dead-reckoning kind. Homing in on a radio signal is a rather different story. The Marconi system used a combination of directional and omnidirectional aerials to produce multiple bearings, where the transmitter was guaranteed to be at the intersection of those bearings, with the output visual displayed in the form of needles on a meter that could overlap.
Typical usage would be a member of the Danish or French Resistance placing a transmitter at a known frequency in the target building. The Marconi R1155 was sensitive enough to pick up even relatively low-power transmissions from a few hundred miles away* (I have great fun with the one I got back into working condition) and home in on it as you could any VOR on a modern aircraft. The difference being that, because you've multiple bearings, you have range as well as direction once you're close enough for the needles to be visually something other than parallel.
Aircraft navigation of the 80s was not much more than a simple variant on the theme, using multiple VOR transmitters at well-known locations rather than significantly-offset aerials operating on a single VOR. Ultimately, though, you're still using multiple bearings, except here the point of overlap is the aircraft itself and not a homing beacon.
What do you do when VORs are out of range?
The R1155 was capable of picking up medium-power signals from London with the aircraft in North Africa. A modern receiver has vastly superior reception. Unless you're flying over one of the poles, it's very hard to imagine any place on Earth where you could be out of range given 1980s-era technology and be incapable of accurate positioning.
*The R1155 was rated at 10uV of transmission power to 50mW of usable signal.
It isn't clear to me that KAL-007 was a genuine navigational error. Marconi's RDF was good enough to do precision-bombing and instrument-only landing in the 1940s. It is entirely possible that navigational aids 40 years later were indeed inferior, but even if true that's not through a lack of capability but a lack of wit. I'm not inclined to believe the conspiracy theories that the pilot was paid by the CIA to trigger the USSR defenses (the CIA haven't been competent in anything else, so there's no reason to believe they'd be able to accomplish such a task). Nonetheless, staggering errors of judgement were made by the pilot, even given all the other staggering errors of judgement that had led to pathetically sub-standard navigational aids.
Ultimately, however, this is true of most other disasters - be it the R101, the Titanic, the current global economic meltdown, Fukoshima or any others you might care to name. The problem can almost always be traced to a string of errors, stupidities and absurdities, ALL of which had been known to be errors, stupidities and absurdities AT THE TIME. In other words, gross negligence -- usually, but not always, accompanied by bean-counting. The disasters do NOT lead to solutions, the solutions already existed. The disasters lead merely to the accountants being ordered to loosen the purse-strings. At least for that week.
(The recent sinking of a cruise ship with loss of life has led to the discovery that modern passenger ships also lack sufficient lifeboats - and are also horribly unstable once they start shipping water, leading to half the lifeboats they do have being unusable. This is a repeat of the situation leading up to the Titanic. It exists not because people don't know how to build lifeboats or count passengers, but because decisions are made according to profit margins and not according to rational examination of cause-and-effect.)
History does not repeat itself, but accountants do. You can't avoid making decisions based on some economic philosophy, but it is self-evident to anyone but the determinedly blind that none of the economic philosophies out there are very good at risk management.
Is the gas engine equivalent. It'll be interesting to see if/when anyone actually uses either project, versus the software merely being there. The world doesn't operate according to Field of Dreams, building it means nothing. What matters is not what is there, but what people find useful.
Freshmeat record: http://freecode.com/projects/balsaasync
Site: http://apt.cs.manchester.ac.uk/projects/tools/balsa/
Also useful: http://apt.cs.man.ac.uk/projects/tools/lard/
For low-level ccNUMA, you'd want three things:
If you were really clever, the MTU would become a CPU with a very limited instruction set (since there's no point re-inventing the rest of the architecture and external caching for CPUs is better developed than external caching for MTUs). In fact, you could slowly replace a lot of the chips in the system with highly specialized CPUs that could communicate with each other via a tunneled CPU network protocol.
The Transputer was a brilliant design. Intel came up with a next-gen variant, called the iWarp, but never did anything with it and eventually abandoned the concept.
IIRC, each Transputer had four serial lines where each could be in transmit or receive mode. They each had their own memory management (16K on-board, extendable up to 4 gigs - it was a true 32-bit architecture) so there was never any memory contention. Arrays of thousands of Transputers, arranged in a Hypercube topology, were developed and could out-perform the Cray X-MP at a fraction of the cost.
Having a similar communications system in modern CPUs would certainly be doable. It would have the major benefit over a bus in that it's a local communications channel so you always have maximum bandwidth. Having said that, a switched network would have fewer interconnects and be simpler to construct and scale since the switching logic is isolated and not part of the core. You can also multicast and anycast on a switched network - technically doable on the Transputer but not trivial. Multicasting is excellent for MISD-type problems (multi-instruction, single-data) since you can have the instructions in the L1 cache and then just deliver the data in a single burst to all applicable cores.
(Interestingly, although PVM and MPI support collective operations of this kind, they're usually done as for loops, which - by definition - means your network latency goes up with the number of processes you send to. Since collective operations usually end in a barrier, even the process you first send to has this extra latency built into it.)
It's also arguable that it would be better if the networking in the CPU was compatible with the networking on the main bus since this would mean core-to-core communications across SMP would not require any translation or any extra complexities in the support chips. It would also mean CPU-to-GPU communications would be greatly simplified.
Ultimately, if you are switching between tasks, you have the CPU and memory overhead of a task-switching mechanism plus the latency overhead. It makes no difference whether the mechanism is in the OS, the program or a tea cosy. If you have such a mechanism and it is already running and you are already paying the price for it, then provided the mechanism is implemented efficiently it will be cheaper to use what you're already paying for than to re-implement it in yet another layer.
Memory bandwidth is indeed a significant issue, but it's surely more expensive for task-switching (where you're pulling state data off a queue and pushing it back on) versus true parallel operation (where each task maintains its own state independently and the state is always resident). I'd frankly prefer a different architecture in the computer such that bottlenecks between the cores and memory were reduced through a better structure rather than a dependency on miniscule caches, but we have what we have. I'd also prefer network cards to be able to do DMA and bypass the kernel (since that would automatically halve the bus bandwidth consumed by network operations) - and some can, but it's not very common.
Destroying Java is easy, it uses lousy models. However, for any concurrent Lua program, I could write a parallel Occam program that could slaughter the Lua code.
How should I know, I'm not you.
That's a terminal barrier for synchronous chips, but it's not an obstacle at the puny 3GHz speeds we're currently operating with (especially as overclockers have already established the same chips are capable of 7GHz without issues).
By the time we get to 30 GHz, we may well be working with 3D chips. Furthermore, you don't need a standardized clock for asynchronous chips and async CPUs already exist. (There's even a program to help you design them listed on Freshmeat.)
For doubling, you're correct. But I'm talking a 25-33% increase in clock speeds, not a 100-200% increase. And there's a far worse increase in leakage dropping from 35nm to 22nm than going from 3GHz to 4GHz (the proof of which is that you CAN run a Core2Duo at 7GHz reliably - which would be absolutely impossible if leakage was causing significant errors at that speed).
Fabrication AS IT STANDS is capable of making a 7GHz chip - we know this because the chips they produce can be run at that speed. The problem is that you've got to have the chip sitting in a bath of liquid nitrogen to run that fast. This isn't practical for home computers (yet) and for laptops could pose certain reproductive health problems if the piping broke.
If, however, you could produce superior cooling with existing chip designs, then that isn't an issue. You can ramp up the clock speed such that you generated the same concentrations of heat after the additional cooling is applied. True, the speedup isn't linear (P=I^2/R) but there is some.
The consumer need for faster clocks I've already addressed -- the programmers simply don't exist to make use of the technology as implemented, so you've got to adapt the technology to make use of the programmers as they are.
That is perfectly true, but many algorithms can be (and aren't). Even when algorithms have to be serialized, those algorithms generally form a small part of the overall program. (If you were to draw out a timing diagram for a program after the fashion of critical path analysis, you'd see lots of bits of work that don't need to be done sequentially. There isn't a serial list of dependencies, in the general case, for a complete program from start to end.)
Even knowing where things can be done in parallel isn't enough. There are single-threaded webservers that are faster than Apache's multithreaded model because of the overheads incurred by Apache's approach and the communications overheads of some of the decisions. (A serial server simulating parallel activity should NEVER be faster than a natively parallel server, because simulation itself involves significant overheads.) Simply adding threads to a program isn't enough - they have to be the right threads, communicating in the right way (Ahmdal's Law).
You also need to look beyond the algorithm itself. In general, a program will have input, output, housekeeping and other activities. I'm sure you remember from SE that I/O should be independent of the algorithm. By making those distinct event-driven threads, you're not stuffing your program with conditional branches and that will make your program faster, smaller and more reliable.
The biggest obstacle to higher clock speeds has been getting rid of the heat (which is why supercooled processors can be overclocked to 7 GHz). This could potentially lead to adding another GHz to clock speeds of domestic computers, perhaps 2 per node for top-end supercomputers. That's valuable, for although multicores are good, there just aren't that many decent parallel programmers out there. I (and a few others) find parallel programming easy but the vast majority of coders in the world got into the field as a way to get rich quick and aren't adept at anything beyond Visual Basic or the most trivial aspects of Java.
Badly-coded programs won't run better on multi-way chips, but can be forced to run faster on faster chips, so the only way to compensate for the lack of skill is to crank up the clock, which is only possible if you can avoid the chip cooking itself.
http://com.iarc.fr/en/publications/pdfs-online/stat/sp32/
This is an old book, but I think it's safe to say that even back then you didn't need 300+ pages to describe a straight line.
Those are excellent links. Working my way through them. That's the sort of data that can be sensibly used to make a rational decision on whether the dental X-Ray issue is significant or not (and if significant, to what degree). Agreed that research and applied research are good. Agreed that how things are (in terms of actual impact) vs how things are (in terms of what action people take) is incredibly frustrating and desperately sad.
Although not to do with brain cancer, the following paper (disclaimer: my uncle is one of the authors) covers genetic variations in the repair mechanism in DNA and the impact this has on cancer susceptibility. It demonstrates the fragility of the linear exposure argument elsewhere (since it's safe to assume that we don't know all the genes involved, all the polymorphisms that impact repair capacity or whether all repair is equally impacted) and potentially alters the interpretation of the results in the cites you gave (we know genes are multi-role but we don't know all the roles of all the genes).
http://hmg.oxfordjournals.org/content/11/12/1399.short
Because it's one specific type of exposure event (one large burst, with continual exposure at much lower levels until decontamination was complete), which may or may not map to "bursty" exposure events as happens with medical scans.
Even your other examples are sustained, not bursty.
A person might get a dental x-ray every 6 months, but if a person had a serious head injury every 6 months then they've bigger problems than brain cancer.
This matters.
You've also got to consider the radiation involved. Ionizing radiation of different frequencies won't have an equal probability of ionizing, and a higher frequency will only have a higher probability of ionizing SPECIFIC things (an electron cannot jump half an orbit, you cannot have half a quantum leap).
Finally, you declare that there is no evidence that CT scans cause cancer but you provide no cites to any studies showing this. Falsification of a hypothesis is 9/10ths of science (the other 1/10th being the generation of hypotheses) so if your declaration was indeed true there should be ample evidence for it. So where is it?
Sorry, but my main objection to both the claim and counter-claim is that this is journalism, not science. Can't someone provide links to PLoS One papers? Arxiv? Cancer research group websites? I'd ask my uncle, who was a statistician specializing in cancer research, but he's retired and won't be on the cutting edge any more. This needs to be answered by researchers who have that up-to-the-microsecond knowledge.
However, I'd also point out that the "dramatic reduction" you speak of is questionable. I've seen no reliable figures showing it is dramatically better (dentist offices don't have on-site engineers, won't maintain equipment any more than they have to and are unlikely to have staff highly trained in the use of systems - more likely they know how to press a button but don't know how to adjust settings according to any manual that may exist).
Further, 20-30 years ago, fewer people would have had "routine" X-Rays than today, so even if the per-session dosage is actually lower, the net dose over the year might actually be greater. Instantaneous dose isn't important.
You are correct, although the repair mechanism is not all that good and ONLY exists in nucleic DNA (there is no repair mechanism in mitochondrial DNA).
Dosage over time is important, which is why the maximum safe dose is given as a dose per unit of time. However, in the better tables, the maximum safe dose per year is NOT 365.25x the maximum safe dose per day. The calculations are not simple ones and are constantly under revision. I imagine that with this new data on dental X-Rays that the safe dosage calculations will be revised downwards - probably not by a lot, but by enough to keep the risk within acceptable bounds. A 90% increase in risk is unlikely to be acceptable to WHO or the radiological protection boards of many western nations.
(The US is less likely to pay attention, oddly enough. Although horribly risk-averse in most respects, it has largely ignored EU and WHO recommended safety limits in many areas, opting for conditions that would be considered dangerous hazards elsewhere.)
But it cannot be a linear effect. The ionizing events may be linear, but the body's ability to deal with damage will be non-linear -- approximating to linear only over a small enough number of events. It is also now known that the probability of mutation events in DNA differs substantially along its length - two or three orders of magnitude isn't unusual. Some areas of DNA are unimportant, others more so. Approximating everything to linear relationships doesn't work.
Also, the vast majority of what we know about radiation and cancer comes from Nagasaki and Hiroshima, those being the longest-term studies ever performed on significant populations. That simply isn't enough data points to work with. Our understanding of different types of exposure is much more restricted. Our understanding of repair mechanisms even more so (Selenium is known to play a part, but Selenium supplements do not appear to alter the mechanism's capacity to respond).