State of vector graphics support

Decided to look into the current state of vector graphics support
today. My original testcase was whether would be able to load a graphics into Inkscape then load then save and load the image into OpenOffice. As I tested I increased my target by doing various other tests testing interoperability. The origin for my testing was the hope that SVG support would be so commonplace and good now that we had achieved full interoperability beetween large parts of the desktop. Ended up testing a lot of random file formats and viewers.

I put together a page with my test results and the result was not exactly what I had hoped :)

Be aware that I don’t consider any of the results here as proof of anything except that as a normal user spending 2-3 hours on the problem this was as far as I got.

Watching Steve Jobs Keynote

So Wim discovered that he was unable to view the keynote that Steve Jobs did at MacWorld. The reason was that it was using some weird Quicktime RTSP format which none of the open players seemed to support (could be that they do in their CVS versions). So he hacked up support for it in GStreamer building on the RTSP work which I mentioned a few days ago.
The result looks like this:

The RTSP uri in question is this (needs CVS GStreamer of almost every module)

rtsp://a2047.v1413b.c1413.g.vq.akamaistream.net/5/2047/1413/1_h264_110/1a1a1ae656c632970267e04ebd3196c428970e7ce857b81c4aab1677e445aedc3fae1b4a7bafe013/8848125_1_110.mov

The link from the browser doesn’t work yet, but I think thats probably some player detection or playlist parsing issue.

Fluendo webshop updates

So for a *long* time we have promised to provide a wide set of plugins
for GStreamer through the Fluendo webshop. We have had a series of plugins in beta testing for a long time now while at the same time sorting out the final legal and other practical issues. Anyway things are now ready I have been working a lot on getting everything ready this week.

As a final grand test I have updated the mp3 plugin we have offered for free on the shop for a while now. Due to this I would like to ask that anyone reading this blog entry please try downloading the new mp3 plugin and testing it on their systems. Currently the shop contains an GStreamer MP3 plugin for X86_32, x86_64, Solaris Intel and Solaris SPARC. Also trying to get a Linux PPC version online today. People who have gotten our plugin earlier from the webshop should also get this new version as the code has many bugfixes and improvements over the first version we offered.

The new bug system should be available on Monday, so anyone downloading and having problems during the weekend with the plugins please just send me an email on christian at fluendo dot com.

So unless this final mini test should turn up something unexpected I will upload all the plugins on Monday and send out a press release.

Be aware that the webshop offers you two payment systems so be sure to choose the ‘Free of Charge’ one for the mp3 plugin as the credit card system do not handle charges of 0 very well :) We will be working on getting rid of the credit card option as an option when people just get our free stuff.

Last RTSP step taken

Wim just commited some changes to gst-plugins-base which finally enables RTSP playback in playbin. That means that Totem etc., will be able to automatically play any RTSP stream we have RTP depayloaders for (and our list of RTP depayloaders is starting to get quite long). One of the one’s still not complete is Real support as can be seen in this bug report. So while we have good plugins for decoding Real format in GStreamer now the network support is still missing someone to take it the last mile (ie. replace the code of uncertain origin in the current patch). Hopefully Lutz will take this upon himself. Also a little work is needed to ensure we handle the Real RTSP extensions properly. Other formats like MPEG formats, Xiph formats and Microsoft formats should work with this commit although I am not sure if we have a RTP depayloader for Windows Media ready apart from Fluendo’s commercial one.

Easy codec install

Another set of changes comitted over the last few days was Tim’s work on enabling the easy codec install stuff that was decided upon during the UDS conference. With these API additions writing helper applications that integrate with vendor specific applications to ease codec installation will be much easier to do. Ubuntu already is well underway implementing it and I also noticed a ‘codec buddy’ being listed for Fedora Core 7. Tim will also write an application integrating with the Fluendo webshop using this system.

gnomedesktop.org

Decided to beef up my involvement with gnomedesktop.org a couple of days ago. Blogging has taken over some of the functions of a news site like gnomedesktop, but I still think it could provide a useful resource for GNOME users. So I will try to add more stories and keep the moderation empty again.

Is releasing the code always important?

Been briefly taking part in and watching a discussion about wether Launchpad should be released. The debate made me think about wether all code releasing is truly important or even a good thing.

Once upon a time I was writing articles for a now defunct news site called linuxpower.org. For this site a special publishing system had been written. I know Jeremy considered releasing the code we used for the site a couple of times, but in the end I remember him concluding that the code wasn’t really in a release worthy state and that he didn’t have the time or the interest to clean it up in order to add yet another half-done publishing system the world.

While we all where strong supporters of free software none of us had any problems with this decission. Part of the reason for that is that releasing the code of something doesn’t automatically make it useful for people. In fact it may only be a distraction as you get more useless crap showing up on google when you are trying to find something.

For the release of sourcecode to be truly useful the code needs to be in a state where its been prepared for consumption by anyone else than the original creator. Getting hold of a source package that do not compile or run cause you don’t have access to the 7 post-it notes with manual instructions, the 19 steps only stored in the memory of the creator and is using some database tables you don’t have an sql script to create tend to be of abysmally little value.

