Ok, everybody and his/her brother has blogged about Linq already so why not ramble some words about linq here? .
First, Linq itself. Linq is cool. It's a system to build language constructs inside C# or VB.NET. For the people who haven't waded through the .docs describing Linq in detail, you can see it as operator overloading on steroids: define your own language constructs with C#/VB.NET language constructs in a typed way, so that you can write simple queries or functions over data, which resolve to your own structures, expression trees, or to plain C#, VB.NET, whatever you can think of.
Ok, so that's cool, we can safely all agree on that.
Now, Microsoft thought... "Hey, everybody is doing that attribute based O/R mapping. Why not do it ourselves?". Together with Linq they build DLink: an attribute based O/R mapper. I couldn't believe my eyes: while every decent O/R mapper moves away from attribute based O/R mapping simply because it's not scalable beyond 1 database, Microsoft moves towards it! .
I understand the reason for attribute-based mapping in their case (meta-data in the assembly, which can directly be used by intellisense, compilers etc.) though it's not very flexible to begin with. To see this, consider a domain object, the ol' dreaded 'Customer', and that you map it on an SqlServer table. You give it a good old Guid PK, a nice boolean field 'IsGoldCustomer' which is mapped onto a bit field etc..
Then your client asks you... "You do Oracle too, right?"
You hear yourself mumble through the phone: "Sure, no problem!"
But, next day, when you're starting to work on a port to Oracle, which should be simple, you realize... mapping information inside the domain object, which contains SqlServer specific elements, isn't usable on Oracle. Why didn't you opt for a system which didn't use attribute based O/R mapping!
It's a preview of course, and there's a long road towards final code, but, take it from the field, Microsoft: attribute-based O/R mapping isn't the way to go.