Clint presenting to the Provo Linux User Group about GoOSe.

To view Clint’s posting about the “upcoming” meeting go here:

http://sexysexypenguins.com/2012/01/10/presenting-at-plug-tomorrow-goose-linux-rebuilding-enterprise-linux-the-community-way/

Updates:

2012.01.31: Added link to Clint’s post at http://sexysexypenguins.com

Unfortunately it appears more and more that I, and most of the GoOSe project people in Utah, won’t be able to attend. In scratching our heads over the process we think we have an interesting plan: We are thinking about setting up a virtual presentation.

So we have been looking around at various solutions. We haven’t presented this option to the user group yet but if this works then we might keep this method in our back pocket for future presentation. It could be a very useful thing, we might be able to repeat this for other user groups around the country or even world.

So far we have looked at Google+ hangouts. I think there might be some better solutions out there at the moment though.

To make this work the presentation tool should allow the presenters to provide visual and audio data. It should also allow for the presentation of the slides and ideally a few real life examples of doing things like submitting packages for repos and submitting packages to the GoOSe koji server(s).

The presentation solution should allow the use of Linux systems (Yeah, we all probably run Linux as our primary operating system) and work over relatively low bandwidth, since most of the time presenters may be using a congested hotel wifi service.

I find this to be an intriguing and potentially useful project.

Hopefully we will find a good solution soon!

- Mike

Useful websites:

http://gooseproject.github.com
https://fedorahosted.org/koji/
http://www.google.com/support/plus/bin/answer.py?answer=1215275 — Google+ Hangout

The GoOSe project has promised a response and it is the main topic of conversation for this evenings meeting.
Though I think they [Ascendos] may be thinking of the GoOSe project merging into Ascendos and not the other way around.

So the question becomes when do two projects that appear to be very similar merge? What criteria should be considered in the process and when do projects that are similar stand aside?

Warning: I won’t express my opinion on the proposed merger itself in this posting.

Consider the possibilities…

There once was a boy/girl/other project that seemed an awful lot like another boy/girl/other project. They seemed so similar that people sometimes confused the two. And like other couples people began to whisper about the two becoming one. Now if this was a discussion of relationships between two people everyone would agree that it gets more complicated then that. Accordingly when you talk about open and free software projects there are usually several people involved and complexity can grow.

So lets start with the basic question, why merge at all?

• Merging should create a much cooler and better project!
• Combining the the resources of both groups and at the same time removing duplicated work.
• Resources and tasks become consolidated.
• Eliminate confusion and the “What’s the difference between x, y and z?”.

When projects consider merging they should also consider some of the less pleasant things that might happen. Why shouldn’t projects in merge?

• When you merge projects some people are going to be lost. There may not be any hard feelings but the project, work flow, objectives, and people involved will shift in such a way that members may no longer want be involved. In some cases this may actually result in a new competing project being started by disaffected members.
• Loss of diversity. Competing projects help bring out the best for both projects.

So what if two projects have proposed a merger and decide against merging, what will the outcome be?

Only the shadow knows!

Things can change drastically from one project to another in the space of months, weeks or even days. It seems that a lot of projects tend to pick up a competitor and in the end only one survives. Of course to simply say that there is room for only one Linux distribution is silly. Distrowatch tracks hundreds of active distributions. Though there are only a few top projects that get most of the work. As the independent projects progress contributors will almost inevitably decide what project they want to be with. While this doesn’t necessarily doom either one of the projects it certainly can lead to a lopsided effect.

Consider the case of Ubuntu, SUSE and Red Hat. I don’t think anyone would argue that Red Hat has the largest footprint in enterprise and user base. But that doesn’t mean SUSE and Ubuntu are unused or even inconsiderable in their footprint. While Red Hat is bigger it doesn’t mean that there isn’t considerable contributions or even cooperation with the other two.

So projects can survive in a competitive situation and potentially survive very well. On the other end of the spectrum projects that get overshadowed may not have the interest or man power to continue with their project. The Open Source and Free Software landscape is littered with the decays of really cool projects that never gained enough traction to continue.

Sometimes moving forward as an independent project just means putting the merger process off for a while and merging later down the road. Sometimes it means that you try to get a merger only to find that the other party no longer has an interest in a merger but will take new contributions and contributors.

