It's simply by definition (the software version anyway). To be unstable means to not have been tested thoroughly (this is where the Debian repository names come from - stable, testing and unstable). Even if you don't agree with this definition, for all it's worth that's what I meant. Now, if everyone used the same compiler (same version too!) and flags that wouldn't be a problem. Binaries compiled would also be the same, but if that was the case - why do the extra work and compile in the first place? The reality, of course, is that people use different compilers or *at least* different versions of the same compiler. They may also use different flags for their specific hardware or maybe use flags to remove certain features from software they won't need (That's the whole idea of Gentoo instead of just using binaries, isn't it?). Anyway, let's assume everyone use the same flags. Different versions of compilers compile differently. Ask any developer whether they've seen compiler bugs that caused them problems. I'm sure most will say yes. The bottom-line is that you can't expect that if your software works on your machine with YOUR version of GCC, it will necessarily work on my PC with MY version of GCC. And that's the whole problem and where the 'unstable' name has real consequences instead of just being a theoretical name for untested binaries.

P.S. I don't advice against Gentoo on servers purely because I read that some people on Slashdot don't like it. That's what I hinted at in my previous reply. I don't necessarily need to try Gentoo to see that the idea of Gentoo for servers (in many cases) is not good, simply because what Gentoo does best is not what you want for servers (generally).

I'll ask myself.

Q: Have I seen such problem?
A: Yes, KTX had GA rounding problem where you could take another GA even if you had GA:100

Q: Did this happen on the machine the binary was compiled?
A: No, it worked perfectly on the machine where it was compiled.

Q: Where did it became problematic then?
A: On any other machine where that particular binary was used.

Q: What was the OS that binary was built on?
A: Debian.


Documented case, QW-DEV / KTX.


Can you expect something I build on my dev-machine to work on all the other machines? No. Only if I use specific compiler flags (i386 optimizations) and rather old GLIBC can almost guarantee that the builds I make will work on other machines. Guess why we have more than one build using different GLIBC on our MVDSV, KTX and QTV projects?

I .. am a bit confused. I'm not really sure what you are trying to say with all this, sorry. :\

If anything, are you *supporting* my claim that testing binaries is essential? The whole idea of binary packages in e.g. Debian is that everyone use the same libraries (and versions, of course) and the same binary and everything is tested (so by the time a package hits stable, it won't have bugs as you describe above). Sure, if you compile on a different system, possibly with different versions of libraries, and move that binary to another system without testing it, you can't possibly predict what will happen. It's the same if compile from source on a new system - you can't predict what will happen.

conus.mine.nu is back up again (same location as before, I.E Linköping sweden)

qwfwd port: 30000
KTX ports: 27501 - 27503

conus.mine.nu taken down until I'm settled in my new apartment.
I'm pretty sure it will be a 100/100 connection.
It will now be located in Trollhättan, Sweden.

Hopefully I'll have it up and running by the end of august.
Worst case it's gonna have to wait until november.

Keep on fragging!