SPO600 - And now the package picking begins

So it seems I've landed myself lightspark, a free, open source Flash alternative and mediatomb, a plug and play media streaming app.

Media Tomb, which did not take an arm (ahem..) and a leg to get the source files for, uses assembly in two places that I can see, and they don't seem to be used elsewhere in the program at all (or at least outside of documentation).

The assembley is inline and looks a bit like this:
#ifdef ATOMIC_X86_SMP
    #ifdef ATOMIC_X86
        #error ATOMIC_X86_SMP and ATOMIC_X86 are defined at the same time!
    #endif
    #define ASM_LOCK "lock; "
#endif

#ifdef ATOMIC_X86
    #define ASM_LOCK
#endif

#if defined(ATOMIC_X86_SMP) || defined(ATOMIC_X86)
    #define ATOMIC_DEFINED
    static inline void atomic_inc(mt_atomic_t *at)
    {
        __asm__ __volatile__(
            ASM_LOCK "incl %0"
            :"=m" (at->x)
            :"m" (at->x)
            :"cc"
        );
    }

If I'm reading this correctly, and there is a big chance I'm not, it's saying 'use this assembly only if you're using an x86 processor', otherwise, don't (more or less).

Lightspark however, has a lot more assembly for x86 working with video files, Chris and I looked at this, and determined that it had nearly 120 lines of the stuff and not only that, it uses NASM, an x86-only assembly compiler. However, it also appears that it should be rather straight forward to at least attempt to port to aarch64 assembly, if not try to get some C variations in there. Or at least see if there are C falls backs for that (I don't have the Lightspark code in front of me, so excuse the lack of examples for it.

Media Tomb should be a lot less work in terms of practical coding, Lightspark will likely take more time, but we'll see if the work is doable in the timeframe for this project.

I will be honest, I chose these two, for now at least, because they were both 0 on our list, and I didn't want to stray too far from my comfort zone,Lightspark is a flash alternative, and that is ALWAYS a plus in my mind. The less adobe I can put on a machine of any kind, the better. And a small media server app that isn't XBMC is good too, since somehow that thing has become all-pervasive. If Lightspark ends up being too much work, I may end up passing on it and moving on to a new package.

SPO600 Lab1 - Licenses

SPO600 Lab 1 - Linux Package Licensing

SPO600's first lab looks at two different Linux packages and the license agreements involved with open source software.

Firstly, looking at Audacious, a Linux audio player, which uses the GPL3 license, which is, from their website (and within the application itself), almost impossible to find on its own - Google search to the rescue it seems. The project uses a Redmine-based bug tracking system to track and submit patches/etc, and most patch implementations take anywhere from a few hours to a few months, depending on the size and severity of the problem, and from the look of things, involves the person submitting the bug/patch, and a project manager, with occasional bugs involving up to 3 or 4 people discussing an issue, but always the same project manager in the end. It seems that such a small team doesn’t require much more than a simple bug tracking system, limiting the team members responsible for implementing/upstreaming changes to repositories and keeping them in direct contact with their community. This of course also has the knock on effect that bug fixes may not always be timely, since it appears that one or two people may be doing that whole process.

Another package, x11-common, is part of the X Windows system for linux/unix distributions and uses the Mozilla-based Bugzilla bug tracking system. It’s uses a variation of the MIT license (the X11 License). As the entire X Windows system is run by an educational non-profit foundation with a dedicated board of directors, and other contributors, the team’s involvement is much less direct than a smaller team like Audacious. As such, it makes sense that they’d use a Bugzilla tracking system which is feature rich but decentralized, as the x11-common package is but one part of the larger X Windows project. Larger team means more people are able to look at and fix bugs in a more timely manner, but also makes things a bit more faceless, unless one is intimately involved with the project.

A new blog for a new course [two even!], OOP344 and SPO600. It'll probably be just blank text for a while, until I feel like mocking up templates.

Until then, lots of programming talk. C++, Assembler, and so forth in ugly plain text.