Tuesday, August 23, 2011

Blender 2.59, now with Ocean Simulation

Ok, so I have been tinkering with Blender of late, even going so far as to enroll in an online course (The Nature Academy).

Over the course of various tutorials, lessons, etc, it became necessary to update Blender from the 2.49 release currently found in Natty (Ubuntu 11.04) to something more recent. Initially, I used the most excellent PPA Blender SVN maintained by Ralf Hölzemer.

This was great, up to the point where it seemed each commit broke one of the lessons or tutorials I was working on. Of course, this was to be expected, as the PPA provided a daily build for the in development 2.59 series.

Now that Blender 2.59 is released, I felt it was time to make a stable build. That was pretty easy, take the 2.59 package snapshot from Oneiric (Ubuntu 11.10) as a starting point and backport to Natty. Update it to use the official 2.59 source tar.gz from Blender.org. Add in a little flavor from the Blender SVN package, and voila, you have a nice 2.59 build.

While this was going on, I was also still working on the lessons from my online course, and the most recent lesson came out on Oceans. Unfortunately, this lesson required downloading a special build from Save the Ocean Sim. This was sub-optimal, I had just built 2.59 and now needed to use an earlier build and for one not built for Natty.

After going to the Save the Ocean Sim site, I downloaded the most recent patch and applied it to my build for 2.59. With much happiness (and minimal fiddling), it all compiled and tested fine with the ocean test blend from their site.


open up a terminal, and do the following to get this new Blender build:

sudo add-apt-repository ppa:roderick-greening/blender

Cheers and happy blendering,


Monday, March 14, 2011

In response to "the libappindicator story"

I generally never weigh in on these things, but I think in this case I understand what some may be missing here.

This is in reference to the following blog post: the libappindicator story

Each side refers to process and how the other side failed to follow it. My question is "can anyone point me to the relevant documentation which shows the process being referred to" and "can both parties review this process to see where they fell down" and "can the process be reviewed to ensure that it is clear and works so as to prevent similar future issues".

I suspect that there is no documented process, nor is it generally understood as to how all this was supposed to work by both parties. It's easy to reject an idea citing some failure to comply with a non-documented process. I'd like to be proven wrong and see that a process actually exists and work from there, but I suspect it's currently vapourware.

It's fine for you to state Canonical did not follow the process, but to not link to a doc or provide a post showing the process as approved by either GNOME or the team within GNOME responsible for this particular area, it's quite frankly irresponsible.

In order to make any such claim, you need tangible documentation. GNOME is big enough and the teams are diverse enough, that you need to document process. How else do you get efficient and allow new development to occur? You cannot exist forever in a vacuum.

So, if there is indeed a well documented process, show us the link. Show Mark that his team failed to follow the documented process. Then, once that's done we can move on. Mark will admit defeat and apologize and we can call it a day.

However, if this is not well documented nor consistent across GNOME projects, then GNOME needs to recognize that the lack of a documented process may have contributed here and let's correct that and move on.

PS: I work in a very process driven area (customer service and delivery) and it requires well documented processes to function. I understand all to well when some process exists virtually and is not well documented what can happen. Orders get missed, revenue drops, productivity suffers. As well, people point fingers. The only way to rectify is document the process and get everyone to acknowledge it. The process doesn't have to be perfect, it just has to be documented so you can at least have a reference point to move forward from.


Wednesday, December 22, 2010

Monday, December 13, 2010

Interesting comic regarding Wikileaks

Not KDE/Kubuntu related, but hits a note on freedom...