Posts on tag: source

Meistens sind Bugreports eher lästig. Zum einen verursachen sie Arbeit und zum anderen erinnern sie den Entwickler mit zuverlässiger Regelmäßigkeit daran, dass niemand perfekt ist, auch man selbst nicht. Und dass die besten Unittests niemals alle Anwendungsfälle abdecken können.

Aktuell habe ich für das Perl Modul Config::General einen Bugreport, der eigentlich ein Featurerequest ist: rt.cpan.org#79694. Aber die Idee an sich finde ich überaus charmant: Plugins. Immer wieder kommen nämlich Leute daher, die gerne dieses Spezialverhalten brauchen oder jenes Spezialverhalten. Sofern ich das als sinnvoll erachte und es machbar ist, implementiere ich dann einen entsprechenden Parameter, der das Verhalten einschaltet und programmiere es in das Modul ein.

Das ist schön für den OP, aber es bläht mit der Zeit den Code auf. Tatsächlich bestehen sicher über 80% des Moduls nur aus solchen implementieren Feature-Requests. Entsprechend viele Parameter hat das Modul, die sich zu allem Unglück auch gerne mal in die Quere kommen, weshalb es weitere Parameter und Code gibt, um das zu verhindern oder umgehen zu können.

Man ahnt schon, wo das hinführen wird: ins Chaos.

Aber mit Plugins kann ich mir das "Problem" immer abgedrehterer Spezialwünsche elegant vom Hals halten. Der jenige kann sich dann sein Spezialverhalten einfach selber bauen. Womöglich kann ich auch sowas wie eine "Rezeptesammlung" der besten Plugins anlegen oder so.

Hier also mein Kommentar dazu im erwähnten Bugreport.

Well. Now I started to add some kind of plugin interface to the module. This way one could change the modules behavior in any way. This would solve your problem as well, I think.

Here's some first shot at it:

#!/usr/bin/perl
use lib qw(blib/lib);
use Config::General qw(ParseConfig);
use Data::Dumper;
sub ck {
my($file, $base) = @_;
print “open() tries $file … “;
if($file =~ /blah/) {
print “ignored\n”;
return (0);
}
else {
print “allowed\n”;
return (1, @);
}
}
my %c = ParseConfig(
-IncludeGlob => 1,
-UseApacheInclude => 1,
-ConfigFile => shift,
-Plug => { pre_open => *ck }
);
print Dumper(%c);

Output:

