[tjfontaine]

I think it's great to see someone writing a new manager that is inspired by SMF.

I would love to see a (series of?) blog post(s) about SMF. This wouldn't be a missive against systemd, but given that SMF has seen 10 years of production use, it would be a valuable history lesson. Why was SMF needed for Solaris, what was scope of responsibility, why were the abstractions picked, why were its boundaries where they were, and finally what has and hasn't worked for it?

It seems like the technical community would eat that kind of content up.

[vezzy-fnord]

You can start by reading the 2005 Usenix paper which introduced SMF: https://www.usenix.org/legacy/event/lisa05/tech/full_papers/...

I'm fairly certain Oracle blogs about news regarding SMF with relative frequency.

[tjfontaine]

Indeed, there are lot of good resources that came out when it was introduced. But that's not quite the same as someone being able to put the story into context of today's technology and status quo. Ideally the history lesson comes from someone with knowledge of SMF from many angles.

For instance Bryan Cantrill (full disclosure I worked for/with Bryan while at Joyent) was at Sun for the development of SMF, he's had experience using SMF in production, and more recently from his LX Brand work he's been exposed to the facilities that Linux has created to deal with the same sorts of issues.

Bryan is a superior technologist and a hell of a story teller, I'm sure I would enjoy reading/hearing his telling of why things like libproc and contracts were created and how they evolved over time, and if that as any relationship to why SMF is designed and behaves the way it does.

Note, Bryan is just an example -- there are many other people in the community that were there and could tell the stories. He's just the first person I thought of.

The point is that [re]creating interfaces/subsystems is ok, so long as we do that with the full view of history, such that we avoid that repeating cliche.

(I prefer run on sentences)