Certainl - for the main google index, for which the performance is needed. But the architecture for the Google Search Engine is not necessarily the architecture for GMail. The search engine needs a much higher mips-to-megabyte ratio than a mail storage app (even an indexed one). To provide this service, they will have to investigate each and every economy. Yes, tehy will have fantastic economies of scale, and they are well accustomed to using brute force to solve huge problems. But if the nature of the problem changes, the nature of the soution should chainge. Yes, of course they will use soft raid. But I would expect GMail to ahve a much higer ratio of disks to processors than the search engine, and therefore to make raid economical.
Do you have to change the sand? Just pour more water in. I wouldn't leave it too long, because bugs breed in stagnant water, but it should be OK tfor a few weeks. And sand is cheap.
Just think how many seti@home work units you could pump out a day with 100,000 nodes
Probably not that many. This cluster would be storage dominated not comput dominated. How many mips does it take to read email? Glever indexing is the Google way, not brute force. Obviously, there are some big indexers in there somewhere - but not dominant.
I think that is it. I think that they will be savin a lot of space byobserving common attachments and storing only one copy. If you stor only one copy of each spam, each pr0n binary, each family snap you send to 10 relatives, a lot of space is saved. Of course, they may have difficulty cleaning up each and every copy, so they may (unintentionally) hold a copy after all references have been deleted - which is what they are warning about. If identical attachments are shared, how many Mb do you actuall use with your virtual Gb?
Re:Google has AFAIK a wonderful track record
on
Speculating About Gmail
·
· Score: 3, Insightful
But they haven't shown any sign of trying to exploit it dangerously yet. And they haven't shown any signs of anti-competitive behaviour. The only lock-in method they use is the honourable one of providing a better service.
Google rose fast. If it misbehaved, it could fall fast. There are plenty of competitors waiting in the wings, some with plenty of budget (M$, Yahoo).
I think that we should give Google the benefit of the doubt - while keeping eyes wide open. Abuse of power occurs when people think they can get away with it, either because no-one is looking or because they cannot do anything about it if they are. The second case doesn't apply - we can all switch search engines, email hosts ets easily. We must avoid the first: keep an eagle eye on Google, but make it a friendly one.
Which would in turn require over 650 machines to stick them in (at 8 drives per node, itself probably a tad high since the bus would grind to a crawl in such a machine). All that adds up to at least half of a million dollars.
In that kind of quantlty I could do you a Raid controller driving, say, 128 drives, for about the cost of one machine. You need to Raid it anyway - you couldn't sau "sorry, we lost all your emails when on drive went down". I would bet that Google have some kind of economy raid controller in the works even if not yet deployed.
Bandwidth isn't the problem. How much bandwidth do you spend reading email? Most of that data will sit there unread for months.
Of course we are so far away from totally computer driven vehicles that I doubt I'll see it in my lifetime. But I can dream
I not only dream, I hope. I have just been through seeing my parents have to give up driving because of failing senses, and seen how drastically it cut down their personal freedom. Unless you live in a pretty urban area, a lot of the bits that make life interesting (as opposed to the routine ofe everyday) need cars.
I hope that, by the time I reach their age, there will be a totally computer controlled car. Not necessarily fast or long range, not with the capabilities of my current car. But one which will take mes, at perhaps 20 mph, to points of my choosing within a 10 mile radius. At the time of my choosing. Without my having to wait in the rain for it to arrive. With easy storage for my shopping. That I can leave my personal posessions in while visit several shops. So that I can listen to radio or music of my choice. So that I am not opressed by other peoples children, smelly drunks, obstreperous teenagers. That doesn't detour, stopping frequently, round every housine estate in the area. (I live 10 mins drive from town; the bus takes 40-60 mins to do the journey, and is 10 mins walk from the house).
I don't want speed, sex appeal, performance. I want transport optimised to my personal (nay, selfish) needs.
Note that none of these involved the main flight control systems. All involved subsidiary interlocks which will also be present on Boeing aircraft. For example, the first involved malfunction thrust reversers, part of the engine: made by a different manufacturer, and Boeing use engines from the same manufacturer. The third involved the interlock between sink rate and thrust reverser, also on Boeing.
One of my favourite "software induced" aircraft incidents involved the Boeing 747-400. For reasons that will become clear, it never caused an accident, but it shows the way in which interlocking simple systems can produce unexpected results.
On two or three occasions, while rumbling its way across the Atlantic at cruising altitude, one of these aircraft suddenly throttled back all four engines to flight idle. No danger at altitude, of course, and when the pilots commanded the engines back to cruise thrust, they resumed their duties normally. But worying - suppose this had happend just after takeoff? One engine out is planned for, but all four? The aircraft would crash.
Tot cut to the chase, the flaps have a sensor to tell the pilot whether they are deployed. If the flap deployment mechanism breaks, it is important that the pilot knows what the flap is actually in: accidents have happened because an actuator broke and the pilod didn't realis the flaps were not obeying his commands. So there is a feedback sensor which goes to an indicator on the fight deck: a separate circuit, not shared with anything else.
Such sensors have two protocols: a single-byte protocol, which is unchecked and will, therefore, give data errors in the event of a garble, and an eight byte checksummed packet, which will discard garbled packets and will never lie. It may delay the truth, but only til the next packet comes along, which is not vary long. Since this was only an indicator, and the pilot would probably not even notice if the flaps indicator flickered to an unexpected position for a fraction of a second every few hundred hours, they used the single byte protocol.
Then someone wired this into the autopilot, with the best of intentions. Flaps are used only for takoeff and landing. If flaps are deployed at cruise speed, they will be ripped off. So when the flap indicator reported, because of garbled data, that the flaps were down, the autopilot immediately tried to lose speed to stop the flaps being ripped off - not a good thing to happen. Of course, by the time the pilot intervened, the sensor had retransmitted good data and the autopilot was happy to resume normal service.
Of course, by definition this could not have happened at low speed, and thus could not have caused an accident. Switch to the eight byte protocol, and the problem goes away. But is shows how several changes, all made with the intention of increasing safety, can have the opposite effect. (See also Apollo 13).
And it happened on a Boeing, not an Airbus. In fact, I would argue that afull computerisation with an overview of the whole system is likely to be safer than piecemeal upgrading of individual subsystems. And all new Boeings are FBW.
Could you provide some form of referencce for this? Because is sounds very much like a garbled, misunderstood version of the actual facts.
Airbus aircraft always have been fly-by-wire, with a computer-style joystick instead of a traditional full-sized stick-and-yoke. Boeing is now also fly-by-wire, but keeps the big stick, which is now entirely electronically connected. There is no question of "early Airbuses being different" - on the contrary, Boeing have followed a path pioneered by Airbus.
Both systems normally fly the aircraft according the pilots commands. There is only a difference at the extreme edges of the envelope that they differ. The Boeing philosopy is that the pilot demands maximum nose-up, he gets it. The Aurbus philosopy is that if the pilot demands a nose-up that woukd cause the aircraft to stall, it will limit the pilots input to just before the stall. It will not "fight back" or try to counteract the pilot, it will jus clip his input to the edge of the pre-calculated envelope.
Thare have, as far as I know, been no examples of the kind of "software vs. computer" fight you describe. In fact, as far as I know there have been no examples of accidents directly attributable to fly-by-wire software from any manufacturers.
Where fly-by-wire has been associated with accidents, it has been because of overconfidence by the pilot. The pilot has assumed that the aircraft will not let him do anything wrong, and therefore entered extreme input believeing that the aircraft will keep him inside the envelope. True - in so far as the aircraft itself is concerned. But the computer cannot see outside. This has led to accidents where then aircraft has flown, under perfect control, into some ground or trees the computer could not possibly see.
While not causing these accidents, computer-induced overconfidence has been a factor in them. Aircraft designers are actively working on keeping the pilot in the loop and flying the aircraft with assistance, rather than being a supervisor who has to jump into action at an emergency. However, while we see these few accidents in which FBW has had a small influence, we don't see the accidents which didn't happen because FBW, working with the pilot, got the best possible performance out of the aircraft. Total air accidents per year are steady or falling slightly, while total flights and miles flown are rising steadily. Air travel is getting safer, and FBW has contributed to that.
A possible related precedent. A few years ago, Ford Europe ran an ad campaign which featured some genuine employees from their UK plant. Later, they decided to repeat the same ad campaign in Poland. Rather than take a new photograph, they used the old one. But, since Poland has very few ethnic minority workers, they retouched all the black and Indian employees to white. The stink which blew up was massive, and they had to back down and apologise grovellingly. Which suggests that someone thinks that you have some control of how images of your body are used, at least in an advertising context. (And what a stupid false economy it was using the old photo: the cost of taking a new photo with Polish employees would have been trivial).
I have heard of the nuclear landmines in a non-April 1st context before, so I think the underlying story is probably true. The idea is that there are some bottlenecks which an advancing Soviet force, particularly tanks, would have to pass through (bridges etc). Why send aircraft to bomb them at great risk when you could put the bomb in place at your lesiur. 10kt is not a particularly big nuke, anyway. I don't think the radiation part was intentional - it is the reason the idea got canned. If they had a "clean" bomb, they might still be there.
It goes along with thinking at the time: they were also training troops go hide as the battlefromt passed over them, the re-emerge to harrass the enemy rear and lines of communication.
The chickens, however, are probably someone's April Fool addition.
An interesting article, but on the other hand you can look at it the other way. Larry Wall developed perl because he was fed up with writing special pupose report analysers, and built a general purpose report-analyser-generator - which turned out to be mind-bogglingly useful for other things. But it is a good idea to avoid feature creep: there is always a tendency, if not resisted, to add global features to a quickie "just in case".
But the article was talking about a geograpically close-knit community. I write software fore spcialist machines used by a technically close-knit community. As such, my user interfaces can take advantage of their knoledge (for example, you can assume that a video editor can do timecode arithmetic). The trouble is the marketing droids don't have these skills, and try to force the UI to have features to make it iasy for them to use, rather than the end user. So they want every timecode box laden with calculating abilities, and boxes to show differences between timecodes etc. Lots of screen area, lots of niftiness - "look, I enter it here and it changes over there", but not much use. Luckily, my corporate culture allows me to fight back - "It's not for you, dummy, it's for " carries some weight. The problem sometimes comes with the customaer management, who pay the bill but are not themselves users. All you can ope is the users can control their management like I (sometimes) can mine.
I have never heard of a corporate legal department using or requiring a "development platform"
He didn't say he needed the development platform for the legal deparment. His "we" is speaking for the corporation, not the legal department. Presumably, Gizmos Inc, needing a new development platform for the next generation of gismos, asked their legal department for an opinion on the whole problem. If you have a legal department, it would be foolish not to use it.
And, being a lawyer, he gave the answer of maximum caution. Potential legal trouble from adopting Windows: Zero. Potential legal trouble from adopting Linux: possible, if unlikely: but very expensive if it occurs. On a cash basis, pay something for Mindows now is safer than risk company-busting lawsuit from a victorious SCO later. Management hate risk - they have enough they have to handle, without taking on avoisable risk. And on a technical basis... when did lawyers ever worry about technical problems? Let the geeks suffer.
The word "nanotechnology" spans two competely different fields: nanomachines and nanomaterials.
Nanomaterials is what this article is about. The whole field of nanomaterials is exploitng the fact that extremely small particles of materials show physico-chemical behaviour different from that shown at larger scales. Not that the laws of pysics change as some people have said, but that tiny size has an effect upon which laws manifest. Some of those changes are useful - which is why people are researching them. Some are, surprise surprise, dangerous. You get that with any new invention - fire destroys as well as warms.
Nanomaterials are here, now. We need to worry about them like any other new chemical (which, in a way, is what they are - on the boundaries of chemistry and materials physics). But not more. Of course they should be tested - and guess what, they are, as this article shows. No more (or less) of a risk than any of the hundreds of new chemicals which emerge every year. Move along, folks, nothing to see here.
Nanomachines are a totally different question. Nanomachines are extremely tiny machines build up either from molecules, or by using silicon engineering developed for microchips to machine silicon (actually two very different technologies lumped together, but so be it). Apart from a few very crude devices, nanomachines are still a long way from any serious production.
People have hypothesized that it might be possible to build self-replicating nanomachines, and that such self-replicationg nanomachines might replicate so fast as to take over the world and reduce it to "grey goo". While you cannot say that this is absolutely impossible, it is very, very far ahead of anything even dreamed off. While a few useful widgets might emerge in the next few years, such gadgets are orders of magnitude away from anything presenting a serious risk to people at large.
(And, actually, I believe we already have self-replicating nanomachines: they are called viruses).
But, because of the confusion of the two terminologies, people are saying "Panic about what nanomachines might do because nanomaterials are here now".
I don't agree. An eventuality occurred which the original software designers hadn't thought of. This happens all the time in embedded systems - the world is not only more complicated than we think, it is more complicated than we can think.
This failure required two failures in a row - one human, one software. After this failure, both systems will be fixed, so this failure won't happen again on this system. Furthermore, it won't happen again on any system those involved in cleaning up work on - we learn by our mistakes. Unfortunately, because they appear to be going to keep the details secret, none of the rest of us will have chance to learn from their mistakes.
This is nothing to do with monopolies. Any man-made system will hav failures. But it does have a bit to do with open/closed: if the system were open source, those interested would see the fixes even if they dsidn't get a complete report (which they paobaly would). "Many eyballs" would have made this failure less likely (though not impossible). A case for wanting open source in safety criticasl software: maximise the clooegiate understanding.
Well, Chernobyl blew its 12 foot thick reinforced concrete lid far enough into the air to flip over. And all that heat has to go somewhere - you'd probably end up with a local volcano.
Then, when it all cools down, groundwater will get into it and spread radiation throughout the watershed. If it didn't boil of as radioactive steam first. Think of the problems if a reactor in the upper reaches of the Missouri explodes, and radioactive water contaminates the whole Mississippi-Missouri water system. Not fun.
Sure - when it happens. And yes, Iter is the next step on the way, and will show the technical possibility of fusion with net energy output. But it is a long, long way from showing the commercial feasability. It is going to be a long time before we have fusion power - and it is always possible that we will discover some barrier which means it will never be commercially feasible.
On the point of making nuclear power stations safe, I agree with you. There are some designs around not for which the worst credible accident is really not that bad at all.
But there is still the waste disposal problem. Until we have a solution for the disposal of the higher-level waste that is in place and shown to be working, I for one will not be supporting nuclear powery.
I parsonally am not happy with long term repositories such as Yucca Mountain - too many unknowns. My favoured version was the subduction zone disposal - return it to the earth's core, which is used to it. Does anybody know why this disappeared off the map?
HDTV is not automatically 1080i - there are a whole slew of possible HD formats, and different broadcasters are picking different ones. The only one I know of going to full HD production is going to use 720i. I think there are 14 allowable slots in the matrix of standards, and people are taling about using most of them - and, apparently, Australia is going for a fifteenth.
atheism, [is] about not *believing* in God, NOT believing there isn't a God.
Very much agreed. I would like to label the second one, the assertion that there isn't and cannot be a God, "antitheism". An atheist just finds the hypothesis that God exists, for all known values of God, less convincing than the null hypothesis, that there is no God.
Why should one not swap out program and data structures that one is not using, and free up ram for high-turnover uses such as disk caching? Given that disk space is cheap and the page swapping system exists, you might as well make use of it. I agree that, if one were developing a new OS with todays hardware, it is arguable that you shouldn't bother with a swapping mechanism (though the inifinite ability of people to use up processor power makes me doubt this). But since we have the swapping mechanism, you can effectively buy $100 worth of extra ram for about $5 (the cost of the disk space). Sounds a good deal to me.
Slashdot Mirror
Certainl - for the main google index, for which the performance is needed. But the architecture for the Google Search Engine is not necessarily the architecture for GMail. The search engine needs a much higher mips-to-megabyte ratio than a mail storage app (even an indexed one). To provide this service, they will have to investigate each and every economy. Yes, tehy will have fantastic economies of scale, and they are well accustomed to using brute force to solve huge problems. But if the nature of the problem changes, the nature of the soution should chainge. Yes, of course they will use soft raid. But I would expect GMail to ahve a much higer ratio of disks to processors than the search engine, and therefore to make raid economical.
Do you have to change the sand? Just pour more water in. I wouldn't leave it too long, because bugs breed in stagnant water, but it should be OK tfor a few weeks. And sand is cheap.
Just think how many seti@home work units you could pump out a day with 100,000 nodes
Probably not that many. This cluster would be storage dominated not comput dominated. How many mips does it take to read email? Glever indexing is the Google way, not brute force. Obviously, there are some big indexers in there somewhere - but not dominant.
I think that is it. I think that they will be savin a lot of space byobserving common attachments and storing only one copy. If you stor only one copy of each spam, each pr0n binary, each family snap you send to 10 relatives, a lot of space is saved. Of course, they may have difficulty cleaning up each and every copy, so they may (unintentionally) hold a copy after all references have been deleted - which is what they are warning about. If identical attachments are shared, how many Mb do you actuall use with your virtual Gb?
But they haven't shown any sign of trying to exploit it dangerously yet. And they haven't shown any signs of anti-competitive behaviour. The only lock-in method they use is the honourable one of providing a better service.
Google rose fast. If it misbehaved, it could fall fast. There are plenty of competitors waiting in the wings, some with plenty of budget (M$, Yahoo).
I think that we should give Google the benefit of the doubt - while keeping eyes wide open. Abuse of power occurs when people think they can get away with it, either because no-one is looking or because they cannot do anything about it if they are. The second case doesn't apply - we can all switch search engines, email hosts ets easily. We must avoid the first: keep an eagle eye on Google, but make it a friendly one.
Which would in turn require over 650 machines to stick them in (at 8 drives per node, itself probably a tad high since the bus would grind to a crawl in such a machine). All that adds up to at least half of a million dollars.
In that kind of quantlty I could do you a Raid controller driving, say, 128 drives, for about the cost of one machine. You need to Raid it anyway - you couldn't sau "sorry, we lost all your emails when on drive went down". I would bet that Google have some kind of economy raid controller in the works even if not yet deployed.
Bandwidth isn't the problem. How much bandwidth do you spend reading email? Most of that data will sit there unread for months.
Of course we are so far away from totally computer driven vehicles that I doubt I'll see it in my lifetime. But I can dream
I not only dream, I hope. I have just been through seeing my parents have to give up driving because of failing senses, and seen how drastically it cut down their personal freedom. Unless you live in a pretty urban area, a lot of the bits that make life interesting (as opposed to the routine ofe everyday) need cars.
I hope that, by the time I reach their age, there will be a totally computer controlled car. Not necessarily fast or long range, not with the capabilities of my current car. But one which will take mes, at perhaps 20 mph, to points of my choosing within a 10 mile radius. At the time of my choosing. Without my having to wait in the rain for it to arrive. With easy storage for my shopping. That I can leave my personal posessions in while visit several shops. So that I can listen to radio or music of my choice. So that I am not opressed by other peoples children, smelly drunks, obstreperous teenagers. That doesn't detour, stopping frequently, round every housine estate in the area. (I live 10 mins drive from town; the bus takes 40-60 mins to do the journey, and is 10 mins walk from the house).
I don't want speed, sex appeal, performance. I want transport optimised to my personal (nay, selfish) needs.
Note that none of these involved the main flight control systems. All involved subsidiary interlocks which will also be present on Boeing aircraft. For example, the first involved malfunction thrust reversers, part of the engine: made by a different manufacturer, and Boeing use engines from the same manufacturer. The third involved the interlock between sink rate and thrust reverser, also on Boeing.
One of my favourite "software induced" aircraft incidents involved the Boeing 747-400. For reasons that will become clear, it never caused an accident, but it shows the way in which interlocking simple systems can produce unexpected results.
On two or three occasions, while rumbling its way across the Atlantic at cruising altitude, one of these aircraft suddenly throttled back all four engines to flight idle. No danger at altitude, of course, and when the pilots commanded the engines back to cruise thrust, they resumed their duties normally. But worying - suppose this had happend just after takeoff? One engine out is planned for, but all four? The aircraft would crash.
Tot cut to the chase, the flaps have a sensor to tell the pilot whether they are deployed. If the flap deployment mechanism breaks, it is important that the pilot knows what the flap is actually in: accidents have happened because an actuator broke and the pilod didn't realis the flaps were not obeying his commands. So there is a feedback sensor which goes to an indicator on the fight deck: a separate circuit, not shared with anything else.
Such sensors have two protocols: a single-byte protocol, which is unchecked and will, therefore, give data errors in the event of a garble, and an eight byte checksummed packet, which will discard garbled packets and will never lie. It may delay the truth, but only til the next packet comes along, which is not vary long. Since this was only an indicator, and the pilot would probably not even notice if the flaps indicator flickered to an unexpected position for a fraction of a second every few hundred hours, they used the single byte protocol.
Then someone wired this into the autopilot, with the best of intentions. Flaps are used only for takoeff and landing. If flaps are deployed at cruise speed, they will be ripped off. So when the flap indicator reported, because of garbled data, that the flaps were down, the autopilot immediately tried to lose speed to stop the flaps being ripped off - not a good thing to happen. Of course, by the time the pilot intervened, the sensor had retransmitted good data and the autopilot was happy to resume normal service.
Of course, by definition this could not have happened at low speed, and thus could not have caused an accident. Switch to the eight byte protocol, and the problem goes away. But is shows how several changes, all made with the intention of increasing safety, can have the opposite effect. (See also Apollo 13).
And it happened on a Boeing, not an Airbus. In fact, I would argue that afull computerisation with an overview of the whole system is likely to be safer than piecemeal upgrading of individual subsystems. And all new Boeings are FBW.
Could you provide some form of referencce for this? Because is sounds very much like a garbled, misunderstood version of the actual facts.
Airbus aircraft always have been fly-by-wire, with a computer-style joystick instead of a traditional full-sized stick-and-yoke. Boeing is now also fly-by-wire, but keeps the big stick, which is now entirely electronically connected. There is no question of "early Airbuses being different" - on the contrary, Boeing have followed a path pioneered by Airbus.
Both systems normally fly the aircraft according the pilots commands. There is only a difference at the extreme edges of the envelope that they differ. The Boeing philosopy is that the pilot demands maximum nose-up, he gets it. The Aurbus philosopy is that if the pilot demands a nose-up that woukd cause the aircraft to stall, it will limit the pilots input to just before the stall. It will not "fight back" or try to counteract the pilot, it will jus clip his input to the edge of the pre-calculated envelope.
Thare have, as far as I know, been no examples of the kind of "software vs. computer" fight you describe. In fact, as far as I know there have been no examples of accidents directly attributable to fly-by-wire software from any manufacturers.
Where fly-by-wire has been associated with accidents, it has been because of overconfidence by the pilot. The pilot has assumed that the aircraft will not let him do anything wrong, and therefore entered extreme input believeing that the aircraft will keep him inside the envelope. True - in so far as the aircraft itself is concerned. But the computer cannot see outside. This has led to accidents where then aircraft has flown, under perfect control, into some ground or trees the computer could not possibly see.
While not causing these accidents, computer-induced overconfidence has been a factor in them. Aircraft designers are actively working on keeping the pilot in the loop and flying the aircraft with assistance, rather than being a supervisor who has to jump into action at an emergency. However, while we see these few accidents in which FBW has had a small influence, we don't see the accidents which didn't happen because FBW, working with the pilot, got the best possible performance out of the aircraft. Total air accidents per year are steady or falling slightly, while total flights and miles flown are rising steadily. Air travel is getting safer, and FBW has contributed to that.
Well you can see where Goolge got the colour scheme for their logo. It is just the colours of the Lego bricks.
A possible related precedent. A few years ago, Ford Europe ran an ad campaign which featured some genuine employees from their UK plant. Later, they decided to repeat the same ad campaign in Poland. Rather than take a new photograph, they used the old one. But, since Poland has very few ethnic minority workers, they retouched all the black and Indian employees to white. The stink which blew up was massive, and they had to back down and apologise grovellingly. Which suggests that someone thinks that you have some control of how images of your body are used, at least in an advertising context. (And what a stupid false economy it was using the old photo: the cost of taking a new photo with Polish employees would have been trivial).
I have heard of the nuclear landmines in a non-April 1st context before, so I think the underlying story is probably true. The idea is that there are some bottlenecks which an advancing Soviet force, particularly tanks, would have to pass through (bridges etc). Why send aircraft to bomb them at great risk when you could put the bomb in place at your lesiur. 10kt is not a particularly big nuke, anyway. I don't think the radiation part was intentional - it is the reason the idea got canned. If they had a "clean" bomb, they might still be there.
It goes along with thinking at the time: they were also training troops go hide as the battlefromt passed over them, the re-emerge to harrass the enemy rear and lines of communication.
The chickens, however, are probably someone's April Fool addition.
An interesting article, but on the other hand you can look at it the other way. Larry Wall developed perl because he was fed up with writing special pupose report analysers, and built a general purpose report-analyser-generator - which turned out to be mind-bogglingly useful for other things. But it is a good idea to avoid feature creep: there is always a tendency, if not resisted, to add global features to a quickie "just in case".
But the article was talking about a geograpically close-knit community. I write software fore spcialist machines used by a technically close-knit community. As such, my user interfaces can take advantage of their knoledge (for example, you can assume that a video editor can do timecode arithmetic). The trouble is the marketing droids don't have these skills, and try to force the UI to have features to make it iasy for them to use, rather than the end user. So they want every timecode box laden with calculating abilities, and boxes to show differences between timecodes etc. Lots of screen area, lots of niftiness - "look, I enter it here and it changes over there", but not much use. Luckily, my corporate culture allows me to fight back - "It's not for you, dummy, it's for " carries some weight. The problem sometimes comes with the customaer management, who pay the bill but are not themselves users. All you can ope is the users can control their management like I (sometimes) can mine.
I have never heard of a corporate legal department using or requiring a "development platform"
He didn't say he needed the development platform for the legal deparment. His "we" is speaking for the corporation, not the legal department. Presumably, Gizmos Inc, needing a new development platform for the next generation of gismos, asked their legal department for an opinion on the whole problem. If you have a legal department, it would be foolish not to use it.
And, being a lawyer, he gave the answer of maximum caution. Potential legal trouble from adopting Windows: Zero. Potential legal trouble from adopting Linux: possible, if unlikely: but very expensive if it occurs. On a cash basis, pay something for Mindows now is safer than risk company-busting lawsuit from a victorious SCO later. Management hate risk - they have enough they have to handle, without taking on avoisable risk. And on a technical basis... when did lawyers ever worry about technical problems? Let the geeks suffer.
The word "nanotechnology" spans two competely different fields: nanomachines and nanomaterials.
Nanomaterials is what this article is about. The whole field of nanomaterials is exploitng the fact that extremely small particles of materials show physico-chemical behaviour different from that shown at larger scales. Not that the laws of pysics change as some people have said, but that tiny size has an effect upon which laws manifest. Some of those changes are useful - which is why people are researching them. Some are, surprise surprise, dangerous. You get that with any new invention - fire destroys as well as warms.
Nanomaterials are here, now. We need to worry about them like any other new chemical (which, in a way, is what they are - on the boundaries of chemistry and materials physics). But not more. Of course they should be tested - and guess what, they are, as this article shows. No more (or less) of a risk than any of the hundreds of new chemicals which emerge every year. Move along, folks, nothing to see here.
Nanomachines are a totally different question. Nanomachines are extremely tiny machines build up either from molecules, or by using silicon engineering developed for microchips to machine silicon (actually two very different technologies lumped together, but so be it). Apart from a few very crude devices, nanomachines are still a long way from any serious production.
People have hypothesized that it might be possible to build self-replicating nanomachines, and that such self-replicationg nanomachines might replicate so fast as to take over the world and reduce it to "grey goo". While you cannot say that this is absolutely impossible, it is very, very far ahead of anything even dreamed off. While a few useful widgets might emerge in the next few years, such gadgets are orders of magnitude away from anything presenting a serious risk to people at large.
(And, actually, I believe we already have self-replicating nanomachines: they are called viruses).
But, because of the confusion of the two terminologies, people are saying "Panic about what nanomachines might do because nanomaterials are here now".
I don't agree. An eventuality occurred which the original software designers hadn't thought of. This happens all the time in embedded systems - the world is not only more complicated than we think, it is more complicated than we can think.
This failure required two failures in a row - one human, one software. After this failure, both systems will be fixed, so this failure won't happen again on this system. Furthermore, it won't happen again on any system those involved in cleaning up work on - we learn by our mistakes. Unfortunately, because they appear to be going to keep the details secret, none of the rest of us will have chance to learn from their mistakes.
This is nothing to do with monopolies. Any man-made system will hav failures. But it does have a bit to do with open/closed: if the system were open source, those interested would see the fixes even if they dsidn't get a complete report (which they paobaly would). "Many eyballs" would have made this failure less likely (though not impossible). A case for wanting open source in safety criticasl software: maximise the clooegiate understanding.
It also could drastically cut the time of commercial flights -- perhaps shortening the trip between New York and London to less than five hours.
Considering Concorde did that in three hours, thit wouldn't be much achievement. I make it that it could do NY-LON in just over one hour.
What I think they should have said is that it could go from any point on the earth to any other, including the antipodes, in less than five hours.
Mind you, it would take three hours to get through security on departure and an hour on arrival to collect your baggage, if it had arrived with you.
Well, Chernobyl blew its 12 foot thick reinforced concrete lid far enough into the air to flip over. And all that heat has to go somewhere - you'd probably end up with a local volcano.
Then, when it all cools down, groundwater will get into it and spread radiation throughout the watershed. If it didn't boil of as radioactive steam first. Think of the problems if a reactor in the upper reaches of the Missouri explodes, and radioactive water contaminates the whole Mississippi-Missouri water system. Not fun.
Sure - when it happens. And yes, Iter is the next step on the way, and will show the technical possibility of fusion with net energy output. But it is a long, long way from showing the commercial feasability. It is going to be a long time before we have fusion power - and it is always possible that we will discover some barrier which means it will never be commercially feasible.
On the point of making nuclear power stations safe, I agree with you. There are some designs around not for which the worst credible accident is really not that bad at all.
But there is still the waste disposal problem. Until we have a solution for the disposal of the higher-level waste that is in place and shown to be working, I for one will not be supporting nuclear powery.
I parsonally am not happy with long term repositories such as Yucca Mountain - too many unknowns. My favoured version was the subduction zone disposal - return it to the earth's core, which is used to it. Does anybody know why this disappeared off the map?
I was referring to going 720p 16x9. It looks as if they are going to be the first with significant amounts of native HD instead of up-rezzed SD.
HDTV is not automatically 1080i - there are a whole slew of possible HD formats, and different broadcasters are picking different ones. The only one I know of going to full HD production is going to use 720i. I think there are 14 allowable slots in the matrix of standards, and people are taling about using most of them - and, apparently, Australia is going for a fifteenth.
Since it was a French system:
Systeme Expensive Contre les AMericains
atheism, [is] about not *believing* in God, NOT believing there isn't a God.
Very much agreed. I would like to label the second one, the assertion that there isn't and cannot be a God, "antitheism". An atheist just finds the hypothesis that God exists, for all known values of God, less convincing than the null hypothesis, that there is no God.
Why should one not swap out program and data structures that one is not using, and free up ram for high-turnover uses such as disk caching? Given that disk space is cheap and the page swapping system exists, you might as well make use of it. I agree that, if one were developing a new OS with todays hardware, it is arguable that you shouldn't bother with a swapping mechanism (though the inifinite ability of people to use up processor power makes me doubt this). But since we have the swapping mechanism, you can effectively buy $100 worth of extra ram for about $5 (the cost of the disk space). Sounds a good deal to me.