Friday Dec 09, 2005

LISA05 Thursday: Booth and panels

While I've been listening to various talks, other folks have been answering questions about Solaris, the new systems, and other Sun products in our booth on the vendor floor. We have a double wide, and it was busy whenever I passed by during session breaks:

Busy booth

In addition to the engineers I've mentioned were here, Cindy Swearingen, who is one of the lead technical writers for the Solaris System Administration Guide, handled many inquiries. She's manning the center table here:

Cindy has the conn

There were new Opteron and UltraSPARC T1 systems in the booth; Jonathan has a conversation, with the T2000 ("Niagara") system in the foreground:

Near Niagara

Let's look closely at the Niagara box:

Inside Niagara

I do like the aluminum cases, although I'll always have fond memories of entering datacentres with racks upon racks of wine-coloured systems.

Finally, if you poked around, you might have got a demonstration from Dave or David of some ideas in smf(5) visual administration:

smf visualization demo

That's real code and a live graph, by the way.

[ T: ]

Thursday Dec 08, 2005

LISA05 Wednesday BoF

After a rapidly served and consumed dinner at Taste of Thai, the Solaris BoF squad headed back for the Wednesday session at 9 pm. The room filled up fast, with some folks ultimately having to stand in the back:

Room fills for Wednesday BoF

I decided to spell Jonathan as T-shirt gerbil, and was happy to give out Sara's OpenSolaris ringer Ts and the new Inside Jack shirts in exchange for good questions or smart remarks.

Next time we'll be sure to order XXL sized shirts.

Dan mentioned that his laptop was spallating, or emitting shrapnel, or something like that, but he and Bill managed to get both their presentations to share what little functionality remained.

Laptop appeasement

After Dan did a great job covering the coming work in the near future of Solaris, Bill took the stage for a two hour thorough overview of ZFS.

Bill on zfs

Even after two hours and many answers dispensed, Bill fielded midnight questions with enthusiasm.

Persistent questioners

Nice camera awareness on Bill's part.

[ T: ]

Monday Nov 07, 2005

Program technical status, 7 November

[Repost from forum thread.]

It's been two months since my initial status message, which is probably a bit too long. Most of the efforts I mentioned in that update have made progress, so it's worth mentioning their current status:

1. Elementary project hosting support.

The web site development for simple project hosting is underway. At present, those enhancements are expected for delivery sometime in December. (You may have noticed that a number of issues with the site were recently fixed.) In parallel, we are attempting to eliminate some of the manual steps in community and project creation.

2. Source code management (SCM), first phase.

The first phase of source code management involves adding Subversion hosting for individual projects and for the ON consolidation to publish ongoing changes in a read-only Subversion repository. Prototyping for the former has begun, but is dependent on the elementary project hosting work.

The first phase of source code management involves adding For ON, Stephen Lau has been experimenting with publishing a "squelched" SCCS history; you can see the result of Chandan integrating this work in the latest release of the source browser. For instance, here's a file with some recent revisions and also the squelched history:

http://cvs.opensolaris.org/source/history/on/usr/src/cmd/svc/configd/configd.h

This work, along with some SCCS and TeamWare insights gleaned by Alan Burlison, is expected to be the basis of any SCM migration we pursue, as well as for the short term read-only Subversion publication.

3. Partitioned ON source tree.

The partitioned ON source tree is undergoing internal code review--internal only due to the encumbered code involved. Mike Kupfer gave much more detail in a recent blog entry

http://blogs.sun.com/roller/page/kupfer?entry=on_the_road_to_nightly

As noted in my previous update, a partitioned tree means that projects can issue public source drops of their development code, and get proper community development going.

4. ON GCC readiness.

Bug fixes that eliminate GCC warnings have continued to integrate into the Nevada gate. As a result, we're now able to finish drafting a cleanliness policy for integrations and making the tools changes to support them. This policy will be discussed in the Tools community, once the draft is complete.

Because we've been making progress on those initial items, new aspects of the program will receive more attention. The two new areas of focus are discussed below.

5. Governance development.

The development of the governance for the OpenSolaris community is being led by the CAB. One effort in support of that has been creating a document articulating the engineering values that go into OpenSolaris software, as well as a process that contributors can follow that results in the production of such software. The most recent draft of the development process is available as HTML