A lot of source code is written by one or two persons for their own private or professional use. Code written like that is often using a lot of shortcuts to achieve its tasks, like hardcoding values, no code comments, no documentation, no real build system, relying on a database structure thats been created manually and incrementally over a period of time and so on. Thus sending that code out there doesn’t make it instantly useful. So unless your application is truly special nobody will probably ever bothering spending the weeks or months it would take to make it useful to themselves or the even longer period it would take to make it useful to the world at large.

That said there are of course cases where even such code could be useful, for instance if the code documents a certain piece of hardware or fileformat. But once again it would require the code to actually correctly document the hardware or fileformat in question, sending out a file called nvidia-driver.tar.gz which contains a driver you tried to make by trial and error, but which never did anything apart from cause 4 of your graphics card to stop working permanently is probably not doing anyone any favours. At least not without a lot of code comments and a big warning.

Which brings me a back to trying to pressure someone to open source something. In many cases unless the person asked to release some code wants to release the code to the world and thus is willing to take the time and effort to make sure the world would truly be able to use the code then getting the code released would probably be of little or no value. In fact it might just be adding to the noise making googling for actually useful code a little harder.

So in terms of Launchpad. I am sure it could be a useful tool for various people or groups if released, but release means more than doing ‘tar -cvf lp.tar /var/www/’. Thus unless one can convince Canonical that there is true value for them in spending the time and the money to prepare LP for a release and maintaining that release as a public project, then all achieved is probably getting a big tarball of useless crud put onto the net and at the same time have wasted developer time on an effort of little value.

In the meantime maybe effort should instead be spent on improving existing projects already available which has a featureset similar or close to what Launchpad offers.

Feelgood stuff

I guess we all sometimes feel burned out by the goings of the free software community. Endless discussions about the technical superiority of one solution over another, a feeling of the community sometimes being overly narrow in its view of the world beyond or the amount of negative feedback tending to heavily outnumbering the good or dealing with licensing issues might all be things that steal energy. Yes, there are many reasons for sometimes wanting to throw in the towel and look for both work and entertainment a different sector of society.

Yet many of us have stuck around for quite a long time now and I guess there are many reasons for it, like good friends, jobs, professional pride and so on. Another burst of energy comes from the times when you see free software having a positive impact on people’s life, like when Wingo showed me how they had deployed Linux at schools across Namibia. But it doesn’t need to be as big as that, today for instance it put a smile on my face seing a mail from someone who had been using the Flumotion streaming server to let family members living remotely take part in the Christmas festivities at their family home. Not exactly a use that changes the way of the world, but it did give me a sense of joy seing someone being able to use our technology in a way that enriched their lives. Thanks for sharing that.

GNOME plans for the future

Noticed some tiny disturbance in the force before Christmas as
Thom Holwerda of osnews
posted an article about what he felt was the sorry state of free desktops. Seems most people in the GNOME camp simply ignored the article as irrelevant, but Aaron Segio of Trolltech and KDE let it somewhat get to him.

Personally I felt Thom kinda pointed out some troublesome points, but that his context and conclusion was wrong.

First of all he critized GNOME for not having a clear vision for GNOME 3. Well this is true, but that is mostly due to not having any clear ideas for something that would require a GNOME 3. GNOME 2 came about as a result of shortcomings in GTK+ at the time, causing the GTK+ maintainers having to break API compatability in order to improve for instance the handling various writing languages and fonts.

As part of having to port to the new GTK+ some policy changes where made for GNOME in terms of focus and goals. Goals and policies which people are still very happy with and don’t see a big need to change.

At the moment GNOME is doing quite well with incremental improvements with a lot of the major effort by GNOME contributors and companies going into projects such as HAL, X.org, Cairo, NetworkManager, GStreamer, Telepathy, OpenOffice, Firefox and Bluetooth support to mention a few. The thinking being that having a full featured office suite for instance is more important to potential users than having a panel that can be themed to have the shape of a sextant. At the same time the core parts of GNOME are continously moving forward with incremental improvements or replacements.

Why GNOME’s incremental approach is considered less by Thom than Apple’s is not clear to me, but for some reason he feels that unless you put a major version number behind something in the linux world you by definition stand still.

And to be honest incremental improvements is what everyone is doing these days. Windows Vista, MacOSX and KDE4 don’t really contain anything earth shattering, they are basically increamental improvements over the predecessors. Thom mentiones KDE’s Plasma, Appeal and Solid in his article as KDE4 efforts. Aasegio mentioned Phonon and Decibel as other examples. Well if you look at each of them, none of them are actually doing anything ‘new’, they are all just attempts at trying to do what is already being done, but in what each project maintainer feel is a better way. Which is just the same as how GNOME currently increments forward, although since GTK+ is not breaking API the need/motivation to call it GNOME3 is not very big. The excitement around Compiz recently showed how more glitz can be brought to the desktop as an incremental improvement.

The thing is that until we find a new way to interact with our desktops, nobody will be doing anything truly significantly new anytime soon, apart from maybe in the application space.

