Archive for the ‘misc’ Category

Distribution-specific builds

For quite some time now, we’ve attempted to distribute OpenPanel as a single set of packages. In theory this works fine, as ABI changes should be reflected in Debian’s package names. However, more and more problems came up lately where older versions of libraries vanished from newer distributions and Ubuntu has shown more ABI-divergence from Debian than we anticipated.

To solve this problem, we’ve decided to create separate builds for each of our supported platforms: Debian Lenny and  Squeeze, Ubuntu Lucid and Natty. For now, Ubuntu Oneiric and Precise point to Natty’s packages, and Ubuntu Maveric points to Lucid’s packages. Note that these platforms are not supported (yet).

To switch your OpenPanel installation to the new packages, you’ll need to change your /etc/apt/source.list. The basic syntax is:

deb http://download.openpanel.com/deb <distribution> main 
deb-src http://download.openpanel.com/deb <distribution> main

where distribution should be replaced by the code name for your distribution; either lenny, squeeze, wheezy, lucid, maverick, natty, oneiric or precise.

For OpenApp, append openapp to the deb line:

deb http://download.openpanel.com/deb <distribution> main openapp
deb-src http://download.openpanel.com/deb <distribution> main openapp

Keep in mind that Ubuntu 10.04 Lucid is presently the only supported distribution for OpenApp; other distributions might just work, but we’ve never tested it.

What are we up to?

Our site has remained dormant for quite a while and we get the occasional visitor on the irc channel poking us with a stick to check for rigor mortis. It’s not that bad, actually. We’re very close to a 1.0 release, code-wise, and have been for quite a while. But the devil is in the details and the details are definitely in the packages. When we started the project, Debian 4 and CentOS 4 were sensible stable targets. Obviously, they’re not anymore. So our first effort into getting ready for a testable pre-1.0 branch is to pick up whatever pile of paperclips and rubber bands we used to autobuild the packages for both these platforms and re-adopt the contraption to work with their newer distro brethern, CentOS 5 and Debian 5.
Read the rest of this entry »

On Snobism

Recently I decided to bring some life to the Grace homepage. I always expected it to spawn some controversy so I’ve not been surprised by seeing a vocal group of people dismissing its ideas out of hand. One of the most colorful reviews is one that could only make me chuckle: “it’s like Java and PHP gang-raped a Makefile”. I’m not likely to make too much out of reactions like that, these are questions about taste where you just can’t please everyone (and shouldn’t try).
Read the rest of this entry »

Browser, What Ails Thee?

The problem with developing front-end applications for web browsers from a back-end developer’s point of view.

In our search for quick (and equally dirty) Javascript solutions for problems like form creation and control, we’ve run across a lot of frameworks. “Let’s use the framework which makes our lives easiest” was the chant, to implement anything third party loosely and, if it breaks, rip it out and either find something better or write something from scratch.

Read the rest of this entry »

When you are designing a project with complex storage requirements and some demands on reliability and performance, a few options come to mind.

Even though at OpenPanel we have strong feelings about NIH, we didn’t think writing our own database store was the way to go. Many smart people have already written many different database backends, which means that in both quantity and quality the database area is well-covered. So, writing our own was right out.

The second option that comes to mind is to use the most basic kind of database available: a key/value store like Berkeley DB or GDBM. Combining a few key/value stores together yields a lot of flexibility, but there’s a lot of glue you need to write, then. In programming language terms, the key/value API is not powerful.
Read the rest of this entry »

People requested a screencast of our command line interface, opencli, in action as well, so here it is:

We’ll be adding a dedicated screenshots section to our website soon.

The premise sounds easy enough: There’s no arguing with free. In the server control panel market we found a niche dominated by commercial players with a stranglehold on price and a bunch of products that annoy system administrators to the bone. So we set out to create something appealing — software with disruptive potential. With a product in our hands that ticks all the checkboxes in terms of nerd appeal, you would say that this would be as easy a sell as free blowjobs at a LAN party. Unfortunately, things are not quite that simple.

We went through the hoops submitting the news of our release to a dozen of the usual suspects, got a couple of hits and the first testers have arrived. There’s even a couple of people around doing more involved things like trying to port packages to other distros. It’s not bad and we appreciate all the people helping us out by playing with the beta, but a stampede it is not. Building a community takes time.

In terms of strategy, this may be the real reason for the ‘release early, release often’ mantra. Especially when your project is in a niche area, expect community building to take up maybe just as much time as actual development. We wanted to avoid getting distracted by actual users too early in the game, so our gut feeling at the time was ‘early, schmearly’. We had a couple of other reasons, some of them even sounded real good — like how there are too many open source projects in the field that need so much polishing that the market has been mostly ignoring them. But the fact of the matter is, all the hours of community building we’ve been avoiding up to the beta release will have to be put in double now. We’ll need to go from our current mode of reclusive introversion to full-blown extravert. Tough job for a bunch of nerds.

Here’s a preview of the upcoming Beta release of our life’s work. Now that we’re over that “oh no, we’re all going to die and we’ll never finish it” point, things are starting to look well. Or perhaps the other way around:

We’ll pick up the last bugs we found monday and then seed a release candidate to our alpha team. If no show stoppers emerge, that will be followed up shortly by a full public release of the OpenPanel beta.

[kml_flashembed movie="http://youtube.com/v/rdklako-Hy4" width="425" height="350" wmode="transparent" /]

Using Protocols in C++

A major source of anger and frustration in C++ style OO is multiple inheritance. It’s a source of anger and frustration and one most people recognize as a path best avoided. The Objective-C idea of a protocol is a real life-saver in many occasions where you would need to deal with multiple inheritance otherwise. The concept of a protocol is to have a second way of classifying objects, one that completely sidesteps the hierarchical class model and instead just classifies objects by their common functions.

One area where the concept of protocols is quite convenient is iteration. There is usually a wide area of possible classes that could, theoretically, enumerate a list of contained items. Although C++ lacks protocols proper, template iterators are a fine way to access any class that implements a de facto iterator protocol. The only thing missing is an explicit declaration of the implemented protocol.

The Grace iterator<collectionclass,nodeclass> template is a minimized version of the visitor<> template. It requires one function (visitchild) to be defined inside your class that returns a pointer to a child node. Here is what it would look like for a purely synthetic class:


class syntheticlist
{
public:
   syntheticlist (void) {}
   ~syntheticlist (void) {}
   string *visitchild (int atpos)
   {
       if ((atpos<0)||(atpos>1)) return NULL;
       if (atpos==0) str = "Hello";
       else str = "world";
       return &str;
   }
protected:
   string str;
};

int myApp::main (void)
{
   syntheticlist L;
   foreach (n,L) fout.writeln (n);
   return 0;
}

The foreach macro goes through the following steps:

  1. It creates an iterator<syntheticlist, string *> pointing to L
  2. It sets up a for loop that starts at visitchild(0) and stops when it returns NULL
  3. It creates a temporary reference variable n linked to the current node.

The Grace iterator protocol looks a bit ascetic with only visitchild and the lack of the traditional first() and next() pattern. Part of this is due to the visitor protocol (which iterator is a part of) being about more than just of iteration. If your goal, however, is to make your class iterable with foreach, you can safely assume an argument value 0 to mean ‘first’ and any value bigger than 0 to mean ‘next’ if that makes more sense in your context. Most collection classes used within Grace use growable arrays, which means they don’t have to keep any state information in order to be iterable.

Project supported by CloudVPS a leading European cloud server provider.