Keanu has his own style and put everything he had into that movie
Yep, and that's the problem, really.
Troll, I know, but please ppl, face facts - Keanu Reeves' best work was Bill and Ted, a movie in which the main requirement was to act badly but look cool. A job which he did well, for the same reason that Hervé Villechaize was good at being short.
Actually, most realtime systems do use interrupts. They're the best way of getting multi-rate processing done - for instance, there's no need to check the ambient air temperature faster than maybe every 100ms, bcos it doesn't change that fast, but calculations of engine fuelling required need to be done at the millisecond kind of timing. To do this, you split your code into stuff running at separate task rates. Interrupts ensure that more important tasks interrupt less important tasks. Every engine controller uses this system.
Of course, you don't want interrupts to screw your data. To this end, your RTOS ensures that every task has a separate stack or that the lower-priority task's registers are pushed and popped during interrupts, and you have to design your code to take account of interrupts. For example, if a low-priority task sets a bit-field to zero and then fills in each bit one at a time, a high-priority task mustn't read that bit-field bcos it may read the value before the low-priority task has finished filling in all the bits. Embedded code has its own sets of challenges which you don't usually see in the desktop world.
Incidentally, the "relatively simple" embedded system is no longer simple. In order to meet ever-tighter emissions controls and get better performance and mileage from the same engine, the processing is *seriously* complex. On my current project at work, we're currently using a 32-bit processor with floating-point support running at 32MHz (for the record, that's a pretty high-end embedded controller), and we've had to do some *serious* hacking to get our application to run in real-time at full RPM!
Actually they don't do that these days. *Very* large fines now. I work for Ford, and I've coincidentally just been to a lecture about this.
There's a concept called a "defeat device", which is anything used to make the car's emissions behave differently in normal driving to how they would do under the EPA standard cycles. Anything can be a "defeat device", from a switch to a black box to a control algorithm to a lookup table to a single variable.
EPA test cars on a standard cycle. However, they are also allowed to just take this thing for a drive and see how it behaves, and if it looks wrong then they can do you - particular problems are events (like step-changes) happening just outside the EPA cycles. It is then down to the manufacturer to prove 100% that the reason for that step-change in emissions just outside the EPA cycle is due to a fundamental, can't-get-round feature of the engine, and not due to a defeat device. If you can't prove that 100%, you're assumed guilty and fined.
The essential thing to get here is the "guilty until proven innocent" bit. Auto manufacturers have to disclose to the EPA every part of their strategies which can affect emissions, and show that if emissions are increased at any point, this is either due to stopping the engine melting down or due to an essential driver safety requirement (foot-to-floor is a classic - you can give out more emissions here, bcos it's unsafe for the driver not to have torque when they're trying to overtake). If the EPA doesn't think you're right about your decisions, they can stop you selling the car. And if you don't disclose something which affects emissions, you're 100% screwed.
So far, fines have been relatively small, $100 million max. Toyota however are currently fighting a case which, if they lose, will cost them in the order of billions of dollars. Bad news...
A development board is designed for use by engineers working out how to drive the chip. Typically there'll be a few peripherals (ADCs, DACs, etc), a serial port or similar as a programming and debugging interface (and the debugging interface itself will be something you wouldn't get on a laptop), some RAM onboard, all that kind of thing.
As an analogy, it's the difference between a bare engine clamped to a dynamometer, and an engine fitted in a car. You can work out how to get your power source working, but there's a whole load of other stuff that needs to go around it in order to build something useful.
Maybe so. But I can think of a number of ways of making their life hell. The most obvious way is to trace where she goes, and mount an extensive poster campaign about her, all round her college campus, all round her new job, all round her parents' house, etc. Shit, if someone had ruined my life, I'd sure as hell go about doing the same to them.
There are laws about harassment, and about defamation. But in order to kick these in, the family have to take you to court, at which point you get your chance to stand up and say your piece. At that point, it goes into the public record, and I'm sure there'd be a few papers prepared to take this on. If the kid is now over 18, they go in the public record as well.
The other solution is for the teacher to refuse to move. If he forces the school to sack him, he can claim unfair dismissal against them (and the school authority has much more money than the parents!).
To prove innocence, the best way is what a kid in England did. He was accused of date-rape - again, a his-word-against-hers case - and his university offered not to press charges if he quietly stepped down. His solution? He went to the police station, reported the "crime" himself, and thereby forced the police to investigate the rape claim. It went to court, and of course there was no evidence so he was completely cleared. Sounds like given the evidence against the girl, this teacher could easily do the same.
No-one can *force* you to resign. You resign yourself. Make them fire you, and you're in a much stronger position if you have a large amount of evidence to back your case up.
In the early 90s, ABS was standard on F1 cars. It was removed (along with various other electronic aids) to make the driving more "challenging". Check this link, written in 1991 when ABS came in: http://autopedia.com/stuttgart-west/Physics/StuttP hysics12.html. Particularly the quote:
"Drivers who do not have ABS have already complained that it gives their competition an unfair advantage."
I therefore submit that you are wrong - either threshold braking does not give better results, or it's theoretically better but it's so difficult to do that even top drivers can't use it reliably on race-prepared cars. Either way, the technique does not belong in the skill-set we should expect of any road driver.
Should a driver have the right to turn off ABS if they think they can brake better themselves? If they can demonstrate this fact, then yes. However, car drivers are notorious for believing they have levels of skill which they don't in fact have - the accident statistics are full of these. And if you can't brake in time, you're not just endangering yourself, you're also endangering other ppl with the 2 tons of metal you're controlling when you come off the road on a corner and wipe out another car. Over-confidence when the controls will try and mitigate your actions is one thing - over-confidence where your failure will *definitely* lead to an accident is another thing altogether.
"Your right to wave your fist around ends at my nose".
The majority of US drivers may wear seatbelts. However, US drivers (for some reason) have the right to refuse to wear seatbelts. Car manufacturers (for some reason) are therefore compelled to provide airbags which will hold someone who isn't wearing a seatbelt. This means that the airbags must come out faster and harder.
For myself, I'd rather say that anyone not using a seatbelt does so at their own risk. Unfortunately this is not the case. For the sake of protecting a few muppets who deserve to become Darwin Award nominees, other "regular" folks may suffer minor injuries that they would not otherwise have done.
Grab.
Re:Crichton isn't really an SF author
on
Prey
·
· Score: 2
Scuse me?
"An appreciation for how arrogant *fictional* engineers and programmers, written to be arrogant" would be more on the money. Remember that every character in the book is saying words bcos Crichton wants them to, not bcos of a psychological assessment of all engineers and programmers!
Back in the real world, shit that can get you killed has backups, and backups of the backups. If you don't, you get what you deserve, which in this case is to be eaten by ravenous dinosaurs.:-) The moral is that if you make dumb decisions, you suffer, whether you're an engineer, a lawyer or an archaeologist.
Minority Report had nothing to do with the book's plot - instead, they created an entirely new plot which worked, was internally consistent and had its own message. They took the concept of Precrime but built it into a completely new story. Apart from a few completely unnecessary comedy elements (bouncing eyeballs, sicksticks, top-down view of apartments with the "spiders"), and the unnecessarily saccarine ending with the Precogs, I thought it worked pretty damn well. With better editting and a more consistent vision, it could have been a great movie - as it was, it was just a pretty good one.
The best bit of it was that they obviously spent some money on decent scriptwriters to come up with a consistent plot, believable situations and proper characters. I wish I knew where they found them, and why no-one else in Hollywood chooses to use them...
MAJOR SPOILER FOR BOOK:-
The plot of the book was actually that the army were planning a military coup. Anderton was going to kill the army leader to stop Precrime being disbanded - the army leader got this info and mindf*cked Anderton, who had no idea why he was being told he was going to be a murderer and thought it was all a setup to lose him his job and damage Precrime. Finally he finds out about the coup. He knows he has a choice, and he rationally decides to kill the army leader anyway to keep Precrime in place. Basically, the whole story is a quadruple cross./SPOILERS
Anyway, if they can do the same kind of job on I Robot (take the main concept of the book and apply a whole new decent plot around it), I'll be happy. My worry is that this happens so rarely, it's practically unheard-of.
BTW, Dark City *and* The Crow. The Crow was *the* classic film when I was at uni - stunning visuals. Whether Will Smith has the charisma of Brandon Lee, I don't know, but it should be worth the ticket price anyway.
They do. Oxfam and others spend most of their time digging wells, providing schools and medical care, teaching ppl more efficient farming techniques, passing round new techniques developed by the people themselves, etc. Quoting from Oxfam's site:-
In all our actions Oxfam's goal is to enable people to exercise their rights and manage their own lives.
This can take the form of supporting people in efforts to gain access to productive opportunities, such as land rights, markets, training, and government services. It can also consist of supporting the efforts of poor and marginalized people to organize and participate in decision-making.
Trouble is, when the rains simply don't come, or when the rains come too much and flood everyone's land, you're screwed. At that point, you need outside help to get you through, and to help you get back on your feet again.
I suggest that you could allow everyone to die as a matter of policy. But if you did, then to keep an ethical policy, you'd also have to let all Mississippi residents drown when the river floods, and let LA residents burn to death when forest fires hit. Oh, and allow all cities in CA, AZ and CO to dry up and blow away, bcos they don't get enough rain to support themselves.
It's worse than that. With SUVs being as they are, the *average* fuel economy of US cars is *way* less now than it was 10 years back. From the EPA site (link here):-
The average fuel economy for all model year 1999 light vehicles is 23.8 miles per gallon (MPG). Within this category, average fuel economy is 28.1 MPG for passenger cars and 20.3 MPG for light-duty trucks. The 1999 fuel economy average is the lowest value since 1980 and is 2.1 MPG less than the peak value of 25.9 MPG achieved in both 1987 and 1988. Average fuel economy for new light vehicles has dropped 1.0 MPG since 1996.
Grab.
Re:You've yet to see station selling suitable fuel
on
239 MPG Car
·
· Score: 5, Insightful
Maybe Michael should RTFarticle...
The 'one-liter car' is powered by a single-cylinder diesel engine...
So how many places in the world is it impossible to get diesel? Given that this is the fuel *all* (bar none!) trucks use. The story poster had it right - there's new diesel fuels around which are less polluting, which makes this even better. But it'll still run just fine on plain old diesel.
The only trouble is selling diesel cars to the US market. Or in fact selling *any* fuel-efficient car to the US market.
Best answer - if you're doing work at home, make it a GPL project. You can then get yourself a SourceForge account, which (a) provides a convenient point to distribute your work to the world, and (b) provides an unbeatable off-site backup of the project.
Of course, this isn't much use for other stuff like the book you're writing or whatever, but it's a good solution for software/electronics projects.
Spectrum, C64, Amiga, Atari ST - they all had a totally mass market for games.
Then as now, the core market was the same - mostly teenage boys. Sure, there's plenty of adults today with PS2s and hardcore gaming rigs, but there were similar adults back then with the latest home computer (eg. the Amiga A2000). This is especially the case for the Amiga, which was *way* ahead of the PC but got slammed by Commodore screwing up and going bankrupt by investing in too many shit projects. For an example, StarGlider 2 was 5 years ahead of X-Wing, and conventional flight sims were ahead by a similar amount. The area which saw particularly impressive advances was the graphical adventure area, which was the precursor to all the Tomb Raider stuff - the Amiga and Atari ST were the prime movers in this.
Remember that Doom was a 2-D hack which just looked like 3-D. It wasn't until Quake that 3-D cards became required. The Amiga had 3-D games throughout though - the only thing that wasn't invented was the first-person shooter. Had some bright spark come up with that (and they certainly had platforms that'd support it!) then things would have been quite different. The only issue was that one type of game, it was nothing to do with the platform.
Grab.
Re:On the death of video games...
on
Electronic Life
·
· Score: 2
However, Clive Sinclair had shipped the ZX81, Commodore had its PET going and the VIC20 was just on its way in, and small 8-bit home computers were multiplying like rabbits! And the primary use of all of these was to play games.
Sure, hardware where the only means interaction was a joystick were well on their way out - it's only in the relatively recent past that consoles have made a return. The 80s and 90s were absolutely the realm of the home computer (as defined by including a keyboard), due to the fact that a few hackers could program them, and the rest of the world could play the games they created. The keyboard was less important for the many, but without it, the few couldn't produce the stuff that the many used.
With that in mind, Crichton's guess was pretty short-sighted even at the time.
It's rather the same way that after the crashes of Pets.com and other similar crap ideas, ppl spouted a load of nonsense about "the web is bad for business". The problem isn't the medium, the problem is that a bunch of business majors went hog-wild, didn't think the problem through, and consequently cratered their companies. Early-80s consoles had exactly the same problem due to the management of the various companies all doing *really* dumb things.
Ornithoptors are a nice idea, and again, a few ppl have made working balsa-wood models of them.
The problem is that nifty techniques often don't scale. In the case of ornithoptors, flapping a plane-size wing requires stronger materials than are ever likely to be available. Be interesting to see if this gadget will scale to passenger-size aircraft.
Incidentally, I'm not sure how the bloke making these things reckons they'd be good for in cities. The wings are huge!
That's why I totally can't stand the Roger Moore films - it's always the gadget that saves him. And Brosnan seems to be going the same way.
The Sean Connery films, the gadgets were very much a side issue, never a life-saver. That's where Timothy Dalton scored - him and Sean Connery were the only Bonds prepared to get into a proper fight. Shame the Dalton films were done so averagely though - the whole thing was just recovering from the damage done by Moore. Dalton prepped the franchise to get serious for Brosnan.
I'd agree with you on that. Thing is, I'm coming from the point-of-view of real-time control of physical systems.
If you're talking about embedded stuff in palmtops, that's a very different target - palmtops and desktops have pretty much the same core requirements, so the implementation is likely to be pretty similar too.
Most of the umpty-tum million chips going out though are microcontrollers - there's zillions more microcontrollers than anything else, and they're all in "commodity" electronics. When you're selling a few million pieces a year, the cost of writing the software becomes negligible - you just want to be able to squeeze it into the cheapest, nastyest little chip you can find. The benefits of OO simply don't apply. If you're talking mobile phones though, OO becomes a strong contender - software reuse, modularity and ease-of-interfacing mean you'll likely get a faster time-to-market, which in mobile phones is much more important than the final cost of them. (To give an example of how critical time-to-market is, my friend who works for a mobile phone design company had a project last year where the deadlines were so tight, the customer couldn't wait for the final version of the PCB, so they built 50,000 phones with the old PCB and had a bunch of ppl using patch-wire and soldering irons to fix them!)
Yeah, C++ has its place, and that place is in rapid-development or user-interface-related stuff - mobile phones and palmtops are the classic applications. But it will always be cheaper to buy a low-featured microcontroller than a high-featured one, so I think code efficiency (in terms of time, RAM and ROM usage) will always (or for some significant time, at least - never say never!;-) be more important than the benefits of OO for large-production-run low-cost items, and for embedded real-time control systems where there's some serious processing going on.
Oops, forgot to mention one key detail - embedded *control* systems. If you only want to run a mobile phone, no-one gives a damn if it crashes every day (as several do). If you're controlling a washing machine and it tips water over the floor every day, that's bad news. If you're controlling a car and the software (and therefore the car!) crashes every day, that's major legal action. If you're controlling an aircraft and the software (and therefore the plane!) crashes, that's the end of the company and the careers of everyone involved.
However, I stand by what I said. C++ has too many areas of uncertainty for use on embedded systems. It is nice for concealing complexity from the user, but that isn't necessarily what you want for control systems - see the "leaky model" post on/. yesterday.
Re "slow", I will acknowledge that it depends how you code it. But if you're using all the features of the language such as abstract base classes and multiple inheritance, then it can't but take longer to execute, simply bcos there's more to check at every function call!
Lots of ppl use C++ but just write similar code to what they'd otherwise write in C. In that case, there genuinely will be little change in execution time. However, in that case there is no reason for them not to be writing in C, bcos all the classes are providing is a convenient place to group functions together.
We're currently using a 32MHz PowerPC chip in a car engine controller. We're *only just* managing to get everything running in the time allowed, and we've had to make some changes to get it down to that. We're using C, with some assembler to optimise the more extreme corners of it.
And note that this is still a traditional engine controller (lookup tables and stuff). Moving to new-fangled "model-based control" will require at least another order of magnitude improvement or more in processor speeds. Processor speeds will improve, but ppl are more likely to use extra power to implement features than to allow them to write OO.
In embedded control systems software (where speed of response is critical), everyone still uses C, and will do for a *long* time. Why? It's fast and efficient, everyone understands it, and there is no embedded processor yet which is fast enough for the more "bloated" development methods like OO to be used.
Other embedded control software (where speed of response is not critical; mobile phones for example) tend towards C++ for convenience - everyone understands C++. C++ is too slow and too unpredictable for it to be used for proper control systems, particularly when it's safety-related or safety-critical, but it's fine for interfaces on phones and stuff like that.
Embedded software is the big boom area now. Get into that, and don't look back.
Slashdot Mirror
Keanu has his own style and put everything he had into that movie
Yep, and that's the problem, really.
Troll, I know, but please ppl, face facts - Keanu Reeves' best work was Bill and Ted, a movie in which the main requirement was to act badly but look cool. A job which he did well, for the same reason that Hervé Villechaize was good at being short.
Grab.
Actually, most realtime systems do use interrupts. They're the best way of getting multi-rate processing done - for instance, there's no need to check the ambient air temperature faster than maybe every 100ms, bcos it doesn't change that fast, but calculations of engine fuelling required need to be done at the millisecond kind of timing. To do this, you split your code into stuff running at separate task rates. Interrupts ensure that more important tasks interrupt less important tasks. Every engine controller uses this system.
Of course, you don't want interrupts to screw your data. To this end, your RTOS ensures that every task has a separate stack or that the lower-priority task's registers are pushed and popped during interrupts, and you have to design your code to take account of interrupts. For example, if a low-priority task sets a bit-field to zero and then fills in each bit one at a time, a high-priority task mustn't read that bit-field bcos it may read the value before the low-priority task has finished filling in all the bits. Embedded code has its own sets of challenges which you don't usually see in the desktop world.
Incidentally, the "relatively simple" embedded system is no longer simple. In order to meet ever-tighter emissions controls and get better performance and mileage from the same engine, the processing is *seriously* complex. On my current project at work, we're currently using a 32-bit processor with floating-point support running at 32MHz (for the record, that's a pretty high-end embedded controller), and we've had to do some *serious* hacking to get our application to run in real-time at full RPM!
Grab.
Actually they don't do that these days. *Very* large fines now. I work for Ford, and I've coincidentally just been to a lecture about this.
There's a concept called a "defeat device", which is anything used to make the car's emissions behave differently in normal driving to how they would do under the EPA standard cycles. Anything can be a "defeat device", from a switch to a black box to a control algorithm to a lookup table to a single variable.
EPA test cars on a standard cycle. However, they are also allowed to just take this thing for a drive and see how it behaves, and if it looks wrong then they can do you - particular problems are events (like step-changes) happening just outside the EPA cycles. It is then down to the manufacturer to prove 100% that the reason for that step-change in emissions just outside the EPA cycle is due to a fundamental, can't-get-round feature of the engine, and not due to a defeat device. If you can't prove that 100%, you're assumed guilty and fined.
The essential thing to get here is the "guilty until proven innocent" bit. Auto manufacturers have to disclose to the EPA every part of their strategies which can affect emissions, and show that if emissions are increased at any point, this is either due to stopping the engine melting down or due to an essential driver safety requirement (foot-to-floor is a classic - you can give out more emissions here, bcos it's unsafe for the driver not to have torque when they're trying to overtake). If the EPA doesn't think you're right about your decisions, they can stop you selling the car. And if you don't disclose something which affects emissions, you're 100% screwed.
So far, fines have been relatively small, $100 million max. Toyota however are currently fighting a case which, if they lose, will cost them in the order of billions of dollars. Bad news...
Grab.
In a word, everything!
A development board is designed for use by engineers working out how to drive the chip. Typically there'll be a few peripherals (ADCs, DACs, etc), a serial port or similar as a programming and debugging interface (and the debugging interface itself will be something you wouldn't get on a laptop), some RAM onboard, all that kind of thing.
As an analogy, it's the difference between a bare engine clamped to a dynamometer, and an engine fitted in a car. You can work out how to get your power source working, but there's a whole load of other stuff that needs to go around it in order to build something useful.
Grab.
Maybe so. But I can think of a number of ways of making their life hell. The most obvious way is to trace where she goes, and mount an extensive poster campaign about her, all round her college campus, all round her new job, all round her parents' house, etc. Shit, if someone had ruined my life, I'd sure as hell go about doing the same to them.
There are laws about harassment, and about defamation. But in order to kick these in, the family have to take you to court, at which point you get your chance to stand up and say your piece. At that point, it goes into the public record, and I'm sure there'd be a few papers prepared to take this on. If the kid is now over 18, they go in the public record as well.
The other solution is for the teacher to refuse to move. If he forces the school to sack him, he can claim unfair dismissal against them (and the school authority has much more money than the parents!).
To prove innocence, the best way is what a kid in England did. He was accused of date-rape - again, a his-word-against-hers case - and his university offered not to press charges if he quietly stepped down. His solution? He went to the police station, reported the "crime" himself, and thereby forced the police to investigate the rape claim. It went to court, and of course there was no evidence so he was completely cleared. Sounds like given the evidence against the girl, this teacher could easily do the same.
No-one can *force* you to resign. You resign yourself. Make them fire you, and you're in a much stronger position if you have a large amount of evidence to back your case up.
Grab.
In the early 90s, ABS was standard on F1 cars. It was removed (along with various other electronic aids) to make the driving more "challenging". Check this link, written in 1991 when ABS came in: http://autopedia.com/stuttgart-west/Physics/StuttP hysics12.html. Particularly the quote:
"Drivers who do not have ABS have already complained that it gives their competition an unfair advantage."
I therefore submit that you are wrong - either threshold braking does not give better results, or it's theoretically better but it's so difficult to do that even top drivers can't use it reliably on race-prepared cars. Either way, the technique does not belong in the skill-set we should expect of any road driver.
Should a driver have the right to turn off ABS if they think they can brake better themselves? If they can demonstrate this fact, then yes. However, car drivers are notorious for believing they have levels of skill which they don't in fact have - the accident statistics are full of these. And if you can't brake in time, you're not just endangering yourself, you're also endangering other ppl with the 2 tons of metal you're controlling when you come off the road on a corner and wipe out another car. Over-confidence when the controls will try and mitigate your actions is one thing - over-confidence where your failure will *definitely* lead to an accident is another thing altogether.
"Your right to wave your fist around ends at my nose".
Grab.
The majority of US drivers may wear seatbelts. However, US drivers (for some reason) have the right to refuse to wear seatbelts. Car manufacturers (for some reason) are therefore compelled to provide airbags which will hold someone who isn't wearing a seatbelt. This means that the airbags must come out faster and harder.
For myself, I'd rather say that anyone not using a seatbelt does so at their own risk. Unfortunately this is not the case. For the sake of protecting a few muppets who deserve to become Darwin Award nominees, other "regular" folks may suffer minor injuries that they would not otherwise have done.
Grab.
Scuse me?
:-) The moral is that if you make dumb decisions, you suffer, whether you're an engineer, a lawyer or an archaeologist.
"An appreciation for how arrogant *fictional* engineers and programmers, written to be arrogant" would be more on the money. Remember that every character in the book is saying words bcos Crichton wants them to, not bcos of a psychological assessment of all engineers and programmers!
Back in the real world, shit that can get you killed has backups, and backups of the backups. If you don't, you get what you deserve, which in this case is to be eaten by ravenous dinosaurs.
Grab.
(offtopic, but anyway...)
/SPOILERS
Minority Report had nothing to do with the book's plot - instead, they created an entirely new plot which worked, was internally consistent and had its own message. They took the concept of Precrime but built it into a completely new story. Apart from a few completely unnecessary comedy elements (bouncing eyeballs, sicksticks, top-down view of apartments with the "spiders"), and the unnecessarily saccarine ending with the Precogs, I thought it worked pretty damn well. With better editting and a more consistent vision, it could have been a great movie - as it was, it was just a pretty good one.
The best bit of it was that they obviously spent some money on decent scriptwriters to come up with a consistent plot, believable situations and proper characters. I wish I knew where they found them, and why no-one else in Hollywood chooses to use them...
MAJOR SPOILER FOR BOOK:-
The plot of the book was actually that the army were planning a military coup. Anderton was going to kill the army leader to stop Precrime being disbanded - the army leader got this info and mindf*cked Anderton, who had no idea why he was being told he was going to be a murderer and thought it was all a setup to lose him his job and damage Precrime. Finally he finds out about the coup. He knows he has a choice, and he rationally decides to kill the army leader anyway to keep Precrime in place. Basically, the whole story is a quadruple cross.
Anyway, if they can do the same kind of job on I Robot (take the main concept of the book and apply a whole new decent plot around it), I'll be happy. My worry is that this happens so rarely, it's practically unheard-of.
BTW, Dark City *and* The Crow. The Crow was *the* classic film when I was at uni - stunning visuals. Whether Will Smith has the charisma of Brandon Lee, I don't know, but it should be worth the ticket price anyway.
Grab.
They do. Oxfam and others spend most of their time digging wells, providing schools and medical care, teaching ppl more efficient farming techniques, passing round new techniques developed by the people themselves, etc. Quoting from Oxfam's site:-
In all our actions Oxfam's goal is to enable people to exercise their rights and manage their own lives.
This can take the form of supporting people in efforts to gain access to productive
opportunities, such as land rights, markets, training, and government services. It can also consist of supporting the efforts of poor and marginalized people to organize and participate in decision-making.
Trouble is, when the rains simply don't come, or when the rains come too much and flood everyone's land, you're screwed. At that point, you need outside help to get you through, and to help you get back on your feet again.
I suggest that you could allow everyone to die as a matter of policy. But if you did, then to keep an ethical policy, you'd also have to let all Mississippi residents drown when the river floods, and let LA residents burn to death when forest fires hit. Oh, and allow all cities in CA, AZ and CO to dry up and blow away, bcos they don't get enough rain to support themselves.
Grab.
It's worse than that. With SUVs being as they are, the *average* fuel economy of US cars is *way* less now than it was 10 years back. From the EPA site (link here):-
The average fuel economy for all model year 1999 light vehicles is 23.8 miles per gallon (MPG). Within this category, average fuel economy is 28.1 MPG for passenger cars and 20.3 MPG for light-duty trucks. The 1999 fuel economy average is the lowest value since 1980 and is 2.1 MPG less than the peak value of 25.9 MPG achieved in both 1987 and 1988. Average fuel economy for new light vehicles has dropped 1.0 MPG since 1996.
Grab.
Maybe Michael should RTFarticle...
The 'one-liter car' is powered by a single-cylinder diesel engine...
So how many places in the world is it impossible to get diesel? Given that this is the fuel *all* (bar none!) trucks use. The story poster had it right - there's new diesel fuels around which are less polluting, which makes this even better. But it'll still run just fine on plain old diesel.
The only trouble is selling diesel cars to the US market. Or in fact selling *any* fuel-efficient car to the US market.
Grab.
Best answer - if you're doing work at home, make it a GPL project. You can then get yourself a SourceForge account, which (a) provides a convenient point to distribute your work to the world, and (b) provides an unbeatable off-site backup of the project.
Of course, this isn't much use for other stuff like the book you're writing or whatever, but it's a good solution for software/electronics projects.
Grab.
Eh?
Spectrum, C64, Amiga, Atari ST - they all had a totally mass market for games.
Then as now, the core market was the same - mostly teenage boys. Sure, there's plenty of adults today with PS2s and hardcore gaming rigs, but there were similar adults back then with the latest home computer (eg. the Amiga A2000). This is especially the case for the Amiga, which was *way* ahead of the PC but got slammed by Commodore screwing up and going bankrupt by investing in too many shit projects. For an example, StarGlider 2 was 5 years ahead of X-Wing, and conventional flight sims were ahead by a similar amount. The area which saw particularly impressive advances was the graphical adventure area, which was the precursor to all the Tomb Raider stuff - the Amiga and Atari ST were the prime movers in this.
Remember that Doom was a 2-D hack which just looked like 3-D. It wasn't until Quake that 3-D cards became required. The Amiga had 3-D games throughout though - the only thing that wasn't invented was the first-person shooter. Had some bright spark come up with that (and they certainly had platforms that'd support it!) then things would have been quite different. The only issue was that one type of game, it was nothing to do with the platform.
Grab.
However, Clive Sinclair had shipped the ZX81, Commodore had its PET going and the VIC20 was just on its way in, and small 8-bit home computers were multiplying like rabbits! And the primary use of all of these was to play games.
Sure, hardware where the only means interaction was a joystick were well on their way out - it's only in the relatively recent past that consoles have made a return. The 80s and 90s were absolutely the realm of the home computer (as defined by including a keyboard), due to the fact that a few hackers could program them, and the rest of the world could play the games they created. The keyboard was less important for the many, but without it, the few couldn't produce the stuff that the many used.
With that in mind, Crichton's guess was pretty short-sighted even at the time.
It's rather the same way that after the crashes of Pets.com and other similar crap ideas, ppl spouted a load of nonsense about "the web is bad for business". The problem isn't the medium, the problem is that a bunch of business majors went hog-wild, didn't think the problem through, and consequently cratered their companies. Early-80s consoles had exactly the same problem due to the management of the various companies all doing *really* dumb things.
Grab.
Ornithoptors are a nice idea, and again, a few ppl have made working balsa-wood models of them.
The problem is that nifty techniques often don't scale. In the case of ornithoptors, flapping a plane-size wing requires stronger materials than are ever likely to be available. Be interesting to see if this gadget will scale to passenger-size aircraft.
Incidentally, I'm not sure how the bloke making these things reckons they'd be good for in cities. The wings are huge!
Grab.
Too right.
That's why I totally can't stand the Roger Moore films - it's always the gadget that saves him. And Brosnan seems to be going the same way.
The Sean Connery films, the gadgets were very much a side issue, never a life-saver. That's where Timothy Dalton scored - him and Sean Connery were the only Bonds prepared to get into a proper fight. Shame the Dalton films were done so averagely though - the whole thing was just recovering from the damage done by Moore. Dalton prepped the franchise to get serious for Brosnan.
Still can't stand Brosnan as Bond though.
Grab.
I'd agree with you on that. Thing is, I'm coming from the point-of-view of real-time control of physical systems.
;-) be more important than the benefits of OO for large-production-run low-cost items, and for embedded real-time control systems where there's some serious processing going on.
If you're talking about embedded stuff in palmtops, that's a very different target - palmtops and desktops have pretty much the same core requirements, so the implementation is likely to be pretty similar too.
Most of the umpty-tum million chips going out though are microcontrollers - there's zillions more microcontrollers than anything else, and they're all in "commodity" electronics. When you're selling a few million pieces a year, the cost of writing the software becomes negligible - you just want to be able to squeeze it into the cheapest, nastyest little chip you can find. The benefits of OO simply don't apply. If you're talking mobile phones though, OO becomes a strong contender - software reuse, modularity and ease-of-interfacing mean you'll likely get a faster time-to-market, which in mobile phones is much more important than the final cost of them. (To give an example of how critical time-to-market is, my friend who works for a mobile phone design company had a project last year where the deadlines were so tight, the customer couldn't wait for the final version of the PCB, so they built 50,000 phones with the old PCB and had a bunch of ppl using patch-wire and soldering irons to fix them!)
Yeah, C++ has its place, and that place is in rapid-development or user-interface-related stuff - mobile phones and palmtops are the classic applications. But it will always be cheaper to buy a low-featured microcontroller than a high-featured one, so I think code efficiency (in terms of time, RAM and ROM usage) will always (or for some significant time, at least - never say never!
Graham.
Oops, forgot to mention one key detail - embedded *control* systems. If you only want to run a mobile phone, no-one gives a damn if it crashes every day (as several do). If you're controlling a washing machine and it tips water over the floor every day, that's bad news. If you're controlling a car and the software (and therefore the car!) crashes every day, that's major legal action. If you're controlling an aircraft and the software (and therefore the plane!) crashes, that's the end of the company and the careers of everyone involved.
Grab.
Not bad going! :-)
/. yesterday.
However, I stand by what I said. C++ has too many areas of uncertainty for use on embedded systems. It is nice for concealing complexity from the user, but that isn't necessarily what you want for control systems - see the "leaky model" post on
Re "slow", I will acknowledge that it depends how you code it. But if you're using all the features of the language such as abstract base classes and multiple inheritance, then it can't but take longer to execute, simply bcos there's more to check at every function call!
Lots of ppl use C++ but just write similar code to what they'd otherwise write in C. In that case, there genuinely will be little change in execution time. However, in that case there is no reason for them not to be writing in C, bcos all the classes are providing is a convenient place to group functions together.
Grab.
Simply *true*.
We're currently using a 32MHz PowerPC chip in a car engine controller. We're *only just* managing to get everything running in the time allowed, and we've had to make some changes to get it down to that. We're using C, with some assembler to optimise the more extreme corners of it.
And note that this is still a traditional engine controller (lookup tables and stuff). Moving to new-fangled "model-based control" will require at least another order of magnitude improvement or more in processor speeds. Processor speeds will improve, but ppl are more likely to use extra power to implement features than to allow them to write OO.
Grab.
And Gnu's not Unix. Yeah right.
If it quacks like a duck and waddles like a duck...
Grab.
You forgot to mention working out a bit, so you're in shape for all those group exercise meetings before work.
Grab.
Dead right.
In embedded control systems software (where speed of response is critical), everyone still uses C, and will do for a *long* time. Why? It's fast and efficient, everyone understands it, and there is no embedded processor yet which is fast enough for the more "bloated" development methods like OO to be used.
Other embedded control software (where speed of response is not critical; mobile phones for example) tend towards C++ for convenience - everyone understands C++. C++ is too slow and too unpredictable for it to be used for proper control systems, particularly when it's safety-related or safety-critical, but it's fine for interfaces on phones and stuff like that.
Embedded software is the big boom area now. Get into that, and don't look back.
Grab.
You ever been to Britain? Accents R us!
Grab.