We were using a version of gcc no later than 2.95, and we started on Solaris 2.6 (moving to Solaris 8 as follow-on work, and so on).
Actually, I'm not even sure which version of gcc we _started_ with on the project I'm thinking of, it may have been 2.71...
(to related posts) I wouldn't be surprised if re-allocation was faster than locking/unlocking; we certainly saw cases at the speeds we needed where locking was entirely too expensive a bottleneck, including simply for string manipulation (which we'd already minimized as you would expect).
Actually, RogueWave's documentation was inconsistent with their own implementation, at least last time I checked.
The case that brought it to my attention was the map delete. There was supposed to be a version that returns an iterator to the position after the location you're deleting; however, while the documentation for RogueWave said it DID, the signature had a void return type (both in the code and in the signature within the documentation itself).
I'm not saying things haven't changed since then; they may well have. But at the time, that was a dead-end and obviously erroneous documentation.
String isn't threadsafe in Solaris either; I believe that's actually SGI's implementation.
It was lucky for us that we'd already been using ACE, since ACE's CString IS threadsafe.
ACE was great for threading -- Solaris doesn't support the r-w mutex (though POSIX on Solaris does), but we were better off once we set to working around that.
We had a nasty bug like that too -- the strange thing was that gcc was ok with the symbol name lengths when we compiled for debug, but something in our release build flags (the optimization level I think) would truncate the symbol names, which then caused naming conflicts, etc...quite a mess.
The tradeoff on binary size for code readability and maintainability (and execution time, of course) can be well worth it, IF you have the memory to spare. Our target machines rarely have less than 1GB of RAM, so it's not been an issue.
Pay attention to which operations are expensive for the various data structures (map vs. list vs. vector, etc.).
The fact that the operations' syntax for each of these is standardized is a double edged sword -- it makes for clean code and syntax, but it can mask poor-performing operations. Consider iterating over a map vs. over a list, for example.
So, consider carefully what operations you perform on various structures, and (of course), profile where/when appropriate. Looking at the actual implementation of the STL you choose can go a long way in revealing such troublespots, if that's an option (SGI's implementation is pretty easy to get ahold of).
In terms of usability, the STL is great. I've been told that it's not the be-all and end-all as far as performance goes, but it can handle most applications, even situations where there IS a performance requirement as long as it's not an especially stringent one.
We developed a call-routing application for Solaris in C++ using ACE and the STL, and were able to meet a fairly hefty performance goal.
The biggest downsides on the STL that we encountered were a few compile issues in terms of integrating ACE into the build (not a big deal), and the larger one of somewhat poor documentation of the STL itself. We used the MSDN STL documentation, and while Microsoft's implementation may agree with that API spec, Solaris' certainly didn't. See the signature of the map::delete method for an interesting example.
Both the Solaris (actually SGI) and RogueWave implemementations DO NOT match the documented interface, even though Rogue Wave's documentation says it does! So make sure your intended usage is actually supported by the implementation of the STL that you're using.
Isn't Barratry a crime, at least in some districts?
What we need is a properly-motivated DA in such a district -- they can track down people harassed by Scientology's sharks^H^H^H^H^H^Hlawyers, and bring barratry charges against them.
It might not do much more than "send a message", but I would think if done properly, and with accompanying civil suits (again, the trick is to find sufficient funding to take the Scientology teams on), people could start to put the hurt back on this cult.
The "real" problem, of course, is his company's attempt to obey the letter of the GPL but spitting in the face of its spirit. That sounds a bit dogmatic, I know.
It would be nice if he took a stand on the real issue, but I suspect then he'll have to choose between the ideal and his job. That's what I call a "sticky situation".
While the code MAY be obfuscated, you're still releasing it under the GPL.
And while it's true that it's "Almost" as useless as reverse-engineered bytecode, it's not necessarily. Someone with the patience and, say, economic motivation, could still retrieve your full codebase, and be perfectly within their rights to do anything with it, including compete directly against the company.
If you really want to stop this, that's a tack you could take -- try to convince management that there IS a security risk in releasing even the obfuscated code.
I don't see companies like Microsoft or Cisco releasing even obfuscated source to code they consider valuable.
Someone (several someones) at the LEAST violated the terms of their Beta Test agreement.
Granted, that's not "cracking", but (correct me if I'm wrong) many a warez release has begun under such circumstances, with authorized holders (testers, even employees) of software releasing them to unauthorized persons, wittingly or no.
I imagine the source driving BnetD is an interesting project in its own right.
However, if I was Blizzard, I would have offered the private deadicated (sic) server capability (closed-source for the stated reasons above) that Half-Life and Quake3 (and others, no doubt) used, to allow a secure "master authentication server".
I honestly don't see why they insist on providing their own servers, and ONLY their own servers, when they don't charge for the service (besides, given some of the security and stability pains they've endured, I'm not sure they could get away with charging). I mean, I doubt they'd recoup the costs in banner ads even 3 years ago...
Sure, it provides infrastructure for an official ladder and an official ranking -- but surely there's more to it than that.
I never said BnetD didn't have other, and far more legitimate, purposes.
I never said the "official" BnetD was being used for the WC3 Beta either -- though I can see where my post could be read that way.
It's rather sad that Blizzard is going after the official BnetD people, if in fact they had nothing to do with the WC3 aspects of it -- but, at the end of the day, I supposed Blizzard decided to attack the target that was visible, since the rest are probably rather anonymous.
Blizzard is ultimately doing the right thing in going after people cracking the Beta, IMHO.
I mean, ideally they ought to allow things like bnetd for their published games, since that reduced the load on their real battle.net servers, which I think most of us will agree is often more than they can handle.
Instead of citing security of their protection algorithms, I think they ought to be working WITH the bnetd people -- they need to find a way to allow copy protection while still allowing user-operated servers.
If they need a real example of a system that works, they need look no farther than Half-Life or Quake3 -- they can be played on LANs without authentication, but by and large, you need a licensed copy to play on the Internet.
Different judge, different plaintiff, different defendants...you never know. Funny how that seems to make all the difference in the US Justice System.
Seriously, though, I tend to agree with you. Nintendo's probably got a comparable amount of legal gorilla to bring, so the Flash Linker people would need to get a _very_ strong team and a better judge, and they'd still have their work cut out for them.
The toughest battles are usually the ones worth fighting though...
As far as I can tell, this is a good candidate for an interesting trial:
1) It CAN be used to copy games illegally. I don't think anyone will disagree.
2) It CAN be used to _legally_ copy games, or save data. Nintendo might try to disagree with this being legal, but I don't think they can convince anyone of that in a courtroom.
So, it has both uses that are legal, and those that infringe on copyright.
It's been awhile since I read the DMCA, so I'm not sure which particular provision selling this device is supposed to be violating. I'm guessing it's the sale/distribution of a copy-protection-circumvention device.
The hardware angle would be silly, so it must be that they claim copying their ROMs is the violation. Are GBA ROMs encrypted, or otherwise proof from copying beyond their storage on a chip in a funky plastic case?
Bottom line, I think these people could mount a fairly strong challenge to at least the lawsuit, and possibly take the route of the DMCA being unconstitutional: It's being used to make a _fair use_ under copyright -- space/time shifting of user data -- illegal.
Well the difference there is in the details. Rental agreements for physical space make no claims (implicit or explicit) of ownership of what's inside -- more for liability than courtesy (they don't want to be held liable for someone storing drugs or dead bodies, etc.).
You're not renting the data SPACE for an MMORPG -- you're paying for the right to access and control a very limited subset of interrelated data. Mythic explicitly retains the right of final authority over that data in the EULA, as well they should.
What you're talking about is more like the Yahoo briefcase accounts, or webhosting, or things like that. There, again, the agreements are very specific about who retains ownership of online material, etc. -- for example, when you post something on a message forum, you generally lose all "rights" to the ideas and other forms of potentially valuable input. At least, they claim so, I'm not sure if THAT would stand up in court or not either.
The example I'm thinking of is a gaming forum -- they generally state right out front that if you post a new idea, they have the right to use it without recognizing or compensating you (the nice guys do anyway, of course).
Well, the difference there is purchase of property vs. permission to use a service. DAoC players, at most, have a claim of ownership of the _client_ software.
I think it's a stretch to claim ownership of data you've -- altered. You can't even claim to have created the data by earning items/currency in game -- you've only altered the data state of the account, which is provided by and belongs to Mythic -- you just pay for _access_ to said account (at least, that's how I'd word the EULA -- I'm not sure if Mythic did so or not).
So manipulating that data in a way that's explicitly disallowed is a violation of the terms of access to that account; thus you can have your access revoked.
I guess the hinge question is, "Does the player OWN the account, or is he simply paying for access to it and buying/receiving the software to manipulate it?"
There is nothing to "own". It's all data and software owned by Mythic. Heck, even the client belongs to Mythic, by the strictest definitions of the EULA (granted, that won't necessarily stick if push came to shove). At a minimum, the server side data -- the state of the accounts -- belongs to Mythic. They store it, they provide the access and bandwidth and hardware to manage and alter it.
A player claiming to "OWN" the currency or items, to the extent that THEY should be able to dictate what is done with them, has a flaw in their logic.
Look at a real world example: Arcades. If you play a few hours, invest tons of _real_ cash, and earn a million tokens, what can you do with them? You can trade them in, _according to the rules and conversion rates specified by the arcade_. Technically, even taking them off the premises is THEFT -- you don't earn the tokens, they're just a form of representation of the "winnings" you've obtained through one of the allowed systems of the arcade -- a game of luck, skill, or both. Those tokens belong to the arcade, subject to the rules they establish.
Now, do people pool them inside the arcade to get a bigger prize? Sure. That's allowed, at least implicitly. Are you _allowed_ to take them home and build up a larger stockpile? NO. Do people do it anyway? Yes.
But does that mean the arcade visitors have a "Right" to take those tokens from the arcade, and sell them for real cash to other people? No way. The rules explicitly disallow it, and the tokens remain the property of the arcade throughout. The data on Mythic's servers is less tangible, but NO less their property.
Regardless of the way BSI thinks things "should" be, there are a few very simple facts:
1) To play the game, you have to abide by the EULA.
2) The EULA specifically DISALLOWS sales of items and currency, but (at the time of writing) allows the sale of ACCOUNTS in an "as-is" fashion -- specifically, that Mythic is not responsible if such a deal goes sour, etc. If you ebay your account and the buyer gets the account banned, don't be surprised if they hold the SELLER responsible as well, etc.
Since these provisions are spelled out in the EULA, I see no merit to this lawsuit. EQ, UO, etc. were gray areas because the original agreements don't discuss out-of-band commerce relating to the game. Mythic's EULA for DAoC DOES, and that makes their position all but impregnable.
They can legitimately say that the rules are in place to preserve the physical security of the game, and to preserve the enjoyment of the player base -- something that has DIRECT economic value to the owners of the game.
The players have NO right to break those rules or work outside of them; they're both paying to play, and agreeing to abide by the set provisions of the game when they do so. If they're not happy, they can save themselves 10 bucks a month and play elsewhere.
Bottom line, it's in Mythic's best interest as the owners and providers of DAoC to not allow the sale of items and currency -- they probably shouldn't even allow the sale of accounts, in fact. It's just like a bar or nightclub -- you can pay to get in, but if you try to grope the women or sneak your friends in, you should expect to get kicked out and black-listed.
The nightclub doesn't tolerate such behavior when it's expressly forbidden, and shouldn't be required to by any means. The same applies to Dark Age of Camelot and Mythic.
Re:Trillian Rocks and AOL can go suck eggs
on
AOL vs. Trillian
·
· Score: 1
Has there been ANY significant development effort on ICQ since AOL bought it? I guess they upgraded it to where it serves ads now, but that's the only change I've noticed.
I get this feeling that AOL bought ICQ in hopes of letting it fester and die, and moving the user-base over to AIM.
Random data is rarely the worst case for a compression scheme. Truly random data of sufficient size will probably bring the compressor to its knees (yielding 1:1 or worse compression). BUT, if you know the compressor's algorithm, you can design a data set to be compressed that will yield compression results at least as bad as random data would.
Slashdot Mirror
We were using a version of gcc no later than 2.95, and we started on Solaris 2.6 (moving to Solaris 8 as follow-on work, and so on).
Actually, I'm not even sure which version of gcc we _started_ with on the project I'm thinking of, it may have been 2.71...
(to related posts) I wouldn't be surprised if re-allocation was faster than locking/unlocking; we certainly saw cases at the speeds we needed where locking was entirely too expensive a bottleneck, including simply for string manipulation (which we'd already minimized as you would expect).
Xentax
Actually, RogueWave's documentation was inconsistent with their own implementation, at least last time I checked.
The case that brought it to my attention was the map delete. There was supposed to be a version that returns an iterator to the position after the location you're deleting; however, while the documentation for RogueWave said it DID, the signature had a void return type (both in the code and in the signature within the documentation itself).
I'm not saying things haven't changed since then; they may well have. But at the time, that was a dead-end and obviously erroneous documentation.
Xentax
String isn't threadsafe in Solaris either; I believe that's actually SGI's implementation.
It was lucky for us that we'd already been using ACE, since ACE's CString IS threadsafe.
ACE was great for threading -- Solaris doesn't support the r-w mutex (though POSIX on Solaris does), but we were better off once we set to working around that.
Xentax
We had a nasty bug like that too -- the strange thing was that gcc was ok with the symbol name lengths when we compiled for debug, but something in our release build flags (the optimization level I think) would truncate the symbol names, which then caused naming conflicts, etc...quite a mess.
Xentax
The tradeoff on binary size for code readability and maintainability (and execution time, of course) can be well worth it, IF you have the memory to spare. Our target machines rarely have less than 1GB of RAM, so it's not been an issue.
Oh, one other thing:
Pay attention to which operations are expensive for the various data structures (map vs. list vs. vector, etc.).
The fact that the operations' syntax for each of these is standardized is a double edged sword -- it makes for clean code and syntax, but it can mask poor-performing operations. Consider iterating over a map vs. over a list, for example.
So, consider carefully what operations you perform on various structures, and (of course), profile where/when appropriate. Looking at the actual implementation of the STL you choose can go a long way in revealing such troublespots, if that's an option (SGI's implementation is pretty easy to get ahold of).
Xentax
In terms of usability, the STL is great. I've been told that it's not the be-all and end-all as far as performance goes, but it can handle most applications, even situations where there IS a performance requirement as long as it's not an especially stringent one.
We developed a call-routing application for Solaris in C++ using ACE and the STL, and were able to meet a fairly hefty performance goal.
The biggest downsides on the STL that we encountered were a few compile issues in terms of integrating ACE into the build (not a big deal), and the larger one of somewhat poor documentation of the STL itself. We used the MSDN STL documentation, and while Microsoft's implementation may agree with that API spec, Solaris' certainly didn't. See the signature of the map::delete method for an interesting example.
Both the Solaris (actually SGI) and RogueWave implemementations DO NOT match the documented interface, even though Rogue Wave's documentation says it does! So make sure your intended usage is actually supported by the implementation of the STL that you're using.
Xentax
I think Nelson nicely summarizes my reaction to this news: Haha!
Xentax
Isn't Barratry a crime, at least in some districts?
What we need is a properly-motivated DA in such a district -- they can track down people harassed by Scientology's sharks^H^H^H^H^H^Hlawyers, and bring barratry charges against them.
It might not do much more than "send a message", but I would think if done properly, and with accompanying civil suits (again, the trick is to find sufficient funding to take the Scientology teams on), people could start to put the hurt back on this cult.
Xentax
Precisely. TANSTAAFL.
The "real" problem, of course, is his company's attempt to obey the letter of the GPL but spitting in the face of its spirit. That sounds a bit dogmatic, I know.
It would be nice if he took a stand on the real issue, but I suspect then he'll have to choose between the ideal and his job. That's what I call a "sticky situation".
Xentax
While the code MAY be obfuscated, you're still releasing it under the GPL.
And while it's true that it's "Almost" as useless as reverse-engineered bytecode, it's not necessarily. Someone with the patience and, say, economic motivation, could still retrieve your full codebase, and be perfectly within their rights to do anything with it, including compete directly against the company.
If you really want to stop this, that's a tack you could take -- try to convince management that there IS a security risk in releasing even the obfuscated code.
I don't see companies like Microsoft or Cisco releasing even obfuscated source to code they consider valuable.
Xentax
Someone (several someones) at the LEAST violated the terms of their Beta Test agreement.
Granted, that's not "cracking", but (correct me if I'm wrong) many a warez release has begun under such circumstances, with authorized holders (testers, even employees) of software releasing them to unauthorized persons, wittingly or no.
Xentax
Yeah, that's the problem.
I imagine the source driving BnetD is an interesting project in its own right.
However, if I was Blizzard, I would have offered the private deadicated (sic) server capability (closed-source for the stated reasons above) that Half-Life and Quake3 (and others, no doubt) used, to allow a secure "master authentication server".
I honestly don't see why they insist on providing their own servers, and ONLY their own servers, when they don't charge for the service (besides, given some of the security and stability pains they've endured, I'm not sure they could get away with charging). I mean, I doubt they'd recoup the costs in banner ads even 3 years ago...
Sure, it provides infrastructure for an official ladder and an official ranking -- but surely there's more to it than that.
Xentax
I never said BnetD didn't have other, and far more legitimate, purposes.
I never said the "official" BnetD was being used for the WC3 Beta either -- though I can see where my post could be read that way.
It's rather sad that Blizzard is going after the official BnetD people, if in fact they had nothing to do with the WC3 aspects of it -- but, at the end of the day, I supposed Blizzard decided to attack the target that was visible, since the rest are probably rather anonymous.
Xentax
Blizzard is ultimately doing the right thing in going after people cracking the Beta, IMHO.
I mean, ideally they ought to allow things like bnetd for their published games, since that reduced the load on their real battle.net servers, which I think most of us will agree is often more than they can handle.
Instead of citing security of their protection algorithms, I think they ought to be working WITH the bnetd people -- they need to find a way to allow copy protection while still allowing user-operated servers.
If they need a real example of a system that works, they need look no farther than Half-Life or Quake3 -- they can be played on LANs without authentication, but by and large, you need a licensed copy to play on the Internet.
Xentax
Hmm. I was trying to decide if there was a legitimate way to disallow amateur development of software for the GBA, and I can't think of one.
So, I agree.
Xentax
Different judge, different plaintiff, different defendants...you never know. Funny how that seems to make all the difference in the US Justice System.
Seriously, though, I tend to agree with you. Nintendo's probably got a comparable amount of legal gorilla to bring, so the Flash Linker people would need to get a _very_ strong team and a better judge, and they'd still have their work cut out for them.
The toughest battles are usually the ones worth fighting though...
Xentax
As far as I can tell, this is a good candidate for an interesting trial:
1) It CAN be used to copy games illegally. I don't think anyone will disagree.
2) It CAN be used to _legally_ copy games, or save data. Nintendo might try to disagree with this being legal, but I don't think they can convince anyone of that in a courtroom.
So, it has both uses that are legal, and those that infringe on copyright.
It's been awhile since I read the DMCA, so I'm not sure which particular provision selling this device is supposed to be violating. I'm guessing it's the sale/distribution of a copy-protection-circumvention device.
The hardware angle would be silly, so it must be that they claim copying their ROMs is the violation. Are GBA ROMs encrypted, or otherwise proof from copying beyond their storage on a chip in a funky plastic case?
Bottom line, I think these people could mount a fairly strong challenge to at least the lawsuit, and possibly take the route of the DMCA being unconstitutional: It's being used to make a _fair use_ under copyright -- space/time shifting of user data -- illegal.
Xentax
I bet this (the parent) gets modded to flame-bait or trolling, but I have to agree.
Not all that long ago, I often saw news on Slashdot before any of the "mainstream" news entities online. Lately, it's been the other way around.
Xentax
Well the difference there is in the details. Rental agreements for physical space make no claims (implicit or explicit) of ownership of what's inside -- more for liability than courtesy (they don't want to be held liable for someone storing drugs or dead bodies, etc.).
You're not renting the data SPACE for an MMORPG -- you're paying for the right to access and control a very limited subset of interrelated data. Mythic explicitly retains the right of final authority over that data in the EULA, as well they should.
What you're talking about is more like the Yahoo briefcase accounts, or webhosting, or things like that. There, again, the agreements are very specific about who retains ownership of online material, etc. -- for example, when you post something on a message forum, you generally lose all "rights" to the ideas and other forms of potentially valuable input. At least, they claim so, I'm not sure if THAT would stand up in court or not either.
The example I'm thinking of is a gaming forum -- they generally state right out front that if you post a new idea, they have the right to use it without recognizing or compensating you (the nice guys do anyway, of course).
Xentax
Well, the difference there is purchase of property vs. permission to use a service. DAoC players, at most, have a claim of ownership of the _client_ software.
I think it's a stretch to claim ownership of data you've -- altered. You can't even claim to have created the data by earning items/currency in game -- you've only altered the data state of the account, which is provided by and belongs to Mythic -- you just pay for _access_ to said account (at least, that's how I'd word the EULA -- I'm not sure if Mythic did so or not).
So manipulating that data in a way that's explicitly disallowed is a violation of the terms of access to that account; thus you can have your access revoked.
I guess the hinge question is, "Does the player OWN the account, or is he simply paying for access to it and buying/receiving the software to manipulate it?"
There is nothing to "own". It's all data and software owned by Mythic. Heck, even the client belongs to Mythic, by the strictest definitions of the EULA (granted, that won't necessarily stick if push came to shove). At a minimum, the server side data -- the state of the accounts -- belongs to Mythic. They store it, they provide the access and bandwidth and hardware to manage and alter it.
A player claiming to "OWN" the currency or items, to the extent that THEY should be able to dictate what is done with them, has a flaw in their logic.
Look at a real world example: Arcades. If you play a few hours, invest tons of _real_ cash, and earn a million tokens, what can you do with them? You can trade them in, _according to the rules and conversion rates specified by the arcade_. Technically, even taking them off the premises is THEFT -- you don't earn the tokens, they're just a form of representation of the "winnings" you've obtained through one of the allowed systems of the arcade -- a game of luck, skill, or both. Those tokens belong to the arcade, subject to the rules they establish.
Now, do people pool them inside the arcade to get a bigger prize? Sure. That's allowed, at least implicitly. Are you _allowed_ to take them home and build up a larger stockpile? NO. Do people do it anyway? Yes.
But does that mean the arcade visitors have a "Right" to take those tokens from the arcade, and sell them for real cash to other people? No way. The rules explicitly disallow it, and the tokens remain the property of the arcade throughout. The data on Mythic's servers is less tangible, but NO less their property.
At least, that's the way I look at it.
Xentax
Regardless of the way BSI thinks things "should" be, there are a few very simple facts:
1) To play the game, you have to abide by the EULA.
2) The EULA specifically DISALLOWS sales of items and currency, but (at the time of writing) allows the sale of ACCOUNTS in an "as-is" fashion -- specifically, that Mythic is not responsible if such a deal goes sour, etc. If you ebay your account and the buyer gets the account banned, don't be surprised if they hold the SELLER responsible as well, etc.
Since these provisions are spelled out in the EULA, I see no merit to this lawsuit. EQ, UO, etc. were gray areas because the original agreements don't discuss out-of-band commerce relating to the game. Mythic's EULA for DAoC DOES, and that makes their position all but impregnable.
They can legitimately say that the rules are in place to preserve the physical security of the game, and to preserve the enjoyment of the player base -- something that has DIRECT economic value to the owners of the game.
The players have NO right to break those rules or work outside of them; they're both paying to play, and agreeing to abide by the set provisions of the game when they do so. If they're not happy, they can save themselves 10 bucks a month and play elsewhere.
Bottom line, it's in Mythic's best interest as the owners and providers of DAoC to not allow the sale of items and currency -- they probably shouldn't even allow the sale of accounts, in fact. It's just like a bar or nightclub -- you can pay to get in, but if you try to grope the women or sneak your friends in, you should expect to get kicked out and black-listed.
The nightclub doesn't tolerate such behavior when it's expressly forbidden, and shouldn't be required to by any means. The same applies to Dark Age of Camelot and Mythic.
Has there been ANY significant development effort on ICQ since AOL bought it? I guess they upgraded it to where it serves ads now, but that's the only change I've noticed.
I get this feeling that AOL bought ICQ in hopes of letting it fester and die, and moving the user-base over to AIM.
Xentax
Wow, talk about misinformed.
Random data is rarely the worst case for a compression scheme. Truly random data of sufficient size will probably bring the compressor to its knees (yielding 1:1 or worse compression). BUT, if you know the compressor's algorithm, you can design a data set to be compressed that will yield compression results at least as bad as random data would.
Xentax