Seeing benchmarks conducted by Phoronix always fills me with emptiness on the inside. While I really welcome the idea of benchmarking Linux, their methodology always seem lacking for me.
All we get are a bunch of numbers, without any actual investigation of what those numbers should represent, what can be the reason of the outcome, and sometimes the measurements make simply no sense.
For example, according to these benchmarks, Ubuntu 7.04 reads memory twice as fast as newer versions. There is no possible way it can be a valid result. At least assuming that the exact same compiled code was used on every installation. Which brings us to another problem: no information on the tests. All we get is a software name, a version number and the result numbers. Which would be almost fine if they were prepackaged binaries, but with FOSS different compile time options and compiler flags can make quite a difference in the results too.
About the nonsensical tests: RAM speed should be the same regardless of the OS. So dedicating a full page to RAM speed tests should be senseless. No. It's actually a nice control to the tests, and the numbers show that there's a problem somewhere. Either the tests, the measurements are off significantly, or there is something flawed in either the 7.04 configuration or the others that cause almost 50% difference in such test.
Also, measuring compile times. They managed to measure the time it takes to compile 3 software written in C using an unspecified compiler with unspecified options.
At the end, no conclusion were drawn, just the results summaried in English instead of plain numbers. The whole thing gives me the feeling that they don't really know that they are testing, they're just running a bunch of programs and reporting the numbers they output.
I'm sorry if it seems like I'm just ranting, but I've tried a couple times sending emails that point out the flaws in their methodology, to no use.
I do consider C++ a bad language. The syntax is a MESS, it's quite lacking on the OO front, and the language/STL misses some quite important components (e.g. concurrency, networking). And having an actual ABI would help too.
However, it's still generally my language of choice, and not only because it's the language I know most. It has the flexibility of C while providing some OO capabilities and the STL. And there is the widespread availability too (although that's not really C++'s honour but GCC's).
One could also argue that C++ software is easier to deploy, as it needs no VMs or interpreters, but it's quite a moot point because every moderately sized application will have 3rd party dependencies to provide everything the STL is lacking.
Also, the RAII idiom is perhaps my favorite pattern, and I'm yet to see a language that has RAII support as strong as C++ has. (Although I do plan to have further investigations about Python 3k/2.5's 'with' statement, it seems to be a good contender) I rely heavily on RAII while coding/desinging, this makes coding in Java very sour for me. And Ruby's block idiom, while it's really lovely and comes very handy in many cases, it ain't no RAII.
Like it or not, while it's slowly fading away, C++ will still be around for a while. I don't really see KDE rewritten in any other language any time soon.
Much of the reason that RAII is such a big deal for C++ is that C++ doesn't help manage resources. The fact that one can free in destructors and that destructors are called automatically in some circumstances is important only if you need to free. That's simply not an issue for many languages.
Yes, there are other resources to manage. Python's with and Common Lisp's unwind-protect are both good for open file handles and the like. unwind-protect is better than with and with is better than constructor/destructor because constructor/destructor and to a lesser extent with require too many contortions to use.
Weird, as I was browsing the language shootout, I got the impression that SBCL produces damn fast code, in most cases comparable to the code emited by GCC or Java 6.
It's distributed under BSD license, no EULA can screw that. Every attempt at it could be averted by getting the BSD licensed code and making own builds without any strings attached.
That infamous EULA was intented for other Google services, and was mistakenly used for the browser. Supposedly (I haven't actually read it) it was already changed/clarified.
Yes, the code is available under the BSD license, which is basically a "do whatever you want" license. You can download it, you can build it, you can redistribute it. You can even rebrand it and start selling it, although it wouldn't make you the most popular person around the internets.
It's the binary that was (and as you noted, is) distributed under that unfortunate EULA. For me it is really clear that they did not intend to have such an EULA, with the BSD licensed code, it REALLY makes no sense.
Also, accoring to http://www.en.rankings.hu/ Firefox 2.x is the most used web browser version in Hungary. (Although IE6 + IE7 combined are still way beyond 50%.)
Disclaimer: I don't want to offend you, I have nothing personal against you (I don't even know anything about you).
But.
I have seen this many times. People have their Great Idea. Like writing a whole new operating system. However, they do this by staring threads on the internets about how great their operating system will be. Without having actual goals (other than the vague ideas about what will make their system so great), doing their research on the topic or even having the necessary skills to start.
If you really intend to create a new operating system, then go for it. I'd be happy to see your next post in 3-6 months about the "New operating system I've been developing and published in <this> git repo. It has no name yet, and can boot only on <insert virtual machine>, and doesn't do too much even on that one. I also have plans to do <this> and <this> in the next months. Comments welcome."
All we get are a bunch of numbers, without any actual investigation of what those numbers should represent, what can be the reason of the outcome, and sometimes the measurements make simply no sense.
For example, according to these benchmarks, Ubuntu 7.04 reads memory twice as fast as newer versions. There is no possible way it can be a valid result. At least assuming that the exact same compiled code was used on every installation. Which brings us to another problem: no information on the tests. All we get is a software name, a version number and the result numbers. Which would be almost fine if they were prepackaged binaries, but with FOSS different compile time options and compiler flags can make quite a difference in the results too.
About the nonsensical tests: RAM speed should be the same regardless of the OS. So dedicating a full page to RAM speed tests should be senseless. No. It's actually a nice control to the tests, and the numbers show that there's a problem somewhere. Either the tests, the measurements are off significantly, or there is something flawed in either the 7.04 configuration or the others that cause almost 50% difference in such test.
Also, measuring compile times. They managed to measure the time it takes to compile 3 software written in C using an unspecified compiler with unspecified options.
At the end, no conclusion were drawn, just the results summaried in English instead of plain numbers. The whole thing gives me the feeling that they don't really know that they are testing, they're just running a bunch of programs and reporting the numbers they output.
I'm sorry if it seems like I'm just ranting, but I've tried a couple times sending emails that point out the flaws in their methodology, to no use.