I've been making good progress on getting KDE 4.4 (release candidates) working. It's been quite an interesting ride, in both a good and bad way. =)

First, there's the fun of 10.6 making it even harder to have code that forks without it accidentally exploding on the CoreFoundation fork-without-exec prohibition. I was able to solve this with a combination of fixes from macports' kdelibs4, and some of my own code which changes things to use low-level POSIX APIs instead of Qt APIs for some bounds-checking before execution.

Next, there's the fun of Phonon. KDE 4.4 requires a newer version of Phonon than what ships with Qt (even Qt 4.6). On OSX it gets even hinkier, since the QuickTime plugin for Phonon requires private Qt headers, so the only sane way to build it is to build the Phonon included with Qt, rather than building it as a separate project.

I ended up adapting a patch the Kubuntu folks use to inject a modern Phonon into Qt 4.6. In the process, I finally got around to learning my way around Git (and gitorious), and have set up my own Qt branch which includes my (binary incompatible outside of Fink) patch to Qt to fix plugin-building, Phonon from kdesupport, the kde-qt (formerly qt-copy) changes, and my patches to Qt that splits OSX into two platforms, Q_OS_DARWIN (i.e. use raw UNIX APIs, no Core*), and Q_OS_MAC (standard Qt/Mac).

Long story short, I'm getting there. I've gotten about half of KDE 4.4 RC1 built and apparently running reasonably. RC2 was just released to packagers, and I'm testing out my move to Qt 4.6.1 from 4.6.0, but once I get everything test-built on 10.6, I'll go validate everything on 10.4 and 10.5 (including making some DBus fixes for 10.4).

After that, the next thing to tackle is Mono, and then eventually I'll see if I can get KDE3 building/working on 10.6.

It's been a crazy couple of weeks, with Snow Leopard out, people are scrambling to fix packages that haven't been already. I was a slacker in running the seeds this time around, and haven't really had much chance to give my packages a serious look until recently, but FYI, I am working on getting everything building everywhere I can.

Some notes on popular stuff:

• KDE3: There were a number of annoying things blocking KDE3, but with the approval of some of the other maintainers, I've got a lot of the deps that were failing fixed up, and I'm working my way through a full KDE build and hope to have everything hunky-dory in unstable in the next few days.
• KDE4: First of all: there will not be KDE4 on x86_64 in the near future. Qt4/Mac 64-bit does not have the Qt3Support framework, which plenty of KDE4 bits still depend on. I'll definitely be making sure that KDE4 builds fine in 32-bit mode, and in 64-bit X11 though, and after that, well, we'll see how much work it is to excise Qt3Support from at least the base libraries. In the process, I'm going to try to update it to KDE 4.3.1.
• Java packages: When I packaged a lot of Java stuff for 10.4 and 10.5, I tried to build them targeting the 1.4 JDK, so it was more likely that built jars would work for most people. Unfortunately, Snow Leopard removes the 1.4 JDK, so I'm updating everything to build with the 1.5 JDK. Most stuff is handled, I'll be fixing up other stuff as I run into them.

If you have packages that you use day-to-day, let me know, I'll try to get to them first. I've been fixing things up on a first-come, first-serve basis based on reports to my maintainer email address(es).

I'll post here on my blog if I hit any other major milestones. In the meantime, happy Finking. :)

I've been spending some spare time working on an OpenNMS iPhone app, and things are coming along just great. As many of you know, I do a lot of work with porting various UNIX C/C++ applications to Mac OS X, but despite now having many years of practice doing such things, I actually have very little knowledge of writing C/C++ code from scratch.

I've debugged many a bad header, but up to this point I could count the number of lines of code I've actually written where I need to manage my own memory on erm... well, 20 hands? OK, bad analogy.

Still, it was with much trepidation that I approached finally hunkering down and learning Objective C. The verdict is: not bad. I did have to go through some growing pains learning how scoping and memory management works, but it's not as troublesome as I'd feared -- and the class libraries are pretty robust. In a couple of weeks, it's nearly feature-complete for what I wanted to get working for a 1.0 release. All that's left is the alarm detail page, and being able to acknowledge alarms from the app.

The biggest thing I learned was Instruments and the LLVM static analyzer are you friends! The Clang Static Analyzer is friggin' awesome -- it wraps your build and then analyzes the resultant binaries and outputs a report that tells you whether you've passed ref-counted data, allocated without deallocating, and other spiffy things.

I'm stopping to work on getting an OpenNMS 1.7.6 (and next week, 1.6.6) release out the door, but hopefully I'll have a chance to pick it back up and finish it off soon. I'm still waiting for the OpenNMS corporate iPhone development paperwork to go through anyways.

Without further ado... screenshots:

It's open-source, so if you want to see my awful code, you can check it out from SourceForge.

Just a note to say that I've released KDE 4.2.4 to Fink unstable. And now it's time for the fun part: big bold red text telling you it breaks stuff.

KDE4/X11 Plasma Desktop on Mac OS X in Xephyr

Working KOffice file asociations

Actually, that was just the text saying that I was going to have big bold red text telling you it breaks stuff. Here's the real thing:

It breaks stuff!

But let me explain: it makes things better! Because of some esoteric stuff relating to case-sensitivity, existing packages, and bugs in Fink dpkg, there were issues on a number of people's systems with the existing KDE packages and conflicting paths. Of course, the root of the issue is that Fink didn't have a proper "/opt" type directory, so a number of packages for quite some time have been using "/sw/lib" for that purpose (/sw/lib/qt4-x11, /sw/lib/flex, etc.)

Since I was going to have to move things around anyways to fix this issue, I decided to do it right. As of Fink 0.29.7, the package validator accepts "/sw/opt" as a valid path to root packages. All of the KDE4 packages have been changed to use this new path, so when you upgrade to KDE 4.2.4, you will end up with a nice fresh clean KDE in /sw/opt/kde4/x11 or /sw/opt/kde4/mac (or both).

But wait, there's more!

I've also spent a lot of time fixing bugs and tweaking some fink-specific behaviors so that KDE integrates better with your Fink experience.

• Fink's kdelibs4 automatically knows about the usual locations for kde4 files, so all KDE4 apps will start properly without needing /sw/opt/kde4/{x11,mac} in the path. This includes KDE4 apps launched from the Finder.
• The kdebase-workspace package is now supported for KDE4/X11. That means you can start a full KDE desktop!
• As a test, I created proper Info.plist files for KOffice, so file associations actually work. Till Adam has been working on a more robust way of doing this in the future, but if I find the time I might work on setting up more associations for common KDE apps in the mean time. (Kommon apps?)

So, for those of you who have already tinkered with KDE4 in Fink, I'm sorry to say it all needs an upgrade. But, on the bright side, once you do, you'll have a much nicer KDE.

As always, if you run into any issues, please let me know.

The conversation has continued over at the 451 CAOS Theory blog. In response to my musings on intent, David Dennis asked a great question:

Benjamin,

A question for you (and Tarus). Is this topic important to you because:

1. You believe it's an important marketing differentiator for the software you work on vs. competitors
2. You believe it's an important philosophical / moral issue worth evangelizing
3. both

Tackling a) involves traditional marketing objectives around branding, awareness, messaging, positioning, etc. Not necessarily a cake walk, but certainly possible to make progress.

Tackling b) involves changing the way people think and behave, which is much much more challenging.

My response is:

Definitely both.

From a personal point of view, I've been involved in open source software since before the phrase was coined, so I do feel that it is at least a personal philosophical issue. BUT I'm also a pragmatist, and I know that arguing purely for philosophy's sake will not convince anyone.

That said, that philosophy drives me to support the companies that I think are doing it "right." I work for OpenNMS not just because I think the software's great, but also because I love that we can compete with "the big guys" by having a better community.

Part of the reason that we get so passionate about it is that a lot of these "does it really matter?" conversations start with the implication that we're already failing to compete, which is just plain wrong. I'm sure that's why we probably often sound defensive when we are hoping to sound convincing. ;)

I'm the first to roll my eyes at the "true believers" -- while I think that in the end open source is a better way to do things in a "pay it forward" kind of way, I believe it's better from a philosophical and pragmatic way. It won't work for everyone, but it can work for open source projects as an alternative to big-money funding.

I am a child of the VC tech industry. I've worked at startups and I know what it feels like to work on software you think is great only to be shut down and have the IP sold off, just because the VP of sales didn't do his job. It's refreshing to work for a company that starts with community first, and grows by being truly profitable, rather than by incurring massive amounts of debt. (See: current economy.) It's refreshing to not be one of 10 companies the VC bets on, and if 9 of them fail, "eh, oh well, that's statistics."

Since we grow as we have profit, rather than funding, the biggest investment we can make is in our time, improving the software, and growing the community. There is nothing wrong with the "fauxpen source" companies' business model, they are welcome to write good software as best they can, and get market share, but in the end, we do differentiate by our openness and our interaction with the community. When they co-opt the phrase that was meant to be equivalent to "free software" to now mean "kind of free software," it does pure open source companies a disservice and it is a lie by omission that they equate their software to be "just as free" as ours.

Sure, that's competition, but that's why it's important for us to get the word out that there is a difference.

I've just committed all of KDE 4.2.2 to Fink Unstable.

There's still a lot of rough edges, but it's definitely at least beta quality, and a lot of apps work great. It includes a number of fixes, including updated scripts to register all of the desktop files properly with ksycocoa on post-install, case-sensitive filesystem fixes, and a number of other packaging fixes. I've also finished packaging all of the "core" KDE distribution.

I've got Amarok working in my experimental tree, I just need to do a little more testing before I can release it (It's based on a snapshot of what will become Amarok 2.1.0, since 2.0.x has some build issues on Mac OS X that are difficult to resolve). Also, the KOffice folks just put out a release candidate that I'm working on finishing up packaging on. Hopefully I will have that out soon.

As always, please let me know if you run into issues. I've test-built on 10.5/i386 and 10.4/ppc so I'm sure some 10.4/i386 and 10.5/ppc users will give bug reports soon. ;)

I've had a chance to get a few more of the KDE4 packages polished up into what I hope is a releasable state. :)

Please give them a shot, let me know if you have any issues, if things don't work as expected. I know one major thing to look into still is to get document-opening working. Right now the KDE desktop files describe which apps should open different document types, but that is not being translated to OSX's document-opening APIs.

The following packages were released to unstable today:

• digikam-mac and digikam-x11
• kdeaccessibility4-mac and kdeaccessibility4-x11
• kdeadmin4-mac and kdeadmin4-x11
• kdeartwork4-mac and kdeartwork4-x11
• kdeedu4-mac and kdeedu4-x11
• kdegraphics4-mac and kdegraphics4-x11
• kdemultimedia4-mac and kdemultimedia4-x11

Big ones left on the hitlist are amarok2 and koffice2. Amarok2 I'm starting work on again as a snapshot of the 2.1.0 build, since there are some issues with 2.0.x building on OSX. KOffice is actually working pretty well in my experimental tree, but 2.0 release candidate is due out in the next week or so, so I'm going to wait to update to that before doing a release.

Yes, that's right, a post to my blog that isn't about OpenNMS. ;)

As you can tell, I've been pretty busy having fun hacking on OpenNMS lately. While I have been keeping up with my Fink work to some extent, one major thing was still looming: finally getting all the work I did on KDE/Mac released in Fink, now that things have stabilized.

If you've been watching the commits for the last few months, you've seen the beginnings of that work. Updates to Qt, releases of support things like strigi and soprano... The big hurdle was getting D-Bus in a state where it plays well with KDE/Mac. After some initial hiccoughs, the D-Bus updates have been released to Fink now, and seem to be working well for people.

Today, I released the base packages for KDE 4.2.x into fink: kdelibs4, kdepimlibs4, and kdebase4.

Because of the cross-platform nature of KDE, I've released them in 2 variants: mac and x11, so you can run konqueror as an X11 app, or as a mac app. :)

Some things will only be present in one or the other, for various reasons (X11-specific features, etc.) One thing that will be in the X11 variant that is not there now is kdebase-workspace, so no plasma desktop as of yet. I've built it, but it doesn't act right currently, so I'm waiting to release until it's in a usable state.

This is still early test stuff, so if you run into issues with it, please feel free to let me know and I'll see what I can do.

I can't thank enough Orville Bennett and the other KDE/Mac folks. They have picked up the early work I did on porting and ran with it, helping polish it into a nice, buildable, and solid set of code while I was on my "hiatus" from KDE packaging. :) They have done a lot of great work in helping bring native mac KDE from "freakish mutant" to "used every day by KDE developers."

In the coming weeks I hope to get more of the base KDE packages done. I'm in the testing phase for koffice, amarok, kdeartwork, and a couple of others, and working my way through packaging more. I'll post as I get anything interesting.

So I'm a slacker. But I have an excuse, really! I was having so much fun working on JSPs last Friday, that I totally forgot to write TWiO last week. OK, it's JSPs, so I guess I'm lying about having fun, but I was really almost done with a new feature. ;)

Anyways, since I've gotten a little sloppy, I'm going to make it up for you, with a feature on the new Provisiond, which is shaping up quite nicely. And to show my shame, I've dubbed this week's article: This Week (or Two) in OpenNMS.

But, to begin... What's been going on for the last two weeks?

Project Updates

New Node Page

• Stable: Current Release is 1.6.2

  1.6.2 is still the current release, and while there are a few fixes pending since it's release, there are no immediate plans for a 1.6.3 yet.

• Unstable: Current Release is 1.7.0

  Commits have been speeding by on trunk as Provisiond moves it's way into a feature-complete state. I'm still hoping we'll get a 1.7.1 release out soon so people can give it a shot, but, well, we have to stop to breathe first. In the meantime, feel free to try the nightly snapshots (if it's not on a production system, of course).

• Trunk: RANCID Updates

  Antonio and Guglielmo have been furiously working away on the RANCID integration, focusing on authentication, and the UI for the most part.

• Trunk: SNMP Refactoring

  Matt has spent some time refactoring some of the SNMP data so that it is instead in the snmpInterface table where it belongs, and it means no more 0.0.0.0 IPs where they don't belong. This cleans up our model a bit to be more sane. (A bit.)

• Trunk: Provisiond Updates

  Provisiond is nearing feature-complete, and is definitely at a point where it can be tried out on real-world networks. See below for a feature on Provisiond.

• Trunk: Node Page Updates

  Donald and Matt have both been working on updating the node page to be more dynamic. It's pretty slick now, offering tabs detailing various information related to the node.

• Branch: Inventory Management

  Matt Raykowski continued work on his inventory daemon. I'm still waiting for a more detailed update of what it does/will do, I'll try to get an update before next week's TWiO.

Provisiond: An Overview

Provisioning Groups: UI

Provisioning Groups: Edit Requisition

Provisioning Groups: Edit Foreign Source

A History Lesson

Architecturally, OpenNMS is very sound. It was written from the beginning with scalability in mind, by people who had been dealing with network management for their entire careers. However, Java, as a language (and as an environment), has grown immensely in power, reliability, and expressiveness since we started this project. Gone are the heady days of requiring IBM's 1.3 JDK because it was the only one that handled large numbers of open ports gracefully.

That does not mean all remnants of those days are gone, however.

Over the years, most of OpenNMS has gone through an architectural upgrade, under the guidance of Matt Brozowski. Whole subsystems were cleaned up, rewritten, and/or modernized. 3 glaring exceptions remained, until recently: Capsd (the capability scanner), Notifd (the notification engine), and the web UI (I don't know if it's web 1.0, or web 0.9, but well... it needs an upgrade.) Thanks to the recent implementation of Provisiond, I'm happy to say we only have two glaring exceptions to the wonderful architectural upgrades OpenNMS has gone through. Notifd: I'm coming for you next!

Capsd! Huugh! Good God, Y'all! What Is It Good For?

OpenNMS has three distinct phases when it comes to how it discovers and works with nodes:

1. Discovery (What's Out There?)

   Discovery is the beginning of the life of a node. OpenNMS does a ping sweep across the range of addresses specified in your configuration, and says, "did it respond?" If the answer is "yes," discovery shouts into the event bus, "HEY! I suspect I might have found a new node!" Discovery is not actually a requirement of OpenNMS, it is entirely possible to use it without doing discovery, either by sending your own newSuspect event (through a script, or the "Add Interface" link in the admin UI), or by using the model importer.

2. Capability Scanning (What Does It Do?)

   Capsd, the capability scanning daemon, listens for newSuspect events, and says, "Hmm, what is this IP address capable of?" It does service scans (based on the capsd plugins defined), checks for SNMP, and does some other things to determine whether it's a new node or part of another node, and what services are publicly listening.

3. Monitoring (Is It Still Doing It?)

   Once a node has been discovered and capability scanned, it goes into the queue to be monitored, based on the poller-configuration. At that point it becomes a part of the normal poll/data-collection/thresholding/notification cycle that you know and love.

The Model Importer

Some of our users are integrating OpenNMS into larger systems, or want tighter control over what nodes OpenNMS is aware of than can be provided by a ping sweep and Capsd scan. For that, we wrote the model importer, or "provisioner".

To use the model importer, you would create an import definition XML file, which describes the nodes, their interfaces, and services which you want to manage directly. Most folks who are doing this either export from some other internal database of managed nodes, or use the Manage Provisioning Groups UI and custom-build a set of nodes directly. You hit the import button, and voila! Your database is populated with the exact set of nodes, interfaces, and services you specified.

This is very powerful, but also very rigid. It's pretty much an all-or-nothing affair; there's no room for discovering extra information about provisioned nodes.

What Does Provisiond Do?

Provisiond replaces the functionality of Capsd, and replaces and expands upon the old model importer, by defining not only the nodes and interfaces you wish to monitor, but also adding the ability to distinguish how we should behave when importing these nodes. It has a pluggable architecture which allows for defining policies such as, "scan the imported node, and if it's in this IP address range, automatically put it in the routers category," and "scan the specified interface, automatically discover the SNMP interfaces, and if they are non-IP, don't bother putting them in the database."

Architecturally, Provisiond is chopped up into a number of subsystems:

• The Provisioner

  This is the meat of provisiond, it's responsible for managing a provisioning "lifecycle," which includes scheduling scans, listening for events, and kicking off the various parts of scanning and writing to the database. Matt has written a very powerful engine for doing these various tasks which I suspect will move into other parts of the code as we refactor them in the future. There's a lot more flexibility in determining when things will be scanned than Capsd's main loop.

• Detectors

  The detectors are the replacements for Capsd scanners, and they've received an upgrade over their Capsd counterparts as well. They've been rewritten with an architecture that allows them to run asynchronously, so service scans which take a while don't have to bottle up the scanning of other nodes. Additionally, the SNMP scanning has received an upgrade that lets us react to bulk gets as soon as a complete "row" of data is received, so node sub-interfaces discovered through SNMP will start showing up sooner.

• Policies

  Policies act as filters on the data as it's coming in. We've got a few simple ones in the first release, but since they're written with a very simple and pluggable API, it makes it easy for you to define your own business logic by creating an incredibly simple class and dropping it in the classpath.

A Bit More on the Model

The existing model importer had the concept of a "provisioning group," which is a collection of node/interface/etc. definitions, and was configured through the Manage Provisioning Groups UI. Each provisioning group had a "foreign source" which defined a discrete collection of nodes, so that if you removed a node from that foreign source, it would be deleted from the database as well.

In Provisiond, the foreign source is no longer just a tag that's a unique identifier, it's a definition of the behavior of the provisioner (ie, defines the detectors and policies). To that end, we've renamed the generic "provisioning group" to a Requisition. There is then a separate configuration for the Foreign Source which defines the policies which describe how the requisition is imported.

What Works?

At this point, almost everything. The only thing missing is the part that listens for newSuspects, so it doesn't completely replace Capsd as of yet. However, barring that, all of the functionality of Capsd is essentially implemented in Provisiond at this point.

How Do I Try It?

Grab a 1.7.1 snapshot or build from source, and fire it up. Provisiond is enabled by default now, and you can go to the Manage Provisioning Groups link in the UI to try it out. Did I mention this is unstable software? Really, it's unstable software. Don't do this on a production system! That said, it's cool. =)

Upcoming Events

• March 14th, 2009: OpenNMS User Conference Europe 2009 will be held in Frankfurt am Main, Germany.

• April 6th-10th, 2009: OpenNMS training will be available through The OpenNMS Group at the OpenNMS training facility in Pittsboro, NC.

• June 14th-19th, 2009: OpenNMS Dev-Jam 2009, the annual OpenNMS developers conference, will be in Minneapolis-St. Paul this year.

If you have anything to add to the events list, or you wish to be a Dev-Jam sponsor, please let me know.

I'm Beat

Man, it was a lot of work to write that up. I'm so tired, I just might miss TWiO next week. We'll just have to see. ;)

As always, if you wish to berate me publicly, feel free to leave a comment on my blog, and if you wish to berate me privately, feel free to send me an e-mail. Until next time!

Welcome to This Week in OpenNMS for Friday the 13th. It's yet again time to take a look at what's been going on in the world of OpenNMS development.

Project Updates

• Stable: Current Release is 1.6.2

  1.6.2 is still the current release, and while there are a few fixes pending since it's release, there are no immediate plans for a 1.6.3 yet.

• Unstable: Current Release is 1.7.0

  Trunk has been moving fast still, and I hope we'll get a 1.7.1 release out soon-ish, but we're still trying to get provisiond up to a demoable state first. In the meantime, feel free to try the nightly snapshots (if it's not on a production system, of course).

• Trunk: Javamail Updates

  Dave's been working on refactoring our javamail support into it's own module, to make it easier to reuse in different portions of OpenNMS.

• Trunk: RANCID Integration

  Guglielmo continued work on the RANCID integration; the API has stopped changing much and most of the work has been going on in the UI at this point.

• Trunk: Provisiond

  Matt has most of the provisiond code working, some simple scanning is possible now, there are just a few loose ends to tie up before there's a working prototype.

• Trunk: Node Page Updates

  Donald's spiffy new ajaxy node page is active, and lets you page through data related to the node directly in the node page.

• 1.6 Testing: Minor Updates

  Jeff, Bill, and a few others have done some minor updates to 1.6-testing (which of course are forward-ported to trunk as well) including IE rendering issues, additional MIBs, read-only KSC report support, and more.

• Trunk: Map Updates

  Antonio has continued work on the new trunk map code, which includes support for all modern SVG browsers (Safari, Firefox, and IE with the Adobe SVG plugin).

• Trunk: RESTful Support for Map Data

  Matt Raykowski submitted RESTful API support for map and related data (map elements, linkd data, etc.) which will be useful for future map work.

• Trunk: XMP/Cartographer Support

  Jeff merged Bobby Krupczak's Cartographer agent support for OpenNMS to trunk.

  Cartographer "implements a novel approach to managing distributed systems by automatically discovering and tracking the relationships between its component systems and applications. Cartographer does so via specially designed agents -- residing on clients, servers and (potentially) network devices -- that detect, identify, and track the inter and intra-system dependencies or relationships. Dependencies include network level services like DNS, DHCP, and SMTP as well as higher-level application abstractions like filesystems, databases, directory services, telephony, and middleware."

Upcoming Events

• March 14th, 2009: OpenNMS User Conference Europe 2009 will be held in Frankfurt am Main, Germany.

• April 6th-10th, 2009: OpenNMS training will be available through The OpenNMS Group at the OpenNMS training facility in Pittsboro, NC.

• June 14th-19th, 2009: OpenNMS Dev-Jam 2009, the annual OpenNMS developers conference, will be in Minneapolis-St. Paul this year.

If you have anything to add to the events list, or you wish to be a Dev-Jam sponsor, please let me know.

If You Can't Love the Source You've Opened, Open the Source You Love

That's all for this week. I hope you all have a wonderful valentine's day if you're into that kind of thing. As always, feel free to drop me a line if you have any questions, comments, or if you wish to know my address so you can send me some mysterious white powder through postal mail.