15 January 2008

Motion to the Board: Proposed Community Group Creation

APPROVED by the OGB on Feb 6th, 2008

Summary

The OpenSolaris community needs a new Community Group to facilitate collaboration, design, and development of OpenSolaris-based distributions. Because of new tools that are already available to the community, but are rapidly reaching maturity, it is probable that there will be a large number of community-based distributions being created soon. In addition, the current set of Community Groups available to sponsor projects are not properly scoped or otherwise suitable for the nature and goals of distribution projects. As such, the creation of a new Community Group is needed.

Scope
The proposed Distribution Community Group shall be the group to which the OGB delegates responsibility for encouraging the sustained growth and success of OpenSolaris-based distribution projects. Distributions that have previously been sponsored by another Community Group may remain with that group. However, it is hoped that all such projects will approach the contributors of this new community to seek reassignment (sponsorship), or that if necessary, they be reassigned.

The Distribution Community Group should be the central place for discussions and decisions regarding OpenSolaris-based distributions and their impact upon the OpenSolaris community. To support this, it is proposed that the OGB will allow the group to act as the initial arbiter in dispute resolution amongst distributions and related projects.

Some examples of dispute resolution might include: acting as an arbiter between distribution project leaders when disagreement between them arises, ensuring that any relevant policies and guidelines established by the constitution or authorised governing body are followed, and encouraging reconciliation when there are disputes.

The Distribution Community Group will actively work to ensure that there is a healthy relationship between its sponsored projects and the rest of the community. It will accomplish this by doing things such as: ensuring that feedback from the group's sponsored projects is provided to the related Community Groups and projects, encouraging the further development and creation of tools related to the development of distribution projects, and ensuring that projects coordinate their releases with related Community Groups (such as the Advocacy Community Group).

The Distribution Community Group will also work to establish unified processes and resources to assist distribution projects in contributing to the sustained growth and success of our community. The usage of a common set of resources will help keep our community's efforts from becoming fragmented. Promoting the use of these unified resources and processes (such as a reference technology platform) will allow individuals to be free to innovate in many areas of OpenSolaris technology instead of reinventing the basic tools and processes that every distribution project needs to operate.

Rationale
There are many reasons a Distribution Community Group is needed. One of them is that past events have shown that none of the existing community groups are wholly suitable for the community-wide impact that distributions can have within the OpenSolaris community. In addition, none of the existing Community Groups are properly scoped for the kind of decisions that need to made to by a knowledgeable, focused group of individuals whose primary interest relates to the production of distributions.

Finally, the tools necessary to build a distribution are quickly reaching maturity, and the Community Group will encourage individuals creating or maintaining distributions to participate directly in the OpenSolaris community to avoid some of the past problems that have arisen.

Proposal
The core of this proposal is to:
  • Create a Distribution Community Group
  • That existing distribution projects be encouraged to seek re-sponsorship or be reassigned to to this new community
  • That the following individuals be considered for the initial set of core contributors (they have each accepted this nomination):
    • Shawn Walker (id: swalker) (proposed facilitator)
    • Erast Benson (id: erast)
    • Eric Boutilier (id: ericb)
    • David Comay (id: comay)
    • Sara Dornsife (id: sarad)
    • Glynn Foster (id: gman)
    • Moinak Ghosh (id: moinakg)
    • Jim Grisanzio (id: jimgris)
    • Stephen Hahn (id: sch)
    • Ian Murdock (id: imurdock)
    • John Plocher (id: plocher)
    • Joerg Schilling (id: joerg)
Proposed Contributor List
The following individuals are those that I would like to have as the initial core contributors (those that have already accepted are listed above in the proposal section):
  • Ken Mays (id: kmays)
  • Danek Duvall (id: dduvall)
  • Dennis Clarke (id: dclarke)
  • Bart Smaalders (id: barts)
I would ask the OGB consider this proposal two weeks from January 16th, 2008.

Thank you for your attention to this matter.

[Proposal Version 10 - Updated Feb 7th, 2008 05:26pm CDT]

07 November 2007

A proposal for ensuring sustained Community Growth and Success

This proposal is intended to provoke productive discussion, surrounding our current governance structure, by highlighting some of the deficiencies that currently exist. While not exhaustive, it attempts to explain why the current governance structure is insufficient for the success and growth of the community, by comparing and contrasting our existing governance model with that of other organisations at a high level. It also suggests how our governance structure might be changed to address those deficiencies.

