A multilevel view of DevOps (with more balance)
My take is that DevOps Means Don't Be An A-Hole. That's kind of a compliment to what you are saying I think - devops is about improving communications.
I don't think it's this simple. Instead I think that the broad label of 'DevOps' is a reaction to three different sets of organizational problems, which I am going to list in decreasing order of severity.
First is the blame problem, where developers get blamed for not delivering features and operations gets blamed for services not being available. If you have the blame problem it trumps everything else, because the interests of developers and operations are fundamentally opposed to each other. All of the communication in the world cannot fix that.
Next is problems of ignorance, where development and operations don't understand each other's environments, problems, and constraints. It's stereotypical for sysadmins (me included) to see this as primarily a development problem where developers have ignored issues like installation, logging, performance, and operational reliability, but I'm sure that there's things about development that operations doesn't get. Fixing this requires education and possibly making development and operations care enough about each other's problems to get that education.
(See Tedd Dziuba for some ways to make developers care.)
The final set of problems are cultural ones, where the two groups are assholes to each other mostly because that's how they've always behaved and it's just how operations and development deal with each other. If this is your only 'DevOps' problem, you can indeed fix it with just better communication and more respect.
(The quibble here is that sometimes cultural issues have roots in things like the amount of respect and pay that goes to various groups, because people are people.)
Each level of organization problem creates the levels of problems below it (unless you're really lucky and have a staff of selfless, motivated saints). An organization with the blame problem is going to have cultural problems and almost certainly ignorance problems; an organization with ignorance issues is going to grow cultural ones. It follows that you need to fix problems from the top down in order to make lasting changes.
(Yes, this is a more balanced view of DevOps than my first entry on it. Sometimes I run a little bit too hard with an idea.)
Oracle shows its appreciation for long-term Sun customers again
I suppose that this is not exactly news, but I noticed recently that as part of its 'transition' of sun.com (aka getting rid of sun.com), Oracle has of course gotten rid of docs.sun.com as well. Just as they've done with other sun.com properties, there are no specific redirections for old docs.sun.com URLs; all URLs now wind up on a generic Oracle documentation website.
So let me summarize that: Oracle broke all old links to Sun documentation.
All of those links to Sun docs that are in our documentation and notes, and perhaps yours as well? Dead. All of those links on people's web pages that say some variant of 'and here's the official documentation for more information'? Dead. All of those URLs for manuals that you were going to get around to reading sometime? Well, you get the theme here. This is an especially annoying situation for docs.sun.com because the documentation URLs that Sun used were so meaningless by themselves. If all you have is an old URL, you probably now have essentially no chance of figuring out what manual it went to so that you can look it up on the new Oracle documentation site.
I'm aware that this is nothing new for old Sun URLs, and that some of the things that have happened as a result are much more annoying and troublesome. It's just that for some reason, this particular set of URLs going away really gets to me (partly, I admit, because I have some links to Sun documentation in WanderingThoughts entries, links that are now dead).
(For a somewhat more important example, ZFS error status URLs now redirect to something that wants you to log in to Oracle's support system. They may or may not work after you do that.)