Conclusion?

I don’t have one beyond this: Merging two communities is a tricky business and has long term consequences. It is not a trivial item to undertake.

For the boy/girl/other and boy/girl/other discussed earlier, perhaps it is a good thing to just be friends for the time being. Divorces suck.

- Mike

Websites:

Andrew Cutler posting to goose-linux@googlegroups.com
http://gooseproject.org
http://ascendos.org
http://distrowatch.com

This weekend is coming up and I know that you are probably pondering the same question you did last Friday:

What to do on Saturday?!

Don’t worry, I have a solution!

This weekend there is going to be a “sprint” day for the GoOSe Project. A sprint day is a day to focus and work on a particular project in the open source and free software world.

If you would like to join us, and I would encourage you to do so, simply launch your favorite IRC client and join us on #gooseproject at irc.freenode.net.

If you want to meet up and work with people in your local area the IRC channel is a great place to ask and on the mailing list goose-linux@googlegroups.com.

The sprint will run from 10MDT to 14MDT (10AM – 2PM). However don’t let those times discourage you from joining earlier or later!

What is going to be worked on?

Anything you feel is appropriate! Joining the project, working on documentation, the website, building packages, working on logos/graphics, and coding tools!

So come on out and join us for Saturday.

- Mike

PS

And if your in the SLC area feel free to join Herlo, Nafai and I at a local coffee shop for the sprint!

Websites:

http://gooseproject.github.com

The EL words

I have been using Linux off and on for a number of years (It is actually coming close to 20!) and have seen it mature over those years. I have also used various Free and Open Source operating systems as well as proprietary systems. One of the the most remarkable things has been to see the widespread adoption of Linux in the Enterprise space.

I believe that Linux could have happily remained as a hobbyist dream and enjoyed a long life of fruitful innovation. Of course this is idle speculation that has in many ways past us by.

As companies begin to adopt products they have certain expectations for the products they employ, regardless of the associated cost. In some ways they have greater flexibility than the home hobbyist since they have coffers to reach in and pay for more stable and reliable systems. While offering money helps motivate further production and development of systems, is a great means of advancing systems and attracting developers, it doesn’t solve everything. Investment of money does tend to set higher expectations.

Some of the higher expectations that are set with adoption of a system in the enterprise are things such as:

• Reliability
• Stability
• Timely and Productive Bug Resolution
• Proactive Development
• Regular Updates

There have been a number of Linux Distributions over the years that have all strived for these goals. Some of them more productively then others.

The current crop of Enterprise level distributions are:

• Red Hat Enterprise Linux
• Oracle Enterprise Linux
• SUSE Enterprise Linux
• Ubuntu
• CentOS

I am sure there are others but those are the most common ones that I hear of working with people from enterprise environments.

Give and Ye Shall Receive

Of the previously listed distributions both Oracle Enterprise Linux and CentOS are based upon Red Hat Enterprise Linux. While they may be the most prominent they are most certainly not the only ones.

Why has one distribution become so popular and been rebuilt by so many?

We could look at the market share and assume that it is simply a matter of dominance in the market place. It might be the fruits of  long and hard efforts to promote their brand and create an effective training and certification process.

I suspect that all of these items play a varying roles in the “success” of Red Hat and the RHEL clones. I also think that one of the big differences is how readily accessible the source code is for the users. You may have noticed that there isn’t a rebuild of the SUSE system running around out there.

Red Hat is a very open company and publishes source code to a publicly available ftp site where anyone can grab the source RPM packages.

What did they ever do for you?

Red Hat is a very different company in this sense. There have been a few packages that they haven’t released the source code for, or have taken their time (i.e. RHN Satellite Server released as Spacewalk), but they don’t restrict access to updates in source code form. It is very possible for you to get the demo version of RHEL and keep it up to date by building your own updated RPMs wth the source RPMs from the ftp site.

These packages are available and people can rebuild these packages and come up with a rebuild of a RHEL system from Tip to Tail. And the world has certainly done it. The number of systems out there that do a rebuild of RHEL is pretty impressive and they keep coming.

But what does this do for Red Hat?

