Funkt.

Jetzt endlich sogar kabellos verbunden mit meiner restlichen Infrastruktur.

Schon spannend was das System alles an Paketen mitbringt.

• Aircrack-ng
• Aircrack-ptw
• etc...

Die volle Ausstattung um Unsinn zu treiben. :-)

Dazu noch die Pläne der Freifunker, einen La Fonera Router mit Notebook-Baterien im Rucksack liegen zu haben, der Mesh und gleichzeitig vorhandene Netze Attakieren öffnen kann...

:-)

Leider kann das gegenwärtige OpenWRT noch keinen AdHoc Modus gleichzeitig mit etwas anderem anbieten (sonst könnte der Accesspoint bis zu 4 Netzwerke gleichzeitig anbieten) so dass es nicht möglich ist, das er über ein Normales WLAN Netz sein Internet bezieht und diesen dann über das Mesh weiter gibt.

Andererseits gibt es den La Fonera Pack, der auf das normale Fonera zusätzlich zu der Fonera Dienstleistung noch das Meshing anbietet.

Also muss es wohl doch irgendwie gehen.

Nur wie?

Ha!

Es Funkt. Frei.

Naja fast. Jedenfalls funkt das OpenWRT schon mal. An dem Freifunk arbeite ich noch.

Immerhin gibt es ein paar Straßen weiter wohl noch weitere 3 Leute die Freifunk machen. Interessanterweise wohl auch immer gleich sowohl OLSR als auch B.A.T.M.A.N..

Na mal schaun wie das läuft. Auf dem Fonera soll ja zusätzlich auch noch FON als Dienst laufen.

Ah well, schaun mer mal.

Wenn die Hardware tatsächlich an Hitzeproblemen verstirbt, muss ich halt ein neueres Modell nachbestellen.

Marc-Uwe Kling fasst die Stimmung nicht nur der Geeks zur gegenwärtigen Politik sehr krass zusammen.

(zu Hotaka)

Well, am WE hab ich mich mit Felix gerade über Versionskontrollsysteme und unsere Experimente mit HG unterhalten, als mich jemand 'von der Seite angemacht' hat, dass doch wohl im Moment alle Welt weg von HG und hin zu GIT wechseln würde.

Well, das konnte ich so nicht glauben, aber ich wollte mir die verschiedenen Tools dann doch mal anschauen - vor allem in Hinsicht auf SVN Kompatibilität - denn ich setze SVN sowohl für meine Arbeit, also auch für mich [browser:/ Privat] ein.

Na, denn ma auf zu dem Vergleich:

GIT

... hab ich mir als erstes dran genommen, und bin erst mal dran gescheitert, das das perl-script, dass den SVN-Modus macht via Fink natürlich nicht mit meiner Installation zusammenwollte, weil diese alten Perlhacker natürlich alle davon ausgehen, das Perl in /usr/bin/perl liegt. Well, tut es bei mir nicht, bzw, in /usr/bin liegt eine alte version von Perl, die eine bestimmte Library nicht enthält, die aber das Skript benötigt. ARGH! Also erst mal einen Patch zusammengebaut und an den Maintainer geschickt der das auf /usr/bin/env perl ändert. Oh well.

Danach war aber eigentlich alles dandy, bis auf die Tatsache, das ich trotz längerem nachlesen ums verrecken nicht verstanden habe, welchen Sinn diese komische Staging-Area "Index" haben soll, die man bei GIT immer zuerst mal auffüllen muss, bevor man sie Comitten kann.

Well, GIT is powerfull - aber für meinen Geschmack zu sehr an den Geschmack von Herrn Torvalds angepasst. Mag ja sein das er nur mit inkonsistenten und komplizierten Kommandozeilenoptionen effizient arbeiten kann. Ich jedenfalls hab was besseres verdient. Ausserdem erzeugt es bei mir Ablehnung wenn Herr Torvalds aus seiner Göttlichen Eingebung sämtliches anderes für Mist erklärt und dann etwas neues macht was deutlich komplizierter ist als die anderen - ohne das klar wird, wieso diese Komplexität der richtige Default ist und man nicht das Einfache zum Default machen kann, um das komplizierte als Option anzubieten.

