Remember that SCO had a unix product before buying Caldera's linux distro. SCO's own unix was a Xenix-derivative. So SCO does have some unix code (quite a bit) that isn't covered by GPL. It could be *that* code that they are basing their lawsuit on.
Re:Business Models or "Developers, developers!"
on
Minitel Hits Twenty
·
· Score: 1
He is talking about the internet as we know it now, a functional forerunner of the internet as far as the position it takes in a lot of people's daily lives.
I doubt it. His phrasing was such that he really did claim the internet didn't exist yet at the time. Had he known that this wasn't true, he could have phrased it differently There was no phrasing that indicated to me that he really meant internet *as we know it*. I'm more inclined to say he actually believed what he wrote literally.
Dumping is selling below your own cost. It has nothing to do with your competitor's cost. If it costs you $5 to make a widget, and you sell it for $1, you lose $4 on every sale. The reason this is illegal is that it is a tactic that only a large company making profits elsewhere can afford to try. A small company cannot try to do such a thing and remaing in existence for long because they don't make enough money elsewhere to cover for the loss. Thus a big company can drive a small one out of business by just choosing to operate at a loss for a while. Hopefully you understand what the danger is of allowing the situation where once a company becomes big it gets to stay that way purely by virtue of being big and nothing else.
But one thing that *is* allowed is to sell your product for less than your competitor when it actually costs you less than your competitor's product costs him. If you have a better means of producing widgets that really *does* cost only $1, then you can charge $1 for a widget perfectly legally, but your competitor cannot drop his price to $1 to compete with you if his cost is still up at $4. He has to ring the price down by reducing his own cost, not by selling at a loss.
Your analogy has nothing to do with the complaint. We aren't asking them to point out what was stolen so that we can give it back and forget the whole thing. We're asking for them to point it out becasue if they don't they have no proof a theft actually occurred. It's like claiming I took your car and parked in in my multi-level garage, without specifying where in the garage it is, when you had the keys to the garage the whole time, and my permission to go look around whenever you want, and you still won't point out where the alleged car you claim I put in my garage actually is.
...they answered "if(x == 5)" and you answered what you just said, they would get the job.
Then it would be a job I would not want and the fact that I was rejected would be a good thing in the long run. (Not that the issue of one bit of syntax matters that much, but the fact that my potential boss would be so petty as to hire or fire based on it would be a warning flag to me.)
The problem with standards is that most proponents don't admit that what they are doing is totally arbitrary. They get this holier-than-thou attitude that there is ONE right way based on what "normal" people would think, and how the other ways are "abnormal". I understand the need to conform to standards, but the more asinine the proponents are about it and the less they recognize the purely made-up arbitrary nature of them, the less willing I am to conform to them. If the standard proponent admits that a particular rule has no real rationale other than they chose to pick one way for consistency, then I'm a lot more willing to work within that rule.
You're assuming we see it as a problem. I *like* the fact that booleans aren't artificially crippled version of an int in C and are instead just ints like they *really* are underneath. What I don't like is that the library of system routines aren't consistent with the meaning of booleans. (Most functions on man page 2 return zero for success, while most functions in stdlib return zero for failure, rendering this neat feature rather useless in practice because you always have to remember which way around the function you are using does it, and it might be the opposite of the handy boolean interpetation.)
I would argue that if your compiler does something different with
for( ; condition ; )
than it does for
while( condition )
that it is broken. The rule is that for( ; condition ; ) literally means: start a loop, do nothing before the loop starts, check condition at the bottom of the loop, do nothing at the bottom of each loop.
If your compiler is inserting some kind of code for those "do nothing" parts, I would call that broken.
That's only if you view "put parentheses next to name" as an indicator of "this is a function". I don't. You only see it that way because that's the convention you are used to seeing. The convention I'm used to seeing is "put parentheses next to name" means "these parentheses are a required part of the syntax for this thing - hence they are directly attached to it." I think that makes more sense. so, for example, if you choose to put parenthesis around the expression of a return statement, they don't go next to the return. They are not part of the syntax of return. They are part of the syntax of the expression, in that case:
return (foo);
means: return thingy; where in this case thingy is "(foo)".
Whereas:
while( foo ) means: while( thingy ), where thingy is "foo".
To me, this: while ( foo ) would read as: while thingy, where thingy is "( foo )", which is of course not really what's happening.
I think having a default is useful because when you see the special case you immediately know that it's acting differently, that the code is dependent on increment/decrement order, and that there is probably a good reason why it was written that way.
That's not true though. The code could be just as dependant on increment order when it's written postfix as when it's written prefix. If you train yourself to only bother thinking about it when you see it one way and not the other, you are asking for trouble. You should be paying attention to it BOTH ways. In fact, I would argue that the cases where postfix is really needed are more unusual than the cases where prefix is really needed. The idea is very strange of the return value from an operation NOT being the result of the operation but instead the result before the operation was done. That's not the way anything else in the language works. Imagine if you had a concatenation string function called concat(x,y) that tacks y on to the end of x. It would be very odd for that to return x as it looked before concatenation.
There's times when convention is wrong to me. And this is one. I see no reason to do "x++' unless there was some reason the person wanted to return the preincremented value, so that's the version that makes me stop and think about it, while you have the opposite reaction. Besides, I avoid '++' side-effects like the plague, so I'm usually using it on a line by itself (or as the last clause of a for(...) header), where you don't really care when the value is returned since you're just throwing the return value away anyway. And in the case where you are just throwing the return value away, it makes no sense to bother remembering what it used to be before the increment occurred.
But that wouldn't be the same as the object not having mass.
Go re-read my post that caused you to argue with me in the first place. I never said there would be no wind - just that it can't be measured on the F-scale without stuff being damaged, and that's why we don't know the intensity of tornadoes that are too rural.
That's the GOAL, but in practice the only way they have to do it is to assess damage to objects with well-known properties. So while the goal of the F scale is to get a range of guess for the windspeed the system USES property damage to make that guess. (It's like measuring mass in Kilograms by using a weight scale. Kilograms are NOT a measure of weight, but on earth there's a known one-to-one mapping between the two, so weight is typically used to arrive at a figure for mass. The F-scale does the same sort of thing, but in a more vague fasion.
If your only means of measuring mass was a scale, you wouldn't know what the mass of something in zero-G is. And if the only means of measuring windspeed is to look at damage to well-known manmade objects, and there aren't any around, you don't know what the windspeed was.
Frodo pulled through, beside his very mortal constitution, because of the application of what you might call magic.
Yes, but put it in terms of a computer game with hit points or some other such damage mechanism. To make Frodo's player really *feel* that notion that Frodo almost died, Frodo has to be down to scant hit points left. And then the difference between him dying and him living is a mere matter of typing speed and how on-the-ball the players of the elves at Rivendell are. "Oh, darn, I made a typo and that slowed me down enough that Frodo is dead. Darn Darn Darn! Oh, man I'm so sorry. Now who's gonna be able to carry the evil artifact."
My point is that in a GAME, you can't really have too many near-death scenes before one becomes an actual-death scene. In a game with fair rules mechanics, you are just as likely to fail in a 50/50 situation as live. This is not really how novels like LOTR work. In a novel, you die if the author things it makes sense to happen there. Senseless, plot-setting-back deaths don't happen. But realisticly, they would.
I'm not saying a PK MMORPG can't work at all - but there's no way in hell it will be as grandiose a story as LOTR. To make your character likely to live, you would avoid the quests where the odds are heavily against you, like, oh, say, two low level newbie halflings walking to the heavily armed enemy-held zone and chucking the world's most powerful artifact into a volocano mere days march from the enemy's main stronghold.
As long as you follow the principle of least surprise and don't overload the + operator to take square roots it's really not a problem.
please refer to my example. The problem comes when you overload an operator that already has a different meaning, confusing anyone reading the code who doesn't know about your overload. In my example, the operator '+' already meant pointer-offset arithmetic. I changed it to mean "numerical addition to the string interpeted as an int". It's a valid understanding of what '+' could mean. It's logical. But it's getting in the way of an existing operation.
I'm not complaining about code *I* write. The point is that it lets other people write code that is slow to read and understand. Just because *I* would never use overloading that way doesn't mean I won't be affected by it when someone else does and I have to deal with their code.
I do agree about being allowed to write your own operators. It would be nice. And it gets around the overloading problem. (You know it's a made-up operator because it's using a syntax not in the original language.) The reason this hasn't been done is how incredebly hard it is to implement it. You need to tell the scanner of the compiler about the new operator so it can return it as a different kind of token from just plain 'identifier'. Consider your "y cat z" example. If "cat" is a user-defined method, then the scanner will return that code as just "identifier, identifier, identifier" - leaving the parser with no clue what to do with it. So for this idea to work, the parser has to be able to tell the scanner to make changes to itself partway through the run. As in, "Hey scanner - from now on when you see "cat" I want you to return that to me as a binary operator token." then y cat z would become "identifier binary_op identifier". And I haven't even really touched the issue of operator precedence.
These I think are still solvable problems, though, if someone was ambitious enough to work on them. (The operator definition would also need a way to define precedence - perhaps as a simple integer where the smaller the number the 'tighter' the precedence for that operator, and if two operators of equal precedence cause an ambiguity, then resort to left-to-right evaluation.)
One thing a game has to have before you can even consider PD is real consequential results from your actions. In the real world, if you just kill someone out in the street with witnesses and take his stuff, you're not going to get away with it, and your life as a free man will be pretty much over. Consequences like that have to exist in the MMORPG or PD isn't going to be fair. (Hey, let's go beat up on some newbies for a while...)
The problem with permanent death is that first the game engine has to be at *least* as fair as a compenent human gamemaster would be in a tabletop RPG. And that just isn't the case. When you can die because of bugs, or network lag times, and things like that, that's when permanent death just isn't fair. And if you think permanent death is somehow true-to-form for middle earth, NO it isn't. Gandalf was ressurected as The White. Sauron died by Isildur's hand - but no not really. And the author's hand was in there making sure none of the characters who needed to live for the plot ended up dying, even though there were many cases where they easily would have.
If Lord of the Rings had been an MMORPG with permanent death, then Frodo would have died from the wraith's wound before reaching Rivendell and the whole story would have ended right there. The "he almost died but barely pulled through" story element that happens a lot in Tolkien wouldn't work if a computer was calling the shots.
Uhh. Doesn't it normally go that way? Y'know, kinda from the sky to the ground?
Oh, my god! It's raining...vertically!!! RUN FOR SHELTER!
Re:Best way to survive tornadoes
on
Surviving Tornadoes
·
· Score: 2, Informative
But the area of potential tornados is a VAST area. Are you seriously suggesting that nobody should build anywhere in all of Oklahoma, Texas, Nebraska, etc?
Other than that, I agree with your sentiment. I felt the same way when the mississippi river flooded and wiped out all those farmers - tough luck. You built right next to a huge river that is known to flood every 50 years or so. You knew it was a flood plain because you liked the rich farming soil it provided - people told you the Misissippi river has one nasty flood like that once every 50 years or so. So tough. Live with it. Taking into account the fact that you might get flooded out one year should have been part of your risk assessment when deciding if the rich soil of a floodplain was worth it.
Since the F scale is measured only by damage done, how could you tell that an F5 had struck open prarie? The definition of F5 is based on the way in which buildings are damaged. If none were there to damage, how would you know whether it reached F5 or not?
Actually the way lawyers define it is, "lost opportunity." That is, they've lost the opportunity to have a sale take place.
So, if I wanted to buy a hot dog from a hot dog stand, but I was an idiot and forgot my wallet so I couldn't, have I just stolen a hot dog? After all, I caused the vendor to lose the opportunity to sell one to me that I would otherwise have bought.
Slashdot Mirror
Instead you're squeeing like a stuck pig.
What planet are you on where this is the case?
Uhm, this is Earth - you know the bluish-green one, third one out? Yeah, that one, right there.
Remember that SCO had a unix product before buying Caldera's linux distro. SCO's own unix was a Xenix-derivative. So SCO does have some unix code (quite a bit) that isn't covered by GPL. It could be *that* code that they are basing their lawsuit on.
He is talking about the internet as we know it now, a functional forerunner of the internet as far as the position it takes in a lot of people's daily lives.
I doubt it. His phrasing was such that he really did claim the internet didn't exist yet at the time. Had he known that this wasn't true, he could have phrased it differently There was no phrasing that indicated to me that he really meant internet *as we know it*. I'm more inclined to say he actually believed what he wrote literally.
Dumping is selling below your own cost. It has nothing to do with your competitor's cost. If it costs you $5 to make a widget, and you sell it for $1, you lose $4 on every sale. The reason this is illegal is that it is a tactic that only a large company making profits elsewhere can afford to try. A small company cannot try to do such a thing and remaing in existence for long because they don't make enough money elsewhere to cover for the loss. Thus a big company can drive a small one out of business by just choosing to operate at a loss for a while. Hopefully you understand what the danger is of allowing the situation where once a company becomes big it gets to stay that way purely by virtue of being big and nothing else.
But one thing that *is* allowed is to sell your product for less than your competitor when it actually costs you less than your competitor's product costs him. If you have a better means of producing widgets that really *does* cost only $1, then you can charge $1 for a widget perfectly legally, but your competitor cannot drop his price to $1 to compete with you if his cost is still up at $4. He has to ring the price down by reducing his own cost, not by selling at a loss.
Your analogy has nothing to do with the complaint. We aren't asking them to point out what was stolen so that we can give it back and forget the whole thing. We're asking for them to point it out becasue if they don't they have no proof a theft actually occurred. It's like claiming I took your car and parked in in my multi-level garage, without specifying where in the garage it is, when you had the keys to the garage the whole time, and my permission to go look around whenever you want, and you still won't point out where the alleged car you claim I put in my garage actually is.
Since SCO is a Microsoft Spinoff, indirectly microsoft moeny is behind this, even if SCO is doing it on it's own.
Then it would be a job I would not want and the fact that I was rejected would be a good thing in the long run. (Not that the issue of one bit of syntax matters that much, but the fact that my potential boss would be so petty as to hire or fire based on it would be a warning flag to me.)
The problem with standards is that most proponents don't admit that what they are doing is totally arbitrary. They get this holier-than-thou attitude that there is ONE right way based on what "normal" people would think, and how the other ways are "abnormal". I understand the need to conform to standards, but the more asinine the proponents are about it and the less they recognize the purely made-up arbitrary nature of them, the less willing I am to conform to them. If the standard proponent admits that a particular rule has no real rationale other than they chose to pick one way for consistency, then I'm a lot more willing to work within that rule.
++ predates object-oriented code. It dates back to original K&R C. I was using ++x back when object.method() was a compile-error.
You're assuming we see it as a problem.
I *like* the fact that booleans aren't artificially crippled version of an int in C and are instead just ints like they *really* are underneath. What I don't like is that the library of system routines aren't consistent with the meaning of booleans. (Most functions on man page 2 return zero for success, while most functions in stdlib return zero for failure, rendering this neat feature rather useless in practice because you always have to remember which way around the function you are using does it, and it might be the opposite of the handy boolean interpetation.)
If your compiler is inserting some kind of code for those "do nothing" parts, I would call that broken.
That's only if you view "put parentheses next to name" as an indicator of "this is a function". I don't. You only see it that way because that's the convention you are used to seeing. The convention I'm used to seeing is "put parentheses next to name" means "these parentheses are a required part of the syntax for this thing - hence they are directly attached to it." I think that makes more sense.
so, for example, if you choose to put parenthesis around the expression of a return statement, they don't go next to the return. They are not part of the syntax of return. They are part of the syntax of the expression, in that case:
return (foo);
means: return thingy; where in this case thingy is "(foo)".
Whereas:
while( foo )
means: while( thingy ), where thingy is "foo".
To me, this:
while ( foo )
would read as: while thingy, where thingy is "( foo )", which is of course not really what's happening.
I think having a default is useful because when you see the special case you immediately know that it's acting differently, that the code is dependent on increment/decrement order, and that there is probably a good reason why it was written that way.
That's not true though. The code could be just as dependant on increment order when it's written postfix as when it's written prefix. If you train yourself to only bother thinking about it when you see it one way and not the other, you are asking for trouble. You should be paying attention to it BOTH ways. In fact, I would argue that the cases where postfix is really needed are more unusual than the cases where prefix is really needed. The idea is very strange of the return value from an operation NOT being the result of the operation but instead the result before the operation was done.
That's not the way anything else in the language works. Imagine if you had a concatenation string function called concat(x,y) that tacks y on to the end of x. It would be very odd for that to return x as it looked before concatenation.
There's times when convention is wrong to me. And this is one. I see no reason to do "x++' unless there was some reason the person wanted to return the preincremented value, so that's the version that makes me stop and think about it, while you have the opposite reaction. Besides, I avoid '++' side-effects like the plague, so I'm usually using it on a line by itself (or as the last clause of a for(...) header), where you don't really care when the value is returned since you're just throwing the return value away anyway. And in the case where you are just throwing the return value away, it makes no sense to bother remembering what it used to be before the increment occurred.
But that wouldn't be the same as the object not
having mass.
Go re-read my post that caused you to argue with me in the first place. I never said there would be no wind - just that it can't be measured on the F-scale without stuff being damaged, and that's why we don't know the intensity of tornadoes that are too rural.
F is a measure of the size and wind speeds.
That's the GOAL, but in practice the only way they have to do it is to assess damage to objects with well-known properties. So while the goal of the F
scale is to get a range of guess for the windspeed the system USES property damage to make that guess. (It's like measuring mass in Kilograms by using a weight scale. Kilograms are NOT a measure of weight, but on earth there's a known one-to-one mapping between the two, so weight is typically used to arrive at a figure for mass. The F-scale does the same sort of thing, but in a more vague fasion.
If your only means of measuring mass was a scale, you wouldn't know what the mass of something in zero-G is. And if the only means of measuring windspeed is to look at damage to well-known manmade objects, and there aren't any around, you don't know what the windspeed was.
Frodo pulled through, beside his very mortal constitution, because of the application of what you might call magic.
Yes, but put it in terms of a computer game with hit points or some other such damage mechanism. To make Frodo's player really *feel* that notion that Frodo almost died, Frodo has to be down to scant hit points left. And then the difference between him dying and him living is a mere matter of typing speed and how on-the-ball the players of the elves at Rivendell are. "Oh, darn, I made a typo and that slowed me down enough that Frodo is dead. Darn Darn Darn! Oh, man I'm so sorry. Now who's
gonna be able to carry the evil artifact."
My point is that in a GAME, you can't really have too many near-death scenes before one becomes an actual-death scene. In a game with fair rules mechanics, you are just as likely to fail in a 50/50 situation as live. This is not really how novels like LOTR work. In a novel, you die if the author things it makes sense to happen there. Senseless, plot-setting-back deaths don't happen. But realisticly, they would.
I'm not saying a PK MMORPG can't work at all - but there's no way in hell it will be as grandiose a story as LOTR. To make your character likely to live, you would avoid the quests where the odds are heavily against you, like, oh, say, two low level newbie halflings walking to the heavily armed enemy-held zone and chucking the world's most powerful artifact into a volocano mere days march from the enemy's main stronghold.
As long as you follow the principle of least surprise
and don't overload the + operator to take square roots it's really not a problem.
please refer to my example. The problem comes when you overload an operator that already has a different meaning, confusing anyone reading the code who doesn't know about your overload. In my example, the operator '+' already meant pointer-offset arithmetic. I changed it to mean "numerical addition to the string interpeted as an int". It's a valid understanding of what '+' could mean. It's logical. But it's getting in the way of an existing operation.
I'm not complaining about code *I* write. The point is that it lets other people write code that is slow to read and understand. Just because *I* would never use overloading that way doesn't mean I won't be affected by it when someone else does and I have to deal with their code.
I do agree about being allowed to write your own operators. It would be nice. And it gets around the overloading problem. (You know it's a made-up operator because it's using a syntax not in the original language.) The reason this hasn't been done is how incredebly hard it is to implement it. You need to tell the scanner of the compiler about the new operator so it can return it as a different kind of token from just plain 'identifier'. Consider your "y cat z" example. If "cat" is a user-defined method, then the scanner will return that code as just "identifier, identifier, identifier" - leaving the parser with no clue what to do with it. So for this idea to work, the parser has to be able to tell the scanner to make changes to itself partway through the run. As in, "Hey scanner - from now on when you see "cat" I want you to return that to me as a binary operator token." then y cat z would become "identifier binary_op identifier". And I haven't even really touched the issue of operator precedence.
These I think are still solvable problems, though, if someone was ambitious enough to work on them. (The operator definition would also need a way to define precedence - perhaps as a simple integer where the smaller the number the 'tighter' the precedence for that operator, and if two operators of equal precedence cause an ambiguity, then resort to left-to-right evaluation.)
One thing a game has to have before you can even consider PD is real consequential results from your actions. In the real world, if you just kill someone out in the street with witnesses and take his stuff, you're not going to get away with it, and your life as a free man will be pretty much over. Consequences like that have to exist in the MMORPG or PD isn't going to be fair. (Hey, let's go beat up on some newbies for a while...)
The problem with permanent death is that first the game engine has to be at *least* as fair as a compenent human gamemaster would be in a tabletop RPG. And that just isn't the case. When you can die because of bugs, or network lag times, and things like that, that's when permanent death just isn't fair. And if you think permanent death is somehow true-to-form for middle earth, NO it isn't. Gandalf was ressurected as The White. Sauron died by Isildur's hand - but no not really. And the author's hand was in there making sure none of the characters who needed to live for the plot ended up dying, even though there were many cases where they easily would have.
If Lord of the Rings had been an MMORPG with permanent death, then Frodo would have died from the wraith's wound before reaching Rivendell and the whole story would have ended right there. The "he almost died but barely pulled through" story element that happens a lot in Tolkien wouldn't work if a computer was calling the shots.
Uhh. Doesn't it normally go that way? Y'know, kinda from the sky to the ground?
Oh, my god! It's raining...vertically!!! RUN FOR SHELTER!
But the area of potential tornados is a VAST area. Are you seriously suggesting that nobody should build anywhere in all of Oklahoma, Texas, Nebraska, etc?
Other than that, I agree with your sentiment. I felt the same way when the mississippi river flooded and wiped out all those farmers - tough luck. You built right next to a huge river that is known to flood every 50 years or so. You knew it was a flood plain because you liked the rich farming soil it provided - people told you the Misissippi river has one nasty flood like that once every 50 years or so. So tough. Live with it. Taking into account the fact that you might get flooded out one year should have been part of your risk assessment when deciding if the rich soil of a floodplain was worth it.
Since the F scale is measured only by damage done, how could you tell that an F5 had struck open prarie? The definition of F5 is based on the way in which buildings are damaged. If none were there to damage, how would you know whether it reached F5 or not?
Shouldn't "sex" be an .org? Or, perhaps multiple .orgs
Actually the way lawyers define it is, "lost opportunity." That is, they've lost the opportunity to have a sale take place.
So, if I wanted to buy a hot dog from a hot dog stand, but I was an idiot and forgot my wallet so I couldn't, have I just stolen a hot dog? After all, I caused the vendor to lose the opportunity to sell one to me that I would otherwise have bought.
What a stupid definition for "theft".