This can be seen as a subproject of ethtool netlink interface but from the technical view it's independent. Every new piece of software is going to be buggy and with frequent changes and rewrites, new regressions are introduced. Automated selftests can help a lot but as ethtool deals with hardware devices, we do not want these tests to depend on a specific hardware. The netdevsim driver was created as a virtual device which (unlike e.g. dummy) cannot be used for actual network traffic but implements various configuration interfaces so that it can be used for their (automated) testing.

The day has come to finally merge more and more apps into one single place, and this time it shall be externaltools. I'd like to merge functionality of externaltools into geekos, as they share quite a lot of concerns. This way, we can beat fragmentation and have a single tool to track teams, tools and floors.

Short-term:

1. Understanding of docker knowledge

My music manager, Bard, was improved in the last hackweek with a very simple React-based web interface but I didn't like the result at all (basically, after learning React I noticed I didn't like it and all the dependencies and the complexity it added) so since then, I've reimplemented the web interface using just jQuery. Also, in the last months I've added musicbrainz data structures to the database (which was also ported to use Postgresql) to prepare bard to use MusicBrainz's data. I also stopped using other python libraries to read audio files and use the ffmpeg libraries directly instead with a c++ wrapper implemented inside Bard which is much much faster. In this hackweek I'll try to finish the integration of Bard with MusicBrainz (basically, import the needed MB data to the database) and use it to generate a web interface that shows and uses that information to organize music. This would allow to show information and for example perform searches for songs not only on the main artist but also on performers or even mixer (see for an example all information available on this Queen album)

Ceph offers a highly scalable and fault-tolerant storage system. Samba is already capable of sharing data located on the Ceph Filesystem, however scale-out sharing (the same data exposed by multiple Samba nodes) currently requires the use of CTDB for consistent and coherent state across Samba cluster nodes. In such a setup CTDB provides a clustered database with persistent key-value data storage and locking. Database usage is abstracted out via a generic dbwrap interface. Ceph's librados library provides an API for the storage and retrieval of arbitrary key-value data via the omap functions. A watch/notify protocol is also provided as a mechanism for synchronising client state (locking). Key-value data stored in the RADOS back-end inherits the same redundancy features as regular objects, making it a potentially good candidate as a replacement for CTDB in scale-out Samba clusters.