My thoughts on the Red Hat / CentOS partnership

It’s been six months since Red Hat announced they were joining forces with CentOS. I think things have settled down enough for me to make a post without controversy. I’ll use my usual question and answer format to answer the most common questions I’ve gotten.

Q: Did you know about the plans for the merger?
Yes. I was in the loop as a “consultant” for about 8 months.

Q: Why CentOS and not Scientific Linux?
There were pro’s and con’s for each distribution. I personally thought that Scientific Linux’s workflow and desire for others to create “spins” would have fit better with Red Hat’s goals. But the complications associated with working with goverment funded labs far outweighed the work that would have been saved by using Scientific Linux.

Q: What is Red Hat’s real agenda? Are they trying to get rid of RHEL clones?
If you read Red Hat’s press releases about why they wanted to do this, then you know what their real agenda is.
They are not trying to get rid of the RHEL clones.
Red Hat needed a way to be able to let people try their products that layer on top of RHEL. But how can you let people try them without giving away RHEL for free.
My best example is from OpenShift, the product I work on. We had OpenShift Origin that worked on Fedora, and we had OpenShift Enterprise, that works on RHEL6. But we had no official way for users who didn’t already have RHEL subscriptions to try OpenShift on an enterprise OS. After the team up with CentOS we are able to have users try OpenShift Origin on CentOS.

Q: Do I think the whole joining of forces thing will work?
Yes. I think there is still going to be some rough patches. But I think as the months turn into years, those rough patches will be worn smooth.

Q: How does this affect Scientific Linux?
I am unable to comment on this question at the present time. Not because anyone is silencing me. But because currently I don’t know. There are multiple paths that Scientific Linux can take, and they are proceeding with caution and due diligence.

Hepix Dinner

Gallery

This gallery contains 20 photos.

The Hepix Dinner was help at the Henry Ford Meusium. It was a casual buffet style with different tables having different cultural foods. All of it was very good.

Hepix 2013

Gallery

This gallery contains 4 photos.

Hepix 2013 was held in Ann Arbor, Michigan, USA. It was from Monday October 28 to Friday November 1, 2013. These are a few of the general pictures taken there.

Two Years at Red Hat

Do you still enjoy working at Red Hat?
Has the enviroment changed after the novelty wore off?

Yes, I still love working at Red Hat.
I no longer wake up, surprised to find myself working at Red Hat, so in that sense, the novelty has worn off.
But, even after two years, the Red Hat culture still feels like a custom fit to me.

Do you still like working on OpenShift?

Yes.
The team has grown quite a bit, but it is still an awesom team to work with. There is the occasional disagreement over an issue here or there. But everyone looks at the real goal, and works out the best way to do it.
Besides the great people to work with, I really like that OpenShift has transformed into a three pronged project. OpenShift Origin has all the source code out there if you want to set up your own OpenShift infratructure on your own. OpenShift Enterprise let’s you setup up your own OpenShift instrastructure with our help and support. And then OpenShift Online, for those who just want to use it, ready made.

Any interesting stories to tell?

It’s always interesting having people from Sales contact me, asking for the inside scoop on RHEL clones. Even though I work for Red Hat, I still feel the same about RHEL clones. I feel RHEL should be used in your production enviroments and/or when you need support. But you should use Scientific Linux in your testing and/or development enviroments. They never like to hear that, and they rarely contact me again. My Red Hat is off to the one sales guy who not only contacted me again, but allowed me to speak to their customer.

Open WebOS on Fedora 17

The Open WebOS team is hard at work. As soon as I finished my post to build OpenWebOS on Fedora 16, they had already updated the build script to include more items, particularly the web browser. The browser required libraries that were only found in Fedora 17.

I had been looking for an excuse to update to Fedora 17, and now I found one.

Unfortunatly they aren’t prepared for a bleeding edge distribution like Fedora. The library pbnjson that they want to build, doesn’t like the yajl version 2.0.4. Fedora 16, and all of the supported Ubuntu versions, have yajl 1.0.x. And this library builds just fine with all the 1.x version.

So, to make a long story short, I’m working on putting things into rpm’s, so that I can build these packages on my terms. It will take me longer than using their script, but I will have more control, and it will be more reproduceable.

So far, I am using the system cmake, and I have made the cmake-modules-webos rpm.

- cmake-modules-webos-0.9-1.fc17.src.rpm
- cmake-modules-webos-0.9-1.fc17.noarch.rpm

As I work my way through each module, I’ll see if I can just use the system version instead of the Open WebOS version. Hopefully that will make things more system independant.

Open WebOS on Fedora 16

Relavent Links:
https://github.com/openwebos – Source code for Open WebOS
https://github.com/openwebos/build-desktop – Scripts to get it built and working on your desktop

