It's not dead, but Microsoft is now focused on the Entity Framework.
I've used LINQ to SQL on small projects, and it's quite nice as a lightweight data-layer and i'd consider using it again on similar sized projects. The LINQ implementation itself is really good and until recently much better than the NHibernate LINQ project. On the larger project I used L2S on, I found it hard to come up with a unit-of-work pattern that I was happy with, due to limitations with the L2S 'DataContext' class. Trying to implement something like 'Session per request' with L2S seems either very difficult or impossible.
I also wouldn't really consider L2S as a true ORM, as it really doesn't give you many mapping options. Your class design really needs to follow your database schema (table-per-class) otherwise it will fight with you every step of the way. Another thing I don't like about L2S is the need to use specific types (
EntityRef) to handle collections, references and lazy-loading. This means it's not possible to keep your domain model ORM agnostic without adding another layer of abstraction.
My other issue with L2S is the sole reliance on LINQ to generate queries. The LINQ provider is very well written and generally creates decent SQL for the majority of queries but I have my concerns that there are more complex queries that can't be expressed well with LINQ. Using L2S you basically have to revert to calling stored procedures in these cases, whereas (for example) NHibernate has several API's (LINQ provider, QueryOver, HQL etc) that can be used when you want more control over the generated SQL.
In L2S's defence over NHibernate, there is a lot less overhead in getting it up and running on a project.