Planet Larry

How to Create Self-Signed SSL Certificates (Part 1)

How to Create Self-Signed SSL Certificates (Part 1 of 3)

nvidia, opengl, compositing: play nice!

"Fixed a bug that caused extremely slow rendering of OpenGL applications on X screens other than screen 0 when using a compositing manager."

How to Install Cygwin

2 monitor radeon xorg.conf

PHP segfaulting with pecl/uuid and pecl/imagick

Ran into a bug yesterday, where http://pecl.php.net/uuid in combination with http://pecl.php.net/imagick yielded a segfault when using uuid_create(). GDB backtrace looks like this (without the exact place where it happens in libuuid, as there is unfortunatly no libuuid1-dbg-package in current Ubuntu versions):

gdb --silent --ex run --args php -r "var_dump(uuid_create());"
#0  0xb6e85321 in ?? () from /lib/libuuid.so.1
#1  0xb6e862bf in uuid_generate () from /lib/libuuid.so.1
#2  0xb6bcc67a in zif_uuid_create (ht=0, return_value=0xbffff1e8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /usr/src/pecl-uuid-trunk/uuid.c:182
#3  0x0835d26a in zend_do_fcall_common_helper_SPEC (execute_data=0x894ed4c) at /build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
#4  0x08333d8e in execute (op_array=0x891c464) at /build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104
#5  0x082fe283 in zend_eval_stringl (str=0xbffff998 "var_dump(uuid_create());", str_len=24, retval_ptr=0x0, string_name=0x871f2fc "Command line code")
    at /build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1172
#6  0x082fe422 in zend_eval_stringl_ex (str=0xbffff998 "var_dump(uuid_create());", str_len=24, retval_ptr=0x0, string_name=0x871f2fc "Command line code", handle_exceptions=1)
    at /build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1214
#7  0x082fe4a3 in zend_eval_string_ex (str=0xbffff998 "var_dump(uuid_create());", retval_ptr=0x0, string_name=0x871f2fc "Command line code", handle_exceptions=1)
    at /build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1225
#8  0x083a0579 in main (argc=3, argv=0xbffff854) at /build/buildd/php5-5.3.2/sapi/cli/php_cli.c:1235

The interesting thing is, the crash happens in libuuid, but only if imagick is enabled. Let’s see what Valgrind says:

valgrind -q  php -r "var_dump(uuid_create());"
==25103== Invalid write of size 2
==25103==    at 0x5517321: ??? (in /lib/libuuid.so.1.3.0)
==25103==    by 0x55182BE: uuid_generate (in /lib/libuuid.so.1.3.0)
==25103==    by 0x57D0679: zif_uuid_create (uuid.c:182)
==25103==    by 0x835D269: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25103==    by 0x8333D8D: execute (/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104)
==25103==    by 0x82FE282: zend_eval_stringl (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1172)
==25103==    by 0x82FE421: zend_eval_stringl_ex (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1214)
==25103==    by 0x82FE4A2: zend_eval_string_ex (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1225)
==25103==    by 0x83A0578: main (/build/buildd/php5-5.3.2/sapi/cli/php_cli.c:1235)
==25103==  Address 0x30 is not stack'd, malloc'd or (recently) free'd
==25103== 
==25103== 
==25103== Process terminating with default action of signal 11 (SIGSEGV)
==25103==  Access not within mapped region at address 0x30
==25103==    at 0x5517321: ??? (in /lib/libuuid.so.1.3.0)
==25103==    by 0x55182BE: uuid_generate (in /lib/libuuid.so.1.3.0)
==25103==    by 0x57D0679: zif_uuid_create (uuid.c:182)
==25103==    by 0x835D269: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25103==    by 0x8333D8D: execute (/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104)
==25103==    by 0x82FE282: zend_eval_stringl (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1172)
==25103==    by 0x82FE421: zend_eval_stringl_ex (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1214)
==25103==    by 0x82FE4A2: zend_eval_string_ex (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1225)
==25103==    by 0x83A0578: main (/build/buildd/php5-5.3.2/sapi/cli/php_cli.c:1235)
==25103==  If you believe this happened as a result of a stack
==25103==  overflow in your program's main thread (unlikely but
==25103==  possible), you can try to increase the size of the
==25103==  main thread stack using the --main-stacksize= flag.
==25103==  The main thread stack size used in this run was 8388608.
Segmentation fault

