The hope was to make a Golden GoOSe available for Christmas, but it didn’t work. Oh well, here’s another release candidate!

GoOSe Linux 6.0 Beta Release Candidate 5 (RC5) is now available for testing. Visit http://get.gooseproject.org/ to obtain the download.

Once you arrive at the above link, the downloads are under /releases/6.0/Beta-RC5/GoOSe/<arch>/.

The GoOSe Project is always interested in feedback around its project. Please feel free to drop us a line about this release.

Comments/Questions:

• Send us an email goose-linux@googlegroups.com
• Contact us on irc.freenode.net at #gooseproject
• Leave a comment on this blog post

Issues with GoOSe 6.0

If you find yourself having trouble installing, using or managing GoOSe Linux, please let us know. The best way is to file issues at our main project site on github, but we’re happy to have the information in any of the ways listed above.

Testing can be done by anyone. Please feel free to check our new testing wiki page for information on what tests need to be run and which have already passed. If you have interest in helping us test, thank you, thank you, thank you for the help!

GoOSe Beta-RC5 will be available for 1 week from today. At such time the GoOSe team will decide whether it will be the first Golden GoOSe release. This will be based upon feedback provided, so please do tell us what you think!

Cheers,

herlo

GoOSe Linux 6.0 Beta Release Candidate 4 (RC4) is now available for testing. Visit http://get.gooseproject.org/ to obtain the download.

Once you arrive at the above link, the downloads are under /releases/6.0/Beta-RC4/GoOSe/<arch>/.

The GoOSe Project is always interested in feedback around its project. Please feel free to drop us a line about this release.

Comments/Questions:

• Send us an email goose-linux@googlegroups.com
• Contact us on irc.freenode.net at #gooseproject
• Leave a comment on this blog post

Issues with GoOSe 6.0

If you find yourself having trouble installing, using or managing GoOSe Linux, please let us know. The best way is to file issues at our main project site on github, but we’re happy to have the information in any of the ways listed above.

GoOSe Beta-RC4 will be available for 2 weeks from today. At such time the GoOSe team will decide whether it will be the first Golden GoOSe release. This will be based upon feedback provided, so please do tell us what you think!

Cheers,

herlo

GoOSe Linux 6 Beta Release Candidate 3 (RC3) is now available for testing. Visit http://get.gooseproject.org/ to obtain the download. Please see the following pages for download links and testing instructions.

Note: The links below are provided by the Fedora Project as a useful pointer to tests the GoOSe Project should be be performing. Please do not modify content on the links below, they are only for reference. It is expected that the GoOSe Project will build its own tests based upon the great tests provided below.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Ideally, all Alpha, Beta, and Final priority test cases for
Installation [1], and Base [2] should pass in order to meet the Final Release Criteria [3]. Help is available on #gooseproject on irc.freenode.net.

[1] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[2] https://fedoraproject.org/wiki/QA:Base_validation_testing
[3] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria

The GoOSe Project thanks the Fedora Project for providing such good testing information and allowing us to ‘stand upon shoulders of giants’ as we grow and learn.

Goose Project

Earlier this year I was at South East Linux Fest in Charlotte NC, and listened to a talk by Clint Savage (Herlo) about a new Enterprise Linux rebuild project that he was working on. The goal of the project was to make a community based enterprise rebuild that operates very similar to Fedora. I was intrigued, like most people the giant gap between RHEL 6 and CentOS 6 was frustrating to me; the idea of a community run enterprise distro sounded great.

The question was how can I help? The answer was “What are you good at?” Since GoOSe is just getting off the ground they need help all over. Naturally I started working on documentation stuff, but because its a small community the team needed someone with PostgreSQL experience so I started helping with that as well.

What I am doing is not the point of this post. The point I am trying to make is that in a large community like Fedora, it can be hard to find a task that interests you, someone is already packaging your favorite stuff, or people are working on infrastructure you know and it can be intimidating to try and jump in.

GoOSe is a new project and there is plenty of stuff for people to work on. It is also a small group of people working on it at them moment which makes it that much easier to get acquainted and feel comfortable working with the group.

If this sounds interesting to you, or you want to hear more jump in #gooseproject on freenode, or visit the website. You can also see source code on github

Recently, I have given a response similar to this at least a half-dozen times and thought it could be useful here.  I work with many github repositories and manage them each and every day.  Below is the workflow I use to make things simple, easy and efficient.

