I for one welcome our new buggy GST DecodeBin!

August 9th, 2007

Consider the following gst-launch pipelines.

The first one uses decodebin as all proper GStreamer pipelines should:

nenolod@petrie ~ $ gst-launch-0.10 filesrc location=/home/nenolod/Moby\ -\ Porcelain.mp3 ! decodebin ! audioconvert ! audioresample ! osssink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...

ERROR: from element /pipeline0/filesrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(1811): gst_base_src_loop (): /pipeline0/filesrc0:
streaming task paused, reason not-linked (-1)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
FREEING pipeline ...

The second one works, by not using decodebin:

nenolod@petrie ~ $ gst-launch-0.10 filesrc location=/home/nenolod/Moby\ -\ Porcelain.mp3 ! mad ! audioconvert ! audioresample ! osssink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock
Got EOS from element "pipeline0".
Execution ended after 241196555000 ns.

Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
FREEING pipeline ...

Now for today’s round of questions:

  • What the hell does gstbasesrc.c(1811): gst_base_src_loop (): /pipeline0/filesrc0: streaming task paused, reason not-linked (-1) mean?
  • Why does decodebin fail while calling the mad GST pad directly works?
  • How does Audacious handle this situation differently than GStreamer?

I leave determining those to the reader.

Is C really a good language for runtime frameworks?

May 5th, 2007

Most C-like object-oriented languages (C++, ObjC) have a runtime library. But is writing that library in C such a good idea? It has been two years since Atheme.org set out to create a framework for it’s projects to use, and only recently have we made any breakthroughs on that. Our first attempt was Claro, but this has mostly not made it due to strange licensing arrangements (MPL), which is incompatible with our licensing philosophy.

Our second attempt contains several frameworks for various tasks. This includes Mowgli, which is our base framework. Mowgli can be considered very similar to both Boost in C++ and the System namespace in .NET. At the core of Mowgli, is mowgli.object, which is probably the coolest part of our framework. Mowgli’s object framework is very advanced; it allows for private destructors, hidden visibility, metadata, messaging and a lot more. In addition, mowgli objects can easily be reflected into other systems and paradigms, like D-Bus (we intend infact, to provide a library which does this).

However, is C such a great language for this? The fact that we’re using C means that our types are very long, e.g. mowgli_object_class_t, and so on. For a base library, I think C is probably fine, but I don’t know how usable Mowgli will be alone for writing OO apps using our framework. Perhaps we should also design a language to be used with our frameworks… if that is the case then I’m sure we’ll do OK with that.

Anyway, why not write an object framework in something like Erlang? I guess that isn’t challenging enough.

Keeping Open Source and Peer Directed projects real

April 18th, 2007

…and where a lot of people fail at it.

Drama in Open Source is becoming a lot more prevalent these days, even between projects. For instance, a few weeks ago, there was a fairly alarming interaction between the bcm43xx Linux driver developers and the OpenBSD bcw developer. However, what you probably don’t know, is that there’s a lot of interactions not only between projects but inside projects as well. I’d name some projects where this is very prevalent, but that would be a waste of time and accomplish nothing, so I don’t think I will.

The drama monster can attack any project, small or big. Size doesn’t really matter, and it doesn’t really seem to care what the issue could be about. Anything is fair gain. Of course, the drama monster is a manifestation of human personality in general, but management decisions can be made to avoid this from becoming a major problem very early on. I’m not talking about “codes of conduct” policies either.

A look at the problem

In most projects, you have friendly people and unfriendly people towards your position. This is a way of life, and there isn’t much that can be done about it. The problem is that when you do not have backing from your friendly people, the unfriendly people will take that as an opportunity to attack your position. This can be devastating and causes a lot of otherwise great developers to leave projects. Again, I can produce specific examples, but that is uninteresting.

Most intra-project drama comes about because there is no steering committee (larger projects) or person to make a final decision (small projects). In a situation like this, the results can be devastating. When there is no central authority in the project, cherry-picking can occur. In some projects, this works to the project’s advantage. However, in other projects, it results in a whole lot of drama. A large contributor and indicator to whether or not bazaar-style development will be successful is the overall maturity level of the contributors. If the contributors are immature, a bazaar-style approach will eventually fail. If the contributors are mature, then this paradigm of development can prove to be very successful.

Combining the unified (“Cathedral”) and decentralized (“Bazaar”) paradigms, and why it does not work

Some projects more recently have tried to combine qualities of the unified development paradigm and the decentralized development paradigm. This has usually resulted in a large organization where people generally do what they wish with what they are working on. While this may prove advantageous at first, the deficiencies of this combined model usually expose themselves fairly early, especially when people have to work together on a component of the overall project.

This model can work if people rarely have to collaborate with other people directly. It can also work if the people who are collaborating are friendly to each other’s position on how the project should proceed. However, it can result in major problems if the people do not wish to collaborate. In this case, the cathedral side of the combined paradigm usually wins out and a developer loses his commit access. This results in further drama because then the people who are friendly to the now ex-developer decide to hold a grudge against the person that ex-developer argued with. This sort of drama is the most dangerous to any project following this combined paradigm, and can result in forks that may not be very-well considered.

Forking for political reasons is also not keeping it real

When major disagreements happen, so do forks. Most forks ultimately fail because they are political in nature and usually do not receive much public vision. Political reasons can be a good spark towards thinking out a plan for a fork, but should never be used as a direct cause to begin a fork. This is non-useful and will simply scare away developers that may otherwise choose to contribute. If a project does get forked for political reasons, then both sides of the debate are usually harmed. Nothing usually comes out of a hostile fork except for further problems. As such, forking for political reasons is not keeping things real.

