Uhhhh.... you DO know that Britain invented the MRI? That the MRI was invented in 1973 but Chernobyl went up in 1986? As for the rest of your claims, they sound more like sour grapes (Britain has more high-ranking Universities than any country other than the United States). If you're more interested in trolling than querying, you're doing a good job of it. As for "proof", since you're probably not going to consider the fact that I was a research assistant at the University of Manchester for the inorganic biochemistry group involved in this research... Well, many scientific papers are pay-to-view and I'm not buying the whole Slashdot readership access to all the journals articles were published in, just to satisfy one anonymous coward over one point. If you're that interested, and care that much, look it up yourself. Try looking for papers on radioactive sheep in Cumbria.
There are several problems with all of this. The original experiment does not appear to have any control group, it is unclear if the population sampled was genuinely random, the size of group tested seems to have been extremely small for a meaningful statistical study, and (perhaps most important of all), it assumes that mammalian vision is uniform greyscale AND that the candy was monochromatic.
(That last pair of points are important. Monkeys do not see all colours with equal clarity. Neither do humans, which is why monitors actually have more real-estate set aside for blue than for anything else. Complicating things, colours are usually the product of mixing. They are not "pure". We don't know what the monkeys saw, therefore cannot tell if their decision was influenced by their ability to even see the treats.)
Personally, I have developed a skepticism of such observational science. Too many possible explanations, yes, but more importatly too little experimentation to eliminate alternatives. If an explanation is put forward and then acted upon, especially in an area like psychology where those being acted upon are likely vulnerable groups, it's important to make sure the explanation is likely to be correct. Likely to be possible isn't good enough.
What would I suggest? Well, in the 1950s through to the last few years, options have been limited. These days, though, you can take fMRIs, MRIs and CAT scanners into the field. During the Chernobyl accident, it was fairly standard procedure for MRIs on trucks to be used to scan farm animals for contamination. See the brain in action as it makes the choices. See when the choice is made and which neural pathways were involved. Much better than speculating about what's going on. If you want more data, scientists decoded the optic fibre transmissions of cats ten years ago, or thereabouts. We can literally see if that plays a part in the decision.
You still end up doing statistics, sure, but with far more numbers that have far more meaning behind them and far less room for interpretation.
Compiler optimization is one of the most complex parts of the compiler. It's considered a Black Art by many because it is often counter-intuitive and not terribly amenable to logic. Rewriting compilers for in-order wouldn't seem to be much, but I'm guessing it's going to be a real headache. Source-to-source optimizers, like OpenIMPACT, will also need to be modified substantially.
However, previous generations will also need to be supported, so all of these programs will need to support both styles of code execution. Bloatbloatbloatbloat.
Very often, mathematical analysis will involve matrix algebra, systems of linear equations, systems of ordinary differential equations, or some other highly parallel task. Whether you use Freshmeat or Google, you'll find an extraordinary number of packages that are either highly multithreaded or use PVM or MPI to achieve parallelism. If the new POWER chips don't support out-of-order, maths users will suffer.
I can't see why a maths operation wouldn't be threadable. For example, (a*b)+(c*d) could be run as two threads for the multiplications, with one of those threads then performing the addition. A processor that keeps loading and executing instructions in distinct threads until a result is required (or processing elements are exhausted) would be able to do this and my understanding was that processors capable of hyperthreading and (if necessary) instruction reordering would be capable of such parallelism.
However, this depends on there being lots of maths compute elements. Since maths data is typically big (you want 64-bit precision output, so intermediate calculations need to be done at a much higher resolution - Intel uses 80-bits), expensive on silicon and not required to be fast for the majority of users, I imagine most CPU manufacturers only put in the maths capabiliy absolutely required. It's not surprising that for some high-end uses, the GPU is now being used in the same way as the maths co-processor once was.
Microsoft has launched a new bio-warfare division and is attempting to gene-splice the cancer mutagens from Linux with Minesweeper DNA in an effort to cause brain tumours in open source advocates.
If the terms are a megalomaniac lawyer's dream that would cut the throat of all competitors so gratuitously that the EU is forced to declare Microsoft in contempt of reality and seize all of their money and property, then, yes, the terms would indeed end up being pro open source.
Sure, you'll get a lot of irritating jabbering, but you get a lot of that anyway, and I can usually hear the sound from the headsets in the next two or three seats, so I'm used to being irritated. I'm rather more concerned with the fact that the FCC started asking about wiring and suddenly all the airlines are inspecting like mad. I'm also rather more concerned with the fact that I cannot get a reasonable quote on the radiation exposure to passengers on international flights. The difficulty in getting that number makes me think that for some long-haul flights, air crew and possibly passengers are exceeding safe limits. Air crew in particular, as they fly a lot. I'm also rather more concerned with "air rage", where passengers - usually drunk from the duty free - go berserk. With the increased restrictions on movement on aircraft, I imagine the death rate from deep vein thrombosis has also risen. There have also been reports in the press about passengers being able to gain access to aircraft control wiring in some cases. Aircraft systems operate on ARINC busses, which are just very expensive RS-232 links with a published protocol.
So, between mechanical issues, mental issues and medical issues, I just can't see how cell phones could add a whole lot of risk.
But all Microsoft has to do is find a senior manager or two who have significant stock and are disgruntled. Bound to be plenty of those. Microsoft then makes them a job offer with much better pay. Cheaper than buying the stocks directly. Not sure if they can buy stocks directly, but if they can, again, that would be cheaper than buying all the stock. A third option is for Microsoft to act in ways that deliberately drive Yahoo's stock value down and use the threat of financial loss to intimidate shareholders into coughing up.
Oh, I totally agree with you, I was merely allowing for the possibility that there was some level of intelligence behind this. The sensible thing, in my opinion, would be to maintain numbers and focus that manpower on AMD's strengths. Maintaining numbers doesn't mean maintaining weaknesses. AMD has the benefit of dexterity, which means it can shift focus far more quickly than Intel. AMD only has to attack in one area, Intel has to guard in every area. But AMD cannot hope to use that dexterity if it gets rid of core staff and (therefore) core competencies. Nor can it remain nimble if it had demoralized its staff. This is a vicious scrap between AMD and Intel. Regardless of how AMD may see things, Intel's viewpoint can best be summarized with a movie quote: There Can Be Only One. AMD may see the 10% of the workforce as bulky. Maybe that's true, but to use the analogy of Intel as a sword-wielding maniac, chainmail and shield are also bulky... but extremely useful if you plan on living very long. However, I don't see a strong case for saying that the 10% are even bulk. AMD could probably do with adding to its workforce, so that it has some armour against Intel's attacks.
One thing companies often forget. You don't win these kinds of power struggles by being efficient. A company with no employees is infinitely efficient but won't be winning anything. Money doesn't matter, either. There's always someone who will loan money... at a suitable interest rate. And, if the sales team is good enough, you can always recover in time. So how do you win? One way is by convincing the other side they have already lost. The Celts would do this with warpaint, by doing screaming berserker charges and putting the heads of enemies on spikes. This probably wouldn't work too well with AMD, at least not as it stands. Another method is by using the opponent's strength against them. Get them to throw their weight behind the wrong project. Get Intel to pull another Itanium, and simply run round them. Intel has too much inertia to back out fast from such errors.
A third option is to make the chips more widely available. I've worked for two companies that tried putting in substantial orders for AMD's processors, with AMD not even bothering to return the calls. Let's say this is because AMD didn't have the workforce to fill the orders. How is ditching workforce going to help? Surely, if they're struggling to meet demand, they'd want MORE people, not less.
The idea is to save mone, but this is only a useful tactic in the short-term. In the longer term, there's now that much less that the company can do, and (as you point out) that much less morale to do the work with. Yes, sometimes downsizing is the only way to stay afloat, because you need the mony now. On the other hand, if there's sufficient slack in the system that 90% of the people can do 100% of the work, then a full workforce can either fill more orders, deliver the orders that much faster or diversify the range supported by the company.
I am not an economist (it shows) but I am aware of the financial hazards of over-correction, the expenses involved in re-hiring, the dangers of brain-drain (especially to competition, and don't think NDAs and non-competes haven't been worked around by skilled lawyers), the impact on workforce loyalty (where such things still exist), and the cost in lead-time and therefore orders when things do pick up. Some painful decisions are inevitable, but the number of companies that never recover shows that massochism is alive and well amongst directors. Being painful doesn't make a decision correct.
You wouldn't believe some of the depravity on the Internet. (Seriously, it's not a "safe" place, but if you're Puritan, neither is the phone book, and the only guaranteed safe TV channel is one that is empty. Even Senators have been known to use profanity live.)
Better education would be the smartest move (and not just about the Internet), followed by "safe" (as in: non-controlling, non-manipulative, non-guilt-tripping, non-judgemental) support from trusted adults - not necessarily parents, and in many cases parents would be the worst option.
Some (maybe even many) kids will have an enquiring mind that won't tolerate obstrctions and would rather burn itself out trying than to give up. The worst thing that can happen is for such kids to be forced to back down. It can destroy their mind. I'm not joking. However, most of the areas that are likely to give parents concern are unlikely to be areas that obsessive geek kids are interested in. It should be easy enough to do a little steering to maximize what the kid learns, rather than cripple the kid to stop them encountering something that might hold their interest for a few seconds if just let go.
In their eyes, the only good solutions are new solutions.
I beg to differ. They're after profit, although novelty never hurts in advertising. I think that in their eyes, the only good solutions are the ones that cost the consumer more or give the consumer less. Preferably both. Switching on QoS on their routers (it's standard on Cisco and I'm pretty sure Juniper as well, so that's all the ISPs you need to give a damn about) would cost nothing but - by reducing turbulent data flows - give customers more. Since most xDSL and cable modems use Linux and Linux has QoS, it shoudn't be hard to notify customers or even just switch the damn thing on by default in the next system image.
The chair of Internet Czar officially still exists but is unoccupied. That might be a good place for politically-savvy geeks to press the case for QoS. It's all about labels. You could have an IQ of 2,000,000 and thirty simultaneous senior programmer roles, but executives will simply see you as a lesser lifeform. Same person as Internet Czar would be worshipped by the same executives as a god.
Gaining karma points on Slashdot is good. Designing lolcats only Geeks could actually understand and be amused by is good. Demonstrating to Pastis the readership relationship between his cartoon and chedder cheese is good. Drinking Real English tea is good. Watching "Not the Nine O'Clock News", "Kenny Everett" and "The Goodies" is good.
There's MTUs and window sizes to consider - default works fine most times, but do you understand those controls and when they should be used?,
Unless you're running some fancy link technology, you don't get to tune your MTU. If, like most of us, you're running Ethernet and WiFi only, you're stuck with 1500 bytes.
As for window sizes, they're pretty much tuned automatically nowadays, at least if you're running a recent Linux or Windows Vista.
Youl'll find the Web100 patch for Linux provides much better auto-tuning than the default. I don't know if/when it will go into the mainstream kernel, but I can think of very few patches more important. MTU settig is a Black Art. Setting it to 1500 will maximize total bytes transmitted, and the size of packet won't seriously impact the probability of the packet being lost, but WILL impact the recovery time and the storage requirements for recovery. 1500 also doesn't fit on a page boundary, reducing the theoretical maximum load on the system.
RED shouldn't be too hard, although there are a lot of RED-based systems (GRED, SRED, WRED, etc) and some of these are nasties. Also, BE AWARE, some frikkin' idiot wrote the basic RED implementation as a pipe, not as something applied to a pipe, so you cannot use it as expected and you cannot directly compare that RED implementation with other QoS, as it's a totally different form.
Multimedia is a b*tard, because the QoS methods you need (BLACK, WHITE and PURPLE are specifically designed for types of multimedia flow) do not exist for Linux as far as know. The alternative to using QoS would be to use RSVP or MPLS, but that requires every router between source and destination to recognize the protocols, auhorize their use, and then honour them. Not going to happen.
However, different tricks can be used, according to circumstance. If multiple nodes will nominally get the same data but some of it is corrupted in each case, there are methods of finding the nearest neighbor who can retransmit a packet, If there is uncertainty a to what is correct, the classes of problem normally described in terms of Byzantium generals include solutions to this.
Ok, here's the theory. Two packts have travelled some distance along two distinct paths p1 and p2. If nothing is done, then at least one packet is guaranteed lost, and quite likely both will. Thus, you will need to retransmit both packets, thus hitting every node along p1 and p2 will have the total traffic shifted over some given time period increased. When traffic levels are low enough, the extra traffic is absorbed into the flows and there's no impact beyond a slight fluctuation in latency.
If the total traffic is above some certain threshold, but below a critical value, then a signficant number of packets will be retransmitted. This causes the load to increase, the next cycle around, causing further packet loss and further retransmits. There will be a time - starting with a fall in fresh network demand - in which observed network demand actually rises, due to accumulation of erors.
There will then be a third critical value, close to but still below the rated throughput of the switch or router. Provided no errors occur, the traffic will flow smoothly and packet loss should not occur. This isn't entirely unlike superheating - particularly on collapse. Only a handful of retransmits would be required - and they could occur anywhere in the system for which this is merely one hop of many - to cause the traffic to suddenly exceed maximum throughput. Since the retransmitted packets will add to the existing flows, and since the increase in traffic will increase superlinearly, that node is effectively dead. If there's a way to redirect the traffic for dead nodes, there is then a high risk of cascading errors, where the failure will ripple out through the network, taking out router/switch after router/switch.
Does flow management work? Linux has a range of RED and BLUE implementions. Hold a contest at your local LUG or LAN Gamer's meets, to see who can set it up the best. Flow management also includes ECN. Have you switched that on yet? There's MTUs and window sizes to consider - default works fine most times, but do you understand those controls and when they should be used?
None of this stuff needs to be end-to-end unless it's endpoint-active (and only a handful of such protocols exist). It can all be done usefully anywhere in the network. I'll leave it as an exercise to the readership to identify any three specific methods and the specific places on the network they'd be useful on. Clues: Two, possibly all three, are described in detail in the Linux kernel help files. All of them have been covered by Slashdot. At least one is covered by the TCP/IP Drinking Game.
Does this mean that scratch DJs have to pay a format shifting fee for each scratch?
That comes under License Extensions for Time Delta Shifting, Recursive Shifting and Spanish Inquisition Sketch Shifting, all of which must be paid for individually. Remember, every time you scratch a record without paying, an angel gets its wings and legs ripped off.
Slashdot Mirror
Uhhhh.... you DO know that Britain invented the MRI? That the MRI was invented in 1973 but Chernobyl went up in 1986? As for the rest of your claims, they sound more like sour grapes (Britain has more high-ranking Universities than any country other than the United States). If you're more interested in trolling than querying, you're doing a good job of it. As for "proof", since you're probably not going to consider the fact that I was a research assistant at the University of Manchester for the inorganic biochemistry group involved in this research... Well, many scientific papers are pay-to-view and I'm not buying the whole Slashdot readership access to all the journals articles were published in, just to satisfy one anonymous coward over one point. If you're that interested, and care that much, look it up yourself. Try looking for papers on radioactive sheep in Cumbria.
That depends on how generous the discoverer is with their money.
(That last pair of points are important. Monkeys do not see all colours with equal clarity. Neither do humans, which is why monitors actually have more real-estate set aside for blue than for anything else. Complicating things, colours are usually the product of mixing. They are not "pure". We don't know what the monkeys saw, therefore cannot tell if their decision was influenced by their ability to even see the treats.)
Personally, I have developed a skepticism of such observational science. Too many possible explanations, yes, but more importatly too little experimentation to eliminate alternatives. If an explanation is put forward and then acted upon, especially in an area like psychology where those being acted upon are likely vulnerable groups, it's important to make sure the explanation is likely to be correct. Likely to be possible isn't good enough.
What would I suggest? Well, in the 1950s through to the last few years, options have been limited. These days, though, you can take fMRIs, MRIs and CAT scanners into the field. During the Chernobyl accident, it was fairly standard procedure for MRIs on trucks to be used to scan farm animals for contamination. See the brain in action as it makes the choices. See when the choice is made and which neural pathways were involved. Much better than speculating about what's going on. If you want more data, scientists decoded the optic fibre transmissions of cats ten years ago, or thereabouts. We can literally see if that plays a part in the decision.
You still end up doing statistics, sure, but with far more numbers that have far more meaning behind them and far less room for interpretation.
However, previous generations will also need to be supported, so all of these programs will need to support both styles of code execution. Bloatbloatbloatbloat.
Very often, mathematical analysis will involve matrix algebra, systems of linear equations, systems of ordinary differential equations, or some other highly parallel task. Whether you use Freshmeat or Google, you'll find an extraordinary number of packages that are either highly multithreaded or use PVM or MPI to achieve parallelism. If the new POWER chips don't support out-of-order, maths users will suffer.
However, this depends on there being lots of maths compute elements. Since maths data is typically big (you want 64-bit precision output, so intermediate calculations need to be done at a much higher resolution - Intel uses 80-bits), expensive on silicon and not required to be fast for the majority of users, I imagine most CPU manufacturers only put in the maths capabiliy absolutely required. It's not surprising that for some high-end uses, the GPU is now being used in the same way as the maths co-processor once was.
Ah, but what does that make a Beowulf cluster?
The only one with any right to do that would be the bogiman.
Microsoft has launched a new bio-warfare division and is attempting to gene-splice the cancer mutagens from Linux with Minesweeper DNA in an effort to cause brain tumours in open source advocates.
I thought it said "Open Source Chef" and wondered what a South Park character was doing at Microsoft.
If the terms are a megalomaniac lawyer's dream that would cut the throat of all competitors so gratuitously that the EU is forced to declare Microsoft in contempt of reality and seize all of their money and property, then, yes, the terms would indeed end up being pro open source.
So, between mechanical issues, mental issues and medical issues, I just can't see how cell phones could add a whole lot of risk.
But all Microsoft has to do is find a senior manager or two who have significant stock and are disgruntled. Bound to be plenty of those. Microsoft then makes them a job offer with much better pay. Cheaper than buying the stocks directly. Not sure if they can buy stocks directly, but if they can, again, that would be cheaper than buying all the stock. A third option is for Microsoft to act in ways that deliberately drive Yahoo's stock value down and use the threat of financial loss to intimidate shareholders into coughing up.
One thing companies often forget. You don't win these kinds of power struggles by being efficient. A company with no employees is infinitely efficient but won't be winning anything. Money doesn't matter, either. There's always someone who will loan money... at a suitable interest rate. And, if the sales team is good enough, you can always recover in time. So how do you win? One way is by convincing the other side they have already lost. The Celts would do this with warpaint, by doing screaming berserker charges and putting the heads of enemies on spikes. This probably wouldn't work too well with AMD, at least not as it stands. Another method is by using the opponent's strength against them. Get them to throw their weight behind the wrong project. Get Intel to pull another Itanium, and simply run round them. Intel has too much inertia to back out fast from such errors.
A third option is to make the chips more widely available. I've worked for two companies that tried putting in substantial orders for AMD's processors, with AMD not even bothering to return the calls. Let's say this is because AMD didn't have the workforce to fill the orders. How is ditching workforce going to help? Surely, if they're struggling to meet demand, they'd want MORE people, not less.
I am not an economist (it shows) but I am aware of the financial hazards of over-correction, the expenses involved in re-hiring, the dangers of brain-drain (especially to competition, and don't think NDAs and non-competes haven't been worked around by skilled lawyers), the impact on workforce loyalty (where such things still exist), and the cost in lead-time and therefore orders when things do pick up. Some painful decisions are inevitable, but the number of companies that never recover shows that massochism is alive and well amongst directors. Being painful doesn't make a decision correct.
Better education would be the smartest move (and not just about the Internet), followed by "safe" (as in: non-controlling, non-manipulative, non-guilt-tripping, non-judgemental) support from trusted adults - not necessarily parents, and in many cases parents would be the worst option.
Some (maybe even many) kids will have an enquiring mind that won't tolerate obstrctions and would rather burn itself out trying than to give up. The worst thing that can happen is for such kids to be forced to back down. It can destroy their mind. I'm not joking. However, most of the areas that are likely to give parents concern are unlikely to be areas that obsessive geek kids are interested in. It should be easy enough to do a little steering to maximize what the kid learns, rather than cripple the kid to stop them encountering something that might hold their interest for a few seconds if just let go.
I'm sure there were plenty of people from 200 years ago posting on today's Slashdot.
It's easy to deal with cats on Slashdot - remember to embed a cheeseburger in the first post.
I beg to differ. They're after profit, although novelty never hurts in advertising. I think that in their eyes, the only good solutions are the ones that cost the consumer more or give the consumer less. Preferably both. Switching on QoS on their routers (it's standard on Cisco and I'm pretty sure Juniper as well, so that's all the ISPs you need to give a damn about) would cost nothing but - by reducing turbulent data flows - give customers more. Since most xDSL and cable modems use Linux and Linux has QoS, it shoudn't be hard to notify customers or even just switch the damn thing on by default in the next system image.
The chair of Internet Czar officially still exists but is unoccupied. That might be a good place for politically-savvy geeks to press the case for QoS. It's all about labels. You could have an IQ of 2,000,000 and thirty simultaneous senior programmer roles, but executives will simply see you as a lesser lifeform. Same person as Internet Czar would be worshipped by the same executives as a god.
What's bad... All American TV shows and movies.
Unless you're running some fancy link technology, you don't get to tune your MTU. If, like most of us, you're running Ethernet and WiFi only, you're stuck with 1500 bytes. As for window sizes, they're pretty much tuned automatically nowadays, at least if you're running a recent Linux or Windows Vista.
Youl'll find the Web100 patch for Linux provides much better auto-tuning than the default. I don't know if/when it will go into the mainstream kernel, but I can think of very few patches more important. MTU settig is a Black Art. Setting it to 1500 will maximize total bytes transmitted, and the size of packet won't seriously impact the probability of the packet being lost, but WILL impact the recovery time and the storage requirements for recovery. 1500 also doesn't fit on a page boundary, reducing the theoretical maximum load on the system.
RED shouldn't be too hard, although there are a lot of RED-based systems (GRED, SRED, WRED, etc) and some of these are nasties. Also, BE AWARE, some frikkin' idiot wrote the basic RED implementation as a pipe, not as something applied to a pipe, so you cannot use it as expected and you cannot directly compare that RED implementation with other QoS, as it's a totally different form.
Multimedia is a b*tard, because the QoS methods you need (BLACK, WHITE and PURPLE are specifically designed for types of multimedia flow) do not exist for Linux as far as know. The alternative to using QoS would be to use RSVP or MPLS, but that requires every router between source and destination to recognize the protocols, auhorize their use, and then honour them. Not going to happen.
However, different tricks can be used, according to circumstance. If multiple nodes will nominally get the same data but some of it is corrupted in each case, there are methods of finding the nearest neighbor who can retransmit a packet, If there is uncertainty a to what is correct, the classes of problem normally described in terms of Byzantium generals include solutions to this.
If the total traffic is above some certain threshold, but below a critical value, then a signficant number of packets will be retransmitted. This causes the load to increase, the next cycle around, causing further packet loss and further retransmits. There will be a time - starting with a fall in fresh network demand - in which observed network demand actually rises, due to accumulation of erors.
There will then be a third critical value, close to but still below the rated throughput of the switch or router. Provided no errors occur, the traffic will flow smoothly and packet loss should not occur. This isn't entirely unlike superheating - particularly on collapse. Only a handful of retransmits would be required - and they could occur anywhere in the system for which this is merely one hop of many - to cause the traffic to suddenly exceed maximum throughput. Since the retransmitted packets will add to the existing flows, and since the increase in traffic will increase superlinearly, that node is effectively dead. If there's a way to redirect the traffic for dead nodes, there is then a high risk of cascading errors, where the failure will ripple out through the network, taking out router/switch after router/switch.
Does flow management work? Linux has a range of RED and BLUE implementions. Hold a contest at your local LUG or LAN Gamer's meets, to see who can set it up the best. Flow management also includes ECN. Have you switched that on yet? There's MTUs and window sizes to consider - default works fine most times, but do you understand those controls and when they should be used?
None of this stuff needs to be end-to-end unless it's endpoint-active (and only a handful of such protocols exist). It can all be done usefully anywhere in the network. I'll leave it as an exercise to the readership to identify any three specific methods and the specific places on the network they'd be useful on. Clues: Two, possibly all three, are described in detail in the Linux kernel help files. All of them have been covered by Slashdot. At least one is covered by the TCP/IP Drinking Game.
If you're in Blackburn, Lancashire, you have a 1:40,000 of finding a hole going to Australia. The rest are quantum entangled with strawberry fields.
That comes under License Extensions for Time Delta Shifting, Recursive Shifting and Spanish Inquisition Sketch Shifting, all of which must be paid for individually. Remember, every time you scratch a record without paying, an angel gets its wings and legs ripped off.
Ah! And the ones you hate, loath and despise, you exile to Canberra.