Fazit: Funktioniert, push und pull zum SVN server waren kein Problem und das ist schon mal ein starkes Stück. Beindruckendes Tool, dass aber auch viel Ablehnung in mir erzeugt.

BZR

... war dann der zweite Kandidat, der nicht mehr viel Langsamer daherkommt als die anderen beiden (allerdings auch nicht zacko schnell). Allerdings, gibt es eine nette Extension die das Kommando shell hinzufügt. Das ist nett, denn dann hat man eine native Shell in bzr und hat superschnelle reaktionen, Tabvervollständigung überall, etc.

Der Checkout aus SVN hat auch prima geklappt (die Anfangsschwierigkeiten hatte ich vor einem halben Jahr, als ich mir die SVN-Python-Bindings selber bauen musste. ARGH war das ein Kampf.) Jetzt hatte ich sie aber schon und mir auch schon die notwendigen Wrapper-Skripte gebaut die die Library dann halt noch dazuladen.

Well, was soll ich sagen: pull vom SVN war hervorragend, lokales arbeiten auch, aber das Push.. das stirbt immer mit Fehler 175008 (ernsthaft!) und wirft mir dann noch an den Kopf das irgend eine property nicht angewendet werden konnte. Wenn er wenigstens sagen würde welche Property das Problem ist.. Aber naja.

Fazit: Sehr poliert. Gerade im Vergleich zu meinem letzten Test ist die Dokumentation viel besser geworden, das ganze Tool wirkt durchdacht. Vor allem der Output der Kommandos hat mir gefallen, schön aufgeräumt und übersichtlich. Dann ist da natürlich die Tatsache das dieses Tool doch immer noch das einzige ist, das tatsächlich Verzeichnisse auch Versionieren kann und mit renames vernünftig umgeht. Ahh.... Endlich ohne scheu refaktorn. :-)

HG

... will ich eigentlich schon länger mal benutzen, aber es hat mir bisher immer nur zu ein paar kleinen Experimenten gereicht. Allerdings: Felix hat sich schon anstecken lassen und verwendet das jetzt nahezu ausschließlich.

Well, mein Testcase hat leider gar nicht Funktioniert. Einigen Anmerkungen hatte ich entnommen das HG jetzt auch auf SVN zurückschreiben kann herausgefunden wie das geht, hab ich aber leider nicht. Oh well.

Fazit: Schnell, gute Bedienung und Python - aber ungeeignet um damit gegen SVN Repositories zu Arbeiten.

Fazit Fazit

So, dann bleibt mir also die Wahl: entweder GIT zu akzeptieren um damit gegen SVN zu arbeiten, oder aber den Bug in BZR zu finden um dann damit zu Arbeiten.

Vom Bauchgefühl her würde ich mich eigentlich lieber an BZR heranmachen. Mögen tue ich HG am liebsten, das hat einfach das einfachste Design und auch noch eine sehr gute Integration in das System - so öffnet es zum Beispiel standardmäßig gleich das System Merge-Tool (opendiff) anstatt CVS like Konflitkmarker in der Datei zu verstreuen.

So macht man dass.

BZR ist auf jeden fall mein zweiter Favorit - auch Python (kann ich also Hacken) und schön durchdacht - wenn auch manchmal etwas verbose zu bedienen (pull z.B. macht kein merge, aber er sagt einem dann das man statt pull merge machen müsste. ???)

GIT wirkt wie eine mächtige Kanone - ja man kann damit auch auf Spatzen schießen - ja danach wären sie tot - aber muss man sich das wirklich antun, das jeder normale Usecase ein wenig Komplizierter zu handhaben ist als mit den anderen Tools, nur damit man im zweifelsfall auch den Linux-Kernel mit dem gleichen Tool Maintainen kann?

Ich jedenfalls beantworte diese Frage für mich mit einem klaren nein. Und werde mich jetzt erstmal auf bzr und hg werfen.

Auf Archive.org. Goilomat.

Wie funktioniert eine Linotype Maschine 1 und 2.

Ich habe mich über die letzten zwei Tage erneut von Katrin inspirieren lassen.