So if forking is not the answer, what is?

It depends on the paradigm, but it seems that having a place where people can vent their issues without having it come back to haunt them is a very good start. Some projects and development communities (Atheme) have such a way already. People voicing concerns is usually productive, people filing complaints with more powerful people in the project is usually not the way to solve the problem, however that is also human nature. Allowing arguments to happen (as long as it is directed to somewhere out of the public view) is usually an effective solution to the problem.

Audacious, and the day I got called a script kiddie.

October 28th, 2005

For those who do not know, I’ve started a new project called Audacious. It’s a media player based on BMP and XMMS sources, and has already picked up another developer.

In other news, I’ve g:lined nick125 from my IRC network, for his anti-nenolod behaviour. This has resulted in a lot of trolling on freenode, leading up to this little incident:

17:39 -!- kbrooks [n=kbrooks@unaffiliated/kbrooks] has joined #audacious
17:39 < kbrooks> nenolod: pm me now
17:41 < kbrooks> nenolod: YOU are a script kiddie. End of story. Goodbye
17:41 -!- kbrooks [n=kbrooks@unaffiliated/kbrooks] has left #audacious [”Leaving”]

I’m starting to agree with lilo about these Traditional IRC users. They need to go back to GameSurge.

We want you.

September 6th, 2005

This is a call to all of you people out there on freenode, (I know there are some who lurk around this blog, wondering about when I’m going to disclose information on hyperion 2.) We want you for freenode’s support team. I will be up front with you — this is a helper role, not a staff role, but hey — status is not important! This is about the community, and helping your peers get acquainted with the network. This is not a tech-support role, it goes much deeper than that. Social skills are required.

The following is a list, or a basic outline of what your duties will be, if you do apply for this role on freenode:

  • Managing support requests from start to completion.
  • Answering questions from new users, and current users on the network concerning logistical operations.
  • Directing users to more accurate sources of information when you do not know the answer, or researching the inquiry. (either is acceptable, most of the time, the latter is preferred.)
  • Reporting network trouble to the core group (lilo, LoRez, dmwaters)
  • Relaying ircd bug reports to myself, or jilles
  • Working with freenode staff to solve problems

Staff interaction is high, this is not for the weak of heart. (Sometimes UDontKnow smells, but we don’t tell him that.) However, you get to meet a lot of new people and work with them on a personal level. Hopefully you will volunteer your time. We will be holding interviews this week, around 02:00 fST.

n0theme? funny!

August 29th, 2005

One of the people who used to be involved with our project, brian, has decided to fork Atheme. For some reason, there was a communications breakdown with him. Anyway, his project is located at www.notheme.org.

A disappointing part of this is that he has decided to take swipes at the development team. I’m not going to dispute that things were not necessarily too great with brian for the last few months, and we were fairly sure that brian did not agree with our direction — so we found a way to work through the issue without him. Several people had an issue with him leading up to this fork.

That aside, I would like to personally wish him luck with his fork of Atheme, perhaps he can come up with some great security-oriented ideas that we have yet to establish. However, Atheme will still live on, no matter what he wishes to say about our direction. We are going nowhere, and intend to stay around for a very long time.

For you gentoo users out there — beu will be importing Atheme into portage sometime this week. That will be something to look forward to!

As for me ircd-wise, I have found a nice comfortable home amongst the ircd-hybrid team. This is still a little wierd… but hey! Dianora has a lot of excellent ideas, that could shake up the IRCd world. So that should be interesting. Update (09/02): Also on freenode staff.

generic library fun?

July 29th, 2005

In Atheme, I’ve started breaking out generic functions (block allocation, connection tracking, etc), into a library, called libatheme. The goal is to allow that section of code to be reusable in other programs. If you’re interested, idle in the Atheme development channel, and watch the commits to see what changes are occuring.

That’s all for now.


July 28th, 2005

For those of you following Atheme’s development, you may or may not know of our plans to include an optional webservice module in Atheme 0.3 for the purpose of creating a web interface with.

Right now, we’re in the process of building an appropriate RPC interface around a library called xmlrpc-epi, which is released under the BSD license (just like Atheme). Our plan is simple. Using the new connection code, we’re going to create a TCP listener and a small HTTPD inside Atheme. The HTTPD will be very simple, and will only be usable for the XMLRPC interface.

Here’s the deal though. The XMLRPC interface is replacing realtime SQL support, as it is safer and ensures data integrity through Atheme being able to enforce it’s own data constraints. (Don’t worry, the postgresql backend is not being removed, nor will be any time in the future.)

You might be wondering what XMLRPC is. It’s basically a system that allows for the declaration of nice and easy to use interfaces, and also allows for the ability to use these interfaces remotely. In a computer program, internally, these interfaces (or jump-points, or symbols, or routines) are typically called procedures, and using these procedures is typically referred to as a procedure call. RPC extends the concept of having multiple routines, by allowing different programs to call work with other programs on another (or the same) machine. XMLRPC makes this concept work multiplatform by defining a platform-independent specification for program execution. There are many security issues with XMLRPC though, but those flaws are applicable to any system of this nature.

Another IRC-related package, NeoStats, takes RPC in a different direction by emulating a PostgreSQL server. While that is rather advanced, and could be rather useful, the overhead seems a little unnecessary for Atheme, and does not ensure data integrity in the manner that a RPC protocol would.

So the big thing for 0.3 is going to be XMLRPC.