And to give an example of what I am talking of I want to point to the Nintendo Wii as a device which actually is doing something ‘new’. While parts of the technology has been around for quite a while the way the Wii controler works do truly change the way you interact with the system (making it much for physical for one) as compared to previous and competing consoles.

On the desktop space I think doing something I feel deserve the title ‘new’ will be harder, but I think the Lowfat experiement of Mirco has the potential. And if it pans out it might become the foundation and focus of a GNOME 3 cycle. But with all such experimental efforts we can’t commit to it before the proof of concept has reached a bit further so we know we can accomodate all the major usecases. And maybe in the end it will end up being more like what we at Fluendo try to do with Elisa, making it a add-on to the current desktop/system for a specific usecase rather than a full desktop replacement. Yet using many of the same building blocks as the desktop.

So while both GNOME and KDE could do with more developers I don’t see any truly dark clouds on the horizon. And if Thom or anyone else have any clear ideas on something that would require GNOME to change so many of its internals to justify switching the major version number to 3, then please come with them. In the meantime lets just continue incrementing our way towards perfection within the constraints of the current paradigm :)

The Failure to Enjoy Terry Pratchett

For many years I have heard people I know, and whom I think tend to have similar taste to myself, say how funny the Discworld novells by Terry Pratchett are. Due to this I have multiple times tried picking up ‘The Color of Magic’ hoping to find it very funny. Instead each time I find the book extremely dull and boring. Neither creating ‘funny’ setence-words from the phonetics of the words like insurance or economics or a world whose concepts tries to be funny by outdoing absurdity itself really ever get me to laugh, hardly even smile.

So I guess Terry Prachett will continue to be an undiscovered ‘gem’ for me.

Jokosher on Solaris

Thanks to our friends at Sun we have a SPARC box running Solaris in the office which we use for various development. Yesterday Jan was trying to figure out why gst-python had problems under Solaris. This patch and the problem was solved so Jan moved on to trying to run Jokosher on Solaris. The application started, but Jan was not able to to get it to do much. What hindering Jokosher on Solaris seems to have two major components, one was our Solaris install lacking HAL which Jokosher needs and which newer versions of Solaris has, the other was some hardcodings of the GStreamer ALSA plugin in Jokosher. Jokosher switching to autoaudiosink should solve part of that and if we put together an autoaudiosrc plugin Jokosher should in theory be able to run well under Solaris also. Anyway if we manage to have Jokosher work without any changes on both Solaris and Linux there should be nothing stopping us from getting it running under Windows and MacOS X as well without further changes (apart from audio source plugins for GStreamer for those architectures). An audiosrc plugin is incoming from Sebastian Moutte soon so maybe Jokosher 0.3 will be available for both Linux, Solaris and Windows.

The Magic Lamp of Standardization

Just saw an article on whats up next in Linux desktop standardization where there is blurb talking about the discussion at the latest ODSL Desktop Architects Meeting about the issues around Linux Audio (or multimedia in general if you want).

The final outcome was this: It was decided to start addressing these issues by creating a focus group and mailing a list of what’s needed from audio APIs, and how to deal with bringing consistency to Linux audio.

Which is exactly the kind of outcome a conference like this can ever hope to achieve and which also shows why it is a complete waste of time trying to address the issue in such a forum.

The DAM meetings are set up as a ‘lets get everyone together to see if we can find common ground’ type of meeting. Which isn’t bad, but it only lends itself to a certain type of problems.

The problem with Linux audio is not that people out there do not ‘know’ what the problem is, the problem is that people disagree, often quite strongly on how to solve it, and that there is limited resources available for solving it using any solution. So instead of actually moving towards solving it we get a lot of cute discussions on related topics such as when to push and when to pull as one example.

To solve the problems mentioned in the article you will need to step on some toes, sink a lot of man hours into the chosen solution and in the end win out on excellence. Which surprisingly is a bit harder than one would think :)

I think the ODSL-DAM context fails horribly already on the first hurdle, in the sense that the DAM conference is not set up to do any kind of toe stepping, rather to the contrary. Not that I am saying that the DAM type meetings are useless, not at all, but a format made for trying to increase cooperation between two quite mature and well established solutions like GNOME and KDE doesn’t necessarily lend itself well to a problem requiring some painful trailblazing.

That said I do think the problems are being addressed, but they are not and will not be addressed by things like ODSL DAM, instead they are being addressed by individual developers, contributing companies and distributions who are already all moving in mostly the same direction. The thing is however that for the contexts these people and groups are moving something like DAM is more of a distraction than a valuable contribution towards the end goal at this point in time.

To let on where I see things moving based on what the distro’s are doing I will say that on the audio side the solution that is gaining traction is PulseAudio which will be run on top of ALSA and providing legacy support for ESD and OSS. For the codec problem there are solutions being worked on around GStreamer.

Within the context of these technologies and some other technologies that comes as a consequence around them also longer term plans are made for addressing the issues faced. For instance making sure that Pulse Audio is an acceptable solution for both people doing so called pro-audio and for the normal desktop, like it is on MacOSX.

Blog talking about Fedora, GNOME, GStreamer and related topics

css.php

Bad Behavior has blocked 703 access attempts in the last 7 days.