It is the author's hope that all recipients of this proposal will take the time to reflect on and carefully consider the points made here before responding. This proposal is primarily directed at the OGB, as representatives of our current governing structure. However, all recipients are encouraged to respond. The inspiration for this proposal is a direct result of recent events which revealed that governance of the community is at the heart of issues facing the community today.

The OpenSolaris community has existed as a self-governing entity since Friday February 10th, 2006 [1]. Since that time, individual parts of the community (and thus, the community as a whole) are continuing to make progress in many areas, including: technical, communication, and growth [2]. The community has grown slowly, but surely, into something that we can continue to be proud of. The Advocacy (User Group), Desktop, DTrace, and ZFS community groups are just a few examples of that growth and progress.

However, the majority of this progress is a result of Sun's indirect leadership [3], involvement, and the contributions of many individuals within the community. Many of those individuals are paid by Sun to work on Solaris, OpenSolaris, and related community projects. It is important to note the distinction of “paid by”; as many individuals are not employees of Sun (contractors) or were not employed by Sun at the beginning but currently are. By observation, it is apparent that none of this progress would have been possible without Sun's initiative to provide the source code that served as the nucleus around which the OpenSolaris project formed, and without their ongoing, significant financial support (which the author estimates to be in the range of millions of dollars).

Clearly, governance is one of the most important aspects of the community. However, governance alone is not sufficient to achieve sustained growth and success in a completely self-governing body, such as the one we currently have. The leadership hierarchy must be clear, and seen as inspirational [4], creative, shrewd, and fair.

Upon reflection, it should become apparent that leadership and guidance is a necessary part of governance. To help us better understand our current governance model, it is helpful to compare and contrast our own governance model with that of others. Narrowing our focus, from the many governance models widely known, results in several which we will briefly examine. Commercially related projects include: Mac OS X [5], PostgreSQL [6], MySQL [7], and Ubuntu [8] (created and supported by Canonical [9]). Other projects are those such as Fedora [10], which are essentially alpha or beta representations of commercial products [11]. Finally, we have Apache [12] and OpenBSD [13]; which are organised around completely open source [14] products.

All these projects or products share several common characteristics. However, some characteristics are common and clearly visible: sustained growth and success. Each project or product has a parent entity that continues to build a community providing sustained growth and success, whether they are primarily proprietary in nature [5], have taken a hybrid approach between open source and proprietary add-ons [7], or have the primary focus of the project completely as open source [6, 8, 10, 12, 13]. They may also be experimenting with pay-for-contribution models.

In each case, clear leadership within well-defined areas of expertise is evident. There is a direct correlation between the quality of the leadership and the sustained growth and success of each project or product. The results are evident in a successfully delivered and widely-adopted end-product within their respective target markets.

For a moment then, let us consider the leadership that is integral to these projects and products. In Apple's [15] case, few would dispute that Steve Jobs is clearly the primary source of leadership, and has been directly responsible for their current success [16]. Likewise, the OpenBSD project is well known for its leader, Theo De Raadt, who, while sometimes outspoken [17], has relentlessly driven the project towards an admirable level of fervour and success [18] as defined by its stated goals [19].

