You can stabilise just about anything with an electronic control system. A famous example would be a high-point balance - think of balancing a pencil on its point on the end of your finger. You can maybe do it for a few seconds, max. But build an electronic control system which can measure the position of the pencil and move its "finger" accordingly, and it'll stay there forever (or until you kill the power to the controller!:-) The control system doesn't have to be computerised, often analogue works better on simple problems with well-understood maths due to the faster response time, but digital systems are much more versatile and are therefore better at solving less clear-cut problems (like "the plane's slewing a particular way, one engine is only giving half-power and the left elevator appears to be stuck, what do I do?").
Having said that, a passenger aircraft is unlikely to be dynamically unstable, for safety. So computers will have been the main factor, in that they've allowed this thing to be designed (with finite-element analysis or whatever).
OS-wise, it'll be some real-time OS. Either an off-the-shelf one like Wind River's Tornado, or some custom scheduler they've designed themselves. Task schedulers are quite easy to design, and that's about all you need for an embedded system (since no-one uses dynamic memory allocation in embedded stuff). Sorry to disappoint!;-)
Re:This movie SUCKED HUGE - are you people morons?
on
Minority Report
·
· Score: 3, Informative
Film's not yet out over here. But...
Of course some of it's going to _appear_ derivative of other films. It's based on a book by Phil K. Dick, the guy who wrote the book "Bladerunner" was based off. The guy who had a massive hand in inspiring Gibson and others to go cyberpunk in the 80s. It's gonna be derivative in the same way that "Lord of the Rings" is derivative of "Willow" and "The Dark Crystal".
Backlights are good, and hi-res LCDs are pretty hot these days too (I lucked out on a 17" 1280x1024 LCD at work, and I love it to bits!:-) But eyes aren't set up to look long-term at lit things, they're set up to look at things which reflect light back. Paper is just easier for eyes to look at for long periods.
Electronic ink will be the big thing to hit displays. But I don't think even that will get away from paper - flicking between pages of a book is simply quicker and easier than flicking through a document.
Most ppl can get their typing speed up to something good enough to take notes in real time. But I doubt anyone could get their graffiti speed up to anything like handwriting level, never mind the speed of a typical good typist.
That's the thing - we don't have to suffer. We should know the technology well enough to ensure we can keep our asses covered.
Of course, there's no need to be defensive unless your management really are a bunch of unscrupulous weasels!:-) If your managers are good (as mine are at my current job) then there's no need.
My current place is pretty much a classic *good* example. Medium-size company (200-250 employees), flat management structure. You can trust the managers, right up to board level, not to stiff the employees - many of them have worked up from engineering positions so they know the score, and if you say "the customer's wrong, it'll actually take this long" then they'll fight your corner as far as it takes. And it gets real loyalty and real benefits for the company - we'll work longer hours and put ourselves out to meet a release (up to a limit, of course!;-) bcos we take pride in what we do. I know I could move to a job 20 miles down the road for 5-10K more, but frankly I don't want to.
Make sure everyone knows what estimates you gave. Or if you can't make the higher-ups aware, make sure your estimate and your disapproval of your boss's new estimate are recorded in an email to your boss. Then you take as long as it takes, and when it overruns and fingers are pointed at you, you say "I told you so" and point them to the evidence. And if you get fired/downgraded for that, there's a nice little sum waiting for you at the industrial tribunal when you bring that "constructive dismissal" case.;-)
Re the trade-off thing, again you need to get written down what the results will be, and send it to your boss. Preferably also CC it to his boss. If the trade-off will mean more bugs, then write it down. Then when there are bugs, you have some comeback by saying "I was forced to release this code without having tested it, even though I said what the consequences were".
BTW, don't forget to check the "notify on read" and "notify on receipt" boxes when you send the email, then you actually have proof that (a) it got there, and (b) he read it. If he later claims ignorance, or says "Outlook must have eaten it", you've got evidence otherwise. Emails are your evidence when the shit hits the fan!
There are some bad managers out there. If you get one, don't be afraid to go over his head and talk to his boss, or to your personnel manager. You have a right to do that if you have a complaint about him.
And if all else fails, find another job. Seriously. If the management at your place doesn't value you, get the hell out.
Trouble is, what it actually gets is everything a *developer* wants in it, which ain't necessarily the same thing. And the developer implementing it won't necessarily write it in any way that anyone can use it effectively. And the end product becomes bloated with features that most ppl will never need, simply bcos someone thought it was "neat". Can you say "Emacs"...?;-)
Depends. If ppl go straight to code, then the code *is* the design. So review the code for all of this.
If they do a detailed design first, then you should be taking the next logical step of reviewing the design against the requirements. Then the code gets reviewed against the design.
The thing is, no tool can catch the classes of bugs that are thrown up by these review steps. No tool EVER will, bcos what these steps are doing is taking a concept expressed in some customer's Word document and over a bunch of meetings and turning it into a design document and some code. Believe me, if you've found a tool that can do this, you've cracked natural languages, AI and the Turing Test in one go!
That's not to say that tools aren't useful. If you can have a tool manually search for "if(x=0)" then that's useful, so there's a good chance that you can at least catch most of the typos that way. But no tool will ever replace a review by a human.
Re (2) and (3), having separate groups is a *really* good way to get the old "them-and-us" battle going. The testers hate the programmers bcos they see themselves as covering up for the programmers' lack of skills; the programmers hate the testers bcos the testers keep telling them that they're screwing up; and everyone hates QA for telling them how to do their job.
The problem is that very few bugs occur at the purely code stage, and most of them are easy to trace. The real problem is design bugs - they're the killers. The solution at our company is to (a) review, (b) separate development, and (c) follow a V-model quite strictly. We have one group of engineers, where everyone writes, codes, reviews and tests, and for each section, everyone will have a different role so no-one gets stuck just being the tester.
Someone writes a requirements spec, and also writes the system test spec by which they'll prove that the thing works as expected. Writing the test spec forces you to put numbers to your requirements, basically making you self-review the requirements for errors, and it find a lot of bugs. Someone else checks that the requirements spec makes sense, and also that the system test spec matches up with the requirements spec. And typically we spend over a quarter of our time at the requirements stage, bcos it's dead easy to edit a single line in a Word document but it's a helluva lot more difficult to change a zillion C files, test specs, etc.
If the system is simple, we'll go straight to code. But if the system is complex, we do a detailed design (usually in Simulink and Stateflow these days, since we're coding for embedded control systems). The person who does the design MUST NOT be the same person who wrote the requirements - this effectively gives us another review of the requirements, to catch any oddities which can't be implemented. And someone will review that the design is actually meeting the requirements.
The same person who's done the detailed design will also write a test spec to say how to test the code. This will cover all boundary conditions, so any time there's a comparison, for instance, we'd check that it gets ">=" instead of just ">". We've got an in-house tool which allows us to write test specs in Excel and run them on code automatically. And someone will review this to make sure it matches the design and covers all cases.
Then someone writes the code. The coder MUST NOT be the designer - as with the requirements/design separation, this gives us a free review. They'll put that through Lint to check for obvious problems (we follow the MISRA coding standard, with a few exceptions where MISRA didn't get it right), and then run their code through the test spec. If it fails, they'll look for the bugs in the code. Sometimes they find bugs in the test spec; in that case the test spec gets modified. Having an automated test spec means we can run tests on code with zero overhead for repeating the tests.
And then the code will be run against the system level tests, and hopefully everything passes. If it doesn't, the system level test has found a bug in the design, where the design isn't meeting the requirements. Rinse and repeat.
It's worth saying that we're writing code for automotive control systems. How much testing to do is really a trade-off of the cost of testing against the cost of failure, and in our case, failure is not an option!
The code may not be, but the *hardware* absolutely does, and correct operation of the code is linked to the hardware it runs on. Upgrading the hardware may cause all sorts of problems with the software.
For example, at my last company we had an inventory system which dated back to the early 80s. It used VT100 dumb terminals which connected to a central location running custom software. In 1995 or so they replaced the dumb terminals with proper PCs, but it was still only possible to connect using a VT100 emulator on the PC. And they couldn't improve the link, bcos the inventory system was intimately connected to the VT100 links.
The whole dumb terminal business in itself illustrates how you'd write sofware to match hardware requirements. No-one today would try and let Diablo's central server control every bit on your screen, bcos it just isn't worth it, there's a perfectly good PC sat there which can do it much easier. Just tell the PC where each object is, and offload the display stuff onto the PC. But 20 years (and longer) back, terminals had to be dumb bcos processing was so expensive, hence VT100 as a text solution and, later, X-Windows as a GUI solution.
Point is, when you write code then you will usually make assumptions about your hardware, for example, assuming that using a 32-bit counter counting clock ticks is adequate for long timeouts. It may well have been adequate on a 1MHz 8088, but when you jump to a 1GHz Pentium then you get all sorts of problems. For another example, I've got a whole bunch of Win3.11 games which aren't usable, bcos the game designers didn't think to allow for increasing processor speeds. So the moment you hit "start", the Pacman ghosts zip round the screen like greased lightning and hit you before you can press a button!
If you took the trouble 15 years back to cater for clock speeds of 100GHz, data transfer rates of 1TB/s and data block sizes of 100TB, then your code is probably still OK today and for a few years yet. If not, like most code written way back when, then it's probably gone geriatric. You may not even be able to guarantee it'll run on new machines, so you'd only be able to run it on the old 8088 sat in the corner gathering dust. If this program happens to be something which sorts files into alphabetical or time order, then you'd be better rewriting it to run fast on new hardware than forcing it to run slowly on old hardware.
12V lighting needs significantly larger cables (thicker copper core) - recabling an entire school would not be cheap, and the cables are more expensive (bcos copper core is more expensive than PVC coating). Fluorescent lights in place of filament lights would make a difference though.
Solar panels used for heating water are viable (pay back investment within 5 years or so), but solar panels for generating electricity won't pay back the investment in less than 20 years (assuming they last that long - most electrical things break inside 20 years, and photovoltaic cells are mounted on glass so are very vulnerable to damage).
So by spending on these, we could dump a whole bundle of money into something that gives no benefit. I think you could have chosen your "cost-saving" examples a bit better!;-)
Having said that, you're dead right from the POV of saving money - if you need to cut costs, look at all corners. If you can buy second-hand PCs for $100 each and blow Red Hat and StarOffice onto them, and still have a useable system, then you don't need to buy top-line gear at $500 each plus another $500 for all the software.
It didn't. Lucas added it about a year after the original release, when he saw it was a big success, everyone was raving about it, and he realised he could make pots of money out of it. The original didn't have that heading.
And comparing Ep1 with the original? No fancy moves, no feet, no jumps, nothing.
Jean-Luc Besson has _much_ better things to do with his time than read teen sci-fi books. Besson nicked it from Bladerunner and Asimov's Foundation series of books, but Besson was the first to get the image onto the screen.
If it's the beginning of the saga, the rest of the saga has to be in place. Be assured that Lucas is making this shit up as he goes along and as CGI FX get cheaper. Since Lucas apparently crapped on the SW fiction writers bigstyle (I'm not into the books, but the word is that the films are way inconsistent with the books), then I'd hazard a guess that he doesn't much care about writing a consistent saga.
Let's be honest here, the first film was never conceived as being the "fourth" film. It was only some time later that Lucas thought he could chisel some more money out by giving himself the room to do prequels.
Shame the film isn't up to par technically then, really. CGI that looks it, dialogue like, well, like the last film really. It's a shame really, since there's so much going for Star Wars. However, Lucas seems to have the sadiM touch - everything gold he touches turns to shit. The phrase "snatching defeat from the jaws of victory" was made for Lucas's script-writing (or should that be "the Jawas of victory"?;-)
What fun. So will the quality of picture increase, or will they instead fill more of the disk with pointless guff like crappy menus, interviews with the man who cleans the shoes of the second team coach driver, etc? I know which one my money's on.
Sometimes, from other ppl. If I see it, it goes right back in review, and I won't pass the review until the fuckwit responsible has removed them. If you're writing code for yourself, then fine, please yourself. If you're writing code that anyone else will see, *especially* the customer, then hell no.
Thing is, there's two essential things that a reviewer/maintainer has to understand about a program: what it does; and why it does it. It should be possible to work out the first one of these just from the code, so long as the variables and functions are named sensibly. The second can be worked out from code with some effort, or the coder can add comments to explain why they're doing things that way and make it easier for maintainers.
But if someone has deliberately given all the variables names which don't reflect what they do, then it's utterly impossible to work out what the code is doing, and it's therefore also impossible to work out why it's doing it. So the code is unmaintainable - it isn't possible for anyone else to pick it up and work out what it does, except with massive work. If in 6 months time your company says "oh, we've got this code we can use with slight modifications, let's quote 1 month to do this contract" and then they find out you've made the code utterly obscure, then they'll crash and burn. And if that happens, the company *will* fire (or at least formally discipline) the person who wrote the original code, bcos they've been grossly negligence in doing their job. And you can kiss goodbye to any reference from them, so you'll be SOL in finding your next job.
Yes. And it's you that needs it, since you obviously haven't bothered to find out what really happened to the Hindenburg (hint: it has _nothing_ to do with the hydrogen).
Grab.
Re:The whole outer skin could provide fuel...
on
Zeppelins on Patrol?
·
· Score: 2
NASA have already put up a solar-powered plane (unmanned) which IIRC holds the record for the longest time anything has stayed up without needing refuelling (or refuelling with kerosene, anyway).
You must see some _very_ strange ppl walking around. FF wasn't close to realistic, just one notch better than Toy Story 2. Bodies didn't move properly, faces didn't work, plus there were plenty of nice rectangular polygons floating around in areas where they didn't think you'd notice (hands, arms, etc). I won't start on the animators who couldn't make a character do anything without wildly exaggerated arm and body movements, bcos they said they were going for manga-style accentuated movements, so I'll let that one go. But the realism wasn't much better than Toy Story 2. The old guy was better than the others (bcos they animated him last after they'd done the others), but still pretty dodgy.
Depends. Do you add more value than an Indian programmer? If someone at your company finds it harder to communicate with you and get you to do stuff right than they do with some guy in India, then I'd say they have no business employing you anyway!;-) The company doesn't exist for your personal benefit - the aim is to make a profit, not to be a job-creation scheme. Eastern Europe went the way of the job-creation scheme, and that worked a real treat (for killing industry, anyway). Also bear in mind that there's extra cost in contracting stuff out to provide oversight of your contractor, so their cost per hour isn't necessarily the total cost to your business.
Thing is, you use ppl where they add value. For example, making clothes - you may contract out the actual making of clothes to Thailand or somewhere, but the value is added by the designer, and the designer is based in the US (or wherever). As an engineer, you add value by producing a good detailed design - translation from detailed design to code is pretty much a "turn-the-handle" operation which any coding monkey of any nationality can do (assuming they're competent and work to time, which is why a typical contract has penalty clauses for being late or code not matching spec).
Slashdot Mirror
You can stabilise just about anything with an electronic control system. A famous example would be a high-point balance - think of balancing a pencil on its point on the end of your finger. You can maybe do it for a few seconds, max. But build an electronic control system which can measure the position of the pencil and move its "finger" accordingly, and it'll stay there forever (or until you kill the power to the controller! :-) The control system doesn't have to be computerised, often analogue works better on simple problems with well-understood maths due to the faster response time, but digital systems are much more versatile and are therefore better at solving less clear-cut problems (like "the plane's slewing a particular way, one engine is only giving half-power and the left elevator appears to be stuck, what do I do?").
;-)
Having said that, a passenger aircraft is unlikely to be dynamically unstable, for safety. So computers will have been the main factor, in that they've allowed this thing to be designed (with finite-element analysis or whatever).
OS-wise, it'll be some real-time OS. Either an off-the-shelf one like Wind River's Tornado, or some custom scheduler they've designed themselves. Task schedulers are quite easy to design, and that's about all you need for an embedded system (since no-one uses dynamic memory allocation in embedded stuff). Sorry to disappoint!
Grab.
Aooool, Vienna!
Grab.
Film's not yet out over here. But...
Of course some of it's going to _appear_ derivative of other films. It's based on a book by Phil K. Dick, the guy who wrote the book "Bladerunner" was based off. The guy who had a massive hand in inspiring Gibson and others to go cyberpunk in the 80s. It's gonna be derivative in the same way that "Lord of the Rings" is derivative of "Willow" and "The Dark Crystal".
Grab.
Backlights are good, and hi-res LCDs are pretty hot these days too (I lucked out on a 17" 1280x1024 LCD at work, and I love it to bits! :-) But eyes aren't set up to look long-term at lit things, they're set up to look at things which reflect light back. Paper is just easier for eyes to look at for long periods.
Electronic ink will be the big thing to hit displays. But I don't think even that will get away from paper - flicking between pages of a book is simply quicker and easier than flicking through a document.
Grab.
Most ppl can get their typing speed up to something good enough to take notes in real time. But I doubt anyone could get their graffiti speed up to anything like handwriting level, never mind the speed of a typical good typist.
Grab.
That's the thing - we don't have to suffer. We should know the technology well enough to ensure we can keep our asses covered.
:-) If your managers are good (as mine are at my current job) then there's no need.
;-) bcos we take pride in what we do. I know I could move to a job 20 miles down the road for 5-10K more, but frankly I don't want to.
Of course, there's no need to be defensive unless your management really are a bunch of unscrupulous weasels!
My current place is pretty much a classic *good* example. Medium-size company (200-250 employees), flat management structure. You can trust the managers, right up to board level, not to stiff the employees - many of them have worked up from engineering positions so they know the score, and if you say "the customer's wrong, it'll actually take this long" then they'll fight your corner as far as it takes. And it gets real loyalty and real benefits for the company - we'll work longer hours and put ourselves out to meet a release (up to a limit, of course!
Grab.
Make sure everyone knows what estimates you gave. Or if you can't make the higher-ups aware, make sure your estimate and your disapproval of your boss's new estimate are recorded in an email to your boss. Then you take as long as it takes, and when it overruns and fingers are pointed at you, you say "I told you so" and point them to the evidence. And if you get fired/downgraded for that, there's a nice little sum waiting for you at the industrial tribunal when you bring that "constructive dismissal" case. ;-)
Re the trade-off thing, again you need to get written down what the results will be, and send it to your boss. Preferably also CC it to his boss. If the trade-off will mean more bugs, then write it down. Then when there are bugs, you have some comeback by saying "I was forced to release this code without having tested it, even though I said what the consequences were".
BTW, don't forget to check the "notify on read" and "notify on receipt" boxes when you send the email, then you actually have proof that (a) it got there, and (b) he read it. If he later claims ignorance, or says "Outlook must have eaten it", you've got evidence otherwise. Emails are your evidence when the shit hits the fan!
There are some bad managers out there. If you get one, don't be afraid to go over his head and talk to his boss, or to your personnel manager. You have a right to do that if you have a complaint about him.
And if all else fails, find another job. Seriously. If the management at your place doesn't value you, get the hell out.
Grab.
That's the theory.
;-)
Trouble is, what it actually gets is everything a *developer* wants in it, which ain't necessarily the same thing. And the developer implementing it won't necessarily write it in any way that anyone can use it effectively. And the end product becomes bloated with features that most ppl will never need, simply bcos someone thought it was "neat". Can you say "Emacs"...?
Grab.
What?! You *have* to provide more details, so we can try this!
Grab.
Depends. If ppl go straight to code, then the code *is* the design. So review the code for all of this.
If they do a detailed design first, then you should be taking the next logical step of reviewing the design against the requirements. Then the code gets reviewed against the design.
The thing is, no tool can catch the classes of bugs that are thrown up by these review steps. No tool EVER will, bcos what these steps are doing is taking a concept expressed in some customer's Word document and over a bunch of meetings and turning it into a design document and some code. Believe me, if you've found a tool that can do this, you've cracked natural languages, AI and the Turing Test in one go!
That's not to say that tools aren't useful. If you can have a tool manually search for "if(x=0)" then that's useful, so there's a good chance that you can at least catch most of the typos that way. But no tool will ever replace a review by a human.
Grab.
Re (2) and (3), having separate groups is a *really* good way to get the old "them-and-us" battle going. The testers hate the programmers bcos they see themselves as covering up for the programmers' lack of skills; the programmers hate the testers bcos the testers keep telling them that they're screwing up; and everyone hates QA for telling them how to do their job.
The problem is that very few bugs occur at the purely code stage, and most of them are easy to trace. The real problem is design bugs - they're the killers. The solution at our company is to (a) review, (b) separate development, and (c) follow a V-model quite strictly. We have one group of engineers, where everyone writes, codes, reviews and tests, and for each section, everyone will have a different role so no-one gets stuck just being the tester.
Someone writes a requirements spec, and also writes the system test spec by which they'll prove that the thing works as expected. Writing the test spec forces you to put numbers to your requirements, basically making you self-review the requirements for errors, and it find a lot of bugs. Someone else checks that the requirements spec makes sense, and also that the system test spec matches up with the requirements spec. And typically we spend over a quarter of our time at the requirements stage, bcos it's dead easy to edit a single line in a Word document but it's a helluva lot more difficult to change a zillion C files, test specs, etc.
If the system is simple, we'll go straight to code. But if the system is complex, we do a detailed design (usually in Simulink and Stateflow these days, since we're coding for embedded control systems). The person who does the design MUST NOT be the same person who wrote the requirements - this effectively gives us another review of the requirements, to catch any oddities which can't be implemented. And someone will review that the design is actually meeting the requirements.
The same person who's done the detailed design will also write a test spec to say how to test the code. This will cover all boundary conditions, so any time there's a comparison, for instance, we'd check that it gets ">=" instead of just ">". We've got an in-house tool which allows us to write test specs in Excel and run them on code automatically. And someone will review this to make sure it matches the design and covers all cases.
Then someone writes the code. The coder MUST NOT be the designer - as with the requirements/design separation, this gives us a free review. They'll put that through Lint to check for obvious problems (we follow the MISRA coding standard, with a few exceptions where MISRA didn't get it right), and then run their code through the test spec. If it fails, they'll look for the bugs in the code. Sometimes they find bugs in the test spec; in that case the test spec gets modified. Having an automated test spec means we can run tests on code with zero overhead for repeating the tests.
And then the code will be run against the system level tests, and hopefully everything passes. If it doesn't, the system level test has found a bug in the design, where the design isn't meeting the requirements. Rinse and repeat.
It's worth saying that we're writing code for automotive control systems. How much testing to do is really a trade-off of the cost of testing against the cost of failure, and in our case, failure is not an option!
Grab.
The code may not be, but the *hardware* absolutely does, and correct operation of the code is linked to the hardware it runs on. Upgrading the hardware may cause all sorts of problems with the software.
For example, at my last company we had an inventory system which dated back to the early 80s. It used VT100 dumb terminals which connected to a central location running custom software. In 1995 or so they replaced the dumb terminals with proper PCs, but it was still only possible to connect using a VT100 emulator on the PC. And they couldn't improve the link, bcos the inventory system was intimately connected to the VT100 links.
The whole dumb terminal business in itself illustrates how you'd write sofware to match hardware requirements. No-one today would try and let Diablo's central server control every bit on your screen, bcos it just isn't worth it, there's a perfectly good PC sat there which can do it much easier. Just tell the PC where each object is, and offload the display stuff onto the PC. But 20 years (and longer) back, terminals had to be dumb bcos processing was so expensive, hence VT100 as a text solution and, later, X-Windows as a GUI solution.
Point is, when you write code then you will usually make assumptions about your hardware, for example, assuming that using a 32-bit counter counting clock ticks is adequate for long timeouts. It may well have been adequate on a 1MHz 8088, but when you jump to a 1GHz Pentium then you get all sorts of problems. For another example, I've got a whole bunch of Win3.11 games which aren't usable, bcos the game designers didn't think to allow for increasing processor speeds. So the moment you hit "start", the Pacman ghosts zip round the screen like greased lightning and hit you before you can press a button!
If you took the trouble 15 years back to cater for clock speeds of 100GHz, data transfer rates of 1TB/s and data block sizes of 100TB, then your code is probably still OK today and for a few years yet. If not, like most code written way back when, then it's probably gone geriatric. You may not even be able to guarantee it'll run on new machines, so you'd only be able to run it on the old 8088 sat in the corner gathering dust. If this program happens to be something which sorts files into alphabetical or time order, then you'd be better rewriting it to run fast on new hardware than forcing it to run slowly on old hardware.
Grab.
12V lighting needs significantly larger cables (thicker copper core) - recabling an entire school would not be cheap, and the cables are more expensive (bcos copper core is more expensive than PVC coating). Fluorescent lights in place of filament lights would make a difference though.
;-)
Solar panels used for heating water are viable (pay back investment within 5 years or so), but solar panels for generating electricity won't pay back the investment in less than 20 years (assuming they last that long - most electrical things break inside 20 years, and photovoltaic cells are mounted on glass so are very vulnerable to damage).
So by spending on these, we could dump a whole bundle of money into something that gives no benefit. I think you could have chosen your "cost-saving" examples a bit better!
Having said that, you're dead right from the POV of saving money - if you need to cut costs, look at all corners. If you can buy second-hand PCs for $100 each and blow Red Hat and StarOffice onto them, and still have a useable system, then you don't need to buy top-line gear at $500 each plus another $500 for all the software.
Grab.
Compared to, say, GNU, Apache, KDE...? ;-)
Grab.
It didn't. Lucas added it about a year after the original release, when he saw it was a big success, everyone was raving about it, and he realised he could make pots of money out of it. The original didn't have that heading.
Grab.
And comparing Ep1 with the original? No fancy moves, no feet, no jumps, nothing.
Jean-Luc Besson has _much_ better things to do with his time than read teen sci-fi books. Besson nicked it from Bladerunner and Asimov's Foundation series of books, but Besson was the first to get the image onto the screen.
Grab.
If it's the beginning of the saga, the rest of the saga has to be in place. Be assured that Lucas is making this shit up as he goes along and as CGI FX get cheaper. Since Lucas apparently crapped on the SW fiction writers bigstyle (I'm not into the books, but the word is that the films are way inconsistent with the books), then I'd hazard a guess that he doesn't much care about writing a consistent saga.
Let's be honest here, the first film was never conceived as being the "fourth" film. It was only some time later that Lucas thought he could chisel some more money out by giving himself the room to do prequels.
Grab.
To literally see that, I suggest you watch "Meet the Feebles". Classic Friday night post-pub film! :-)
Grab.
Shame the film isn't up to par technically then, really. CGI that looks it, dialogue like, well, like the last film really. It's a shame really, since there's so much going for Star Wars. However, Lucas seems to have the sadiM touch - everything gold he touches turns to shit. The phrase "snatching defeat from the jaws of victory" was made for Lucas's script-writing (or should that be "the Jawas of victory"? ;-)
Grab.
What fun. So will the quality of picture increase, or will they instead fill more of the disk with pointless guff like crappy menus, interviews with the man who cleans the shoes of the second team coach driver, etc? I know which one my money's on.
Grab.
Sometimes, from other ppl. If I see it, it goes right back in review, and I won't pass the review until the fuckwit responsible has removed them. If you're writing code for yourself, then fine, please yourself. If you're writing code that anyone else will see, *especially* the customer, then hell no.
Thing is, there's two essential things that a reviewer/maintainer has to understand about a program: what it does; and why it does it. It should be possible to work out the first one of these just from the code, so long as the variables and functions are named sensibly. The second can be worked out from code with some effort, or the coder can add comments to explain why they're doing things that way and make it easier for maintainers.
But if someone has deliberately given all the variables names which don't reflect what they do, then it's utterly impossible to work out what the code is doing, and it's therefore also impossible to work out why it's doing it. So the code is unmaintainable - it isn't possible for anyone else to pick it up and work out what it does, except with massive work. If in 6 months time your company says "oh, we've got this code we can use with slight modifications, let's quote 1 month to do this contract" and then they find out you've made the code utterly obscure, then they'll crash and burn. And if that happens, the company *will* fire (or at least formally discipline) the person who wrote the original code, bcos they've been grossly negligence in doing their job. And you can kiss goodbye to any reference from them, so you'll be SOL in finding your next job.
Grab.
Yes. And it's you that needs it, since you obviously haven't bothered to find out what really happened to the Hindenburg (hint: it has _nothing_ to do with the hydrogen).
Grab.
NASA have already put up a solar-powered plane (unmanned) which IIRC holds the record for the longest time anything has stayed up without needing refuelling (or refuelling with kerosene, anyway).
Grab.
Um, hello?
You must see some _very_ strange ppl walking around. FF wasn't close to realistic, just one notch better than Toy Story 2. Bodies didn't move properly, faces didn't work, plus there were plenty of nice rectangular polygons floating around in areas where they didn't think you'd notice (hands, arms, etc). I won't start on the animators who couldn't make a character do anything without wildly exaggerated arm and body movements, bcos they said they were going for manga-style accentuated movements, so I'll let that one go. But the realism wasn't much better than Toy Story 2. The old guy was better than the others (bcos they animated him last after they'd done the others), but still pretty dodgy.
Grab.
Depends. Do you add more value than an Indian programmer? If someone at your company finds it harder to communicate with you and get you to do stuff right than they do with some guy in India, then I'd say they have no business employing you anyway! ;-) The company doesn't exist for your personal benefit - the aim is to make a profit, not to be a job-creation scheme. Eastern Europe went the way of the job-creation scheme, and that worked a real treat (for killing industry, anyway). Also bear in mind that there's extra cost in contracting stuff out to provide oversight of your contractor, so their cost per hour isn't necessarily the total cost to your business.
Thing is, you use ppl where they add value. For example, making clothes - you may contract out the actual making of clothes to Thailand or somewhere, but the value is added by the designer, and the designer is based in the US (or wherever). As an engineer, you add value by producing a good detailed design - translation from detailed design to code is pretty much a "turn-the-handle" operation which any coding monkey of any nationality can do (assuming they're competent and work to time, which is why a typical contract has penalty clauses for being late or code not matching spec).
Grab.