First off, whoever you are pulling from is the ‘upstream’ repo. My example uses the the saltstack repository (git://github.com/saltstack/salt.git). Make sure it’s set to the read only git url so as to not accidentally push to upstream directly. To set this, you can do the following operation in your repository:

git remote add upstream git://github.com/saltstack/salt.git

Next, adjust the origin repository to point to your fork of the saltstack repository. In my case, my username is ‘herlo’ so my ssh-based read-write git url would be ‘git@github.com:herlo/salt.git’. To adjust the values, do the following:

git remote set-url origin git@github.com:herlo/salt.git

It’s possible that ‘origin’ isn’t set, but if you cloned originally from the saltstack repo, it will need to be adjusted.

Finally, it’s good to verify this, run ‘git config –list’ and look for lines similar to what I show below. If you have yours configured this way, you are ready to work with the github pull request structure simply and efficiently.

git config --list
..snip..
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.url=git@github.com:herlo/salt.git
branch.master.remote=origin
branch.master.merge=refs/heads/master
remote.upstream.url=git://github.com/saltstack/salt.git
remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/*

Last step, and this is more of a workflow piece than anything. Simply perform tasks in this fashion and you’ll be able to handle most anything with github’s pull requests.

1. git pull upstream master/develop -  (the develop branch is likely the one you want)
2. do some work, make commits to your changes, etc.
3. git push origin master
4. submit a pull request at your fork – (for example, https://github.com/herlo/salt/pull/new/master)
5. once your merged changes are accepted, go back to step one – rinse and repeat.

I hope this helps clarify how the workflow in github could work. It’s simple, easy and effective.

Please let me know of any tweaks as you go through this process. I’d like to hear of any way to improve my process as well.

Cheers,

herlo

Having fun learning Flask, a web framework for Python.

Currently working on a new mock-up of the Goose Linux Project website in flask.  It’s coming along nicely however my CSS-Fu is not strong

Alright folks, it’s been decided, determined and is about to be announced! Um, yeah, that’s right everyone, the ‘Quest for the Golden GoOSe’ Sprint is on!

When is this happening you ask? Well it’s very simple and very soon, in fact it’s happening July 27-28, 2012. Yes, that’s Tomorrow and Saturday. It’s a bit unexpected for some of you, to be sure, but if you can make it, we’d love to have you for any time possible. If you can’t make it, take some time this next week and work on the GoOSe. The goal is to get the Golden GoOSe 6.0 release out by the end of August, so we really need to start cranking!

What’s left, you ask? Quite a bit actually, but the biggest piece still remaining is our Quality Assurance testing and reporting components. We’re working on them in our qa repository on github, and you can most definitely fork it and get an idea of what we’re doing. We need some serious help with ABI compliance, validation of RPMS and overall validation that all packages have been built.

Wait! There’s more! We also need help with documentation, code and usability testing of the isos. The documentation is all based upon our
‘How to Cook a Goose’ wiki page on github, the skein code needs to be
updated to the new github v3 api and the Isos can be downloaded and
tested.

Some of this is more self-explanatory and some is just plain confusing. This is where we need your help! If you have ever wanted to define how things work, you can jump in now and help us identify things and help us solve problems. That’s the fun part about free and open source software! A good for instance, what is the usability testing requirements for our Isos? Well at the moment, we don’t really have a good handle on this, but you could step in and define some requirements. If you would prefer to help write code, you could clean up things that might look a bit messy. There’s plenty to do!

Please come and help us out this weekend or anytime next week! We’ll be in #gooseproject on irc.freenode.net, or you can work by email, github or ESP. We’re excited to be moving forward and look for your help making the the ‘Quest for the Golden GoOSe’ 6.0 release a reality!

Cheers,

Clint

I am excited to be speaking at the SouthEast LinuxFest tomorrow!! The presentation about one of my latest projects, GoOSe Linux – Rebuilding Enterprise Linux the ‘Community’ Way. The presentation will take place at 1:30pm on Friday, June 8. If you ever were curious how Enterprise Linux is built in an open and transparent way, come by and listen. It will be entertaining and enlightening.

The Fedora project will be putting on a Beefy Miracle lunch across the street from SELF on Saturday (I think it’s at noon) so come by and get a Beefy Miracle in honor of Fedora 17.

Also, stop by the Fedora booth sometime during the weekend with your canned goods we’ll be collecting this weekend for the Loaves and Fishes food pantry in Charlotte, NC. Their priority list includes canned meats, canned pasta (such as spaghetti’os, ravioli, etc.), cereal, canned fruit, and 100% fruit juice. Nothing in glass, please!

Plus, you’ll get a little surprise in return. I won’t give it away, but as you might have guessed it’s something that is definitely beefy. Hope to see you there!

There are quite a few other goodies on the schedule, so please feel free to peruse. It should be a great weekend!

Cheers,

herlo

The GoOSe team has been working very hard to get a 6.0 gold release out the door, we are very close.

Just released today is the second Release Candidate (Beta-RC2) for GoOSe 6.0 – You can find it here. In addition to the DVD, netinstall and CD installation images, you will now find a Live Desktop ISO.

Please help us by downloading and using the ISO images. File any bugs you find. It’s incredibly easy to become a contributor!! (If you are not a contributor yet, please email bugs to the goose-linux mailing list.)

Cheers,

herlo

Well, it looks like I’ve been roped into presenting at the Utah Open Source Conference (UTOSC) 2012 again! :) I’ll be presenting three times, in fact.

The first will be on my latest project, GoOSe Linux – Rebuilding Enterprise Linux the ‘Community’ Way at 11:15am on Thursday, May 3.. If you ever wondered why CentOS took so long to rebuild Enterprise Linux, wondered what other options are out there, or even were just curious how Linux is built, come by and listen. It will be entertaining and enlightening.

The second talk will be Koji – A Reliable, Repeatable Build Environment, 4pm on Thursday, May 3. If you aren’t aware of what Koji does, it builds and manages RPMs. While we use it for the GoOSe project, many folks need a simple and clean way to build packages in a repeatable and reliable way.  Koji can also build LiveCD/LiveDVD images, manages repositories, tags builds and much, much more.

The last presentation I will be giving is ‘The State of Open Source‘, it’s a keynote presentation at 1:30pm on Friday, May 4. Expect this talk to be light and fun! I hope everyone comes out and enjoys this talk as well.

Additionally, it looks like Victor and the gang have created badges for you to put on your blog, Facebook, Google+, etc. so get them out there and come hang out at UTOSC 2012!

Cheers,

herlo

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

Well, this has been a long time coming. It’s taken over 6 months of hard work by our community. Tomorrow night, January 11, 2012, I will stand in front of the Provo Linux User Group (PLUG) and talk about what we have been working toward.

GoOSe Linux – Rebuilding Enterprise Linux the Community Way

Yes, GoOSe Linux is almost here and we’re ready to discuss the process and the goals of our little community. If you have been hearing me rant about GoOSe on the Utah Open Source Planet, Google Plus or Facebook and want to hear more. Or if you are just plain bored tomorrow night with nothing better to do, come down to the Provo Linux User Group. Learn more about how the Enterprise Linux Rebuild community is working together to make a better ecosystem.

If you can’t make it, or want to preview the slides, you can get them on my speakerdeck.com page. I look forward to seeing you all there.

Date: January 11th, 2012
Time: 7:30 PM
Location: C7 Data Centers (Lindon)

For more information, check out the PLUG announcement.

Cheers,

herlo

The original post is in the GoOSe mailing list. I am reprinting here for a wider audience.

As of this morning, it appears we only have around 40 failed builds! We’re getting very close! I think we could make an alpha by the end of next week with a good bit of sprinting! As I understand it, one is planned for next week, maybe we should sit down and figure out those details?

Cheers,

Clint

This document is a copy. You can always find the canonical copy here.

The GoOSe Project is only one of the upstream enterprise Linux rebuild projects. We are excited to work together with others in the EL rebuild space, and feel that there is plenty of room for separate but collaborative communities. The similarities in our goals should work for our mutual benefit. And the differences which exist should only strengthen us all.

So we need to answer this question:

In what can we collaborate?

What follows are the results of a pretty free-form brainstorming session we had at one of the GoOSe Project's weekly meetings.

• Shared infrastructure

  Sharing certain pieces of infrastructure makes a lot of sense.

  • Upstream Sources Mirroring -- Although there are various places that one can find the upstream sources having another collaborative mirror for the various rebuild projects could be beneficial.
  • Cross Project Backups -- Doing backups is difficult, if we spread out the load of backing up our repositories, scripts, look aside caches, configuration files we could restore in the case of a catastrophic failure
  • Project Mirroring -- Distributing the final product of our efforts can be daunting as well. Again, being willing to mirror the ISOs or packages of the other projects will help make all the products better accessible.
  • Help Building and Configuring Non-Shared Infrastructure -- Most of these projects are using the same or similar tools, Koji for example. Working together on setting up these systems will help reduce the amount of constitutional knowledge(better phrase here?)

• QA help

  • Building QA Test Suites -- Due to the common ancestor of these projects, a common set of test cases could be useful. This should be extensible/fork able for the test cases which would be specific to a certain project.
  • Cross-QA Checks -- A very good way of testing if something is correct is having someone else run the same test as you. Sharing the QA work and results would reduce the need for everyone to figure things like this out for themselves. I think the best example of this would be the information needed to verify ABI compatibility.

• Documentation

  Of the many places where EL rebuild projects can easily collaborate, the best return of investment is sure to come from the documentation side. Again the common ancestor of these distribution works in our favor. There is a great need for documentation and how-to's. Sadly most good documentation is out of date. Thus a collaborative documentation effort would help lighten the load and keep things better up to date.

  Other documentation-like ideas include common wikis, a common askbot-style system, etc.

• Distribution Creation Information

  The main product of all these different projects is a Linux distribution. Sharing the problems and various solutions to compile and create this product helps to make the entire community better. Things to share include:

  • package build order
  • package meta data
  • package content signatures
  • ABI compliance information
  • upstream trademark issues/problems
  • missing build dependencies

• Community Enhancements

  As the number one goal of the GoOSe project is to build the community, we spend a lot of time thinking about the ways to enhance the ENTIRE community ecosystem. We plan on sharing what we learn for best practices for:

  • community management
  • meetings
  • organizational structure
  • updates to your community about your progress

  We also plan on working on spreading the word about our community goals. Some tools to help us accomplish this include:

  • EL Rebuild Planet -- Would others be interested in joining this?
  • Social Networking -- Twitter, Identica, Facebook, etc.

  We also want to practice what we preach about making this truly a community based idea. Please fork and update this document to help improve it.

With a stronger community around our projects we can all have a better time accomplishing our goals. And hopefully making the world a little bit better than we found it :).

Well, it looks like we’re just about finished with Pass #1 to build all of the imported SRPMs we can from upstream. The GoOSe Project results are looking good.

Build statistics from 2011-11-01 through 2011-12-09

Completed Builds: 658
Failed Builds: 296

It appears that a bit more than 1/3 of the builds failed and notifications are going out to the package owners. This means we can work through each of them and resubmit them. Odds are that most of them are due to dependency issues and only a few for other reasons.

We’re preparing for Pass #2 this weekend. We’ve discovered some interesting things, however, so here’s something we’ll be putting in place first (hopefully):

A repository to track BANNED and EXCLUDED (for now, other names may arise) SRPMs.

At the moment, there are SRPMs we cannot build because we don’t support an architecture (s390, for example) There is no reason to build packages that won’t work. There are also some packages that contain proprietary content we need to scrub, even though the license states they are free software. These packages will have to wait unless they affect a critical path of getting GoOSe 6.0 composed in coming weeks.

The plan here is to create a repository to track these banned / excluded SRPMs. Skein will query this git repository for the BANNED and EXCLUDED files to make sure any request, grant, or build actions first check to make sure the package is not in either list. If the package is in the list, skein will refuse to act upon the package and the requester will have to resolve the issue before attempting again.

Watch for the updated skein v2.1 with this fix in place in the very near future.

Cheers,

Herlo

The GoOSe Project has been very busy over the past two weeks. This evening, after dinner, I will be releasing skein 2.0. It’s major functionality will be documented and placed in the RELEASE.rst file on github. Essentially, the request, query, grant, import and build functionality is what makes this 2.0 and ready to use.

The best part about this tool is, while I have been working on it, almost all of the remaining SRPMS have been imported and the majority of them have been built on our koji server. Right now, we’re on the last batch and I expect it to finish sometime late Friday or early Saturday (12/10/2011). This ends our first major hurdle to getting an Alpha release of GoOSe Linux 6.0 out the door.

Another huge tool in this process is Grapple, written by python master Nafai, (aka Travis Hartwell). He spent a good bit of time getting this github hook in place that will record all git commits and help to process them automatically. I spent a bit of time and added a client script to grab the recorded commits and send them on to koji automatically with the proper dist value and url. No more guessing! This is the ‘automagic’ corollary to skein build.

Next up, I plan to rebuild the failed builds and push them through koji again, using skein build. Possibly doing this a few more times until we get things pared down to the packages that don’t just have dependency problems. I hope to have most of those fixed up and in place by Monday or Tuesday next week (12/12/2011).I’ve also noticed a few builds that will never build for our arches, so I will have to figure out what to do with them for now.  I don’t want to waste koji resources trying to rebuild them when I know they will never work.

The first Alpha ISO is getting close enough to taste it now! We’ll have to make sure to have a grand celebration upon our first Golden GoOSe Release :)

Cheers,

Herlo

 

Not to long ago I was contacted by a “local” Linux User Group, specifically the Provo Linux User Group (PLUG), to put together a presentation on the GoOSe project.

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

If you have ever wanted to help build your own Linux enterprise rebuild, come join the GoOSe Project and get involved!

Today and tomorrow we’re sprinting. We also have a sprint scheduled for next week!

Why you ask? Well, I finally have had enough time to finish coding skein and it’s ready for release to 2.0. There are most definitely some bugs and other things that need to be completed (read: documentation), but it’s functional and is ready to get us to the end of our first rebuild phase.

We have a ways to go, and a goal of EOY 2011 for our first Alpha!

Come join us at #gooseproject on irc.freenode.net and get started today! More information is available at http://gooseproject.org

Cheers,

Herlo

As some of you may already know, I’ve been a part of this enterprise rebuild project for a while now and things have been going pretty well.

As I have been working on getting the import functionality into skein pre2.0, there are a few features that have come to mind as I go along. It’s very interesting to see these features appear once the tool is out in the wild. Some of them have come from other users/contributors and some from my brain, but here’s a dump of what I have been considering adding to skein:

• skein revoke – (this one is from imak, and quite a good idea) It’s possible to accidentally request a repo that you didn’t mean to request. skein revoke will allow you to specify that you erred and will allow you to close the request with a nice message you provide.
• skein request from an SRPM – the above request brought forth something I’d been thinking about doing, but hadn’t really formalized. I suspect this feature will be a good bit of our automation in our second push to finish GoOSe 6.0 by year’s end.
• skein update – providing this feature will probably happen after 2.0. The plan would be to allow an already existing repo to be updated to a new release or version of an SRPM. In addition, it’s possible the update will be to a new branch, which update should be able to handle.

As for the rest of the features, the code for export was just finished today. I expect to be able to finish push, upload and import by the end of this coming week. Then it will be on to importing the rest of the upstream tree and building GoOSe 6.0

Cheers,

Herlo

As some of you may already know, I’ve been a part of this enterprise rebuild project for a while now and things have been going pretty well. Recently, though, I’ve made some good progress on our import and build tool, skein.

Skein’s goal is provide easy functionality for rebuilding SRPMS from upstream and import them into github, where they can be built using our koji instance. The process is actually easier than one might think:

• skein request – Request a particular repository be setup on our github organization for the specified package. The package itself should be able to be requested from the SRPM, but that feature is not yet available.
• skein query – To verify the request has been placed, this shows the open queries (by default).
• skein show – For a particular request, show the detail of who requested and the purpose of such a request.
• skein grant – Only an admin can grant the repository. Only members of the admin team on our github organization can grant the repository.
• skein extract – Once granted, the SRPM can be extracted and placed into two basic directories:
• /path/to/package/lookaside/ – contains the archive from the SRPM, usually a tar, tar.gz or zip file. The contents of this directory can then be pushed to the lookaside cache.
• /path/to/package/git/ – contains the spec file, any patches and other sources that are not archives. A Makefile and sources file are also generated along with a .gitignore to provide useful functionality during the koji build

Other functionality is currently under development:

• skein push – Once extracted and committed to the git repository, this pushes the git commits to github.
• skein upload – Once extracted, this uploads the content of the lookaside directory to the lookaside cache at pkgs.gooselinux.org.
• skein import – A combination of skein extract, push and upload, since that seems fairly logical.
• skein build – Albeit mostly complete, it will need to be tested with an SRPM that has been run through this process.

I took a few minutes the other day and created a video of the completed process. I post this here for others to use for their benefit, but also so I can have it in another place besides my laptop.

Skein video

Cheers,

Herlo

Recently the Ascendos reached out to the GoOSe project. It started with a very polite email to the GoOSe mailing list from Andrew Cutler. Shortly afterwards, over the course of a couple weeks, a few people stopped in to #gooseproject and expressed interest in possibly merging the two projects.

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

We’re starting to really ramp up on the GoOSe Project. If you haven’t heard about this project, check out my previous posts.

Well, I have been meaning to write this post every day this week, only to be bombarded with work or other projects getting in the way. However, I am currently sitting at the Beans & Brews at 45 East 11400 South in Sandy, Utah participating in the very first GoOSe Sprint.

My goal today is very simple, get skein 2.0 out the door for testing. Most of contributors will be using skein to build the upstream packages necessary to make the distribution work, so I need to finish this work.

There are other tasks being performed today, including documentation, package building, automating tasks and finishing up the new website.

If you have any interest in seeing how an enterprise quality distribution can be rebuilt using free software, we’d love to have you stop by #gooseproject on irc.freenode.net. The GoOSe mailing list is another great place to read about what we’re doing.

Or if you like physical space, come on by the Beans & Brews today from 10am until 2pm. There should be at least a few of us working on something all day long. Just look for the nerds in the corner getting all excited while discussing phrases like ‘build process’ and ‘skein grant’ :P

Update: We’re going to be moving down to the Beans and Brews at 155 East 13800 South at approximately 12:45pm

Cheers,

Herlo

Hi all!

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

I believe it has come time to lay out some thoughts on the different EL(Enterprise Linux) distros and the communities that surround them.

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.

Many of you may have already heard from my good friend Derek Carter about the GoOSe Project. If you haven’t, I’d love to hear your comments on what we are doing. I’d also encourage many of you to come and join the project and help us to build a community of contributors dedicated to making the best enterprise Linux rebuild available.

Recently, Jonathan Nadaeu and I sat down and discussed Fedora, GoOSe and a few other fun things on This Week in Fedora. The majority of the interview was about the GoOSe project and it covers a good bit of why we’re doing what we’re doing, how it works and how to get involved. Have a listen, and come hang out and help out the project!

In addition, I was asked to do a presentation this week on how to build RPMs at the Ogden Area Linux User Group (OALUG). While I teach this in my day job as a Red Hat Trainer, I’ve never given my own presentation. I’m really excited to share some very useful tips and tricks on how to build an RPMs and set them up in a custom repository for your company or for others to consume. It’s very cool and very easy to do most of this work.

So come on up to OALUG tomorrow night if you can.  I’ll make sure to follow-up here with the useful links for those interested.

Cheers,

Herlo

Introducing the GoOSe Project

Recently I blogged about how some friends and I were talking about what it would take to rebuild an enterprise Linux project. We started researching what we would need and we got started. The result? The GoOSe Project.

What is the GoOSe project? It is a community rebuild of an enterprise Linux distribution based in the USA. But it is also more than that. The GoOSe project is more importantly a practice in building an Open Source community. We wanted to practice what we preach about how best to build a community. It just so happens that the product that this practice produces is a Linux distro.

Why "GoOSe"?

The name of the project was just a bit of riffing done on IRC(look around 20:03.38). We have quite a bit done as far as getting things rebuilt and have some ideas as to how we want to run this community. We have an ethos. A Koji instance running our builds. And we are just about done with the Buildroot needed to make a fully functional system bootstrap.

The GoOSe project is "in progress" to getting the first build out. We are currently just about done with the first step which is to compile all the upstream packages into a buildroot we can use to compile our packages. A more detailed status update will be blogged about later.

Why another rebuild project?

As I mentioned above, community is the hard part. And although there are various other projects similar to ours, we think we can fill a certain niche.

The centOS project for example is probably the biggest rebuild project out there and it caters to those who are looking for a 100% drop-in replacement for the upstream Linux distribution. Scientific Linux is built as a base for supporting computing clusters and experiments.

The GoOSe project is not out to replace or out-do any of these projects. We are here to build a community of passionate folks to build the best community-based enterprise operating system around. We will be sharing everything that we learn, everything we modify, and everything we build to help use create this distribution. We all benefit from an improved community structure. We also benefit from having more than one project meeting different goals/niches. The things we learn also help all the other projects out there to have a well functioning system themselves.

GoOSe Goals

Our goal with building the GoOSe project is to have a cool community built around an easily constructed set of enterprise-grade software. The technical pieces of the equation taking the hard part out of building an enterprise operating system. Herlo said it best when he said this with regard to the vision of the project:

"[I see the GoOSe project as a] group of friends hanging out, building cool things with an enterprise-ready technology. Not exclusive to building the technology itself."

Come help us

We're already working away on these goals. You can come and help us. Here are some resources to get you started:

• The project's development mailing list (currently the only list until we need more).

• The project's irc channel

• The project's main web site (currently being worked on)

• The project's main github page.

• The project's main wiki

• A link to "how you can help".

• The project's blog planet.

There is still plenty to be done. Come join us. It'll be fun I promise.

Over the past few months, I’ve been working on a project which has inspired me to think about how a complete Operating System is built from the ground up. Luckily for me, this process is pretty well documented by the Fedora Project.

The project I’ve been working on does require a bit of thought around enterprise Linux versions run by a community. There is the ever amazing CentOS, Scientific Linux and a few others who have been around the block a time or two. The work that they have done has been immense and very helpful to many, including me.

For my project, the work was about building a fully binary compatible, enterprise-ready, community version of Linux, very similar to what CentOS and others have done. The question always comes ‘why?’ which will be addressed later on in future posts. Suffice it to say, the work we’ve been doing has paid off in both a individual and community sense.

In the beginning of this project, it was clear that we needed some tools to make things work the way we wanted. Luckily, there were tools out there to do a good portion of our work. Tools like koji, mock and of course Linux to bring it all together. But other tools seemed to be missing and I went on a quest…

The first tool that seemed to be missing was a way to import src.rpms from the most popular upstream vendor. These packages needed to be rebuilt by koji in some fashion, but just taking the srpms and rebuilding them had been done before, and seems to be the preferred way to date. In my mind however, it seemed that we were missing a step. Enter skein.

While skein is still very green and will need quite a bit more work, it accomplishes the goal of extracting the srpms into two parts. This tool basically sets up two things; a git repository on github.com (for now) along with a location and verifiable way to store the archive stored inside the srpm, called a lookaside cache. If one looks at the way the Fedora Project maintains their source, this process is very similar.

Once the srpm is imported with skein, it can be built with koji. At the moment, this process is fairly manual, but the plan is to improve skein to also allow building from the repositories. However, another bit more automatic way to build would be to use a git hook. Luckily, github provides several ways to accomplish this, including a custom URL to which an HTTP POST can be sent. At which time, koji would download the spec file and source from the appropriate locations and build a srpm.

Koji completes its task by building the binary RPM(s) and appropriately tagging the successful builds. Once complete, mash can be used to generate custom repositories to prepare for composing actual iso images. Mash is a command-line tool, again used by Fedora.

Once the repositories are generated by mash, pungi takes over. The process of building an iso is actually very simple, just a kickstart file, some repositories and pungi are used to create a fully installable DVD or multi-CD iso image.

Here’s a bit of my excellent artwork to better describe the process.

A couple things to note about this process is that while it is starting to become clear how to build an OS from an upstream vendor, there are parts that still haven’t been addressed. Currently, we can import with skein and rebuild the SRPM and build the binary RPMs with koji. We yet to have enough binary RPMs to actually construct a buildroot, but we are getting very close.

Automating the builds with git hooks and a skein build process is a nice big step toward making our own Operating System possible.

The other big piece of the puzzle is dependency resolution. Now this has been mostly resolved by tools and apis like Yum and RPM, but I still feel very much like a n00b when working with them. My hope is to figure out that process in the next week or so, and update skein to make building faster and easier overall.

Cheers,

herlo

Last week I got an email out of the blue.

While trying to organize a complete mess of an nagios install (half borked
by a nagiosql install) I ran across a post where you offered up an example
of your nagios configs. The link is now password protected, I know the
post is over 2 years old and things change....but I was wondering if you
still had that info available?

I did poke around your github but didn't find any nagios info.

Thanks!

This email was in reference to a comment I made to this blog post by the Standalone Sysadmin.

After working for a few months on this project, we are ready to begin the flood of public announcements. Over the course of the next few weeks, I'll be posting information on the build process. We are using koji for our build infrastructure, which has actually been fairly beneficial for the professional work I've been doing lately. It turns out that plenty of organizations build and manage their own software in rpm form and need it to integrate with EL or other rpm-based linux distro's. So far, koji is the best system for making these custom packages work well with EL, in my opinion. And now, back to building more pkgs.

In a recent blogpost I discussed what would be needed to start a rebuild project based on sources provided by a prominent Linux distribution.

Some friends and I started working towards this goal. We quickly determined that as interesting and difficult the technical problems and hardware needs for such a venture are, they are surprisingly the easy part. Much more difficult is the task of building a community.

Community is Key

The key to any vibrant Open Source project is the community behind the project. Without a living, breathing community, any project is doomed to end up dead.

Analyzing other Open Source projects out there I discovered there are two distinct communities involved with any “successful” project. The contributor community and the user community. And yes one is a sub-set of the other (or ideally would be). These two communities are symbiotic as well.

Contributor Community

The contributor community is the core of a project. It consists of volunteers working on task relating to the creation, improvement, and release of a project. Without the contributor community the project could not exist. This isn’t to say the contributor community works in a vacuum. The contributor community relies on the user community for a few things:

• First and foremost: Validation. Working on an Open Source project is a labor of love. Volunteers give a great deal of their time, talent, and work to an Open Source project. A vibrant user community validates the work of the contributors.

• Second: User base. A project without users is a business without customers. No users; no project. The more users a project has the more willing contributors will be to work on the project.

• Third: Feedback. There’s an old maxim: “Many hands make light work.” The Open Source equivalent to this is “Under many eyes, all bugs are shallow”. The larger the install base, the more likely quality bug reports will be generated and problems will be found and fixed.

User Community

The other half of the project exists in the user community. The user community consists of those who download, install and use the project in their daily work. The user community depends on the contributor community for few things as well.

• Number one: A Quality Product. People are using large Open Source projects in the core infrastructure of their businesses. A quality product makes this possible.

• Second: Transparency. Given the importance of a quality product. Users are eager for updates. These can be either security updates, new features, new releases, or just “we’re working on these problems”. When you develop your project “in the dark” users will start to get leery. If you miss big releases regularly they start to loose confidence. Fear of a dying project can lead users to find alternatives or to fork the project themselves.

• Finally: Permanence. The user community depends on the contributor community for permanence. Open Source projects are living things and require constant care and feeding. They have their own life cycle. Open Source projects are created by volunteer forces. Those volunteers’ priorities change, they move on — for whatever reason. A completely open development model helps overcome these speed bumps that can affect a project. Some recent events come to mind with regard to the movement of a community:

  • OpenSolaris/Solaris to OpenIndinana/Nexenta

  • OpenOffice.org to LibreOffice to Apache open office.

Another item to think about is reducing the “bus factor”. The access to the entire project should not be limited to one member or small group of members of the contributor community. It should be available to all of the core trusted team. See CentOS Project Administrator Goes Missing.

The ultimate answer to all of these concerns is to make the entire project VERY easy to fork. Using new distributed SCM tools makes this pretty easy. The ideal Open Source project should be able to be completely forked in a weekend at the longest.

Community Trust

When the user community and contributor community trust each other, things really start to happen. More contributors show up to help as they feel valued and want to participate. The stronger contributor community means a higher quality, better trusted project. The higher quality project then attracts more users and the feedback cycle grows. The output of this feedback cycle is better support, and a better product.

Attracting Contributors

After defining what the communities are and what they want, let’s talk about how to attract more people to both. To attract people to the contributor community you have to have a very low barrier of entry for contributions. I’ve found one of the easiest ways to do this is with a tool which allows for easy contributions. One such tool is GitHub. The manner in which you contribute to a project on GitHub is easy:

1. Fork the repository

2. Make changes in your fork, and push the changes back to GitHub.

3. Send a pull-request.

4. The upstream project will accept or reject your change set.

This low barrier of entry for a contributor also works as a great apprentice method. As people show their competency through things like these pull requests, they can easily be apprenticed into the core group of contributors. This makes your project a true meritocracy. This apprentice system balances access with trust, and gives a clearly defined path from user to contributor.

In order for this apprentice system to work you need to have a list of todo items. Ideally this list would be full of low-hanging fruit for apprentice contributors. Things such as improving documentation, or adding an additional feature or simple bugfixes are good examples.

Advertising the hard problems your contributors are working on in a todo list or using blogging/social media give a potential contributor a good idea of what is in store with the core team. The fun part of being a contributor is to work out how to solve the difficult problems.

Attracting Users

The easiest way to attract users is to have a high quality product. Another important tool for attracting users is a vibrant, open collaborator community.

Regular releases are key. Users (rightly) see regular, on schedule releases as a sign of a healthy, mature project. Usually the first signs of a dying or dead project are the lack of regular updates, or delayed updates with no explanation.

Users expect communication from the contributor community. This communication is multi-pronged. Good bug reports are a key form of communication. Bugs should be “scrubbed” regularly looking for bugs which are show-stoppers and when a bug is fixed the “fix” and when it will be packaged should accompany every bug closing.

Other communication channels include the project’s documentation. Documentation is something which can lag behind very easily. Ideally the documentation for a project is auto-generated directly from the source code. If auto-generated documentation isn’t easy to do, then a documentation team should be part of the contributor group.

The project should also have a blog. This blog should entail interesting problems being faced, the current status, highlights of people who are working with/on the project. There should also be a planet for all the people who have an interest in your project to share their entries. To drum up traffic, the main blog could feature something from the user’s planet regularly.

Social media is another avenue for attracting users. Getting the news out on new releases, or other news items is easily done using the various social media sites.

Holding your meetings in a public place is another way of being transparent to your user community. Ideally these meetings would be in a medium such as IRC so there is automatically a transcript or log of the meeting minutes.

There should also be a status page where users can quickly get an idea where the project is with regards to its goals. Things to include here would be tasks needed to finish the next release, show stopper bugs/issues, automatic updates from the various tools used in the project, and any other information like that.

In Closing

A community is key to making an open source project work. Cultivating community should be the first priority of a project. A well groomed community spirit, will do more for a project than any technological advances or fancy tools any day. Remember the folks who would work on something need motivation. I for one would do it again for free.

Stay tuned for step 1 and finally an official announcement of what this lead up is about.

There was some interesting action on the CentOS mailing list recently which stemmed from a tweet posted by Dag Wieers.

The question posited is: "How does one rebuild RHEL in a timely, open and collaborative way?"

Well, a few of my UTOSC friends and I did a little brainstorming and came up with what we think a good bootstrapping infrastructure for just such a project would entail:

A good model

A good example of how to run a distro is Fedora. Their infrastructure team is very open and inclusive. They do have a system which allows for automated timely builds as well.

Yes, the Fedora project does slip it's release dates, but when it does so there is good reason and things are done in a very open manner. A release date slipping because it's "not done yet" is one thing. Helping your users understand what "not done yet" *IS, is a much more important part of managing a project.

Bootstrapping

A lot of these ideas come from observation of the Fedora Infrastructure team.

Account management

The Fedora Account system is central to the management of the Fedora Project. It's a directory service which handles accounts and access to various infrastructure resources.

A good directory service should be the first thing a RHEL clone would need to bring up.

The most robust I'm aware of is FreeIPA.

Build system

Fedora uses Koji to manage the builds of their packages. This allows for a fully open and automate-able build of packages from an upstream vendor. This is truly the key to a distro which needs to move fast.

There should also be a system in place for feedback of the packages in the distro. Bodhi is a good tool for such a task.

Public internet presence

A distro also needs an internet presence, a way of managing content, interaction with users, interaction with developers and testers, and a means for wide communication. All of these tasks can be done pretty cheaply if not freely.

• Github for source code related to the project (you could even use it as an issue tracker)

• Google Groups for mailing lists -- mailing lists are a great way to manage a diverse group of help.

• A public website is also needed to host www.$PROG.org and the project's documentation.

• There should also be a downloads.$PROJ.org for hosting things such as isos, yum repos, etc. This should be available via FTP, RSYNC, and HTTP.

Semi-public internet presence

In order for a distro like this to survive there needs to be multiple mirrors of the downloads server. These would be primed via a mirror host which is restricted to everyone except a few first-level mirror sites. The update of the mirrors would use rsync.

Internal Infrastructure.

There should also be an infrastructure host whose job it is to manage the other hosts mentioned. This host would have no public-facing interfaces except SSH. This host would act as the configuration management system's server, as well as the bastion host for the trusted infrastructure users to access and configure other servers.

EVERYTHING would be configured using a configuration management system (puppet, chef, etc). This allows for the infrastructure team to quickly adjust for demand or utilization of resources.

Bottom line

If such a project were to exist, the bootstrap resources needed would be:

• Four servers minimum -- SuperMicro has a 4-node 2-RMU server

• Some storage of some sort -- An inexpensive SAN solution would allow for the most flexibility. This Coraid Appliance would be nice.

• People interested in being open and willing to work in this endeavour.

This may be a pie-in-the-sky idea, but I think it has merit. Can you think of anything missing from the above proposal?

Cheers
Goozbach

Oh the busy, busy times are here!

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/