"Funny, I thought I heard that as of yesterday the batteries on the lander would have been depleted unless the lander had received an order to recharge its batteries."
I can't find any reference to this except here. Is someone trying to start an urban myth?
The important thing is getting both feet off the floor at the same time. It requires a far more complex balance control system than the "move one foot, rebalance, tilt, move other foot" that robot walking has been doing for a while.
If you use proprietary software the danger is that it gets discontinued.
Then you are stuck with an unsupported legacy system that you can't support at all
Competition in the proprietary market means that you have to bet on a product and if the provider goes under you (at best) get left with a load of crappy, undocumented escrowed code that often won't even build.
Alternatively you buy a product and the provider "discontinues support" so that you get hung up for a big upgrade (usually with a shed load of license costs to go with it).
For equivalently functional products (for my project's needs) I'll take OSS as a risk mitigation measure every time.
Dan Ingals has built a neat linux/squeak based system on ITX.
"We have now assembled a software kernel that includes a lean Linux base (modified by Ian Piumarta to provide direct frame buffer display), and a full Squeak 3.6 image and VM, all fitting on a 32M CF card with about 10MB left over. For my needs this is an ideal solution: buy a Silent Station, stick in a CF card, and resell it as a graphical weather station. It's especially nice that the Silent Station uses a 12v supply, which means you can hack together a 5-hour UPS from a lead-acid battery and a trickle charge circuit."
The reason they haven't done this is that the imposition of a frequent, hard, driving test would be more expensive, harder to implement and politically far more unpopular than more automatic monitoring.
Therefore, it ain't going to happen.
The spy-in-the-car will either fall at the first hurdle or people will just accept it.
Also IIRC HUD technology is a lot more sophisticated than simply sticking a clear screen in between you and the outside world. The optics in a HUD tweak the image to make it appear to come 'from infinity' so that your eyes can focus on it at the same time as focusing on the view outside.
Tom
Watson-Watt invented it, Loomis enhanced it
on
Tuxedo Park
·
· Score: 3, Interesting
"Watson-Watt became the superintendent of the radio division of the National Physics Laboratory in Teddington. In 1936 his radio stations were able to detect aircraft up to 70 miles away."
"He persuaded the government to set up a network of radar stations to provide early warning of aircraft attacking over the English Channel. "Radar" was short for "radio detecting and ranging." It was due to radar that the over-stretched resources of the RAF were able to be in the right place at the right time as Luftwaffe aircraft streamed over during the Battle of Britain from August to October 1940. The Germans could not understand why the defending aircraft (such as the Spitfire, illustrated above) were so often there to meet them."
"In the 1930s, British scientists were at the cutting edge of radar technology. While crude by modern standards, their systems could spot Nazi bombers up to 150 miles from the English coast, enough of a warning for Royal Air Force fighters to intercept them. But the radar apparatus was too bulky to mount in planes, and the equipment was not sensitive enough to detect a U-boat's periscope. That changed in early 1940, when physicists at the University of Birmingham invented the magnetron. This plump copper disk was only four inches across, but its glass horns emitted short-wavelength pulses of extremely high power--just the ticket for small radars that could probe much farther and resolve details far finer than any previous system."
"When Prime Minister Winston Churchill learned of the magnetron, he sensed that it marked a turning point in the war. Given the state of British industry, though, he needed U.S. help in refining the magnetron and, most of all, producing them in volume. That August, he sent a mission to Washington, where it presented a top-secret magnetron to astonished U.S. researchers."
Jython can, so can Bistro, hell I expect more can than can't.
They'll only have two languages each
on
The Future of Java?
·
· Score: 2, Interesting
The JVM supports loads of languages and so does the CLR. But who cares? People will develop, almost exclusively, in C# and VB on the CLR and people will develop, almost exclusively, in Java (and a scripting language, Jython I hope) on the JVM.
All the rest are side shows.
The JVM is cross platform now. The CLR might be, but might not (I'll believe it when its running on PalmOs and Symbian, not just Linux and BSD).
The sad thing is that, as the condom information permeates through the population, the message will end up as "condoms aren't any use" and a load of teens won't bother with them (amazingly they'll still have sex) and infection and pregnancy rates will go up.
Tom
We don't know enough to do software engineering yet. If materials in the physical world were as poorly understood, and changed as fast as they do in the software world they couldn't do it there either.
If requirements were as poorly understood and changed as fast in the physical world as they do in the software world construction would cost a fortune and most big buildings would never get finished (or would never be fit for purpose).
People who say things like "Make sure the requirements don't change" are living in a fantasy world where they want to blame their inability to deliver on someone else.
The rules haven't changed, get a high quality small team, get good access to a user who knows what they want and grow a system from small beginnings, checking at each stage that it all works and that quality is high.
Its all there in Brooks.
Its no surprise that the guys pushing the agile methodologies were all very succesful designers and developers anyway.
If you are interested in the AI implications try David B. Fogel's "Blondie24: Playing at the Edge of AI instead".
Blondie24 taught itself to play checkers using an evolutionary approach developed by Fogel. While it was never as good as the specialist programs like Chinook it was a better player than its creator.
Unlike DeepBlue Blondie24 was not given any game specific code and it still managed to be one of the best players around. I believe DeepBlue had predefined strategies coded in and a database of thousands of end games (but I may be wrong).
Will people stop spouting off about needing production line reliability in software development.
The software equivalent of car manufacturing is stamping a CD. It's very reliable. What software developers do is design, not manufacture.
The problem is that they ship half baked and unfinished designs (that they call products) without really thorough testing and refinement.
Have a look at the concept cars from an automobile design shop. How reliable and safe do you think they are? Its only after a couple of years of prototyping and testing that they have a design that they would risk manufacturing.
The problems with software stem from manufacture being too easy, not too hard.
Its true you won't find many jobs writing linked lists these days (Who wants to?!?) but you aren't confined to admin jobs. I wouldn't know where to start coding a scheduler but I'm not quite at the Access and ASP level yet.
The hard problem in in house software development isn't the coding (well, sometimes it is) its understanding the problem you are trying to solve and implementing solutions. These are untidy, people generated business problems and I think that puts a lot of geeks off.
I code for a living and I make good money solving hard problems because I understand the domain, have analyis and design skills and get on with the client.
(and I'm over forty, so there is still hope for most of you)
look at http://www.solarbuzz.com/FastFactsGermany.htm
It's stats are:
German Energy and Electricity Industry German domestic energy sources in 1998 were: Coal: 46%, Nuclear power: 31%, Natural Gas: 14%, Renewable Energy: 6% Oil: 3%. In consumption terms, though, oil accounted for 44%
Basically, if you want it for the same task you bought it for and you run the same environment, it will work forever.
If you want to run an old car you can always take it to an independant garage or fix it yourself, if you can be botherered to learn the skills. Wouldn't it be nice if software was like that...
Slashdot Mirror
The story of the program is partially corroborated here:
Though there is no information about the explosion.
Margaret Attwood doesn't write science fiction. When asked she said:
"No, it certainly isn't science fiction. Science fiction is filled with Martians and space travel to other planets, and things like that.".
She cannot risk it being science fiction because it won't be accepted as 'real' literature.
"Funny, I thought I heard that as of yesterday the batteries on the lander would have been depleted unless the lander had received an order to recharge its batteries."
I can't find any reference to this except here. Is someone trying to start an urban myth?
The important thing is getting both feet off the floor at the same time. It requires a far more complex balance control system than the "move one foot, rebalance, tilt, move other foot" that robot walking has been doing for a while.
Hats off to Sony
If you use proprietary software the danger is that it gets discontinued.
Then you are stuck with an unsupported legacy system that you can't support at all
Competition in the proprietary market means that you have to bet on a product and if the provider goes under you (at best) get left with a load of crappy, undocumented escrowed code that often won't even build.
Alternatively you buy a product and the provider "discontinues support" so that you get hung up for a big upgrade (usually with a shed load of license costs to go with it).
For equivalently functional products (for my project's needs) I'll take OSS as a risk mitigation measure every time.
Dan Ingals has built a neat linux/squeak based system on ITX.
"We have now assembled a software kernel that includes a lean Linux base (modified by Ian Piumarta to provide direct frame buffer display), and a full Squeak 3.6 image and VM, all fitting on a 32M CF card with about 10MB left over. For my needs this is an ideal solution: buy a Silent Station, stick in a CF card, and resell it as a graphical weather station. It's especially nice that the Silent Station uses a 12v supply, which means you can hack together a 5-hour UPS from a lead-acid battery and a trickle charge circuit."
The reason they haven't done this is that the imposition of a frequent, hard, driving test would be more expensive, harder to implement and politically far more unpopular than more automatic monitoring.
Therefore, it ain't going to happen.
The spy-in-the-car will either fall at the first hurdle or people will just accept it.
Tom
Boiled frog anyone?
Yes, yes, its gDesklets.
I notice python is the scripting language for Karamba events and it looks like gDoclets is written in it.
Cool
Also IIRC HUD technology is a lot more sophisticated than simply sticking a clear screen in between you and the outside world. The optics in a HUD tweak the image to make it appear to come 'from infinity' so that your eyes can focus on it at the same time as focusing on the view outside.
Tom
Watson-Watt Invented it
"Watson-Watt became the superintendent of the radio division of the National Physics Laboratory in Teddington. In 1936 his radio stations were able to detect aircraft up to 70 miles away."
"He persuaded the government to set up a network of radar stations to provide early warning of aircraft attacking over the English Channel. "Radar" was short for "radio detecting and ranging." It was due to radar that the over-stretched resources of the RAF were able to be in the right place at the right time as Luftwaffe aircraft streamed over during the Battle of Britain from August to October 1940. The Germans could not understand why the defending aircraft (such as the Spitfire, illustrated above) were so often there to meet them."
Loomis helped mass produce it for mobile use and developed it
"In the 1930s, British scientists were at the cutting edge of radar technology. While crude by modern standards, their systems could spot Nazi bombers up to 150 miles from the English coast, enough of a warning for Royal Air Force fighters to intercept them. But the radar apparatus was too bulky to mount in planes, and the equipment was not sensitive enough to detect a U-boat's periscope. That changed in early 1940, when physicists at the University of Birmingham invented the magnetron. This plump copper disk was only four inches across, but its glass horns emitted short-wavelength pulses of extremely high power--just the ticket for small radars that could probe much farther and resolve details far finer than any previous system."
"When Prime Minister Winston Churchill learned of the magnetron, he sensed that it marked a turning point in the war. Given the state of British industry, though, he needed U.S. help in refining the magnetron and, most of all, producing them in volume. That August, he sent a mission to Washington, where it presented a top-secret magnetron to astonished U.S. researchers."
So, as usual, a joint effort.
BigTom
Jython can, so can Bistro, hell I expect more can than can't.
The JVM supports loads of languages and so does the CLR. But who cares? People will develop, almost exclusively, in C# and VB on the CLR and people will develop, almost exclusively, in Java (and a scripting language, Jython I hope) on the JVM.
All the rest are side shows.
The JVM is cross platform now. The CLR might be, but might not (I'll believe it when its running on PalmOs and Symbian, not just Linux and BSD).
BigTom
The sad thing is that, as the condom information permeates through the population, the message will end up as "condoms aren't any use" and a load of teens won't bother with them (amazingly they'll still have sex) and infection and pregnancy rates will go up. Tom
We don't know enough to do software engineering yet. If materials in the physical world were as poorly understood, and changed as fast as they do in the software world they couldn't do it there either.
If requirements were as poorly understood and changed as fast in the physical world as they do in the software world construction would cost a fortune and most big buildings would never get finished (or would never be fit for purpose).
People who say things like "Make sure the requirements don't change" are living in a fantasy world where they want to blame their inability to deliver on someone else.
The rules haven't changed, get a high quality small team, get good access to a user who knows what they want and grow a system from small beginnings, checking at each stage that it all works and that quality is high.
Its all there in Brooks.
Its no surprise that the guys pushing the agile methodologies were all very succesful designers and developers anyway.
If you are interested in the AI implications try David B. Fogel's "Blondie24: Playing at the Edge of AI instead".
Blondie24 taught itself to play checkers using an evolutionary approach developed by Fogel. While it was never as good as the specialist programs like Chinook it was a better player than its creator.
Unlike DeepBlue Blondie24 was not given any game specific code and it still managed to be one of the best players around. I believe DeepBlue had predefined strategies coded in and a database of thousands of end games (but I may be wrong).
Tom
Erm,
Here I am, in the City, in my Oxford Shirt and Chinos (I sometimes have to pretend to be a manager).
I'm looking across the office at, say, 50 developers, none of whom have a tie (I'd say only about 25% have a collar).
(same in the last 4 banks I worked in)
Will people stop spouting off about needing production line reliability in software development.
The software equivalent of car manufacturing is stamping a CD. It's very reliable. What software developers do is design, not manufacture.
The problem is that they ship half baked and unfinished designs (that they call products) without really thorough testing and refinement.
Have a look at the concept cars from an automobile design shop. How reliable and safe do you think they are? Its only after a couple of years of prototyping and testing that they have a design that they would risk manufacturing.
The problems with software stem from manufacture being too easy, not too hard.
Sounds like one.
Do you have any references?
I take it the guys who build F1 race cars aren't engineers as they are constantly changing and redesigning components.
Oh yes, the "tin benders" who built the X planes during the 50s and 60s cannot have been either.
Bridgebuilding... Sheeesh!
Its true you won't find many jobs writing linked lists these days (Who wants to?!?) but you aren't confined to admin jobs. I wouldn't know where to start coding a scheduler but I'm not quite at the Access and ASP level yet.
The hard problem in in house software development isn't the coding (well, sometimes it is) its understanding the problem you are trying to solve and implementing solutions. These are untidy, people generated business problems and I think that puts a lot of geeks off.
I code for a living and I make good money solving hard problems because I understand the domain, have analyis and design skills and get on with the client.
(and I'm over forty, so there is still hope for most of you)
look at http://www.solarbuzz.com/FastFactsGermany.htm
It's stats are:
German Energy and Electricity Industry German domestic energy sources in 1998 were:
Coal: 46%,
Nuclear power: 31%,
Natural Gas: 14%,
Renewable Energy: 6%
Oil: 3%.
In consumption terms, though, oil accounted for 44%
So, are you going to volunteer to be the first noble carrier of smallpox back into the wild?
Or is it only Third World scourges you want to protect.
Nor does it wear out.
Basically, if you want it for the same task you bought it for and you run the same environment, it will work forever.
If you want to run an old car you can always take it to an independant garage or fix it yourself, if you can be botherered to learn the skills. Wouldn't it be nice if software was like that...
I hope they gave it its correct attribution "Bored of the Rings" by National Lampoon