Last time ITT Tech was covered by any forum I read, it was soundly ridiculed as not teaching any skills worth knowing, and the certification was denounced as being utterly worthless and accepted by nobody. ITT Tech probably taught Good Governance on Numenor.
Again, which dialect? T-SQL isn't identical to PL-SQL. You are correct about NoSQL (though that's often just a fancy way to describe a subclass of key/value databases, which also includes the BerkeleyDB family, XML databases and a myriad of other styles). However, it's not limited to that. Hierarchical databases exist, as do "star" databases (data warehouses), object-oriented databases (sometimes considered a branch of NoSQL), indexed sequential databases are still a popular format,
SQL is also not a static specification. The formal definition has changed over time, though nobody actually uses the formal definition as the proprietary one is often superior by a large margin. The formal definition is only useful in identifying classes of functionality that are present/absent from any given database and to identify what extensions are unique to an implementation (such as Informix' blade design) versus being a highly custom variant of the standard.
In some cases, yes. C coding style recommendations have changed over the years. Some C dialects have died (K&R, for example) and others have grown. The standards have shifted, so those who have learned C99 will be at a disadvantage to those who know C1x for newer code -- though the reverse will be true for middle-aged code. Ancient code could be in any of a thousand dialects.
The market for C is growing, but the number of shifts from C to C++, C# or Java (or other languages) is also growing and the value of C in general in 2 years time will depend on which of those two trends grew the faster.
Not sure about glorified. Users get to scream when the feature sets change. Admins can't. Users often get to practice in other environments, it's much harder for admins to. Users get to blame admins when things fall over. Admins get to........well, turn into a paranoid, schizophrenic wreck of a human being.
I'd be wary about that "old knowledge". It may prove useful. There's LOTS of legacy software out there. I stay familiar with Fortran because it's still bloody good for numeric computations and it's uneconomic to translate old Fortran codes, which means I'm going to encounter it. I spent time learning about Intels iWARP chip (brilliant design, naff implementation) and Content Addressable Memory because these are ideas that have appeared multiple times and will therefore appear again. Understanding the principles now saves me time and effort for when they become important later on.
That's not to say I stay from the bleeding edge. I try to split my time 50:50 between the past that I may well encounter in the future (a trait that secured me my current job) and the future that I will certainly encounter in the future (a trait that secured me my jobs at NASA and Lightfleet). Both will come up, that is inevitable, but it's not possible to know in advance which one will come up first or in what way.
Generalizing is best done by making the fewest assumptions about the past, present and future that you can that will leave you enough time to learn the skills well.*
*This is important. 100 half-baked skills are of equal value to 100 highly-tuned future-only skills that turned out to be a dead-end. None whatsoever. Mastering a smaller set of transferable skills, legacy skills and future skills, thus being totally generalized, is the obvious ideal.
It also depends on when you're talking about. After the Dot-Com crash, Java programmers were hurt FAR, FAR worse than C or Fortran programmers. Shortly before Y2K, Fortran and Cobol programmers were in massive demand. (For those who argue Y2K was a hoax because nothing happened, I'd point out that after a large fortune and a larger army of coders went to work on fixing the bugs, you should have EXPECTED nothing to happen. Fixing problems after the disaster is too late.)
So the decay curve isn't a simple one. It has bounces and bottomless pits along the way.
However, and I can't stress this enough, staying current isn't merely a matter of learning the next feature of the old language set. To stay relevant, you MUST diversify. A coder should also be a damn good system admin and be capable of database admin duties as well. Being able to do tech writing as well won't hurt. You don't know what's going to be in demand tomorrow, you only know what was in demand when you last applied for work.
Programmers and systems admins shouldn't specialize on one OS either. As OS/2 demonstrated, the biggest thing out there in week 1 can be a forgotten memory by week 12. The market is slow at some times, fickle at others. You don't know how it'll be, the best thing you can do is hedge your bets. If you've covered (and stay current on) Linux, a BSD Unix variant, a SysV Unix variant, Windows Server, and at least one RTOS (doesn't matter which), you'll know 98% of everything you'll need. You can learn the specific lingo needed by a specific OS implementation quickly because that's only a 2% filler and not a 100% learn from scratch.
Although workplaces don't do sabbaticals (which is stupid), you should still plan on spending the equivalent of 1 study year for every 7 work years. (If you spend 1 hour a day practicing, relearning, or expanding your skills excluding any workside stuff, you're well in excess of what is required. I can't guarantee that an hour a day will make you invulnerable to downturns, but I can guarantee that there will never be a time, even in the worst recession, that your skills aren't in demand.)
I will talk slower for the benefit of the hard-of-thinking.
In a sequential processing system, polling cannot begin until the last event has been fully processed. Which means that if you have a button that does something really complicated, NO other button can work until that process is complete. Can you tell me the games where this is the way things are done, so I can avoid it?
In a threaded system, with CORRECT design, one event produces one interrupt produces one thread. That thread lasts the lifetime of that process, then dies. Thus, there isn't a thread per button, there's a thread per active event. Event-driven designs almost invariably use this design because you get a flat latency (ie: you're not waiting for something else to finish, which will take a non-deterministic amount of time).
My definition of real-time is indeed correct. The "short and bounded time" description of yours is the effect of guaranteeing N amount of runtime in M amount of wall-clock time (the time has to be bounded, as N cannot exceed M, and because latency has to be extremely tiny, M is classically small making N classically small.) Real-time means Extremely And Utterly Predictable, my definition says how that is achieved in real-time systems, your joke of a definition describes the consequences once it is achieved.
Clearly, you have not looked at any source code since no modern game will use polling. I suggest you try again.
RASDIT is known to any - and I mean ANY - person who has even got as far as 1st year Comp Sci or Software Engineering. If you need to google it, you're not qualified to tell those of us who are professionals how we operate or how we define things. And you can't have googled very well, I found the definition from various university papers from the UK, US and Oz.
You've never seen split-screen games with different framerates? You probably have, just not in the trivial sense. Try again. The level of changing detail (static detail is immaterial) on the screen has to be different enough for you to measure the difference, and judging by eye will be impossible so you should put the action onto disk and then run through it with an editor. Tell me then that the two players run at exactly the same rate. (No, an FPS counter isn't enough. it's trivial for games to reduce detail to increase FPS, so you actually have to go onto the screens and =measure= the level of change per user.)
Standard multiplayer games use event-driven I/O (because polling is bloody awful) and if you want simultaneous action then each event will be on one thread. You don't queue them up. Some multiplayer games opt to have one thread per player, rather than one thread per event, but that means that user input is non-deterministic. Pressing up and firing should perform exactly the same operation no matter which button made contact first. That's a parallel operation, not a sequential one.
There is generally one core engine doing the heavy lifting, but even there you parallelize the hell out of it. (You could timeslice, I suppose, but only an incredibly moronic imbecile would use 40-year-old serialized and painfully slow simulations of threading when true threading is available.)
As for the other post, no you do NOT want the perception of realtime in gaming. Realtime in software engineering has a very specific meaning (there is a fixed relationship between CPU time and wall-clock time) and that is exactly what you do NOT want in a single-player game. In a single-player game, the most important thing is that there is a fixed relationship between game time and wall-clock time. This is NOT, however, realtime. Realtime can vary the relationship between game time and wall-clock time since it fixes CPU time and less CPU intensive scenes would therefore run faster than more CPU intensive scenes.
With non-networked multiplayer games, the slight variations are going to be unimportant in comparison to each player having equal CPU resources. The intensity of processing needed for one player should not alter - by any degree whatsoever - the responsiveness of the controls of the other player. (And, yes, again you have to do that multithreaded. You can't sequentially read and process because that would add enough latency to kill the opponent right off the bat.)
My guess is that you've not looked at the source for a lot of multiplayer (or even single-player) games. I would also guess that you've very little parallel processing experience, RASDIT, or low-level engineering. (Trust me, low-level engineering is a terrifying experience if you're not a master of parallelization.)
Networking using RDMA would allow for smoother multiplayer games (since there's no OS interrupts or OS networking stack involved).
GPUs are incredibly powerful these days - throw in a few DSPs as well and you can do some computations even faster than you could achieve via GPGPU.
Consoles are aiming too low in the market - more powerful CPUs would be fine. If necessary, have more expensive peripherals and keep the console the same price.
The BBC Micro could handle RGB and Video Out at the same time, so so can a console. That means you can support things like 24bpp-32bpp, double-width monitors, etc, as well as HDTV. Restrict the user to the hardware they want rather than a specific TV standard.
At any decent speed, it's cheaper to increase the number of busses than to increase the speed of a shared bus. Even if it's a switched one like PCI Express.
Having said that, the highest-speed PCI-e and HT busses are pushing 5-8 GT/s, which should be plenty fast for a game even on a shared bus.
Since the mobo will be custom, you can actually exploit high-speed, low-latency RAM (main memory being the slowest component that is in frequent use and thus the most critical of the bottlenecks).
Yes they can. No sane person designs the logic of a program to depend on the I/O. You design the I/O as an independent module. You then probe the hardware and use the correct module for it. The game engine doesn't care if the triangles are solid green, bump-mapped, run through a shader or some other algorithm is used. Why should it? It doesn't change the game mechanics one iota.
You are forgetting, however, that individual gamers are very unlikely to play all types of game but that the complete set of gamers will play a very large range of game types. Thus, the OS must be more generic than necessary and therefore de-optimized for actual usage. Yes, average gamers might make things worse, just as average home users could screw up their DSL or cable modem by compiling their own firmware. I doubt many average home users have done so, even though they actually CAN do this and nothing is locked down (well, for most systems).
An intense network game player might very well want to port Web10G to their console's OS so that they can tune the hell out of the networking. If you're playing single-player games, you want raw speed. If you're playing two-player console games, you want absolute smoothness between the threads. Raw speed vs real-time (the two are not the same and are often mutually exclusive).
I'm not terribly impressed by any current console. In terms of console capability vs. computer ability of the same era, even the Colecovision did better. Consoles could be a hell of a lot better - and should be. Of course, not having an R&D budget, I won't be able to put one together to prove this, but it's easy to infer from the fact that the GPU is virtually everything and high-end gaming machines still sell in significant numbers. Why would you want an expensive gaming machine that uses sub-optimal off-the-shelf parts rather than a console that has a motherboard designed specifically for that one purpose alone? Answer: because people are expecting more and aren't getting it any other way.
Dunno about the Bad Astronomer, but *my* conclusion is that everyone would be better served if "ancient alien" and "ghost-hunting" programs were shifted off channels like History and Discovery and onto something dedicated to "off-beat" theories. I disagree with censorship, but I also disagree with mixing educational documentaries and conspiracy theorists on the same channel. You either dilute the value of the educational stuff or you give false credibility to the nutcases.
This isn't to say that I believe the channels shouldn't air unorthodox views - they should, provided it is good science. Nor am I saying that the channels should show all documentaries that fit the orthodoxy - if it's pseudoscience, it's pseudoscience no matter who it agrees with. In fact, I'd be more worried about bad science that attempts to "prove" something that is true, since that is more likely to pervert the casual viewer's ability to critically reason.
These "science" channels are a big reason why we're becoming an Idiocracy.
Brian Cox and Jeff Forshaw recently tried to answer questions on the big bang and other curios of modern cosmology in The Guardian newspaper. It's hard to tell if they were dumbing down the science for the readers, but the general consensus was that their explanations were neither helpful nor informative. This isn't an indictment of their abilities, as there have been countless celebrity scientists in the media who have made a pig's ear of explaining things. Now, science SHOULD be explained, but clearly the level of the explanations needs work.
Assuming the objective is to reduce misunderstandings, what would be the right level to pitch the more complex aspects of astronomy and cosmology?
Never quite understood the idea of remotely switching a satellite off when de-orbiting it. You'd want to switch off any non-command channel transmitter, sure, as that could interfere with other satellites, but there's no obvious reason to switch off any command channel stuff and this isn't the sort of crash you want to be able to reboot from. Now, I'll throw in one proviso in there - you DO want the computer system switching off once the thermal conditions go out of range, as you don't want a partially-functioning system sending random messages that could mess with the trajectory. But you absolutely want to have the satellite on a controlled descent for as long as possible (ideally via a mix of ground control and on-board computer, since you don't want control lost if the link is lost).
The whooshing sound you hear is the incredibly large number of theoretical satellites you'd need to be able to model the upper atmosphere (plus the fact that you can't treat the extreme upper atmosphere as a fluid).
Yes, the space weather affects things, but we monitor that increasingly. It can be modeled. Not in fine detail, but in aggregate, as indeed can the weather. You may not be able to compute the exact trajectory (you can actually prove you can't, since it's a chaotic system) but you can improve your estimation of the probability of any individual trajectory.
You run the simulation through a CFD package, compare the prediction with reality, and tweak the parameters for the upper atmosphere accordingly. Keep crashing satellites until you consistently get good results. Problem solved.
Shooting a movie shouldn't be an issue unless it could have an effect on the ecosystem or would require some form of construction.
I certainly agree there, though there are times when that would apply to a regular person using a video camera - there are plenty of extremely fragile ecosystems. However, in the case where an ecosystem is that fragile, conservation laws aught to be in effect and permits shouldn't exist. If there are permits, then the ecosystem is declared as not being fragile since the authorities are claiming that there can be cases when large film crews, support trucks, lighting and the inevitable trash that results are perfectly acceptable.
So either NH is confessing to being incompetent at conservation or it's abusing the permit system. It can't not be one of those, but in the interests of fairness we shouldn't assume it's the latter. After all, the scientific method suggests we should not blame on malice that which can be explained equally well by stupidity (the simpler, and more common, cause).
Slashdot Mirror
Last time ITT Tech was covered by any forum I read, it was soundly ridiculed as not teaching any skills worth knowing, and the certification was denounced as being utterly worthless and accepted by nobody. ITT Tech probably taught Good Governance on Numenor.
Again, which dialect? T-SQL isn't identical to PL-SQL. You are correct about NoSQL (though that's often just a fancy way to describe a subclass of key/value databases, which also includes the BerkeleyDB family, XML databases and a myriad of other styles). However, it's not limited to that. Hierarchical databases exist, as do "star" databases (data warehouses), object-oriented databases (sometimes considered a branch of NoSQL), indexed sequential databases are still a popular format,
SQL is also not a static specification. The formal definition has changed over time, though nobody actually uses the formal definition as the proprietary one is often superior by a large margin. The formal definition is only useful in identifying classes of functionality that are present/absent from any given database and to identify what extensions are unique to an implementation (such as Informix' blade design) versus being a highly custom variant of the standard.
In some cases, yes. C coding style recommendations have changed over the years. Some C dialects have died (K&R, for example) and others have grown. The standards have shifted, so those who have learned C99 will be at a disadvantage to those who know C1x for newer code -- though the reverse will be true for middle-aged code. Ancient code could be in any of a thousand dialects.
The market for C is growing, but the number of shifts from C to C++, C# or Java (or other languages) is also growing and the value of C in general in 2 years time will depend on which of those two trends grew the faster.
Not sure about glorified. Users get to scream when the feature sets change. Admins can't. Users often get to practice in other environments, it's much harder for admins to. Users get to blame admins when things fall over. Admins get to.... ....well, turn into a paranoid, schizophrenic wreck of a human being.
I'd be wary about that "old knowledge". It may prove useful. There's LOTS of legacy software out there. I stay familiar with Fortran because it's still bloody good for numeric computations and it's uneconomic to translate old Fortran codes, which means I'm going to encounter it. I spent time learning about Intels iWARP chip (brilliant design, naff implementation) and Content Addressable Memory because these are ideas that have appeared multiple times and will therefore appear again. Understanding the principles now saves me time and effort for when they become important later on.
That's not to say I stay from the bleeding edge. I try to split my time 50:50 between the past that I may well encounter in the future (a trait that secured me my current job) and the future that I will certainly encounter in the future (a trait that secured me my jobs at NASA and Lightfleet). Both will come up, that is inevitable, but it's not possible to know in advance which one will come up first or in what way.
Generalizing is best done by making the fewest assumptions about the past, present and future that you can that will leave you enough time to learn the skills well.*
*This is important. 100 half-baked skills are of equal value to 100 highly-tuned future-only skills that turned out to be a dead-end. None whatsoever. Mastering a smaller set of transferable skills, legacy skills and future skills, thus being totally generalized, is the obvious ideal.
It also depends on when you're talking about. After the Dot-Com crash, Java programmers were hurt FAR, FAR worse than C or Fortran programmers. Shortly before Y2K, Fortran and Cobol programmers were in massive demand. (For those who argue Y2K was a hoax because nothing happened, I'd point out that after a large fortune and a larger army of coders went to work on fixing the bugs, you should have EXPECTED nothing to happen. Fixing problems after the disaster is too late.)
So the decay curve isn't a simple one. It has bounces and bottomless pits along the way.
However, and I can't stress this enough, staying current isn't merely a matter of learning the next feature of the old language set. To stay relevant, you MUST diversify. A coder should also be a damn good system admin and be capable of database admin duties as well. Being able to do tech writing as well won't hurt. You don't know what's going to be in demand tomorrow, you only know what was in demand when you last applied for work.
Programmers and systems admins shouldn't specialize on one OS either. As OS/2 demonstrated, the biggest thing out there in week 1 can be a forgotten memory by week 12. The market is slow at some times, fickle at others. You don't know how it'll be, the best thing you can do is hedge your bets. If you've covered (and stay current on) Linux, a BSD Unix variant, a SysV Unix variant, Windows Server, and at least one RTOS (doesn't matter which), you'll know 98% of everything you'll need. You can learn the specific lingo needed by a specific OS implementation quickly because that's only a 2% filler and not a 100% learn from scratch.
Although workplaces don't do sabbaticals (which is stupid), you should still plan on spending the equivalent of 1 study year for every 7 work years. (If you spend 1 hour a day practicing, relearning, or expanding your skills excluding any workside stuff, you're well in excess of what is required. I can't guarantee that an hour a day will make you invulnerable to downturns, but I can guarantee that there will never be a time, even in the worst recession, that your skills aren't in demand.)
I will talk slower for the benefit of the hard-of-thinking.
In a sequential processing system, polling cannot begin until the last event has been fully processed. Which means that if you have a button that does something really complicated, NO other button can work until that process is complete. Can you tell me the games where this is the way things are done, so I can avoid it?
In a threaded system, with CORRECT design, one event produces one interrupt produces one thread. That thread lasts the lifetime of that process, then dies. Thus, there isn't a thread per button, there's a thread per active event. Event-driven designs almost invariably use this design because you get a flat latency (ie: you're not waiting for something else to finish, which will take a non-deterministic amount of time).
My definition of real-time is indeed correct. The "short and bounded time" description of yours is the effect of guaranteeing N amount of runtime in M amount of wall-clock time (the time has to be bounded, as N cannot exceed M, and because latency has to be extremely tiny, M is classically small making N classically small.) Real-time means Extremely And Utterly Predictable, my definition says how that is achieved in real-time systems, your joke of a definition describes the consequences once it is achieved.
Clearly, you have not looked at any source code since no modern game will use polling. I suggest you try again.
RASDIT is known to any - and I mean ANY - person who has even got as far as 1st year Comp Sci or Software Engineering. If you need to google it, you're not qualified to tell those of us who are professionals how we operate or how we define things. And you can't have googled very well, I found the definition from various university papers from the UK, US and Oz.
You've never seen split-screen games with different framerates? You probably have, just not in the trivial sense. Try again. The level of changing detail (static detail is immaterial) on the screen has to be different enough for you to measure the difference, and judging by eye will be impossible so you should put the action onto disk and then run through it with an editor. Tell me then that the two players run at exactly the same rate. (No, an FPS counter isn't enough. it's trivial for games to reduce detail to increase FPS, so you actually have to go onto the screens and =measure= the level of change per user.)
Well, no. It doesn't. It's useful for tracing where a given person has been precisely because caesium is picked up by bones.
Standard multiplayer games use event-driven I/O (because polling is bloody awful) and if you want simultaneous action then each event will be on one thread. You don't queue them up. Some multiplayer games opt to have one thread per player, rather than one thread per event, but that means that user input is non-deterministic. Pressing up and firing should perform exactly the same operation no matter which button made contact first. That's a parallel operation, not a sequential one.
There is generally one core engine doing the heavy lifting, but even there you parallelize the hell out of it. (You could timeslice, I suppose, but only an incredibly moronic imbecile would use 40-year-old serialized and painfully slow simulations of threading when true threading is available.)
As for the other post, no you do NOT want the perception of realtime in gaming. Realtime in software engineering has a very specific meaning (there is a fixed relationship between CPU time and wall-clock time) and that is exactly what you do NOT want in a single-player game. In a single-player game, the most important thing is that there is a fixed relationship between game time and wall-clock time. This is NOT, however, realtime. Realtime can vary the relationship between game time and wall-clock time since it fixes CPU time and less CPU intensive scenes would therefore run faster than more CPU intensive scenes.
With non-networked multiplayer games, the slight variations are going to be unimportant in comparison to each player having equal CPU resources. The intensity of processing needed for one player should not alter - by any degree whatsoever - the responsiveness of the controls of the other player. (And, yes, again you have to do that multithreaded. You can't sequentially read and process because that would add enough latency to kill the opponent right off the bat.)
My guess is that you've not looked at the source for a lot of multiplayer (or even single-player) games. I would also guess that you've very little parallel processing experience, RASDIT, or low-level engineering. (Trust me, low-level engineering is a terrifying experience if you're not a master of parallelization.)
Have they checked under the sofa cushions?
A lot is possible with today's technology.
Yes they can. No sane person designs the logic of a program to depend on the I/O. You design the I/O as an independent module. You then probe the hardware and use the correct module for it. The game engine doesn't care if the triangles are solid green, bump-mapped, run through a shader or some other algorithm is used. Why should it? It doesn't change the game mechanics one iota.
You are forgetting, however, that individual gamers are very unlikely to play all types of game but that the complete set of gamers will play a very large range of game types. Thus, the OS must be more generic than necessary and therefore de-optimized for actual usage. Yes, average gamers might make things worse, just as average home users could screw up their DSL or cable modem by compiling their own firmware. I doubt many average home users have done so, even though they actually CAN do this and nothing is locked down (well, for most systems).
An intense network game player might very well want to port Web10G to their console's OS so that they can tune the hell out of the networking. If you're playing single-player games, you want raw speed. If you're playing two-player console games, you want absolute smoothness between the threads. Raw speed vs real-time (the two are not the same and are often mutually exclusive).
I'm not terribly impressed by any current console. In terms of console capability vs. computer ability of the same era, even the Colecovision did better. Consoles could be a hell of a lot better - and should be. Of course, not having an R&D budget, I won't be able to put one together to prove this, but it's easy to infer from the fact that the GPU is virtually everything and high-end gaming machines still sell in significant numbers. Why would you want an expensive gaming machine that uses sub-optimal off-the-shelf parts rather than a console that has a motherboard designed specifically for that one purpose alone? Answer: because people are expecting more and aren't getting it any other way.
Hmmmm. That might not be such a bad idea. They could then move Destroy-Build-Destroy to the shopping network.
Dunno about the Bad Astronomer, but *my* conclusion is that everyone would be better served if "ancient alien" and "ghost-hunting" programs were shifted off channels like History and Discovery and onto something dedicated to "off-beat" theories. I disagree with censorship, but I also disagree with mixing educational documentaries and conspiracy theorists on the same channel. You either dilute the value of the educational stuff or you give false credibility to the nutcases.
This isn't to say that I believe the channels shouldn't air unorthodox views - they should, provided it is good science. Nor am I saying that the channels should show all documentaries that fit the orthodoxy - if it's pseudoscience, it's pseudoscience no matter who it agrees with. In fact, I'd be more worried about bad science that attempts to "prove" something that is true, since that is more likely to pervert the casual viewer's ability to critically reason.
These "science" channels are a big reason why we're becoming an Idiocracy.
Brian Cox and Jeff Forshaw recently tried to answer questions on the big bang and other curios of modern cosmology in The Guardian newspaper. It's hard to tell if they were dumbing down the science for the readers, but the general consensus was that their explanations were neither helpful nor informative. This isn't an indictment of their abilities, as there have been countless celebrity scientists in the media who have made a pig's ear of explaining things. Now, science SHOULD be explained, but clearly the level of the explanations needs work.
Assuming the objective is to reduce misunderstandings, what would be the right level to pitch the more complex aspects of astronomy and cosmology?
Never quite understood the idea of remotely switching a satellite off when de-orbiting it. You'd want to switch off any non-command channel transmitter, sure, as that could interfere with other satellites, but there's no obvious reason to switch off any command channel stuff and this isn't the sort of crash you want to be able to reboot from. Now, I'll throw in one proviso in there - you DO want the computer system switching off once the thermal conditions go out of range, as you don't want a partially-functioning system sending random messages that could mess with the trajectory. But you absolutely want to have the satellite on a controlled descent for as long as possible (ideally via a mix of ground control and on-board computer, since you don't want control lost if the link is lost).
The whooshing sound you hear is the incredibly large number of theoretical satellites you'd need to be able to model the upper atmosphere (plus the fact that you can't treat the extreme upper atmosphere as a fluid).
Yes, the space weather affects things, but we monitor that increasingly. It can be modeled. Not in fine detail, but in aggregate, as indeed can the weather. You may not be able to compute the exact trajectory (you can actually prove you can't, since it's a chaotic system) but you can improve your estimation of the probability of any individual trajectory.
You run the simulation through a CFD package, compare the prediction with reality, and tweak the parameters for the upper atmosphere accordingly. Keep crashing satellites until you consistently get good results. Problem solved.
I certainly agree there, though there are times when that would apply to a regular person using a video camera - there are plenty of extremely fragile ecosystems. However, in the case where an ecosystem is that fragile, conservation laws aught to be in effect and permits shouldn't exist. If there are permits, then the ecosystem is declared as not being fragile since the authorities are claiming that there can be cases when large film crews, support trucks, lighting and the inevitable trash that results are perfectly acceptable.
So either NH is confessing to being incompetent at conservation or it's abusing the permit system. It can't not be one of those, but in the interests of fairness we shouldn't assume it's the latter. After all, the scientific method suggests we should not blame on malice that which can be explained equally well by stupidity (the simpler, and more common, cause).
Well, it's better than Bigfoot telling reporters that he's quaternion.
That's why New Zealand is already working on cloning Moas. Plenty of meat for T Rex and the KFC fast food chains to divide between them.
Just remember, feeding politicians to the keas is a bad idea - their natural diet is nuts and the added protein would be bad for them.
There's actually a quite remarkable web server written in postscript.
They're going to take it to an island off New Zealand and clone it?