It would depend on how the legislation would be implemented. Suppose that a copyright expires after five years in such a way that certain copyright concepts still apply to the work, such as the concept of derived work. Suppose you take a FOSS program whose copyright has expired, and make modifications to it. If this modified program is regarded as derived work of this program, then it inherits the non-copyright status; the modified program is also not copyrighted. Furthermore, any executable code is also a derived work. In this situation, with these rules, the incentive for cannibalizing the free program is greatly reduced, because the executable code cannot be put under a proprietary license which prohibits reverse engineering, modification and copying. This deflates much of the proprietary software model.
I could make the argument that under these rules it's okay to withhold the source code for a modified version (derived work) of a program whose copyright has expired. Everyone has access to the original source code. So what I'm withholding is basically the access to the patches that I developed and applied, except that I'm allowing people to run the compiled program. Those patches are my work, so I have a right to keep them secret. If someone doesn't like that, they are welcome not to use the modified versions of my program and just use the original, to which everyone has the source. I'm not imposing any restrictions on reverse engineering, modifying and re-distribution of my binaries (because, under these rules, I cannot do that). Anyone who wants to make an open source version of program which has exactly the same features as my no-source version can do so, and in so doing may even reverse-engineer my program. This still leaves me with some incentive to make such a program, but that incentive is small and improportion to the engineering effort I have put into it. Anyone willing to put in approximately the same effort can duplicate and compete with what I have done.
I used CFS (from AT&T research) some 15 years ago. CFS was an early effort based on the NFS protocol, providing a server (trusted, run by you) which would hold your keys and re-export an encrypted directory in plain text for you to mount locally. It was quite useable.
How about actually recompiling Windows into native code running on that mainframe. Now that would be impressive. Especially if it was big endian, and with unusual word sizes, not matching the ``everything is an 80386'' programming model underneath Windows.
This is not scientific; it's a study of one subject based on self-reporting.
You don't even have a control group, which is required for proper rigor; two subjects would be required for that.
To draw any statistifically significant conclusions, your groups have to be reasonably large.
Fact is, injuries can clear up on their own, simply by the passage of time. Any other event which correlate with the healing are not necessarily linked to it by cause-and-effect. Temporal and spatial co-occurence of two events isn't always evidence of cause-and-effect.
Shifting from C major to G major involves the alteration of a single note.
On a piano keyboard, the notes are nearly identically laid out, except that you're playing from G to G, and the F is sharp.
You haven't changed the identities of any notes. All 12 semitones are still there in the same order, from low to high.
This is not commesurable with a random scrambling of the notes.
Of course, there are undoubtedly instruments that make key changing very hard. Anything with valves that are geared toward diatonic playing, or some ``shift key'' to obtain chromatic notes like a chromatic harmonica, etc.
It's still not a complete scrambling of the note identities under the same fingerings.
You have no control group. The pain could have vanished for any number of reasons not related to Dvorak, including the passage of time. I had bouts with carpal some 19 years ago. It went away, never came back.
As a runner, I had injuries that came and went, never recurring. I didn't do anything other than maybe reduce training intensity for a little while, then return to normal. There is no explanation other than just passage of time and natural healing, keeping in mind that any specific conclusions based on studying one subject are unscientific bunk.
I believe that the typewriter jamming issue solved by QWERTY makes typists faster. It's not true that QWERTY is designed to slow typists down. QWERTY is designed to eliminate ``hazards'' in the machine's ``pipeline''.
We can in fact liken this to the execution of instructions on a processor.
The opponents of QWERTY say that its purpose is to bring about ``underclocking'', i.e. slowing down of the overall keystroke issue rate. But the technical issue is not speed, but collision between the hammers in the typewriter. The margin, or window of interference for adjacent hammers (corresponding to keys that are in adjacent columns of the keyboard) is worse than for keys that are horizontally distant.
There can be consider parallelism in the action of these hammers. Two keystrokes can be in progress at the same time, with one hammer slightly ahead of the other. One strikes the tape and paper, then recoils, and the other one lands in the same spot afterward. The farther apart the hammers are located, the closer together they can be temporally; i.e. the faster the typist can issue these keystrokes without causing a jam! I.e. the typist is encouraged to be faster, not to be slower.
But this spaced arrangement also makes it easier for the typist to go fast. Alternation between the hands leads to much more rapid typing. The typist can double the rate compared to using one hand. It's difficult to type a fast sequence with the fingers of one hand. This is particularly true of the weaker fingers: ring finger and pinky. Pianists struggle to get these into shape. Try playing a fast trill using your ring finger and pinky on a weighted piano keyboard, then try it with your thumb and index finger, then with two strong fingers from the opposite hand.
Also it takes energy to make the keys and hammers move, in a typewriter or piano. The typist can use gravity: the weight of his forearm from the elbow can act through a single finger to send power to the keystroke. If two or more keys have to be hit in rapid succession using the same hand, the energy of a single fall of the forearm has to be distributed across all three. C. C. Chang describes the concept of parallel sets and gravity attack principle in his Fundamentals of Piano Practice http://www.pianofundamentals.com/book.
When piano music contains a monophonic passage (one melody line), pianists take advantage of two-handed fingering to achieve greater virtuosity. Playing a melody with one hand is a difficult compromise for the sake of polyphony (e.g. Bach two-part invention with two independent melody lines often at the same tempo).
Also look at the African folk instrument known as the thumb piano. It's a resonant box with protruding, tuned metal reeds that are plucked with the thumbs. The scale is arranged such that you can play fast runs by hitting notes with alternate thumbs on opposite sides of the ``reedboard''. Virtuoso thumb piano players can shred blazingly fast over scale and arpeggio runs due to this left right alternation. You can see these guys in action in Bela Fleck's documentary film Throw Down Your Heart http://www.throwdownyourheart.com/. It's hard to believe they are just using their thumbs.
Well, that concludes my typing rant. At least it's not about static versus dynamic typing, for once!:)
The people subject to disciplinary actions should be the idiots who stuff a large number of recipients into the To: and cc: fields, instead of using bcc: .
If the list is needed repeatedly, it should be set up as a mailing list.
When you e-mail from some subscribed mailing list, you don't see the name of everyone on that list in your headers. The contents of To: is a name representing the mailing list. The mailing list uses lcc: to target the recipients, which is similar to bcc:.
It's very easy to reply-all by accident. Typically, the two cases are not very different in the user interface. There is a different button or whatever to reply versus reply all, but otherwise the flow of replying is the same.
Portable computers and wireless was already quite widely used a decade ago, so these are no-brainer predictions based squarely on what is already happening. It's not difficult to predict that things already in wide use, and increasing, will grow to become ubiquitous.
Laptop computers existed in the 1980's already. I had a 386SX laptop in 1990, 32 bit and all. It was powerful enough to run early versions of Linux.
Programmable HP calculators available in the 1970's were in fact portable computers.
There was plenty of wireless computing going on in 1999 already. Cell phones were already ubiquitous. Other wireless devices were not, but they had some presence, and it was more or less obvious they would merge with cell phones. ``Convergence'' was already a buzzword.
By 1999, PDA's like the Palm Pilot were already very popular.
You could get CDPD access with a Sierra Wireless AirCard in the PCMCIA slot of your laptop, or a small handheld computer running Windows CE.
I was working at a wireless software company on a client-server enterprise solution for mobile, secure wireless access to the intranet and internet, coporate e-mail and other applications. This was already second-generation app. When I had joined in 1997, (at around the same time I got this Slashdot account!), I did maintenance on the first generation one whose development started in around 1994.
Any-key-humor was slightly funny twenty years ago when Homer Simpson couldn't find the Any key.
``Press any key'' unambiguously means that any keyboard input is acceptable.
The real point of the humor is that users (who are native English speakers) get so acustomed to grammatically-gutted error messages which lack proper capitalization, punctuation and the use of articles like "a" and "the", that they no longer parse ``press any key'' in the obvious way. It's a computer message so there must be article missing, right? The user has come to believe that the computer is a Russian immigrant.
The lesson from Any Key humor is that text presented to the user should be recognized as grammatic by a native speaker of the user interface language in which it is written, and it should follow the proper orthographic conventions used in the written version of that language.
A prank program that doesn't allow the user to continue because he hasn't pressed the nonexistent Any key is not funny. The victim won't get the joke; it just looks like something has frozen, which is indistinguishable from routine behavior of a computer running DOS and Windows.
This may be slightly better:
unsigned int i = 0;
for (;;i++) {
getch();/* nonportable character-at-a-time input */
switch (i) {
case 5:
printf("please, i asking, to press any key!\n");
break;
case 8:
printf("!!?? it is still not any key, what now you did!\n");
break;
case 10:
printf("No no no! user to find... any... key... and just to press!\n");
break;
case 15:
printf("it is in afghanistan keypad on standard soviet keyboard.\n");
break;
case 20:
printf("will not continue until any key. understand? discussion end.\n");
break;
}
}
You can be effectively fired for refusing to break a law in an environment where law-breaking is so serious that if you were to draw attention to it with a wrongful dismissal suit, there would be no employment to come back to.:)
You'll be able to pick up very good, experienced developers for half, maybe a third of their current salaries.
Nope, just some of their ex-coworkers.
Smart companies know that you don't cut the slaraies in half across the board, but cut departments in half, leave the good people who did all the work anyway, at their original salaries.
Anyway, hardware has been cheaper than programmers for quite a long time. Throwing hardware at problems doesn't eliminate software, and doesn't shift a whole lot of responsibility from software to hardware.
More capable hardware tends to create opportunities and challenges for software developers, except in cases when you simply want to solve yesterday's problems a constant factor faster.
consider for example situations in which you avoid doing certain things in the software due to performance limitations. For instance some inexact query over a large data set may restrict itself to less interesting semantics, because it would take too long. When the hardware improves, someone will realize that now is the time to revisit that TODO: in the code to make the function look deeper.
There are cases like that in real-time and quasi-real-time programming too. TOday the response time is just so fast, so there are only so many things we can do in processing an event. We'd like to do more complicated event processing, but the cycles aren't there. When the cycles open up (new hardware), you can add semantics there. Someone has to write the code.
Lots of opportunities like that in interactive systems, where you can cram more and more behavior into the system which has to execute in a responsive way in between user interface events. Merely speeding up the old system doesn't provide any visible improvement, because the old system already has instantaneous response time; the user can't tell much difference between 100 milliseconds and 50 milliseconds. So the new hardware is a waste unless you make it do more, which brings down the program's 100 ms response back to the original 50 ms.
Wouldn't it be ironic if you could legally go out and get your cocaine fix, but had to get a prescription for some medication that you thought you needed?:)
Are you saving 2 seconds when you switch applications by losing 60 seconds over the course of 10 minutes as you're actually using an individual application?
Improving those two seconds is responsiveness.
Wasting small amounts of time over a long period is a loss of throughput.
Guess which one is more important for interactive computer use?
Those 60 seconds you lose over 10 minutes aren't seconds that can be put into good use, because they are not in one nice 60 second block.
Put it another way, whatever task you are doing with the computer wouldn't get done any sooner if that time were recovered. The task would be done with fewer disk accesses, which isn't the same thing!
In modern processors, there is no penalty for using virtual memory
This is incorrect. Virtual address translation imposes overheads, in some cases severe.
The performance of virtual memory depends on the TLB. The TLB has a fixed size and can span only so much virtual memory. What's worse, TLB's are rarely fully associative. So certain patterns of page access can thrash a TLB entry. On some architectures, the TLB is direct mapped. This means that each page is assigned to a fixed position in the TLB cache. If some code alternately works with just two pages that map to the same TLB entry, there will a stream of TLB misses. E.g. a word-by-word memcpy from one page to the other will be orders of magnitude slower than a copy through a large temporary buffer.
all translation from virtual to physical address space is done internal to the processor and you won't notice the difference.
Notice the difference compared to what? When was the last time you were able to run a version of your operating system without virtual memory management enabled?
There is never perfect information in any market. That is one of the reasons why there is a spread in prices; there is no one ``correct'' price, just a moving point at which bids meet asks.
Buyers and sellers always conceal some things from each other, in any transaction. If you're buying a used car, you don't know everything about it, and you don't know everything that the seller knows.
The people who get hurt by insider trading are gamblers. Insider trading doesn't hurt the market's long-term valuations of an equity which has some kind of intrinsic worth supported by its fundamentals.
Slashdot Mirror
It would depend on how the legislation would be implemented. Suppose that a copyright expires after five years in such a way that certain copyright concepts still apply to the work, such as the concept of derived work. Suppose you take a FOSS program whose copyright has expired, and make modifications to it. If this modified program is regarded as derived work of this program, then it inherits the non-copyright status; the modified program is also not copyrighted. Furthermore, any executable code is also a derived work. In this situation, with these rules, the incentive for cannibalizing the free program is greatly reduced, because the executable code cannot be put under a proprietary license which prohibits reverse engineering, modification and copying. This deflates much of the proprietary software model.
I could make the argument that under these rules it's okay to withhold the source code for a modified version (derived work) of a program whose copyright has expired. Everyone has access to the original source code. So what I'm withholding is basically the access to the patches that I developed and applied, except that I'm allowing people to run the compiled program. Those patches are my work, so I have a right to keep them secret. If someone doesn't like that, they are welcome not to use the modified versions of my program and just use the original, to which everyone has the source. I'm not imposing any restrictions on reverse engineering, modifying and re-distribution of my binaries (because, under these rules, I cannot do that). Anyone who wants to make an open source version of program which has exactly the same features as my no-source version can do so, and in so doing may even reverse-engineer my program. This still leaves me with some incentive to make such a program, but that incentive is small and improportion to the engineering effort I have put into it. Anyone willing to put in approximately the same effort can duplicate and compete with what I have done.
Nice quote. Unfortunately, you will find plenty that get in the way of clarifying your ideas.
You can certainly construct features of one language within another if you really *try*.
Demonstrably false, sorry.
I used CFS (from AT&T research) some 15 years ago. CFS was an early effort based on the NFS protocol, providing a server (trusted, run by you) which would hold your keys and re-export an encrypted directory in plain text for you to mount locally. It was quite useable.
How about actually recompiling Windows into native code running on that mainframe. Now that would be impressive. Especially if it was big endian, and with unusual word sizes, not matching the ``everything is an 80386'' programming model underneath Windows.
This is not scientific; it's a study of one subject based on self-reporting.
You don't even have a control group, which is required for proper rigor; two subjects would be required for that.
To draw any statistifically significant conclusions, your groups have to be reasonably large.
Fact is, injuries can clear up on their own, simply by the passage of time. Any other event which correlate with the healing are not necessarily linked to it by cause-and-effect. Temporal and spatial co-occurence of two events isn't always evidence of cause-and-effect.
Shifting from C major to G major involves the alteration of a single note.
On a piano keyboard, the notes are nearly identically laid out, except that you're playing from G to G, and the F is sharp.
You haven't changed the identities of any notes. All 12 semitones are still there in the same order, from low to high.
This is not commesurable with a random scrambling of the notes.
Of course, there are undoubtedly instruments that make key changing very hard. Anything with valves that are geared toward diatonic playing, or some ``shift key'' to obtain chromatic notes like a chromatic harmonica, etc.
It's still not a complete scrambling of the note identities under the same fingerings.
You have no control group. The pain could have vanished for any number of reasons not related to Dvorak, including the passage of time. I had bouts with carpal some 19 years ago. It went away, never came back.
As a runner, I had injuries that came and went, never recurring. I didn't do anything other than maybe reduce training intensity for a little while, then return to normal. There is no explanation other than just passage of time and natural healing, keeping in mind that any specific conclusions based on studying one subject are unscientific bunk.
I believe that the typewriter jamming issue solved by QWERTY makes typists faster. It's not true that QWERTY is designed to slow typists down. QWERTY is designed to eliminate ``hazards'' in the machine's ``pipeline''.
We can in fact liken this to the execution of instructions on a processor.
The opponents of QWERTY say that its purpose is to bring about ``underclocking'', i.e. slowing down of the overall keystroke issue rate. But the technical issue is not speed, but collision between the hammers in the typewriter. The margin, or window of interference for adjacent hammers (corresponding to keys that are in adjacent columns of the keyboard) is worse than for keys that are horizontally distant.
There can be consider parallelism in the action of these hammers. Two keystrokes can be in progress at the same time, with one hammer slightly ahead of the other. One strikes the tape and paper, then recoils, and the other one lands in the same spot afterward. The farther apart the hammers are located, the closer together they can be temporally; i.e. the faster the typist can issue these keystrokes without causing a jam! I.e. the typist is encouraged to be faster, not to be slower.
But this spaced arrangement also makes it easier for the typist to go fast. Alternation between the hands leads to much more rapid typing. The typist can double the rate compared to using one hand. It's difficult to type a fast sequence with the fingers of one hand. This is particularly true of the weaker fingers: ring finger and pinky. Pianists struggle to get these into shape. Try playing a fast trill using your ring finger and pinky on a weighted piano keyboard, then try it with your thumb and index finger, then with two strong fingers from the opposite hand.
Also it takes energy to make the keys and hammers move, in a typewriter or piano. The typist can use gravity: the weight of his forearm from the elbow can act through a single finger to send power to the keystroke. If two or more keys have to be hit in rapid succession using the same hand, the energy of a single fall of the forearm has to be distributed across all three. C. C. Chang describes the concept of parallel sets and gravity attack principle in his Fundamentals of Piano Practice http://www.pianofundamentals.com/book.
When piano music contains a monophonic passage (one melody line), pianists take advantage of two-handed fingering to achieve greater virtuosity. Playing a melody with one hand is a difficult compromise for the sake of polyphony (e.g. Bach two-part invention with two independent melody lines often at the same tempo).
Also look at the African folk instrument known as the thumb piano. It's a resonant box with protruding, tuned metal reeds that are plucked with the thumbs. The scale is arranged such that you can play fast runs by hitting notes with alternate thumbs on opposite sides of the ``reedboard''. Virtuoso thumb piano players can shred blazingly fast over scale and arpeggio runs due to this left right alternation. You can see these guys in action in Bela Fleck's documentary film Throw Down Your Heart http://www.throwdownyourheart.com/. It's hard to believe they are just using their thumbs.
Well, that concludes my typing rant. At least it's not about static versus dynamic typing, for once! :)
The people subject to disciplinary actions should be the idiots who stuff a large number of recipients into the To: and cc: fields, instead of using bcc: .
If the list is needed repeatedly, it should be set up as a mailing list.
When you e-mail from some subscribed mailing list, you don't see the name of everyone on that list in your headers.
The contents of To: is a name representing the mailing list. The mailing list uses lcc: to target the recipients, which is similar to bcc:.
It's very easy to reply-all by accident. Typically, the two cases are not very different in the user interface. There is a different button or whatever to reply versus reply all, but otherwise the flow of replying is the same.
Portable computers and wireless was already quite widely used a decade ago, so these are no-brainer predictions based squarely on what is already happening. It's not difficult to predict that things already in wide use, and increasing, will grow to become ubiquitous.
Laptop computers existed in the 1980's already. I had a 386SX laptop in 1990, 32 bit and all. It was powerful enough to run early versions of Linux.
Programmable HP calculators available in the 1970's were in fact portable computers.
There was plenty of wireless computing going on in 1999 already. Cell phones were already ubiquitous. Other wireless devices were not, but they had some presence, and it was more or less obvious they would merge with cell phones. ``Convergence'' was already a buzzword.
By 1999, PDA's like the Palm Pilot were already very popular.
You could get CDPD access with a Sierra Wireless AirCard in the PCMCIA slot of your laptop, or a small handheld computer running Windows CE.
I was working at a wireless software company on a client-server enterprise solution for mobile, secure wireless access to the intranet and internet, coporate e-mail and other applications. This was already second-generation app. When I had joined in 1997, (at around the same time I got this Slashdot account!), I did maintenance on the first generation one whose development started in around 1994.
Any-key-humor was slightly funny twenty years ago when Homer Simpson couldn't find the Any key.
``Press any key'' unambiguously means that any keyboard input is acceptable.
The real point of the humor is that users (who are native English speakers) get so acustomed to grammatically-gutted error messages which lack proper capitalization, punctuation and the use of articles like "a" and "the", that they no longer parse ``press any key'' in the obvious way. It's a computer message so there must be article missing, right? The user has come to believe that the computer is a Russian immigrant.
The lesson from Any Key humor is that text presented to the user should be recognized as grammatic by a native speaker of the user interface language in which it is written, and it should follow the proper orthographic conventions used in the written version of that language.
A prank program that doesn't allow the user to continue because he hasn't pressed the nonexistent Any key is not funny. The victim won't get the joke; it just looks like something has frozen, which is indistinguishable from routine behavior of a computer running DOS and Windows.
This may be slightly better:
unsigned int i = 0;
for (;;i++) { /* nonportable character-at-a-time input */ ... any ... key ... and just to press!\n");
getch();
switch (i) {
case 5:
printf("please, i asking, to press any key!\n");
break;
case 8:
printf("!!?? it is still not any key, what now you did!\n");
break;
case 10:
printf("No no no! user to find
break;
case 15:
printf("it is in afghanistan keypad on standard soviet keyboard.\n");
break;
case 20:
printf("will not continue until any key. understand? discussion end.\n");
break;
}
}
You can be effectively fired for refusing to break a law in an environment where law-breaking is so serious that if you were to draw attention to it with a wrongful dismissal suit, there would be no employment to come back to. :)
You'll be able to pick up very good, experienced developers for half, maybe a third of their current salaries.
Nope, just some of their ex-coworkers.
Smart companies know that you don't cut the slaraies in half across the board, but cut departments in half, leave the good people who did all the work anyway, at their original salaries.
Anyway, hardware has been cheaper than programmers for quite a long time. Throwing hardware at problems doesn't eliminate software, and doesn't shift a whole lot of responsibility from software to hardware.
More capable hardware tends to create opportunities and challenges for software developers, except in cases when you simply want to solve yesterday's problems a constant factor faster.
consider for example situations in which you avoid doing certain things in the software due to performance limitations. For instance some inexact query over a large data set may restrict itself to less interesting semantics, because it would take too long. When the hardware improves, someone will realize that now is the time to revisit that TODO: in the code to make the function look deeper.
There are cases like that in real-time and quasi-real-time programming too. TOday the response time is just so fast, so there are only so many things we can do in processing an event. We'd like to do more complicated event processing, but the cycles aren't there. When the cycles open up (new hardware), you can add semantics there. Someone has to write the code.
Lots of opportunities like that in interactive systems, where you can cram more and more behavior into the system which has to execute in a responsive way in between user interface events. Merely speeding up the old system doesn't provide any visible improvement, because the old system already has instantaneous response time; the user can't tell much difference between 100 milliseconds and 50 milliseconds. So the new hardware is a waste unless you make it do more, which brings down the program's 100 ms response back to the original 50 ms.
my Lisp program dies?
'(one two three four five six seven eight nine ten ...?)
*duck*
Check out the pot it pot refrigerator for a innovative low-tech solution that is changing peoples' lives for the better right now
That would be: http://en.wikipedia.org/wiki/Pot-in-pot_refrigerator
(I am not a libertarian, by the way)
Thanks for the stunning revelation there.
Wouldn't it be ironic if you could legally go out and get your cocaine fix, but had to get a prescription for some medication that you thought you needed? :)
Are you saving 2 seconds when you switch applications by losing 60 seconds over the course of 10 minutes as you're actually using an individual application?
Improving those two seconds is responsiveness.
Wasting small amounts of time over a long period is a loss of throughput.
Guess which one is more important for interactive computer use?
Those 60 seconds you lose over 10 minutes aren't seconds that can be put into good use, because they are not in one nice 60 second block.
Put it another way, whatever task you are doing with the computer wouldn't get done any sooner if that time were recovered. The task would be done with fewer disk accesses, which isn't the same thing!
In modern processors, there is no penalty for using virtual memory
This is incorrect. Virtual address translation imposes overheads, in some cases severe.
The performance of virtual memory depends on the TLB. The TLB has a fixed size and can span only so much virtual memory. What's worse, TLB's are rarely fully associative. So certain patterns of page access can thrash a TLB entry. On some architectures, the TLB is direct mapped. This means that each page is assigned to a fixed position in the TLB cache. If some code alternately works with just two pages that map to the same TLB entry, there will a stream of TLB misses. E.g. a word-by-word memcpy from one page to the other will be orders of magnitude slower than a copy through a large temporary buffer.
all translation from virtual to physical address space is done internal to the processor and you won't notice the difference.
Notice the difference compared to what? When was the last time you were able to run a version of your operating system without virtual memory management enabled?
What's the alternative? Globalized security, courtesy of Big Brother?
Don't good fences make good neigbors?
I suppose it's wasteful, in code, for module entry points to validate parameters, too. :)
There is never perfect information in any market. That is one of the reasons why there is a spread in prices; there is no one ``correct'' price, just a moving point at which bids meet asks.
Buyers and sellers always conceal some things from each other, in any transaction. If you're buying a used car, you don't know everything about it, and you don't know everything that the seller knows.
The people who get hurt by insider trading are gamblers. Insider trading doesn't hurt the market's long-term valuations of an equity which has some kind of intrinsic worth supported by its fundamentals.
Man uses free market mechanisms to avoid losing three quarters of a million bucks, and Big Brother comes down on him.
I can't imagine not selling stock after learning of some upcoming bad news, by any means.
what are you supposed to do?
``Gee, I'm going to lose 750 thousand dollars just to be a law-abiding citizen, out of the goodness of my heart''.
This is no more wrong than counting cards at a black jack table.
I have five of them, plus reverse.
The commute is all the war I need.
Rules are not incompatible with free will.
Free will is rule processing.
A vending machine demonstrates a low form of free will when it accepts some coins, rejects others, and serves merchandise.
It's not anywhere complex enough to have a concept of self, but I believe that this can arise from sufficiently complex rule processing.
The drama is in the high levels of the software, so to speak, not in the rigid computional software.
When will this tired B.S. come to rest?