Slashdot Mirror

I received this from Apache just moments ago. It may clear up some questions. I redacted personal info.

Dear [redacted],

You are receiving this email because you have a login, [redacted], on the Apache JIRA installation, https://issues.apache.org/jira/

On April 6 the issues.apache.org server was hacked. The attackers were able to install a trojan JIRA login screen and later get full root access:

https://blogs.apache.org/infra/entry/apache_org_04_09_2010

We are assuming that the attackers have a copy of the JIRA database, which includes a hash (SHA-512 unsalted) of the password
you set when signing up as [redacted] to JIRA. If the password you set was not of great quality (eg. based on a dictionary word), it
should be assumed that the attackers can guess your password from the password hash via brute force.

The upshot is that someone malicious may know both your email address and a password of yours.

This is a problem because many people reuse passwords across online services. If you reuse passwords across systems, we urge you to change
your passwords on ALL SYSTEMS that might be using the compromised JIRA password. Prime examples might be gmail or hotmail accounts, online
banking sites, or sites known to be related to your email's domain, [redacted].

Naturally we would also like you to reset your JIRA password. That can be done at:

https://issues.apache.org/jira/secure/ChangePassword!default.jspa

We (the Apache JIRA administrators) sincerely apologize for this security breach. If you have any questions, please let us know by email.
We are also available on the #asfinfra IRC channel on irc.freenode.net.

Regards,

The Apache Infrastructure Team

I received this from Apache just moments ago. It may clear up some questions. I redacted personal info.

Dear [redacted],

You are receiving this email because you have a login, [redacted], on the Apache JIRA installation, https://issues.apache.org/jira/

On April 6 the issues.apache.org server was hacked. The attackers were able to install a trojan JIRA login screen and later get full root access:

https://blogs.apache.org/infra/entry/apache_org_04_09_2010

We are assuming that the attackers have a copy of the JIRA database, which includes a hash (SHA-512 unsalted) of the password
you set when signing up as [redacted] to JIRA. If the password you set was not of great quality (eg. based on a dictionary word), it
should be assumed that the attackers can guess your password from the password hash via brute force.

The upshot is that someone malicious may know both your email address and a password of yours.

This is a problem because many people reuse passwords across online services. If you reuse passwords across systems, we urge you to change
your passwords on ALL SYSTEMS that might be using the compromised JIRA password. Prime examples might be gmail or hotmail accounts, online
banking sites, or sites known to be related to your email's domain, [redacted].

Naturally we would also like you to reset your JIRA password. That can be done at:

https://issues.apache.org/jira/secure/ChangePassword!default.jspa

We (the Apache JIRA administrators) sincerely apologize for this security breach. If you have any questions, please let us know by email.
We are also available on the #asfinfra IRC channel on irc.freenode.net.

Regards,

The Apache Infrastructure Team

I received this from Apache just moments ago. It may clear up some questions. I redacted personal info.

Dear [redacted],

You are receiving this email because you have a login, [redacted], on the Apache JIRA installation, https://issues.apache.org/jira/

On April 6 the issues.apache.org server was hacked. The attackers were able to install a trojan JIRA login screen and later get full root access:

https://blogs.apache.org/infra/entry/apache_org_04_09_2010

We are assuming that the attackers have a copy of the JIRA database, which includes a hash (SHA-512 unsalted) of the password
you set when signing up as [redacted] to JIRA. If the password you set was not of great quality (eg. based on a dictionary word), it
should be assumed that the attackers can guess your password from the password hash via brute force.

The upshot is that someone malicious may know both your email address and a password of yours.

This is a problem because many people reuse passwords across online services. If you reuse passwords across systems, we urge you to change
your passwords on ALL SYSTEMS that might be using the compromised JIRA password. Prime examples might be gmail or hotmail accounts, online
banking sites, or sites known to be related to your email's domain, [redacted].

Naturally we would also like you to reset your JIRA password. That can be done at:

https://issues.apache.org/jira/secure/ChangePassword!default.jspa

We (the Apache JIRA administrators) sincerely apologize for this security breach. If you have any questions, please let us know by email.
We are also available on the #asfinfra IRC channel on irc.freenode.net.

Regards,

The Apache Infrastructure Team

Just use Poi.

Last time I looked Apache was written in C++.

From Apache's web site, with my emphasis: "Apache Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies."

Been there, done that, sort of. I actually had to maintain a program written with something called Jelly. Overall, I'd rather stick with Java/JSP.

I think what you want is Ant.

Really, I've been involved in a project where we had external consultants who were pushing for all shell scripts to be stored as and deployed from Ant xml files (so it would essentially have been shell scripts packaged as huge XML files), their main argument for this was that if we did this we could "use version control on all the scripts", we decided to ignore them and simply use Subversion for the scripts without XML-ifying them.

Pure dynamic. It's a datamining / analysis site, so every user is viewing their own set of data, slicing and zooming randomly. Caching is completely useless for 99.9% of the pages, but we do store some heavy "SELECT COUNT(*) ... GROUP BY ..." queries in memcached. We chose PSQL because it can handle the complex multiple table joins with many indexes required - just that one thing would mean endless pain in a non relational datastore.

If you still have any doubt, just write your code the easy way and grab Apache JMeter to benchmark your site on localhost. You'll be surprised how well even the dev server works, on an average page with ~10 queries, it takes only 50-100ms to serve a page. At 10/sec/core, extrapolated to 24 hours means almost a million pages/core. You can just take this and run it on a 8-12 cores node and survive any traffic surge imaginable, without cache. Add cacheing and I really can't see how a blog/news site/forum/CMS can ever require NoSQL to run, except when you reach "Facebook" popularity.

PS.: We aim for these numbers for a non cacheable page: 1s = slow but manageable. 0.2s = good. 0.1s or less = perfect.

Indeed it is. Lucene, however, is Java. With a C# port that (as I understand it) was, at the time, done by line-by-line translation.

On Sunday, I'll be releasing an alpha version of a LAMP "virtual appliance" that runs a customized WordPress MU/BuddyPress install I call Foojbook. The eventual hope is to get it running on devices like this, as Eben Moglen explains in the interview.

