48 Augen

An ocean of bicycles in Amsterdam.

Drawing paintings in a church.

Living in a box. #Amsterdam #TravelPhotography

NSDM Terrein in Amsterdam-Noord.

They can't see me in their virtual reality.

"Around The World", a carousel attraction at a fairground in Amsterdam. #StreetPhotography

Phone call to heaven (or hell).

Old and new neighborhoods in Zagreb.

Hey I'm Dove, can I join you at the pigeons backyard?

Checking out the offers the week in front of a super market in Prague.

Utah in San Francisco.

Last place of the Kings. Wooden tombstones in Bonanza Cemetery, Idaho, USA.

#SuperMarket

Super market sign in Yellowstone West, USA.

I really need to re-activate this blog. The last post is almost 2 years old. The blog looks abandoned and I do not have enough time to publish regularly new tech posts. I have too many other things and ideas consuming my time. So I decided to make two big changes for this site:

I add photography. I would not call me a real photographer but I like photography, I like cams, I shot pics myself, so why not show some stuff here. I mostly do travel photography and street photography. I will mainly sync some of my pics from Instagram here, some best-of collections, maybe one or two other articles. Let me start with some pictures I shot in Tenerife last year.

If your Fedora system alerts you about Zero disc space, you may check your Docker installation.

Docker is a great virtualization platform for distributed applications. You can use it to have application containers to ship and deploy them, or use it locally to develop your applications. Cool stuff but it may hit you from the back under some circumstances. You probably won't experience it if you are using Docker under MacOS or Windows because you need to run it in a VirtualBox anyway.

Some days ago Fedora alert my disc was full, and applications stopped to work properly. Usually a Fedora system can run with 5 to 15 Gigabytes disc space, I configured my system partition with 50 Gigabytes to have enough space for logs and cache files. Now it was full. Why? Later I figured out the reason: Docker's large DevideMapper files eats up my disc space on the system partition.

Docker relied on aufs that is not supported in the Linux kernel used by RHEL/Fedora (and marked as deprecated in the Ubuntu kernel) but later Docker backend settled on a DeviceMapper implementation for Fedora, or any other Linux that doesn't ship by default with aufs support. The DeviceMapper plugin stores the data in very big files (~100GB), by default on your system partition. Not a good place if you have limited size here.

A clean solution would be to create an own disc partition for Docker and mount it to /var/lib/docker/ or /var/lib/docker/devicemapper/. I've used a quick fix and copied the Docker files to my /home disc partition that is lot of bigger than my system partition. You can achieve it by:

Note: this worked on my Fedora 20 machine, using two different partitions for the system and home directories!

get root: $ sudo su

stop the Docker demon: # systemctl stop docker.service

copy Docker files: # cp -R /var/lib/docker/ /home/_varlibdockerfiles

backup original Docker files: # mv /var/lib/docker/ /var/lib/docker.backup

add link to new Docker files: # ln -s /home/_varlibdockerfiles/ /var/lib/docker

start Docker demon again: # systemctl start docker.service

Now you can test it by running one of your built Docker containers. You may run into an error like: Error response from daemon: Error running DeviceCreate (createSnapDevice) dm_task_run failed. That means you may have to repair the device mapper meta data:

stop the Docker demon again: # systemctl stop docker.service

# thin_check /home/_varlibdockerfiles/devicemapper/devicemapper/metadata

if this do not show any errors, proceed with: # thin_check --clear-needs-check-flag /home/_varlibdockerfiles/devicemapper/devicemapper/metadata

start Docker demon: # systemctl start docker.service

If this works and you don't experience unexpected behaviour of your Docker containers, you could remove the backup of the Docker files from your system partition: # rm -Rf /var/lib/docker.backup

My system partition is now back to ~9GB disc usage :)

Other sources:

Resizing Docker containers with the Device Mapper plugin by Jérôme Petazzoni

Inside Docker for Fedora20/RHEL7 by Etsuji Nakai

Chyrp is a lightweight blogging engine, written in PHP, working with SQLite and MySQL. It is possible to create different types of posts, e.g. Text, Video, Photo, Link and Quote. It looks like a good open-source alternative for Tumblr.

I currently try out Chyrp, thinking about to replace my private Wordpress blog. The recent Chyrp version includes an option to import content from the Wordpress-XML export file. But it didn't work for exports from Wordpress.com-Blogs and the default import creates only Text posts in Chyrp, regardless of the post type of the original Wordpress data. So I fixed it and added an additional chyrp module that enables the import of types posts. My Wordpress branch for Chyrp improves:

imports from wordpress.com is possible

tag import is fixed (only with enabled tag module)

category import was added (only with enabled category module)

import typed Wordpress posts (link, quote, video, image) to the right Chyrp feathers (link, quote, video, photo) if they are enabled