Investigating further, we see that each one of these projects has structured its leadership or governance differently. The Fedora project chose a mix of appointed and elected members with RedHat given final veto power (with the intention that it is to be used infrequently) [20]. The OpenBSD project seems to have chosen its leader as a result of a meritocratic [21] view (Theo is responsible for the project's existence and also responsible for a significant portion of engineering and other efforts) [19]. Finally, the Ubuntu community also chose to follow a meritocratic governance model [22] that includes teams (similar to our community groups), a technical board (similar to our ARC), a community council (similar to our OGB), and a clear leader (otherwise known as SABDFL [23] to which we currently have no equal).

With the current governance structure of our community, the author does not see a way for our community to achieve the required sustained growth and success. The current governing board, as originally intended, does not have the ability to provide the clear leadership that our community requires. Recent discussions on our mailing lists have made it quite clear [24] that community groups are responsible for the day-to-day leadership and activities within our community [25].

However, the constitution does not specify which community groups are responsible for which activities and leadership roles. As a result, recent discussions [26, 27] have lead to limited consensus about whom has authority over these activities that are seen as representing the entire community [28].

It is apparent, as a result of this, that our community is unable to decide what the vision, purpose, and goals of our community really are. This is surprising, given they were defined at one point [29]. Clearly, our community has not decided who represents our leadership in these areas.

This leadership issue has resulted in the failure of our community to achieve the level of sustained growth and success required for our continued existence. It also illustrates the need for clear, inspired leadership within our community. Clear, inspired leadership naturally provides the sort of vision [4] that we require to determine a clear direction, and a set of goals; while ensuring consensus about who controls different areas of the community.

The real issue behind our current troubles is not primarily technical or logistical (as the author erroneously previously believed) in nature; it is not about naming, trademarks, or branding; it is about the failure of community groups to take up the responsibilities, that the OGB, empowered by our constitution, has delegated to them [24] (which may be because they were not informed of this delegation; adequately or at all).

The primary failure, as the author sees it, is that we currently have no efficient, effective way to ensure that decisions will be made when no clear consensus exists [30]. The OGB is currently unable to guide our community in many situations, as they are not empowered to do so, and voting on every issue is likely to end in deadlock either due to the apathy of eligible voters [31] or a vocal minority that prevents consensus from being achieved.

Consequently, the author believes that our governance structure must be revised to prevent the current retardation in the growth and success of our community. To achieve this, a specific individual must be designated to provide the clear, inspired leadership role that our community needs, along with empowering the OGB, to ensure that an overall direction and vision for our community can be established.

We need to remember that Sun deserves special consideration as the founding member of this community, the primary (and only as far as the author is aware) financial supporter, and trademark holder. They deserve, nay, must, have a key role in directing this community, especially in the areas of product development and marketing.

The author believes that Sun must be allowed to fulfil this role as a key leader for many reasons. Sun is accountable to their shareholders for their significant financial support they provide to the OpenSolaris project; whether that is directly or through a foundation is immaterial. The potential for our sustained growth and success, and to a certain extent, Sun's, is directly tied to the community. Failure or Success by either Sun or of the community will affect both.

In conclusion, to resolve these deficiencies, it is the author's belief that our existing governance structure must be revised to ensure that clear, inspired leadership is provided to our community (as a whole). Communities surrounding the Linux kernel [32], Ubuntu, Python [33], OpenBSD, Apple, et al. have shown us how significant, sustained growth and success can be achieved when a specific individual helps provide the clear, inspired leadership every community needs. Our community would not even exist today if were not for the decision of leadership (notably, Jonathan Schwartz) [34] at Sun to provide the source code that provides the reason for our existence.

The only remedy available, in the author's view, is to ensure that four changes are made by amending our constitution:

1) The OGB is empowered to make more decisions for the community.

2) An individual is chosen by our community to work with the OGB. They will provide clear, inspired leadership and vision. It must be made known that this position is one that is likely to be full-time and require their complete focus. Any individual that is part of our community should be eligible for this position regardless of whom they are or are not employed by.

3) That Sun is permitted, as the principal stakeholder in our community, to play a key role in product development and marketing of the OpenSolaris trademark (which they own) given their clear experience, accountability to their shareholders, and success in this area. This role must be given a greater degree of authority than what is currently granted by the constitution.

4) That the role of product development and marketing, as outlined in our constitution, should be shared with Sun in a well-defined manner with qualified members of the community.

Without Sun's continued support, the vision and clarity of inspired leadership that a qualified individual can provide, and the further empowerment of the OGB; the community will not achieve the sustained growth and success that it requires for its continued existence [35].

--
Shawn Walker

P.S. The author appreciates and acknowledges the help of other community members (you know who you are!) who persevered ( :-) ) through earlier drafts of this document. This proposal would not have been possible without your assistance.

P.P.S. This proposal was originally posted on the ogb-discuss mailing list. You can read the responses to it here. I encourage everyone to respond on the ogb-discuss mailing list (or here of course).

07 March 2007

OpenSolaris 2007 OGB Election Statement


"Why should I elect you for a position on the OGB?" you might ask. In short, I believe I should be elected because I feel I can best represent the interests of independent OpenSolaris developers. The long answer is a bit more involved.


I have participated in the contribution process for the OpenSolaris project, so I am personally aware of the long process involved in becoming registered, researching, testing, and getting contributions integrated. I also feel that my perspective of the OpenSolaris community is possibly less "biased" (for good or bad) since I have no affiliations (past or present) with an entity that has commercial interests in Solaris or OpenSolaris.


In addition, since I have only been part of the Solaris/OpenSolaris communities since 2005, I feel that I am less likely to look at certain aspects of the community with "rose-coloured glasses" since I am not intimately familiar with much of the possible history surrounding them.