http://www.opensolaris.org/os/community/onnv/os_dev_process/

or as PDF

http://www.opensolaris.org/os/community/onnv/os_dev_process/d-devproc-alpha.pdf

If you're subscribed to cab-discuss, you know that drafts of the charter, which transfers responsibilities for OpenSolaris to the community from Sun, are being vigorously discussed in that forum. We're attempting to keep the various stakeholders engaged so that the charter document can be completed and ratified promptly.

6. SCM, second phase.

The evaluation of a distributed SCM solution will be pursued directly now. I'll be issuing draft requirements and an initial candidate list very shortly; this discussion will take place in the Tools community, although I'll send a notice to opensolaris-discuss.

In terms of source releases, I thought I should also mention that libm, the C math library, was released in binary form in the past month. Cleaning up the source code for release is in progress. And, as I mentioned in another thread, team members have reviewed the packaging tools source and are working out whether a two step release is needed there as well. The Java Desktop System consolidation successfully published their code last week; other consolidations are getting close to releasing their trees as well.

As always, please share your concerns; I am happy to receive them privately or on the list.

[ T: ]

Friday Oct 28, 2005

opensolaris.org: Java Desktop source release, and scfdot, too

As Glynn just blogged about it, I'd like to congratulate the JDS team (and the Desktop Community) on releasing the source to the Java Desktop System on opensolaris.org. In particular, I want to mention the build instructions, which provide a very clear starting point for those interested in exploring the source and how to build it.

I also wanted to point out that not only is a newer graph of the smf(5) services available:

but that, courtesy of David and Dan, you can now generate your own, using scfdot. Visit the smf(5) community if you're interested.

[ T: ]

Friday Sep 09, 2005

Program technical status, 9 September

[Reposted from forum thread.]

I've had a few weeks to get oriented and thought I would bring folks up to date on the work we intend to pursue in the short term. My primary concern after an initial survey is creating additional infrastructure to get currently internal-to-Sun projects and conversations out in the open, on the opensolaris.org site, before the development phase of Nevada closes, and we move into a more limited Beta phase, where project work starts to focus exclusively on integration readiness.

That is, even though we are working to define and transition to a community development process and governance model, I don't want the absence of the documents describing such things to be an excuse for not moving conversations outside. Accordingly, we are working on a number of items that eliminate that excuse. I'll start with the general items, and then some specific to the ON consolidation.

1. Elementary project hosting support.

Typically, in terms of communication, projects inside Sun are very similar to projects we see in open source efforts: they have web pages, mailing lists, and download areas. (Some may also have IRC channels, Wikis, and blogs.) Much useful conversation and experimentation can take place using only these media, and so I want to get basic project hosting functionality up on opensolaris.org.

Projects that prefer to host elsewhere can use this facility as a pointer to their primary site, so that they appear in lists of OpenSolaris-related work.

2. Source code management, first phase.

The Code Manager ("TeamWare") distributed source code manager (SCM) has been in use at Sun for over twelve years; its predecessors were also distributed SCM solutions. It is difficult to envision how we might move the current practices of the consolidations using TeamWare to an SCM that doesn't match up well with the features and extensions that have been in use for so long. However, TeamWare itself has deficits when we consider its use on the open Internet (and even within Sun's wide area network).

In order to make progress, and in order to support new and current projects and consolidations that are not tied to TeamWare, I believe that we must offer a centralized SCM facility while the current set of open source distributed SCM solutions are evaluated against criteria based on TeamWare's use within Sun and on suitability for use on an Internet-hosted site. Luckily, recent developments in the SCM space suggest that one or more SCMs may meet many of these criteria already. A draft set of criteria will be published shortly, after which candidate SCMs will be evaluated against them.

The proposed centralized SCM solution is Subversion, based on features, ease of integration, and community vigor. Information on Subversion may be found at

http://subversion.tigris.org/

Tools to make the source drops of TeamWare-based consolidations available via a read-only repository will also be found/refined/developed. We will publish a representation of ON via a read-only repository during this phase.

3. Partitioned ON source tree.

