Personal note first: I’ve been swamped with deliveries these past two weeks, which means that most of my mail is parked in the inbox waiting for reply; if you read this post and wonder why I haven’t replied to you yet.. just know that anything that could be construed as work will have to fit in the 8am-7pm time range.. and I started writing this at 10pm.
In August I’ve migrated my blog, website (and a few customers’ websites as well) from a vserver to a KVM guest, thanks to my hoster – ios-solutions – having it available, and with IPv6. Move to IPv6 was something I was particularly interested in, since I’ve deployed it locally to have stable addresses for all systems and with it on the server I could tell who was connecting to what exactly.
Today, after making sure that the migration to KVM was working quite well, I applied the same migration to the server that hosts xine’s website and Bugzilla installation. This allows me to use a single local guest to build packages for both servers, and keep both Portage world files empty, using Portage 2.2 sets feature to distinguish what to install on one or the other.
The “new” server (which is actually a hybrid made by a base image of Earhart, this server, and the configurations from Midas, the old xine server) lost its name and naming scheme (given that when I called it Midas it was also “my” server) and is now simply xine-project.org — but at the same time it gained full IPv6 support and, contrarily to my own domain, that means that mail can be delivered on a pure IPv6 network as well.
At any rate, I wanted to take this opportunity to remember everyone that xine is not entirely dead, as it can be told by me actually spending my personal free time to work on its server rather than simply giving up. While I have not followed through with the 1.2 release – mostly because I lost track of xine after my weeks at the hospital three years ago – there should be enough code there to be released, if somebody cared about giving it some deserved love. But just doing that is … unlikely to help alone.
If you’ve been following me for long enough, you know that I have worked hard on xine and learnt a lot by doing so. One of the things I learned is that its design and not-invented-here-isms are not something you really want on a modern project. On the other hand, I still think that the overall, general, high-level design of splitting frontends and the library with more tightly coupled plugins is a good idea. Of course this is more or less the same overall, general, high-level design followed by VLC.
What are the problems with continuing with xine-lib the way it is? Well, the plugins right now are too abstracted; while they don’t reach the level of abstraction of GStreamer, that makes them obnoxious, and they are still mostly shipped with xine, there are limitations, which is why of all the major users of libav/ffmpeg, xine does not use libavformat to demux the files, d’oh. Plugins also have a long list of minor issues with their design, starting with the whole structure handling that is a total waste of space and CPU cycles.
So if you’re interested in xine, please come to #xine @ OFTC, the project has still potential, but it needs new blood.