Finally, Like Stephen Lau, and many others (including the current and past members of the current OGB), I believe that the OGB should be a group that primarily acts in a support role to serve the OpenSolaris community. My goals, if elected, are to do everything possible to:


  • Lower the entry barrier for new members to contribute to the community (regardless of the type of contribution, it does not have to be "code") where possible
  • Streamline the RTI process
  • Ensure that there is open communication with the community
  • Encourage growth of the OpenSolaris community
  • Help unify our community through strategic consolidations of projects and efficient allocation of community resources
  • Ensure that our community does not become fragmented
  • Streamline the processes involved in being recognised as a contributor or as a nominee for elections
  • Ensure that the OGB is involved in the day-to-day operations of the community as little as possible
  • Help the community achieve its goals (especially those listed on the roadmap)

It should be noted that the current and past CAB/OGB has, in my opinion, worked towards these goals with an admirable fervour. The new OGB can only hope to continue and improve upon the work that was started by them as time passes.

01 March 2007

Looking for Solaris USB Tips?

If you're looking for information about USB Device support on Solaris, then I have good news for you! The Solaris Ready USB FAQ posted on SUN's website probably has the answers you are looking for. Recently, I had a problem getting my external USB / Sata Hard Drive Enclosure working and found the USB Storage section of the FAQ invaluable.

24 February 2007

An alternative to packages

I have a set of software I want to provide for the Solaris 10+ community (more on that in the coming weeks). However, the existing solutions for distributing software for Solaris (and other UNIX like systems in general) are sadly lacking. It might seem backwards to some, however, I feel that before I begin the porting and distribution effort for this new software I need a good way to distribute it that makes it as painless as possible for all parties involved. Ease of maintenance, as a developer, is especially important to me.

With that in mind, I am researching different options for easily distributing software to Solaris users. Note, I said users and not administrators, although this can just as easily apply to them as well. Users want to run their software with as little pain as possible, and developers need a way to distribute the software that users want to run with as little pain as possible. That requires a distribution system that meets certain goals:
  • Anyone can install software
  • Anyone can distribute software
  • It doesn't matter whether the software is installed or not
  • Shared downloads
  • Good security
All of these goals are important. In the past, other projects such as blastwave, SUN Freeware, OpenPKG and others have provided solutions that work great for administrators, but aren't so great if you're not the system administrator. Thankfully, we don't have to sacrifice the goal of allowing users to run the software they want or any of the other ones listed above. Not only that, we already have a solution that achieves every one of those goals: The Zero Install System.

The project leader, Dr. Thomas Leonard, has been very helpful in assisting me with these efforts and welcomed contributions. The past week or so, I have been looking into what changes are necessary to allow Solaris to be a fully supported and operational platform for the Zero Install System. Since Zero Install is written in python, it is already fairly portable by nature.

I have been working through the test suite included with Zero Install making whatever changes are necessary for it to pass all applicable tests and I am just about finished. I have not had to make many changes due to the excellent work performed by the Zero Install team and its contributors. So far, all of the changes I've done are found in the unpack library.

While the Zero Install System is not yet fully functional, you can be certain that I will be doing whatever is needed for that to happen. I will post an announcement here once I am certain that it is fully functional, and have a sample software package available for testing. Meanwhile, I suggest reading the following material related to Zero Install and installation / packaging systems:

14 June 2006

Happy First Birthday OpenSolaris

It is hard to believe that a year has already passed. So much has happened in the OpenSolaris community since the project was first officially launched. The most important of these things to me have been: charter establishment, release of binaries for libm, sccs, and make, release of the solaris packaging software and code, the establishment of the desktop and laptop communities, the release of a ndis wrapper and configuration tool, and the selection of a distributed source code management system.

Looking back, I was able to submit several small patches that were later integrated into the OpenSolaris project. While these patches were trivial in nature, each bit was an expression of my appreciation for the contribution that SUN has made to the community. In addition, it was a joy to work with people such as Dan Mick and others at SUN that helped integrate my changes. The community and people inside of SUN have provided a veritable cornucopia of useful resources. Some of the resources and people that helped me over the last year include:

* Dan Mick's blog postings, such as a posting about diagnosing kernel troubles. Dan also provided extensive personal assistance that helped get me through several technical hurdles, and the code integration process.

* Bryan Cantrill's blog with heaps of postings about DTrace.

* Ben Rockwood's blog with several introductions to Solaris methodology, as well as an important resource for Solaris enlightenment addicts.

* Alan Hargreave's blog. Chock full of reflections on Solaris/OpenSolaris, life, technical information, and most important of all: brewing information.

* Jim Grisanzio's blog, for a great perspective on the community, and for being a righteous defender of all that is just.

* Glynn Foster (aka Gman), whose tireless assistance with JDS was quite helpful.

* Dennis Clarke, who has provided a significant amount of resources through blastwave.org, to ensure that community members have access to a high quality resource for software. Not only has Dennis provided this service free to the community for years, but he has also provided resources for developers to build and provide that software to the community.

Those are just a few examples of great resources and people that are part of the OpenSolaris community.

In the near future, I hope to pick back up some of my patches that I had to previously abandon due to a sudden career change and past schedule demands for University. I've been writing code since I was a child, and programming for almost eighteen years. Yet, after all of these years, I still enjoy doing so. My contributions to the OpenSolaris project have been a labor of love, and I look forward to contributing more over the years to come.

05 August 2005

vim for the blastwave impaired

For those of you that wanted vim packaged for x86 without using blastwave. There is hope:

http://icculus.org/~eviltypeguy/pkg/vim/

You can grab the pkg along with everything build-system or source-related that I used from there. The simple instructions if you want to rebuild it your own way:


  1. Download the vim-6.3.tar.bz2 and all the other files at the URL listed above, extract the vim tarball to a build directory of your choice.

  2. Place the "copyright", "pkginfo", and "vimtopkg" files in the newly extracted directory.

  3. Edit pkginfo with your editor to match your personal info.

  4. Do a configure with something like what is below from the top level directory adding or disabling features as you please, replacing the --prefix with one of your own choosing.:
    ./configure --prefix=/opt/BCvim --with-features=huge --with-compiledby='my @ email address' --enable-perlinterp=no --enable-pythoninterp --enable-tclinterp --enable-cscope --enable-workshop --enable-multibyte --enable-xim --enable-fontset --with-x --enable-gnome-check

  5. Perform the make from the top level directory:
    make

  6. Run vimtopkg from the top level directory:
    ksh ./vimtopkg

  7. Tell it you want to use the pkginfo file.

  8. Be amazed as a complete package is written out for you ready to enjoy via pkgadd



Thanks to Phil for the original gnutopkg script that I based the vimtopkg ksh script on. I also have a more generic one suitable for packaging just about any autofoo* based program.

Technorati Tags:

06 July 2005

Whodunit? Finding what package a file belongs to

Those of you who are refugees from the RedHat Linux world, may be used to a rather simple way of finding out what package claims responsibility for a particular file. Well, you'll be relieved to know it's just as easy to find out under Solaris as it is when running RPM based Linux distributions. Here's a simple example of how I found out what package references /usr/bin/nautilus:

/usr/sbin/pkgchk -l -p /usr/bin/nautilus

Here is the resulting output:

Pathname: /usr/bin/nautilus
Type: regular file
Expected mode: 0755
Expected owner: root
Expected group: other
Expected file size (bytes): 677516
Expected sum(1) of contents: 25862
Expected last modification: Dec 16 11:52:16 2004
Referenced by the following packages:
SUNWgnome-file-mgr
Current status: installed

Technorati Tags:

23 June 2005

UTF-8 Locales: Disabling the Language Box

Thanks to Laurent Blume who recently posted the *real* solution (not the cheap hack I posted a few months back) as to how to disable the incredibly annoying language selection boxes that JDS and Motif feature by default under Solaris 10 and UTF-8 locales. The solution is simple and kudos to Laurent for finding it!

Technorati Tags:

17 June 2005

Solaris Development Tip

Beware /usr/ucb.

By default this is in your path, and if you want to use the SUN Studio compilers to compile anything and everything, you need to either put /usr/ucb after /opt/SUNWpro/bin in your path, or take it out completely (highly recommended).

The reason for this? As far as I can tell /usr/ucb/cc implies -Xs, since /usr/ucb/cc is designed to act as an interface to the BSD Compatibility Package C compiler. So, if you go along your merry way and try to compile source code that uses C99 extensions, such as the following:

#define a(...) foo

You may encounter bizarre errors such as:
"test.c", line 1: bad formal: .
"test.c", line 1: bad formal: .
"test.c", line 1: bad formal: .

