Wandering Thoughts archives


More signs of Oracle's view of Solaris

Well, that was fast. Back in ReadingSolarisTeaLeaves I wrote:

Any free version of Solaris 10 is now basically a sampler, much like Oracle has done with a personal use version of their database, and I wouldn't be surprised if the Solaris license was revised to reflect that in a while.

When I wrote this, I was thinking 'in six months or so'. In fact it was less than a month; as Ben Rockwood wrote recently, Solaris is no longer free to use. You can evaluate it for 90 days, but after that you need a paid-up support contract. It seems that Oracle's view of Solaris's future is getting clearer and clearer.

On the one hand, this doesn't directly affect us; the university has a long-standing general support agreement with Sun, so we're covered. On the other hand, this agreement is renewed on a year to year basis and who knows how much Oracle is going to want for it when renewal time comes around. It would be quite easy for Oracle to price support out of our reach; we can't afford 'enterprise production' costs and even prices like a thousand dollars a year per system would be gulp-inducing.

(It's possible that Oracle has already announced general Solaris support prices, but as usual it's not easy to find this thing on the revised Sun/Oracle website, so I have no idea. All I could find right now was a blurb on 'Oracle Premier Support', which doesn't exactly sound inexpensive.)

I'd like to think that Oracle wouldn't throw away easy money by pricing their support offerings out of our reach, but I'm not that naive. There are all sorts of reasons that Oracle might set quite high support prices, including discouraging small organizations from running Solaris because they cost too much to support in the long run. Also, various Oracle people have apparently said that they view Solaris as their high end offering and, well, high end offerings mean high end prices.

solaris/ReadingSolarisTeaLeavesII written at 23:50:39; Add Comment

My theory on why our worklogs work for us

I mentioned in the last entry that 'worklogs', email reports of what we've done on our systems, work for my current job here at the university but did not really work for my previous job, to the extent that we fell out of the habit of writing them. As it happens, I have some theories on why this happened; in fact, I think that there are two important contributing factors, one technical and one cultural.

The first is that we have an official search interface (and private on-web archive) of our worklogs. This makes them actively useful; they are not rarely consulted, essentially make-work history, they are live reference documentation that other people can and will actively use. This creates a strong cultural pressure to keep writing them.

(It also makes it easy to refer to previous worklog messages, since each has an archive URL, and in fact it's common for worklog messages to refer to previous ones for context or fuller explanation of procedures or whatever.)

The other reason is that worklogs are a communication method between members of the group and this communication is necessary because we are not siloed into little independent areas and projects; we all work on pretty much all areas of our systems. This is very definitely a cultural issue because my previous job wound up being relatively strongly siloed, where each person had their distinct speciality that only they worked on.

(My current job is culturally anti-silo, in fact, in that people actively try to become familiar with areas that others are working on and are uncomfortable with one person being, say, the email specialist. This doesn't mean that we always achieve perfect parity of knowledge and capabilities (and I'm not sure it's even possible), but we do try to make gestures that way.)

sysadmin/WhyWorklogsWorkForUs written at 02:00:43; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.