Wer kennt das nicht: Wieder einmal ist der Abfluss verstopft und die Küche könnte auch einmal einen neuen Anstrich vertragen. Nunja: Alles kein Problem!
http://www.youtube.com/watch?v=NxWNQ2paWO4&feature=related
Also viel Spaß beim nächsten Ruf der Handwerker!
Bereits am 11. Februar gab es eine größere Demonstration gegen ACTA in Kiel, aber wie das bei unliebsamen Themen in der Politik so ist, kommen diese schneller wieder, als einem manchmal recht ist. Und so stand auch bereits für den Am 25. Februar der Termin für eine weitere Demonstration fest. (more…)
Not quite 0x0001 0000 0000 0000 years since the last post in this category but still long enough to justify emitting a new sign that there’s still some developement going on with GeSHi. And it’s quite a coincidence that Markus „Notch“ Persson is taking over GitHub with its own new language now being highlighted. And since most assembly languages are quite easy to highlight it’s only natural to add support for highlighting of this new language for GeSHi.
So there it is: After only about 10 minutes looking at the language specs the basic structure looked simple enough and since GeSHi already supported a bunch of different assembly languages it’s only natural to use another one of them as the template. In this case I decided go for Z80 assembly as the ZiLOG Z80 instruction set is quite simple and still the language file was elaborate enough to support all the features required by Notch’s new assembly language. Actually: I even could remove some features not required to properly highlight DCPU-16.
After a short clean-up of the language file – removing all the old instructions, registers and directives – it took only few more steps to fill in the list of supported instructions: In the case of the DCPU-16 instruction set this is a quite small set of only 16 instructions, 11 registers and 3 „memory shortcuts“. Thus there was not that much to copy from the specs, althoug the example given there looks quite nice when rendered with this new language file:
; Try some basic stuff
SET A, 0x30 ; 7c01 0030
SET [0x1000], 0x20 ; 7de1 1000 0020
SUB A, [0x1000] ; 7803 1000
IFN A, 0x10 ; c00d
SET PC, crash ; 7dc1 001a [*]
; Do a loopy thing
SET I, 10 ; a861
SET A, 0x2000 ; 7c01 2000
:loop SET [0x2000+I], [A] ; 2161 2000
SUB I, 1 ; 8463
IFN I, 0 ; 806d
SET PC, loop ; 7dc1 000d [*]
; Call a subroutine
SET X, 0x4 ; 9031
JSR testsub ; 7c10 0018 [*]
SET PC, crash ; 7dc1 001a [*]
:testsub SHL X, 4 ; 9037
SET PC, POP ; 61c1
; Hang forever. X should now be 0x40 if everything went right.
:crash SET PC, crash ; 7dc1 001a [*]
; [*]: Note that these can be one word shorter and one cycle faster by using the short form (0x00-0x1f) of literals,
; but my assembler doesn't support short form labels yet.
There were no major problems, except for some trouble with two regular expressions which broke rendering; but since those weren’t needed I could just simply remove them.
If you like to try out the language file for yourself just visit the main GeSHi site or grab a copy of the language file directly from the SVN trunk.
Als indirekte Antwort zu einem Beitrag bei Teekeks.
„Ich hasse es!“, drehte er sich um. Wieder einmal laß er entgegen seiner Überzeugung das Totholz, was sich selbst Zeitung schimpfte. Er war schnell fertig, denn außer Angst, Hass, Titten und dem Wetterbericht stand da nicht viel. Zumindest keine der relevanten Nachrichten. Zum Beispiel die explodierenden Tankstellen auf Grund explodierender Benzinpreise, oder die Arbeitslosigkeit trotz Arbeitsamt, oder der Abbau von Bürgerrechten. Frustriert presste er wortlos dem verwirrten Verkäufer die halb zerknüllte Ausgabe wieder in die Hand. Verdutzt schaute ihm der Verkäufer hinterher; jedoch ohne Kraft, seine Stimme zu erheben. Für diesen Hungerlohn war es diese Badlektüre jedenfalls einfach nicht wert. (more…)
Für manche Probleme, wie etwa die Beziehung von Katzen zur eigenen Tastatur:
Its very hard to code with one hand and pet a cat who is half on your keyboard w/ the other. I need Dan to come home, take care of the kids.
gibt es ganz einfache Lösungen:
You need the cat desk bed! (of course, cat won’t use it anyway)
(via hier und Twitter)
Graffiti sind immer wieder ein Ärgernis für das Stadtbild. Während man häufig nur irgendwelche Schmierereien mit wenigsagendem Inhalt findet, gibt es doch auch hin und wieder einmal die Künstler unter den Leuten mit der Sprayflasche. So geschehen mit einem Zug der deutschen Bahn in München, bei dem der äußere Anstrich etwas korrigiert wurde:
Na, wo würden Sie einsteigen? Na? Die richtige Antwortet lautet hier: Bei den schmalen Doppelfenstern. Wie? Schauen wir doch einmal aus einer etwas anderen Perspektive auf die Dinge:
Sollte auch dieser Blick noch nicht beim Einsteigen helfen, sollte man sich die vermeintliche Tür einmal aus nächster Nähe betrachten, denn diese ist in sich ein wahres Meisterwerk!
Schaut man genau hin, fallen der etwas zu kräftige Türöffner-Knopf und die etwas unsauber umgesetzten Gummi-Einrahmungen der Fenster zwar auf; insgesamt hat sich der Künstler aber alle Mühe gegeben. Soetwas sieht man nur selten im Stadtbild! Respekt!
Story via Firewulf, Bilder via ilovegraffiti.
Bereits seit einiger Zeit wollten sich mein Courier-IMAP(S)-Server und die Kunden-Mailclients nicht so recht vertragen. Und auch die Fehlermeldung der Mailclients war nicht so recht schlüssig, denn der Fehler trat zuerst bei einem Update von Courier 4.4 auf 4.8 auf, war dort aber im Wesentlichen durch einen Programmierfehler bedingt. Da dieser aber eigentlich in der 4.9 bereits lang behoben sein sollte, nun ja. Blieb also als einfachster Workaround ein Hold des Paketes in der alten Software-Version. (more…)
Am Samstag dem 11. September 2010 war es wieder einmal so weit. Unter dem Motto „Freiheit statt Angst“ hieß es wieder einmal Demonstrieren für mehr Bürgerrechte und weniger Überwachungsstaat. Aufgerufen wurde zu dieser Demonstration u.a. vom AK Vorrat, dem AK Zensur, dem FoeBuD, der freien Ärzteschaft, ver.di, sowie zahlreichen anderen Organisationen und Parteien, die sich dem Thema Bürgerrechte verpflichtet fühlen. Zur Demonstration kamen laut Veranstaltern etwa 7500 Bürger, die ihrem Unmut über die aktuellen politischen Entwicklungen äußern wollten. (more…)
Eine der anspruchvollsten Aufgaben in einem Netzwerk ist die Verwaltung der Teilnehmer und das Routing von Informationen zwischen diesen. Ist diese Aufgabe in klassischen verdrahteten Netzwerken noch vergleichsweise einfach zu bewerkstelligen, da sich die Netztopologie nur selten ändert und daher in den meisten Fällen statisch behandelt werden kann, herrschen in WLANs sehr dynamische Bedingungen vor. Zu jedem Zeitpunkt kann ein Client dem Netzwerk beitreten, zu einem anderen Zeitpunkt wieder verlassen, oder bei größeren Netzwerken, wie sie z.B. in Firmen und Universitäten vorkommen sogar von einem Zugangspunkt zu einem anderen umziehen.
Bei diesen vergleichsweise komplexen Netzwerken, handelt es sich immer in der Regel um Infrastruktur-Netzwerke, also solche, bei denen ein zentraler Zugangspunkt den Zugriff der Teilnehmer verwaltet, Zeitscheiben für die Datenübertragung zuteilt oder andere Management-Aufgaben, wie die Sitzungsverwaltung übernimmt. Aber nicht in jedem drahtlosen Netzwerk gibt es diese zentrale Instanz. Ein sehr gutes Beispiel hierfür sind sogenannte Ad-hoc-Netzwerke, die wie ihr Name bereits vermuten lässt ad-hoc aus dem Nichts aus aufgebaut werden können. Nehmen an solch einem Netzwerk wenige Clients teil, sehen sich diese in den meisten Fällen und abgesehen von der Vergabe der passenden Netzwerk-Parameter (BSSID, ESSID, IP der Clients, Netmask und Gateway) ist nicht sonderlich viel zu beachten.
Spannender wird es jedoch, wenn nicht mehr alle Teilnehmer jeden anderen sehen und das Ad-hoc-Netzwerk als ein Mesh-Netzwerk zu betrachten ist. Ein Projekt, was sich mit dem Betrieb solcher Mesh-Netzwerke beschäftigt, ist Freifunk, dass in einer ganzen Reihe von Städten bereits meist kleinere, teils aber auch größere Ad-hoc-Netzwerke aufzuweisen hat. In diesen Netzen muss typischerweise jeder am Routing teilnehmen, um ein Datenpaket vom Absender zum Empfänger zu befördern, da es im Gegensatz zu Infrastruktur-Netzwerken kein zentrales Routing gibt und daher sich die Clients untereinander kooperativ um alle Verwaltungsaufgaben kümmern müssen. Die Aufgabe des Routings ist dabei relativ unproblematisch über eine Reihe von Protokollen geregelt, von denen OSPF, OLSR und BATMAN die am Häufigsten eingesetzten sind. Diese funktionieren aber allesamt nur, wenn alle zu routenden Clients sich auch am Protokoll beteiligen und regelmäßig ihre Informationen dem Netz mitteilen.
Ein relativ neuer Weg, der derzeit vom Freifunk Chemnitz beschritten wird, ist es nun, auch Clients ohne Routing-Software den Zugang zum Netz zu ermöglichen. Die hierfür eingesetzte Technik des ARP-Roaming ähnelt ein wenig dem Vorgehen in Infrastruktur-Netzwerken, denn der Client wird von den Routern „verwaltet“ und wenn nötig zwischen diesen umgezogen, wenn sich seine Position im Netzwerk ändert. Damit dies auch ohne Infrastruktur-Modus in einem Ad-hoc-Netzwerk funktioniert, müssen jedoch eine Reihe von Bedingungen erfüllt sein.
Eine der wichtigsten Bedingungen, damit man einen Client ohne Probleme von einem zum anderen Router umziehen kann, ist, dass der Client möglichst wenig davon mitbekommt. Insbesondere der Standard-Gateway sollte aus Sicht des Clients an jeder Stelle des Netzes identisch sein. Zu diesem Zweck wird beim Freifunk Chemnitz im Ad-hoc-WLAN-Teil des Netzes mit einer Anycast-IP für den Standard-Gateway gearbeitet, die unabhängig vom Router, der die Anfrage des Clients empfängt immer identisch ist. Somit entfällt bei einem Handover eines Clients die Umkonfiguration von Netzwerk-Parametern.
Ein weiteres Problem, was sowohl mit dem Routing zusammenhängt, aber auch die Verwaltung der Clients betrifft ist zudem die IP-Adress-Vergabe. Man könnte theoretisch zwar einen zentralen DHCP-Server nehmen und auf Layer 2 (Ethernet-Ebene) routen, hätte dann aber sofort einen Netzausfall, wenn der Client sich in einem Teil des Netzwerkes anmeldet, der gerade keine Verbindung zum DHCP-Server besitzt. Der gegenteilige Weg, also dass jeder Router auch gleichzeitig DHCP-Server spielt, scheint zwar übertrieben, birgt aber andererseits einen Reihe essentieller Vorteile, die man für die Netzwerk-Verwaltung benutzen kann. Damit nun auch ein einzelner, nicht gerade mit dem Rest des Netzwerkes verbundener Knoten noch operativ bleibt, muss jeder der DHCP-Server autark und autoritiv entscheiden können. Da er dies für den gesamten im Netzwerk verwendeten Adressbereich nicht autark tun kann, muss jedem DHCP-Server ein eigener Adressbereich zugeteilt werden, den dieser autonom verwalten darf. Zu diesem Zweck wird der gesamte für das WLAN vorgesehene Adressbereich noch einmal in Subnetze unterteilt. Im Fall von Freifunk Chemnitz handelt es sich hierbei um ein /17-Netz für WLAN, welches in /28-Netze für jeden Router aufgeteilt wird. Da sich einige Clients etwas zickig haben, wenn der DHCP-Server aus einem anderen Subnetz kommt, ist eine der IPs dieses /28-Netzes für den DHCP-Server des Routers zugewiesen.
Wäre noch ein letzter Aspekt kurz zu erwähnen: Nämlich das Backbone-Netzwerk, welches von den Nodes untereinander verwendet wird, um das Netz auch beim Zusammenbruch direkter Funkstrecken (z.B. Sichverbindungen, Richtfunk) über alternative Wege, wie eine VPN-Verbindung über UMTS) am Leben zu halten. Da auch diese Struktur sehr dynamisch sich ändert, wird dieser gesamte Netzbereich (beim Freifunk Chemnitz ein /21) mit OLSR verwaltet.
Somit besitzt jeder Node, der am Routing teilnimmt folgende 4 Angaben:
Diese gehören zu den folgenden 2 Netzwerken:
Betrachtet man sich das Netzwerk bisher, so ist dieses noch sehr unflexibel: Möchte ein Client umziehen, muss er, trotz dem er an jedem Router Pakete in das Netzwerk senden kann, zum Empfang der Antwort immer in Reichweite des Knotens bleiben, der ihm seine IP zugeteilt hat, da bedingt durch die im Routing bekanntgegebenen Subnetze alle Pakete des WLAN immer wieder zu dem Knoten, der die IP vergeben hat, zurück geroutet werden.
Soviel zum Vorgeplänkel; tut mir echt leid, dass ich etwas ausholen musste, aber der spannende Teil kommt nun!
OLSR bietet nun die Möglichkeit, die an jedem Knoten angeschlossenen „Netzwerke“ – sogenannte Host-Network Associations – bekanntzugeben. Neben ganzen Subnetzen funktioniert dieser Mechanismus nun auch für einzelne IPs, womit es möglich wird, einen Client, der von seinem Heimat-Knoten entfernt im Netzwerk lebt – ähnlich dem Roaming im Telefonnetzen – an seiner fremden Basisstation zu erreichen. Dies funktioniert, weil Hostrouten immer Vorrang vor Netzwerk-Routen haben und diese somit überschreiben.
Wenn man nun einen Client von einem zum anderen Knoten im Netzwerk umziehen kann, ist als letzter Schritt für eine Automatisierung dieses Vorgangs zu sorgen, da der Client möglichst nichts davon mitbekommen soll. Damit man aber von Seite der WLAN-Knoten weiß, dass nun plötzlich ein Knoten in Reichweite ist, muss eine Möglichkeit gefunden werden, die Clients der Umgebung zu beobachten und die Verbindungsqualität zu bewerten. Ein einfacher Ansatz ist derzeit bereits im Netz von Freifunk Chemnitz umgesetzt und betrachtet den Inhalt der ARP-Tabelle der Router als Quelle für neue Clients. Wird dort ein neuer Client entdeckt, wird durch einen ARP-Ping geprüft, ob dieser wirklich in der Nähe ist und im Erfolgsfall als Client im OLSR registriert, um dem Netzwerk Bescheid zu geben, dass dieser Knoten den neu gesichteten Client empfangen kann. Schlegt ein ARP-Ping fehl, so wird nach einem Timeout erneut versucht diesen Client zu erreichen bzw. nach einer einstellbaren Anzahl Fehlversuche der Client als unerreichbar wieder entfernt.
Auch wenn dieser bisher noch recht passive Versuch der Client-Erkennung beim Umzug von Clients eine Reihe kleinerer Nebenwirkungen besitzt, was sich i.d.R. durch Nicht-Erreichbarkeit des Clients äußert, funktioniert dieser Ansatz in der Praxis bereits vergleichsweise gut für das noch sehr frühe Entwicklungsstadium: Immerhin wird hier auf Software-Ebene nachgebildet, was typischerweise die Netzwerk-Hardware erledigt. Weitere Ausbaustufen umfassen daher auch Dinge wie eine verbesserte Erkennung neuer Clients bereits anhand ihres Traffics, bzw. ein dem ARP-Spoofing entlehntes zwangsweises Umziehen des Standard-Gateway für einzelne Clients. Auch eine proaktive Erkennung der Bewegung eines Clients zwischen den Routern und eine dieser Bewegung angepasste vorausschauendes Handover des Clients sind Dinge, die auf der Wunschliste bereits heiß diskutiert werden und in spätere Versionen durchaus einfließen werden. Mehr dazu aber in einem gesonderten Beitrag, da jedes dieser Themen eine ganze Menge Aspekte berührt, die weit über den Umfang dieses Eintrags hinausgehen würden.
Powered by WordPress