Not really any more helpful. After two hours debugging the issue with the help of Mikko and Pierre we found out, that pecl/imagick is linked against libuuid too:

ldd /usr/lib/php5/20090626+lfs/imagick.so
    (...)
    libuuid.so.1 => /lib/libuuid.so.1 (0xb7086000)
    (...)

For whatever reason this is happening, this is most likely the root cause of the issue.

Solution (sort of)

pecl/uuid was loaded by /etc/php5/conf.d/uuid.ini and pecl/imagick by /etc/php5/conf.d/imagick.ini. As they are loaded in there alphabetical order, imagick initialized before uuid. Renaming /etc/php5/conf.d/uuid.ini to /etc/php5/conf.d/00-uuid.ini fixed the issue, as uuid is than initialized before imagick and the segmentation fault was gone.
Not sure about that, but maybe it would be a good idea to check in PHP_MINIT(uuid) in pecl/uuid if pecl/imagick has been initialized before and warn the user about it?

Paludis 0.54.3 Released

Paludis 0.54.3 has been released:

• split debug now works correctly again.
• IDs for repositories will now exist but be masked in their origin repository when a repository is already configured.
• New –graph-jobs option for ‘cave resolve’.
• ‘cave execute-resolution’ no longer shows (no output for x seconds) messages when only one job is active.
• The option descriptions for ‘cave import –preserve-work’ now match what the option values do.
• ‘cave purge’ will now error if given parameters, since it does not do anything with them.

Walkthrough of a CSS3 website design slice.

Slicing is a sign of a terrible golfer. Slicing is also the process of cutting up an image design into smaller images and writing markup code to turn it into a living, breathing website. I recently got a request from a friend to slice their portfolio website. Here is the original design he sent to me (and dumped on WIPUP as well).

It is a fixed width, fixed height website design. Technically speaking, it’s a rather simple design. Most website frontend coders would just launch right into slicing, but this time I wanted to have some fun. I wanted the freedom that any slicer and designer yearns towards – perfect separation between presentation and content, and complete disregard for browser compatibility.

Yes, if you haven’t already guessed, I built this site with CSS3. The only images I used in the end were the green background image, and the splash screen background image (oh, and the leaf icons for the navigation, but those don’t really count).

Most of the layout was straightforward using things like the new border-radius and box-shadow tags. However the lump in the navigation bar posed some complications. In the end I was able to recreate it using a three-layered solution (via the z-index tag). The first layer held the navigation strip with shadow effects. The second (above first) layer created the lump in the navigation’s shape and shadow. A third layer mimicked the second except with a slightly decreased width, slightly offset at the top and a shadow of the same colour as the background to create a "fading" effect for the shadow on the sides. With position: relative, and offsetting to place them, I managed to recreate the effect pretty darn well, if I might say so myself.

Finally, I used Google’s Font API to choose a more appropriate font, applied text-shadows (with a different colour in my a:hover tags to create a nice glow effect) and stuck it up online for my friend to see. Here’s the result (output via Gecko renderer):

This multi-tab bar is a common webdesign element, so this trick might help other CSS3-yearning developers. Here’s the code for those who are interested. The design works in Firefox, Opera, and Safari. Chrome does not render rounded shadows correctly but otherwise works fine. It fails with IE8 and below. Haven’t tested IE9.

Related posts:

1. Countdown to KDE 4.4 and the new KDE website: 5 days left
2. Countdown to KDE 4.4 and the new KDE website
3. Countdown to KDE 4.4 and the new KDE website: 3 days left

Linux Sea last content chapter

The last chapter in Linux Sea focuses on Using A Shell. This seems to me like a nice last chapter, as it confronts the user with the exciting world of shell scripts. I hope that the chapters in the book are sufficiently stuffed so that beginners (who are not afraid to learn) can more easily start off with (Gentoo) Linux. Of course, this is just the beginning. The existing content needs to be sharpened, extended where needed, updated, etc. so expect a few updates coming along!

Falcon Programming Language Mirror on GitHub

I have decided that to mirror the official Falcon PL git repository on GitHub. This should make it easier for everyone to watch or fork that don’t use Gitorious. Please note I am not competing with anyone here. It’s just not everyone uses Gitorious, and if you don’t use it, but use Github instead, the repository is still available to you for use.

So, please, watch me, fork me, etc.

http://github.com/steveno/falconpl

The Camp 2010: Slides

