I don't see how this relates to my comment. I have my vfat partition(s) mount on boot, but they are mounted in such a way as to only allow root to edit them - and only members of a certain group can read them.
Let me try:
1) While running Windows you get the initial infection. The virus modifies files in the (wide open) linux partition. Windows virus-detection software (that has not been primed for this virus) is not alerted.
The virus can modify any files on the Linux partition, add more, and change permissions.
2) When you boot into Linux a lot of programs are run as root, and many others that are setuid root will be run from time to time after booting. One of those programs was infected by the virus when it was running as windows.
Alternatively the virus could have:
- Added a new setuid file and a cron job to run it.
- Added a new file and a boot-time script to run it.
- Modified any common utility and made it setuid root (so it has the necessary permissions when you run it yourself later.) I could go on.
Now that an infected program is running as root, it can do what it wants to the Windows partition - infect anything, kill or modify the anti-virus programs (including modifying it so it SPREADS the virus), install new software, etc. No Windows virus checking is running and a unix root program can do anything. So now it's the Windows partition's turn to be wide open.
With both partitions infected your machine is a hazard to itself and the rest of the net regardless of which system you are running.
Yeah, right. You'd do the same thing I would do if I had a such a business model: post it to Slashdot the next time we're all ranting about how stupid the music industry is.
I'm more the tech than business type. Yet I've already refrained from posting a few (pending patent applications or business presentations).
Chances are anyone who would actually implement such a business model wouldn't advertise the fact that they don't have one!
You missed the point. I'm not saying anything about whether I have one or not. I'm saying that IF I had one THAT lucrative I'd develop it myself or SELL it to someone who would. I wouldn't give it to the established monopoly, with which it could compete, for free. B-)
Is it simply a collection of stories of people who succeeded and those who didn't. Or does she provide some kind of analysis and state what she thinks were the important reasons for success?
... if it's just a collection of stories, then why should I buy this book?
So you can get a few raw facts and draw your OWN conclusions about what works and what doesn't?
... one thing that Sun must still address is how to increase their adoption in the corporate sector.
Sun says that's why they're charging for Star Office in the first place (rather than just open-sourcing it). They want to achieve penetration in businesses that are used to paying through the nose for tools such as Microsoft Office and think free software means amateur crudware.
They should give William Shatner a beta model out of pure respect..
If I recall the Trek backstory correctly, Spock's mother (a human woman) was the inventor of the universal translator. (And saved the show - no more needing to find planets where convergent evolution led to English-speaking neo-Romans.)
So say i'm using a digital camcorder in the mall and britney's new single starts playing from the loud-speakers does my camcorder shut down because it detects the watermark?
Imagine the effect on police "wires" if crooks take to playing watermarked music in the background.
Heck: I bet there'd be a big market for "watermarked silence" recordings just for making bugging more difficult.
Hmm, a lot of telephone equipment does analog-to-digital and vice-versa conversions. Looks like the baby bells are all in big trouble now! Hahaha.
They'll just get an exception.
Of course the exception won't cover the converters in your computer's sound card or any add-on VoIP adapters you could use as the hardware component of a network telephone. So your alternative to their service will cost more, and will flake out if someone is playing a watermarked recording or radio program in the background.
Re:You misrepresent the phrase.
on
Fair IP Laws?
·
· Score: 2
I'll come back with counter-arguments on your points, though I don't disagree with them completely.
If you disagree with the notion that granting a monopoly to an inventor (of software or anything else) does not promote progress, then your disagreement is not with me. You disagree with the framers of the Constitition and have a problem with the concept of patents in general.
Not at all. But I claim that patents, like many interventions (legal or medical), have both good and bad effects. The trick is to find a formulation and dosage where the good effects dominate, and avoid situations where the harm is worse than the help.
For the tech common in the founder's time (manufacturing processes, chemical formulations, agriculture, milling, etc.) a patent of 10-20 years duration appears to hit the peak of the benefit-cost vs time curve. And for those industries even today, and many more, the same still seems to hold true. Perhaps the peak has moved in a bit, but not much.
But software is another can of worms. With its rapid time scale - faster than the patenting process itself - a patent's retarding and anti-competitive effects are greatly magnified, pulling in the time of the cost-benefit peak and lowering the curve. It seems likely that for ANY length of patent the costs will outweigh the benefits.
Fortunately, the built-in incentive structure of the software market provides more than adequate incentive for innovation without software patents, rendering them unnecessary.
You are flat-out WRONG in saying that patents are granted to the first to disclose, not the frst to invent. In fact, the complete opposite is true. In the US, unlike the rest of the world, only the person who first invented is entitled to a patent, regardless of who disclosed it first or who filed a patent application first.
Tell that to the guy Alexandar Grahm Bell beat to the patent office by half an hour.
In theory the patent goes to the first to invent. In practice patent office trusts the application time as a proof of precedence and lets the courts settle any claims of prior invention. The courts aren't very sympathetic to somebody who didn't move on their own patent (with its associated disclosure and clock-starting on free use). Courts also limit their intervention as much as possible. So the result is if you were already USING your prior art, the patent holder loses his coverage on THAT ASPECT of his patent. But you don't get the patent, and the rest of the patent is still in force.
Net result is that first to the office wins, and a prior inventor who was second to the office (or didn't go) gets crumbs.
(I'm pressed for time so I'll skip the other two points. I partially disagree with your third and nearly agree with your last - especially about the incentive structure for the USPTO.)
You have a 4-digit UID and still you stooped that low to gain karma.
I can't gain karma. Even with the point I lost for that posting I still have a lot more than the cap (accumulated before the cap went on.)
I made that follow up for two reasons:
- To provide a link in my user page so I could find the thread conveniently.
- So people who think my postings are often interesting or informative would be more likely to read it than the posting of some random Anonymous Coward.
Now I don't KNOW that there are such people. But leaving the signpost helps them if they do exist, and isn't a big load on the rest of the readers if they don't.
You misrepresent the phrase.
on
Fair IP Laws?
·
· Score: 2
How does software programming not "promote the progress of science and useful arts"?
The question is not whether programming promotes the progress of science and useful arts, but whether giving the first guy to publish a technique a MONOPOLY on it for YEARS promotes, or retards, progress.
How is a programmer not an "author and inventor"? How is novel, useful and nonobvious software not a "writing and discovery"?
Of course they are. That's not the issue
and, why should software programmers be treated differently and not be entitled to "exclusife rights"?
Because the limited-time exclusive rights of patent are granted (and enforced on the rest of us by people with guns) in order to encourage inventors to publish their techniques, rather than keeping them a secret.
Intellectual property "rights" are not RIGHTS. They are PRIVILEGES. They are created and doled out by governments in order to obtain something of value for their citizens and their economies.
In the absense of patent protection an inventor of, say, a new manufacturing process might chose to keep it a trade secret rather than enabling his competition by publishing it. So the public gets only that one artisan's output, and the secret may become lost when he dies. Giving him a limited-time lock on the use of the process lets him license it to others for a fee, making him richer, getting more, cheaper goods into the hands of the consumer, and making the technique free and public once the patent expires.
This situation does NOT apply to software.
Once commercial software has been sold the easily-backed-up code is available for archiving and the technique it embodies is susceptable to reverse-engineering. So the invention won't be lost with the inventor's death.
Even if a software developer keeps the software itself secret and just sells its services, the fact that the service CAN be done (and is profitable) will likely cause its re-invention, by someone else who will not hold the algorithm so closely. (Remember: Patent is granted to the first to DISCLOSE, not the first to INVENT.) And if no one else reinvents the technique, the death of the software AUTHOR doesn't mean the loss of the SERVICE.
Software development lead times (including reverse-engineered cloning) are long enough and payoff times are short enough that there is no need to provide long-term protection to encourage authors to publish their products. You DO need protection against verbatim copies ("piracy"). But a short-term software COPYRIGHT is adequate for that purpose.
There was a robust software industry before software patents, and while even software copyrights were in doubt. This provides a proof-of-concept. Both patent and stretched-into-super-patent copyright are much more likely to RETARD, rather than PROMOTE, advance in the software-based "useful arts". So the Constitution does not autorize the granting of such such Intellectual Property privileges to software authors. ORDINARY copyright on the source code is adequate protection to "encourage" software development by providing a tool to discourage outright piracy. Nothing further is needed, desirable, or Constitutional.
The original MBONE's routing architecture wasn't scalable. More sophisticated routing schemes have been devised fairly recently but to my knowledge there are next to no ISPs that offer multicast connectivity to consumers.
And given that corporate mergers are resulting in a significant fraction of the ISPs being owned by content provider megacorps, don't expect them to be in any rush to deploy them, or to make the input accessable to end users (rather than just the media corps) if they ARE deployed.
There's probably more money to be made by the megacorps by promoting mom-and-pop "internet radio" than by blocking it. But until the media decision makers have an epiphany the dogs will likely remain in the manger.
They have invented, among MANY other things... "the transistor, the laser and wireless technologies."
But remember that Bell Labs is an institution, not an individual. It is composed of MANY scientists. It is not impossible that the barrel has acquired a bad apple. The trick is to find the bad apples and pull them out before they spoil the barrel.
Of course it COULD be that the research in question wasn't faked, with the anomolies coming from a clerical error, a jackpot, or a previously-undiscovered bit of physics. That's why they're INVESTIGATING, rather than just recalling the papers and canning those connected with 'em.
... about Dvorak vs. Qwerty, but have no idea if they're true:
- Dvorak is significantly better than Qwerty. But there are a number of other "improved" keyboards that are about the same amount better than Qwerty. So if you're an executive looking into paying to retrain, you look into the merits and find there is no clear choice.
(We hear a lot about Dvorak because it's the one that gets better press, and has some support in the computer community, more for historical reasons than its merits relative to other improved keyboard layouts. That, combined with the relative ease of remapping a computer keyboard {compared to a mechanical typewriter} might get it over this hump. A trivial graphic config tool in Gnome and Kde would give it a BIG push.)
- Qwerty wasn't deliberately designed to be slow. It was just the first layout that was built by that group of engineers. The deficiencies were quickly discoverd and they came up with a better layout. And management nixed it because of the retraining costs - the first such decision.
At the time there were less than ten trained typists.
you really should try and get a couple of VoIP blasters, they coupled with fobbit or fobbit+openH232 make a very viable VOIP solution that is invisible and completely operated from the $35.00 analog telephone plugged into it.
I thought VoIP Blaster had been discontinued by the manufacturer. Have they changed their minds?
The std says B::f() is considered only if C::f() does not exists. (== C::f() is alias of B::f())
I read the snippet you posted to mean that C::C() had the option of calling B::f() or C::f(), and got off on a rap on THAT being broken in my second post. I will be more than happy to stand corrected on that issue. What you describe is what I WANT the standard to say for that case.
But my real gripe is this:
class A *aPrtToA;
class X { X(); ~X() };
class A { A(); virtual void f(); };
class B : public A { B(); virtual void f(); };
class C : public B { X anX; C(); virtual void f(); };
A::A() { aPtrToA = this; }
X::X() { aPtrToA->f(); }// C::f() or B::f()?
X::~X() { aPtrToA->f(); }// C::f() or B::f()?
I claim the standard should require that when anX is constructed or destructed B::f() is called. As I recall the "final" version of the standard it essentially said "don't do that, the behavior is undefined".
I don't know what current production compilers do. But when I looked at the stuff current about 10 years ago:
- Some would do C::f() and B::f()
- Some would do B::f() and C::f()
- Some would do C::f() and C::f()
- None would do B::f() and B::f() (IMO the "correct" thing to do).
When a virtual function is called directly or indirectly from a constructor (including from the mem-initializer for a data member) or from a destructor, and the object to which the call applies is the object under construction or destruction, the function called is the one defined in the constructor or destructor's own class or in one of its bases,
In other words:
When a virtual function is called from the constructor of the derived class it MAY get the behavior of its own class or it MAY get the behavior of the base class.
Which is even more broken than I described.
I claim the standard SHOULD say that a constructor or destructor MUST get the version of the virtual function that is a member of ITS OWN class - the class of which this constructor or destructor is a part. It gets a BASE class virtual function if and only if there is no overriding definition in this class.
(A constructor / destructor and a virtual member function OF THE SAME CLASS can interact through a member variable so the member function can selectively delegate to its base class version if necessary. A constructor/destructor can NOT interact with the BASE CLASS version of the member function to promote its behavior.)
On the other hand, when the virtual function is called from the mem-initializer for a member object, I claim the standard SHOULD require that it MUST get the behavior of the BASE class version of the member function. More importantly, I claim that the constructors and destructors of MEMBER OBJECTS of the derived class should also invoke the BASE class' version of the virtual member function.
(A derived-class virtual member function will typically depend on member state that has not been fully initialized. And it can not even defer to the base-class version because it can't trust the state of any member variable to flag the necessity.)
Of course the standard is correct in saying that it should NOT get the behavior of a further-derived class of which the class containing the constructor, destructor, mem-initializer, or member object is a base.
Congratulations to the Edison Design Group. An awesome job.
It's too bad that the standard itself is broken...
In case you're interested: The issue is a deceptively fine point in constructor/destructor semantics. The current standard allows behavior that massively breaks a bunch of stuff you'd have been able to do if it had required behavior that conformed with the rest of the philosophy of the language. It is this:
You have a class base class with,
a virtual member function and,
a constructor that,
exports a copy of the pointer to the instance under construction (which is stored externally), and
a derived class with,
a member variable of a class-with-construction type, and
an overriding of the virtual function, and
the constructor of the derived class's member variable (or something it calls, or some other member-variable initialization) gets hold of the pointer and,
calls the virtual member function. Does it get the base class version, derived class version, or go wonky?
Similarly during DEstruction of the member variables (i.e. after the derived class destructor but before the base class destructor).
My claim is that the standard SHOULD explicitly specify the behavior as follows:
The result of a virtual member function call is defined from the execution of the first line of any constructor of the class through the execution of the last line of the destructor, at the most-baseward class where the virtual member function has a defined behavior (unless a more derived class overrides the function to again be pure virtual, and this is allowed).
The result of a virtual member function call to a virtual member function that is overridden in a derived class is the derived class behavior if the function is called during or after the execution of the first line of any constructor and before or during the execution of the last line of the destructor (unless a more derived class overrides the function again), the base class behavior if called before the first line of a derived class constructor or after the last line of the derived class destructor.
In other words: Member variable constructors/destructors (and everything else executing at that time) "see" the base class.
Instead we have this: With respect to calling virtual member functions during construction the early language definition and first ANSI standard said the behavior was undefined. The "final" standard essentially says "don't do that". I'm not sure what current compilers do. But when I checked about ten years ago, of the four binary combinations of whether constructors and destructors got it "right" or "wrong":
cfront (and cfront-derived compilers at Sun and SGI) got it "wrong" one way.
three compilers for PCs got it "wrong" a second way.
g++ got it "wrong" the third way.
Now the semantics I've described are very powerful and create a consistent object model.
Up to the beginning of the user-written code of the constructor through the end of the user-written code of the destructor the instance is a collection of components - base classes, member variables - which have their own internally-consistent behaviors. It is wrong to execute the derived-class member function, because the derived class instance doesn't exist yet. But it is right to execute the base-class member function, because the base class DOES exist and IS initialized.
After the execution of the constructor and before the execution of the destructor the derived-class instance is a fully-constructed and initialized member of the derived class. It might later be hammered into a new shape by serving as a component of a more-derived class, but for now it's consistent.
During the constructors the components are pulled together into a whole, and during the destructor they're disassembled into their components. But the constructors and destructor are aware of the state of the assembly, and can use care not to let a derived-class virtual member function be executed until everything it depends on is ready, or co-operate with it by passing it flags to inform it of construction progress.
I won't go into all the things this enables. But I will note that it would make C++ more consistent and more powerful for object-oriented programming than other contenders, which also do this "wrong". (For instance: Smalltalk has the derived-class ("subclass") behavior during the base-class ("superclass") construction. This risks breaking the consistency of already-debugged construction code whenever a method is overridden and requiring those coding to constantly recheck code outside their new class' modularity boundary.)
Since the behavior I want is a legal option within the standard, perhaps the Edison Design Group might be willing to give me a compiler switch or pragma ("object_construction_semantics"?) to cause their compiler to generate it?
... warnings of demons and death... that you know from Indiana Jones actually were warnings about nuclear radiation.
(Funny you should mention that character. Did YOU have the same take I did ("fission chain reaction!") to the scene in Temple of Doom where the artifacts are brought close together and they start glowing?)
Egyptian jewelry and pottery from those graves have adorned houses and women everywhere...
Some radioactive gold (used as needles for cancer therapy but later replaced with some other isotope) once got stolen and dumped into the jewelry market. For a while there were necklaces that caused sores and scars and wedding rings that made fingers fall off. A medical cobalt-60 source got into the scrap metal market too, down in Mexico...
But on to the main point of this post...
Imagine for a moment that the ancient Egyptians used nuclear energy four thousand years ago, and that all knowledge of it was lost in the following upheavals.
Now imagine that the pyramids were nuclear waste disposal sites...
Back in the late '60s or so - about the time of the "pyramid power" craze and the beginning of public concern over disposal of waste from nuclear power plants - I did a rap on the subject. Alternatively titled "Nuclear Reactors of the Gods" or "Pyramid Nuclear Power", it was a mostly-tongue-in-cheek thing that pulled together a number of threads:
Plutonium's 24,000+ year half-life ("If you had buried a thousand pounds of plutonium [in small pieces!] under the pyramid of Cheops during its construction there'd still be [most of it] pounds left.")
Anomolous results from attempts to locate rooms in a large pyramid by cosmic-ray ocultation.
The discovery of a large deposit of depleted uranium in western Africa. (This had been explained by geologists as the ash of a natural water-moderated reactor that formed in river-delta sediment and ran at a few hundred watts for centuries, but for the rap I proposed tailings from ore enrichment.)
The discovery of dry-cell batteries (carbon rod / caustic paste / metal can / asphaltam seal in pottery urn, explained as probably being used for electroplating) in an early Egyptian dig, combined with the observation that modern civilization went from the carbon/zinc dry cell to nuclear bombs and power reactors in under two hundred years, while Egyptian civilization stood for several THOUSAND. ("So why didn't THEY get to nuclear reactors. Well, what if they did?")
A speculation about Egyptian scientific naming conventions being analogies with a conceptually-related myth. (After all, WE did this before we got into acronyms, especially when naming the radioactives. Consider: Uranium, Plutonium, Thorium,...)
There was a lot more. But this gets us to the hunt for waste disposal sites.
How do you get rid of the waste? How about hauling it out into the desert and piling rocks on top of it? But it will be dangerous for hundreds of thousands of years. How do you mark it to keep your distant descendants out of trouble?
"Here lies the-one-like-unto-the-sun-god (Tut-Ankh-Amon). Do not enter here and do not take the relics. If you do you will get SO sick. You will puke for days, your hair will fall out, your skin will fall off. If you survive that you will likely die of painful lumps, become impotent or nearly so, and if you manage to have descendants that aren't stillborn their line will be cursed by deformities for generations."
(At one point I thought of doing a psudonymous nut-cult-style book on the subject, with the bulk of the evidence of the former civilizations destroyed in a thermonuclear exchange between Atlantis and Mu, and the Egyptian fraction of civilization's technical base being lost under the Sahara - which is a very recent desert. I probably could have brought in the stories of the flood and maybe the plagues of Egypt. But that's beyond the scope of this post.)
But why doesn't someone do this deliberately? That is, create a domain for the sole purpose of receiving spam only, and automating a banned email list to other servers.
[Details on how to set up the TRAP deleted.]
That answers the first part of the question...
But how about the second part? Is there an existing tool to automate the conversion of the collected spam-trap mail into denials of future mail deliveries (and perhaps also to purging of still-enqueued letters to real addresses earlier in their mailing list order)?
Better yet: It could also modify the behavior of the SMTP server so it spawns a (limited nubmer of) "sticky TCP connection" child process to hang the spammer's bulk-mailing tool. Deploy a bunch of these puppies around the net and spamming becomes impractical once the spammer's mailing list has acquired a few addresses on spam-trapping sites.
If brightly coloured spandex clothes ever become commonplace I'm quitting this planet...
If I could have the body that goes with them - movie-star appearance, no (or greatly slowed) aging (and reversion to prime-of-life apparent age), improved stamina, mind that stays sharp under stress, exhaustion, and injury, rapid healing (including from repeated beating-to-unconsciousness) - bring 'em on!
I won't even insist they be bulletproof and have anti-gravity, supercomputer w/comm, vacuum & radiation shielding, air recycling, and warp drive.
Slashdot Mirror
I don't see how this relates to my comment. I have my vfat partition(s) mount on boot, but they are mounted in such a way as to only allow root to edit them - and only members of a certain group can read them.
Let me try:
1) While running Windows you get the initial infection. The virus modifies files in the (wide open) linux partition. Windows virus-detection software (that has not been primed for this virus) is not alerted.
The virus can modify any files on the Linux partition, add more, and change permissions.
2) When you boot into Linux a lot of programs are run as root, and many others that are setuid root will be run from time to time after booting. One of those programs was infected by the virus when it was running as windows.
Alternatively the virus could have:
- Added a new setuid file and a cron job to run it.
- Added a new file and a boot-time script to run it.
- Modified any common utility and made it setuid root (so it has the necessary permissions when you run it yourself later.)
I could go on.
Now that an infected program is running as root, it can do what it wants to the Windows partition - infect anything, kill or modify the anti-virus programs (including modifying it so it SPREADS the virus), install new software, etc. No Windows virus checking is running and a unix root program can do anything. So now it's the Windows partition's turn to be wide open.
With both partitions infected your machine is a hazard to itself and the rest of the net regardless of which system you are running.
Yeah, right. You'd do the same thing I would do if I had a such a business model: post it to Slashdot the next time we're all ranting about how stupid the music industry is.
I'm more the tech than business type. Yet I've already refrained from posting a few (pending patent applications or business presentations).
Chances are anyone who would actually implement such a business model wouldn't advertise the fact that they don't have one!
You missed the point. I'm not saying anything about whether I have one or not. I'm saying that IF I had one THAT lucrative I'd develop it myself or SELL it to someone who would. I wouldn't give it to the established monopoly, with which it could compete, for free. B-)
Is it simply a collection of stories of people who succeeded and those who didn't. Or does she provide some kind of analysis and state what she thinks were the important reasons for success?
... if it's just a collection of stories, then why should I buy this book?
So you can get a few raw facts and draw your OWN conclusions about what works and what doesn't?
... one thing that Sun must still address is how to increase their adoption in the corporate sector.
Sun says that's why they're charging for Star Office in the first place (rather than just open-sourcing it). They want to achieve penetration in businesses that are used to paying through the nose for tools such as Microsoft Office and think free software means amateur crudware.
You have a new business model that would equal their current revenue streams?
If I had a new business model that would equal their current revenue streams I'd probably be out looking for venture capital right now.
But in any case I certainly wouldn't give it to them for free.
They should give William Shatner a beta model out of pure respect..
If I recall the Trek backstory correctly, Spock's mother (a human woman) was the inventor of the universal translator. (And saved the show - no more needing to find planets where convergent evolution led to English-speaking neo-Romans.)
So give a copy to Nimoy as his inheritance. B-)
So say i'm using a digital camcorder in the mall and britney's new single starts playing from the loud-speakers does my camcorder shut down because it detects the watermark?
Imagine the effect on police "wires" if crooks take to playing watermarked music in the background.
Heck: I bet there'd be a big market for "watermarked silence" recordings just for making bugging more difficult.
Hmm, a lot of telephone equipment does analog-to-digital and vice-versa conversions. Looks like the baby bells are all in big trouble now! Hahaha.
They'll just get an exception.
Of course the exception won't cover the converters in your computer's sound card or any add-on VoIP adapters you could use as the hardware component of a network telephone. So your alternative to their service will cost more, and will flake out if someone is playing a watermarked recording or radio program in the background.
I'll come back with counter-arguments on your points, though I don't disagree with them completely.
If you disagree with the notion that granting a monopoly to an inventor (of software or anything else) does not promote progress, then your disagreement is not with me. You disagree with the framers of the Constitition and have a problem with the concept of patents in general.
Not at all. But I claim that patents, like many interventions (legal or medical), have both good and bad effects. The trick is to find a formulation and dosage where the good effects dominate, and avoid situations where the harm is worse than the help.
For the tech common in the founder's time (manufacturing processes, chemical formulations, agriculture, milling, etc.) a patent of 10-20 years duration appears to hit the peak of the benefit-cost vs time curve. And for those industries even today, and many more, the same still seems to hold true. Perhaps the peak has moved in a bit, but not much.
But software is another can of worms. With its rapid time scale - faster than the patenting process itself - a patent's retarding and anti-competitive effects are greatly magnified, pulling in the time of the cost-benefit peak and lowering the curve. It seems likely that for ANY length of patent the costs will outweigh the benefits.
Fortunately, the built-in incentive structure of the software market provides more than adequate incentive for innovation without software patents, rendering them unnecessary.
You are flat-out WRONG in saying that patents are granted to the first to disclose, not the frst to invent. In fact, the complete opposite is true. In the US, unlike the rest of the world, only the person who first invented is entitled to a patent, regardless of who disclosed it first or who filed a patent application first.
Tell that to the guy Alexandar Grahm Bell beat to the patent office by half an hour.
In theory the patent goes to the first to invent. In practice patent office trusts the application time as a proof of precedence and lets the courts settle any claims of prior invention. The courts aren't very sympathetic to somebody who didn't move on their own patent (with its associated disclosure and clock-starting on free use). Courts also limit their intervention as much as possible. So the result is if you were already USING your prior art, the patent holder loses his coverage on THAT ASPECT of his patent. But you don't get the patent, and the rest of the patent is still in force.
Net result is that first to the office wins, and a prior inventor who was second to the office (or didn't go) gets crumbs.
(I'm pressed for time so I'll skip the other two points. I partially disagree with your third and nearly agree with your last - especially about the incentive structure for the USPTO.)
You have a 4-digit UID and still you stooped that low to gain karma.
I can't gain karma. Even with the point I lost for that posting I still have a lot more than the cap (accumulated before the cap went on.)
I made that follow up for two reasons:
- To provide a link in my user page so I could find the thread conveniently.
- So people who think my postings are often interesting or informative would be more likely to read it than the posting of some random Anonymous Coward.
Now I don't KNOW that there are such people. But leaving the signpost helps them if they do exist, and isn't a big load on the rest of the readers if they don't.
The question is not whether programming promotes the progress of science and useful arts, but whether giving the first guy to publish a technique a MONOPOLY on it for YEARS promotes, or retards, progress.
How is a programmer not an "author and inventor"? How is novel, useful and nonobvious software not a "writing and discovery"?
Of course they are. That's not the issue
and, why should software programmers be treated differently and not be entitled to "exclusife rights"?
Because the limited-time exclusive rights of patent are granted (and enforced on the rest of us by people with guns) in order to encourage inventors to publish their techniques, rather than keeping them a secret.
Intellectual property "rights" are not RIGHTS. They are PRIVILEGES. They are created and doled out by governments in order to obtain something of value for their citizens and their economies.
In the absense of patent protection an inventor of, say, a new manufacturing process might chose to keep it a trade secret rather than enabling his competition by publishing it. So the public gets only that one artisan's output, and the secret may become lost when he dies. Giving him a limited-time lock on the use of the process lets him license it to others for a fee, making him richer, getting more, cheaper goods into the hands of the consumer, and making the technique free and public once the patent expires.
This situation does NOT apply to software.
Once commercial software has been sold the easily-backed-up code is available for archiving and the technique it embodies is susceptable to reverse-engineering. So the invention won't be lost with the inventor's death.
Even if a software developer keeps the software itself secret and just sells its services, the fact that the service CAN be done (and is profitable) will likely cause its re-invention, by someone else who will not hold the algorithm so closely. (Remember: Patent is granted to the first to DISCLOSE, not the first to INVENT.) And if no one else reinvents the technique, the death of the software AUTHOR doesn't mean the loss of the SERVICE.
Software development lead times (including reverse-engineered cloning) are long enough and payoff times are short enough that there is no need to provide long-term protection to encourage authors to publish their products. You DO need protection against verbatim copies ("piracy"). But a short-term software COPYRIGHT is adequate for that purpose.
There was a robust software industry before software patents, and while even software copyrights were in doubt. This provides a proof-of-concept. Both patent and stretched-into-super-patent copyright are much more likely to RETARD, rather than PROMOTE, advance in the software-based "useful arts". So the Constitution does not autorize the granting of such such Intellectual Property privileges to software authors. ORDINARY copyright on the source code is adequate protection to "encourage" software development by providing a tool to discourage outright piracy. Nothing further is needed, desirable, or Constitutional.
No software patents.
No business model patents.
No patents on "doing the same thing with a computer that used to be done by hand".
Copyright term reduced back to 17 + 17 years.
Law changes extending copyright do not apply to works already published when the extension is passed.
Copyright covers software CODE but not appearance, behavior, or functionality.
Copying interface definitions (i.e. ".h files") to interoperate with copyrighted software is explicitly "fair use".
The original MBONE's routing architecture wasn't scalable. More sophisticated routing schemes have been devised fairly recently but to my knowledge there are next to no ISPs that offer multicast connectivity to consumers.
And given that corporate mergers are resulting in a significant fraction of the ISPs being owned by content provider megacorps, don't expect them to be in any rush to deploy them, or to make the input accessable to end users (rather than just the media corps) if they ARE deployed.
There's probably more money to be made by the megacorps by promoting mom-and-pop "internet radio" than by blocking it. But until the media decision makers have an epiphany the dogs will likely remain in the manger.
They have invented, among MANY other things... "the transistor, the laser and wireless technologies."
But remember that Bell Labs is an institution, not an individual. It is composed of MANY scientists. It is not impossible that the barrel has acquired a bad apple. The trick is to find the bad apples and pull them out before they spoil the barrel.
Of course it COULD be that the research in question wasn't faked, with the anomolies coming from a clerical error, a jackpot, or a previously-undiscovered bit of physics. That's why they're INVESTIGATING, rather than just recalling the papers and canning those connected with 'em.
Above post was me - Ungrounded Lightning (Rod). For some reason slashdot is losing track of my login today.
... about Dvorak vs. Qwerty, but have no idea if they're true:
- Dvorak is significantly better than Qwerty. But there are a number of other "improved" keyboards that are about the same amount better than Qwerty. So if you're an executive looking into paying to retrain, you look into the merits and find there is no clear choice.
(We hear a lot about Dvorak because it's the one that gets better press, and has some support in the computer community, more for historical reasons than its merits relative to other improved keyboard layouts. That, combined with the relative ease of remapping a computer keyboard {compared to a mechanical typewriter} might get it over this hump. A trivial graphic config tool in Gnome and Kde would give it a BIG push.)
- Qwerty wasn't deliberately designed to be slow. It was just the first layout that was built by that group of engineers. The deficiencies were quickly discoverd and they came up with a better layout. And management nixed it because of the retraining costs - the first such decision.
At the time there were less than ten trained typists.
you really should try and get a couple of VoIP blasters, they coupled with fobbit or fobbit+openH232 make a very viable VOIP solution that is invisible and completely operated from the $35.00 analog telephone plugged into it.
I thought VoIP Blaster had been discontinued by the manufacturer. Have they changed their minds?
Apple knows [apple.com]. You have three non-pull-apart options.
[options deleted]
Well, let's see...
The crud they put on the disk locks up the Apple when you try to play it. Thus...
This is "technology" that "effectively prevents" unauthorized copying.
Breaking your computer is part of the correct operation of this technology, so
Fixing your computer is "circumvention" of "technology" that "effectively prevents" unauthorized copying, a felony under the DMCA, and
Apple's post telling you how to fix your computer is "trafficing" in circumvention technology, also a felony.
Quick! Call the FBI! (And ask Adobe for the phone number of the appropriate person to call. B-) )
I read the snippet you posted to mean that C::C() had the option of calling B::f() or C::f(), and got off on a rap on THAT being broken in my second post. I will be more than happy to stand corrected on that issue. What you describe is what I WANT the standard to say for that case.
But my real gripe is this:I claim the standard should require that when anX is constructed or destructed B::f() is called. As I recall the "final" version of the standard it essentially said "don't do that, the behavior is undefined".
I don't know what current production compilers do. But when I looked at the stuff current about 10 years ago:
- Some would do C::f() and B::f()
- Some would do B::f() and C::f()
- Some would do C::f() and C::f()
- None would do B::f() and B::f() (IMO the "correct" thing to do).
When a virtual function is called directly or indirectly from a constructor (including from the mem-initializer for a data member) or from a destructor, and the object to which the call applies is the object under construction or destruction, the function called is the one defined in the constructor or destructor's own class or in one of its bases,
In other words:
When a virtual function is called from the constructor of the derived class it MAY get the behavior of its own class or it MAY get the behavior of the base class.
Which is even more broken than I described.
I claim the standard SHOULD say that a constructor or destructor MUST get the version of the virtual function that is a member of ITS OWN class - the class of which this constructor or destructor is a part. It gets a BASE class virtual function if and only if there is no overriding definition in this class.
(A constructor / destructor and a virtual member function OF THE SAME CLASS can interact through a member variable so the member function can selectively delegate to its base class version if necessary. A constructor/destructor can NOT interact with the BASE CLASS version of the member function to promote its behavior.)
On the other hand, when the virtual function is called from the mem-initializer for a member object, I claim the standard SHOULD require that it MUST get the behavior of the BASE class version of the member function. More importantly, I claim that the constructors and destructors of MEMBER OBJECTS of the derived class should also invoke the BASE class' version of the virtual member function.
(A derived-class virtual member function will typically depend on member state that has not been fully initialized. And it can not even defer to the base-class version because it can't trust the state of any member variable to flag the necessity.)
Of course the standard is correct in saying that it should NOT get the behavior of a further-derived class of which the class containing the constructor, destructor, mem-initializer, or member object is a base.
It's too bad that the standard itself is broken...
In case you're interested: The issue is a deceptively fine point in constructor/destructor semantics. The current standard allows behavior that massively breaks a bunch of stuff you'd have been able to do if it had required behavior that conformed with the rest of the philosophy of the language. It is this:
You have a class base class with,
a virtual member function and,
a constructor that,
exports a copy of the pointer to the instance under construction (which is stored externally), and
a derived class with,
a member variable of a class-with-construction type, and
an overriding of the virtual function, and
the constructor of the derived class's member variable (or something it calls, or some other member-variable initialization) gets hold of the pointer and,
calls the virtual member function.
Does it get the base class version, derived class version, or go wonky?
Similarly during DEstruction of the member variables (i.e. after the derived class destructor but before the base class destructor).
My claim is that the standard SHOULD explicitly specify the behavior as follows:
The result of a virtual member function call is defined from the execution of the first line of any constructor of the class through the execution of the last line of the destructor, at the most-baseward class where the virtual member function has a defined behavior (unless a more derived class overrides the function to again be pure virtual, and this is allowed).
The result of a virtual member function call to a virtual member function that is overridden in a derived class is the derived class behavior if the function is called during or after the execution of the first line of any constructor and before or during the execution of the last line of the destructor (unless a more derived class overrides the function again), the base class behavior if called before the first line of a derived class constructor or after the last line of the derived class destructor.
In other words: Member variable constructors/destructors (and everything else executing at that time) "see" the base class.
Instead we have this: With respect to calling virtual member functions during construction the early language definition and first ANSI standard said the behavior was undefined. The "final" standard essentially says "don't do that". I'm not sure what current compilers do. But when I checked about ten years ago, of the four binary combinations of whether constructors and destructors got it "right" or "wrong":
cfront (and cfront-derived compilers at Sun and SGI) got it "wrong" one way.
three compilers for PCs got it "wrong" a second way.
g++ got it "wrong" the third way.
Now the semantics I've described are very powerful and create a consistent object model.
Up to the beginning of the user-written code of the constructor through the end of the user-written code of the destructor the instance is a collection of components - base classes, member variables - which have their own internally-consistent behaviors. It is wrong to execute the derived-class member function, because the derived class instance doesn't exist yet. But it is right to execute the base-class member function, because the base class DOES exist and IS initialized.
After the execution of the constructor and before the execution of the destructor the derived-class instance is a fully-constructed and initialized member of the derived class. It might later be hammered into a new shape by serving as a component of a more-derived class, but for now it's consistent.
During the constructors the components are pulled together into a whole, and during the destructor they're disassembled into their components. But the constructors and destructor are aware of the state of the assembly, and can use care not to let a derived-class virtual member function be executed until everything it depends on is ready, or co-operate with it by passing it flags to inform it of construction progress.
I won't go into all the things this enables. But I will note that it would make C++ more consistent and more powerful for object-oriented programming than other contenders, which also do this "wrong". (For instance: Smalltalk has the derived-class ("subclass") behavior during the base-class ("superclass") construction. This risks breaking the consistency of already-debugged construction code whenever a method is overridden and requiring those coding to constantly recheck code outside their new class' modularity boundary.)
Since the behavior I want is a legal option within the standard, perhaps the Edison Design Group might be willing to give me a compiler switch or pragma ("object_construction_semantics"?) to cause their compiler to generate it?
Pretty please?
(Funny you should mention that character. Did YOU have the same take I did ("fission chain reaction!") to the scene in Temple of Doom where the artifacts are brought close together and they start glowing?)
Egyptian jewelry and pottery from those graves have adorned houses and women everywhere...
Some radioactive gold (used as needles for cancer therapy but later replaced with some other isotope) once got stolen and dumped into the jewelry market. For a while there were necklaces that caused sores and scars and wedding rings that made fingers fall off. A medical cobalt-60 source got into the scrap metal market too, down in Mexico...
But on to the main point of this post...
Imagine for a moment that the ancient Egyptians used nuclear energy four thousand years ago, and that all knowledge of it was lost in the following upheavals.
Now imagine that the pyramids were nuclear waste disposal sites
Back in the late '60s or so - about the time of the "pyramid power" craze and the beginning of public concern over disposal of waste from nuclear power plants - I did a rap on the subject. Alternatively titled "Nuclear Reactors of the Gods" or "Pyramid Nuclear Power", it was a mostly-tongue-in-cheek thing that pulled together a number of threads:
Plutonium's 24,000+ year half-life ("If you had buried a thousand pounds of plutonium [in small pieces!] under the pyramid of Cheops during its construction there'd still be [most of it] pounds left.")
Anomolous results from attempts to locate rooms in a large pyramid by cosmic-ray ocultation.
The discovery of a large deposit of depleted uranium in western Africa. (This had been explained by geologists as the ash of a natural water-moderated reactor that formed in river-delta sediment and ran at a few hundred watts for centuries, but for the rap I proposed tailings from ore enrichment.)
The discovery of dry-cell batteries (carbon rod / caustic paste / metal can / asphaltam seal in pottery urn, explained as probably being used for electroplating) in an early Egyptian dig, combined with the observation that modern civilization went from the carbon/zinc dry cell to nuclear bombs and power reactors in under two hundred years, while Egyptian civilization stood for several THOUSAND. ("So why didn't THEY get to nuclear reactors. Well, what if they did?")
A speculation about Egyptian scientific naming conventions being analogies with a conceptually-related myth. (After all, WE did this before we got into acronyms, especially when naming the radioactives. Consider: Uranium, Plutonium, Thorium, ...)
There was a lot more. But this gets us to the hunt for waste disposal sites.
How do you get rid of the waste? How about hauling it out into the desert and piling rocks on top of it? But it will be dangerous for hundreds of thousands of years. How do you mark it to keep your distant descendants out of trouble?
"Here lies the-one-like-unto-the-sun-god (Tut-Ankh-Amon). Do not enter here and do not take the relics. If you do you will get SO sick. You will puke for days, your hair will fall out, your skin will fall off. If you survive that you will likely die of painful lumps, become impotent or nearly so, and if you manage to have descendants that aren't stillborn their line will be cursed by deformities for generations."
(At one point I thought of doing a psudonymous nut-cult-style book on the subject, with the bulk of the evidence of the former civilizations destroyed in a thermonuclear exchange between Atlantis and Mu, and the Egyptian fraction of civilization's technical base being lost under the Sahara - which is a very recent desert. I probably could have brought in the stories of the flood and maybe the plagues of Egypt. But that's beyond the scope of this post.)
But why doesn't someone do this deliberately? That is, create a domain for the sole purpose of receiving spam only, and automating a banned email list to other servers.
[Details on how to set up the TRAP deleted.]
That answers the first part of the question...
But how about the second part? Is there an existing tool to automate the conversion of the collected spam-trap mail into denials of future mail deliveries (and perhaps also to purging of still-enqueued letters to real addresses earlier in their mailing list order)?
Better yet: It could also modify the behavior of the SMTP server so it spawns a (limited nubmer of) "sticky TCP connection" child process to hang the spammer's bulk-mailing tool. Deploy a bunch of these puppies around the net and spamming becomes impractical once the spammer's mailing list has acquired a few addresses on spam-trapping sites.
If brightly coloured spandex clothes ever become commonplace I'm quitting this planet...
If I could have the body that goes with them - movie-star appearance, no (or greatly slowed) aging (and reversion to prime-of-life apparent age), improved stamina, mind that stays sharp under stress, exhaustion, and injury, rapid healing (including from repeated beating-to-unconsciousness) - bring 'em on!
I won't even insist they be bulletproof and have anti-gravity, supercomputer w/comm, vacuum & radiation shielding, air recycling, and warp drive.
[Objections to the anaecdotal evidence deleted.]
Fine.
But the anaecdote may convince some other bands to try it. And if they also succeed - and get press - the third wave could be a flood.
And Adam Smith's "invisible hand" drowns the RIAA. B-)
(Assuming the SSSCA doesn't put it in handcuffs, of course...)