Herausgekommen ist ein [attachment:blog:2008/04/12/22.16:AnimatedGrid.app.zip kleines Cocoa-Programm] ([browser:/open-source/animated-grid Source]) dass ein wenig mit solchen Grid-Animierten Ansätzen herumspielt und nebenbei noch ein wenig Sheets und Preferences verwendet.

Interessant ist dabei für mich der unterschiedliche Ansatz: Katrin war wichtig, das jeder Display Vorgang in konstanter Zeit abläuft und sie verwendet daher eine Liste der einzelnen Rechtecke. Ich hatte mir das auch überlegt, mich dann aber dagegen entschieden weil es komplexer zu Programmieren gewesen wäre.

Geschwindigkeit hat sich dann im Test überhaupt nicht als Problem herausgestellt - aber das grundsätzliche Problem bleibt. War es vernünftig den Code erst einmal einfach zu halten? Ich bin überzeugt das ja.

Ganz zufrieden bin ich aber noch nicht, weil das einzige Objekt ein View und gleichzeitig der Controller für die Preferences des Programms ist.

Aber - das Programm ist so auch kurz und Übersichtlich.

Hm.

Mal schauen was ich noch daraus mache. Vorschläge für interessante und auf dem modell ausdrückbare Algorithmen immer gerne an mich.

Hier noch ein paar Screenshots:

Endlich ist mir wieder so ein Punkt klargeworden, der mich schon lange an Python stört, den ich aber bisher noch nicht so richtig spezifizieren konnte.

Zusammenfassen lässt es sich als: Konvention ist besser als eine eigene Syntax / Regel.

Konkret geht es um folgendes: Python besitzt eine eigene Syntax für Konstruktoren. Nämlich diese:

class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

point = Point(10, 15)

Der Konstruktor eines Objekts heißt immer __init__ (das mit den Unterstrichen finde ich sowieso hässlich, aber well, darüber ärgere ich mich wan anderes).

Das ist gut, weil man so den Konstruktor immer gleich findet.

ABER: Das ist total scheiße wenn man mehrere Wege braucht um ein Objekt zu initialisieren.

Denn genau wie in Java auch, kann man anhand den Argumenttypen ja keinen dispatch machen. Doh.

Also, wenn man das Beispiel erweitern will um auch Polarkoordinaten zu unterstützen, dann geht das nicht, denn bei

class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __init__(self, theta, phi)
        self.x = ...
        self.y = ...

point = Point(10, 15)

kann die Runtime nicht mehr auflösen welchen Konstruktor mann denn jetzt genau gemeint hat.

Doh.

Jetzt hat man entweder die Wahl so etwas zu machen wie hier im Trac-Projekt

class WikiPage(object):
    """Represents a wiki page (new or existing)."""

    realm = 'wiki'

    def __init__(self, env, name=None, version=None, db=None):
        self.env = env
        if isinstance(name, Resource):
            self.resource = name
            name = self.resource.id
        else:
            self.resource = Resource('wiki', name, version)
        self.name = name
# ....

Was aber total ekelig ist, denn jetzt hat der Konstruktor auf einmal einen Parameter name der überhaupt nicht mehr dass ist, was er mit seinem Namen dokumentiert.

Klasse. Jetzt muss man tatsächlich den Code des Konstruktors lesen um zu verstehen was für Argumente man benötigt um so ein Objekt zu erzeugen. Habt ihr wirklich gut gemacht!!!!11!!

Oder aber man scheißt auf das Konzept eines Konstruktors und schreibt Factory-Methoden, also im Beispiel etwa so:

class WikiPage(object):
    """Represents a wiki page (new or existing)."""

    realm = 'wiki'

    @classmethod()
    def create_from_resource(klass, env, resource, db=None):
        page = WikiPage(env, resource.id, resource.version, db)
        page.resource = resource
        return page

    def __init__(self, env, name=None, version=None, db=None):
        self.env = env
        self.resource = Resource('wiki', name, version)
        self.name = name
# ....

Das ist jetzt immerhin klarer - hat aber den Nachteil das der Leser jetzt wissen muss dass man Factory Methoden einsetzt und welche (nichtstandardisierte) Konvention man für diese einsetzt. Na Klasse.

