Adam Stiles wrote: > As I've said before, binary compatibility is irrelevant. No, it isn't. If it were, then why does everyone spend so much time worrying about? And I do literally mean everyone, both within and beyond the OSS community.
In fact, from a > security point of view, binary _in_compatibility -- to the point where > binaries compiled on one box would not run on any other box -- might be > desirable, then there could never be such a thing as a virus. This kind of nieve thinking doesn't help you. The Apache slapper worm attacked a vulnerability in OpenSSL, a library notorious for it's ABI-incompatilibites and managed to sucessfully trojan a entire rash of boxes. So no, there will still be plently of viruses. > {Obviously > some sort of compatibility mode would be required for initial bootstrapping > of a system, but access could be restricted by means of something like a > motherboard jumper, that could not be defeated by software alone.} And just how is that going to modify the binary code provided on a CD? > Source > compatibility is all that really matters, and there are enough examples > around to show that this is entirely achievable. Yet it's not as interesting as ABI compatbility. API compatibility is pretty easy to maintain. ABI is not. ABI is also more desirable. ABI compatability is how KDE code from 3.0 can still run on 3.4 today. That's a desirable thing, because it means I don't have to keep my application up with the KDE developers if I don't want to. ABI compatability is how programs written from kernel 2.0-era can still run on a 2.6 kernel today, without any changes. That's also desirable. And I'm not just talking > about compatibility across different versions of the same distro, or even > different Linux distributions; but Linux, the BSDs, Solaris and legacy > systems too. Then you don't know what you talk about. No UNIX is 100% API compatable with any other UNIX or UNIX-alike, even along the lines of SUS and POSIX. If you don't believe me, go look at the code for tcpdump. Or at the Apache Portable Runtime. > The only reason why you would ever want to be able to run a binary not > compiled by you is if you did not have the source code; and if you don't have > the source code, it's probably because someone doesn't want you to have it. That's not true. Stop being so simple-minded. What if I have 2000 webservers? Why should I take the time to compile source on each one? Or take the time to compile the source on one box and /distribute/ the binaries? Especially when we have groups of people who do that, who produce products called Linux distributions. And odds are, for any given piece of software, they're going to a better job of packaging it up and resolving issues than any individual person can. Doing things like more widespread testing, keeping abreast of development issues and bugs, providing patches, and the like. Something most people don't have time to do. Certainly something that's just not acceptable in a production environment, where downtime == money lost. > If somebody doesn't want you to have the source code, then there is probably > something in it that they are ashamed to show you. That's simply not the case. What if the source code contains a nifty algorithm I don't want anyone to have? What if it contains trade-secrets that make my business process really efficent? There are plenty of valid reasons to not want someone to have access to your code. Please, go read some books on software engineering, configuration management, and quality assurance before spouting anymore of what amounts to simple-minded nonsense. You clearly haven't considered even remotely enough cases to give any of your suggestions merit. Adam Skutt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]