Thursday Jul 19, 2007

Observations on packaging

Over the past few months, a bunch of us have been exploring various options for packaging. (Actually, I suppose I've been pursuing this on a part-time basis for a year now, but it's only recently that it's made it to the top of the stack.) I've looked at a bunch of packaging systems, ported a few to OpenSolaris, run a bunch on their native platforms, and read a slew of manual pages, FAQs, blogs, and the like. In parallel with those efforts, Bart, Sanjay, and others have been analyzing the complexity around patching in the Solaris 10 patch stream, and improving the toolset to address the forms of risk that the larger features in the update releases presented.

In the course of those investigations, we've come up with a number of different approaches to understanding requirements and possibilities; I'll probably write those out more fully in a proper design document, but I thought it would be helpful to outline some of those constraints here. For instance, one way to look at how we might improve packaging is to separate the list of "design inputs" for a packaging system into "old" and "new".

When I make a list of this kind, I know it's bound to offend. (I already know it's more scattershot than the argument we'll present in a design document.) Feel free to send me the important inputs I've omitted, as I have a few follow-up posts on requirements—lower level, more specific intentions—and architectural thoughts where I can cover any issues not mentioned here.

"Old" inputs

The "old" inputs are those that are derived from current parts of the feature set around software packaging and installation. Many of these inputs will really be satisfied by the new installer work ("Caiman") Dave's leading, but the capabilities of the packaging system will change some from difficult and fragile to straightforward and robust. With effort, some might even achieve some elegance.

  1. Hands off. For a long time, via the JumpStart facility, it's been easy to provision systems via scripted installed. This technology is still sound, particularly when we consider that the Flash archives allow a mix of image-based provisioning with the customizations JumpStart offered.
  2. Virtualized systems. As long or longer, we've supported the notion of diskless systems, where the installed image is shared out, in portions, between multiple running environments. Zones was a direct evolutionary successor of the diskless environments, and shows that this approach can lead to some very economical deployment models. Lower-level virtualization methods can also benefit from the administrative precision that comes out of sharing known portions of the installation image.
  3. Availability and liveness. With Live Upgrade, it's been possible for a while now to update a second image on a running system while the first image is active—a command to switch images and a reboot is all that's required to be running the new software. This approach requires too much feature-specific knowledge at present, but provides a very safe approach to installing an upgraded kernel or larger software stack, as reverting to the previous version is just a matter of switching back to the previous image. So, a package installation option that doesn't ruin a working system is a must.
  4. Change control. In principle, with the current set of package and patch operations, it is possible to create a very specific configuration—that may never have been tested at any other site, mind you—from the issued stream of updates. From a service perspective, the variety of possible configuration combinations is too broad, but the ability to precisely know your configuration and make it a fixed point remains important.
  5. Migration and compatibility. There's a very large library of software packaged in the System V format that will run on most OpenSolaris-based systems. Providing well-defined compatibility and migration paths is an obvious constraint, given the goals of the development process.
  6. Networked behaviour. Believe it or not, the current installer and packaging support a large set of network-based operations—you can install specific packages and systems over the network, if you know where everything is. That is, the current components need to be assembled into some locally relevant architecture by each site to be useful—any replacement needs to make this assembly unnecessary, potentially via a number of mechanisms, but definitely via a list of known (trusted?) public package repositories.

"New" inputs

But, as you might expect, the efforts around Approachability, Modernization, and Indiana have brought to light some new qualities a packaging system must possess.

  1. Safety. One of the real complications from virtualized systems, at least in current packaging, is that a developer has to understand each of the image types his or her package might reach, and make sure that the set of pre- and post-install scripts, class actions scripts, and the like are correct for each of these cases. When that doesn't happen, the package is at a minimum incorrectly installed; in certain real cases, this class of failures compromises other data on the system. Restrictions in this space, particularly during package operations on an inert image, seem like a promising trade-off to achieve greater safety.
  2. Developer burden. Current packaging requires the developer provide a description of the package, its dependencies, and contents across a minimum of three files, in addition to knowing a collection of rules and guidelines around files, directories, and package boundaries. Most of these conventions should be encoded and enforced by the package creation and installation tools themselves, and it should be possible to construct a package with only a single file—or from an existing package or archive.
  3. smf(5) aware. OpenSolaris-based systems have an understanding of services and service interdependencies, derived from the Service Management Facility's service descriptions. smf(5) service management during packaging operations is awkward under current packaging and very much needs to be improved but, more importantly, the service graph provides a rich set of relationships among larger components that should lead to a better understanding of the rules around consistent system assembly.
  4. Minimization. For a while, the current system has had some very coarse package "blocks", from which one could construct a system—the various metaclusters. These, with the exception of the minimally required metacluster and the entire metacluster, split the system along boundaries of interest only to workstation installs. Any suitable packaging system must provide query and image management tools to make image construction more flexible and less error-prone (and eliminate the need for things like a "developer" metacluster, for that matter).

    It's also pretty clear that the package boundaries aren't optimized in any fashion, as evidenced by the differing rates of change of the binaries they currently enclose—in the form of the issued patches against Solaris 10.

  5. Multiple streams of change, of a single kind. Although we noted the continued need to control change above, it's also important to be able to subscribe to a stream of change consistent with one's expectations around system stability. The package system needs to allow one to bind to one or more streams of change, and limit how the interfaces the aggregate binaries from those streams evolve. That is, it should be possible to subscribe to a stream of only the most important updates, like security and data corruption fixes, or to the development stream, so that one's system changes in a way consistent with one's expectations.

    Conversely, the tradeoff between complexity and space optimization in current patches—which introduce a separate and difficult-to-calculate dependency graph and distinct namespace entries for each platform, among other issues—has slid much too far, given the increase in system richness and the increases in disk space and bandwidth. There seems to be little long-term benefit in preserving the current patch mechanism, particularly since Sun never offered it in a form useful outside of Sun's own software.

  6. ZFS aligned. ZFS offers the administrator access to so many sophisticated options around deployment and data management that it would be foolish for a packaging system to not explore how to take advantage of them—zfs snapshot and zfs clone are the most obvious capabilities that allow the packaging system to limit the risk of its modifications to an image, without excessive consumption of storage space or system time.
  7. Prevent bad stuff early. Another classic OpenSolaris-style requirement is that the set of available packages be known to be self-consistent and correct at all times, to spare the propagation of incomplete configurations. In a packaging system, this input expands on our intent to reduce the developer burden to assist the developer in writing as correct a package as possible, and to enable the repository operator to block incomplete packages from being made available to clients. There's a rich set of data here, as we noted for smf(5) service descriptions above.
  8. Friendly user deployment. Direct from Indiana, but sensible and apparent to all is that packaging systems have advanced to a point where the usability of the client is expected, and not an innovation. I haven't got the complete timeline of packaging developments—the literature survey continues—but it's clear that Debian's apt system marks the current expectations about the client-side capability and ease-of-use.

In the course of the Indiana discussions, Bryan raised one point, which I'll paraphrase as "it's not an idea until there's code". That's a sound position, which I also happen to hold—Danek and I (and Bart and Daniel, I hope) and have been quietly prototyping for a little while now, to see if we had a handle on this collection of inputs. I'd like to give a bit more background, in the form of requirements and assertions, in an upcoming post or two. Then we're hoping to start a project on to take the idea all the way from notional fancy to functioning code.

[ T: ]

Friday Jun 15, 2007

OpenSolaris: Picnic, California Edition

OpenSolaris just turned two—enjoy some good food and good company in the Northern California sun. Tomorrow's first ever OpenSolaris picnic [Upcoming] will be at Baylands Park in Sunnyvale, starting at 11:00 a.m..

Tamara and Ben will, of course, be superlative hosts. See you there!

[ T: ]

Friday Jun 08, 2007

Half a week

I was out half this week, helping my younger son deal with a nasty sinus infection—and then an allergic reaction to the prescribed antibiotic. So, between finishing various deliverables, I've been trying to catch up on my mailing list traffic. This afternoon, I got to ogb-discuss, the Governing Board alias, which has been exploring the next steps for the Architecture Review process for open development.

A few minutes ago, I replied to one message in the thread, and then reread the message was from Tuesday. Given that I was out three days, this makes quasi-arithmetical sense, as

Friday - ~2.5 days = Tuesday

Maybe in an hour or two, I'll be able to prove "Monday = Monday", give or take.

[ T: ]

Wednesday Jun 06, 2007

OpenSolaris: Five updates conservative developers should make

It's been almost two-and-a-half years since Solaris 10 was released, and if we look at Nevada (via Developer Edition or one of the other distributions), we can see that many of the technologies introduced in S10 are becoming still more capable. At this point, even the most conservative software developer can assume that certain features are always present. So, for the conservative OpenSolaris application developer, here are the five low-risk, high-reward updates you should make to your application:

  1. Provide x86 and SPARC versions. OpenSolaris has two primary instruction set targets, i386 and sparc. Each of these has both a 32- and a 64-bit variant. The metrics on Solaris 10 and SX:CE/DE downloads tell us that the Solaris volume is substantial on both targets so, for maximum uptake, you should attempt to offer software on both.

    On x86, you should consider delivering both 32- and 64-bit versions, if your application can take advantage of a 64-bit address space. But there is a large contingent of 32-bit only users, so don't stop delivering appropriate binaries prematurely.

    Of course, if you're writing at a hardware-independent level, like on a Java language platform, then you get x86 and SPARC (and presumably others) for free.

  2. Make packages that deliver into sparse zones. The primary software delivery mechanism is still System V packages—but your software's already packaged properly, so that's not an issue. (Right?) With Solaris 10, the Zones feature offers a sparse variant that requires package support. Roughly, this support means that the package author shouldn't deliver into /usr and should add the three properties needed to the pkginfo file.

    There are some fairly serious Zones deployers out there; Joyent is probably the most public example, but there are plenty of corporate datacentres using Zones to their advantage. If you want your software run by them or their customers, providing a Zones-compatible package seems like the easiest way to get it into their hands and onto their Zones.

  3. Replace your init.d scripts with smf(5) manifests. The Service Management Facility (smf(5)) provides a collection of capabilities that make service administration easier, while also reducing the development burden on application authors. Converting your service from the rc\*.d script to a service description and methods means that administrators get automatic restart (and higher service availability), an easy on/off switch, and a place to make site-specific annotations (using the various template properties). There's a free comptetive advantage here, if your service runs under smf(5) and a rival's doesn't.

    Of course, you can do more: placing key configuration values in the service repository means that various administrative utilities can be taught to make manipulating your application's feature set easy to the deploying administrator. But that won't happen without an initial service conversion.

    (Once you write a manifest for your service, you'll also probably want to write a rights profile, so that administrative authority for your service and its instances can be easily delegated.)

  4. Understand needed privileges. One of the more interesting features in Solaris 10 and later is the work Casper did to split out the absolute privilege owned by root into a specific collection of privileges. That means that you can take away a process's ability to fork or exec, change file ownership, or manipulate or utilize various subsystems of the operating system. If your application runs with the minimal set of privileges it needs to function, then the set of actions a hypothetical exploit against your application can invoke becomes limited, which reduces the impact of an intrusion. You can reduce your privileges via the smf(5) manifest you wrote for #3, via the role-based access control (RBAC) configuration, or via the privileges API.

  5. Don't unnecessarily ship duplicate components. The various OpenSolaris distributions include a lot of software; most of these offer one or more update mechanisms for the components they include. Whether or not you prefer minimal patches to wholesale package replacements, if you ship a duplicate component, it's your responsiblity to update it if a defect or security hole is found. Sometimes you have to ship a component—the distros don't update it often enough—but private libraries (or private copies of the Java runtime) have a collection of costs, many of which are imposed on your customer.

For specific kinds of software, there's more to investigate. Language interpreters and byte-code virtual machines (and probably complex daemons) should have DTrace providers. Network device drivers should write to the latest version of the generic LAN device (gld) interface. Archival programs should be ZFS-compatible—there's going to be a lot of data on ZFS. Daemons should investigate using libumem for memory allocation (and event ports in place of poll(2) or select(3C)). And so on.

There are OpenSolaris communities for each of these topics but, if you're having trouble getting started, I would suggest an email to opensolaris-code, that reads something like: "I have a [daemon/driver/app] that does [practical purpose/amazing feat/curious entertainment]. Are there any OpenSolaris features I can use to make it better?"

Looking forward to your mail.

Thanks to Dave for #5. Dave also confesses to being keen on #3.

[ T: ]

Tuesday Jun 05, 2007

SFW: Integrating coreutils and which variants

Last night, I finished up another task, in an attempt to reduce my current multitasking factor: I integrated initial versions of coreutils and which from the GNU Project into the Freeware consolidation. As a lower priority task, it took longer than a more dedicated developer might have managed, but it's reasonably pleasing to look back:

There's still a bunch of process associated with SFW that requires redesign—legal review and Section 508 compliance, in particular—but I think, barring the latent intervals, this sequence was a reasonable consensus-driven open development experience.

If you look at other mailing lists during June – November and February – April, you'll be able to verify that I was indeed working—just on other things, and not just surfing the Web...

Of course, now that I know that these commands will start to show up more widely when Build 67 is released, I can update my dotfiles, so I get the versions I prefer:

$ svn diff
Index: sh-functions
--- sh-functions        (revision 91)
+++ sh-functions        (working copy)
@@ -36,6 +36,10 @@
                        PATH=$HOME/bin:$HOME/bin/$(/usr/bin/uname -p):$PATH
+               gnu)    # PREPEND: Bundled GNU command variants
+                       PATH=/usr/gnu/bin:$PATH
+                       MANPATH=/usr/gnu/share/man:$PATH
+                       ;;
Index: bashrc
--- bashrc      (revision 91)
+++ bashrc      (working copy)
@@ -49,8 +49,12 @@
        path clear home sfw csw

-if hash gls > /dev/null 2>&1; then
-       alias ls="gls --color -CF"
+if [ -x /usr/gnu/bin/ls ]; then
+       alias ls="/usr/gnu/bin/ls --color -CF"

+if [ -x /usr/gnu/bin/which ]; then
+       alias which="/usr/gnu/bin/which"

If you're using a distribution that offers SUNWgnu-coreutils, SUNWgnu-which, and the other /usr/gnu packages, do share your feedback with the maintainers on sfwnv-discuss—or become one and pick your favourite package.

[ T: ]

Wednesday May 23, 2007

OpenSolaris: Defect tracking relationships

Just prior to the Board election, we ran a poll of the core contributors to get some sense of what one active subset felt were the five most pressing obstacles to open development. Dan just issued an initial Beta of a webrev-based approach, derived from his earlier experiment on, so that's a starting point for Priority 3. The Board is tackling, in full public view on ogb-discuss, Priority 4: there's OGB/2007/001, Project creation enhancements and OGB/2007/002, Community and Project Reorganization as two significant chunks of a stablized reorganization. Priority 2, the deployment of a "request to integrate" system, is somewhat gated on ON and sister consolidations' switch to Mercurial, being pursued in the scm-migration project—it's an aspect of workflow that isn't required by all of the hosted consolidations. Priority 5, the deployment of an wiki, is in a requirements gathering phase over on website-discuss.

That leaves Priority 1, the deployment of a public bug tracking system. Bug tracking has loomed over the OpenSolaris effort for pretty much its entire implementation phase; we've known that aspects of the current bug tracking methodologies impact many parts of Sun's business, and that any solution will require the identification of which entanglements are strategic—meaning that there's a requirement for any new system—and which are accidental—meaning that there's only some transition cost, as the entangled system can be adjusted to consume information in some designed fashion. So, as part of getting a set of draft requirements together for discussion, I thought I would work through some of the issues facing defect tracking as we move to open development. Most of these points are about the developer–distribution (or upstream–downstream) interface that a defect tracking system (DTS) or defect tracking architecture represents.

The primary requirement that a distribution has on their DTS is some ability to maintain confidential data associated with each tracked defect. Let's call that database a proprietary annotation system (PAS)—the data within it capture the customer histories associated with various defects or collections of defects ("products"?) represented in the system. The DTS, meanwhile, is meant to be neutral across all participants, developers and distribution assemblers, and unconcerned with non-technical characteristics of the defect.

This contrast allows us to postulate a set of relationships among various active DTSs and PASs for an open development community.

The association of confidential information with an existing defect looks something like

1 DTS to 1 PAS

Of course, in the OpenSolaris case, SMI's annotations become just one potential PAS; other distributions may also choose to annotate publicly known ("community tracked") defects:

1 DTS to N PAS

One requirement that we've heard during preliminary discussions with the various teams is there must be some ability to search the entirety of the product-relevant portion of the DTS. One possibility is that each PAS operator builds a search corpus that combines the upstream DTS with the PAS content. A potentially more economic alternative would be to allow the the associations to be bidirectional (so that an indexer with authorizations allowing it to access one or more proprietary annotation systems can present a complete defect corpus). Making the existence of the annotations public does not seem like a significant leak of proprietary information, while the existence of annotations might be a useful measure of defect significance. (It is probably worth explicitly stating that having a complete defect corpus for searching does not imply that use of a single DTS is the only means of obtaining such a corpus.)

These associations are more complex objects than the current See Also links in typical monolithic DTSes, in that they carry one or more mappings of status and responsibility between the DTS and each PAS. Potentially, this capability could lead to more precise handling of release readiness, in that a query involving a group of PAS-tracked defects could indicate that one or more stoppers are blocking the release of a certain version of the tracked product. Of course, prior to open development, the Solaris organization has historically managed that fairly well for its products, so why is it worth discussing?

Well, for OpenSolaris today, the set of defects in our own DTS isn't the complete set of relevant defects for product release. In fact, as examples, Solaris tracks the defects, branches, and patches for GNOME, Mozilla Firefox, and Perl, among others. That is, Sun's current combined DTS/PAS, Bugster, is in the following relationships with an upstream source

Defects tied to upstream defects

when the product is affected by an upstream-sourced component, and

Customer annotations on upstream

when a customer is affected by an upstream-sourced component. There's also an awkward local cost since upstream state is usually tracked manually (or possibly via custom scripting).

We can choose to apply this tracking need to our second defect/annotation figure above, in two ways: we can track the OpenSolaris consolidation defects as a peer of other upstream DTSs

Community is upstream peer

or, more interestingly, we can allow community management of the relevance of upstream defects, like the following

Community manages upstream

(A distribution may not choose to annotate the public DTS record on an upstream bug, but may instead choose to annotate on the upstream DTS record directly. Ignoring the community signal when it has a mismatch with distribution priorities seems likely; using it as a guide when no conflicting principle exists seems like a safe course as well.)

I think that introducing these kinds of associations allows us to solve a large class of defect tracking problems that are currently impacting the OpenSolaris space. (Obviously there are issues, too--for instance, one could introduce association cycles (that clients must detect).) I would expect that the confidentiality issue impacts all of the distributions pulling from OpenSolaris consolidations (and probably, more generally, all groups looking at open development): I believe every distribution has customers of some kind. The importance of upstream relationships may presently be operating environment-specific, although I know other groups are also dependent on some number of OSS components.

[ T: ]

Friday Mar 16, 2007

Busy, stopping email

The past couple of months have been busy: I've been working on different deliverables for OpenSolaris, SMF, and SFW. I'll try to give summaries on each of these items as they complete in the coming weeks, but I thought I should mention the consequences of some anti-spam provisions I implemented on in February. Since these restrictions can cause mail to OpenSolaris lists to be dropped, you may wish to read on.

At the time, we had essentially no anti-spam on's mail pipeline, and we relying on Mailman (which handles our 120+ lists) to reject spam directly, or for list moderators to do so manually. We knew that some lists were promptly moderated, and others less so, but figured things were working, for the most part. This state of affairs then changed.

It was public news that there was a jump in spam volume the previous fall. On, spam hit all of our addresses, including administrative aliases for list subscription and removal. Mailman requires time to process each request, and with the rate of inflow, finally built to a backlog of almost 35 000 unprocessed Mailman administrative queries in early February. For a potential OpenSolaris list subscriber, this translated to a multi-hour wait for subcription requests—no way to make it easy to get in on a conversation.

To stop the -subscribe and -unsubscribe addresses from getting pounded, I started activating the basic anti-spam features of Postfix (which we have run on since the initial setup). Presently, we expect a host to have legitimate DNS entries and to not be on various blacklists, and we expect envelopes to be well-formed. The backlog started to clear as these controls were in place, and was completed with no dropped requests a day or two later. (We had one hiccough: I had initially written the configuration so that Postfix didn't trust the Mailman outbound mail, which meant that we did both anti-spam on the inbound submission and also on the dozens or hundreds of outbound messages to the list subscribers. Once we straightened that out, things have been much better.)

Since we imposed these requirements after initial subscriptions, it is possible that a valid subscriber to a Mailman list can no longer send mail acceptable for This problem is particularly likely to be related to a host lacking a valid MX record. If you've sent mail to that hasn't appeared in the lists, please check that you have a valid MX record. You can use one of the web forms offering MX lookups, but on an OpenSolaris-based system it's easy to do this using nslookup(1M):

$ nslookup

> set querytype=mx

\*\* server can't find NXDOMAIN


Non-authoritative answer:   mail exchanger = 10   mail exchanger = 10   mail exchanger = 10   mail exchanger = 20   mail exchanger = 20

Authoritative answers can be found from: nameserver =

(In fact, rosseau lost its MX record in the past couple of weeks, so I, too, got caught by the new policy.)

Both our Mailman instance and our many moderators are much happier now, processing many fewer, mostly legitimate list postings. If you've a valid MX record, aren't blacklisted, and are still having problems, website-discuss is the place to ask.

[ T: ]

Wednesday Jan 03, 2007

OpenSolaris: Restricted builds through the ages

Last month, Stephen Harpster announced that there would be a two-build sequence with restricted integration conditions. This sort of restriction isn't new for Solaris development, as I'll show below, but the means of arriving at the restriction and the manner in which we shared it shows we are still learning what an "open process" must do—and when we miss, to make sure we learn from those mistakes.

So Stephen's announcement noted that Build 54 and 55 would be "only bug fixes". That's not new; we can look at the build-by-build restrictions on ON integrations for Solaris 8

Solaris 8 ON build restrictions

Solaris 9,

Solaris 9 ON build restrictions

and Solaris 10,

Solaris 10 build restrictions

Here, each box represents a cycle of the two-week build clock. Solid boxes indicate a strong "bugfix only" integration policy (like "stopper only" or integrations requiring the consolidation's technical lead's approval); outlined boxes indicate a weak "bugfix only" integration policy (meaning no specially approved projects). I've worked out these integration policy digests from the ON schedules of past releases; policies will vary for other consolidations, but should match up roughly with ON's history.

Solaris 8 and 9 show the classic "(Development Complete–)Beta–Beta Refresh–Ship" pattern that characterized Solaris releases. In Solaris 10, the Solaris Express program gets reflected in that, although there were identified Beta and Beta Refresh builds, the shift from early release to late release really takes place with the Beta Refresh build, which was the first in a series of restricted builds, until Ship.

Thus, for current Nevada, ON looks a lot like it did for the release that became Solaris 10:

OpenSolaris NV ON build restrictions

Inferences you might make are at your own risk.

Of course, the freezes we took in the past were easily achieved as there was only one distribution derived from the ON sources. Now that we are a community with a collection of active distributions, the notion of periodic and public restricted builds may still be attractive, so that distributions could choose to issue their latest version from a known stabilized build. Certainly current distributions (or emerging ones) might consider using the stabilized build 55—however we got here—as an opportune version to base their next release upon.

Of course, there is a tradeoff between letting each distribution stabilize and a consolidation-wide restriction. Perhaps a topic for a future post?

We, as a community, will need to have a position on restricted builds. Please think about it, and then feel free to comment here, and mail me privately. Public discussions, I suspect, are more valuable: opensolaris-code would be a good forum for the technical tradeoffs, possible frequency of stabilized builds, and so on, while cab-discuss would be the best place for inter-distribution and coordination issues.

[ T: ]

Monday Dec 11, 2006 Prevent accidental robotomies

We've been working through bits and pieces of, looking for the troubling portions where regular human touches are currently required.

These are troubling because (a) someone forgets to touch when someone else is on vacation, sick, or whatever, and then (b) someone depending on that resource being touched gets annoyed/loses time/sends us Kafkaeque email about transforming into an automaton.

Recently, Steve pulled a little Python script together and now we can smoothly offer direct DVD downloads of Solaris Express Community Release across each incremental release. In honour of his script, a new download button:

Get the (SXCR) DVD. should work, without problem, for the duration of Nevada. But pipe up on website-discuss if it fails.

[ T: ]

Monday Dec 04, 2006

Untuning for 53

Since I bumped into a couple of problems after moving to Build 53, I thought I should make a note and save folks some time. My laptop's a reasonably standard install, but I do turn off a few more daemons, in the hope of squeezing out a few minutes' more battery life. With the new GNOME bits, you need to make sure that

$ svcs \\\*hal\\\* \\\*fc-cache\\\*
STATE          STIME    FMRI
online         Nov_28   svc:/application/font/fc-cache:default
online         12:27:47 svc:/system/hal:default
shows that both hal(1M) and fc-cache(1M) are running, as their functionality is required by other components. (If you don't have application/font/fc-cache enabled, you'll have trouble getting much of GNOME to run--you'll see core files, running on which pstack(1) will reveal a stack trace filled with symbols beginning with "FC"...) A couple of svcadm enable invocations will bring things back into spec.

If you haven't customized your system and you're still having similar problems, you probably want to visit desktop-discuss.

[ T: ]

Wednesday Nov 29, 2006

53 looks good

About six weeks ago, in anticipation of GNOME 2.16, I switched my desktop from an Ion window manager-based X11 environment to the JDS environment integrated with Solaris. Now, with the delivery of Build 53—not yet on the Download Centre, apparently—the wait is over:

A few keyboard shortcuts input, a tweak of the window preferences, and it's back to normal work. (Or better: using evince and gnome-terminal in their full screen modes are distinct improvements for reading documents onscreen.)

Background image by Mandolux.

[ T: ]

Thursday Nov 09, 2006

Tip: Mercurial atop ssh

On, we host Mercurial and Subversion via their ability to tunnel through an SSH connection. A slight gotcha with Mercurial is that it turns off compression when tunnelled through SSH, as described in hg(1):

$ man hg
    - Mercurial doesn't use its own compression via SSH; the right thing
      to do is to configure it in your ~/.ssh/ssh_config, e.g.:
        Host \*
          Compression off
        Host \*
          Compression on
      Alternatively specify "ssh -C" as your ssh command in your hgrc or
      with the --ssh command line option.

For pulls of a large repository, such as ON, compression changes an approximately 51 minute operation to a 17 minute operation. So you'll want something like

$ cat ~/.ssh/config
    Compression yes
in your SSH configuration.

[ T: ]

Tuesday Nov 07, 2006

OpenSolaris: Documentation tutorial buffet

Each of the community groups that make up OpenSolaris is experimenting with different styles of introductory materials (or procedures), so that potential contributors don't get blocked on the details and can focus on their real intention—contributions. The Documentation community group has been energetically pursuing a complete offering: they have a large document tree, they're using a "scratchpad" on the Genunix wiki, and they have at least one mailing list. They even have a Flash animated tutorial, illustrating how to use a DocBook XML toolchain. Slick.

[ T: ]

Monday Nov 06, 2006

OpenSolaris Day, Buenos Aires

I've been back from Buenos Aires for a week now, and just wanted to comment on my trip, and show the few pictures I managed to take. Like its sister events, Buenos Aires TechDays was a densely packed three day conference, with multiple tracks available on OpenSolaris, Java, NetBeans, SunStudio, Glassfish, and other technologies and platforms. I updated the "Building and Deploying OpenSolaris" talk, to cover the convenient Starter Kit, which has the tools and source (and OS images) and to mention the ONNV Mercurial repository on

The talk was simultaneously translated into Spanish, using some slick IR emitter arrays and receivers. Russ, I think, was much more effective, as he gave his presentations in Spanish.

The event was held at the Hilton Buenos Aires, which is located in the recently redeveloped Puerto Madero area. When Teresa and I walked around on the first day, we saw activity in the harbour, and paused to watch (along with a few hundred other pedestrians), as this tugboat


helped this coast guard ship


turn out of the relatively narrow channel.

Back at TechDays, we enjoyed the chance to have further technical discussions, with many resolutions


to study new problems, reengage with old ones, or just return to Argentina.

The Inquirer's Fernando Cassia has more on the NetBeans portion of the event.

In Argentina, but missed TechDays? There's an OpenSolaris user group—check it out.

[ T: ]

Wednesday Oct 11, 2006

OpenSolaris: TechDays, Buenos Aires, 23 - 25 October

I'll be visiting Argentina for the first time, to present at the upcoming TechDays in Buenos Aires. As with all TechDays, the event itself is free, but you must register in advance. The event is being held at the Hilton Buenos Aires; OpenSolaris day is 23 October.

As always, if you want to meet up and talk about OpenSolaris, software development in Argentina, or any other topic, leave me a comment or send me some email.

I'm a little tired today, as I made a round-trip to Los Angeles to visit the Argentinian consulate there and obtain a visa. 700+ miles on the road, but the friendly officers were able to do the turnaround in only a few hours.

[ T: ]




« July 2016
External blogs