What clued me into what was wrong was the following warning when I tried to enable c99 extensions:
/usr/ucb/cc -xc99=all -o test test.c
cc: Option -Xs requires -xc99=none

Obviously, I'm not passing -Xs myself, so /usr/ucb/cc must be implying it automatically. I encountered this while trying to compile the latest version of metacity (the default GNOME window manager). While I realise many Solaris old-timers may already know about this, I thought I would pass it along as I'm fairly new to Solaris development myself.

I've been told and have read comments by a few different friendly SUN engineers that there is no good reason to have /usr/ucb in my path. I plan to follow their advice.


Technorati Tags:

16 June 2005

Solaris Express Community Release Tip

If you're having problems booting the Solaris Express Community Release (necessary to Build OpenSolaris), try unplugging any USB devices you have connected to the system (especially if it's a Logitech Optical USB Mouse). There's a bug right now that prevents some systems with certain USB Mice from being able to properly boot the Solaris Express Community Release. I have been told that a fix will be put out for this soon.

Additionally, when you have any problems booting the Solaris Express Community Release, you should read Dan Mick's blog entry about debugging the boot process so that you can provide more information to those who can fix it.

Technorati Tags:

15 June 2005

OpenSolaris is here!

What are you still doing here? Get it now!

Technorati Tags: Solaris OpenSolaris

05 May 2005

Groups vs. Roles

Like me, you may be a bit fuzzy on the high level differences between groups and roles, after all they do have a lot of similarities. Rohan Pinto de-mystifies them for us rather nicely.

Technorati Tag

24 April 2005

Solaris 10: Yet another development tip

A little note about something to be careful of when compiling and developing applications within a non singlebyte locale (a Unicode or locale other than "C"). You should always check the man pages of the utilities you're using in your build process or anywhere else first before using them. Some of the utilities that are in /usr/bin or /bin only properly handle singlebyte locales and won't work properly in others.

For example, the "tr" utility in /bin/tr or /usr/bin/tr will fail with a not-so-helpful message about "bad string" when in reality you've given it perfectly valid input. This is a result of it not supporting singlebyte locales. Instead, you will have to use /usr/xpg4/bin/tr or /usr/xpg6/bin/tr which support multi-byte locales.

Technorati Tag

19 April 2005

Solaris 10: A Few Development Tips and Solutions

Like me, after setting up Solaris 10 and getting your development environment going with the gcc that comes "in the box" (or "in the iso" as is the most likely case), you may have run into bizarre errors when running "configure" for programs you tried to compile and install. "configure" spouts things like system unable to compile programs, no proper compiler installed and so forth. You may also have encountered errors about missing symbols that look like they come from libstdc++. Well, be mystified no more. Four easy steps to a more blissful development environment:

1) Remove /usr/ucb from your path. You probably won't miss it, and unless you have the SUN studio tools installed, it's best if it's not in your path anyway (due to /usr/ucb/cc I believe).

2) Apply the fix found here for SUN's possible oversight.

3) Add /usr/sfw/bin to your $PATH (preferably *first* in my opinion)

4) Add /usr/ccs/bin to the *end* of your $PATH

Have fun!

Technorati Tag .

09 April 2005

Need a quick way to kill the X server?

Recently I had an X11 program misbehave and esentially make my JDS desktop unresponsive to my input. Since I don't have another system nearby where I can login in via SSH and kill Xorg manually, I've just been hitting the reset button because for some odd reason Control + Alt + BackSpace doesn't kill the server by default with Solaris 10 (on some systems possibly?).

Well, I happened to post about this on the Solaris x86 Yahoo Group Mailing List and Adrian Saul along with Casper Dik of SUN were kind enough to post the solution, and why it was needed. The solution is simple, add the below to the bottom of your /etc/X11/xorg.conf:


Section "ServerFlags"
Option "HandleSpecialKeys" "Always"
EndSection


Solved the problem rather nicely, fear misbehaving X11 programs no more!

Technorati Tag

07 April 2005

Packaging Options?

Continuing on with my journey into the world of Solaris...

A problem has confronted me, namely what to do about packaging. Yes, Solaris 10 comes with it's own packaging system. However, let's be honest, it's not nearly as convenient to use as RPMs are, especially when you need the ability to rebuild packages on demand easily.