_open() tries cfg ... allowed
_open() tries x/*.conf ... allowed
_open() tries x/1.conf ... allowed
_open() tries x/2.conf ... allowed
_open() tries x/blah.conf ... ignored
$VAR1 = {
          'niemand' => '2',
          'hallo' => '1'
        };

However, I'll need some time to figure out which are the best places for hooks to add. But you'll get the picture.

Momentan bin ich ja am überlegen, in meinen Terrarium Controller "Terraduino" eine Failsafe-Platine einzubauen. Dafür bin ich jetzt am experimentieren, wie man am Attiny85 (den hab ich da), I2C spricht. Ich hab mir also die "TWI/I2C library for Wiring & Arduino" zur Brust genommen, mir einen Attiny-Compatibility-Layer besorgt, den Kram zusammengehackt und dann mit dem avr-gcc versucht zu compilieren. Das kam dabei heraus:

env -P/usr/local/bin:/usr/bin - avr-gcc -g -mmcu=attiny85 \
  -Wall -Wstrict-prototypes -Os -mcall-prologues -funsigned-char \
  -funsigned-bitfields -fpack-struct -fshort-enums -Wundef -I. \
  -I../at/tiny/cores/tiny -DARDUINO=101 \
  -DF_CPU=16000000L -Os -c twi.c -o twi.o
twi.c: In function 'twi_init':
twi.c:80: error: 'TWSR' undeclared (first use in this function)
twi.c:80: error: (Each undeclared identifier is reported only once
twi.c:80: error: for each function it appears in.)
twi.c:80: error: 'TWPS0' undeclared (first use in this function)
twi.c:81: error: 'TWPS1' undeclared (first use in this function)
twi.c:82: error: 'TWBR' undeclared (first use in this function)
twi.c:90: error: 'TWCR' undeclared (first use in this function)
twi.c:90: error: 'TWEN' undeclared (first use in this function)
twi.c:90: error: 'TWIE' undeclared (first use in this function)
twi.c:90: error: 'TWEA' undeclared (first use in this function)
[..]

Tja. Und dann habe ich mich praktisch zu Tode gegoogelt. Verursacht wird das Ganze weil die entsprechenden Makros fehlen. Zunächst dachte ich, die fehlen, weil auf irgendeine magische Weise die Datei avr/iotn85.h nicht included wurde. Also hab ich sie included und bekam noch mehr komische Fehlermeldungen:

Attempt to include more than one  file.
Include  instead of this file.

Natürlich hat das nichts gerbacht, zumal die avr/io.h bereits included war. Langer Rede, kurzer Sinn: letzlich habe ich herausgefunden, dass der Attiny85 halt keinen TWI Support hat. Somit sind die entsprechenden Macros nicht definiert und daher kamen die Fehler.

Zum Glück hat der Attiny85 aber USI Support eingebaut und dafür gibt es auch eine I2C Slave Library. Runtergeladen, Eingebunden und den avr-gcc damit gefüttert: Läuft.

Sehr schön :)

Manchmal ist Opensource ja schon komisch. Ich meine, ich liebe es, keine Frage. Aber was man da für Blüten findet, was Leute an Code veröffentlichen, ist zum Teil bizarr.

Hier mal die Obskuritäten, die ich heute gefunden habe:

MQ File Mover:

The MQ File Mover application is a software package designed to move files using WebSphere MQ (aka MQSeries). MQFM processes “Action” commands, which are controlled through an MQFM Workflow XML file. The user combines a series of Action commands to create the MQFM Workflow XML file.

Der Name der Software suggeriert, dass man damit Dateien verschieben kann. Aber offensichtlich ist das ein überaus aufwändiger Task, wenn man dazu mehrere Dutzens Abstraktionsebenen, WebSphere UND XML braucht. Warum es ein system("mv ...") nicht tut, ist mir ein Rätsel.

runawk:

runawk is a small wrapper for the AWK interpreter that helps one write standalone AWK scripts. Its main feature is to provide a module/library system for AWK which is somewhat similar to Perl's "use" command. It also allows one to select a preferred AWK interpreter and to set up the environment for AWK scripts. Dozens of ready for use [modules].awk are also provided.

AWK ist ja nun eine recht alte Erfindung. Richtig alt. Quasi antik. Hin und wieder beim Shell-Scripting recht nützlich. Aber sobald es portabel und/oder modular sein soll, völlig ungeeignet. Spätestens jetzt schreibt man seine Scripten in Perl oder Python neu. Da sind die Sachen, die runawk anbietet, bereits eingebaut. Dieses Tool ist ein echter Anachronismus, erst recht, wenn man bedenkt, dass das erste Release von 2011 ist.

Spack:

Spack is a standalone package manager with its own CPIO-based package format but aiming to keep total compatibility with Slackware Linux. Written in POSIX shell as much as it makes sense, it attempts to provide a fairly complete toolkit to build, install, remove, list, retrieve, and arrange your packages. It can be used as an alternative to Slackware's pkgtools, just to independently and properly manage your local software on any distribution, or as the main package manager of the distribution you build yourself.

Ähm. Es gibt natürlich keine Paketverwaltungen für jegliche Unices. Es gibt auch keine unabhängigen. Man braucht deshalb unbedingt den tausendsten Paketmanager. Mit proprietärem Format. Unbedingt. Weil die ganzen Probleme, die die Entwickler anderer Paketmanager hatten, muss man unbedingt nochmal durchkauen. Grrrnzzzz.

VTD-XML:

Virtual Token Descriptor for eXtensible Markup Language (VTD-XML) refers to a collection of efficient XML processing technologies centered around a non-extractive XML parsing technique called Virtual Token Descriptor (VTD). Depending on the perspective, VTD-XML can be viewed as either an XML parser, a native XML indexer or a file format that uses binary data to enhance the text XML, an incremental XML content modifier, an XML slicer/splitter/assembler, or an XML editor/eraser.

Ich weiss nicht, was das Teil macht. Ausser die ausufernde XML-Toolkit-Landschaft noch weiter aufzublähen. Zumal der Entwickler nicht mal in der Lage ist, in seiner Beschreibung exakt zu beschreiben was es sein soll. Gruselig.

Quelea:

Quelea is lyrics projection software for churches. It aims to incorporate the best features of existing solutions as well as leveraging new, useful technologies that existing solutions don't have.

Mein Liebling. Hachmach. Mein verehrter Schwiegervater macht sowas. Bibelstunde mit Liedern singen und so. Die beamen da auch die Liedertexte an die Wand, unter Verwendung von Powerpoint. Wir unterhalten uns hier über eine Zielgruppe zwischen 50 bis 70 (+-20 am älteren Ende). Die kommen gerade ebenso mit Powerpoint zurecht und selbst das musste man geduldig erklären. Eine extra Software? Für Linux? WTF?! Um ein paar Verse an die Wand zu kriegen?

libfiu:

libfiu is a C library for fault injection. It provides functions to mark "points of failure" inside your code (the "core API"), and functions to enable/disable the failure of those points (the "control API"). The core API is used inside the code on which you want to perform failure injection. The control API is used inside the testing code in order to control the injection of failures.

Ja, das Debuggen von fehlerhaftem Code ist ein mühseliges Geschäft. Es kann einem den Tag oder wahlweise auch das Leben versauen. Aber Fehler in einen Code einschleusen? Huch! (Vielleicht verstehe ich das Teil auch nur nicht...)

Mintboard:

Mintboard is PHP forum software focused on usability.

The Master Or Desaster. Zehn Punkte aus der Minuskiste. Man beachte auch das erste Releasedatum: Juli 2012. Ja, auch im Jahre 2012 setzt sich jemand hin und schreibt eine Forensoftware. From scratch. In PHP. Und es gibt sogar Subscriber. Meine lieber Herr Gesangsverein, das ist der Kracher.

Ich muss diesen Sammelrant jetzt beenden, weil ich dringend weiter an meiner neuen DOS Version weiterarbeiten muss...

Eben beim Schockwellenreiter gesehen: jemand hat S5 modernisiert, diese Version ist jetzt cross-browser-fähig. Sehr fein. Ich muss mein Pod::S5 Modul updaten.

Heute hat Thorsten Leemhuis bei Heise einen Artikel darüber veröffentlicht, dass angeblich die Gefahr drohe, dass der [Linux-]Desktop zersplittere. Und zwar weil jemand den Gnomedesktop geforkt und Ubuntu Unity eingeführt hat.

Fangen wir mal beim grundsätzlichen an, Herr Leemhuis schreibt:

Statt zwei sind es daher nun sechs Desktops, die hoch in der Gunst der Anwender stehen. Diese Konkurrenz wird sicher das ein oder andere nützliche Bedienkonzept entstehen lassen; aber das wird die Nachteile, die der Wettbewerb und die Zersplitterung mit sich bringen, nicht aufwiegen können. [Hervorhebung von mir]

Es ist hier die Rede von Opensource Software. Die mag im "Wettbewerb der Beliebtheit" stehen, mehr aber auch nicht. Eine "Konkurrenz" gibt es in dem Bereich nicht. Es gibt keinen "Desktop Hersteller" im eigentlichen Sinne, auch wenn zum Beispiel die meisten Entwickler von Gnome bei Redhat angestellt sein mögen. Dieses Marketinggeschwätz passt überhaupt nicht zum Gedanken, der hinter Linux im speziellen und Opensource im Allgemeinen steht. Oder weniger nett formuliert: Hätte Herr Leemhuis hier die ganzen Bullshitbingobegriffe weggelassen, wäre der Artikel nur noch halb so voll gewesen - allerdings auch von jedem weiteren Sinn befreit. Denn wenn man sich vor Augen hält, dass es diese herbeifabulierte Konkurrenz gar nicht gibt, dann wird einem schnell klar, dass keine Gefahr droht, wenn es plötzlich mehr Desktops gibt als vorher. Insofern hätte sich der Artikel bereits an Substanzlosigkeit in Luft aufgelöst.

Der Denkfehler (oder soll ich es eklatante Wissenslücke nennen?) ist jedoch, dass genau dieses forken und weiterentwickeln der eigentliche evolutionäre Motor der gesamten Opensourcebewegung ist. Wieviele coole Dinge nutzen wir heute, die als Forks angefangen haben? FreeBSD, Firefox oder Android - um nur ein paar zu nennen. Und es war schon immer so, dass es mehr Forks gibt, als Überlebende. Nur ein paar geforkte Projekte entwickeln sich wirklich signifikant weiter und überholen das Elternprojekt oder lösen es sogar später ab. Auf dem Weg dahin gibt es immer reichlich Tote (Projekte). Das ist wie bei der natürlichen Evolution. Wir Menschen sind auch nur Forks. Und wir sind der einzige überlebende Fork, nicht der einzige den es je gab. Auf dem Weg vom kleinen Säuger bis zu uns Homo Sapiens sind zig tausende Arten ausgestorben. Nicht anders ist das bei Opensource.

Das ist völlig normal. Und weil das so ist, gibt es immer von allem mehrere. Es gibt mehrere Terminalprogramme, mehrere Mailprogramme, mehrere Shells, mehrere Interpreter, mehrere Compiler, mehrere Grafikprogramme, mehrere Taschenrechner und natürlich auch mehrere Fenstermanager. Und das ist verdammt gut so.

Und da wären wir beim eigentlichen Verständnisproblem: tatsächlich gibt es gar keinen "Desktop" unter Linux. Die grafische Oberfläche unter Linux (und übrigens auch FreeBSD, OpenBSD oder OpenSolaris) ist X11. Das stellt Protokolle für die Client-Server-Kommunikation zwischen grafischen Komponenten zur Verfügung. Darauf setzt der Fenstermanager auf. Es gibt mehrere Dutzend Fenstermanager. Wobei da nur die aktiv entwickelten gezählt sind. Einschliesslich aller Existierender sind es Hunderte!

Und auf dem Fenstermanager kann ein Sessionmanager aufsetzen. Gnome oder KDE sind solche Sessionmanager. Tatsächlich ist der Fenstermanager, den KDE verwendet KWin. Den kann man sogar ohne das KDE-Gedöhns benutzen. Plünnkram wie eine Taskbar, Startmenü oder Drag&Drop bietet der Sessionmanager an.

Grundsätzlich kann jeder Anwender den Fenstermanager (oder Sessionmanager) verwenden, den er will, und zwar völlig unabhängig davon, welche Linuxdistribution er einsetzt oder was dort der Default sein mag. Meinetwegen kann Ubuntu vorgeben, was es mag. Wenn ich nicht mit Unity arbeiten möchte, lösche ich es und installiere was anderes. Und wenn es Ratposon ist. Und nein, man muss dazu nicht mal ein erfahrener Anwender sein, die Ubuntu Bordmittel, namentlich das Paketsystem, erlauben so etwas.

Aber zurück zu Herrn Leemhuis. Er macht sich Sorgen über "Linux auf dem Desktop":

Wenn ich noch an den von vielen gehegten Wunschtraum "Linux auf dem Desktop" glauben würde, dann würde ich sagen, der rückt damit wieder etwas weiter in die Ferne

Ich frage mich, wen er mit "den vielen, die den Wunschtraum hegen" meint. Oder wieviele. Wahrscheinlich ein paar Marketingleute, so wie er einer zu sein scheint, die meinen sich mit Linux beschäftigen zu müssen. Und das Wort "Wunschtraum" ist dann auch gleich die Negation davon, denn ein Wunschtraum ist ein unerfüllbarer Traum.

In der Realität jedoch hat Linux und Opensource den Planeten nachhaltig erobert. Es hat nachweisbar und messbar die Welt signifikant verändert. Nehmen wir nur das Mobile-OS Android. Platz 2 nach Apple im Smartphonemarkt. Bald wird es einen Opensource-Sateliten geben. Ich könnte unendlich lange Beispiele aufzählen. Ja es mag sein, dass Linux am Desktop nicht weit verbreitet ist. Aber das liegt sicherlich nicht daran, dass es zu viele Fenstermanager oder Desktopsysteme gibt. Oder dass die, die es gibt schlecht wären (sind sie nicht, mein Stiefsohn arbeitet seit einem Jahr mit KDE und ist nachweislich ein völliger Noob was Rechner angeht - und ist klaglos zufrieden).

Die Ursache ist, dass PC Hersteller ohne Not ihre Systeme mit komerzieller Software vorinstallieren. Und die allermeisten PC-Käufer packen das Teil aus und wollen direkt gleich sofort loslegen. Da ist Windows installiert? Ok, clickety-click. Und es liegt an Schulen und Universitäten, die ebenfalls ohne Not Windows einsetzen. Auf diese Weise wächst der Nachwuchs mit Windows auf (oder mit Apple, da ist es das gleiche bzw. noch schlimmer, d.h. die Indoktrinierung dort ist schlimmer) und weiss gar nichts von Linux.

Und angesichts dessen ist die Heraufbeschwörung eines Problems weil es zu viele Forks gibt, totaler Unsinn. Wahrscheinlich hat dem Autor einer gesagt: Hey schreib mal was mit Linux Desktops. Oder so. Man weiss es nicht.

Übrigens - ich verwende FreeBSD und das hier ist mein "Desktop" (Fenstermanager CTWM):

2012-08-10 - CTWM: