OpenSUSE Meanderings

At work we debated adding OpenSUSE 11 as
an officially supported platform[ 1]. In the past, when doing this, I’ve
preferred using the targeted platform exclusively for an extended period. For
various reasons, this hasn’t been feasible this time. While testing time has
been devoted to it, that doesn’t give one the same familiarity as using it for daily tasks.

Since I am a KDE user, I decided to convert my
Kubuntu home desktop[ 2] to OpenSUSE 11,
using KDE 3.5. This conversion happened about two months ago. While it isn’t
quite the same, it has provided a very nice experience which augmented our testing.

From the personal, non-work related, standpoint, I am very satisfied with
OpenSUSE 11 as a deskop OS. The developers have produced a very usable KDE
environment. I’m looking forward to upgrading to KDE 4.2 in OpenSUSE 11.1. The
distro as a whole “feels” (subjective I know) more complete and solid than
Kubuntu. At some point I will distill my thoughts into a real article, but this is all for now.

From the work-related standpoint, we will eventually support OpenSUSE, but it
will require a bit more work and time than planned. Part of the reassessment
stems from the need to refactor both processes and code to work with a
non-YUM[3][4] based system. In the long run this will be a good thing however as
zypper is far more robust application than YUM.

[1] We actually will unofficially support operating systems. This means if
someone opens a support ticket with us, we will assist the user to surmount an
issue. This typically does not involve submitting changes to our product.
However, even that is a guideline. Some months ago a ticket came in regarding
FreeBSD jails. We don’t support such, and the customer knew it, however he was
willing and able to work around various deficiencies to run our product and had
done so for a few years. A recent change in our product broke his setup. I was
able to track down the change and we provided a fix that was merged into the
product. In this case the fix benefited the wider audience. return

[2] For sometime I had contemplated migrating from Kubuntu as many things about just were no longer satisfying. return

[3] One test was to install YUM and put our product through its paces. YUM was
adequate for installing most packages, but it simply cannot replace zypper for
full system package management. There were times when YUM simply could not
update the system, requiring us to use zypper. return

[4] This is non-YUM Linux as we do support FreeBSD although our handling of
package management therein is rather poor. Standard procedure for experienced
users of our Product on that platform is to disable our product’s management of Ports and Packages. return

From Tech Support to QA

Resolve the issue and move to the next one. This is a common mind set among the Tech Support personnel where I work. This is certainly commendable from the customer’s view point as the customer certainly wants the issue resolved and in a timely fashion. However, what benefits the customer more:

1. Resolve the immediate problem; or
2. Resolve the underlying issue (wherein the problem reported by the customer is merely a symptom of a different problem)

A key question for transitioning from point 1 to 2 is “why?” E.g.

• Why did this problem occur?
• What data or environment change caused this?
• Why does the ( data or environment ) cause this issue?

Asking the questions and tracing symptoms to the source is invaluable. Once the source is identified, one can determine reproducibility and define a test, all of which can lead to a fix. Once the issue is fixed, we can Assure the problem will not reoccur in the future, for this customer or others.