A number of ON-based projects are ready to share their development versions, in code form, on the site. However, the current source publication process for ON is too arduous to expect individual projects to use team member time to handle their own publication. We are thus partitioning the source tree into open ("usr/src") and encumbered ("usr/closed") subtrees, so that projects can easily publish and independently buildable open tree containing their changes. This work is already underway.

4. ON GCC compiler readiness.

Steady progress is being made to make ON builds GCC warnings free. As we are now closing in on a warnings-free build, we will be examining the current build tools to make GCC clean (or, if you prefer, alternate compilation clean) an ongoing requirement for integration, without being an undue burden on contributors. There are numerous possibilities that are opened up by a GCC build, but the primary justification for the present work is that it finds bugs prior to integration.

There are, of course, many other activities going on: Karyn's list of consolidation priorities hints at what additional code is nearing openness, creation of additional website content, the already mentioned development process and governance and charter work, and the publication of ON source drops. (Plus work in community building and support, marketing efforts, ...) I thought I should call out that we have added additional sponsors for ON and that John Beck has been working to close some gaps in sponsor technical coverage, so that code fixes submitted during this interim phase don't get chilled waiting for a sponsor.

Feedback welcome. I'll read it all, but I can't promise replies to all.

[ T: ]

Tuesday Sep 06, 2005

Reexamining OpenSolaris technical concerns

I've recently rejoined the team working directly on the OpenSolaris effort. The past few weeks I've been getting caught up on where Open is with respect to a number of areas, both technical and process. During my survey, I've been pleased to see how good the current technical team ("I-team", or implementation team, in local software development framework-speak) is—they've got a handle on the complexities of delivering the nearly 36 000 files in the ON consolidation in a partitioned, cleansed form, and are spending a good chunk of time so that the other major source trees that make up Solaris ("consolidations") don't have to reinvent these procedures themselves.

There are a number of technical topics—involving how we develop software—that I want to visit over the next few weeks in this blog, because it seems like a reasonable way to describe some of the key aspects to what we're doing now and lay out the set of issues that need to balanced in any effort to make a principles-driven community development process. For instance, a short list of topics would include at least

  • multiple compiler support implications,
  • "shrink to fit" architectural processes,
  • source code management requirements and options,
  • programmatic facilities at opensolaris.org ("web services versus web pages"), and
  • workflow tools and support, on and off the site.
And probably some other things that are worrying me (like how to keep up with a few hundred additional email messages per day, above the few hundred I was already receiving).

That said, I am happy to hear your concerns, hopes, fears, and speculations about OpenSolaris, and email is, of course, fine.

[ T: ]

Wednesday Aug 10, 2005

smf(5): Identity Manager conversion

Scott Fehrman's written a detailed conversion of the Sun Java System Identity Manager to use smf(5). In Scott's scenario, the Identity Manager runs inside Apache/Tomcat and uses MySQL as the backing database; Scott discusses both service and their dependencies as he constructs the manifests.

See BigAdmin for Scott's article.

[ T: ]

Friday Jul 15, 2005

smf(5): Manifest destiny, Round One

I received polite mail this morning reminding me that I have mugs to ship. I got distracted during break, but we'll be boxing up the mugs and getting them to the authors. So, for Round One, here is the set of submitted service manifests submitted to date:

application/informixInformix Dynamic database serverPrasad JampalaUSA
application/mysqlMySQL database serverKeith LawsonCanada
application/oracle/[database]Oracle database controlJoost MuldersNetherlands [Sun]
application/oracle/[listener]Oracle listener Joost MuldersNetherlands [Sun]
[application]/popfile[POPFile mail classifier]Iouri GoussevCanada
[application/print]/cupsCommon Unix Printing systemBoyd AdamsonAustralia
[application/print]/xprintX Window System Print serverPeter ErikssonSweden
[network/ident:pident]pident IDENT daemon Gary MillsCanada
[network/nntp:inn]INN NNTP server Gary MillsCanada
network/ntp:openntpOpenNTPD daemon Todd CarsonUSA
network/[smtp:postfix]postfix SMTP MTA\* Ben RockwoodUSA
network/[smtp:qmail]qmail SMTP MTA Iouri GoussevCanada
network/txpi:tcp]TXPI TCP Hans van MaarenThe Netherlands
[network/xcom:default]CA-XCOM data transportHans van MaarenThe Netherlands

