This is my favorite gripe with C++, so I agree with you that is seems silly and redundant.
However, you could get close to the Java way by just writing the class out like in Java in a C++ header file. We have to ask ourselves the question: Won't don't C++ programmers do this? Force of habit? Compile times? Group pressure? Or is it, after all, better this way?
Another thought: Nothing would prevents header file being automatically generated from source files, though a few extra comments would be neccessary like/*+ public: */ and/*+ virtual*/ Why has this not been done? Don't tell me nobody thought of it:)
Well, nm is from binutils. It's certainly not gcc only --- it can read various object file formats. Anyway, surely you are only interested in those that your linker, ld, can actually read.
It is true that nm is faithful to the object code, in that "private" artifacts and type info in C (C++ has them, as you suspect, encoded into the name, much like Java) are listed. This reflect the fact that nothing prevents you from modifying a header file to use a private artifact --- it's a compiler thing, not a linker. I'm not famliar enough with Java to know if accessibility is enforced down at the runtime level. It seems a counter-constructive thing to do, but maybe there is something about Java that forces this to be so.
However, my point was that even with private/public adoration, the API you get is rather useless. It's very well to know that a constructor for a rectangle takes for doubles as input, but would that be lower left corner, height and width? Does the class require that the height and width (parameters) to be positive? How about 0, is that ok? If I copy a rectangle, would that be a deep or shallow copy? Is the constructor thread-safe?
All this is usually documented in comments in the code --- doxygen or javadoc. And there you get the full API for free anyway, with clickable links and everything. What's the point in jerking around with object/bytecode when you have this?
Nothing prevents you from doing so in C++ --- try man nm.
However, the interface you get this way is not very well documented --- in Java or C++. For this reason, most people doing C++ (and Java) uses comments in the source files, which are then transformed into documentation by doxygen and similar programs (like javadoc).
But unless you define a term "key size" to mean "the entropy of a sequence of randomized keys" the second paragraph is just meaningless, if I was to be in nitpicking mode.
But now I tire of this discussion. Thanks for your part...
You said you were a mathematician, and I'm not much of a crypto guy either, though I am confident about what I posted. I'd recommend going to the source and getting the full math treatment.
Sigh. What you wrote is essentially meaningless --- at least I can't see how to generalize the definition of a bit. A bit is a (state) variable with two possible values. I don't know if you could possible make this an dimension in an outcome(?) space, then approximate the dimension the way the fractals guys do (which I think is nonsense, and seems to have fallen out of favor, but hey) and thus arrive at fractional bits. I'm sure the result would be very different from what you imagine in any case.
And it is not just my lack of capacity to understand weird things. But you cannot represent 26 different states with 4.7 bits --- it's nonsense. You need 5 bits. That's the long and short of it. Now, I understand what you mean. You are saying that the strength of a key is defined as the number of states it can hold, and thus a key of 5 bits has a strength of 32, whereas an key containing 1 letter would have a strength of 26, the way I put it earlier. And certainly, I could have defined the strength of a key
as the log_2 of this number, arriving at your 4.7 number. That is why I said I was nitpicking. I think this is where you have been confused, though it is hardly catastrophic.
There is a dichotomy between the level of math I am talking about and level you were. I was talking mostly pure math and saying it may or may not apply practically, you're starting practically and trying to argue up to the math. If you're a mathematician, you should know how good that idea is:-)
I am a mathmatician, you can search for my master thesis if you want --- though it is in danish, so I doubt you would understand any of it. It is on the subject of approximation of topological spaces (using normal coverings). A "dichotomy", indeed;-) Separating mathematics from reality is one thing, but separating it from reason is quite another! If you want fractional bits, you need a definition, and a definition that makes some sort of sense. At the very least, the definition should imply the current definition for integer numbers.
Snipping a lot of trivia...
I'm sure that modern encryption has been scrutinized for this sort of weakness, but even so, it's the kind of thing that ought to be instinctively repulsive mathematically; when you composite two encryption forms together you are basically creating a new one, with unknown characteristics. Any monster can pop out of the folds of math-space and bite you. Better to stick with what we mostly know about.
I don't know about repulsive, but you hit the nail on the head with the new alghorithm thing.
Also, fractional bits pop up all the time in info theory and encryption (a branch of info theory). One example of a fractional bit, though not related to encryption so much as error correction, is a value that you know is either one or zero, but you only know it is a one with 90% confidence. That isn't a full bit, but neither is it zero bits. Happens all the time. In fact, technically, in the real world we never deal with bits, as we can never be 100% certain. Inside your processor it is so close to 100% as to make no difference, but as you get out into the world the uncertainties can reach our threshold of conciousness, and fractional bits is the most natural way to work with error correction situations.
You are, I assume, referring to "fuzzy logic" here. Now, such a state variable is usually defined as a real number between 0 and 1, and so the value of the such a bit might be 0.7, or whatever. You could even say that the average number of bits with a value about something is 23.3, but then we are talking about an average number of bits, which is a quite different beast than the number of bits.
Sorry for nitpicking, but the above statement is rather silly, unless you can think up a way of generalizing the definition of a bit to include rational numbers;-)
As we both know, this is toally besides the point:) The point of course, was that by more bits we don't mean shifting the original letters more, we mean shifting the letters in more ways. Eh. Approximately.
Well, I'll try to explain why people think what you are proposing is suboptimal.
Firstly, I think you have misunderstood what "adding extra bits" (enlarging the key) means --- at least in this context. In my (silly) example, the key had the length of 1 (number). Notice there is no bits, since the atomic unit in this encryption unit is letters. If you increase the number of bits we would have more numbers.. E.g, (1,2) would make "have" into "icwg", which would be harder to break. The scheme is actually not THAT bad --- there are methods to break this sort of encryption, but it isn't trivial. A person that has not studied cryptography would be pressed to break something like this, at least if the key length is unknown.
If you take this method to an extreme with keys longer than the text, you would have a fair encryption method, provided that the keys are kept secret. But nevermind that.
Now, to invent another cryptographic method, let's consider a method where the positions in the alfabet are multiplied rather than added, and the modulo of 26 is taken. So for the example key (1,2) and the word "have" the result would be "hbvj".
How secure are these methods combined? Well, if the coded and original letters have position x and y, respectively, and we are using keys k,l with values k_1, k_2,..., k_n and l_1, l_2,..., l_m, where n and m are some integral numbers. Then the effort spend on encrypting the message is O(n+m). The effort spend decrypting then will only be proportional to the smallest common multiple of n and m --- it's an easy proof, so I leave it as an exercise. However, for the same effort you could have obtained and effort proportional to the multiplum... and the encryption and decryption rutines would be simpler, and thus less errorprone. That's one argument against layering encryption algorithms.
Now, either of these algorithms may be weak --- indeed, the muliplum algorithm is for a number of reasons, most importantly the distribution of the resulting letters is not uniform. Note that if the addition is performed first, no harm is done by this, but if the multiplication is performed second, the distribution would be skewed in such a way that the addition key could be guessed from the distribution of the letters of the encoded message. This would render the combined algorithm weaker then the addition alone. This is the "real world" example you asked for... and admit it, it is not that far-fetched for a slashdot comment;-)
Disclaimer: I'm not really a crypto guy, just an IT specialist + mathematician.
But who knows if the combined algorithm has a flaw that neither algorithm had, separated?
As for simple layering the same protocol, consider this (silly example): Exchanging each letter with the letter n positions futher along the alphabet does not get more secure by being done multiple times.
The same holds true for 3DES and every asymetric encryption method I have seen.
Well, I'll be rolled in tomato source. Thanks! I never knew --- it's even made it's way to linux:) At least "man strlcpy" fetched a likely looking manpage, if nowhere as nice as the BSD one you linked.
The problem is that people forget to append that stupid 0 termination... and with long strings strncpy tends to fill buffers up with useless 0'es. I always code my own (it's only three lines) and use that. Safe, and efficient. strn?cpy should be deprecated, and replaced with stringcpy, which does the right thing and fillfield() which does with strncpy does.
Instead of shooting the poor programmers, including a "grep strcpy checkinfile; if [ $? != 0]; then send_evil_mail; fi" in the cvs checkin scripts is probably more effective. Works for KDE people, at least (not that that KDE would have problems with strcpy, obviously, but that kind of thing.)
While I agree with the sentinent, I cannot but hasten to warn that strncpy is evil, and it should almost never be used. Why? It doesn't zero-terminate, so it might turn a C-string into a non-C-String, with hilarious results.
I assume several C-String libraries must have been designed and built over the years. But I none seems to have prevailed for whatever reason. Which is a bloody shame, because C's string (mis)-handling are a trategy, so messy and unclean in such a nice & clean language. I wonder why?
(And yes, I'm perfectly aware why strncpy does what it does, I just wish they had called it fillrecord or something sensible instead.
Anandtech is just one tester. Against that we have 100 of dualbooting linuxusers, who with identical hardware got wildly different results. Perhaps Anandtech has a more optimized windows platform than their linux counterpart? Were they running updatedb while testing? Video capture? Any other background daemon? BTW, I don't trust Anandtech's tests. Too often, their results are inconsistent with other testers, and often their results are just insane.
Anyway, even if that is the case, UT2004, Thinktanks, dominions2, hardball, Majesty and other games do not have this tendency at all. Some even report superior framerates running window applications under wine, which makes no sense. Again, I think they must be running some background proccesses under windows without their awareness.
I think we differ because ultra low level mulitplatform is inherently much more difficult than when we hit the C++-level. If the platform differences are down to different system libraries, coding multiplatform is not that hard. I should know, I code multiplatform every day. Most of our trouble comes from libraries which uses unsigned char instead of char (yes, we have an important platform with signed chars). And porting to windows is always an experience, but again, it is not that hard.
Finally, to be clear, I believe the game publishers and developers have a perfect right to be (stupidly in my opion, but whatever) developing for a single platform (often single platform multiple times, because the games are ported to XBox/PS2). It just that I won't be buying them, which was my point, and a wine hack doesn't cut it with me. That, and stating that if I would do a game, I would buy/steal an engine (like the linked one) and do it from there, keeping the code running on as many platforms as I could get my dirty hands on. That is all, and I hope that you can understand this viewpoint as well. I have no shortages of games, BTW --- just shortage of time to play them. I still havn't played Doom3 very far, e.g.
Re speed: Multiplatform means either little or nothing, depending on whether you do it dynamically or statically. At least, that is my experience. It may be different in the graphics area, but then, UT2004 and other games seems to disagree. Re testing: Porting catches more bugs than your would ever dream, so in a way porting reduces the need for testing. Of course, for each supported platform, you need some testing, but as each platform also brings some customers, there should be a valid business case for this.
As for Doom3 speed: The number you quote is bogus. The dual booters (can't get fairer than that) seems to get very different results, with Linux outperforming windows as often as the other way around. From what I hear, it seems to be soundrelated, so maybe the sound chipset means more than anything else. *shrug*
I won't comment on the other games... the windows ones I never play. Nor am I qualified for commenting on the directx vs. opengl, but then, the engine I linked seems to be able to use both with little trouble.
So in conclusion, I believe that making mulitplatform game is exactly as easy as I think. And if you doubt me, look for all the games that are released on ps2, xbox and windosw simultanously. Look harder for games that are release for windows, mac and linux concurrently --- many small game developers manages it. Which again suggests that it is not that hard
You mean like Doom3, UT2004 etc. scales over a largish hardware range, dropping advanced features as needed? Why, the same way.
To be specific, I would take an open-source engine (e.g this one ) and port it to the mentioned platforms. Then I would allow effects to be switched on and off (use stencil shadows or just blobs? Viewing distance?) and use the good old trick of having two (or three) detail levels used at different distances. And so on.
Java is another possibility, though I must admit, I don't know about Java and PS2 --- but when a JVM exists for Z/OS, everything is possible.
As I said, it is not that hard And as I said, I don't buy games that are not natively running on Linux.
My hardware friends tells me that this is becoming increasingly not true. Custom chips are being replaced with reprogrammable chips instead, essentially moving hardware->software, except for making those chips.
It's not the paying I mind. It's the fact that it seldom works, and never perfectly. This is my experience with Civ III, which is an officially supported game, plus a host of other non-supported games.
No, if game developers want my money, it's the Linux way. I, myself, develop software, which I rutinely run on Z/OS, Linux and windows. It is not that hard! In fact, if I were developing games, I would do it hardware indepently enough that porting to PS2, gamecube, xbox and windows would be no problem --- and keep the developing on the greatest development platform I have ever had the pleasure to use.
I always believed it was the sentence I quoted, and that the other part was just to separate that right from the distribution. So anybody may run it, but if you want to distribute, read on sort-of-thing.
Otherwise, I can't see how it is legal to run GNU software in most parts of the world --- I believe the law text typically say something like "only the copyright holder may produce any copy, temporary or otherwise". As running an application means copying into RAM... but hey, I'm no expert in this.
It even makes sort of sense... copyright doesn't restrict usage (anyone may view a copyrighted painting...), and I doubt that distributing the warez as running programs on RAM chips would make it legal...
I'm no expert in other package systems, so I really don't know, but if all else fail a simply chroot'ed install-script would do the trick. Not hard at all, I just do not think that the demand is there.
As for hardcoded path-names... These are relatively rare, in my experience. I run all the handcompiled software (all of KDE, e.g.) off my home directory, with some globally installed extra stuff, with no problems. And again, if all else fail, chroot is the bigger hammer that always work, though the work would be slightly larger.
But it does require some minimal effort, which is of course my entire point, such as it is:)
What about the rest of my rights, the ones not related to copying? What about my right to modify the software (for my personal use only)? What about my right to use the software any time I want, internet connection or not?
I think that would depend on the country in which you live. I wouldn't count on having any of those rights, but you might. Check your local laws.
The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program).
And that's your license to run GPL'ed software --- at least in Europe, I don't know (anymore) about the US, as I can't say who the "owner" would be.
PS: In case you doubt it, I totally agree that software running on my own hardware should be mine to do with as I please. The laws are just not made that way, and I am very happy that GPL'ed software makes this possible anyway for a subset of software.
I also believe that this is only the first step. The next thing will be games run exclusively as an online service, streaming the game data directly to you, with most of the software and game data running on some server. Or something like that. It simply requires a faster internet --- about 20Mbit or so, I'd think. Not too far away... and we can thank all that to thieving pirates:-( May they burn in a hell of their own choosing for that:-(
PPS: I actually "own" a game who validates it's key against a server when you connect to an online game. *shrug* The game company in this case is just two guys, who seem to be nice folks.
Well, do it then. Change the paths in ~/.bashrc and setup ld (or just use LD_LIBRARY_PATH), then read from the relevant package manager how to install locally. E.g, in Gentoo, it's an environment variable ROOT=$HOME. For extra points, make a sandbox, but it's not really neccessary. Wish granted. That wasn't hard, was it?:o)
I'm sure that this would be default or even more easily configurable if anyone wanted to shoulder the task of maintaining it --- which should be an easy task. The hardest part will be reading info ld, and the a spot of testing. So let me guess: The number of people of wants to do this is
Bzz yourself. Ok, so the law was changed in the US, maybe this year --- I didn't dig, the US doesn't matter to me.. I would be surprised, though, if you were allowed to run unlicensed copies, and I think the devil is in the bit about "owner of a copy of a computer program". I couldn't see the definition what an owner of a copy is, though, so I don't know.
Anyway, that law is simply badly made. E.g, this law seems to suggest that if I buy a computer program, I cannot install it on my computer and have my employee use it, unless I load up (!) It would seem that European lawmakers have not patented badly made laws after all:-/
No, I purchased (gave money for) a CD that included the game on it. I was not informed of any other conditions on the usage of that piece of pressed plastic until after the sale was over, and I was no longer permitted to refuse the agreement.
Unfortunately, that is not how it works --- not in the US, and not in Europe, though the laws are slightly different. You are, of course, free to do what you want to with the plasitc --- but the game itself is copyrighted. That means that it cannot be freely copied, unless you have a license to copy it. In order to run the game, you have to copy it (from disk to RAM). The law is crystal clear about this in the US, and while not so in Europe, the rulings are. Or maybe it is the other way around. And licenses, unlike contracts, can apparantly be simply displayed and you can "take it or leave it". You wonder why mr. Stallman says he despises copyrights? This is why. Join the club, if you please, but this is how all licenses work, including the GPL.
WebDAV is not bad, and well supported by both Linux and Windows. Can run atop of SSL, which makes it secure enough for most purposes.
The downside is, of course, that the server(s) must run a WebDAV capable web server (read: Apache), and I have not seen a way to map window drives to WebDAV(s)(s).
Slashdot Mirror
This is my favorite gripe with C++, so I agree with you that is seems silly and redundant.
However, you could get close to the Java way by just writing the class out like in Java in a C++ header file. We have to ask ourselves the question: Won't don't C++ programmers do this? Force of habit? Compile times? Group pressure? Or is it, after all, better this way?
Another thought: Nothing would prevents header file being automatically generated from source files, though a few extra comments would be neccessary like /*+ public: */ and /*+ virtual*/ Why has this not been done? Don't tell me nobody thought of it :)
Well, nm is from binutils. It's certainly not gcc only --- it can read various object file formats. Anyway, surely you are only interested in those that your linker, ld, can actually read.
It is true that nm is faithful to the object code, in that "private" artifacts and type info in C (C++ has them, as you suspect, encoded into the name, much like Java) are listed. This reflect the fact that nothing prevents you from modifying a header file to use a private artifact --- it's a compiler thing, not a linker. I'm not famliar enough with Java to know if accessibility is enforced down at the runtime level. It seems a counter-constructive thing to do, but maybe there is something about Java that forces this to be so.
However, my point was that even with private/public adoration, the API you get is rather useless. It's very well to know that a constructor for a rectangle takes for doubles as input, but would that be lower left corner, height and width? Does the class require that the height and width (parameters) to be positive? How about 0, is that ok? If I copy a rectangle, would that be a deep or shallow copy? Is the constructor thread-safe?
All this is usually documented in comments in the code --- doxygen or javadoc. And there you get the full API for free anyway, with clickable links and everything. What's the point in jerking around with object/bytecode when you have this?
Nothing prevents you from doing so in C++ --- try man nm.
However, the interface you get this way is not very well documented --- in Java or C++. For this reason, most people doing C++ (and Java) uses comments in the source files, which are then transformed into documentation by doxygen and similar programs (like javadoc).
I am well aware of the concept of entropy :)
But unless you define a term "key size" to mean "the entropy of a sequence of randomized keys" the second paragraph is just meaningless, if I was to be in nitpicking mode.
But now I tire of this discussion. Thanks for your part...
Sigh. What you wrote is essentially meaningless --- at least I can't see how to generalize the definition of a bit. A bit is a (state) variable with two possible values. I don't know if you could possible make this an dimension in an outcome(?) space, then approximate the dimension the way the fractals guys do (which I think is nonsense, and seems to have fallen out of favor, but hey) and thus arrive at fractional bits. I'm sure the result would be very different from what you imagine in any case.
And it is not just my lack of capacity to understand weird things. But you cannot represent 26 different states with 4.7 bits --- it's nonsense. You need 5 bits. That's the long and short of it. Now, I understand what you mean. You are saying that the strength of a key is defined as the number of states it can hold, and thus a key of 5 bits has a strength of 32, whereas an key containing 1 letter would have a strength of 26, the way I put it earlier. And certainly, I could have defined the strength of a key as the log_2 of this number, arriving at your 4.7 number. That is why I said I was nitpicking. I think this is where you have been confused, though it is hardly catastrophic.
I am a mathmatician, you can search for my master thesis if you want --- though it is in danish, so I doubt you would understand any of it. It is on the subject of approximation of topological spaces (using normal coverings). A "dichotomy", indeed ;-) Separating mathematics from reality is one thing, but separating it from reason is quite another! If you want fractional bits, you need a definition, and a definition that makes some sort of sense. At the very least, the definition should imply the current definition for integer numbers.
Snipping a lot of trivia...
I don't know about repulsive, but you hit the nail on the head with the new alghorithm thing.
You are, I assume, referring to "fuzzy logic" here. Now, such a state variable is usually defined as a real number between 0 and 1, and so the value of the such a bit might be 0.7, or whatever. You could even say that the average number of bits with a value about something is 23.3, but then we are talking about an average number of bits, which is a quite different beast than the number of bits.
They think it has become a consumer product, like a DVD-player, and thus outside their core business.
Please explain to me what 0.7 bits is? ;-)
Sorry for nitpicking, but the above statement is rather silly, unless you can think up a way of generalizing the definition of a bit to include rational numbers ;-)
As we both know, this is toally besides the point :) The point of course, was that by more bits we don't mean shifting the original letters more, we mean shifting the letters in more ways. Eh. Approximately.
Well, I'll try to explain why people think what you are proposing is suboptimal.
Firstly, I think you have misunderstood what "adding extra bits" (enlarging the key) means --- at least in this context. In my (silly) example, the key had the length of 1 (number). Notice there is no bits, since the atomic unit in this encryption unit is letters. If you increase the number of bits we would have more numbers.. E.g, (1,2) would make "have" into "icwg", which would be harder to break. The scheme is actually not THAT bad --- there are methods to break this sort of encryption, but it isn't trivial. A person that has not studied cryptography would be pressed to break something like this, at least if the key length is unknown.
If you take this method to an extreme with keys longer than the text, you would have a fair encryption method, provided that the keys are kept secret. But nevermind that.
Now, to invent another cryptographic method, let's consider a method where the positions in the alfabet are multiplied rather than added, and the modulo of 26 is taken. So for the example key (1,2) and the word "have" the result would be "hbvj".
How secure are these methods combined? Well, if the coded and original letters have position x and y, respectively, and we are using keys k,l with values k_1, k_2, ..., k_n and l_1, l_2, ..., l_m, where n and m are some integral numbers. Then the effort spend on encrypting the message is O(n+m). The effort spend decrypting then will only be proportional to the smallest common multiple of n and m --- it's an easy proof, so I leave it as an exercise. However, for the same effort you could have obtained and effort proportional to the multiplum... and the encryption and decryption rutines would be simpler, and thus less errorprone. That's one argument against layering encryption algorithms.
Now, either of these algorithms may be weak --- indeed, the muliplum algorithm is for a number of reasons, most importantly the distribution of the resulting letters is not uniform. Note that if the addition is performed first, no harm is done by this, but if the multiplication is performed second, the distribution would be skewed in such a way that the addition key could be guessed from the distribution of the letters of the encoded message. This would render the combined algorithm weaker then the addition alone. This is the "real world" example you asked for... and admit it, it is not that far-fetched for a slashdot comment ;-)
Disclaimer: I'm not really a crypto guy, just an IT specialist + mathematician.
But who knows if the combined algorithm has a flaw that neither algorithm had, separated?
As for simple layering the same protocol, consider this (silly example): Exchanging each letter with the letter n positions futher along the alphabet does not get more secure by being done multiple times.
The same holds true for 3DES and every asymetric encryption method I have seen.
Well, I'll be rolled in tomato source. Thanks! I never knew --- it's even made it's way to linux :) At least "man strlcpy" fetched a likely looking manpage, if nowhere as nice as the BSD one you linked.
Thanks!!
The problem is that people forget to append that stupid 0 termination... and with long strings strncpy tends to fill buffers up with useless 0'es. I always code my own (it's only three lines) and use that. Safe, and efficient. strn?cpy should be deprecated, and replaced with stringcpy, which does the right thing and fillfield() which does with strncpy does.
Instead of shooting the poor programmers, including a "grep strcpy checkinfile; if [ $? != 0]; then send_evil_mail; fi" in the cvs checkin scripts is probably more effective. Works for KDE people, at least (not that that KDE would have problems with strcpy, obviously, but that kind of thing.)
While I agree with the sentinent, I cannot but hasten to warn that strncpy is evil, and it should almost never be used. Why? It doesn't zero-terminate, so it might turn a C-string into a non-C-String, with hilarious results.
I assume several C-String libraries must have been designed and built over the years. But I none seems to have prevailed for whatever reason. Which is a bloody shame, because C's string (mis)-handling are a trategy, so messy and unclean in such a nice & clean language. I wonder why?
(And yes, I'm perfectly aware why strncpy does what it does, I just wish they had called it fillrecord or something sensible instead.
Anandtech is just one tester. Against that we have 100 of dualbooting linuxusers, who with identical hardware got wildly different results. Perhaps Anandtech has a more optimized windows platform than their linux counterpart? Were they running updatedb while testing? Video capture? Any other background daemon? BTW, I don't trust Anandtech's tests. Too often, their results are inconsistent with other testers, and often their results are just insane.
Anyway, even if that is the case, UT2004, Thinktanks, dominions2, hardball, Majesty and other games do not have this tendency at all. Some even report superior framerates running window applications under wine, which makes no sense. Again, I think they must be running some background proccesses under windows without their awareness.
I think we differ because ultra low level mulitplatform is inherently much more difficult than when we hit the C++-level. If the platform differences are down to different system libraries, coding multiplatform is not that hard. I should know, I code multiplatform every day. Most of our trouble comes from libraries which uses unsigned char instead of char (yes, we have an important platform with signed chars). And porting to windows is always an experience, but again, it is not that hard.
Finally, to be clear, I believe the game publishers and developers have a perfect right to be (stupidly in my opion, but whatever) developing for a single platform (often single platform multiple times, because the games are ported to XBox/PS2). It just that I won't be buying them, which was my point, and a wine hack doesn't cut it with me. That, and stating that if I would do a game, I would buy/steal an engine (like the linked one) and do it from there, keeping the code running on as many platforms as I could get my dirty hands on. That is all, and I hope that you can understand this viewpoint as well. I have no shortages of games, BTW --- just shortage of time to play them. I still havn't played Doom3 very far, e.g.
Re speed: Multiplatform means either little or nothing, depending on whether you do it dynamically or statically. At least, that is my experience. It may be different in the graphics area, but then, UT2004 and other games seems to disagree. Re testing: Porting catches more bugs than your would ever dream, so in a way porting reduces the need for testing. Of course, for each supported platform, you need some testing, but as each platform also brings some customers, there should be a valid business case for this.
As for Doom3 speed: The number you quote is bogus. The dual booters (can't get fairer than that) seems to get very different results, with Linux outperforming windows as often as the other way around. From what I hear, it seems to be soundrelated, so maybe the sound chipset means more than anything else. *shrug*
I won't comment on the other games... the windows ones I never play. Nor am I qualified for commenting on the directx vs. opengl, but then, the engine I linked seems to be able to use both with little trouble.
So in conclusion, I believe that making mulitplatform game is exactly as easy as I think. And if you doubt me, look for all the games that are released on ps2, xbox and windosw simultanously. Look harder for games that are release for windows, mac and linux concurrently --- many small game developers manages it. Which again suggests that it is not that hard
You mean like Doom3, UT2004 etc. scales over a largish hardware range, dropping advanced features as needed? Why, the same way.
To be specific, I would take an open-source engine (e.g this one ) and port it to the mentioned platforms. Then I would allow effects to be switched on and off (use stencil shadows or just blobs? Viewing distance?) and use the good old trick of having two (or three) detail levels used at different distances. And so on.
Java is another possibility, though I must admit, I don't know about Java and PS2 --- but when a JVM exists for Z/OS, everything is possible.
As I said, it is not that hard And as I said, I don't buy games that are not natively running on Linux.
My hardware friends tells me that this is becoming increasingly not true. Custom chips are being replaced with reprogrammable chips instead, essentially moving hardware->software, except for making those chips.
It's not the paying I mind. It's the fact that it seldom works, and never perfectly. This is my experience with Civ III, which is an officially supported game, plus a host of other non-supported games.
No, if game developers want my money, it's the Linux way. I, myself, develop software, which I rutinely run on Z/OS, Linux and windows. It is not that hard! In fact, if I were developing games, I would do it hardware indepently enough that porting to PS2, gamecube, xbox and windows would be no problem --- and keep the developing on the greatest development platform I have ever had the pleasure to use.
UT2004 (at least) use DirectX on the win32 version. Check the requirements for the game if you doubt me :)
I always believed it was the sentence I quoted, and that the other part was just to separate that right from the distribution. So anybody may run it, but if you want to distribute, read on sort-of-thing.
Otherwise, I can't see how it is legal to run GNU software in most parts of the world --- I believe the law text typically say something like "only the copyright holder may produce any copy, temporary or otherwise". As running an application means copying into RAM... but hey, I'm no expert in this.
It even makes sort of sense... copyright doesn't restrict usage (anyone may view a copyrighted painting...), and I doubt that distributing the warez as running programs on RAM chips would make it legal...
I'm no expert in other package systems, so I really don't know, but if all else fail a simply chroot'ed install-script would do the trick. Not hard at all, I just do not think that the demand is there.
As for hardcoded path-names... These are relatively rare, in my experience. I run all the handcompiled software (all of KDE, e.g.) off my home directory, with some globally installed extra stuff, with no problems. And again, if all else fail, chroot is the bigger hammer that always work, though the work would be slightly larger.
But it does require some minimal effort, which is of course my entire point, such as it is :)
I think that would depend on the country in which you live. I wouldn't count on having any of those rights, but you might. Check your local laws.
And that's your license to run GPL'ed software --- at least in Europe, I don't know (anymore) about the US, as I can't say who the "owner" would be.
PS: In case you doubt it, I totally agree that software running on my own hardware should be mine to do with as I please. The laws are just not made that way, and I am very happy that GPL'ed software makes this possible anyway for a subset of software.
I also believe that this is only the first step. The next thing will be games run exclusively as an online service, streaming the game data directly to you, with most of the software and game data running on some server. Or something like that. It simply requires a faster internet --- about 20Mbit or so, I'd think. Not too far away... and we can thank all that to thieving pirates :-( May they burn in a hell of their own choosing for that :-(
PPS: I actually "own" a game who validates it's key against a server when you connect to an online game. *shrug* The game company in this case is just two guys, who seem to be nice folks.
Well, do it then. Change the paths in ~/.bashrc and setup ld (or just use LD_LIBRARY_PATH), then read from the relevant package manager how to install locally. E.g, in Gentoo, it's an environment variable ROOT=$HOME. For extra points, make a sandbox, but it's not really neccessary. Wish granted. That wasn't hard, was it? :o)
I'm sure that this would be default or even more easily configurable if anyone wanted to shoulder the task of maintaining it --- which should be an easy task. The hardest part will be reading info ld, and the a spot of testing. So let me guess: The number of people of wants to do this is
Bzz yourself. Ok, so the law was changed in the US, maybe this year --- I didn't dig, the US doesn't matter to me.. I would be surprised, though, if you were allowed to run unlicensed copies, and I think the devil is in the bit about "owner of a copy of a computer program". I couldn't see the definition what an owner of a copy is, though, so I don't know.
Anyway, that law is simply badly made. E.g, this law seems to suggest that if I buy a computer program, I cannot install it on my computer and have my employee use it, unless I load up (!) It would seem that European lawmakers have not patented badly made laws after all :-/
Unfortunately, that is not how it works --- not in the US, and not in Europe, though the laws are slightly different. You are, of course, free to do what you want to with the plasitc --- but the game itself is copyrighted. That means that it cannot be freely copied, unless you have a license to copy it. In order to run the game, you have to copy it (from disk to RAM). The law is crystal clear about this in the US, and while not so in Europe, the rulings are. Or maybe it is the other way around. And licenses, unlike contracts, can apparantly be simply displayed and you can "take it or leave it". You wonder why mr. Stallman says he despises copyrights? This is why. Join the club, if you please, but this is how all licenses work, including the GPL.
WebDAV is not bad, and well supported by both Linux and Windows. Can run atop of SSL, which makes it secure enough for most purposes.
The downside is, of course, that the server(s) must run a WebDAV capable web server (read: Apache), and I have not seen a way to map window drives to WebDAV(s)(s).