Just a short update: I have just uploaded the slides from the two talks I did at The Camp this year.

The first talk was a lightning talk about what is going on behind the scenes of a large IRC network as seen from an operator’s perspective. You probably won’t get much knowledge from the slides unless you were there.

The slides were made in Apple’s Keynote application and it’s absolutely horrible. I’m back on Beamer and LaTeX again.

The second talk was an introduction to Nokia’s Qt framework and how to write cross-platform GUI applications for both mobile devices and desktops (focus was on Linux and OS X only though). The presentation was followed up by a small workshop with roughly ten participants. We wrote a simple, yet functional, weather application that pulled weather data using Yahoo’s weather API and displayed it with fancy icons that changed dynamically depending on the current weather condition. It went really well and I believe that everyone who participated will now know how to get started with writing GUI applications using Qt.

Both slides are available from https://secure.0x90.dk/~ahf/talks/.

It was also great for me personally to try to do a workshop with a mixture of people with both coding experience and some with no coding experience at all. I hope that I will find opportunities to do this again in the near future. It was much more interesting than the regular presentations that I have done over the past years.

I’ve also had to find some personal projects now that I’m a full time coding monkey. Right now they includes a Qt “social” library that implements stuff like OAuth, the Twitter API, the Facebook API and so forth. I’m going to put it online under a two-clause BSD license when I feel like it’s ready for public review.

And yes, I know. I should stop spending time on this social bullshit and start working on some useful stuff, but hey, it’s interesting and I’ll probably get back to some of the much more serious IRC related projects soon’ish.

I have also been looking into what I can do on the iPad device, but currently it’s purely something I use on the train on my way to and from work every day. I’d guess that 80% of the uptime of the device is spend on Angry Birds and Amazon’s Kindle application. Both are nice applications and I hope that I’ll never have to order books made of paper again. I used to hate ebooks, but reading on the iPad seems to work and it doesn’t annoy me too much. Also, it’s lovely to have your entire bookshelf with you in your bag. I hope to try one of Amazon’s dedicated Kindle devices at some point. I can imagine it’s better at displaying text than the iPad.

Final note: I’ve joined BSD-dk’s board of trustees. It’ll be interesting to see what we can do there over the next year.

I hope that everyone has had an interesting summer.

devops – how hard can it/it can be

Dieter made a good reference to devops and the open source community and (correctly) points out that, even in a more collaborative scene such as the free software communities’, there is still distinction between development and operations. And it isn’t hard to see commonalities between enterprise organizations and free software communities in that respect.

But is the comparison correct? If you look at a distribution as an enterprise, then surely the distinction between upstream (project development) and “downstream” (distribution) should be compared with the relations between an enterprise and its ISVs, not its internal development / operational divisions. If we look at internal divisions, then distributions tend to provide better integration between (internal) projects and the distribution. I cannot talk for every distribution, but in those I do know, the infrastructure team (“operations”) has a firm grip on the infrastructure, yet leaves out sufficient space for development to do their releases/production activity: uploading files, changing documentation, …

This works, if the provided interface does not allow for developers to harm the principles that infrastructure has. This is what many (enterprise) organizations are still lacking, but there is no simple solution for this. Often, the operations team has principles that are difficult to match with the goals of development. Finding the correct balance between development and operations in that respect is quite a challenge – usually, free software communities can get there faster, often because their mass is sufficiently low. With a total ‘employee’ count of a few hundreds it is statistically easier to find a balance than within enterprises of a few thousand employees.

I believe that both teams should write down their principles, policies and standards, and see if they can find matches (which is good) and mutually exclusive distinctions (which is challenging) where more investigation can be done. Both teams should be allowed to question decisions made by the other (but without pretending to know better) and make suggestions. This should lead to the emergence of interfaces where a team has sufficient freedom to get to their own goals autonomously.

With such interfaces, people will start thinking that devops is growing apart (after all, they’re starting to work autonomously and independently of each other). That isn’t true. In my opinion, devops is about interacting on a high level (which is less time-delimited) so that interactions on a low level (which is very time-limited and focused on releasing, releasing, releasing) aren’t necessary. Less interaction means that the teams that are responsible for getting to a specific, short time-framed goal, can cooperate closely and have a better grip on resources and requirements.

What the open source community can learn from Devops

Being active as both a developer and ops person in the professional life, and both an open source developer and packager in my spare time, I noticed some common ground between both worlds, and I think the open source community can learn from the Devops movement which is solving problems in the professional tech world.

