Sam.

http://portal.acm.org/citation.cfm?doid=24054.24056

Check out who one of the authors is.

I didn’t mean for this to turn into too much of a discussion about Sun’s packaging system in general; it’s been covered before in much greater depth by people with much greater knowledge than I on all things Solaris. It was mostly intended to explain to Linux-centric people why Solaris’s third-party package ecosystem is so bare-bones compared to Linux’s, and why a lot of effort goes into building a full stack from source. Since nobody else is commenting, though, there’s no reason to be afraid of a little derail.

SysV packaging is definitely showing its age, and you’ll find few outside of the hardcore Sun faithful who actually try to defend it. IPS in OpenSolaris is still dog slow, much slower than any modern package manager ought to be, but I think it does address most of your concerns. Sun has a decent introduction to IPS packaging in their OpenSolaris docs. Also see the command reference for pkg(1), which has some other useful information in it.

Here’s the nickel version:

IPS handles upgrading pretty seamlessly. Not only does it handle upgrades in the sane way expected of a modern package manager, but it also can take a full ZFS snapshot of your boot environment so you can roll back to a known-working package set without a lot of fuss. (This isn’t hard using RHN Satellite or Spacewalk either, from the Red Hat side, but it takes a lot more plumbing and infrastructure and relies on your ability to downgrade packages cleanly.)

Checksums are handled well by “pkg verify”, as are other things that any other modern package manager could sanity-check, like permissions. OpenSolaris loses points by not having the output format easily parseable/scriptable like the output of “rpm –verify” but the functionality is in place and usable, at least.

Querying and listing packages is done through “pkg contents” and “pkg search”. These functions work identically on local and remote packages, which gives IPS a tiny leg up on its Linux counterparts.

It also manages dependencies pretty well — that was more or less the entire point of bringing Ian Murdock on board with Sun’s platform team. The lack of a regular Internet-oriented package manager like most Linux distros have had for a very long time is definitely something that’s scared a lot of Linux users away from Solaris.

Of course, this means pretty much nothing to you if you’re not running OpenSolaris, which takes some balls to do at this point. And, like any major change in an OS like Solaris, it introduces its own set of problems. Here’s a quote from the pkg(5) manpage about package version numbers:

The first part is the component version. For components tightly bound to OpenSolaris, this will usually be the value of ‘uname -r’ for that version of OpenSolaris. For a component with its own development lifecycle, this sequence will be the dotted release number, such as ‘2.4.10′.

How very intuitive, Sun.

I still plan to update in this way for minor releases and update packs, as my only damage has been minor, hasn’t affected any user-facing aspects of a system and is much quicker than doing clean reinstalls for the majority of systems. However, I’m absolutely not denigrating your approach: I still absolutely am keeping all of my configuration and data backups on hand when facing OS upgrades like this. I keep most systems managed by Puppet, all system configurations in revision control, and everything’s ready to go when a colorful object of choice hits the fan.

As we move more towards a virtualized infrastructure, where we can easily stand up clones of virtual machines to test upgrades, I suspect a lot of these problems will go away. As it stands today, though, I’m glad we have at least a basic release management framework in place and were able to catch these problems before they made their way onto any important systems.

In any case, this is certainly a big motivation for me to move forward with finishing my Spacewalk deployment. Yum has definitely presented us with certain major issues in the release management process.

It’s perfectly possible that my issues were caused by hardware or drivers or any of the other myriad things that make X.org behave completely differently on very similar tasks, but one of the things that drove me nuts the last time I gave Xmonad a serious try was that resizing windows was really, really slow, while other window managers (even relatively heavy-weight WMs like KWin) didn’t seem to have this trouble. This is entirely anecdotal, and may not reflect everyone’s experiences — it may not even be current information. I should update the post to reflect that my experiences with Xmonad are based on code I used around a year ago.

However, awesome does use XCB instead of Xlib, and this may translate into certain performance improvements.

Allen Taylor

This doesn’t seem plausible, in my view. Xmonad uses O(1) operations for all key functions, and runs in constant space. We thought very hard about designing optimal data structures to keep the window manager footprint extremely light.

Perhaps it is just psychological…