... except that the requirement of this clause shall not apply to a satellite digital audio service that is in operation, or that is licensed by the Federal Communications Commission, on or before July 31, 1998;
Strange that such a complaint would appear within a group expousing that "information wants to be free.":)
Not strange at all.
Slashdot is not populated by a bunch of lockstepping conformists. Its postership is large and diverse. The individuals are NOT the average, nor are they the stereotype.
Perhaps on the average the posters think that IP laws are 'way too tight. But some think they're too loose. Post an article about somebody making them tighter and the make-em-loosers will complain, post one about somebody apparently not respecting them at all and the make-em-tighters will sound off.
Further: Few if any Slashdot posters think a published author has no rights at all over the distribution of his work. (How would Copyleft work if that were true? B-) ) So when it looks like a service may be copying and republishing past works far beyond the authors' intended distribution they may sound off.
And even the most fanatic of the "information wants to be free" faction may still post a cautionary note about how a particular act of radically freeing it may attract opposition.
the best way to test code is to not make the mistake in the first place.
But the way to make solid code is to get each bug out as soon as you put it in.
Over my thirty-five years of professional programming I developed a coding/testing method that produces extremely solid code - to the point that one of my collegues once commented that [Rod] is the only person he'd trust to program his pacemaker. B-) It goes like this:
Design ahead of coding.
Of course! If you haven't spent more time designing than you eventually spend coding, you likely haven't yet understood the problem well enough.
This doesn't mean you have to understad every nitty-gritty detail before you write your first line of code - you'll discover things and change your design as you go. But you should know where you're goiong. And as you go, map the road ahead of you.
Not coding until you understand where you're going is VERY scary to administrators. But it gets you to your destination MUCH sooner than striking out randomly.
Get the modularity right.
Think of the final solution as a knotted mass of spaghetti threaded through meatballs inside an opaque plastic bag. Squeeze it around until you find a thin place, where few strands (representing flows of information) connect the halves of the solution on each side of the bag. Cut the bag in half here and label the strands: You've defined a module boundary and interface. Repeat with each of the two smaller bags until the remaining pile of bags each represent an understandable amount of code - about a page - or a single irreducable lump of heavily-interconnected code (one "meatball"). Then tear them open one-by-one and write the corresponding code.
Debug as you go:
This is the key!
Program top-down like a tree walk, stubbing out the stuff below where you're working. As you write the code, also write one or more pieces of corresponding test-code that produces output that is a signature of the operation of every bit of the code you write, and an expected-output file that is hand-generated (or computer-generated by a different tool, preferably written by someone else, or at least in a different language and style if you're alone).
Use a system tool (like diff or cmp) to compare the results (in preference to writing programs to "check" it, so you don't have to worry whether the test is passing beacuse the code is right or the test is broken.)
Run the test(s) every time you make a change or add code. Make a single change at a time between test runs, get it working and tested before you move on. (This is easy for procedural modules and subroutines. For instance: You can build the running of the test into your makefile, and fail the make if the test fails. GUI stuff is tougher, and I didn't have to deal with it myself. But tools are now available to perform similarly there.)
The result is that your bugs will generally be confined to the changes you just made, drastically limiting your search space and shortening your debugging time.
Do COVERAGE testing, and TRACK it.
Don't move on until you have exercised every bit of code where you were working. "Exercise" means your tests have been updated to execute every line or component of a line, driving it to its edge and corner cases and extracting a signature that shows they're doing their job correctly.
Automated coverage tools are an inadequate kludge to try to do this after the fact. Unfortunately, they pass code once all the branches have been executed, but have no idea whether they did the right thing. They may test that you hit the edge conditions - but can they tell if the edge is off-by-one? Human intelligent, with its knowlege of intended function, is required.
I developed a style of marking listings to document coverage, which is why I use hardcopy even in this day of glass terminals.
- a vertical bar beside a line that is completely working. Cross-mark across its top (T) at the first of a set of working lines, across the bottom of the last of a set.
- an "h"-shaped mark beside one that represents a partially-tested branching construct (if, for, do, "}",...} with a cross across the right if the branch case is untested, across the left if the through case is untested. Switch to vertical bar when fully tested (including hitting the edge from both sides if applicable)
- For compounds (i.e. "for( ; ; ) {" or " ? : " underline the portions fully tested, put an "h" with crossbar through those partially tested.
- Declarations "pass" when you've checked that the type is right for the job and at least one hunk of client code uses them.
- Comments "pass" pretty much automatically when you think they're right.
- A place where code is not yet present, or where the code above and below is tested but the flow across the gap is not, gets a break in the vertical line, with crossbars, as if there were an untested blank line "in the cracks". (But there should be a comment in there mentioning it. I start such comments with "MORE", so I can find any that are left with an editor. Similarly a MORE comment marks where I've stopped coding for now.)
When the code is done-and-coverage-tested there's a vertical slash beside all of it. (Sometimes you have to add test code temporarily to make something visible externally, but #ifdef or comment it out rather than removing it when you're done.)
The result is like growing a perfect crystal, with flaws only in the growing surface. When you've tested a part you're usually DONE. You never have to return to it unless you misunderstood its function and have to change it later, or if the spec changes.
DOCUMENT!
Co-evolve a document as the project develops if there's more than one on it, or if it has to be handed off to others later. If you're alone, you can get away with heavy comments.
Put in the comments even if you have the document.
Keep the comments up to date.
Comment heavily even if it's just you and always will be. When you come back to the code (especially if you're following this methodology and only get back to it MUCH later) you'll have forgotten what you were thinking. So put it all down to "reload your mental cache" when you get back to it.
The document should be a complete expression of the intended operation of the code - but in a very different and human-understandable form. (Especially not just pseudo-code for the same thing, or "i = i+1; add one to i". Use pseudo-code only for an ilustration, not an explanation.) Remember: Testing can NEVER tell if it's RIGHT. It can only tell if two different descriptions match. "Self-documenting code" is an untestable myth - all that can be tested is whether the compiler worked correctly.
There's more but I have to go now. I'll try to continue later. The above contains the bulk of the key stuff.
once it's discovered the FSF or Stallman drags them into court and forces them to disgorge their source code.
IANAL, but if it was demonstrably unintentional, wouldn't the court be likely to assess a fine and require the removal of the GPL code?
Probably. But the perception is that while FSF might be reasonable, Stallman has a socialist axe to grind and may push for draconian remidies. Copyleft is based on Copyright, and Copyright law recognizes that enforcement is a game of whack-a-mole. So it compensates by giving the copyright owner a sledgehammer for the moles he does hit.
But in business if you're dragged into court you've ALREADY lost, regardless of the outcome. The costs are high, you don't recover them if you win, and they come right out of your profit margin.
Winning one big suit can drive you into bankruptcy. So businessmen will generally avoid the risk, unless there's a lot of reward for taking the risk. Do Linux and GNU tools provide that improvement over the alternatives? Many companies say yes. But many say no - or "I don't know, but I DO know I don't need it. So I won't bet the farm."
And since Linux (or GNU/Linux, as Stallman likes to say) is under the GPL at the kernel, application, and development toolset level, this forms a barrier against the adoption of Linux.
Well, Linus has stated time and again that running a program under linux, while in requires some linking and interaction with the kernel, constitutes normal use. The issue with the standard libraries is the main reason that the LGPL was written - I don't think RMS ever intended to co-opt applications through the libs. He's an idealist, but he doesn't seem to like sstrongarm tactics.
I agree with both points. With the LGPL and the public statements of Linus (and others in similar positions in the Free Software movement) it's clear to me that with minimal care there's less of a risk with even (L)GPLed software than with proprietary software. (Imagine one of your guys using a Microsoft library, or reverse-engineering and cloning part of Microsoft's code to get around a problem, then finding that Microsoft actually intends to enforce some of those ELUA provisions. B-) )
But it's not MY opinion that matters. It's the opinion of the appropriate executives in thousands of companies, big and small. Many are Pointy Haired Bosses and all have been heavily propagandized by Microsoft. So some of just say "No GNUs is good GNUs."
Downside (for proprietary software vendors): If someone trying to make a non-open-source product uses GPLed code as a small part of the product, unrelated to the product's key features, they must now publish the code to all their key features. (Exception: There's a variant called "LGPL" that essentially lets people use libraries without publishing anything but the libraries they used.)
Trying to paint the GPL in a poor light?
Not at all. Just trying to explain why some software companies shy away from using anything GNU. A real drag when you're working for them and would like to use GNU toolsets, for instance.
Any software publisher should be aware of the license associated with stuff they use in their product. If they aren't, then too bad - software is expensive, and it pays to protect your investment.
Oh, but they are aware. And they're also concerned about the possibility that, if they use any GNU tool in development or even have the code in house, some GNU tool (i.e. Bison) or a lazy programmer might insert GPLed code in their product. Then once it's discovered the FSF or Stallman drags them into court and forces them to disgorge their source code.
Rather than risk this, some software shops just refuse to let it in the door.
And since Linux (or GNU/Linux, as Stallman likes to say) is under the GPL at the kernel, application, and development toolset level, this forms a barrier against the adoption of Linux.
If they are aware of what the GPL means (and it is a very simple license), then, since the GPLed feature is not core and fairly small, they should reimplement it, right?
Right.
But the net result is that GPLed and proprietary software are two separate worlds, with neither side able to incorporate the work of the other. (Or at least not witout serious reverse-engineering and hassle.)
Now this is FAIR. (The proprietary types won't let the GNU types use their proprietary code, the fruit of perhaps a decade of work by hundreds of people. So why should the GNU types let the proprietary types use theirs, which is the fruit of several decades of work by thousands?)
But it's a massive pain in the ass.
This smacks of Microsoft and their incessant whining about how it's so unfair that they can't just use somebody else's work for free.
Nah. Just trying to be "fair and balanced". B-)
I worked for several years in a shop where the corporate software stars were constantly flaming GPL as "more expensive than money". (A decade or so after they went comatose for lack of funds they threw in the towel and released their orphaned source - too little and too late.) I just wanted to make sure their ideas had been included in the discussion.
"Gnu Public License". Also called "copyleft" by its proponents (and "Gnu Public Virus" by its opponents). It's one of several "Open Source" licenses.
The basic idea is to invert copyright, to not just make your code public but also to KEEP it public, including versions of it modified by other people.
You copyright your code, then
license it to others, with the licence provision that provision that, if they distribute your code OR CODE DERIVED FROM IT (i.e. modifications or things containing it) they must also provide the source and sublicence it under the same terms.
Upsides:
Nobody can fix a bug and copyright the fixed version, keeping YOU from using the fix.
Creates a large "commons" of public code that other people can build on.
Lets a large body of users see the code and potentially debug it.
Downside (for proprietary software vendors): If someone trying to make a non-open-source product uses GPLed code as a small part of the product, unrelated to the product's key features, they must now publish the code to all their key features. (Exception: There's a variant called "LGPL" that essentially lets people use libraries without publishing anything but the libraries they used.)
To proprietary software vendors, who place a high value on keeping their "neato-keen inventions" secret, this is seen as "more expensive than money".
No, you do not understand it. Event-driven programs are just good old procedural programs with a higher-level abstraction on top. Some frameworks emphacise the difference by hiding the outer loop from you. But event-driven programming is at least as old as select().
And, yes, Windows programs have a 'main', it's called WinMain. It *does* recieve the command-line string (though not tokenized like in Unix, and it also recieves some other stuff).
Which ARE the points:
It's not called main with arguments (int argc, char** argv). So the "copyright violation" of the original post is not correct.
The style of programming is different. In Windows you don't take a block of procedural code and wrap it in a main(), doing all the work in main() and its subroutines. Instead you do the equivalent of having your main() do nothing more than set up a bunch of signal handler callbacks, then do all your work in the signal handlers. (Or equivalently, follow the initialization with a loop, which waits for an event and then uses a case or table lookup to dispatch the appropriate handler.)
At least that's my limited understanding of the point my wife was making. Perhaps I DON'T understand Windows programming, just as you say. (Not surprising, since I haven't DONE any. B-) )
I don't think this is a good idea. The point should be to change certain behavior in the future, and perhaps to punish them for what they did in the past. It is not to give out mass refunds to computer users, who really did have a choice in the end.
Well *I* think mass refunds ARE a good idea. A slap on the wrist that causes no pain is not very effective at changing future behavior. "First you get his attention."
As for "really did have a choice in the end", what choice? I've bought at least three computers with included Windows that I've never used, because there was no way to get a computer of similar characteristics WITHOUT bundled Windows due to Microsoft's anticompetitive practices. The ELUA that appeared on the screen when I booted 'em always said if you don't like it, don't use it and you get a refund. I've spent hours per machine trying to get that money refunded and have yet to see a cent.
I've always thought that one of the sanctions against Microsoft from the antitrust trial should be requiring them to set up a refund center for people who didn't use the bundled Windows and hadn't been given a refund, requiring them to return the entire added cost (including the computer company's and retailer's markup, and a bit extra for the user's time and trouble applying for the refund).
THAT would be the appropriate sanction for forcing the manufacturers to chose between charging for Windows on all their machines or having it on none.
List of violations (present in each product listed above):
Use of the following at the start of each program: int main(int argc, char* argv)
Funny. But wrong.
As I understand it (from my wife, who's a retired Windows developer - which I'm not), Windows programs consist of a bundle of event handlers and an event loop, and don't have a main() - especially a main(int argc, char** argv), which is a unix-system-interface-ism, related to handling command-line arguments.
One of her favorite flames relates to an alleged windows programmer who was unaware of this fact.
Warn them a week in advance, warn them a day in advance.
Then, in the middle of the night, format everyone's machines and stick fresh OS installs on all of them. If possible, ghost one machine's fresh install and use it everywhere. Then, the only backup you have to worry about is the H: drive.
You're offloading system administration tasks on the users, and giving them an drop-dead ultimatim. Not cool. No fallback. You'll cause much harm.
Instead try billing it as an "upgrade". That way they'll take any inconvenience as a side-effect of something useful to them, rather than as you deliberately screwing up their data and lives to make your job easier.
Also:
Do it by departments, workgroups, or segments of the cube farm, in stages.
Start with a very small group. You get to work the kinks out with a minimum of trouble if something went wrong, and the group will spread the word to other users on how to ease the transistion. That will let you do larger groups later.
Don't just format their disks. Swap 'em out for fresh ones and keep the old disks handy. Help the users recover any data from the swapped out disks for a few days, check that they've got all they need, maybe back the disks up just in case. THEN format them and swap them IN on the next group of victims.
Make a point of how much extra work you're doing to be SURE they don't lose any important data during the transition (even though you're not doing all THAT much extra). And of course harp on how the main point of the upgrade is to protect their data in the future (which IS true).
The cable company and satelite companies are not seeing excess costs by you picking their broadcast signal from the air or from a cable
Actually, they do get hit on the bottom line, as follows:
There are a significant number of people consuming their service and not paying. If they were not tapping it for free, SOME of them would do without, and SOME would buy it (or another company's service). The ones that would do witout don't count. But the ones that would buy their service (along with the ones currently tapping some competitor's service that would buy theirs - the mirror image of the ones who would buy the competitor's if not tapping theirs) represent lost revenue.
Now if they were able to pick up some of that revenue, any left after enforcement costs would represent more net for them, to be split among the owner's profit, content producers revenue, and potential cost reductions (as fixed costs plus enforcement costs are distributed more broadly, leading to a lower consumer price for the max-profit equilibrium).
Needless to say, they feel burned that they're not getting that money, while people who aren't paying it ARE getting the signals they spend so much time, effort, and money to provide to paying customers.
Actually it says if you can reduce the communications workload (say, by partitioning the job at "thin" spots and hammering out interface definitions up front) your workers can spend most of their time working.
But it's really tough to cut the communications to zero without disconnecting the pieces so they can never be assembled.
Another approach is to have communications specialists only use up one "port" on each worker, and do nothing but talk to workers and other communication specialists. (They sometimes call these people administrators, tech leads, or system architects.) The workers may occasionally redirect a port to talk to a neighbor, like when their modules have to interface, but mostly they just talk to the one guy.
Of course that has its own pathologies: The "game of telephone" as the extra hops distort the message and information hiding for office political reasons, to name just two.
Thank you for your reply. Do you have any references regarding claims such as "one developer can only maintain 10-20K lines of code"?
Sorry. That's something that stuck in my mind from 20 or more years ago. So from my standpoint the origin of the comment is long lost.
I've mainly worked in relatively small teams (no more then 4 devs on one project), and I've always faught against managers that wanted to add 2-3 more "temps" to a late project (as if it would increase time-to-market).
Actually, adding 2-3 more temps to a late project WILL increase time-to-market (i.e. make it deliver later).
That one I do have a source for: _The Mythical Man-Month_. The formulation is "Adding personnel to a late project makes it later.", delivered as one of the central catch-phrases and then explored in detail.
Basic idea is the people who are actually getting work done have to stop making progress to spin-up the newbies, and once they're spun up it takes a long time for them to make as much extra progress as was lost spinning them up. The closer to the end of the project, the less time there is to repay the investment.
Of course the "man as four-port" argument says that, if the project is big enough (and not properly partitioned) you'll NEVER make it up, and may slip farther behind, because the ongoing communication load eats as much or more work from existing workers as the added workers put out.
But what if we hadn't spent six trillion dollars [or whatever] on nukes...
Well, the way things were going, about 1965 or so the USSR might well have blown us to hell with a half-billion rubles worth of nukes, then duked it out with Red China about 1980 over who would run the remains of the world.
... creating nuke-pollution timebombs... experimenting on our own population and spreading cancer from fallout...
Maybe we could have [done lots of good stuff with the money instead].
The USSR didn't mind polluting a large chunk of their own territory to make plutonium. Chernobyl was just the LAST and worst spill (that we know of). And vaporizing one operating power reactor is a really close approximation to one all-out nuclear war's fallout. But there were plenty of others. (Like the chemical reaction that boiled a major fraction of a Soviet waste dump. The highways through a big chunk of Siberia are still "no stopping zones" due to that one.)
Three Mile Island, on the other hand, was just a little bit of radioactive steam. The atmospheric tests and the military reactor oopsies in the US were larger, but a drop in the bucket compared to either of the USSR incidents above.
Yes the Hanford experiment was cold-blooded genocide. So tell me about it. My wife is one of the "marginal population" they experimented on while she was still in the womb - born in the reservation downwind of the deliberate release. And she has the birth defects, thyroid disease, and occasional propaganda mail about how minor it was (which somehow keeps showing up with updated mailing addresses) to prove it. Seems that experiment was STILL GOING ON, with the victims' health being monitored, at least through the fall of the USSR.
But that sort of expenditure and NAZI-style human experimentation is why it was so important to get the cold war STOPPED. Another win for SDI.
After all, after you've got enough to destroy the world three times over, isn't the rest a bit of a waste?
"Overkill" is misunderstood, and is NOT what you are apparently assuming. Consider this:
One bomb of X kilotons, successfully exploded over a target, kills 1/N of your enemy's population. So you need N such bombs to kill all of 'em, right?
Wrong, for two reasons:
1 That 1/N assumes a "good" target - like the concentrated population and infrastructure of an industrial city. After your first 5 or so bombs blow up all the big industrial centers, your next 100 or so have to go after the little industrial centers. It takes maybe K*N to get 'em all. "Overkill" of K.
2 But these things are going in on bombers (that are being shot at) and missiles (that may fail, and may also be shot at - the USSR did deploy anti-missiles despite the treaties, and were actually allowed one by the treaties). If you don't want to shoot first you fired your missiles (and gave "GO" to your planes and subs) AFTER they shot at 'em - maybe after the bombs landed, maybe yours are in flight while theirs are going BANG. So only one in J gets through. To hit them all you need at least J*K "overkill". Actually you need more - because bomb loss is a statistical process. If you only sent J*K*N bombs some targets would get hit twice and some missed. So you need "overkill" beyond J*K to be sure you level everything you intended to level.
So "overkill" doesn't mean "kill 'em I*J*K times". "overkill" means "bomb each target I*J times, throwing I*J*K times as much stuff as you'd need if they were all just like the easiest one and everything worked perfectly, and PRAY that every target gets hit at least once." If I*J*K happens to be larger than 2 * (World Population / Soviet Population), that does NOT mean you have enough bombs to kill everybody in the world twice.
We've threatened to use nukes at least half a dozen times in the last half century (including the Berlin blockade), we've shown we can't abide by the rules of the rest of civilization, and _you_ feel secure?
YO! DUDE! During the wind-down of WW II into the Cold War we announced that we'd defend West Germany (including West Berlin) by whatever means necessary. We made treaties that REQUIRE us to use nukes to defend certain allies, not just ourselves, from certain kinds of attack. We've announced a policy of responding to government-launced nuclear, chemical, or biological attacks, on our allies and on signatories of the non-proliferation agreement, with nuclear retaliation. (You don't need to develop your own bombs - you can use ours.) And we announced that we would treat siting nuclear missiles in the Americas aimed at the US as an act of war.
Those ARE the "rules of civilization". We wrote 'em. Rent a clue!
("We" includes the rest of the winners of WW II. And the surviving losers as well.)
"As I walk through the Valley of the Shadow of Death I will fear no evil. For I am the MEANEST son-of-a-bitch in the Valley!" If you TRY to kill me, your whole country will glow for centuries, with nothing left alive but cocroaches and algae. And everybody who might try a classic nuclear, chemical, or biological first-strike KNOWS it. THAT's why I sleep peacefully at night.
How does this [small number of registered developers on most open source projects] rationalize "More Eyeballs"
In addition to the "many submit patches, few apply them to the archive" argument, there's another systematic undercount:
A large project will often have a few people whose job is to integrate the code. Sometimes this means only these integration specialists will have write privileges on the archive. The bigger the project, the more likely this is to occur.
==========
That said, what's "small" about a median of four with write privileges? (The mode of one just means that there are more one-man projects hosted at source forge than N>1 man projects for any particular N.) Four active programmers is a moderately big project, and "median of four" (with mode of non-four) implies there's a bunch with more-than-four as well.
Four is a very good size for a large project. Going above that takes a lot of work and is inefficient on a per-programmer basis, unless you have administrative workers who don't program to do the organization. The "human as four-port" analysis shows why.
Consider a human as a "black box" with a number of "ports", representing equal divisions of his time and/or attention. Each port represents enough time per day to communicate with one co-worker or to do one unit of work. Assume also that this amount is such that the number of "ports" on a programmer is about four. (It's probably a bit larger, but four is close and easy to draw.)
In a given amount of time, with a single-committee project:
A one-man project does four units of work:
W | W-[1]-W | W
A two-man project does six units of work:
W W | | W-[1]-[2]-W | | W W
A three-man project also does six units of work:
W W | | W-[1]-[2]-W | | W-[3]--+ | W
A four-man project does FOUR units of work:
W | [1]--[2]-W | \/ | |/\ | [3]--[4]-W | W
And a five-man project bogs down in talk and does no work at all:
With a different number of "ports" the maximum-work group size changes, but the shape of the curve is the same: Adding people first raises the amount of work done, then levels out, then DROPs it until the group paralyzes. For N ports the stall is at N+1 workers. N work about as well as 1 and (N+1)/2 get the maximum work out.
(Ever wonder why you spend half your time in meetings? THAT's why! If the goal is to get the project done in the shortest time regardless of personnel cost, the most effective size for a group of peers has each worker spending about half his time interacting with other workers.)
Now there are a number of ways around that. For instance:
1 Keep the team small (or one-man) and push out the delivery date.
2 Reduce the "bandwidth" of the communication ports and expand that of the work ports by assigning work on natural modularity boundaries.
3 Build a hierarchical organization, with some people specializing in communication (and doing little or no "work" on the code) and others mostly doing "work" but only interacting with their comm specialist (administrator) and maybe coworkers on closely-associated modules.
4 Build a hierarchical organization with one or a core group making final inclusion decisions and the bulk of the organization doing actual coding in small snippets.
Taking 1 to the limit results in a bunch of one-man projects with long delivery schedules. One man is the most productive on a code-per-manhour basis. But if the project is too large he slows down asymptopically as he approaches his "boggle limit" - the largest codebase he can maintain single-handed but no logner expand. That was once estimated at about 10K-20K lines of code (about the size of the System 6 Unix kernel, through NO coincidence).
Taking 2 to the extreme is what you get if you conider the open-source movement as a whole as a single project: The developers on each project need little communication with the developers of the others, beyond standards promulgated by a few core developers. Within a project it's the natural way to go, but there are limits to how much it can help.
3 represents your typical industrial software operation. But open-source developers usually hate to become pointy-haired bosses and stop codiing themselves, and without paychecks to hand out they have a lot more trouble herding the cats. So a few big open-source projects are be run by one or a few notable developers with strong personalities who are able to bite that bullet on managing-over-coding and use reputation points in place of paychecks to motivate their workforces. And the rest are one-mans or small teams of friends, self-organizing in grand primate style along the lines of 4.
After the climax of WW II, when the world found out a nuke was more than "just a bigger bomb", the game changed.
Up until then it had been progressively bigger wars. Now it was "Let's see if we can avoid a war without surrendering."
So the West came up with the doctrine of "Mutual Assured Destruction" (MAD - i.e. You'd be mad to set off the first nuke. And US presidents had to put on a show of being just crazy enough to use them, or it wouldn't work.) But that's just a stalemate, no "progress" pushing your agenda.
So the East came up with the "Cold War" - with anti-West propaganda and brushfire wars in "domino" countries. (Salami slicing: Pick off the little guys one by one, then the middle-size guys, until the big guy is alone against the world. Cook the Frog: Never create a "Shelling Point" were the chip is knocked off the big guy's shoulder.)
So the West came up with the arms race: "We've got more money so we can outbuid you. You make a missile, we make an anti-missile-missile." (And Rocky and Bullwinkle satarize it with the anti-anti-[pause]-missile-missile-missile.)
And this went on for HALF A CENTURY. Before that it was a major war every generation, with all the "best" weapons in the arsenal in use. Now it was a declining series of "limited wars", with the biggest bombs very carefully NOT used.
Nukes really had made "total war" obsolete. Three war cycles came and went with no World War Three. And it all worked because expensive weapons were built with the intent that they NOT be used, because they'd be too devastating if they were.
There were abortive attempts to limit the proliferation and avoid "destabilizing" situations, in the form of an anti-missile ban and arms reduction treaties. But "stable" meant the Cold War continued to bleed both sides, and one side disarming too fast might mean the War to End All Humanity. Finally Regan abandoned such attempts and went flat-out for better armor, when the USSR couldn't afford to stay even. And the Soviet Union folded.
There was a LOT more to it than that. Like computers and networks for instance. (Restrict communication Soviet style and you slow progress. Have progress in computers and networking and you get communication you can't ban. Try to selectively free your people's communication and you discover that you can't suppress just some. Infrmation wants to be free because PEOPLE want to be free.)
But at the core, preventing nuclear war was done with weapons that worked by NOT being used; weapons that thus created their effects by MAYBE being able to work, so you couldn't risk them actually being used against you.
So, yes, SDI was successfull because they didn't nuke us. The US won the arms race but we ALL won the war.
Get real...
Why get real when I can win with virtual weapons? B-)
Nuclear weapons are like smallpox...America is the only country to have ever used them against someone else...
I see the public schools have neglected your education when it comes to germ warfare. For starters look at the history of the European dark ages - with diseased animal carcases being catapulted over fortress walls or dropped in wells and rivers during sieges.
... and now we live in media induced fear someone will [nuke or germ] us...
Lived that way for over 50 years already - but with the spectre of a massive, simultaneous attack on everything that might be a target (which means essentially everything). One or two suitcase nukes or tactical-shells taking out one city or one dam? ONE plague released in a few spots, using most like non-engineered organisims, rather than a dozen lab-frankenbugs sprayed over a continent simultaneously? Chicken feed. The damage and death is vanishingly small compared to hurricanes and tornadoes, earthquakes, traffic accidents, clogged-arteries, and cancer.
The missle shield was certanly destablizing, it never helped us in any treaty with another super power, not even as a negotiating gambit. [etc.]
Seems to me it worked perfectly.
The Soviet Union collapsed, ending half a century of Cold War. The surviving USSR government officials said the major factor was SDI. Not a single nuclear bomb exploded on or above the soil of the US, its possessions, or its allies (including all the signatories to the non-proliferation treaty). And it was so powerful we didn't even have to actually DEPLOY it!
Lets see your smart bomb or a START-XVI treaty beat THAT!
Yes it's an oxymoron and its self-contradiction is funny. But having it on otherwise-blank pages of manuals is really quite important.
Without it, the people in the technical publications department (and readers of the manual) are likely to spend time trying to determine if the page is blank due to an error. Manuals are delayed and costs rise. And if there is not a policy to insert the phrase on blank pages, manuals may occasionally be published with one or more blank pages that aren't SUPPOSED to be blank.
(Of course the humor of that catchphrase has led to parodies. Example: An experimental microchip that (due to the early silicon compiler's tendency to group repetitive circuitry tightly) had some large, rectangular chunks of the chip unused. So the deisngers hand-instantiated that lettering in the blank area.
Look at the government lying about the "tonkin gulf attack" that lead to the nam war.
Actually the Gulf of Tonkin incedent may have been a mistake. As I heard it:
A US ship was cruising around to "show the flag" in the Gulf of Tonkin. Some small fishing boats were nearby. Sonar reported a pair of torpedoes coming at the ship from the direction of the fishing boats. The ship manouvered and was not hit.
The problem is that when a ship makes a turn, sonar reflecting from its wake looks like two torpedoes zeroing in on the ship. The sonar man SHOULD know about this effect and be able to discount it. But giving that they expected a possible attack (indeed, were serving as a shoulder-chip at the time), he might have reported it as a possible and had it blown out of proportion later.
So maybe an honest error. Or maybe a deliberate error. (Or maybe a story I heard that has no relation to fact - things were hectic back then.)
kill or modify the anti-virus programs (including modifying it so it SPREADS the virus)
THAT'S the one to worry about.
Tell me about it.
I've been worried for a long time about a trojan disguised as an anti-virus update that used the anti-virus software to "fix" uninfected files by infecting them.
Or a variant: One manufacturer's anti-virus configuration treating a competitor's software as being malicious and disabling it.
If Windows' virus scanner didn't catch the virus on the initial infection (when it infected the Linux partition), why would it be useful to infect the computer via Linux as a means of avoiding the Windows virus scanning software?
Because the virus could do things from the Linux environment that WOULD have been detected by the anti-virus software if it tried it from the Windows environment during the initial infection.
Actually its less common than you think. Several hundred firemen every year get caught setting fires and of those several hundred the majority are volunteer.
There are an enormous number of firemen in the country, and a small number of jolly firebugs among their number setting fires. My impression is that the fraction of do-badders among them is MUCH smaller than that of the general population. Unfortunately, it is not zero.
That said: My post was in response to the original poster's claim that "[asking if employees of antivirus companies writeing viruses is] a very insulting question, like asking firemen if they start fires... the answer is [obviously] 'No'". My point is that, though the question may be taken as an insult, the "No" answer is NOT obvious, and if the analogy presented was to hold you would expect a small number of anti-virus software writers to write (and release) viruses, either to drum up more business or just because they can.
Somewhere between one in fifty and one in two hundred of the general population is psychopathic. It appears to be a brain disfunction (analogous to color-blindness, though not necessarily genetic) with effects that amount to "no conscience" and which does not correlate strongly with intelligece (i.e. they may be smart or dumb). They have no sense of right vs. wrong. Those that don't compensate by learning a moral ruleset (or who learn one with holes in it) may commit horrendous crimes and be bemused when others dislike them for it. Those who do compensate often excell in positions where they make life-affecting or life-critical decisions - such as surgery, military/police/fire-fighting (especially command), politics, and business management - because their rational decision-making is not clouded by bursts of emotion when lives or livelihoods are being lost. Though they run the risk of becoming moralistic, they are arguably the most virtuous among us - because they CHOSE virtue, rather than having it thrust upon them.
It is a tribute to our fire-fighters and their institutions that, with a large enough force that there are BOUND to be a few of the conscience-deficient among them, they turn out so many heroes (whether consciencefull or conscienceless) and so few below-zeros.
As for the anti-virus software writers: The data is not in. Let us all hope they do as well.
A hybrid virus could have its own filesystem code, and thereby infect say a linux partition on a dual-boot machine that is currently booted in windows,
In other words, Windows is SO insecure that running it on a dual-boot Win/Lin machine opens a hole to infect the Linux partition. B-)
It is, of course, a very insulting question, like asking firemen if they start fires, or dentists if they're the cause of tooth decay.
True story: My dentist, when I was a kid, would give out lollipops. Pure sugar, artificially-colored, decay-inducing lollipops. Swear to God.
Also: More than one fire department has been caught setting fires to put out. (It's especially prevalant among volunteer fire departments, which are often composed of people who enjoy playing with fires.)
Slashdot Mirror
Is this an Anti-TiVo clause?
Sounds like it's anti XM Radio.
Tag's Trance Trip [tagstrance.com], one of my favorite internet radio stations of all time, just went down.
Danger, Tag:
The intro page is still there and has a bumper. Tag probably needs to take that down, too.
B-(
Strange that such a complaint would appear within a group expousing that "information wants to be free." :)
Not strange at all.
Slashdot is not populated by a bunch of lockstepping conformists. Its postership is large and diverse. The individuals are NOT the average, nor are they the stereotype.
Perhaps on the average the posters think that IP laws are 'way too tight. But some think they're too loose. Post an article about somebody making them tighter and the make-em-loosers will complain, post one about somebody apparently not respecting them at all and the make-em-tighters will sound off.
Further: Few if any Slashdot posters think a published author has no rights at all over the distribution of his work. (How would Copyleft work if that were true? B-) ) So when it looks like a service may be copying and republishing past works far beyond the authors' intended distribution they may sound off.
And even the most fanatic of the "information wants to be free" faction may still post a cautionary note about how a particular act of radically freeing it may attract opposition.
Which seems to be what happened here.
But the way to make solid code is to get each bug out as soon as you put it in.
Over my thirty-five years of professional programming I developed a coding/testing method that produces extremely solid code - to the point that one of my collegues once commented that [Rod] is the only person he'd trust to program his pacemaker. B-) It goes like this:
Design ahead of coding.
Of course! If you haven't spent more time designing than you eventually spend coding, you likely haven't yet understood the problem well enough.
This doesn't mean you have to understad every nitty-gritty detail before you write your first line of code - you'll discover things and change your design as you go. But you should know where you're goiong. And as you go, map the road ahead of you.
Not coding until you understand where you're going is VERY scary to administrators. But it gets you to your destination MUCH sooner than striking out randomly.
Get the modularity right.
Think of the final solution as a knotted mass of spaghetti threaded through meatballs inside an opaque plastic bag. Squeeze it around until you find a thin place, where few strands (representing flows of information) connect the halves of the solution on each side of the bag. Cut the bag in half here and label the strands: You've defined a module boundary and interface. Repeat with each of the two smaller bags until the remaining pile of bags each represent an understandable amount of code - about a page - or a single irreducable lump of heavily-interconnected code (one "meatball"). Then tear them open one-by-one and write the corresponding code.
Debug as you go:
This is the key!
Program top-down like a tree walk, stubbing out the stuff below where you're working. As you write the code, also write one or more pieces of corresponding test-code that produces output that is a signature of the operation of every bit of the code you write, and an expected-output file that is hand-generated (or computer-generated by a different tool, preferably written by someone else, or at least in a different language and style if you're alone).
Use a system tool (like diff or cmp) to compare the results (in preference to writing programs to "check" it, so you don't have to worry whether the test is passing beacuse the code is right or the test is broken.)
Run the test(s) every time you make a change or add code. Make a single change at a time between test runs, get it working and tested before you move on. (This is easy for procedural modules and subroutines. For instance: You can build the running of the test into your makefile, and fail the make if the test fails. GUI stuff is tougher, and I didn't have to deal with it myself. But tools are now available to perform similarly there.)
The result is that your bugs will generally be confined to the changes you just made, drastically limiting your search space and shortening your debugging time.
Do COVERAGE testing, and TRACK it.
...} with a cross across the right if the branch case is untested, across the left if the through case is untested. Switch to vertical bar when fully tested (including hitting the edge from both sides if applicable)
Don't move on until you have exercised every bit of code where you were working. "Exercise" means your tests have been updated to execute every line or component of a line, driving it to its edge and corner cases and extracting a signature that shows they're doing their job correctly.
Automated coverage tools are an inadequate kludge to try to do this after the fact. Unfortunately, they pass code once all the branches have been executed, but have no idea whether they did the right thing. They may test that you hit the edge conditions - but can they tell if the edge is off-by-one? Human intelligent, with its knowlege of intended function, is required.
I developed a style of marking listings to document coverage, which is why I use hardcopy even in this day of glass terminals.
- a vertical bar beside a line that is completely working. Cross-mark across its top (T) at the first of a set of working lines, across the bottom of the last of a set.
- an "h"-shaped mark beside one that represents a partially-tested branching construct (if, for, do, "}",
- For compounds (i.e. "for( ; ; ) {" or " ? : " underline the portions fully tested, put an "h" with crossbar through those partially tested.
- Declarations "pass" when you've checked that the type is right for the job and at least one hunk of client code uses them.
- Comments "pass" pretty much automatically when you think they're right.
- A place where code is not yet present, or where the code above and below is tested but the flow across the gap is not, gets a break in the vertical line, with crossbars, as if there were an untested blank line "in the cracks". (But there should be a comment in there mentioning it. I start such comments with "MORE", so I can find any that are left with an editor. Similarly a MORE comment marks where I've stopped coding for now.)
When the code is done-and-coverage-tested there's a vertical slash beside all of it. (Sometimes you have to add test code temporarily to make something visible externally, but #ifdef or comment it out rather than removing it when you're done.)
The result is like growing a perfect crystal, with flaws only in the growing surface. When you've tested a part you're usually DONE. You never have to return to it unless you misunderstood its function and have to change it later, or if the spec changes.
DOCUMENT!
Co-evolve a document as the project develops if there's more than one on it, or if it has to be handed off to others later. If you're alone, you can get away with heavy comments.
Put in the comments even if you have the document.
Keep the comments up to date.
Comment heavily even if it's just you and always will be. When you come back to the code (especially if you're following this methodology and only get back to it MUCH later) you'll have forgotten what you were thinking. So put it all down to "reload your mental cache" when you get back to it.
The document should be a complete expression of the intended operation of the code - but in a very different and human-understandable form. (Especially not just pseudo-code for the same thing, or "i = i+1; add one to i". Use pseudo-code only for an ilustration, not an explanation.) Remember: Testing can NEVER tell if it's RIGHT. It can only tell if two different descriptions match. "Self-documenting code" is an untestable myth - all that can be tested is whether the compiler worked correctly.
There's more but I have to go now. I'll try to continue later. The above contains the bulk of the key stuff.
IANAL, but if it was demonstrably unintentional, wouldn't the court be likely to assess a fine and require the removal of the GPL code?
Probably. But the perception is that while FSF might be reasonable, Stallman has a socialist axe to grind and may push for draconian remidies. Copyleft is based on Copyright, and Copyright law recognizes that enforcement is a game of whack-a-mole. So it compensates by giving the copyright owner a sledgehammer for the moles he does hit.
But in business if you're dragged into court you've ALREADY lost, regardless of the outcome. The costs are high, you don't recover them if you win, and they come right out of your profit margin.
Winning one big suit can drive you into bankruptcy. So businessmen will generally avoid the risk, unless there's a lot of reward for taking the risk. Do Linux and GNU tools provide that improvement over the alternatives? Many companies say yes. But many say no - or "I don't know, but I DO know I don't need it. So I won't bet the farm."
Well, Linus has stated time and again that running a program under linux, while in requires some linking and interaction with the kernel, constitutes normal use. The issue with the standard libraries is the main reason that the LGPL was written - I don't think RMS ever intended to co-opt applications through the libs. He's an idealist, but he doesn't seem to like sstrongarm tactics.
I agree with both points. With the LGPL and the public statements of Linus (and others in similar positions in the Free Software movement) it's clear to me that with minimal care there's less of a risk with even (L)GPLed software than with proprietary software. (Imagine one of your guys using a Microsoft library, or reverse-engineering and cloning part of Microsoft's code to get around a problem, then finding that Microsoft actually intends to enforce some of those ELUA provisions. B-) )
But it's not MY opinion that matters. It's the opinion of the appropriate executives in thousands of companies, big and small. Many are Pointy Haired Bosses and all have been heavily propagandized by Microsoft. So some of just say "No GNUs is good GNUs."
Trying to paint the GPL in a poor light?
Not at all. Just trying to explain why some software companies shy away from using anything GNU. A real drag when you're working for them and would like to use GNU toolsets, for instance.
Any software publisher should be aware of the license associated with stuff they use in their product. If they aren't, then too bad - software is expensive, and it pays to protect your investment.
Oh, but they are aware. And they're also concerned about the possibility that, if they use any GNU tool in development or even have the code in house, some GNU tool (i.e. Bison) or a lazy programmer might insert GPLed code in their product. Then once it's discovered the FSF or Stallman drags them into court and forces them to disgorge their source code.
Rather than risk this, some software shops just refuse to let it in the door.
And since Linux (or GNU/Linux, as Stallman likes to say) is under the GPL at the kernel, application, and development toolset level, this forms a barrier against the adoption of Linux.
If they are aware of what the GPL means (and it is a very simple license), then, since the GPLed feature is not core and fairly small, they should reimplement it, right?
Right.
But the net result is that GPLed and proprietary software are two separate worlds, with neither side able to incorporate the work of the other. (Or at least not witout serious reverse-engineering and hassle.)
Now this is FAIR. (The proprietary types won't let the GNU types use their proprietary code, the fruit of perhaps a decade of work by hundreds of people. So why should the GNU types let the proprietary types use theirs, which is the fruit of several decades of work by thousands?)
But it's a massive pain in the ass.
This smacks of Microsoft and their incessant whining about how it's so unfair that they can't just use somebody else's work for free.
Nah. Just trying to be "fair and balanced". B-)
I worked for several years in a shop where the corporate software stars were constantly flaming GPL as "more expensive than money". (A decade or so after they went comatose for lack of funds they threw in the towel and released their orphaned source - too little and too late.) I just wanted to make sure their ideas had been included in the discussion.
The basic idea is to invert copyright, to not just make your code public but also to KEEP it public, including versions of it modified by other people.
You copyright your code, then
license it to others, with the licence provision that provision that, if they distribute your code OR CODE DERIVED FROM IT (i.e. modifications or things containing it) they must also provide the source and sublicence it under the same terms.
Upsides:
Nobody can fix a bug and copyright the fixed version, keeping YOU from using the fix.
Creates a large "commons" of public code that other people can build on.
Lets a large body of users see the code and potentially debug it.
Downside (for proprietary software vendors): If someone trying to make a non-open-source product uses GPLed code as a small part of the product, unrelated to the product's key features, they must now publish the code to all their key features. (Exception: There's a variant called "LGPL" that essentially lets people use libraries without publishing anything but the libraries they used.)
To proprietary software vendors, who place a high value on keeping their "neato-keen inventions" secret, this is seen as "more expensive than money".
And, yes, Windows programs have a 'main', it's called WinMain. It *does* recieve the command-line string (though not tokenized like in Unix, and it also recieves some other stuff).
Which ARE the points:
It's not called main with arguments (int argc, char** argv). So the "copyright violation" of the original post is not correct.
The style of programming is different. In Windows you don't take a block of procedural code and wrap it in a main(), doing all the work in main() and its subroutines. Instead you do the equivalent of having your main() do nothing more than set up a bunch of signal handler callbacks, then do all your work in the signal handlers. (Or equivalently, follow the initialization with a loop, which waits for an event and then uses a case or table lookup to dispatch the appropriate handler.)
At least that's my limited understanding of the point my wife was making. Perhaps I DON'T understand Windows programming, just as you say. (Not surprising, since I haven't DONE any. B-) )
I don't think this is a good idea. The point should be to change certain behavior in the future, and perhaps to punish them for what they did in the past. It is not to give out mass refunds to computer users, who really did have a choice in the end.
Well *I* think mass refunds ARE a good idea. A slap on the wrist that causes no pain is not very effective at changing future behavior. "First you get his attention."
As for "really did have a choice in the end", what choice? I've bought at least three computers with included Windows that I've never used, because there was no way to get a computer of similar characteristics WITHOUT bundled Windows due to Microsoft's anticompetitive practices. The ELUA that appeared on the screen when I booted 'em always said if you don't like it, don't use it and you get a refund. I've spent hours per machine trying to get that money refunded and have yet to see a cent.
I've always thought that one of the sanctions against Microsoft from the antitrust trial should be requiring them to set up a refund center for people who didn't use the bundled Windows and hadn't been given a refund, requiring them to return the entire added cost (including the computer company's and retailer's markup, and a bit extra for the user's time and trouble applying for the refund).
THAT would be the appropriate sanction for forcing the manufacturers to chose between charging for Windows on all their machines or having it on none.
Use of the following at the start of each program: int main(int argc, char* argv)
Funny. But wrong.
As I understand it (from my wife, who's a retired Windows developer - which I'm not), Windows programs consist of a bundle of event handlers and an event loop, and don't have a main() - especially a main(int argc, char** argv), which is a unix-system-interface-ism, related to handling command-line arguments.
One of her favorite flames relates to an alleged windows programmer who was unaware of this fact.
Then, in the middle of the night, format everyone's machines and stick fresh OS installs on all of them. If possible, ghost one machine's fresh install and use it everywhere. Then, the only backup you have to worry about is the H: drive.
You're offloading system administration tasks on the users, and giving them an drop-dead ultimatim. Not cool. No fallback. You'll cause much harm.
Instead try billing it as an "upgrade". That way they'll take any inconvenience as a side-effect of something useful to them, rather than as you deliberately screwing up their data and lives to make your job easier.
Also:
Do it by departments, workgroups, or segments of the cube farm, in stages.
Start with a very small group. You get to work the kinks out with a minimum of trouble if something went wrong, and the group will spread the word to other users on how to ease the transistion. That will let you do larger groups later.
Don't just format their disks. Swap 'em out for fresh ones and keep the old disks handy. Help the users recover any data from the swapped out disks for a few days, check that they've got all they need, maybe back the disks up just in case. THEN format them and swap them IN on the next group of victims.
Make a point of how much extra work you're doing to be SURE they don't lose any important data during the transition (even though you're not doing all THAT much extra). And of course harp on how the main point of the upgrade is to protect their data in the future (which IS true).
The cable company and satelite companies are not seeing excess costs by you picking their broadcast signal from the air or from a cable
Actually, they do get hit on the bottom line, as follows:
There are a significant number of people consuming their service and not paying. If they were not tapping it for free, SOME of them would do without, and SOME would buy it (or another company's service). The ones that would do witout don't count. But the ones that would buy their service (along with the ones currently tapping some competitor's service that would buy theirs - the mirror image of the ones who would buy the competitor's if not tapping theirs) represent lost revenue.
Now if they were able to pick up some of that revenue, any left after enforcement costs would represent more net for them, to be split among the owner's profit, content producers revenue, and potential cost reductions (as fixed costs plus enforcement costs are distributed more broadly, leading to a lower consumer price for the max-profit equilibrium).
Needless to say, they feel burned that they're not getting that money, while people who aren't paying it ARE getting the signals they spend so much time, effort, and money to provide to paying customers.
Close. B-)
Actually it says if you can reduce the communications workload (say, by partitioning the job at "thin" spots and hammering out interface definitions up front) your workers can spend most of their time working.
But it's really tough to cut the communications to zero without disconnecting the pieces so they can never be assembled.
Another approach is to have communications specialists only use up one "port" on each worker, and do nothing but talk to workers and other communication specialists. (They sometimes call these people administrators, tech leads, or system architects.) The workers may occasionally redirect a port to talk to a neighbor, like when their modules have to interface, but mostly they just talk to the one guy.
Of course that has its own pathologies: The "game of telephone" as the extra hops distort the message and information hiding for office political reasons, to name just two.
Thank you for your reply. Do you have any references regarding claims such as "one developer can only maintain 10-20K lines of code"?
Sorry. That's something that stuck in my mind from 20 or more years ago. So from my standpoint the origin of the comment is long lost.
I've mainly worked in relatively small teams (no more then 4 devs on one project), and I've always faught against managers that wanted to add 2-3 more "temps" to a late project (as if it would increase time-to-market).
Actually, adding 2-3 more temps to a late project WILL increase time-to-market (i.e. make it deliver later).
That one I do have a source for: _The Mythical Man-Month_. The formulation is "Adding personnel to a late project makes it later.", delivered as one of the central catch-phrases and then explored in detail.
Basic idea is the people who are actually getting work done have to stop making progress to spin-up the newbies, and once they're spun up it takes a long time for them to make as much extra progress as was lost spinning them up. The closer to the end of the project, the less time there is to repay the investment.
Of course the "man as four-port" argument says that, if the project is big enough (and not properly partitioned) you'll NEVER make it up, and may slip farther behind, because the ongoing communication load eats as much or more work from existing workers as the added workers put out.
Well, the way things were going, about 1965 or so the USSR might well have blown us to hell with a half-billion rubles worth of nukes, then duked it out with Red China about 1980 over who would run the remains of the world.
Maybe we could have [done lots of good stuff with the money instead].
The USSR didn't mind polluting a large chunk of their own territory to make plutonium. Chernobyl was just the LAST and worst spill (that we know of). And vaporizing one operating power reactor is a really close approximation to one all-out nuclear war's fallout. But there were plenty of others. (Like the chemical reaction that boiled a major fraction of a Soviet waste dump. The highways through a big chunk of Siberia are still "no stopping zones" due to that one.)
Three Mile Island, on the other hand, was just a little bit of radioactive steam. The atmospheric tests and the military reactor oopsies in the US were larger, but a drop in the bucket compared to either of the USSR incidents above.
Yes the Hanford experiment was cold-blooded genocide. So tell me about it. My wife is one of the "marginal population" they experimented on while she was still in the womb - born in the reservation downwind of the deliberate release. And she has the birth defects, thyroid disease, and occasional propaganda mail about how minor it was (which somehow keeps showing up with updated mailing addresses) to prove it. Seems that experiment was STILL GOING ON, with the victims' health being monitored, at least through the fall of the USSR.
But that sort of expenditure and NAZI-style human experimentation is why it was so important to get the cold war STOPPED. Another win for SDI.
After all, after you've got enough to destroy the world three times over, isn't the rest a bit of a waste?
"Overkill" is misunderstood, and is NOT what you are apparently assuming. Consider this:
One bomb of X kilotons, successfully exploded over a target, kills 1/N of your enemy's population. So you need N such bombs to kill all of 'em, right?
Wrong, for two reasons:
1 That 1/N assumes a "good" target - like the concentrated population and infrastructure of an industrial city. After your first 5 or so bombs blow up all the big industrial centers, your next 100 or so have to go after the little industrial centers. It takes maybe K*N to get 'em all. "Overkill" of K.
2 But these things are going in on bombers (that are being shot at) and missiles (that may fail, and may also be shot at - the USSR did deploy anti-missiles despite the treaties, and were actually allowed one by the treaties). If you don't want to shoot first you fired your missiles (and gave "GO" to your planes and subs) AFTER they shot at 'em - maybe after the bombs landed, maybe yours are in flight while theirs are going BANG. So only one in J gets through. To hit them all you need at least J*K "overkill". Actually you need more - because bomb loss is a statistical process. If you only sent J*K*N bombs some targets would get hit twice and some missed. So you need "overkill" beyond J*K to be sure you level everything you intended to level.
So "overkill" doesn't mean "kill 'em I*J*K times". "overkill" means "bomb each target I*J times, throwing I*J*K times as much stuff as you'd need if they were all just like the easiest one and everything worked perfectly, and PRAY that every target gets hit at least once." If I*J*K happens to be larger than 2 * (World Population / Soviet Population), that does NOT mean you have enough bombs to kill everybody in the world twice.
We've threatened to use nukes at least half a dozen times in the last half century (including the Berlin blockade), we've shown we can't abide by the rules of the rest of civilization, and _you_ feel secure?
YO! DUDE! During the wind-down of WW II into the Cold War we announced that we'd defend West Germany (including West Berlin) by whatever means necessary. We made treaties that REQUIRE us to use nukes to defend certain allies, not just ourselves, from certain kinds of attack. We've announced a policy of responding to government-launced nuclear, chemical, or biological attacks, on our allies and on signatories of the non-proliferation agreement, with nuclear retaliation. (You don't need to develop your own bombs - you can use ours.) And we announced that we would treat siting nuclear missiles in the Americas aimed at the US as an act of war.
Those ARE the "rules of civilization". We wrote 'em. Rent a clue!
("We" includes the rest of the winners of WW II. And the surviving losers as well.)
"As I walk through the Valley of the Shadow of Death I will fear no evil. For I am the MEANEST son-of-a-bitch in the Valley!" If you TRY to kill me, your whole country will glow for centuries, with nothing left alive but cocroaches and algae. And everybody who might try a classic nuclear, chemical, or biological first-strike KNOWS it. THAT's why I sleep peacefully at night.
In addition to the "many submit patches, few apply them to the archive" argument, there's another systematic undercount:
A large project will often have a few people whose job is to integrate the code. Sometimes this means only these integration specialists will have write privileges on the archive. The bigger the project, the more likely this is to occur.
==========
That said, what's "small" about a median of four with write privileges? (The mode of one just means that there are more one-man projects hosted at source forge than N>1 man projects for any particular N.) Four active programmers is a moderately big project, and "median of four" (with mode of non-four) implies there's a bunch with more-than-four as well.
Four is a very good size for a large project. Going above that takes a lot of work and is inefficient on a per-programmer basis, unless you have administrative workers who don't program to do the organization. The "human as four-port" analysis shows why.
Consider a human as a "black box" with a number of "ports", representing equal divisions of his time and/or attention. Each port represents enough time per day to communicate with one co-worker or to do one unit of work. Assume also that this amount is such that the number of "ports" on a programmer is about four. (It's probably a bit larger, but four is close and easy to draw.)
In a given amount of time, with a single-committee project:
A one-man project does four units of work:
A two-man project does six units of work:
A three-man project also does six units of work:
A four-man project does FOUR units of work:
And a five-man project bogs down in talk and does no work at all:
With a different number of "ports" the maximum-work group size changes, but the shape of the curve is the same: Adding people first raises the amount of work done, then levels out, then DROPs it until the group paralyzes. For N ports the stall is at N+1 workers. N work about as well as 1 and (N+1)/2 get the maximum work out.(Ever wonder why you spend half your time in meetings? THAT's why! If the goal is to get the project done in the shortest time regardless of personnel cost, the most effective size for a group of peers has each worker spending about half his time interacting with other workers.)
Now there are a number of ways around that. For instance:
1 Keep the team small (or one-man) and push out the delivery date.
2 Reduce the "bandwidth" of the communication ports and expand that of the work ports by assigning work on natural modularity boundaries.
3 Build a hierarchical organization, with some people specializing in communication (and doing little or no "work" on the code) and others mostly doing "work" but only interacting with their comm specialist (administrator) and maybe coworkers on closely-associated modules.
4 Build a hierarchical organization with one or a core group making final inclusion decisions and the bulk of the organization doing actual coding in small snippets.
Taking 1 to the limit results in a bunch of one-man projects with long delivery schedules. One man is the most productive on a code-per-manhour basis. But if the project is too large he slows down asymptopically as he approaches his "boggle limit" - the largest codebase he can maintain single-handed but no logner expand. That was once estimated at about 10K-20K lines of code (about the size of the System 6 Unix kernel, through NO coincidence).
Taking 2 to the extreme is what you get if you conider the open-source movement as a whole as a single project: The developers on each project need little communication with the developers of the others, beyond standards promulgated by a few core developers. Within a project it's the natural way to go, but there are limits to how much it can help.
3 represents your typical industrial software operation. But open-source developers usually hate to become pointy-haired bosses and stop codiing themselves, and without paychecks to hand out they have a lot more trouble herding the cats. So a few big open-source projects are be run by one or a few notable developers with strong personalities who are able to bite that bullet on managing-over-coding and use reputation points in place of paychecks to motivate their workforces. And the rest are one-mans or small teams of friends, self-organizing in grand primate style along the lines of 4.
It was sucessful because they didn't nuke us???
...
...
... and now we live in media induced fear someone will [nuke or germ] us ...
Precicely.
After the climax of WW II, when the world found out a nuke was more than "just a bigger bomb", the game changed.
Up until then it had been progressively bigger wars. Now it was "Let's see if we can avoid a war without surrendering."
So the West came up with the doctrine of "Mutual Assured Destruction" (MAD - i.e. You'd be mad to set off the first nuke. And US presidents had to put on a show of being just crazy enough to use them, or it wouldn't work.) But that's just a stalemate, no "progress" pushing your agenda.
So the East came up with the "Cold War" - with anti-West propaganda and brushfire wars in "domino" countries. (Salami slicing: Pick off the little guys one by one, then the middle-size guys, until the big guy is alone against the world. Cook the Frog: Never create a "Shelling Point" were the chip is knocked off the big guy's shoulder.)
So the West came up with the arms race: "We've got more money so we can outbuid you. You make a missile, we make an anti-missile-missile." (And Rocky and Bullwinkle satarize it with the anti-anti-[pause]-missile-missile-missile.)
And this went on for HALF A CENTURY. Before that it was a major war every generation, with all the "best" weapons in the arsenal in use. Now it was a declining series of "limited wars", with the biggest bombs very carefully NOT used.
Nukes really had made "total war" obsolete. Three war cycles came and went with no World War Three. And it all worked because expensive weapons were built with the intent that they NOT be used, because they'd be too devastating if they were.
There were abortive attempts to limit the proliferation and avoid "destabilizing" situations, in the form of an anti-missile ban and arms reduction treaties. But "stable" meant the Cold War continued to bleed both sides, and one side disarming too fast might mean the War to End All Humanity. Finally Regan abandoned such attempts and went flat-out for better armor, when the USSR couldn't afford to stay even. And the Soviet Union folded.
There was a LOT more to it than that. Like computers and networks for instance. (Restrict communication Soviet style and you slow progress. Have progress in computers and networking and you get communication you can't ban. Try to selectively free your people's communication and you discover that you can't suppress just some. Infrmation wants to be free because PEOPLE want to be free.)
But at the core, preventing nuclear war was done with weapons that worked by NOT being used; weapons that thus created their effects by MAYBE being able to work, so you couldn't risk them actually being used against you.
So, yes, SDI was successfull because they didn't nuke us. The US won the arms race but we ALL won the war.
Get real
Why get real when I can win with virtual weapons? B-)
Nuclear weapons are like smallpox...America is the only country to have ever used them against someone else
I see the public schools have neglected your education when it comes to germ warfare. For starters look at the history of the European dark ages - with diseased animal carcases being catapulted over fortress walls or dropped in wells and rivers during sieges.
Lived that way for over 50 years already - but with the spectre of a massive, simultaneous attack on everything that might be a target (which means essentially everything). One or two suitcase nukes or tactical-shells taking out one city or one dam? ONE plague released in a few spots, using most like non-engineered organisims, rather than a dozen lab-frankenbugs sprayed over a continent simultaneously? Chicken feed. The damage and death is vanishingly small compared to hurricanes and tornadoes, earthquakes, traffic accidents, clogged-arteries, and cancer.
The missle shield was certanly destablizing, it never helped us in any treaty with another super power, not even as a negotiating gambit. [etc.]
Seems to me it worked perfectly.
The Soviet Union collapsed, ending half a century of Cold War. The surviving USSR government officials said the major factor was SDI. Not a single nuclear bomb exploded on or above the soil of the US, its possessions, or its allies (including all the signatories to the non-proliferation treaty). And it was so powerful we didn't even have to actually DEPLOY it!
Lets see your smart bomb or a START-XVI treaty beat THAT!
American manuals are funny.
This page intentionally left blank.
Yes it's an oxymoron and its self-contradiction is funny. But having it on otherwise-blank pages of manuals is really quite important.
Without it, the people in the technical publications department (and readers of the manual) are likely to spend time trying to determine if the page is blank due to an error. Manuals are delayed and costs rise. And if there is not a policy to insert the phrase on blank pages, manuals may occasionally be published with one or more blank pages that aren't SUPPOSED to be blank.
(Of course the humor of that catchphrase has led to parodies. Example: An experimental microchip that (due to the early silicon compiler's tendency to group repetitive circuitry tightly) had some large, rectangular chunks of the chip unused. So the deisngers hand-instantiated that lettering in the blank area.
Look at the government lying about the "tonkin gulf attack" that lead to the nam war.
Actually the Gulf of Tonkin incedent may have been a mistake. As I heard it:
A US ship was cruising around to "show the flag" in the Gulf of Tonkin. Some small fishing boats were nearby. Sonar reported a pair of torpedoes coming at the ship from the direction of the fishing boats. The ship manouvered and was not hit.
The problem is that when a ship makes a turn, sonar reflecting from its wake looks like two torpedoes zeroing in on the ship. The sonar man SHOULD know about this effect and be able to discount it. But giving that they expected a possible attack (indeed, were serving as a shoulder-chip at the time), he might have reported it as a possible and had it blown out of proportion later.
So maybe an honest error. Or maybe a deliberate error. (Or maybe a story I heard that has no relation to fact - things were hectic back then.)
kill or modify the anti-virus programs (including modifying it so it SPREADS the virus)
THAT'S the one to worry about.
Tell me about it.
I've been worried for a long time about a trojan disguised as an anti-virus update that used the anti-virus software to "fix" uninfected files by infecting them.
Or a variant: One manufacturer's anti-virus configuration treating a competitor's software as being malicious and disabling it.
If Windows' virus scanner didn't catch the virus on the initial infection (when it infected the Linux partition), why would it be useful to infect the computer via Linux as a means of avoiding the Windows virus scanning software?
Because the virus could do things from the Linux environment that WOULD have been detected by the anti-virus software if it tried it from the Windows environment during the initial infection.
Actually its less common than you think. Several hundred firemen every year get caught setting fires and of those several hundred the majority are volunteer.
... the answer is [obviously] 'No'". My point is that, though the question may be taken as an insult, the "No" answer is NOT obvious, and if the analogy presented was to hold you would expect a small number of anti-virus software writers to write (and release) viruses, either to drum up more business or just because they can.
There are an enormous number of firemen in the country, and a small number of jolly firebugs among their number setting fires. My impression is that the fraction of do-badders among them is MUCH smaller than that of the general population. Unfortunately, it is not zero.
That said: My post was in response to the original poster's claim that "[asking if employees of antivirus companies writeing viruses is] a very insulting question, like asking firemen if they start fires
Somewhere between one in fifty and one in two hundred of the general population is psychopathic. It appears to be a brain disfunction (analogous to color-blindness, though not necessarily genetic) with effects that amount to "no conscience" and which does not correlate strongly with intelligece (i.e. they may be smart or dumb). They have no sense of right vs. wrong. Those that don't compensate by learning a moral ruleset (or who learn one with holes in it) may commit horrendous crimes and be bemused when others dislike them for it. Those who do compensate often excell in positions where they make life-affecting or life-critical decisions - such as surgery, military/police/fire-fighting (especially command), politics, and business management - because their rational decision-making is not clouded by bursts of emotion when lives or livelihoods are being lost. Though they run the risk of becoming moralistic, they are arguably the most virtuous among us - because they CHOSE virtue, rather than having it thrust upon them.
It is a tribute to our fire-fighters and their institutions that, with a large enough force that there are BOUND to be a few of the conscience-deficient among them, they turn out so many heroes (whether consciencefull or conscienceless) and so few below-zeros.
As for the anti-virus software writers: The data is not in. Let us all hope they do as well.
A hybrid virus could have its own filesystem code, and thereby infect say a linux partition on a dual-boot machine that is currently booted in windows,
In other words, Windows is SO insecure that running it on a dual-boot Win/Lin machine opens a hole to infect the Linux partition. B-)
It is, of course, a very insulting question, like asking firemen if they start fires, or dentists if they're the cause of tooth decay.
True story: My dentist, when I was a kid, would give out lollipops. Pure sugar, artificially-colored, decay-inducing lollipops. Swear to God.
Also: More than one fire department has been caught setting fires to put out. (It's especially prevalant among volunteer fire departments, which are often composed of people who enjoy playing with fires.)