Unknown post types are still imported as text feather in Chryp, e.g. gallery posts in Wordpress. Currently it is not possible to import them as Photo posts in Chyrp because the photo feather only allows one image per post.

How to import content from Wordpress.com to Chyrp

Go to your Wordpress.com blog dashboard and navigate to the Tools/Export option. Download your data from there as XML and safe it.

In Chyrp you need to enable the module "Wordpress Post Types Importer" and the Link, Quote, Photo and Video feathers.

In Chyrp you go to Manage/Import and:

choose your Wordpress-XML export file as import data

fill in the URL prefix that was used in to link media (images) in the Wordpress posts. For WP.com it probably is: http://{{yourblogname}}.files.wordpress.com/

Wait for the success message.

Check Manage/Posts to control the import.

Today I've learned from The Cangelog news blog about Jeremy Keith's proposal to add a relation between a project/document and its souce code by using rel="source" somewhere in the HTML markup. Sounds good, but it would only be a unspecific relation between a document or project or whatever and something related to some unspecific type of source code container :) I really miss the improved semantics here. And we already have options to describe it.

Keith wrote:

I got chatting to Aral about a markup pattern that’s become fairly prevalent since the rise of Github: linking to the source code for a website or project. You know, like when you see “fork me on Github” links. [...] We were talking about how it would be nice to have some machine-readable way of explicitly marking up those kind of links, whether they’re in the head of the document, or visible in the body. Sounds like a job for the rel attribute, I thought. [...] I’ve proposed rel=”source”.

The "fork me on Github" link has at least 3 different meanings:

the website of a software project contains a relation to the public source code repository of the software

the link points to a repository where the content of the webseite is managed, this link is the same on all pages of the website

the link points to the related source of the currently shown page deep in the repository

A human can see the difference, a machine not. If we add code to markup to make the relation machine-readable, a rel="source" wouldn't do the job. A machine really needs a very clear description about "X has a relation to Y", the machine need to know about X, Y and the relation. A machine needs a object, a predicate and a subject to understand the fact.

Lack of the object

The brainstorming page about rel="source" at the Microformats wiki describe the use case as:

When an author links to a project's (or document's) source code (e.g. on GitHub, Google Code, etc.) a rel value of "source" could be used to explicitly define that relationship.

It already describes the problem: is it the source code of the (software) project or is it a link to the source code of the document (content of the webpage)? X (the object) is not defined here, a simple rel="source" do not imply entailment, there is no logical consequence. Machines would have to guess what the object is.

Lack of the subject and its type

While there is a discussion about the label on the brainstorming site, a machine only cares about the semantical meaning, "sfuzcfzcsz" could be the name of the property that relate a software project to it's download archive. rel="source" don't say anything about the subject or its type, it only describes that the related resource has to do something with source code.

Is it the source code in a zip/tar/xyz archive?

Is it a file containing uncompressed source code?

Is it a repository address you can checkout or clone from? Is it Git, Mercurial, SVN, ...?

Is it a relation to the homepage of a code repository (e.g. most Github links)?

Is the link about a special version, branch, tag of the source code?

Where to put the relation in?

You may able to use rel="source" on a meta and anchor element in HTML. Please try to use it on a PNG image -- e.g. a computer generated fractal -- to describe a relation to the source code of the generating program. Good luck! There is no Microformat vocabulary to wrap it in. Leads to the next problem:

What about listings?

If you have a listing of software projects on one webpage, how can we set the correct relations. Using rel="source" multiple times on various links? A machine would only see multiple source relations on one HTML document because currently there is no proper vocabulary in MF1 and MF2 that you can use to describe the software project or web document, maybe h-item but according the spec "h-item is almost never used on its own."

Already existing and working alternatives

According to a "rel usecase repository", Keith writes:

The benefit of having one centralised for this is that you can see if someone else has had the same idea as you. Then you can come to agreement on which value to use, so that everyone’s using the same vocabulary instead of just making stuff up.

Good advice :) There are alternative options developed by the RDF and Microdata communities, developed months or years ago:

The DOAP project "create an XML/RDF vocabulary to describe software projects, and in particular open source projects." The DOAP vocabulary provides properties like repository and more to describe relations to Repositories, Downloads, Wikis, Issue Lists and a lot of more stuff. You can add DOAP to your HTML via RDFa and Microdata.

The schema.org vocabulary provides concepts like CreativeWork, SoftwareApplication, Code and properties like codeRepository and downloadUrl, also useable in you HTML markup via RDFa and Microdata syntax.

Update (Feb 21): there is already a rel-vcs Microformat that is used and supported by various tools. But t is not listed in the "the official registry for rel values." Of course it shares most of the problems with rel-source regarding semantics.

We don't need to live in a religious Microformats-centric world with the Microformats wiki as your bible. :) And rel="source" would be probably not so awesome because:

it does not add enough semantics that machines can understand the correct fact