Its a gateway into their support and contract services. They know that once they gain a foothold into your enterprise they will have an ongoing customer. Even if their potential customer is using something other then actual RHEL they will eventually join the fold.

From the perspective of RHEL this is a good long term strategy. They are essentially giving away their product, even when it is a rebuild, that will get their foot in the door.

There may not be a need for support for your print server but there will be for your data center.

So as discussed Red Hat has good reason to let rebuilds be encouraged. There is also the fact that good rebuild projects feed back through bug reports and help improve their product.

Let the Rebuilds Begin!

Since there are good reasons for Red Hat to be accommodating of rebuilds, why not just one? Why doesn’t everyone just work on a single project?

Many of the rebuilds have focused on rebuilding for a particular reason. Each has adopted a different model for its administration. While these projects all rebuild Red Hat they can be very different under the covers.

While I have been a big supporter of CentOS in the past, recent events have brought to light the underlying administrative model of CentOS. Following these events there were questions and unhappy answers.

During this unhappy period there was a moment of reflection. A lot of users were unhappy with the delay that it took to get to CentOS 6. The reaction from the CentOS builders and their supports was along the lines of “You will get it when you get it and if you want it faster build it yourself.”.

Towards the ends of the 200+ day wait that it took to build CentOS 6 many people, including myself, began to wonder if there wasn’t a different approach that could be taken.

Enter the GoOSe

GoOSe Enterprise Linux isn’t much different from CentOS in the ultimate product. It will be a rebuild of RHEL and the updates that are released. While almost the same there are some key differences.

The community is probably one of the biggest of the differences. Where CentOS has a small group of builders (6 the last time I checked) that are responsible for building and producing the product, GoOSe is very community oriented. From day one GoOSe has worked to build a meritocracy amongst its users.

GoOSe is meant to be built by the community for the community.

For those that want to be involved in building packages for release there is a path established and helping hands to guide users from an initial contributor to being one of the system builders. As the number of builders grow there is going to be a reduced lag in build time. It also “debusifies” the project.

Debusification is the process of removing reliance on a single or small group of individuals.

Another big difference is that GoOSe wants to be reproducible. You should be able to take the tools and the knowledge provided and rebuild GoOSe or even RHEL, using the provided tools. There is no interest in hiding the build process. Even the build tools that have been created for the project are available for updates and modification.

While GoOSe is still in the early stages it has some great potential.

- Mike

Websites:

http://planet.gooseproject.org

http://www.gooseproject.org

http://github.com/gooseproject

http://www.schwarz.eu/oss/wiki/2011/07/the-downfall-of-centos

http://lists.centos.org/pipermail/centos-devel/2011-March/007101.html

Notice:

2011.09.29.13:09MDT: Minor grammatical corrections and rephrasing.

I always seem to keep busy, yes I know it never seems that way but I in fact keep pretty busy. Currently some of the things that keep me busy at home are:

1. Dog
   • Not only can the dog be a hoot, but a pest too! Of course it is a good thing when he comes and forcefully reminds me that he needs to go out. Forcefully reminding me to take a break can be good. Not sold on dragging me out for a milk bone though…
2. GoOSe Linux
   • GoOSe Linux is a project to rebuild a “major upstream” provider that is going fairly well. The process has been on going since May or June of this year and we have been making some good progress.
3. IPv6
   • IPv4 is gone… sort of… Any ways it is clearly going to be the wave of the future to use IPv6, not like BetaMax was the wave of the home video future either! I am at the point of actually working on rolling it out at home. Why? Fun and profit man! When clients go “Oh and can you talk about transitioning from IPv4 to IPv6?”, there is at least some demand. I suspect it is going to only increase. Transitions are only beginning.
4. Studying
   • Trying to learn more and more and more and more… Oh and more and more and more…

- Mike

Websites:

IPv6 Site: http://ipv6.com/
Hurricane Electric, IPv6 Tunnel Broker: http://www.he.net

The GoOSe Linux project: http://www.gooseproject.org

The Utah Humane Society: http://www.utahhumane.org/
Salt Lake County Animal Shelter: http://animalservices.slco.org/
Murray City Animal Shelter: http://www.petfinder.com/shelters/UT52.html
No More Homeless Pets: http://www.utahpets.org/nmhcms/