Every known matter particle has an antiparticle which has identical mass, but opposite charges (for every kind of charge, including electrical). We don't know why, they just do. There doesn't seem to be much antimatter out there; again, for reasons unknown.
Antiparticles still have positive mass, like every other known particle, and are not repelled by gravity.
When a particle meets its antiparticle, they are converted into their combined mass worth of energy in accord with: E=mc^2 (where E is the energy, m is the combined mass, and c^2 is a ludicrously large number). Hence, antimatter is the most compact form of energy storage theoretically possible.
In other words, pretty good rocket fuel. Antimatter bombs would be rather unpleasant, and any contained antimatter is a potential bomb (there's nothing "potential" about uncontained antimatter for very long).
There is no reliable, efficient way of making antimatter, and no place to just pick it up for free. However, if you smash protons together hard enough with huge particle accelerators, they occasionally spit out highly energetic photons that decay into matched matter/antimatter particle pairs. With luck, you can catch a few in a magnetic field and hold them for a little while. This is about as cost-effective as it sounds.
If you ever meet your anti-self, and he hasn't exploded yet, either he or you will before you have a chance to shake his hand, so don't worry about it.
Despite this title, and the potential benefits of effective antimatter storage, antimatter can not be contained by a nutshell. Don't try.
It's not illegal to be anticompetitive if you're not a monopoly.
Do you really think a software license from Apple that went, "Anyone may make any use of this software, except Microsoft employees, or contractors, who are not permitted to make any use of this software or any derivatives of this software." would be entirely kosher?
The principle that businesses should compete like runners in a race, rather than attack each other like boxers, is woven through the entire body of civil law, not just antitrust law.
A court could order you to release your source code into the public domain no matter what license you use. But only in extreme circumstances would a court do so no matter what license you chose.
The important fact here is that the GPL is only a hair away from the public domain already. Like the absurd example above, it can be interpreted as essentially "public domain for everyone (except these businesses I hate, which are only offered limited use)." Admittedly, that's an odd interpretation given the language of the GPL, but not so terribly odd after reading the "philosophy" section of the GNU home page. Intent matters.
The X11 license doesn't have an advertising clause; that's the BSD license you're thinking about.
From http://www.x.org/terms.htm referred by the GNU homepage as "The X11 License" and compatible with the GPL:
"Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder."
Re:Why do I suspect you're misrepresenting?
on
Free The TA Source Code
·
· Score: 3, Interesting
No one wants that; if GPL code loses protection, so does Microsoft code.
More licence folklore. Fans of the GPL might find this nice to imagine, but breaking the GPL doesn't necessarily mean breaking all copyright protection for software. Contract law is complex and subtle, and more defined by principles involving intent, reasonability, and effect than by hard mechanistic rules.
The GPL is a rather unusual (perhaps "bizarre" would be a better word) contract. It's purpose is not to secure direct material profit, but primarily to allow all use except incorporation into closed source software.
Consider that the intent of putting a product under the GPL might be considered to be anticompetitive, an attempt to force established companies to release trade secrets and give up their ability to withhold software from those who haven't paid if they wish to interoperate with complex standards. The restrictions of the GPL could be struck down without affecting the permissions, if the court determines this is the proper remedy.
The GPL was born out of frustration, and written with hostility against the commercial software establishment. Contracts written with hostile intent toward anyone are always questionable.
The X11 license can also be used with any license ever used
It has been interpreted to be compatible with the GPL, but that doesn't guarantee the courts will agree with this interpretation if someone using the X11 or GNU license disagrees. It is debatable whether the advertising thing is an additional and incompatible restriction. The FSF has no power to define the proper interpretation of software contracts, they can only make their own guesses about what would happen in court.
Why do I suspect you're misrepresenting?
on
Free The TA Source Code
·
· Score: 4, Insightful
I have never heard of someone being successfully sued for a piece of public domain software being poor quality, without an explicit warranty, and I've looked pretty hard.
Can anyone provide a single example?
This is brought up over and over again as a reason not to release code into the public domain, but I've never seen any evidence that a disclaimer sent along with the initial release of public domain software is any less valid than one included in a licence such as the GPL. I believe it's a bit of licence folklore.
First thing: it is widely accepted that you don't need to agree to the GPL to use GPL software, only to distribute it. You don't even have to read it. That means you don't have to see or agree to any disclaimer of warranty.
Similarly, the end users of BSD or X type licenses don't have to see or agree to the terms. Under copyright law, having legally obtained a copy of software, by default you have the right to run it and back it up. Shrink wrap and click-through licenses are both somewhat legally shaky, but still a lot stronger than something you don't even see unless you look for it.
Furthermore, a case could be made that a copyright holder is more likely to be held responsible for defects in his work than a contributor to the public domain. Blanket disclaimers of warranty, especially tucked quietly away in a corner of a contract (especially one presented as "standard" or a mere formality, and not offering the opportunity to negociate), and in strong contrast to public claims, fall somewhere between weak and completely invalid.
Hell, the GPL still hasn't ever been tested in court. There are reasons to believe that releasing software under the GPL is putting it in the public domain, and it is just one test case away from being treated as such.
Picking a licence causes problems, too. The most important one is licence incompatibility: choose one, and you prevent the code from being used in projects using an incompatible licence, while public domain code can be included in projects using any licence I've heard of.
If the problem of liability is not a real one, then public domain is the simplest, easiest to understand, most reliable way to give people the full free use of your code.
Although I can't go into details (still under NDA after 6 years technically), we got bitten by this at a large software house not so long ago. Basically, some of our examples in the documentation were marked as "public domain" software and a third party began to redistribute the examples in binary form with added graphical interfaces. It turned out of the developers of this GUI had written his code on another company's time, and that company decided to sue us. Since there was no limitation of liability in our distributed source code, our lawyers had a harder time justifying our position.
You left out the most crucial part: What was their complaint? It doesn't sound like it had anything to do with merchantability or fitness for a particular purpose, or any sort of implied warranty.
It sounds to me a lot more like an accusation of your company being involved in the unauthorized use of this worker's paid time.
NDA or not, if you're not willing to specify enough details to show whether and how your example is relevant, you shouldn't have brought it up. I think you're using your NDA as an excuse to make vague references to a case that doesn't apply.
Mainly, don't be boring. There is no shortage of windowing systems that do what everyone else is doing, with a few mostly useless features and some buzzword compliance added to distinguish themselves from the pack. The easiest thing in the world to do is make a second-rate clone of an existing system, and that won't do anyone any good.
If you want to see interesting and innovative interfaces, look at games. They are free to experiment and be unfamiliar, people even enjoy the exotic feeling of escape from the humdrum world of standard interfaces. Of course, there is more bad than good, but it's always that way where people are trying new things.
Okay, one reference: Ask Tog. Lots of good thoughts on interface design. One of his gripes stands out for me in particular: the importance of the corners of the screen in a mouse-based interface. You can always hit the corners without looking, and with a little practice, you can also hit things near the corners by "bouncing" off the corner. Radial menus out of the corners are probably the easiest thing in the world to hit reliably and quickly. Don't neglect the corners!
Of course, this goes right out if you switch to a pen. In a lot of ways, current interfaces are much better suited to pens than to mice.
Scenario A: People are given $10, they are allowed a chance to give any part of that to another participant in the experiment, who they don't know (who will otherwise not be given anything).
Result: Very few people give any. The average is under a dollar.
Scenario B: People are given $10, they are allowed a chance to give any part of that to another participant in the experiment, who they don't know (who will otherwise not be given anything), but for every dollar they give, the researchers will kick in another dollar for the other person.
Result: Considerably more people give. The average (given, not received) approaches $5.
Conclusion: these psychological experiments are impossible to interpret and contradictory. One can be found to support almost any conclusion. They should not be considered to offer meaningful insight into human behavior.
In such cases, the people know they are in a psychological experiment (or at least a very unnatural situation), and that knowledge is likely the primary influence on their behavior (especially when the risks and rewards are insignificantly small), making it impossible to extrapolate the results to behavior outside of experiments.
NegWeb is a "semi-literate" programming tool. Basically, it lets you define chunks of output files in any order, in any location in input files. So if you want to put the chunk of documentation for a feature in LaTeX or HTML just before the chunk containing its implementation, you are free to do so.
It differs from other literate programming tools in that it doesn't have any concept of formatting the NegWeb source as a whole. Literate programming started with Donald Knuth's WEB, which arranges Pascal in the same way that NegWeb arbitrary text files (an operation called "tangling," since the results are compilable, but not pretty), but also indexes and pretty prints the Pascal and treats the text between the code chunks as TeX (called "weaving"). Knuth later created CWEB, which does the same thing, but for C instead of Pascal.
My problem with this approach is that when you go to edit it, you deal with the ugly TeX source, or you reweave constantly. Also, unless you are such a TeX wizard that you do it without ever thinking or looking things up, you are distracted from working on your functional output by fiddling with the formatting. The NoWeb approach is to have the plain text source the most readable version of the source, on the principle that code is most often read to be edited.
The name is a play on NoWeb, which is essentially a simplified and generalized CWEB, since NegWeb is essentially a simplified (some literate programmers would say "crippled") and generalized NoWeb. NoWeb is very extensible, and supports indexing and pretty-printing for a lot of languages, as well as using several different formatting languages for weaving, such as LaTeX and HTML.
Either would work for rearranging arbitrary ASCII text chunks into files: NegWeb is simpler, NoWeb is prettier.
You might be surprised at the freedom it gives you to factor your code into short, manageable chunks. It definitely helps to set up a few macros in your text editor to treat the chunk names as hyperlinks to find the definition of the chunk, and all places it is used.
Apple Computers: Proper noun, descriptive term. Lovely trademark. "Apple" isn't a descriptive term for any component of a computer system, hardware or software, so it's as good as a nonsense-word.
Kleenex: Total nonsense word, when they started off, certainly a good trademark then. Haven't they lost their trademark on it, due to it slipping into the common usage as a general term for facial tissues?
This happens from time to time, when a single company is overwhelmingly popular and the descriptive term is too unwieldy for popular use, like "facial tissues." If they haven't, that's another failure of the system and another victory of corporate brute-force legal tactics over rule of law. I do know they fought it, once they saw the danger, but I also know that practically everybody calls facial tissues "kleenex" regardless of the brand.
That wouldn't stop them from advertising "Kleenex brand kleenex: the original and still the best!" it just wouldn't let them stop others from selling what everybody calls "kleenex" as "kleenex."
Calling a windowed operating system "Windows" is like naming an automobile "Wheels." It's a generic descriptor, and managing to enforce it as a trademark suggests underhanded legal tactics (in particular scare tactics) against small challengers and generous settlements against large challengers. Either that, or clueless judges, or both.
Remember MS's defense over the Internet Explorer trademark suit? "Internet Explorer" is too general and vague to be a trademark. "Windows" is just the same. Ditto for "Office," "Word," "Access," "Visual BASIC," and any number of similar names used by MS (I have no idea which ones they claim as trademarks by themselves). You seem to be completely ignoring this aspect.
Now, if they were making something that sounded confusingly like "Microsoft Windows," MS would have an airtight case. However, MS should never have had a hope of holding "Windows" alone as a trademark, and that they do is a serious failure of the legal process.
Now, as a lawyer, you are certainly better qualified than I am to predict failures of the legal process; in some areas, I'm sure that common failures are more imporant than the letter of the law. I can't argue with you if you claim that MS will win this, but it is absurd for you to claim that they should win, that a court upholding their exclusive right within the industry to use a standard industry term as a name for the most visible component of their system would be fair and proper.
There should be no problem with having "IBM Windows," "Sun Windows," etc. let alone "Lindows."
Now, this last bit has nothing to do with current law, to the best of my knowledge, but I remember hearing a principle of trademarks that I really wish was law: all linguistic trademarks should consist of a proper noun followed by a descriptive term. Nobody should ever own marketing catchphrases, fictional character names, or descriptive terms as trademarks by themselves. (I don't recall the source)
In real-world situations, you don't have accurate data for the cost of each link. Only approximations, built on probabilities of delays, estimates of how many packages will be ordered, etc.
The miniscule gain of selecting the best possible path rather than just a very good path would likely be reduced to an imperceptible gain when applied to rough real-world estimates.
There would be some extremely important consequences of P=NP, but direct application of a faster optimal solution of the Travelling Salesman problem to real-world travelling is not likely to be one of them.
Hmm... You can see where this is going, right?
on
Portable GameCube
·
· Score: 2
In a couple of years, when the components have shrunk, become cheaper and less power hungry, we have the instant Gameboy Advance successor selling for $100 a pop, with a nice library of games on small, portable media.
Nintendo is the king of portables, and I think they intend to stay that way.
Arthur C. Clarke was a scientist who, among other things, wrote a paper explaining and introducing the principles of geostationary communications satellites before he sold his first hard science fiction story.
Tom Clancy got his degree in English, and worked as an insurance broker before he became a military drama novelist.
Re:Also under development:
on
Battlefield Lasers
·
· Score: 4, Interesting
Mirror coating, etc. doesn't make a difference.
To be blunt, this is wrong. I do agree, however, that just polishing up a stainless steel shell until you can shave in front of it probably won't make enough difference. Most mirrors don't reflect nearly enough light.
On the other hand, such powerful lasers are hard to make and very expensive. It would be tempting to make them just barely strong enough to work against existing designs which have no defense against such countermeasures. If a spinning (or randomly tumbling), mirrored shell, can cut down the rate of heating by something like 30%, and there's some extra heat-shielding inside, it might be enough to survive.
All kidding aside, you also can't rule out, as I said, revolutionary new developments in mirrored armor. I mean, if there was no way to deflect the beam, there would be no way to generate or aim it!
BTW, Tom Clancy is a novelist, not a physicist. His entire livelihood is sounding plausible about things he doesn't really understand.
Besides, in the battle between bigger armor and bigger guns, the guns always win eventually.
Ah, but which is which? This is an odd historical precedent to apply in favor of a defense mechanism.
...not that the label helps anything. I mean, there's no really clear line between "addiction" and "bad habit."
Multiplayer RPGs are the worst in this way. They give you little rewards every once in a while, for staying on longer, and they tend to be open-ended. In that way, they are designed just like gambling machines: designed to give you random rewards that condition you to want to keep playing. Also, hardcore players, rather than being ridiculed, are respected for the in-game power they develop, so there's social pressure to play more, rather than to play moderately.
I experienced that sort of weirdness when I was developing Beng the Battle Engine, a chat-room RPG battle engine. I thought the sheer repetitiveness of the gameplay (and total lack of graphics, story, or setting) would make it at best a side toy for people to play with when the conversation slowed down, or while waiting for someone they wanted to talk to to show up. Imagine my surprise when a few people basically moved in and spent 8 hours per day or more.
They'd level up past the point I thought anyone would ever get to in just days. I was disturbed. I mean, I was proud they enjoyed it, but I didn't think that much play was healthy. Of course, they didn't continue like that forever. It's just not that good a game, after a hundred hours or so, you've seen everything you could ever see, and then the novelty of being the toughest guy in a game with only a couple dozen players wears off pretty quickly. Some wandered off, and some picked up the source code and started hacking on it, which gave me a lot better feeling about the whole thing.
But it makes me worry about better games. If a cheesy IRC-based micro-MUD can suck away hundreds of hours like that, how far off can the name "EverCrack" be? And there's better stuff coming out all the time!
The given example apparatus would not be a practical device in any way. It needs a way to allow photons in, and could just as easily allow photons out; additionally, the inner surface of the sphere needs to be a photon detector with very precise timing. It doesn't see anything a camera inside the sphere couldn't see.
This is about exploring quantum entanglement. When lasers were invented, nobody knew what to do with them. Everybody thought "Death ray!" which was pretty silly in retrospect; that's a minor application. Then, bit by bit, they found thousands of ways to apply them that revolutionized all sorts of practical devices and allowed entirely new ones.
Developing this would be breaking old rules about what is and isn't possible, and though it's hard to guess exactly what it's good for, you can bet it'll be good for some amazing new technologies.
All the execs would rather lay off people than cut their [own] salaries.
Well, of course! When was the last time you took a pay cut for someone else's job?
Perhaps this is incompetence on the part of the owners, but it's not management incompetence to take as high a salary as you are allowed. You just don't turn down money from the boss. Your work and everything under you is your problem, the expense of your salary and everything above you is your superiors' problem.
very few ideas, if any, spring from the mind of one individual. In reality all high-tech ideas leverage the ideas of many who never get attribution. That's just a fact.
Yeah, that's the point of patents: to make sure good ideas get spread around and seed more good ideas, instead of being hidden and exploited to lesser profit in secret; it's also a major ideological objection to granting monopoly power to any one entity. It cuts both ways.
I love Ruby, especially for the arbitrary-sized integers by default (this might seem like a minor feature, but I deal with exact numbers over a few billion so often that I hate to fumble with extensions and libraries for it), but one thing that confuses me is the block structure. Why "end"?
Why are static conditional and loop blocks, and function and class definitions, so different from the brace type of general blocks, and so different-looking from Perl? And why is the option of "do ||... end" or "{||...}" not more general?
For example (and please correct me if my assumption is wrong), why can you choose between "for do ||... end" and "for {||... }", but not between "def func(n)... end" and "def func {|n|... }" ?
His argument is basically - Wellllll, the Playstation sold the most console ever sooooo that means the Gamecube will be the worst system ever.
Actually, it's more like, GameCube is a less powerful system, with few games, with less developer support, which doesn't play DVDs, didn't actually have strong opening sales, is aimed primarily at small children but with inappropriately fragile media, and is trying to enter a market which is already deliriously in love with it's competition.
Everyone who likes video games wants the PS2, and will buy the PS2 in preference to anything else. GameCube is relegated second system status in a market where few buy a second system, and then it's most commonly to correct their mistake of overenthusiastically picking up the less popular system (he backs this point up with hard numbers).
The point that it would take a couple of years for Nintendo to sell as many GameCubes as there are PS2s out there is a bit of an aside, an explanation of why the developer support is weak, since the GameCube market is going to be miniscule compared to the PS2 market for some time.
The computer is the favorite "busy toy" of someone who doesn't really want to work at work. That, combined with the efficiency gains, has lead to a lot of people doing a lot of nothing aside from maintaining the appearance that they shouldn't be fired. The pointless meanings, aimless memos, unnecessary and ineffective initiatives, etc. Thus the gains of computers are deliberately concealed.
The second of the problem is computers being untrusted and used as a parallel system. There is no such thing as a paperless office. Paper records are kept parallel to computer records, sometimes requiring all of the old work, and all of the computer work. This is more often an apparent problem than a real one, as it moves a smaller amount of administrative work to an earlier time. While it's less efficient than it could be, it's better than not using computers.
The third part, aside from being a problem in itself, is half a cause and half an effect of the second; they grew up intertwined. As home computer systems were adapted to office use, and the first generation of programmers raised with computers from a young age appeared, reliability was sacrificed in favor of attractiveness, apparent ease of learning, and flashy feature checklists. Software is replaced every few years, and old data is lost or damaged. Many users stopped considering computers infallable and started considering them unreliable, dramatically limiting their use.
This last one is indisputably a real, serious problem in software design. Software is rushed to market, then thrown away just as the bugs are worked out. But this is more directly a problem of poor software purchasing; the market demands features, useful or not, and the software industry can only comply to that demand, or be unprofitable and unappreciated.
If you want to be able to use it directly for real general-purpose programming, in the existing environment, it has to interface to any C library. That's a long way above and beyond Turing completeness.
This changes it from a "closed" language, with fully-specified behavior, complete within itself, to an open language which may be extended to arbitrary behavior with external modules, so it's not really a small language at all, just a small interface to a huge language. It either needs to be a compiled language, or to have compiled modules.
On the other hand, if you are willing to allow an environment designed as needed, to access all needed functionality in the form of one input and one output line, it returns to the sort of task a Turing machine can do.
Slashdot Mirror
Every known matter particle has an antiparticle which has identical mass, but opposite charges (for every kind of charge, including electrical). We don't know why, they just do. There doesn't seem to be much antimatter out there; again, for reasons unknown.
Antiparticles still have positive mass, like every other known particle, and are not repelled by gravity.
When a particle meets its antiparticle, they are converted into their combined mass worth of energy in accord with: E=mc^2 (where E is the energy, m is the combined mass, and c^2 is a ludicrously large number). Hence, antimatter is the most compact form of energy storage theoretically possible.
In other words, pretty good rocket fuel. Antimatter bombs would be rather unpleasant, and any contained antimatter is a potential bomb (there's nothing "potential" about uncontained antimatter for very long).
There is no reliable, efficient way of making antimatter, and no place to just pick it up for free. However, if you smash protons together hard enough with huge particle accelerators, they occasionally spit out highly energetic photons that decay into matched matter/antimatter particle pairs. With luck, you can catch a few in a magnetic field and hold them for a little while. This is about as cost-effective as it sounds.
If you ever meet your anti-self, and he hasn't exploded yet, either he or you will before you have a chance to shake his hand, so don't worry about it.
Despite this title, and the potential benefits of effective antimatter storage, antimatter can not be contained by a nutshell. Don't try.
It's not illegal to be anticompetitive if you're not a monopoly.
Do you really think a software license from Apple that went, "Anyone may make any use of this software, except Microsoft employees, or contractors, who are not permitted to make any use of this software or any derivatives of this software." would be entirely kosher?
The principle that businesses should compete like runners in a race, rather than attack each other like boxers, is woven through the entire body of civil law, not just antitrust law.
A court could order you to release your source code into the public domain no matter what license you use. But only in extreme circumstances would a court do so no matter what license you chose.
The important fact here is that the GPL is only a hair away from the public domain already. Like the absurd example above, it can be interpreted as essentially "public domain for everyone (except these businesses I hate, which are only offered limited use)." Admittedly, that's an odd interpretation given the language of the GPL, but not so terribly odd after reading the "philosophy" section of the GNU home page. Intent matters.
The X11 license doesn't have an advertising clause; that's the BSD license you're thinking about.
From http://www.x.org/terms.htm referred by the GNU homepage as "The X11 License" and compatible with the GPL:
"Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder."
No one wants that; if GPL code loses protection, so does Microsoft code.
More licence folklore. Fans of the GPL might find this nice to imagine, but breaking the GPL doesn't necessarily mean breaking all copyright protection for software. Contract law is complex and subtle, and more defined by principles involving intent, reasonability, and effect than by hard mechanistic rules.
The GPL is a rather unusual (perhaps "bizarre" would be a better word) contract. It's purpose is not to secure direct material profit, but primarily to allow all use except incorporation into closed source software.
Consider that the intent of putting a product under the GPL might be considered to be anticompetitive, an attempt to force established companies to release trade secrets and give up their ability to withhold software from those who haven't paid if they wish to interoperate with complex standards. The restrictions of the GPL could be struck down without affecting the permissions, if the court determines this is the proper remedy.
The GPL was born out of frustration, and written with hostility against the commercial software establishment. Contracts written with hostile intent toward anyone are always questionable.
The X11 license can also be used with any license ever used
It has been interpreted to be compatible with the GPL, but that doesn't guarantee the courts will agree with this interpretation if someone using the X11 or GNU license disagrees. It is debatable whether the advertising thing is an additional and incompatible restriction. The FSF has no power to define the proper interpretation of software contracts, they can only make their own guesses about what would happen in court.
I have never heard of someone being successfully sued for a piece of public domain software being poor quality, without an explicit warranty, and I've looked pretty hard.
Can anyone provide a single example?
This is brought up over and over again as a reason not to release code into the public domain, but I've never seen any evidence that a disclaimer sent along with the initial release of public domain software is any less valid than one included in a licence such as the GPL. I believe it's a bit of licence folklore.
First thing: it is widely accepted that you don't need to agree to the GPL to use GPL software, only to distribute it. You don't even have to read it. That means you don't have to see or agree to any disclaimer of warranty.
Similarly, the end users of BSD or X type licenses don't have to see or agree to the terms. Under copyright law, having legally obtained a copy of software, by default you have the right to run it and back it up. Shrink wrap and click-through licenses are both somewhat legally shaky, but still a lot stronger than something you don't even see unless you look for it.
Furthermore, a case could be made that a copyright holder is more likely to be held responsible for defects in his work than a contributor to the public domain. Blanket disclaimers of warranty, especially tucked quietly away in a corner of a contract (especially one presented as "standard" or a mere formality, and not offering the opportunity to negociate), and in strong contrast to public claims, fall somewhere between weak and completely invalid.
Hell, the GPL still hasn't ever been tested in court. There are reasons to believe that releasing software under the GPL is putting it in the public domain, and it is just one test case away from being treated as such.
Picking a licence causes problems, too. The most important one is licence incompatibility: choose one, and you prevent the code from being used in projects using an incompatible licence, while public domain code can be included in projects using any licence I've heard of.
If the problem of liability is not a real one, then public domain is the simplest, easiest to understand, most reliable way to give people the full free use of your code.
Although I can't go into details (still under NDA after 6 years technically), we got bitten by this at a large software house not so long ago. Basically, some of our examples in the documentation were marked as "public domain" software and a third party began to redistribute the examples in binary form with added graphical interfaces. It turned out of the developers of this GUI had written his code on another company's time, and that company decided to sue us. Since there was no limitation of liability in our distributed source code, our lawyers had a harder time justifying our position.
You left out the most crucial part: What was their complaint? It doesn't sound like it had anything to do with merchantability or fitness for a particular purpose, or any sort of implied warranty.
It sounds to me a lot more like an accusation of your company being involved in the unauthorized use of this worker's paid time.
NDA or not, if you're not willing to specify enough details to show whether and how your example is relevant, you shouldn't have brought it up. I think you're using your NDA as an excuse to make vague references to a case that doesn't apply.
Mainly, don't be boring. There is no shortage of windowing systems that do what everyone else is doing, with a few mostly useless features and some buzzword compliance added to distinguish themselves from the pack. The easiest thing in the world to do is make a second-rate clone of an existing system, and that won't do anyone any good.
If you want to see interesting and innovative interfaces, look at games. They are free to experiment and be unfamiliar, people even enjoy the exotic feeling of escape from the humdrum world of standard interfaces. Of course, there is more bad than good, but it's always that way where people are trying new things.
Okay, one reference: Ask Tog. Lots of good thoughts on interface design. One of his gripes stands out for me in particular: the importance of the corners of the screen in a mouse-based interface. You can always hit the corners without looking, and with a little practice, you can also hit things near the corners by "bouncing" off the corner. Radial menus out of the corners are probably the easiest thing in the world to hit reliably and quickly. Don't neglect the corners!
Of course, this goes right out if you switch to a pen. In a lot of ways, current interfaces are much better suited to pens than to mice.
Scenario A: People are given $10, they are allowed a chance to give any part of that to another participant in the experiment, who they don't know (who will otherwise not be given anything).
Result: Very few people give any. The average is under a dollar.
Scenario B: People are given $10, they are allowed a chance to give any part of that to another participant in the experiment, who they don't know (who will otherwise not be given anything), but for every dollar they give, the researchers will kick in another dollar for the other person.
Result: Considerably more people give. The average (given, not received) approaches $5.
Conclusion: these psychological experiments are impossible to interpret and contradictory. One can be found to support almost any conclusion. They should not be considered to offer meaningful insight into human behavior.
In such cases, the people know they are in a psychological experiment (or at least a very unnatural situation), and that knowledge is likely the primary influence on their behavior (especially when the risks and rewards are insignificantly small), making it impossible to extrapolate the results to behavior outside of experiments.
NegWeb is a "semi-literate" programming tool. Basically, it lets you define chunks of output files in any order, in any location in input files. So if you want to put the chunk of documentation for a feature in LaTeX or HTML just before the chunk containing its implementation, you are free to do so.
It differs from other literate programming tools in that it doesn't have any concept of formatting the NegWeb source as a whole. Literate programming started with Donald Knuth's WEB, which arranges Pascal in the same way that NegWeb arbitrary text files (an operation called "tangling," since the results are compilable, but not pretty), but also indexes and pretty prints the Pascal and treats the text between the code chunks as TeX (called "weaving"). Knuth later created CWEB, which does the same thing, but for C instead of Pascal.
My problem with this approach is that when you go to edit it, you deal with the ugly TeX source, or you reweave constantly. Also, unless you are such a TeX wizard that you do it without ever thinking or looking things up, you are distracted from working on your functional output by fiddling with the formatting. The NoWeb approach is to have the plain text source the most readable version of the source, on the principle that code is most often read to be edited.
The name is a play on NoWeb, which is essentially a simplified and generalized CWEB, since NegWeb is essentially a simplified (some literate programmers would say "crippled") and generalized NoWeb. NoWeb is very extensible, and supports indexing and pretty-printing for a lot of languages, as well as using several different formatting languages for weaving, such as LaTeX and HTML.
Either would work for rearranging arbitrary ASCII text chunks into files: NegWeb is simpler, NoWeb is prettier.
You might be surprised at the freedom it gives you to factor your code into short, manageable chunks. It definitely helps to set up a few macros in your text editor to treat the chunk names as hyperlinks to find the definition of the chunk, and all places it is used.
Apple Computers: Proper noun, descriptive term. Lovely trademark. "Apple" isn't a descriptive term for any component of a computer system, hardware or software, so it's as good as a nonsense-word.
Kleenex: Total nonsense word, when they started off, certainly a good trademark then. Haven't they lost their trademark on it, due to it slipping into the common usage as a general term for facial tissues?
This happens from time to time, when a single company is overwhelmingly popular and the descriptive term is too unwieldy for popular use, like "facial tissues." If they haven't, that's another failure of the system and another victory of corporate brute-force legal tactics over rule of law. I do know they fought it, once they saw the danger, but I also know that practically everybody calls facial tissues "kleenex" regardless of the brand.
That wouldn't stop them from advertising "Kleenex brand kleenex: the original and still the best!" it just wouldn't let them stop others from selling what everybody calls "kleenex" as "kleenex."
Calling a windowed operating system "Windows" is like naming an automobile "Wheels." It's a generic descriptor, and managing to enforce it as a trademark suggests underhanded legal tactics (in particular scare tactics) against small challengers and generous settlements against large challengers. Either that, or clueless judges, or both.
Remember MS's defense over the Internet Explorer trademark suit? "Internet Explorer" is too general and vague to be a trademark. "Windows" is just the same. Ditto for "Office," "Word," "Access," "Visual BASIC," and any number of similar names used by MS (I have no idea which ones they claim as trademarks by themselves). You seem to be completely ignoring this aspect.
Now, if they were making something that sounded confusingly like "Microsoft Windows," MS would have an airtight case. However, MS should never have had a hope of holding "Windows" alone as a trademark, and that they do is a serious failure of the legal process.
Now, as a lawyer, you are certainly better qualified than I am to predict failures of the legal process; in some areas, I'm sure that common failures are more imporant than the letter of the law. I can't argue with you if you claim that MS will win this, but it is absurd for you to claim that they should win, that a court upholding their exclusive right within the industry to use a standard industry term as a name for the most visible component of their system would be fair and proper.
There should be no problem with having "IBM Windows," "Sun Windows," etc. let alone "Lindows."
Now, this last bit has nothing to do with current law, to the best of my knowledge, but I remember hearing a principle of trademarks that I really wish was law: all linguistic trademarks should consist of a proper noun followed by a descriptive term. Nobody should ever own marketing catchphrases, fictional character names, or descriptive terms as trademarks by themselves. (I don't recall the source)
In real-world situations, you don't have accurate data for the cost of each link. Only approximations, built on probabilities of delays, estimates of how many packages will be ordered, etc.
The miniscule gain of selecting the best possible path rather than just a very good path would likely be reduced to an imperceptible gain when applied to rough real-world estimates.
There would be some extremely important consequences of P=NP, but direct application of a faster optimal solution of the Travelling Salesman problem to real-world travelling is not likely to be one of them.
In a couple of years, when the components have shrunk, become cheaper and less power hungry, we have the instant Gameboy Advance successor selling for $100 a pop, with a nice library of games on small, portable media.
Nintendo is the king of portables, and I think they intend to stay that way.
Arthur C. Clarke was a scientist who, among other things, wrote a paper explaining and introducing the principles of geostationary communications satellites before he sold his first hard science fiction story.
Tom Clancy got his degree in English, and worked as an insurance broker before he became a military drama novelist.
Mirror coating, etc. doesn't make a difference.
To be blunt, this is wrong. I do agree, however, that just polishing up a stainless steel shell until you can shave in front of it probably won't make enough difference. Most mirrors don't reflect nearly enough light.
On the other hand, such powerful lasers are hard to make and very expensive. It would be tempting to make them just barely strong enough to work against existing designs which have no defense against such countermeasures. If a spinning (or randomly tumbling), mirrored shell, can cut down the rate of heating by something like 30%, and there's some extra heat-shielding inside, it might be enough to survive.
All kidding aside, you also can't rule out, as I said, revolutionary new developments in mirrored armor. I mean, if there was no way to deflect the beam, there would be no way to generate or aim it!
BTW, Tom Clancy is a novelist, not a physicist. His entire livelihood is sounding plausible about things he doesn't really understand.
Besides, in the battle between bigger armor and bigger guns, the guns always win eventually.
Ah, but which is which? This is an odd historical precedent to apply in favor of a defense mechanism.
Revolutionary new developments in extremely shiny rockets, artillery shells, and even mortars.
...not that the label helps anything. I mean, there's no really clear line between "addiction" and "bad habit."
Multiplayer RPGs are the worst in this way. They give you little rewards every once in a while, for staying on longer, and they tend to be open-ended. In that way, they are designed just like gambling machines: designed to give you random rewards that condition you to want to keep playing. Also, hardcore players, rather than being ridiculed, are respected for the in-game power they develop, so there's social pressure to play more, rather than to play moderately.
I experienced that sort of weirdness when I was developing Beng the Battle Engine, a chat-room RPG battle engine. I thought the sheer repetitiveness of the gameplay (and total lack of graphics, story, or setting) would make it at best a side toy for people to play with when the conversation slowed down, or while waiting for someone they wanted to talk to to show up. Imagine my surprise when a few people basically moved in and spent 8 hours per day or more.
They'd level up past the point I thought anyone would ever get to in just days. I was disturbed. I mean, I was proud they enjoyed it, but I didn't think that much play was healthy. Of course, they didn't continue like that forever. It's just not that good a game, after a hundred hours or so, you've seen everything you could ever see, and then the novelty of being the toughest guy in a game with only a couple dozen players wears off pretty quickly. Some wandered off, and some picked up the source code and started hacking on it, which gave me a lot better feeling about the whole thing.
But it makes me worry about better games. If a cheesy IRC-based micro-MUD can suck away hundreds of hours like that, how far off can the name "EverCrack" be? And there's better stuff coming out all the time!
The given example apparatus would not be a practical device in any way. It needs a way to allow photons in, and could just as easily allow photons out; additionally, the inner surface of the sphere needs to be a photon detector with very precise timing. It doesn't see anything a camera inside the sphere couldn't see.
This is about exploring quantum entanglement. When lasers were invented, nobody knew what to do with them. Everybody thought "Death ray!" which was pretty silly in retrospect; that's a minor application. Then, bit by bit, they found thousands of ways to apply them that revolutionized all sorts of practical devices and allowed entirely new ones.
Developing this would be breaking old rules about what is and isn't possible, and though it's hard to guess exactly what it's good for, you can bet it'll be good for some amazing new technologies.
All the execs would rather lay off people than cut their [own] salaries.
Well, of course! When was the last time you took a pay cut for someone else's job?
Perhaps this is incompetence on the part of the owners, but it's not management incompetence to take as high a salary as you are allowed. You just don't turn down money from the boss. Your work and everything under you is your problem, the expense of your salary and everything above you is your superiors' problem.
very few ideas, if any, spring from the mind of one individual. In reality all high-tech ideas leverage the ideas of many who never get attribution. That's just a fact.
Yeah, that's the point of patents: to make sure good ideas get spread around and seed more good ideas, instead of being hidden and exploited to lesser profit in secret; it's also a major ideological objection to granting monopoly power to any one entity. It cuts both ways.
Are you sure you know which side you're arguing?
...why can you choose between "each do |i| ... end" and "each{|i| ... }" ...
I love Ruby, especially for the arbitrary-sized integers by default (this might seem like a minor feature, but I deal with exact numbers over a few billion so often that I hate to fumble with extensions and libraries for it), but one thing that confuses me is the block structure. Why "end"?
... end" or "{||...}" not more general?
... end" and "for {|| ... }", but not between "def func(n) ... end" and "def func {|n| ... }" ?
Why are static conditional and loop blocks, and function and class definitions, so different from the brace type of general blocks, and so different-looking from Perl? And why is the option of "do ||
For example (and please correct me if my assumption is wrong), why can you choose between "for do ||
For some reason, Nintendo sold millions of consoles to people who don't like video games.
Note that it has not yet actually sold one million GameCubes.
Note also that you have a very weak grasp on the difference between hard facts and vague marketing hype.
His argument is basically - Wellllll, the Playstation sold the most console ever sooooo that means the Gamecube will be the worst system ever.
Actually, it's more like, GameCube is a less powerful system, with few games, with less developer support, which doesn't play DVDs, didn't actually have strong opening sales, is aimed primarily at small children but with inappropriately fragile media, and is trying to enter a market which is already deliriously in love with it's competition.
Everyone who likes video games wants the PS2, and will buy the PS2 in preference to anything else. GameCube is relegated second system status in a market where few buy a second system, and then it's most commonly to correct their mistake of overenthusiastically picking up the less popular system (he backs this point up with hard numbers).
The point that it would take a couple of years for Nintendo to sell as many GameCubes as there are PS2s out there is a bit of an aside, an explanation of why the developer support is weak, since the GameCube market is going to be miniscule compared to the PS2 market for some time.
But the way he says it is entertaining.
The Gord's Prophesy of the GameCube
Love the Gord. Fear the Gord.
The computer is the favorite "busy toy" of someone who doesn't really want to work at work. That, combined with the efficiency gains, has lead to a lot of people doing a lot of nothing aside from maintaining the appearance that they shouldn't be fired. The pointless meanings, aimless memos, unnecessary and ineffective initiatives, etc. Thus the gains of computers are deliberately concealed.
The second of the problem is computers being untrusted and used as a parallel system. There is no such thing as a paperless office. Paper records are kept parallel to computer records, sometimes requiring all of the old work, and all of the computer work. This is more often an apparent problem than a real one, as it moves a smaller amount of administrative work to an earlier time. While it's less efficient than it could be, it's better than not using computers.
The third part, aside from being a problem in itself, is half a cause and half an effect of the second; they grew up intertwined. As home computer systems were adapted to office use, and the first generation of programmers raised with computers from a young age appeared, reliability was sacrificed in favor of attractiveness, apparent ease of learning, and flashy feature checklists. Software is replaced every few years, and old data is lost or damaged. Many users stopped considering computers infallable and started considering them unreliable, dramatically limiting their use.
This last one is indisputably a real, serious problem in software design. Software is rushed to market, then thrown away just as the bugs are worked out. But this is more directly a problem of poor software purchasing; the market demands features, useful or not, and the software industry can only comply to that demand, or be unprofitable and unappreciated.
If you want to be able to use it directly for real general-purpose programming, in the existing environment, it has to interface to any C library. That's a long way above and beyond Turing completeness.
This changes it from a "closed" language, with fully-specified behavior, complete within itself, to an open language which may be extended to arbitrary behavior with external modules, so it's not really a small language at all, just a small interface to a huge language. It either needs to be a compiled language, or to have compiled modules.
On the other hand, if you are willing to allow an environment designed as needed, to access all needed functionality in the form of one input and one output line, it returns to the sort of task a Turing machine can do.