For the sake of getting a point across, I'll simplify some things.

First, a crash course on Devops...

A commonly used organisatorial idiom used in tech companies is that of developers and operations.

Developers:

• develop a product
• improve their product based on feedback from production usage

Operations:

• put the product in production, making it available for users/customers
• give feedback to devs

Experience shows this model often falls short. 'Dev' and 'Ops' being too artificially separated from each other, resulting in improper communication, clashing procedures and tools,
resulting in devs disliking ops ("we need to push this out to users, ops are holding us back"), and the other way around ("again new code that will cause trouble, and we will have to figure it out")
It doesn't take a genius to see this is pretty ineffective. There's a better way: integrating and reconciling dev and ops, so that all involved know the hard parts of each others' jobs, and in fact letting each other do the others' job. (developers being responsible for their own checkouts, ops working on the code, etc). Most of all it's about culture over processes. About being smart and nice human beings.
The exact methods are still being experimented with and preached about, and has recently gotten the name "Devops".
There is a really good Devops explanation online, with more details. Read it.

Often enough we're talking about teams working for the same company, usually under the same roof, so it isn't too terribly hard to implement these ideas.

Now, let's look at the open source community

Open source developers ("upstream"):

• develop stuff
• improve their stuff based on feedback from end users

Distributions ("downstream"):

• package stuff and make it available to end users
• get bugreports, which often get forwarded to upstream

Looks familiar?

The problems are similar too...

Like above, the problems stem from both parties not working together enough, and doing things on their own.

Some upstreams:

• like to use "weird" (home grown) build systems
• violate FHS
• use home grown packaging systems. Languages and applications with plugins like to do this
• mix bugfixes, security patches and feature additions in the same code branch (often there is not enough manpower to maintain them in separation, and the need for it is dependent on how/when downstreams ship it anyway)
• run into the chicken/egg problem: they need to release software to have it shipped and tested, but it should only be released after being properly tested. ("Release early, release often" alleviates this, but it's not always that easy)

..making it hard for downstreams.
Even for each other: unannounced/frequent API changes come to mind.

Dowstreams, often:

• Lack discipline and/or tools to properly report back to upstream. Users don't like te report the same issue on two bugtrackers
• Have to make hard choices. Not shipping software at all or patching beyond recognition, often enough without knowing how the software really works or is implemented.
• Don't contribute patches back to upstream. Posting them on some obscure albeit "public" mailing list or code archive isn't the most effective either. Patches that are sent back often don't get merged, making it hard for other downstreams to find them. (and hence, they work on their own patches)

Nothing pleases an upstream more then complaints from end users running into problems that only happen witch patches applied by the distributor (patches that are deemed necessary to make the app work properly in the distro. The irony..)

Some distributions focus on shipping "only stable software", causing them to be obsolete by definition. (Time to production often extends in the order of years), and are forced to apply so many patches that they are essentially forking their upstreams. Add poor feedback loops to the list and the situation is about as ineffecient as it can get.
Other distributions limit their role to giving you the real open source software experience in it's current state, and that state is not always pretty.

but they are much harder to solve

• Upstream and downstream are separated much more, resulting in very little communication between both parties. So the incompatibilities manifest themselves even harder.
• Among distributions, there are very different visions on and implementations of tools and processes. Pretty much each distro has a vision which separates it from the others.
  Among upstreams, there are as well some different ideas on how things should be done. Luckily enough upstream developers agree on some things. But there are some "clusters" doing things their - often radically different - way (freedesktop.org and suckless.org come to mind)
  The amount of incompatibilities is pretty much the carthesian product of the amount of distributions with the amount of "different visions" among upstreams
• Despite their differences, some upstreams and downstreams actually do have some common ground, but as they don't involve each other in tools nor processes, they hardly benefit from each other

So, in contrast to popular belief, open source is not a magical wonderland where everyone works nicely together.

Tech companies are usually on their way if they understand and can introduce agile and devops, but I think in the open source ecosystem it's much harder to bring unity.

Luckily, some smart people are already working on bridging the gap between up- and downstream, and between each other.
some examples:

• transifex.net provides a common translation infrastructure and service
• launchpad.net provides code hosting and cross-project issue tracking (from what I heard, tickets reported for downstreams can easily be linked to the relevant upstream project. But I never tried it)

I also think about Fosdem's cross-distro miniconf and the freedesktop.org project, which encourage closer cooperation between different downstreams and desktop projects, respectively.

So, how can we solve this? How can we maximize the end-user experience with more efficient communication and tools?
Some ideas I have:

• upstreams should definitely abandon cvs and svn. And avoid using no version control. Use a version control system that makes forking and contributing more easy, like git. Downstreams can then fork all the repos and apply the patches in a separate branch. It will improve cooperation between up- and downstream
• upstreams: try to be compatible with how your downstreams and end-users want to use your software. Accept patches that add configure flags to enable/disable support for the xdg basedir spec, for example. You don't need to put them in your master branch.
• Provide the source for each release so that it can easily be fetched and checksummed
• upstreams should definitely avoid coming up with their own "package management" or "self upgrade" solutions. Let downstream do their job and make your software compatible with existing packaging solutions
• use common build systems. Provide makefiles with an install and uninstall target. Don't violate FHS. Make sure your Makefile and software easily allows using a different prefix. I even do this for repo's that contain 1 or 2 shell scripts. (example)
• Ideally, we would have something like git, but for issue tracking. Everyone could still host their own issue tracker, but integration between up- and downstream could become much more efficient
• talk to each other, brainstorm. we can make everyone's life easier

I don't think we should try to go much beyond some common infrastructure/tools and some best practices. People will always have different opinions on how things should be done. And that's a good thing, it's the very definiton of the open source community: scratch your own itch.

What do you think?

Linux Sea: log file management and backups

I’ve added two more chapters to the Linux Sea book. The first one is about Log file management, the second one about Taking Backups. They’re far from finished, but I thought that those two topics are important for day-to-day Gentoo usage and shouldn’t be left out of the Linux Sea saga.

Exherbo Repository Update

I have updated the exheres for the Go Programming Language. Hopefully it will work now. It’s the first one I’ve written from scratch so odds are it won’t work.

I have also started, but not finished, an exheres for LDC. A D programming language compiler. It’s actually part of LLVM. Either way it’s all here:

http://github.com/steveno/exheres

Patches are recommended!

cvechecker 0.5 released

A new intermediate release of cvechecker is now released. The tool is reported to build properly on NetBSD and FreeBSD as well (although much user experience there is still welcome), introduces a cvereport command (example output), has lowered its initial dependency requirements and pullcves now only loads the CVE XML changes in the database, rather than iterating across all CVE XML entries.

Many thanks to Nigel Horne for his continuous testing/hammering on the tool.

Lazyweb: Simple GNOME backup solution

Dear lazyweb, I’m currently looking for a simple GUI-based (GTK) backup solution. A view key requirements:

• I want to back up to a USB drive and want a graphical reminder in case it’s not plugged in
• I want to back my $HOME dir into an encrypted archive
• My /etc and a few other files are to be backed up in a different, non-encrypted archive
• I’d like to keep around a few iterations
• Simple restauration of a whole image or single files from the backup.

Suggestions?

Tech tip #8: Browse Amarok’s embedded MySQL database.

Amarok can probably be called one of Linux’s flagship programs. However since the upgrade from Amarok 1 to Amarok 2 there have been quite a number of controversial changes. One of these changes is that Amarok switched from an SQLite database to a MySQL database to store song information, however whether or not this was the right move is not the topic of this post (why yes, it was a good move, thanks for asking).

With this new database, users were given two choices – an external database or an embedded database. The embedded database was created to simplify the setup for users who weren’t comfortable with the idea of manually setting up a MySQL database. But what happens if you have an embedded database and afterwards you do want to mess around with it and look inside? For whatever purpose be it bugfixing, locating a specific bit of information, or bulk song management (nothing beats a good query!), sometimes you’d want to do this.

Amarok stores its embedded database information in $KDEHOME/share/apps/amarok/mysqle/amarok/ – where $KDEHOME is usually ~/.kde. So as long as you have MySQL setup elsewhere, all you have to do is create a blank database, and dump all of these files where MySQL stores its information. This location is MySQL’s datadir, which is set inside the my.cnf configuration file, normally placed in /etc/mysql/my.cnf. In a regular install, your data dir will be in /var/lib/mysql/ – and will contain one directory per database. So just copy over Amarok’s database files into the database’s directory. The final step is to ensure the files are owned by the mysql user, done by chown mysql:mysql.

Now you can browse the database normally through your preferred method (command line, PHPMyAdmin, or other MySQL client)

That’s it! I hope this is useful to somebody.

Related posts:

1. Tech tip #4: Copy a random set of files from a directory.
2. Tech Tip #5: Rotate a video by 90 degrees with mencoder
3. Playing a song as a background process in Windows

Tech tip #7: Browse Amarok’s embedded MySQL database.

Amarok can probably be called one of Linux’s flagship programs. However since the upgrade from Amarok 1 to Amarok 2 there have been quite a number of controversial changes. One of these changes is that Amarok switched from an SQLite database to a MySQL database to store song information, however whether or not this was the right move is not the topic of this post (why yes, it was a good move, thanks for asking).

With this new database, users were given two choices – an external database or an embedded database. The embedded database was created to simplify the setup for users who weren’t comfortable with the idea of manually setting up a MySQL database. But what happens if you have an embedded database and afterwards you do want to mess around with it and look inside? For whatever purpose be it bugfixing, locating a specific bit of information, or bulk song management (nothing beats a good query!), sometimes you’d want to do this.

Amarok stores its embedded database information in $KDEHOME/share/apps/amarok/mysqle/amarok/ – where $KDEHOME is usually ~/.kde. So as long as you have MySQL setup elsewhere, all you have to do is create a blank database, and dump all of these files where MySQL stores its information. This location is MySQL’s datadir, which is set inside the my.cnf configuration file, normally placed in /etc/mysql/my.cnf. In a regular install, your data dir will be in /var/lib/mysql/ – and will contain one directory per database. So just copy over Amarok’s database files into the database’s directory. The final step is to ensure the files are owned by the mysql user, done by chown mysql:mysql.

Now you can browse the database normally through your preferred method (command line, PHPMyAdmin, or other MySQL client)

That’s it! I hope this is useful to somebody.

Related posts:

1. Tech tip #4: Copy a random set of files from a directory.
2. Tech Tip #5: Rotate a video by 90 degrees with mencoder
3. Playing a song as a background process in Windows

Ogg-seeding bovines and ease of use

Every time I see someone seed an Ogg/Vorbis album on Jamendo's trackers I get that urge to stretch my arms all through the wires and hug whomsoever is on the other side impersonated by that IP my BitTorrent client shows and shout through my monitor: "Thank you! Thank you for caring."

With that out of my system, let's focus on code. I promissed a while ago to write a KTorrent script to help share and seed free (i.e. mostly CC) music, but my work has been stalled by KTorrent not yet supplying the API calls I need. This doesn't mean nothing I'm doing nothing though!

What I did do so far is create a project on Gitorious^[1] to host it — Dashing Freemooina Cow^[2] — and as a subproject a small script called "moo-cow".

Dashing Freemooina Cow is part of a bigger plan to make sharing free music as easy as possible and will initially only handle Jamendo albums, but will be later expanded to any and all free netlabels I can find. I hope to add more advanced features like creating and uploading yet non-existing torrents to trackers and integration with Libre.FM as well.

But until I get my wish concerning the API, you'll have to make use of the spartan shell scrip that is moo-cow. To make use of the script, just download it and edit the MUSIC_DIR to point to where you keep (and seed!) your music; write Jamendo album ID's^[3] each in a sepratate line into album_list and run moo-cow.sh. I've already tested it on about 50 albums and it works!

...so, get the code, download your albums, share and seed to others and don't forget to be dashing! ;)

hook out >> sipping recycled tea and off to bed...

Vim :ruby and :rubydo scope

Note to self. In old Vim (tested in 7.2.320), I could do this:

:ruby x='foo'
:rubydo $_=x

Now every line in the file says foo. But in Vim 7.3 I get an error:

NameError: undefined local variable or method `x' for main:Object

The scoping rules for Ruby in Vim must have changed somewhere along the line. I was abusing this feature to do some handy things, so this is sad.

A workaround is to use global variables in Ruby instead. So this still works:

:ruby $x='foo'
:rubydo $_=$x

Phew.

Beware of warnings about default Apache2 config for PHP

Planet PHP recently popped up a post by Ilia with a warning about the configuration of PHP using AddHandler instead of AddType.

Now I’m all for people publshing warnings about security issues, but they really should at least read the official documentation to check their information first.

In this case, to summarise the documentation:

• AddHandler is used for server-side content handling – it associates a handler with the specified content
• AddType is used for determining the Content-Type in relation to the client request (ie. the default Content-Type identified to the browser)
• BOTH obey multiple extensions, but a response can only have one Content-Type while a file can be handled by multiple Handlers.

This means that while, when using AddType, “test.php.gif” no longer works, “test.php.something” will (assuming .something doesn’t have an associated Type), because .php is the last extension encountered which has an associated Type. So the so called “fix” doesn’t really fix the problem at all.

Additionally, when using AddType, instead of the default Content-Type being text/html, it becomes “application/x-httpd-php”, which is technically incorrect and may result in your website not being viewable in browsers or by search engine bots.

If you really want to make it so that only files ending with .php are handled by PHP, then you should use SetHandler instead of AddHandler. In fact, this is what the current official PHP documentation recommends.

qemu monitor cd change

I’ve been playing around with kvm (which uses qemu) to try out other operating systems and Linux distributions. Up until now, little progress on that part (not because it is difficult, just little time) but there are a few things worth mentioning. For this post, let’s start with a quicky on CD changes.

qemu’s integrated monitor is very nice and powerful. To go to the monitor from inside the vnc session, press Ctrl+Alt+2 (to go back, use Ctrl+Alt+1). Then you can query for attached hardware, add new devices, remove others, cpu’s, etc. Something I found necessary was to switch CD/DVD images. With info block I found the device. I then ran eject ide1-cd0 followed by change ide1-cd0 /path/to/new/image et voila, new CD available.

Getting SmartCard reader working under Gentoo and SSH authentication via OpenPGP

About two weeks ago I ordered a SmartCard reader and got it to work. It's really nifty and I now use I use my Fellowship OpenPGP/member card to sign (and encrypt) my e-mail and log via SSH.

Flameeyes has already reported how he got his working under Gentoo and in short my installation just partially deviates from it, but I'll add more how to chose and use it as well.

First things first — getting your hardware. You can safely skip the next paragraph and just pick one from this list.

In Slovenia we're not that hot on SmartCards, so anything else then ActivIdentity is pretty hard to get and for my taste those are too clunky. So what I did was call up the local importer Crea and was completely taken aback by the treatment I got! I know this sounds like an advertisement, but it's not. It's just that rarely never have I met such a competent and friendly service. Not only do they know about GNU/Linux, they test every model they sell on it as well, e-mailed me a bunch of useful links and even suggested a solution that I didn't think of before. This was a trully nice experience :]

Now that we got the HW it's time to set up the system. In my case I had GnuPG already installed and emerged just pcsc-lite and ccid. You need GnuPG for the obvious reason of handling the GPG/PGP keys and while it is reported that many OpenPGP card readers should work with pure GnuPG, for me this didn't prove the case. What I needed to do is to get PCSC-Lite middleware and the CCID driver. Note: USE="pcsc-lite" pulls in the ebuild for sys-apps/pcsc-lite, but you still need to emerge app-crypt/ccid yourself.

So here's the list of the ebuilds I used:

• sys-apps/pcsc-lite-1.6.1
  with USE="hal usb -static" (on HAL vs. USB flags: I have tried both and they both worked flawlessly)
• app-crypt/gnupg-2.0.15
  with USE="bzip2 ldap nls pcsc-lite smartcard -adns -caps -doc -openct -selinux -static" (if you set pcsc-lite Portage automatically pulls in sys-apps/pcsc-lite as a dependancy; no idea why there isn't a flag to do the same for app-crypt/ccid though)
• app-crypt/ccid-1.3.13-r1(because 1.3.11 doesn't compile)
  with USE="usb -twinserial"

Note that I had to pull in CCID from the testing branch because the stable didn't manage to compile, the other two are from stable branch. (Update: app-crypt/ccid-1.3.13-r1 is now stable) Also the installation method on other distributions varies of course and the PC/SC middleware package has some other names as well.

The most delicate part of course is getting the key(s) on the card. Probably the best HOWTO resides on Fellowship Wiki — I've followed it with just a few alterations, namely:

• take into account that you are using GnuPG 2.x, so you don't have to kill the agent while generating subkeys;
• the HOWTO presumes you already have a few keys, so don't be confused if there's a key extra which you don't have (e.g. the already existing auth key);
• adding an auth key to the OpenPGP card is not handled by the HOWTO and is done by the addcardkey command in the gpg --edit-key interface. Then when asked which kind of key, you just select Authentication key and you're almost set to log into SSH sessions with it!

If, as me (and Flameeyes), you get problems with gpg-agent and/or scdaemon not running (basically the most common problem), it's easily solved. In my case, I edited the /etc/kde/startup/agent-startup.sh file to include this loop:

if [ -x /usr/bin/gpg-agent ]; then
  eval "$(/usr/bin/gpg-agent --daemon --enable-ssh-support)"
fi

The good bit about it is that it works flawlessly throughout KDE and the whole X session — KMail, Dolphin, Kopete, etc. etc.; the caveat though is that if I want to use OpenPGP in a pure TTY (≠ terminal emulator) at the same time I have to kill gpg-agent and run that loop by hand in that TTY. If you happen to mix X with TTY often, you should try Flameeyes' solution with a wrapper. Our methods differ because one's better for one scenario and the other for another — chose whichever suits you better.

As a final treat — authenticating SSH sessions (i.e. logging via SSH with just your OpenPGP card), which is a most cool thing indeed, I followed Greve's instructions, which basically boil down to:

1. make sure you have created the authentication key on the OpenPGP card as explained above. To check that it's working run gpg --card-status and ssh-add -l and see if the Serial number of the first output matches with cardno. of the second;
2. run ssh-add -L to see the SSH public key(s) and copy the one which states the (right) cardno. entry;
3. log onto the server you wish to authenticate to with OpenPGP and paste the SSH public key into ~/.ssh/authorized_keys and there you are!
4. now log off the server and the next time you SSH to that server you'll be using your OpenPGP key and should at most be asked for your PIN.

This trick with OpenPGP authentication works also with Git over SSH, as e.g. used by Gitorious.

Big help provided by: bremner and others on #GnuPG; ph3-der-loewe, jhelwig and jg71 on #FSFEurope; thiago on #KDE and last but not least Flameeyes on his blog and via XMPP.

Flameeyes and me have already decided to update the Fellowship Wiki Card HOWTOs on this matter, but we've still to find time for it.

hook out >> sipping Ceylon Vanilla Bourbon tea and either hacking on moo-cow or studying ...will see
<!--break-->

Application design polish.

Free software is great. Everybody loves free stuff. However there’s one common flaw experienced by a lot of free software – they look ugly.

The reason behind this isn’t because we have too many programmers (yes, we know you never have enough programmers) and have too little artists – no, the problem is a lot more subtle. The real problem is that there is no clear hierachy within the artists. There is no control. There is no clear structure, focus, and branding. The question so many artists fail to ask ourselves as a contributor to free software is – What do we want to communicate?

To illustrate my point, I would like to use Ubuntu as an example. Regardless of your prejudices for the distribution and/or Canonical, they did do something right – they have a brand. They have a clear, recognisable pallette and style – from colourschemes to typefaces. Why don’t you see it for yourself: go and visit Ubuntu.com. Notice the colours. Notice the icon styles. Notice the typography.

Another example of a project taking the steps in the right direction is KDE and their Oxygen iconset + plasma "Air" attempt. However there is still far to go.

However the issue does not lie with such large FOSS projects such as the above mentioned. Instead the real problem lies with smaller software and application created by smaller developer groups. The reason is because these small applications rarely have to worry about problems such as branding – instead they have to focus on creating an elegant application. Design elegance can only rely so far on the design of widgets in the UI toolkit used. The rest is really up to the developer. Allow me to give a quick visual example of Blogilo, a blog client which I’m using to type out this post. Take a look:

The untrained eye would not see any problem with the screenshot – however the application design above screams complexity. There is no elegance. There is no simplicity – no "flow" (a clear step by step separation of functions). A blog client is not a complex application like an IDE. It exists for you to add, edit, and delete blog posts. Nothing more. When stripped down to its basics, a blog client is naught more but a rich text editor with a few extra options. Instead we have frames within frames, accordion panels, tabs, and buttons strewn about. Overkill, in my humble opinion.

Design polish is a very hard topic to separate what is ugly and what isn’t. It’s blends over into many neighbouring topics such as usability, a macro-view of marketing (in this case, Blogilo is part of KDE), and functionality. If you are interested, however, I would like to direct you to this very interesting blog by Troy Sobotka, one of the folks behind Ubuntu, who discusses this in much more clarity and detail than I am capable of.

Related posts:

1. thinkMoult blog design updated.
2. KDE.org relaunch with a brand new design!
3. Ubuntu 10.04 LTS (Lucid Lynx) – packed with goodies.