Since the company I work for uses RPMs to manage all of our software installs via an apt-get repository (which works really, really well by the way) now on RedHat Enterprise Linux boxen I wanted something as similar as possible. I first tried to compile the latest RPM source on my own, and discovered that it was disappointingly Linux focused (Linux isn't UNIX folks, please stop using non-portable functions, etc.). Enter OpenPKG.

OpenPKG provides me with a way to migrate our existing software management structure with fairly little pain over to Solaris 10 while retaining all the conveniences and benefits of both binary and source package management. It also makes people happy that might have otherwise been unhappy with my constant push to move from a Linux platform to Solaris 10.

Some people might think it's rather abhorrent to have multiple packaging systems on their Solaris box, but I don't think so. Especially since this way, I can isolate all the packages or custom versions of common libraries we use into its own directory tree without interfering with SUN's packages in any way and feel safe in the assurance that any changes to my OpenPKG tree won't impact the rest of my system in any permanent fashion.

Yes, I already considered other solutions such as pkgsrc, pkg-get, and so on. However, none of them really have the elegance or simplicity that I needed for managing a completely custom software repository comprised of both binary and source packages. I am interested in other projects out there that are similar to RPM if they exist. Leave a comment if you know about something I don't...

Technorati Tag

08 March 2005

Solaris 10: JDS3 UTF-8 Behaviour giving you the blues?

Like me, you might be an application developer that has to be setup for a UTF-8 development environment, and needs to run their desktkop and everything in the en_US.UTF-8 locale. I do because I run a apache process under my own user account for my mod_perl development work.

You probably figured out that to do so you had to set LANG in your .profile or somewhere else. I set LANG=en_US.UTF-8 in /etc/default/init personally. However, once you did that, you were in for a somewhat unpleasant surprise in JDS. Enabling a UTF-8 based locale causes JDS to attempt to be "helpful", and stick a language input selection box at the bottom left hand corner of almost every dialog on your desktop. While that would be awesome if I needed the ability to type special accented characters, or switch languages on the fly, I don't. So for me, it was just a major visual annoyance.

However, thanks to some users on the Solaris x86 Yahoo Groups Mailing List, a fairly easy solution is at hand. Edit your ~/.dtprofile file and add the following lines at the bottom:


export XIM="htt"
export GTK_IM_MODULE=iiim
export XMODIFIERS="@im=${XIM}"


Now, logout and log back in. Voila! No more annoying language selection dialogs everywhere.

Related Blogs:

07 March 2005

Solaris 10: Tips and Tricks

So...I've got that shiny new Solaris 10 installation up and running. But, along the way I've discovered some incredibly annoying things that just bug me to death. In fact, you may have discovered some of the same things:
  • Your sound card isn't supported by default
  • Your shiny new Gigabit network device isn't supported
  • You are not able to use your Home, End, Page Up, or Page Down keys in X Terminal Programs
  • There's no nifty little network configuration program to make it easy to setup your network device for DHCP
  • All of those wonderful programs you're used to easily installing via yum, apt-get, portage, etc. seem difficult at best to setup and install
What's a person to do?

Well, fear not gentle reader. I am here to bequeath virtuous Solaris bit salvation to you. All of the above problems are easily solveable, thanks to people like Ben Rockwood, those on the Solaris x86 Yahoo Group Mailing List and Sun's wonderful documentation.

Problem 1 - Sound Card Support

Two options that I know of:
  1. http://www.tools.de/solaris/audio/
  2. 4Front Technologies
The free drivers at the first URL may work for you, or may not. The 4Front Technologies drivers are probably the safest bet, though by default they're nagware until you pay for them (banner message everytime you run 'soundon', no nags beyond that) and you have to manually enable them everytime you boot your system (at the moment anyway). I use them with my SoundBlaster Audigy 2 on my Athlon64 workstation and they're quite a treat (beta status currently). Having been used to the shoddy mixers typically available under X11 desktop environments I was pleasantly surprised at the multi-channel audio support and ossxmix, 4Front's mixing program. Highly recommended.

Problem 2 - Network Device Support

I discovered after installation that Solaris 10 didn't support my Realtek 8169 based Gigabit ethernet adapter on my motherboard. However, after spending some time Googling, I found Masayuki Murayama's network driver page. Soon I was enjoying glorious Gigabit ethernet again, and as a plus it works whether you're compiling for a 64-bit kernel or a 32-bit kernel. I should disclaim any usage beyond normal desktop stuff and downloading / uploading files. Workstation level usage only here.

Problem 3 - Unable to use Home, End, Page Up, Page Down Keys

This by far was the most annoying, perplexing, and difficult of all to solve. But with some help from users on the Solaris x86 Yahoo Group Mailing List and some perserverance on my part, I finally discovered the solution (beginning of the thread).

Problem 4 - DHCP Configuration not so nifty

Setting up DHCP and my own hostname turned out to be pretty easy, even though I'm used to a nifty little text-based configuration program in other *nix-like Operating Systems:
  • touch /etc/dhcp.gani0 (where gani0 is the name of your network device driver plus it's enumeration)
  • vi /etc/hostname.gani0 (put whatever you want for a hostname inside of this file and save it)
  • reboot (there are other ways to get this to activate, but I'm lazy...)
Problem 5 - How do I install my Favourite Program?

Most of your favourite programs can probably be found at blastwave, and are easily installable via a nifty little program called pkg-get (usage and installation both found at the link).

Where to from here?

If you want to learn more, Sun's documentation site, BigAdmin, the OpenSolaris site and DryDog are all great sites to start with. As far as the blog world goes, here's my A-List for Solaris:
Whew. This little blurb has already grown long in the telling, so I'll save the other goodies for another time.

So long for now...


Related Blogs:

06 February 2005

Solaris 10: The Journey

Recently, it came to my attention that my RedHat Enterprise Linux subscription was about to expire. At the same time, the company I work for has decided they can no longer afford RedHat's overpriced subscriptions. Considering the licensing alone every year is comparable to a good chunk of one of our employee's annual salary. So, I started looking for alternatives.

From the very beginning I decided there were going to be some key requirements for whatever Operating System I was going to look at as a serious alternative:
  • Flexible Support Options
    • Every dollar counts. Should only have to buy support for the systems that need it (like our Database Servers).
    • The ability to buy support based on a reasonable scale from basic support to mission critical.
  • Flexible Licensing
    • We replace hundreds of packages on whatever Linux distribution we use because of our unique application environment requirements. Now, this is only done for the web servers where the web-based application is executed from. However, having done this it made it absolutely pointless in retrospect to have RHEL subscriptions because we had to roll our own update systems anyway to deal with our package customisations which made our systems unsupported by RedHat.
  • POSIX Environment
    • Our application is written assuming we're running on a POSIX based system.
  • *nix Platform
    • The OS must be a *nix or *nix-like platform. Every since I started using Linux in 1994, I've been convinced that *nix-like Operating Systems are the only way to go when it comes to Servers.
  • Packaging System
    • The OS in question must have a native packaging system of some kind or be able to use RPM packages. Our application is currently packaged using RPM.
    • The packaging system must be well documented or at the very least a very mature system. (RPM while mature is poorly documented in my opinion, not only because it varies from distribution to distribution in it's implementation and usage).
  • Oracle Certified
    • The OS in question must be one of the certified platforms for running Oracle Software.
  • Seamless support for 32/64-bit platforms
    • Currently my company doesn't have any 64-bit hardware. But, I use an custom-built Athlon64 system as my personal development system, and I know that eventually we will have some servers that are 64-bit capable.
    • The OS in question should be able to handle 32-bit and 64-bit applications with equal ease in the same environment.
  • Reasonable Hardware Support
    • Almost all of the hardware we use in our servers is fairly standard, has full documentation or specifications provided to the public, and is generally manufactured by "Open Source" friendly companies. The OS should support it then.
    • The OS in question must also be a viable desktop OS for developers that work on the application.
  • Specific Application Support
    • The following applications should be available for use:
      • perl
      • apache2
      • mozilla
      • Gnome Desktop
    • The following libraries should be available for use:
      • Berkeley DB
      • gd
      • libxml2
      • glib
So, with those requirements in mind, the vendors that provided a suitable Operating System available to me narrowed considerably:
  • SuSE
  • RedHat
But, then I started reading about OpenSolaris, specifically blog entries like this one about DTrace. The more I read about DTrace and what Solaris was capable of (Zones, Self-Healing mechanisms, ZFS in the future, etc.), the more I wanted to try out Solaris. Then, last night I found this page full of all kinds of wondrous things that as a developer I all too often find the need to do. RHEL and SuSE were too expensive, and after finding all of these things it cinched the decision to seriously evalute Solaris.

So, my journey began...

I'll post about my experiences installing, plus all the various things I had to do to get my system working as a desktop soon. As well as the things I still haven't yet figured out...

Related blogs: .