It'll also include Apache Shindig and the example Partuza social networking site that goes with it. BuddyPress doesn't yet support the OpenSocial stack (although it'll potentially be in the next release), so I'm including Shindig/Partuza just in case people want to hack away at that. You will be able to either install Foojbook via the .iso I'm releasing or run it inside a guest OS via QEMU, which I'll also bundle in a separate download targeted at thumbdrives.

I contacted Eben about a month ago about Foojbook, and I intend to be a part of the effort he's putting together. *However*, and I want to stress this, Foojbook is currently just an example of what's possible, and only allows you to set up a single profile for yourself...there is currently no sharing of data or any communication between separate Foojbook installs, since I don't know enough about network protocols and encryption to implement these pieces myself.

There is still a lot of work to be done and, if you're interested in helping out, please contact me.

Great, a number of sites have switched to Cassandra, that's an interesting social benchmark. What about some real engineering benchmarks? I'd like to consider Cassandra but where is the objective data?

Cassandra's data model page states that "Cassandra is much, much faster at writes than relational systems". Great, so how about some comparative data? There is a slide show on the main Cassandra page with a snippet of data about read latency. Reads range from 7 ms to 44 ms. That's pretty anemic in the RDBMS world. There is a statement that writes are limited by network bandwidth.

There is also a presentation from IBM that shows reads ranging from 25 to 900 ms, but with no write data. The fact that read latency gets worse (increases) by a factor of 2 or more when you go from a 3 node to 6 node Cassandra cluster would seem to be worrisome on the surface.

The Facebook Engineering Notes presentation has almost nothing quantitative (only two sentences have numbers) and nothing is documented about read or write performance.

Great, a number of sites have switched to Cassandra, that's an interesting social benchmark. What about some real engineering benchmarks? I'd like to consider Cassandra but where is the objective data?

Cassandra's data model page states that "Cassandra is much, much faster at writes than relational systems". Great, so how about some comparative data? There is a slide show on the main Cassandra page with a snippet of data about read latency. Reads range from 7 ms to 44 ms. That's pretty anemic in the RDBMS world. There is a statement that writes are limited by network bandwidth.

There is also a presentation from IBM that shows reads ranging from 25 to 900 ms, but with no write data. The fact that read latency gets worse (increases) by a factor of 2 or more when you go from a 3 node to 6 node Cassandra cluster would seem to be worrisome on the surface.

The Facebook Engineering Notes presentation has almost nothing quantitative (only two sentences have numbers) and nothing is documented about read or write performance.

Seriously, it is that bad.

The SYSTEM account has no privileges to the network, so shared pages or a shared installation of Apache is invisible to the service. If you intend to use any network resources, the following steps should help:

• Select Apache from the Control Panel's Service dialog and click Startup.
• Verify that the service account is correct. You may wish to create an account for your Apache services.
• Retype the password and password confirmation.
• Go to User Manager for Domains.
• Click on Policies from the title bar menu, and select User Rights.
• Select the option for Advanced User Rights.
• In the drop-down list, verify that the following rights have been granted to the selected account:
   
  • Act as part of the operating system
     
  • Back up files and directories
     
  • Log on as a service
     
  • Restore files and directories
     
• Confirm that the selected account is a member of the Users group.
• Confirm the selected account has access to all document and script directories (minimally read and browse access).
• Confirm the selected account has read/write/delete access to the Apache logs directory!

Now, as far as I understand, the main IIS service runs as Local System. But, for IIS 6+, worker processes run as the user logged into the website (or a set anonymous user, if not authenticated). This seems like it could still harbor some privilege escalation exploits, but seems more secure than Apache on Windows. I guess my point is, if you run Apache for a production server, make sure it is *nix and that it is not running as root.

Apparently, there were regressions with the build.

Here's revision 2 of Apache 2.2.15 with OpenSSL. Preliminary reports indicate that it works like it should.

You're not missing anything, refer to The apache bug tracker for details....

So I went to download the new 2.2.15 win32 binary and it appears to have been taken down? http://www.apache.org/dist/httpd/binaries/win32/ Or am I missing something?

.. but the vulnerability is entirely Apache's fault...

Probably not, actually. From the documentation:

Summary

This module implements the Internet Server extension API. It allows Internet Server extensions (e.g. ISAPI .dll modules) to be served by Apache for Windows, subject to the noted restrictions.

ISAPI extension modules (.dll files) are written by third parties. The Apache Group does not author these modules, so we provide no support for them. Please contact the ISAPI's author directly if you are experiencing problems running their ISAPI extension. Please do not post such problems to Apache's lists or bug reporting pages.

Emphasis theirs.

Apache on linux (at least in all the setups i've seen) starts as root so it can bind port 80 but then switches down to a lower privilage user to do the actual serving. Some damage could still be done of course but hopefully it's limited compared to the damage root can do.

Apache on windows defaults to running as "localsystem" (roughly the windows equivilent of root)

You can run it as another user but apparently ( http://httpd.apache.org/docs/2.0/platform/windows.html ) that user has to have "Act as part of the operating system" privilages. MS describes said privilages as "This user right allows a process to impersonate any user without authentication. The process can therefore gain access to the same local resources as that user.".

So it seems either way to run Apache on windows you have to give it what ammounts to root privilages.

The problem isn't in the dlls per se, the exploit works by causing mod_isapi to unload a dll and leave dangling pointers to the api that can be invoked. The fix is an apache.org change to mod_isapi that prevents such unloading:

2.2.15 Release Notes

Changes with Apache 2.2.15

*) SECURITY: CVE-2010-0425 (cve.mitre.org) mod_isapi: Do not unload an isapi .dll module until the request processing is completed, avoiding orphaned callback pointers. [Brett Gervasoni brettg senseofsecurity.com, Jeff Trawick]

It may be too early in your education to know what you want to do in your career, but I would start looking in to areas where you can specialize. Client/server architecture will always be a skill that looks good. If you want to go this route, look into learning Java Enterprise Edition. UI design is good to know, but with abundance of WYSIWYG editors that are available now, writing UIs is becoming less of a skill. UI design theory is still pertinent even if the coding skills are going the way of the dodo. Some other skills that will come in handy are writing web services, database interaction (with JDBC and JPA, both good to know), and multi-threading. I would also recommend the book Head First Design Patterns to get started on learning how to design software (as opposed to just writing software).

I would agree with what a lot of people have been saying, though. The best thing that you can do is put what you know in to practice. Start out writing a small application for yourself. Write unit tests.Do some code coverage analysis on the code and make sure you are completely covered. You can start with Cobertura. Get to know what APIs are available in JSE. I'm assuming that in an academic environment you are using the latest JSE (6), so I would also look into familiarizing yourself with JSE 1.4. There are some major differences between 1.4 and 5 (and not a whole lot of major differences between 5 and 6), and if you are working on legacy code in the future, it helps to know what differences there are. Write an app in whatever you are used to using, write it again with JSE 1.4. Check out an open source project and debug it. Get code coverage on the project and write tests to cover more lines of code. Most OSS projects would be happy to integrate tests that increase their code coverage. Look through the bugs that have been logged against the project. Pick something small, fix the bug, and submit patches. Get familiar with build systems like Maven 2 or ANT. That should keep you busy until next semester.

It may be too early in your education to know what you want to do in your career, but I would start looking in to areas where you can specialize. Client/server architecture will always be a skill that looks good. If you want to go this route, look into learning Java Enterprise Edition. UI design is good to know, but with abundance of WYSIWYG editors that are available now, writing UIs is becoming less of a skill. UI design theory is still pertinent even if the coding skills are going the way of the dodo. Some other skills that will come in handy are writing web services, database interaction (with JDBC and JPA, both good to know), and multi-threading. I would also recommend the book Head First Design Patterns to get started on learning how to design software (as opposed to just writing software).

I would agree with what a lot of people have been saying, though. The best thing that you can do is put what you know in to practice. Start out writing a small application for yourself. Write unit tests.Do some code coverage analysis on the code and make sure you are completely covered. You can start with Cobertura. Get to know what APIs are available in JSE. I'm assuming that in an academic environment you are using the latest JSE (6), so I would also look into familiarizing yourself with JSE 1.4. There are some major differences between 1.4 and 5 (and not a whole lot of major differences between 5 and 6), and if you are working on legacy code in the future, it helps to know what differences there are. Write an app in whatever you are used to using, write it again with JSE 1.4. Check out an open source project and debug it. Get code coverage on the project and write tests to cover more lines of code. Most OSS projects would be happy to integrate tests that increase their code coverage. Look through the bugs that have been logged against the project. Pick something small, fix the bug, and submit patches. Get familiar with build systems like Maven 2 or ANT. That should keep you busy until next semester.

No I am well aware of the role that corporate contributions have played - like IBM's help with Apache, etc.

Are you really well aware of the role that corporate contributions have played? It's much more than one large company helping out with one project. The Apache Software Foundation and Free Software Foundation have significant corporate sponsorship. 75% of Linux kernel code is written by paid developers. Continued Firefox development is made possible via search royalties. Red Hat is significantly involved in many of the projects that make modern Linux systems useful.

I seriously doubt open source software would be anywhere as near as useful as it is today without the extensive corporate sponsorship and contributions. I don't think it'd be very competitive outside of perhaps academia.

However to expect a corporation to fund a project indefinitely is ludicrous

I didn't say otherwise. I really don't care about accessible open-source software.

We have had a LOT more success with rails, than failure. And we're getting a LOT more done now than before when doing struts/JSP/JDBC style dev.

I'm curious if you have ever tried Apache Wicket. Wicket is yet another framework for Java, and it requires your team to have a solid level of OO programming knowledge because every web page is a hierarchy of components, and to customize behavior, you need to @Override various methods.

I just finished my first iteration of a decent-sized project using Wicket that used many of wicket's components like repeating list/grid views, a custom session with different user types/roles, and some custom components to deal with "edit vs view" modes.

We integrated this project into an existing Spring MVC + regular servlet/jsp web app. Instead of custom JDBC as we did previously, we used hibernate annotations which means no XML nor direct SQL.

Writing wicket was fun; I've had more fun in 3 months of wicket than 2 years of "regular" java. The learning curve was steep, as I spent days solving what later seemed simple problems, but I learned a lot. Future iterations of this project will be quick. Overall, I say medium to large projects will take much less total time from concept to stable delivery using wicket versus other java web methods.

I've not tried Ruby, ROR, JRuby, nor Grails, so unfortunately I can't compare wicket to any of them. But it sure beats Struts, Spring MVC, and JSTL/JSP. Wicket does not allow any logic in the view -- you use plain xhtml+css (with a wicket DTD while designing for validation), and use java code to do everything else, including ajax. So a web+css+javascript master can bust out a prototype/mock-up, and a few wicket programmers can tie in the back end logic. When maintaining, the web designer can open the plain html+css (in their favorite editor) and modify it as needed, without any code in the way.

Wicket is a neat technology, with great security (url encrypting, server-side validation with ajax) and good performance.

    You're very correct on that.

    For a while, I was doing that with a few things, including Apache and the Linux kernel. There were pieces I needed that didn't progress, so I handled my own backporting of various things. That was a long time ago, and those problems were resolved in more current versions, so it hasn't been necessary for years.

    But, if you're using say mod_ssl to handle your SSL on Apache, and you're still in the 1.3.x tree, you'd now be scored down. Apache just moved the 1.3.x tree to 1.3.42 (which was mentioned on here recently), but mod_ssl only has their patch for 1.3.41. I haven't checked to see if they're compatible yet, but for the sake of argument, lets say that it isn't. If I had these in production, and I didn't upgrade to 1.3.42, I'd now score badly, even if I applied the security patch which is what the difference between 1.3.41 and 1.3.42 is. All I'd have to do is ask it to say it's Apache 1.3.42, or even say something stupid like IIS 7.5, if I really wanted to throw off any attackers. Sometimes it's better to announce the wrong thing, just to distract potential attackers. By announcing IIS, they'd try their suite of Microsoft attacks, rather than Linux attacks.

    Oh, and god forbid you were to do a little honeypot action on your production machines. If you were to put a daemon listening to port 23 (Telnet), to automatically block potential intruders (Connected to port 23? Set an iptables rule immediately), they'd see that port 23 was open, and pitch a fit. That's actually a good security idea, although I don't see it used much in the real world.

* One way to work around this is to use a non-standard port (4443 instead of 443, for example).

http://incubator.apache.org/incubation/Incubation_Policy.html

http://incubator.apache.org/guides/proposal.html

http://incubator.apache.org/incubation/Incubation_Policy.html

http://incubator.apache.org/guides/proposal.html

"From most of the Linux advocates I hear commenting on slashdot, there AREN'T bugs or missing features in Linux. So why the developers? ;)
...
I like Linux and have no problem with devs getting paid to work on it. Sound slike a good idea to me; in fact, it sound slike how almost every single product in the world is made, pretty much. That has a user base over like 2. :)"

Accolades on choosing an appropriate SlashID:

• Most of the work in kernel development is in driver development
• We experience time linearly, so being the first to support USB 3 had to wait until USB 3 actually existed for example
• You are referring to Linux distributions as if that is the same as the Linux kernel
• Linus Torvalds, and most of the developers, didn't get paid to develop Linux until it became very popular
• Many, many, many very popular FOSS solutions exist that are very popular and were developed by people who WERE NOT paid to do it. Have you ever heard of Sendmail? No? Well then how about Apache?
• Smiley emoticons intended to indicate snide cleverness are best reserved for those rare occaisons that you actually say something clever
• I went easy on you

Does this endanger the Hadoop project, or projects using Hadoop? Its MapReduce implementation is a rather crucial part.

Does this endanger the Hadoop project, or projects using Hadoop? Its MapReduce implementation is a rather crucial part.

A somewhat optimistic guess is that they'll be restricted to using this defensively. Are they really going to sue Hadoop, the open-source implementation of MapReduce? Hadoop not only implements a version of MapReduce, it even uses its name, so is not at all coy about being a direct infringement of this patent. And yet, I would be surprised if Google sued them, or the many people using it. They certainly haven't said anything yet, as far as I can find--- when things like Amazon Elastic MapReduce were launched, I can't find record of Google saying, "hey, you're stealing our tech!"

A somewhat optimistic guess is that they'll be restricted to using this defensively. Are they really going to sue Hadoop, the open-source implementation of MapReduce? Hadoop not only implements a version of MapReduce, it even uses its name, so is not at all coy about being a direct infringement of this patent. And yet, I would be surprised if Google sued them, or the many people using it. They certainly haven't said anything yet, as far as I can find--- when things like Amazon Elastic MapReduce were launched, I can't find record of Google saying, "hey, you're stealing our tech!"

But it still DOES starts the encrypted request all over again.

Not all over again. Nowadays, subsequent and parallel SSL/TLS connections are quicker than the first, because certain SSL session parameters can be cached and don't need to be renegotiated. The web server needs to be setup to support this, but I expect Gmail already is.

As per http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/README the proposal (Full disclosure: I'm colm@apache.org - the proposer), was that we would start distributing security patches via; http://www.apache.org/dist/httpd/patches/

Thanks, colmmacc.

As per http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/README the proposal (Full disclosure: I'm colm@apache.org - the proposer), was that we would start distributing security patches via; http://www.apache.org/dist/httpd/patches/

Thanks, colmmacc.

That's what Apache presently does with the Win32 versions for deprecated Windows releases.

(Note the unsubtle hints that Apache for Windows never was a good idea.)

As per http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/README , the proposal (Full disclosure: I'm colm@apache.org - the proposer), was that we would start distributing security patches via;

    http://www.apache.org/dist/httpd/patches/

The main point is to reduce the overhead and burden of creating full releases. Releases take a large amount of community involvement and time, and are becoming impractical. The 1.3.x branch does not even build on many modern platforms - for example the configure script is incompatible with dash and there is a getline() function which conflicts with a glibc neologism.

Hope that helps.

As per http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/README , the proposal (Full disclosure: I'm colm@apache.org - the proposer), was that we would start distributing security patches via;

    http://www.apache.org/dist/httpd/patches/

The main point is to reduce the overhead and burden of creating full releases. Releases take a large amount of community involvement and time, and are becoming impractical. The 1.3.x branch does not even build on many modern platforms - for example the configure script is incompatible with dash and there is a getline() function which conflicts with a glibc neologism.

Hope that helps.

lern 2 internets

Apache is catching up - SNI support was committed to 2.2 in May. I just guess it'll take a while for this to filter out to all distros and then to server operators.

There's a good update on this blog

I think 2038 is a nonissue.

In this case it really is as this rule is due to be removed in future releases of SpamAssassin, for details see: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6271

score FH_DATE_PAST_20XX 0.0

You'd probably be better off changing the rule instead of the score. Putting something like:

# Fixes bug: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269
header FH_DATE_PAST_20XX Date =~ /20[2-9][0-9]/ [if-unset: 2006]
describe FH_DATE_PAST_20XX The date is grossly in the future.

in your local SA config would probably be better (unless you really want to just drop the rule entirely).

That said, you'd probably be better off updating everything with sa-update, but this fix works in case you cannot or don't want to do that.

But the Y2K+10 bug is here. If your mail is sorted by SpamAssassin, there's a good chance you have some false positives in the spam folder: SpamAssassin assigns spam points to mails where the year matches /20[1-9][0-9]/ because the year is "too far in the future". Oops.

You'd think developers learned from Y2K, but:

Spamassassin Bug 6269 - FH_DATE_PAST_20XX scores on all mails dated 2010 or later.

Every mail that has gone through Spamassassin since midnight gets a spam score because "the date is grossly in the future." And what's worse, they "fixed" it five months ago on the trunk (not in any released version)... by changing the cutoff year to 2020.

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269

Tell me, how do you not log the data that passes through a server?

Well, duh, most obviously, you can turn off logging or write to /dev/null. But beyond that, as you say, it's nice to have logs in case something crashes. But that doesn't mean you have to log everything! If you're using Apache, you have control over what goes in the log file, as documented here, and if you, for example, omit "%h" from your log string, there will be no record of the IP that sent the request.

In practice, it gets a little more complex than that, but the bottom line is that there is no legal requirement to log everything or to keep the logs. You can omit IPs from your logs, you can delete old logs after an hour, you can do all kinds of things.

I'm not saying that I would necessarily trust anyone to not log me; I'm just saying that I can not log you if I want, on my servers. If Google wanted to, they could do it too.

Why does the world need a non-free web server that only runs on Windows when there's already plenty of free (as in speech) ones out there (http://www.apache.org/, http://www.lighttpd.net/) that run everywhere?

Please compare

http://home.hccnet.nl/th.v.d.gronde/inkscape/ResultViewer.html

to

http://xmlgraphics.apache.org/batik/status.html

My standards actually are based on some standard.

I was excited when I saw 'svg test suite compliance' in the release notes, then I looked at the test results. The omit a large portion of them and fail a massive chunk of them.

A new feature in the release notes is 'Initial SVG font support' ... Inkscape is roughly the same as using Frontpage 2000 to make web pages. Sorry I got your fanboy panties in a bunch, but reality sucks sometimes.

You know, F/OSS is more than GNOME. There is a lot of innovation going on in the F/OSS universe. It has always been this way and I'm willing to bet it will always be that way. That you don't see it says more about you than about the F/OSS universe.

And yes, F/OSS projects copy things from proprietary software, too. And this is a Good Thing. After all, one of the most heard complaints about F/OSS is that it doesn't have whatever it is the complainer wants to have that they do have with their proprietary software of choice. Well, the likes of OpenOffice.org, KDE, GNOME, and many others cater to those wishes.

If you want something original and open source, there are numerous examples. Many features of modern Unix were pioneered in the open-source BSD, many others are pioneered in Linux (e.g. several filesystems), the TeX typesetting system was a real innovation, the open source Apache is the world's leading web server, the Python programming language is open source and certainly innovative; and that's just a few examples.

The first sign for me that someone is selling bullshit is when they try to act like this is some never before seen problem, when in fact there is a good four decades of research of database optimization.

Your point is valid, but I think there is more to it. And the problems these solutions try to solve are quite old too. For example:

Ever tried to design a database, but got the requirement that you should be able to reconstruct the modification history? It boils down to not deleting (ever), and 'deleted' flag fields and other uglyness. A multi-version relational database would be nice, you actually don't need modification/delete operations in this scenario, just 'updates' that add to the previous status. CouchDB does append operations.

In some cases you may not need a complete SQL database, just key->value relations, but have them scaling very well. http://project-voldemort.com/ states: "It is basically just a big, distributed, persistent, fault-tolerant hash table." Then they state that they provide horizontal scalability, which MySQL doesn't (OTOH, we should really look at Oracle for these things).

And you can't really say MapReduce/Hadoop is pointless.