Ninety minutes is the minimum flight time, since China has no water recovery fleet and the vehicle isn't design for splash down. Assuming they want it to land back in China, it has to go at least once around.
That may be all they're planning on. With more than a couple of orbits the ground track will be such that they can't land in China until the Earth and orbit track synch up again. I haven't looked at the likely orbital inclination to figure it out, but that could well be nearly 24 hours (16 or 17 orbits) after launch.
Presumably if all goes well during the first orbit, and they have the consumables (power, O2, etc) aboard, they could go for further orbits, but they may plan on taking it cautiously.
You'll get tons of code out of a well working team
Sure, that's well documented in studies of software engineering economics. So is the fact that in a field like programming, there can be an order of magnitude difference in productivity between two individuals. If you have people like that, you're better off organizing the team like Mills' "Chief Programmer Teams" (what Brooks calls "Surgical Teams").
I don't think anyone has investigated whether that difference correlates with being a smelly polyglot mathematician in either a positive or negative sense. I rather suspect it doesn't correlate at all. My guess, though, is that high IQ helps, but is not the sole predictor. (I know plenty of high IQ people that can't program their way out of a paper bag, so to speak.)
Well, top-down programming is just called top-down programming. It's an idea that sounds good in theory, and helps in decomposing problems. However, if you're not careful, at the low levels you end up with a serious mismatch between your design details and the available APIs and libraries.
At each iteration, you're supposed to identify and address the most significant risks in the project.
Most significant risk, or that which gives you the most functionality for a given effort (bang for the buck)? Depends how you define "risk" and "functionality", I suppose.
We have hundreds of years of experience in building bridges,
And yet they still sometimes fall down. See e.g. Tacoma Narrows, Kanas City Hyatt Skywalk, etc. (These were design failures, not maintenance failures; plenty of bridges fail through wear and tear and bad maintenance, whereas with software "bit-rot" doesn't really happen if you don't change anything.)
We actually do not know how to build a software, not even what a software is.
Speak for yourself.
the only way to find out a decent design is to implement it.
Design by trial and error? I don't think so. If you can't come up with a software design, it's because the problem (the requirements) is itself not well understood (unless you're just an incompetent designer). Now true, there have been many attempts to design software for problem domains that were not well understood (which certainly includes some business situations as well as hard problems like machine vision or natural language understanding). But if you don't understand the problem domain, you shouldn't be trying to design software for it in the first place (except as a research tool to help better understand the problem domain, perhaps).
How can something that is unknown be designed?
Remember those "analysis" and "requirements gathering" steps?
For software already implemented we can use all these fancy design methods to reimplement it,
Why reinvent the wheel? Change the first part to "for well understood problem domains" and I'll agree.
But software designers are not like bridge designers. Bridge designers know what they are doing.
I'm not sure WHY they seem to think that pair-programming is an absolute must with XP, but all the shops using it seem to think so.
Because it works, for several reasons.
First, with an approach like XP (or the somewhat looser Scrum), you're pretty much discarding the conventional design phase and everything that goes with it, like design documents. That means, other than the code itself, there's no "institutional memory" of why the code is the way it is, beyond what's in the memories of the programmer who wrote it. Documented code helps, as do code reviews. Think of pair programming in this sense as a very intense design and code review rolled into one. (This also ties into the skills transfer mentioned in another post).
Designing, moreso than coding, is easier if you have somebody to bounce ideas off of. You can keep each other on track, or come up with an approach the other hasn't thought of. Witht the XP approach you're doing some of the design work at the keyboard while programming -- so better to have two of you.
More subtly, but perhaps most significantly, it promotes team-building, especially if you pair with various team members rather than the same person all the time. This is not just a fuzzy feel-good management thing. Barry Boehm, who literally wrote the book on determining the costs of a software project, found that the largest factor, by far, in a development team's success is the quality of the team. (This after factoring out things like language or application experience.) Pair-programming (and XP) works because it helps build good teams.
There are other ways to achieve that, of course, which is good because XP is not suited to all domains. But I think that's a factor overlooked in the analysis of why it does work.
On the other hand, a company that pays no attention to job titles and swaps around, say, secretaries and developers because they both just sit at keyboards all day is probably also beyond hope.
Job titles serve a purpose, but sure, they shouldn't get in the way, either.
That's a rocket, not a spacecraft. It's in the air for a few minutes, at most -- not on say a multiyear trip to the outer solar system or even a multiyear stay in GEO.
Plenty of rockets do just fine with no software at all, I've launched a few of same myself.
Oh, they're separate jobs, yes, but with overlapping skill sets. I'll certainly agree with you that a designer who hasn't gotten his hands dirty with code in several years is probably going to turn out suboptimal designs. Likewise, a programmer who knows nothing about design is going to have to be spoonfed everything.
But they are separate jobs. A designer certainly has to know the capabilities and paradigms of a given language and APIs, just the same way as a bridge designer has to know the properties of steel and concrete, and usual construction techniques. But just as the latter doesn't have to know how to pour concrete or weld steel (although it certainly helps if they've done that at some time in their career), the former doesn't have to know details that a programmer should, such as how to write a makefile or configure Ant.
Having a design (or at least a set of requirements) probably helps too.
Perhaps you're of the old school and were rolling all the other job titles like analyst, architect, designer, coder and tester into the "programmer" umbrella, but these days that term is mostly synonymous with "coder" with a bit of "designer" thrown in. (Come to think of it, even in the old days "analyst" was separate, and I've had the job title "Programmer-Analyst" -- which is not a psychiatrist for coders;-)
Who hates the idea of pair programming? Smarties ofcourse. They dont want to lose what they feel makes them special.
More likely they're just driven insane by having to wait on the other person. Depends on how bad an impedence mismatch you have. Programmer productivity can vary by an order of magnitude or more between individuals (so called "superprogrammers", although the term is silly). If you have one of the latter, no amount of "skill transference" is going to bring the former up to the same speed, any more than teaming someone with an IQ of 150 with someone with an IQ of 110 is going to raise the latter's IQ to 130. (It might, through frustration, lower the former's though;-)
On the other hand, if you're just talking about a couple of average programmers, one of whom has a couple of years more experience, then yeah, it makes sense.
They are bad for business anyways.
Depends. Nobody needs prima donnas, of course (well, except ballet companies, I suppose;-) but do you just want a stable of predictable but average programmers, or do you want to hold on to those "smarties" who, in a pinch, can deliver good code faster than any eight other programmers put together?
(Of course, you may not have the choice. Superprogrammers aren't nearly as prevalent as the number of average programmers who think they're "super" would indicate;-)
Q: What do you get when you combine the waterfall model with the spiral approach?
A: The flush model.
On a more serious note, the waterfall model does work for certain problem domains, notably those where the requirements are well understood in advance and unlikely to change significantly over the course of development, and where reliability of the final product is critical. This assumes you have the resources (time and people) to do it properly -- and this is why the waterfall method has gotten a bad reputation -- it's been applied where there is insufficient time/resources or the requirements aren't well understood.
Most business applications, for example. The waterfull method is wonderfully suited to something like spacecraft control software, where the spiral approach (we called it "stepwise refinement" twenty-five years ago when I was in college -- there's nothing new) just wouldn't work. But businesses are both constantly changing and adaptable -- a business app that only implements half the requested features is probably still more useful than not, where as software to control complex hardware that's only half done is nearly useless (except that some testing can be done, perhaps).
As always, it's a matter of picking the right tool for the job, rather than picking up your hammer and treating everything as a nail.
Of course, not every application uses local connections - networked apps don't have the option of shared memory.
No, but every application has access to the X server, through which they can communicate. Okay, granted, the programmers have to figure out the ICCCM, which seems to be too much like hard work for a lot of them...
A couple of reasons. One is that the underlying toolkits (Qt and GTK+) are not optimized for X. They're both portable toolkits, so one expects some compromises, and they're both based directly on Xlib rather than on the X Toolkit Intrinsics (Xt). While theoretically this could make them faster than Xt-based kits, it deprives them of the years of performance tuning by expert X programmers that Xt has gone through.
The other reason is that both KDE and Gnome are "desktop systems", not just window managers, and have tons of stuff going on in the background (such as their flavors of CORBA), plus processes for the taskbar, etc.
By the way, KDE and Gnome are not monolithic apps as you seem to think, they do use separate apps for many of the tasks you mention -- but they're also all tied together by the corba-equivalent (so that, for example, a settings app can tell the desktop to change appearance), the messaging functions of which are provided in Windows by the OS layer (and which also duplicates a lot of what the X Server could do for you).
(All that said, on any reasonable hardware not more than a few years old, KDE or Gnome should still be fast enough for most users. Most of the cycles are still going to be spent waiting for the user.)
By replacing Unix domain sockets with hyperqueues (about twice as fast), and the X protocol with XML (an expansion of what, 5 times, 10 times?) you expect things to get faster? Somebody needs to check their math.
How about just adding a hyperqueue option to X?
(And yeah, I know, the X Server isn't the bottleneck anyway. Heck, you can implement an X server in Java and still get reasonable performance (well, to a point), so it's clearly not the bottleneck.)
Oh, Red Dwarf is wonderful. I hope you're not suggesting that the effects are realistic, though. (Rather well done, yes, but not realistic from a Hollywood perspective.)
Galaxy Quest had well-done cheesy effects. That is, the FX themselves were well done, but the ship itself was imitating one from a cheesy TV show -- complete with the video game like sequence where Sigourney Weaver asks something like "why does a starship even have something like this?".
However, I'm beginning to come around to the point of view that a high-budget HHGTTG could survive great effects and sets so long as they have the same irreverant feel to them. After all the TV series didn't quite look like it was done with old cardboard and spray paint.;-)
The MiB aliens were rendered realistically, but they weren't convincing as something that could actually exist -- photorealistic cartoon figures, if you will. (Mind, a lot of "serious" sci-fi movies suffer this same problem...)
(BTW, a great example of this done deliberately is the "scrat" character (the saber-tooth squirrel rat) in "Ice Age". That deliberately goes through some Chuck-Jonesish morphs (eg when squeezed between the two glaciers) for the added humor. Although Ice Age is just 3D animation, not an attempt at photorealism.)
And yes, agree with your points about the fans' expectations.
I guess I didn't make it explicit enough, but from context, I meant "a sci-fi comedy [with realistic SFX] movie that really worked".
By "realistic" I don't just mean "well done", but also "depicts something that could be real". The aliens in MiB were well rendered, but not convincing as "real". That's part of the humor.
Exactly. But by extension there are probably some media where there just aren't any funny jokes (or, more likely, the skill needed to come up with same eludes any artist to date.)
The TV version of HHGTTG works because (a) they cut a lot of the stuff that wouldn't have worked on TV (fortunately they had a lot of material to start with), and (b) it was TV, not a movie, and the budget FX were okay.
Offhand I can't think of a sci-fi comedy movie that really worked. Sure, there are "action comedies" like Men In Black (but again, how realistic were the weapons and aliens?), and there was "Dark Star" -- the latter complete with cheesy effects.
It may have something to with the different levels of "suspension of disbelief". The comedy of HHGTTG, or Dark Star, or even a Chuck Jones cartoon takes place in a universe of completely different physical laws (Wiley Coyote cartoons especially!). High-FX budget SF movies also take liberties with the laws of physics, but try to do so with explanations and "realistic" effects to lower your "suspension of disbelief" threshold.
Would the coyote trying to chase the road runner through a "tunnel" he'd painted on a rock be nearly as funny if, instead of just a painted hole, there was some stargate-like device rigged up that actually let the road runner on through while shutting down in time for the coyote to smack into the rock? Would Pinback chasing the alien with a broom be as funny if the alien didn't look like a beachball with rubber feet?
Remember, Arthur Dent goes around most of the time not really knowing what's going on (he never could get the hang of Thursdays). Palin does that role wonderfully. (Think Arthur Pewty. Or the marriage counselor sketch.)
No matter how good the special effects in the film, on the Radio the pictures are better.
Yes. There's a classic radio sequence -- alas, I can't remember who did it -- that addresses this very point. They make the world's biggest ice cream sundae out of Lake Erie, complete with (IIRC) a fleet of B-52s to top it with the world's biggest cherry.
Yeah, with CG you could do it in film or video, but it wouldn't be as funny.
Slashdot Mirror
Ninety minutes is the minimum flight time, since China has no water recovery fleet and the vehicle isn't design for splash down. Assuming they want it to land back in China, it has to go at least once around.
That may be all they're planning on. With more than a couple of orbits the ground track will be such that they can't land in China until the Earth and orbit track synch up again. I haven't looked at the likely orbital inclination to figure it out, but that could well be nearly 24 hours (16 or 17 orbits) after launch.
Presumably if all goes well during the first orbit, and they have the consumables (power, O2, etc) aboard, they could go for further orbits, but they may plan on taking it cautiously.
Interesting anecdote, but your point was...?
You'll get tons of code out of a well working team
Sure, that's well documented in studies of software engineering economics. So is the fact that in a field like programming, there can be an order of magnitude difference in productivity between two individuals. If you have people like that, you're better off organizing the team like Mills' "Chief Programmer Teams" (what Brooks calls "Surgical Teams").
I don't think anyone has investigated whether that difference correlates with being a smelly polyglot mathematician in either a positive or negative sense. I rather suspect it doesn't correlate at all. My guess, though, is that high IQ helps, but is not the sole predictor. (I know plenty of high IQ people that can't program their way out of a paper bag, so to speak.)
Those are the ones most likely to be outsourced overseas.
Heh. Good point, at least for commercial apps.
I'll get really nervous when that starts happening for military and aerospace stuff (the sort of thing that's all written in Ada).
Well, top-down programming is just called top-down programming. It's an idea that sounds good in theory, and helps in decomposing problems. However, if you're not careful, at the low levels you end up with a serious mismatch between your design details and the available APIs and libraries.
At each iteration, you're supposed to identify and address the most significant risks in the project.
Most significant risk, or that which gives you the most functionality for a given effort (bang for the buck)? Depends how you define "risk" and "functionality", I suppose.
We have hundreds of years of experience in building bridges,
And yet they still sometimes fall down. See e.g. Tacoma Narrows, Kanas City Hyatt Skywalk, etc. (These were design failures, not maintenance failures; plenty of bridges fail through wear and tear and bad maintenance, whereas with software "bit-rot" doesn't really happen if you don't change anything.)
We actually do not know how to build a software, not even what a software is.
Speak for yourself.
the only way to find out a decent design is to implement it.
Design by trial and error? I don't think so. If you can't come up with a software design, it's because the problem (the requirements) is itself not well understood (unless you're just an incompetent designer). Now true, there have been many attempts to design software for problem domains that were not well understood (which certainly includes some business situations as well as hard problems like machine vision or natural language understanding). But if you don't understand the problem domain, you shouldn't be trying to design software for it in the first place (except as a research tool to help better understand the problem domain, perhaps).
How can something that is unknown be designed?
Remember those "analysis" and "requirements gathering" steps?
For software already implemented we can use all these fancy design methods to reimplement it,
Why reinvent the wheel? Change the first part to "for well understood problem domains" and I'll agree.
But software designers are not like bridge designers. Bridge designers know what they are doing.
See examples above. And read some Petroski.
I'm not sure WHY they seem to think that pair-programming is an absolute must with XP, but all the shops using it seem to think so.
Because it works, for several reasons.
First, with an approach like XP (or the somewhat looser Scrum), you're pretty much discarding the conventional design phase and everything that goes with it, like design documents. That means, other than the code itself, there's no "institutional memory" of why the code is the way it is, beyond what's in the memories of the programmer who wrote it. Documented code helps, as do code reviews. Think of pair programming in this sense as a very intense design and code review rolled into one. (This also ties into the skills transfer mentioned in another post).
Designing, moreso than coding, is easier if you have somebody to bounce ideas off of. You can keep each other on track, or come up with an approach the other hasn't thought of. Witht the XP approach you're doing some of the design work at the keyboard while programming -- so better to have two of you.
More subtly, but perhaps most significantly, it promotes team-building, especially if you pair with various team members rather than the same person all the time. This is not just a fuzzy feel-good management thing. Barry Boehm, who literally wrote the book on determining the costs of a software project, found that the largest factor, by far, in a development team's success is the quality of the team. (This after factoring out things like language or application experience.) Pair-programming (and XP) works because it helps build good teams.
There are other ways to achieve that, of course, which is good because XP is not suited to all domains. But I think that's a factor overlooked in the analysis of why it does work.
On the other hand, a company that pays no attention to job titles and swaps around, say, secretaries and developers because they both just sit at keyboards all day is probably also beyond hope.
Job titles serve a purpose, but sure, they shouldn't get in the way, either.
That's a rocket, not a spacecraft. It's in the air for a few minutes, at most -- not on say a multiyear trip to the outer solar system or even a multiyear stay in GEO.
Plenty of rockets do just fine with no software at all, I've launched a few of same myself.
Oh, they're separate jobs, yes, but with overlapping skill sets. I'll certainly agree with you that a designer who hasn't gotten his hands dirty with code in several years is probably going to turn out suboptimal designs. Likewise, a programmer who knows nothing about design is going to have to be spoonfed everything.
But they are separate jobs. A designer certainly has to know the capabilities and paradigms of a given language and APIs, just the same way as a bridge designer has to know the properties of steel and concrete, and usual construction techniques. But just as the latter doesn't have to know how to pour concrete or weld steel (although it certainly helps if they've done that at some time in their career), the former doesn't have to know details that a programmer should, such as how to write a makefile or configure Ant.
Having a design (or at least a set of requirements) probably helps too.
;-)
Perhaps you're of the old school and were rolling all the other job titles like analyst, architect, designer, coder and tester into the "programmer" umbrella, but these days that term is mostly synonymous with "coder" with a bit of "designer" thrown in. (Come to think of it, even in the old days "analyst" was separate, and I've had the job title "Programmer-Analyst" -- which is not a psychiatrist for coders
Who hates the idea of pair programming? Smarties ofcourse. They dont want to lose what they feel makes them special.
;-)
;-) but do you just want a stable of predictable but average programmers, or do you want to hold on to those "smarties" who, in a pinch, can deliver good code faster than any eight other programmers put together?
;-)
More likely they're just driven insane by having to wait on the other person. Depends on how bad an impedence mismatch you have. Programmer productivity can vary by an order of magnitude or more between individuals (so called "superprogrammers", although the term is silly). If you have one of the latter, no amount of "skill transference" is going to bring the former up to the same speed, any more than teaming someone with an IQ of 150 with someone with an IQ of 110 is going to raise the latter's IQ to 130. (It might, through frustration, lower the former's though
On the other hand, if you're just talking about a couple of average programmers, one of whom has a couple of years more experience, then yeah, it makes sense.
They are bad for business anyways.
Depends. Nobody needs prima donnas, of course (well, except ballet companies, I suppose
(Of course, you may not have the choice. Superprogrammers aren't nearly as prevalent as the number of average programmers who think they're "super" would indicate
Q: What do you get when you combine the waterfall model with the spiral approach?
A: The flush model.
On a more serious note, the waterfall model does work for certain problem domains, notably those where the requirements are well understood in advance and unlikely to change significantly over the course of development, and where reliability of the final product is critical. This assumes you have the resources (time and people) to do it properly -- and this is why the waterfall method has gotten a bad reputation -- it's been applied where there is insufficient time/resources or the requirements aren't well understood.
Most business applications, for example. The waterfull method is wonderfully suited to something like spacecraft control software, where the spiral approach (we called it "stepwise refinement" twenty-five years ago when I was in college -- there's nothing new) just wouldn't work. But businesses are both constantly changing and adaptable -- a business app that only implements half the requested features is probably still more useful than not, where as software to control complex hardware that's only half done is nearly useless (except that some testing can be done, perhaps).
As always, it's a matter of picking the right tool for the job, rather than picking up your hammer and treating everything as a nail.
Of course, not every application uses local connections - networked apps don't have the option of shared memory.
No, but every application has access to the X server, through which they can communicate. Okay, granted, the programmers have to figure out the ICCCM, which seems to be too much like hard work for a lot of them...
Why is KDE or Gnome so bloated and slow?
A couple of reasons. One is that the underlying toolkits (Qt and GTK+) are not optimized for X. They're both portable toolkits, so one expects some compromises, and they're both based directly on Xlib rather than on the X Toolkit Intrinsics (Xt). While theoretically this could make them faster than Xt-based kits, it deprives them of the years of performance tuning by expert X programmers that Xt has gone through.
The other reason is that both KDE and Gnome are "desktop systems", not just window managers, and have tons of stuff going on in the background (such as their flavors of CORBA), plus processes for the taskbar, etc.
By the way, KDE and Gnome are not monolithic apps as you seem to think, they do use separate apps for many of the tasks you mention -- but they're also all tied together by the corba-equivalent (so that, for example, a settings app can tell the desktop to change appearance), the messaging functions of which are provided in Windows by the OS layer (and which also duplicates a lot of what the X Server could do for you).
(All that said, on any reasonable hardware not more than a few years old, KDE or Gnome should still be fast enough for most users. Most of the cycles are still going to be spent waiting for the user.)
By replacing Unix domain sockets with hyperqueues (about twice as fast), and the X protocol with XML (an expansion of what, 5 times, 10 times?) you expect things to get faster? Somebody needs to check their math.
How about just adding a hyperqueue option to X?
(And yeah, I know, the X Server isn't the bottleneck anyway. Heck, you can implement an X server in Java and still get reasonable performance (well, to a point), so it's clearly not the bottleneck.)
Oh, Red Dwarf is wonderful. I hope you're not suggesting that the effects are realistic, though. (Rather well done, yes, but not realistic from a Hollywood perspective.)
Galaxy Quest had well-done cheesy effects. That is, the FX themselves were well done, but the ship itself was imitating one from a cheesy TV show -- complete with the video game like sequence where Sigourney Weaver asks something like "why does a starship even have something like this?".
;-)
However, I'm beginning to come around to the point of view that a high-budget HHGTTG could survive great effects and sets so long as they have the same irreverant feel to them. After all the TV series didn't quite look like it was done with old cardboard and spray paint.
See my reply to an earlier comment.
The MiB aliens were rendered realistically, but they weren't convincing as something that could actually exist -- photorealistic cartoon figures, if you will. (Mind, a lot of "serious" sci-fi movies suffer this same problem...)
(BTW, a great example of this done deliberately is the "scrat" character (the saber-tooth squirrel rat) in "Ice Age". That deliberately goes through some Chuck-Jonesish morphs (eg when squeezed between the two glaciers) for the added humor. Although Ice Age is just 3D animation, not an attempt at photorealism.)
And yes, agree with your points about the fans' expectations.
Spaceballs? Cheesy effects.
I guess I didn't make it explicit enough, but from context, I meant "a sci-fi comedy [with realistic SFX] movie that really worked".
By "realistic" I don't just mean "well done", but also "depicts something that could be real". The aliens in MiB were well rendered, but not convincing as "real". That's part of the humor.
Different medium = different jokes
Exactly. But by extension there are probably some media where there just aren't any funny jokes (or, more likely, the skill needed to come up with same eludes any artist to date.)
The TV version of HHGTTG works because (a) they cut a lot of the stuff that wouldn't have worked on TV (fortunately they had a lot of material to start with), and (b) it was TV, not a movie, and the budget FX were okay.
Offhand I can't think of a sci-fi comedy movie that really worked. Sure, there are "action comedies" like Men In Black (but again, how realistic were the weapons and aliens?), and there was "Dark Star" -- the latter complete with cheesy effects.
It may have something to with the different levels of "suspension of disbelief". The comedy of HHGTTG, or Dark Star, or even a Chuck Jones cartoon takes place in a universe of completely different physical laws (Wiley Coyote cartoons especially!). High-FX budget SF movies also take liberties with the laws of physics, but try to do so with explanations and "realistic" effects to lower your "suspension of disbelief" threshold.
Would the coyote trying to chase the road runner through a "tunnel" he'd painted on a rock be nearly as funny if, instead of just a painted hole, there was some stargate-like device rigged up that actually let the road runner on through while shutting down in time for the coyote to smack into the rock? Would Pinback chasing the alien with a broom be as funny if the alien didn't look like a beachball with rubber feet?
It was the first use (at least in television) of bluescreen techniques to create virtual sets,
;-)
Have you forgotten Starlost? (If you haven't, then you have my sympathy.
No, no, no.
Michael Palin.
Remember, Arthur Dent goes around most of the time not really knowing what's going on (he never could get the hang of Thursdays). Palin does that role wonderfully. (Think Arthur Pewty. Or the marriage counselor sketch.)
No matter how good the special effects in the film, on the Radio the pictures are better.
Yes. There's a classic radio sequence -- alas, I can't remember who did it -- that addresses this very point. They make the world's biggest ice cream sundae out of Lake Erie, complete with (IIRC) a fleet of B-52s to top it with the world's biggest cherry.
Yeah, with CG you could do it in film or video, but it wouldn't be as funny.
You seem to think that Woz's goal was better resolution.
Woz's goal? No, of course not, I never said that. That was the goal of some programmers who took advantage of the way Woz's circuit worked.
Have you considered a course in remedial reading?
while underreacting to Enron, SARS, and North Korea.
North Korea I'll go along with, maybe even Enron. But SARS!? Underreacted? Were there ever more than a handful of SARS cases in the US?