Ergo: Die Sprachdesigner haben sich gedacht, das es ja eine Tolle Sache wäre, wenn sie eine eigene Syntax einführen würden, damit Konstruktoren etwas besonderes sein können und haben damit erreicht, dass man sich beim tatsächlichen Programmieren jetzt auf einmal ein Bein Brechen muss, damit man ganz alltägliche Probleme auf eine saubere Art und Weise lösen kann.

Ganz groß.

Hätte man doch von vornherein anerkannt, das ein Konstruktor auch nur eine Methode ist - mit der Konvention dass der Name mit "init" anfängt - dann existierten auf einmal diese Probleme nicht mehr. Denn dann kann man über den namen der Methode dokumentieren was sie soll.

class Point:

    def init_cartesian(self, x, y):
        self.x = x
        self.y = y
        return self

    def init_polar(self, theta, phi):
        # ...
        return self

cartesian = Point().init_cartesian(10, 15)
polar = Point().init_polar(0.23, 0.23)

Yucheh!

Dazu kommt, dass man dann auf einmal sinnige Dinge tun kann, wie zum Beispiel, das ein "Konstruktor" nicht immer die gleiche Klasse zurückgeben muss. Man könnte also zum Beispiel eine öffentliche Superklasse haben, die aber tatsächlich in mehreren privaten Subklassen implementiert ist - zum Beispiel ein String, der je nachdem wie er erzeugt wird anders aussieht: Stringkonstanten vielleicht eine Klasse die nicht/anders an der Garbage-Collection teilnimmt und dafür Uniqued (also garantiert nur einmal) existieren (für einen schnelleren Interpreter interessant), Strings aus einer Datei entweder normal, oder falls die Datei eine gewisse Größe überschreitet als Memory-Mapped File, Strings die Pfade repräsentieren so, dass sie mit den Eigenheiten von Dateisystemen besser klarkommen, Strings die keine Unicode enthalten noch mal anders, damit sie effizienter sein können.... etc.

Und das alles, weil man auf Sprachebene auf ein zusätzliches Konzept verzichtet.

Aber dass, scheint ja für Sprachdesigner das Schwerste zu sein.

Ist ein Schwesterprojekt der Wikipedia.

Man sieht sich als eine Plattform zum gemeinschaftlichen Lernen, Lehren, Nachdenken und Forschen.

Könnte das der lang ersehnte nächste Evolutionsschritt der Universität sein? Das wie sie in 10 Jahren aussieht?

Mal genauer schauen. Morgen.

Will man sowas haben?

Wäre ja schließlich ein Hackerwerkzeug und damit verboten.

Nun, wer will da schon. Immerhin würde man damit ja schließlich normale WEP-Verschlüsselung in so etwa einer Minute entschlüsseln können.

Pah...

Aber Ankucken ist ja nicht verboten.

:-)

Ich will das die Partei transparent ist und bleibt. Jeder der dabei ist oder sich dafür interessiert soll komplett sehen können wie und an was wir arbeiten. Geheimniskrämerei ist nicht.

Ich will das die Partei Demokratie neu erfindet. Das Internet verspricht, dass man sich einfach und so tief man möchte, in die Themen einbringt die einen Interessieren und von denen man etwas versteht. Dieses Versprechen gilt es zu umzusetzen und gleichzeitig die Grundsätze der gleichen, freien und geheimen Wahl zu erhalten.

Hohe Ziele. Vor allem das letzte ist haarig. Denn: Wahlcomputer und mit ihnen alle Systeme die ich bisher kenne, haben einen gravierenden Nachteil: Bei einer normalen Wahl, kann man jeden x-beliebigen Erwachsenen bitten die Wahl zu beaufsichtigen. Wenn man ihm dann noch 3 Minuten lang erklärt wie alles funktioniert, kann er den ganzen Tag zusehen (er hatte vermutlich eh gerade nix zu tun) und am Abend dann mit voller Überzeugung verkünden dass dort alles korrekt abgelaufen ist (wenn dem denn so war).

Das geht mit technischen Systemen bisher nicht - und das ist ein Problem. Aber da sind wir garantiert die einzige Partei die das lösen kann.