\* Ben's Postfix conversion is very simple, and works if postfix is in root's default path; in contrast, Peter Tribble built a full stack of mail processing atop Postfix in smf(5) a few months back. Plus they both have mugs already.

We're now in the process of assembling all of the manifests we know about at the OpenSolaris smf(5) community. If you sent in a manifest without a URL, it would be preferable to give us a link to it, and to give it a copyright and (OSI-approved) licence. (Send me mail if this appears confusing or is difficult.)

Suggestions for Round Two (beyond PostgreSQL and the other database management systems) are welcomed!

[ T: ]

Friday Jun 24, 2005

OpenSolaris BoF at JavaOne

On Monday evening, a few of us—Bryan, Mike, Adam, and myself (plus others, I hope)—will be hosting an OpenSolaris birds-of-a-feather session during JavaOne. The BoF, Java™ Technology on the OpenSolaris™ Platform", will be from 1930 - 2020 in Golden Gate B1 at the Marriott Hotel.

With Team DTrace there, the BoF should be an additional opportunity to ask questions about some of the preliminary Java–DTrace instrumentation techniques and how that might apply to your programming problems. (Of course, you should go to Adam's session for the full story first.) I'm there for a different reason. As Dave mentioned, we're planning a set of classes to make the smf(5) functionality available from the Java platform. It turns out that these might be the first public Solaris-specific Java interfaces we publish, which means we've reached a small unexplored architectural area. To start surveying this terrain, I need to ask the community a couple of questions:

  • What else can we do to make Java a first class systems programming language for Solaris?
  • For instance, what other classes, defaults, or conventions should we offer or modify to make Solaris-based Java development easier/more capable/more fabulous?

Of course, you don't have to go to JavaOne to make suggestions—feel free to make them here. But if you're at the conference, please drop by and make your points in person. The BoF details once more:

Java™ Technology on the OpenSolaris™ Platform

Monday 6/27
7:30-8:20pm
Golden Gate B1
Marriott Hotel

Hope to see you there.

[ T: ]

Monday Jun 20, 2005

Manifests so far

To ward off unintentional duplication of effort, I thought I would list the service manifests submitted to date:

application/mysqlMySQL database serverKeith LawsonCanada
application/oracle/[database]Oracle database controlJoost MuldersNetherlands [Sun]
application/oracle/[listener]Oracle listener Joost MuldersNetherlands [Sun]
[application]/popfile[POPFile mail classifier]Iouri GoussevCanada
[application]/xprintX Window System Print serverPeter ErikssonSweden
network/ntp:openntpdOpenNTPD daemon Todd CarsonUSA
network/[smtp:qmail]qmail SMTP MTA Iouri GoussevCanada

I hadn't heard of POPFile before, but a multiple bucket mail classifier might be the only way for me to keep up with opensolaris-discuss@opensolaris.org.

I've read each of the above manifests quickly, so I'm confident we'll be sending out mugs to each author—yes, even to you, Joost. We'll do a detailed read, send some suggestions (like my first thoughts on service names), and publish links at the contest end. Keep the manifests coming.

[ T: ]

Wednesday Jun 15, 2005

Contest progress; smf(5) discussion

I've been happily receiving submissions of manifests for various services over the past few days. With all the traffic around other news, I believe it only fair to extend the "Manifests sans frontierès" contest to Canada Day (1 July), so that we can all monitor new mailing lists, more vigorous IRC discussion, track countless tags and feeds, and generally commune, and still write some useful code.

benr: I have an Oracle submission in hand.

One of those new forums is smf-discuss-AT-opensolaris-DOT-org, where we'll be having development discussions about smf(5). There's big stuff and little stuff to do, so if you're not certain where to start or are looking for ways to contribute, come talk with us—our learning curve is relatively gentle.

To subscribe, send a blank message to smf-discuss-subscribe-AT-opensolaris.org.

[ T: ]

Tuesday May 10, 2005

Pop-up papercasting

I think papercasting is amusing. A lot of my work at Sun is critical in nature, meaning I feel much of my added value comes during the review phase of various documents (whether that document is text or code). A week ago, I spent a morning working on paper while my car was being serviced; as a typical engineering interval, I thought my working notes might be of interest to someone.

Reading them over, I realized that the notes rely too much on my context, which papercasting wouldn't fix. Hence, a little browser scripting and pop-up papercasting becomes a way to fill in the background on what some of the tasks mean.

Move your cursor into each target to see additional information about that term.

<script src="http://blogs.sun.com/roller/resources/sch/pcast.js"> </script> <script> lastVisible = document.getElementById("caption_20050505"); var a = document.getElementById("pc_20050505_javacity"); a.onmouseover = pcast_over; a.caption = "caption_20050505"; a = document.getElementById("pc_20050505_lamy"); a.onmouseover = pcast_over; a.caption = "caption_20050505"; a = document.getElementById("pc_20050505_arc_contract"); a.onmouseover = pcast_over; a.caption = "caption_20050505"; a = document.getElementById("pc_20050505_manifest_hash"); a.onmouseover = pcast_over; a.caption = "caption_20050505"; a = document.getElementById("pc_20050505_jwadams_review_0"); a.onmouseover = pcast_over; a.linkedTo = new Array("pc_20050505_jwadams_review_1"); a.caption = "caption_20050505"; a = document.getElementById("pc_20050505_jwadams_review_1"); a.onmouseover = pcast_over; a.linkedTo = new Array("pc_20050505_jwadams_review_0"); a.caption = "caption_20050505"; a = document.getElementById("pc_20050505_pizza_lunch"); a.onmouseover = pcast_over; a.caption = "caption_20050505"; </script>

[ T: ]

Monday May 09, 2005

smf(5) in Hungarian

Introducing people to smf(5) can't be limited to English-speaking audiences—everybody needs to know how the system works. On blogs.sun.com's lesser-known sibling site, mediacast.sun.com, Cserép János has posted his Hungarian introduction to smf(5).

In case you couldn't guess, szolgáltatások means service.

Tuesday Apr 26, 2005

smf(5): Chairman's Award

The smf(5) project team was honoured with the Chairman's Award for Innovation today, along with 14 other teams or individuals at Sun. I had a camera with me, and snapped a few pictures but, since the award ceremony was televised, don't have any from that part of the day. Afterwards, we gathered in the Menlo Park campus's amphitheater [TerraServer] for some photos. I managed to capture

the smf(5) team;

our sister team in Predictive Self-Healing, the Fault Management Architecture team; and

the CDDL team (but after they started to move towards one end of the amphitheatre).

We had a short lunch afterwards, but longer conversations with the other award winners, the nominating committee members and other executives:
mws brandishes cup

I borrowed our newer Canon PowerShot SD300 for the day, because it's so much smaller than the S30. I had a little trouble with gphoto2, but I put the SD card directly in the slot on my Acer Ferrari running S10—which mounted directly and seamlessly.

smf(5) was the product of many people's contributions. There are team members who could only participate for a limited period or who are no longer at Sun, and many forms of contribution from all parts of the company—the end result couldn't have been reached without all the shared and distributed lifting. My thanks.

A small and quiet thanks to Jonathan for gesturing me into the studio camera's field of view.

Friday Apr 22, 2005

Adrian explores libexacct

Adrian Cockroft has been exploring the extended accounting streams available in Solaris. By blogging about his exploration, Adrian is sharing his cognitive process—highly valuable to, say, the designer looking to improve a software subsystem for developers. I was amused by the following frustration-induced comment

The design is so abstract that it seems that reading meaningful data out of the log file is some obscure side effect of the code. You can read the data, but there is no guarantee that any specific item of data will be present. The accounting system has various options to send more or less data to the file, so it needs to be flexible, but the important thing is the meaning of the data being logged. I care about the semantic and informational content of the data source. What I get from exacct is "there are some tagged typed objects in this file". I can't consume the data without making assumptions about it, and the API doesn't embody those assumptions.
because some of these drawbacks were design goals: exacct is a general purpose, variable-length, grouped binary record format affording traversal in either direction through the file. I think Adrian's criticism is valid (except that it was always meant for reading and writing data) if I read it as you haven't written the accounting data handling layer yet.

While I wait for some time to think about how we might do that, I've filed

6260320 \*wracct\* should have some form of "for all objects" support
so we can fix at least one annoyance.

About

sch

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
External blogs