Saturday, September 17, 2011

Xfce desktop with kde apps - a mime issue

As an Xfce user, I sometimes still find myself grabbing the occasional Kde application.

Most of the time this desktop 'mix and match' works well.

However there is a mime type incompatibility/annoyance that might affect your opening of .doc files.

KDE and mime types:

Installing kdelibs5-data (just to satisfy a dependency) will bring in the following file:


and here is an issue...

The package libfile-mimeinfo-perl in Debian GNU / Linux will give you two utilities that can help you diagnose your issue:

  1. mimetype
  2. mimeopen
I am going to try mimeopen first and mimetype second, which seems like the roundabout way of doing things, but stay with me whilst I explain.

mimeopen --ask --database=/usr/share/mime yuck.doc

None of my three choices were correct - illustrates the problem nicely.

Now there is a search sequence for the mime information itself, and it is helpful to know whether the rogue setting, is in your personal user space or system wide.

There are two commands issued above (separated by a date just for easier reading).

What those two command together tell me is that it is not a personal (user) setting that is causing the issue.

( By specifying --database in the second command I ignore user specific database checking. )

None of this is actually fixing the issue, we are just diagnosing.

Just hacking around - not recommended :)

mv /usr/share/mime/packages/kde.xml /tmp/

and running mimetype and mimeopen showed no improvement :(

This is to be expected as you need to run update-mime-database to give your system a chance to react to the new situation.

The full command is as follows:

update-mime-database /usr/share/mime

and now mimeopen behaves as it should:

If you run a full KDE desktop then you are probably not going to be happy with losing kde.xml from /usr/share/mime/packages

However as an Xfce user, I probably do not care, and will just keep a copy lying around in case I really need it.

The comment in kde.xml reads...

As discussed on xdg list, *.doc is needed here for disambiguation

However I think if this 'catch all' is to work as intended, somebody needs to give a bit more though to magic / priority so that the correct program is opened in all situations.

Notes and Further reading:

Sunday, September 11, 2011

google API - command line access to googledocs

Each google service has an API.

These APIs change regularly as google develops it's services, however the core activities should always work.

If you want to take advantage of the latest features, then the API might well be developing as I write this. However things like 'Uploading a pdf' should work and be stable ... or so I thought.

I repeat the text below for easy copy/paste for future web searching:

Loading ./cal_man_EL531_509refBySharp.pdf
Failed to upload ./cal_man_EL531_509refBySharp.pdf: {'status': 415, 
'body': 'Content-Type application/pdf is not a valid input type.',
'reason': 'Unsupported Media Type'}

Other types of file might work fine, however the lack of .pdf upload facility from command line, was enough to halt my experiment.

On Debian GNU/Linux the following install will help get you started:

apt-get install python-gdata googlecl

Thursday, September 8, 2011

fairplay drm and 5 device restrictions != 'free as in speech'

So Apple app store restrictions seems to have won out (vlc)

'Free software' developers who keep buying Apple, need to square this with whether, they truly believe in 'free redistribution', 'sharealike' and 'source availability requirements'

Putting conditions like 'you can only install this app on 5 devices', seems to raise no issue with some developers, who are only too happy to wear a badge saying 'free software'

Extract from a user comments (link below) seems prophetic
Apple users are the losers here. Instead of complaining to Apple, the source of the problem, a lot of you clueless wonders want to change VLC, or try to make out that GPL should be banned.

If you need a refresher on the spirit of sharing software, then have quick read of the bullet points in the Debian social contract at

Listing points (1) free redistribution, (2) source code, and (3) derived works

App stores (as Apple defines them) prevent free redistribution, and wrap drm around the app. Both of these in my opinion are against the spirit of what you just read.

Another comment (link provided below) seems to get to the root of the issue:

The legal problem here is that there's no way to distribute an App on the App Store without the FairPlay DRM (even if that App is free and open source).

The licence that VLC was originally released under (GPL) requires that anyone distributing the App not impose any restrictions on the further distribution of that software.

If I download VLC for Windows, I can send the installer to a friend and they can pass it on to their friends etc.

That's not possible with iOS Apps. If I download it from Apple App Store, my copy will only work with my iTunes Store account.

Links and Further Reading:

I have no problem with the LGPL3 or LGPL as licenses, both are endorsed and in general use. Plenty of software in Debian is LGPL3.

What I do object to is the influence of proprietary software companies (and their supporters) in weakening of the licensing, of an established 'free software' project.

If you cannot see the dangers in this, then it is really because you do not understand the argument, or is it simply inconvenient?

About the comments I have linked to: Neither comments are my own, and yes I have cherry picked comments in support of the arguments I make in this article.

If you are the original author of either of those two comments, then please use the contact link on my blogger profile so that I may correctly attribute them in my post.

Tuesday, September 6, 2011

software licensing - permissive licensing, countermeasures

GPL2 (used by Linux kernel) was released in 1991. Since then 2 or 3 large companies have used those 16 years to identify it's weaknesses and develop counter measures.

In 2007 the GPL3 adopted clauses in response to those countermeasures (drm, tivoization, patent grants) and so it goes on.

But MIT/Apache2 is the only license you ever need?

A subject of much debate. MIT / Apache2 fill a need, however they do not require 'share alike' (code / patent grants) in the same way as the GPL, and, do little to protect against the counter measures of the last decade, I mentioned above.

What is wrong with permitting large corporations to bundle your software?

Nothing, however you need to give consideration to the following:
  • Attribution
  • Robocopping

Robocopping - what does that mean?

It could be argued (for and against) that Apache2 / MIT permissive sort of licenses have actually helped, create one of the silicon valley monsters, that every day works against free software and user control.

Here is how it goes - it's the eighties and you want a big slice of the personal computer market. What is your pitch? Well we want to free you from the tyranny of control, of huge software like IBM and buggy software like MSDOS.

So you take a project like BSD (which has a permissive license) and start the Robocopping.

Robocop began as a human, and then had non-organic parts grafted onto his torso in place of original biological components.

When OS8 was released it contained a good chunk of BSD low level utilities for most system tasks (free software) and this was bundled with proprietary software for the cosmetic end of things (the GUI).

Now with OS10, more and more of the free software has been gradually removed. Ironically, whilst pitching itself as a friend of the 'hacker', the development OS8 -> OS9 -> OS10 has gradually removed more and more of the code over which those 'hacker' types have any rights.

But Robocopping - that's just your opinion?

Here I lift a few phrases from a 2004 message exchange, there are plenty more examples of folks expressing similar sentiments:

Quite honestly, I don't think they've taken a great deal more than /bin, /sbin, /lib, /usr/bin, /usr/sbin, /usr/lib or if they have, I couldn't tell...

Source: 2004 message here

If FreeBSD wanted more than attribution, perhaps the choice of BSD license was a bad idea. :-)

