People are always asking "when will I be able to use LINQ against databaseA or databaseB?" and "when will I be able to use Entity Framework against databaseA or databaseB?"

In my mind this is the same question, though most who are asking don't realize it. Why?

An Entity Framework provider gets all of the benefits of the Entity Framework and also gets LINQ for free by way of LINQ to Entities.

If a database vendor wants developers to be able to perform LINQ queries against their database, it's not a stretch to think that they might also want developers to be able to use their database within the Entity Framework.

Why write two providers (a LINQ provider AND an EF provider) when they can write just an EF provider and with it, get LINQ capabilities as well?

An added benefit is that with Entity SQL, it is possible to add provider specific functions.  So when a developer reaches a wall trying to write a LINQ query, the can just step back and use Entity SQL for those cases.

I'm definitely using LINQ to SQL where it makes sense for me. In fact, I'm waiting for a sysadmin to throw .NET 3.5 on my client's web server so I can deploy my first production solution that uses LINQ to SQL!

But for any other db's, I'm not waiting to see who is writing LINQ providers for their databases, but who is writing EF providers (here's a current list, by the way).