Notes:

  • Open WebOS instructions and scripts are still in a state of being updated, this is a beta after all. So it’s possible my fixes aren’t needed, or possibly might not work.
  • This is on Fedora 16. Your milage may vary on anything else.

Steps:
We are going to be following the from Open WebOS, but only modifying them to work on Fedora. When in doubt, follow the official instructions.

1 – Install Packages

  • yum -y install git git-core make autoconf libtool tcl unzip curl qt-dev gcc-c++ yajl-devel yajl qt-devel sqlite-devel pkgconfig
  • yum -y install gperf bison flex glib2-devel openssl-devel libXi-devel libXrandr-devel libXfixes-devel libXcursor-devel freetype-devel libXinerama-devel mesa-libGL-devel gstreamer-devel gstreamer-plugins-base-devel libicu-devel
  • yum -y install boost-devel boost-devel uriparser-devel c-ares-devel libsigc++-devel glibmm24-devel db4-devel libcurl-devel

2 – Setup

  • mkdir webos
  • cd webos
  • git clone git://github.com/openwebos/build-desktop.git
  • cd build-desktop
  • *patch build-webos-desktop.sh*
  • *edit install-webos-desktop.sh*

    You need to replace ${HOME} with the full path for your home. The reason for this is because you need to “sudo” this script, and when you do, it replaces ${HOME} with /root/. This is ok if you are doing all these steps as root, but if you are a normal user, you have broken links all over the place.

3 – Build and Install
From this point on, our steps are the same as the official instructions. But I will put them here so you just have one page.

  • ./build-webos-desktop.sh
  • sudo ./install-webos-desktop.sh

    Be sure to replace ${HOME} with the path for your home area.

3 – Start and Run
Again, this part is straight from the official instructions.

  • ./service-bus.sh start
  • ./service-bus.sh services
  • ./service-bus.sh init
  • ./run-luna-sysmgr.sh
  • *When you are done, close things down with*

    ./service-bus.sh stop

Patch:

--- build-webos-desktop.sh.original	2012-09-08 09:08:02.573439051 -0500
+++ build-webos-desktop.sh	2012-09-07 22:49:51.403333099 -0500
@@ -892,8 +892,12 @@
     do_fetch openwebos/db8 $1 db8 submissions/
 
     ##### To build from your local clone of db8, change the following line to "cd" to your clone's location
-    cd $BASE/db8
+    #cd $BASE/db8
+    cd $BASE/db8.local/db8
+    #sed -i 's/TEST_TARGETS := libmojocore libmojodb/TEST_TARGETS := libmojodb/' build/Makefile.inc
+    #sed -i 's|/usr/local/lib|/usr/lib|' build/Makefile.inc
     make $JOBS -e PREFIX=$LUNA_STAGING -f Makefile.Ubuntu install BUILD_TYPE=release
+    #make $JOBS -e PREFIX=$LUNA_STAGING -f Makefile.Ubuntu install BUILD_TYPE=debug
     # NOTE: Make binary findable in /usr/lib/luna so ls2 can match the role file
     cp release-linux-x86/mojodb-luna "${ROOTFS}/usr/lib/luna/"
     # TODO: remove after switching to cmake
@@ -914,6 +918,7 @@
 
     ##### To build from your local clone of configurator, change the following line to "cd" to your clone's location
     cd $BASE/configurator
+    sed -i 's|-llunaservice -lmojo|-llunaservice /lib/libglib-2.0.so.0 -lmojo|' Makefile.inc
     ARCH_LDFLAGS="-Wl,-rpath-link $LUNA_STAGING/lib" make $JOBS -f Makefile.Ubuntu
     # NOTE: Make binary findable in /usr/lib/luna so ls2 can match the role file
     cp debug-linux-x86/configurator "${ROOTFS}/usr/lib/luna/"

Six months at Red Hat

I’ve been working at Red Hat for six months.  I want to answer the two questions I’m asked the most.  Is working for Red Hat what you expected it to be?  Do you regret leaving Fermilab and Scientific Linux to work on OpenShift for Red Hat?

Is working for Red Hat what I expected it to be?

Yes, and more so.

Their dedication to Linux and open source was one of the main reason’s I wanted to work for Red Hat, so I was glad to find out how pervasive it is through the whole company..  They try to have the whole company open to all the employee’s as much as possible.   They try to support not only open source, but openness in all things, such as open hardware and open government.

Do I regret leaving Fermilab and Scientific Linux to work on OpenShift for Red Hat?

Although I loved working at Fermilab, and I loved making and maintaining Scientific Linux, t I also love working on OpenShift.  It is fast paced, great co-workers, I’m learning a lot, and I am working on a project that I think will help alot of people.

One thing I’ve been learning, is how to work with a large team of people.  I’ve had to learn that I don’t have to do everything myself.  It is a little scary letting others do what you could do, but it’s also very refreshing once you get used to it.