Source: 2004 freebsd discussion here

Friday, September 2, 2011

Reasons to install KDE packages in a non-Kde desktop

My default desktop is Xfce.

However there are some KDE specific or Gnome specific packages that I use also.

The Gnome ones are few (and easy to remember for me), but I need reminding about the Kde ones, so here goes:

  • k3b
  • cantor-backend-r
  • dragon-player
  • filelight
  • gwenview
  • katomic
  • kcollectd
  • kdenlive
  • kdiff3
  • kmplot
  • kstars
  • ksysguard
  • ktuberling
  • okular
  • rocs
The really important programs, for me, are marked in bold.

( younger family members make use of katomic and ktuberling )

k3b - backup to cdrom and dvd - why that particular program?

For me k3b was the first 'burner' program to get it right. It is not perfect. Some might call the user interface a little clunky.

In short 'It works' and it has never let me down.

But 'blah' program is prettier? Well you can keep your pretty desktop integrated whatever - I'll stick with something that is stable and reliable thanks.

Okular for pdf reading - but I have Adobe?

Adobe reader goes much further than 'reading pdfs'. In short, I find the program exceeds what I want.

Adobe products have a habit of doing things in the background, without being too informative about that to the user. This I do not like.

Okular is a very capable replacement, and warns before opening embedded content.

But I need Adobe reader as I need to compete pdf forms?
Okular supports forms - but it prompts you to ensure your agreement before activating the form fields.

Manually: View -> Show Forms

Rocs for 'Graph Theory':

There is the beginnings of a package for 'Nodes' and 'Edges' in the KDE suite.

By no means complete, 'rocs' is a good start, but needs perhaps to attract a few more developers to progress.

Programming rocs graphs to autogenerate nodes / edges uses a javascript type language, something I may dabble with in the future.

Thursday, September 1, 2011

Installing software direct rather than package archives - Ubuntu

A cautionary tale regarding self-installing a browser on Ubuntu.

Ubuntu has a protection system labelled 'AppArmor'.

It's big strength is in protecting users from themselves, when it comes to 'Install Me Java' type popups.

Above is an example of what I refer to as 'Install Me Java' type popups.

Without being a Java expert, the user is giving some Trust to the publisher (wisely or unwisely) as to what the code will do with their computer.

AppArmor is a resident protection system, that is configured (by default) to work with a standard Firefox install*

(*By standard Firefox install, I mean listed at and installed using Ubuntu supplied tools such as Synaptic)

What happens if I install my own browser? Am I protected?

You are still afforded some protection, however AppArmor is not intercepting script execution (Java)

Can you give me an example of why this is a bad idea?

As it happens, Daniel Dieterle has a great article that illustrates the dangers very clearly.

The title probably needs a bit of qualification, and there should be some more clarification regarding the target system (see next paragraph)

How would your system be different & reaction to that article:

Okay, well your target system needs a bit of description here - did Daniel install Chrome himself?

Official release of Ubuntu (as far as I know) has Firefox6 and a stripped version of Chrome named Chromium, however that article seem quite particular in saying Chrome.

To reiterate my previous point:
If you install a browser yourself (manually or manually from ppa) your system AppArmor resident protection, will not give you the same level of protection as an officially supported browser release.

Solution: Stick with Firefox6 (installed by default), or disable Java scripting in any browser you self install.

Both are simple solutions (see image below)

If you *choose* to make your system 'non-standard', then you must also accept responsibility for any extra security precautions then required.

Running Firefox6 with Java disabled is the most secure option.

Running Firefox6 (with no self tinkering, and so benefiting from AppArmor protection of Java scripts), is a fairly secure option.

Self installing Chrome and leaving Java scripting activated is the least secure option. Security conscious users never choose the least secure option.

My browser is Official Ubuntu Firefox 6 and a AppArmor failed to intercept Java script?

Then post the output from the following command:

sudo egrep -i '(profile|apparmor)' /var/log/kern.log

...into a bug report on launchpad.

Summary in two sentences:

Malicious java should be stopped by AppArmor from executing withing Firefox6.

If you still feel a 'stock system' is vulnerable or firefox6+java is not blocking malicious scripts and reporting so in /var/log/kern.log, then file a bug and help close the hole :)