Re:SCO still packs a punch?
on
SCO SCO SCO!
·
· Score: 1
I don't see why there's so much focus on a buyout. I'm sure SCO would be quite happy to stay as they are provided that IBM backs up a very large truck full of money to their loading dock.
And if SCO is such a loser company why would IBM want to buy them? Fight them or pay them, there's no good reason to buy them unless it's to save face or unless they really believe there's value there.
Well, your definition is OK as far as it goes - Skinner himself said that "behavior is shaped by its consequences".
On the other hand, having read three of Skinner's books as well as other research on his work, I can tell you that he didn't think much of punishment as an effective means of controlling behavior. Thus my original comment that he would not approach the problem with punishment in mind.
It wasn't my intention to give a detailed procedure for training children not to stick a knife in a wall socket using Skinner's methods. Skinner accounted for situations where there was a disriminating factor. That's why if you have seen the device where you put a coin in a box and the chicken (I think it was a chicken) plays the piano you note that he only plays when the light comes on.
So you could train the child to discriminate between approaching wall sockets in general and approaching them with knives. I'm not advocating this training, but as a long time critic of some of Skinner's work, I think it's only fair to represent his work accurately.
Nice story, but what you describe is not the Skinnerian approach. Skinner did experiments that proved (at least with animals) that postive reinforcement was the most effective means of training.
In the situation you outlined, he probably would have suggested that the child be rewarded for movements that led away from the socket and through successive aproximation, the desired training would take place. Or he might have suggested rewarding useful behavior that was incompatible with sticking a knife in a wall socket.
Re:Sounds like what C# has that makes it better...
on
Preview of Java 1.5
·
· Score: 1
Here we go again with this disguising argument. Name one vendor who implemented their application using J++ and then discovered after its release that it wouldn't run on anything but Windows. Most programmers who really cared about cross-platform development probably didn't use J++. Most of those who did use it were targeting Windows.
They were willing to sacrifice the appearence of the game in order to make the gameplay more like the original. The could have taken the approach that many other companies did with their 2600 maze games - make sure that there were never more than two objects on the same line at the same time. But then the ghosts wouldn't behave the way you'd expect.
As you mentioned, it might have been possible to use doubling and tripling, but I suspect that there wouldn't be enough time on the scan line to do all the repositioning (Assuming you don't want your ghosts to be limited to a fixed distance apart).
Repositioning on the current scan line for the current scan line is tough to accomplish (I used to think it was impossible until I saw Galaxian).
Hard or not, it makes programming games on other systems trivial by comparison (Obviously the amount of code in a modern game is orders of magnitude larger so I'm not talking about size or development time).
Name any other software you're aware of that requires software timing accuracy down to 1 CPU cycle (Certainly no software running on a PC since that kind of software timing accuracy is impossible). That isn't necessary for all 2600 games, but it is for some.
Remember that the system has only 128 bytes of RAM, no interrupts, and horizontal positioning is performed by timing rather than by value.
Writing for the 2600 was a worthwhile challenge in its day. It strikes me as a rather academic challenge now.
Perhaps the state-of-the-art in games is so good now that players don't get blown away anymore no matter how well programmed they are. If so, it's too bad.
On the other hand, today's games are more about the art and less about the technology and I suppose that's the way it should be.
No. This would make trade secrets trivially easy to circumvent.
As long as you can establish that the third party obtained the information from an individual who violated the NDA they signed or through another individual who had obtained the information in that manner, you could take legal action against that third party.
I guess what you mean by "from scratch", is that it doesn't contain any copying and pasting from any other OS.
Another definition of "from scratch", would mean that Linus had never read any material on Unix internals or spoken to anyone about it and reverse-engineered it by observing the behavior of a legal version as a user. If there were a trade secret case, this would be the best scenario for a defense.
Well, the API and functionality is a lot to have in common. The source code may be entirely different (maybe), but it's hardly as if Linux is a clean-room implentation of Unix.
As far as Windows is concerned, the kernel is not a stand-alone product and POSIX compatibility is a minor function of the overall Windows product. On the other hand, does Linux really go well beyond Unix in functionality?
If Unix is in the public domain, perhaps Linux is merely a derivative work and shouldn't be eligible for copyright protection. I realize I'm mixing trade secrets with copyright, but who knows what effect this "fairness" argument could have on a judge if someone were sued for violating the Linux GPL.
"Just because a person or group reveals a trade secret does not mean that the recipients know it is a trade secret."
That may be the case, but it doesn't mean that they are insulated against the consequences. You can unkowingly buy stolen property at a swap meet, but it doesn't mean you can't be arrested for receiving stolen properly.
"Trade secret law only applies to the original individual who divulged the information."
I seriously doubt your interpretation because it would render trade secrets useless. If the trade secret holder has done his due diligence, any receiver of the secret would have to obtain it through illegal means. No other method of obtaining the secret is possible. (Note: I'm talking about receiving or obtaining a trade secret, not independently coming up with the same idea.)
I'm not an expert on the history of Unix development, but it seems quite plauasible that one or more AT&T Unix trade secrets directly or indirectly played a role in the development of Unix variants including Linux. I don't claim this as a fact, but it wouldn't surprise me. This may not have any relevence to the SCO case, but I think it could play a role if somebody got sued for violating Linux's GPL license.
The rights that MS has as a monopoly are being established by the court cases that have been concluded and those still pending. At the end of that process they will enjoy all the same rights as any other company except where the courts have said otherwise.
Of course, there is the possibility that it may be litigating itself into wealth should it win any court cases or negotiate for money.
Look how AOL bought the unprofitable Netscape. That's an investment that's unlikely to pay off in any conventional way. The big payoff may come from suing MS. An option that could only be exercised by buying Netscape.
About 90% of the developers I've worked with in my career developed software that is sold. Just because a program can't be purchased at retail doesn't mean it isn't sold.
Any kind of advice that says "Always do.." or "Never do.." is going to be wrong at least some of the time. To state the obvious: not all situations are the same, so you can't treat them as if they were.
One reason you might want to rewrite a program from scratch is if the effort to understand the code is significantly greater than the effort to understand the problem you're trying to solve. Of course, requirements are an important part of the analysis. If legacy behavior is a requirement (which will typically include behavior that has nothing to do with the actual problem), then that argues against rewriting since you're going to have to reverse engineer the system anyway.
One should also consider the "do nothing" option. Perhaps the benefits are outweighed by the costs and risks of development.
"Big/Little endian issue, and this is one of the worst problems u will meet in your life:)."
I agree. Even when just communicating between processors with different endian schemes it's a mess if you're using a binary protocol. The worst thing is that you can't isolate the higher-level code from the translation unless you create a middle-layer that understands all of the messages.
Slashdot Mirror
I don't see why there's so much focus on a buyout. I'm sure SCO would be quite happy to stay as they are provided that IBM backs up a very large truck full of money to their loading dock.
And if SCO is such a loser company why would IBM want to buy them? Fight them or pay them, there's no good reason to buy them unless it's to save face or unless they really believe there's value there.
Well, your definition is OK as far as it goes - Skinner himself said that "behavior is shaped by its consequences".
On the other hand, having read three of Skinner's books as well as other research on his work, I can tell you that he didn't think much of punishment as an effective means of controlling behavior. Thus my original comment that he would not approach the problem with punishment in mind.
It wasn't my intention to give a detailed procedure for training children not to stick a knife in a wall socket using Skinner's methods. Skinner accounted for situations where there was a disriminating factor. That's why if you have seen the device where you put a coin in a box and the chicken (I think it was a chicken) plays the piano you note that he only plays when the light comes on.
So you could train the child to discriminate between approaching wall sockets in general and approaching them with knives. I'm not advocating this training, but as a long time critic of some of Skinner's work, I think it's only fair to represent his work accurately.
Nice story, but what you describe is not the Skinnerian approach. Skinner did experiments that proved (at least with animals) that postive reinforcement was the most effective means of training.
In the situation you outlined, he probably would have suggested that the child be rewarded for movements that led away from the socket and through successive aproximation, the desired training would take place. Or he might have suggested rewarding useful behavior that was incompatible with sticking a knife in a wall socket.
Here we go again with this disguising argument. Name one vendor who implemented their application using J++ and then discovered after its release that it wouldn't run on anything but Windows. Most programmers who really cared about cross-platform development probably didn't use J++. Most of those who did use it were targeting Windows.
I guess we're both silly, then. I thought gameplay was part of the art.
Well, at least I gave you an excuse for a little self-promotion.
They were willing to sacrifice the appearence of the game in order to make the gameplay more like the original. The could have taken the approach that many other companies did with their 2600 maze games - make sure that there were never more than two objects on the same line at the same time. But then the ghosts wouldn't behave the way you'd expect.
As you mentioned, it might have been possible to use doubling and tripling, but I suspect that there wouldn't be enough time on the scan line to do all the repositioning (Assuming you don't want your ghosts to be limited to a fixed distance apart).
Repositioning on the current scan line for the current scan line is tough to accomplish (I used to think it was impossible until I saw Galaxian).
Hard or not, it makes programming games on other systems trivial by comparison (Obviously the amount of code in a modern game is orders of magnitude larger so I'm not talking about size or development time).
Name any other software you're aware of that requires software timing accuracy down to 1 CPU cycle (Certainly no software running on a PC since that kind of software timing accuracy is impossible). That isn't necessary for all 2600 games, but it is for some.
Remember that the system has only 128 bytes of RAM, no interrupts, and horizontal positioning is performed by timing rather than by value.
Writing for the 2600 was a worthwhile challenge in its day. It strikes me as a rather academic challenge now.
Perhaps the state-of-the-art in games is so good now that players don't get blown away anymore no matter how well programmed they are. If so, it's too bad.
On the other hand, today's games are more about the art and less about the technology and I suppose that's the way it should be.
No. This would make trade secrets trivially easy to circumvent.
As long as you can establish that the third party obtained the information from an individual who violated the NDA they signed or through another individual who had obtained the information in that manner, you could take legal action against that third party.
I guess what you mean by "from scratch", is that it doesn't contain any copying and pasting from any other OS.
Another definition of "from scratch", would mean that Linus had never read any material on Unix internals or spoken to anyone about it and reverse-engineered it by observing the behavior of a legal version as a user. If there were a trade secret case, this would be the best scenario for a defense.
I often thought this is the real reason why so many companies go back to Berkeley Unix code to implement TCP/IP.
Has anybody reverse engineered TCP/IP code to derive a document that could be used to implement TCP/IP without reference to code?
You hit the nail on the head. A potential standard should be designed, implemented and tested in the real world before becoming a standard.
Many good standards have come directly from industry while others, as you point out, have come from universities.
Well, the API and functionality is a lot to have in common. The source code may be entirely different (maybe), but it's hardly as if Linux is a clean-room implentation of Unix.
As far as Windows is concerned, the kernel is not a stand-alone product and POSIX compatibility is a minor function of the overall Windows product. On the other hand, does Linux really go well beyond Unix in functionality?
If Unix is in the public domain, perhaps Linux is merely a derivative work and shouldn't be eligible for copyright protection. I realize I'm mixing trade secrets with copyright, but who knows what effect this "fairness" argument could have on a judge if someone were sued for violating the Linux GPL.
"Just because a person or group reveals a trade secret does not mean that the recipients know it is a trade secret."
That may be the case, but it doesn't mean that they are insulated against the consequences. You can unkowingly buy stolen property at a swap meet, but it doesn't mean you can't be arrested for receiving stolen properly.
"Trade secret law only applies to the original individual who divulged the information."
I seriously doubt your interpretation because it would render trade secrets useless. If the trade secret holder has done his due diligence, any receiver of the secret would have to obtain it through illegal means. No other method of obtaining the secret is possible. (Note: I'm talking about receiving or obtaining a trade secret, not independently coming up with the same idea.)
I'm not an expert on the history of Unix development, but it seems quite plauasible that one or more AT&T Unix trade secrets directly or indirectly played a role in the development of Unix variants including Linux. I don't claim this as a fact, but it wouldn't surprise me. This may not have any relevence to the SCO case, but I think it could play a role if somebody got sued for violating Linux's GPL license.
The rights that MS has as a monopoly are being established by the court cases that have been concluded and those still pending. At the end of that process they will enjoy all the same rights as any other company except where the courts have said otherwise.
Since MS could afford a bigger army of lawyers that the US government and the states, they were able to win all the court cases. Oh wait ...
Of course, there is the possibility that it may be litigating itself into wealth should it win any court cases or negotiate for money.
Look how AOL bought the unprofitable Netscape. That's an investment that's unlikely to pay off in any conventional way. The big payoff may come from suing MS. An option that could only be exercised by buying Netscape.
About 90% of the developers I've worked with in my career developed software that is sold. Just because a program can't be purchased at retail doesn't mean it isn't sold.
If your so-called "stupid people" didn't use computers, you couldn't afford one.
Any kind of advice that says "Always do.." or "Never do.." is going to be wrong at least some of the time. To state the obvious: not all situations are the same, so you can't treat them as if they were.
One reason you might want to rewrite a program from scratch is if the effort to understand the code is significantly greater than the effort to understand the problem you're trying to solve. Of course, requirements are an important part of the analysis. If legacy behavior is a requirement (which will typically include behavior that has nothing to do with the actual problem), then that argues against rewriting since you're going to have to reverse engineer the system anyway.
One should also consider the "do nothing" option. Perhaps the benefits are outweighed by the costs and risks of development.
"Those who decide to go create and repeat acronyms instead of paying attention are sooner or later left behind and should be."
You mean acronyms like "XML", "HTML", or "GNU"? Or perhaps only other people's acronyms are a problem for you.
"Big/Little endian issue, and this is one of the worst problems u will meet in your life :)."
I agree. Even when just communicating between processors with different endian schemes it's a mess if you're using a binary protocol. The worst thing is that you can't isolate the higher-level code from the translation unless you create a middle-layer that understands all of the messages.