My Universe Logo

My Universe Blog

Octopress als Alternative?

Posted by Jesco Freund at Sept. 29, 2011 6:30 p.m.

In Website, Quo Vadis? ging es um vage Ideen und Möglichkeiten, diese Website auf ein neues Fundament zu stellen. Eine der Überlegungen ging in die Richtung, Inhalte künftig in einem Versionsverwaltungssystem anstelle einer relationalen Datenbank zu speichern. Kurz darauf wurde ich auf Octopress aufmerksam gemacht. Auf den ersten Blick nahezu das, was ich wollte. Auf den zweiten Blick ergaben sich jedoch einige Einschränkungen und Mängel:

  • Octopress generiert statische Inhalte client-seitig, es wird also auf dem Rechner eine Octopress-Installation benötigt, auf dem die Inhalte verfasst werden.
  • Das Deployment erfolgt (anders als die Speicherung der Inhalte) nicht über Git (bzw. Commit & Push), sondern über ein separates Skript
  • Octopress versteht nur Markdown, Textile und vor allem RST werden derzeit nicht unterstützt
  • Octopress arbeitet rein statisch, besitzt also nicht selbst die Fähigkeit, Kommentare entgegen zu nehmen
  • Ein Plugin für eine Tag-Cloud scheint es nicht zu geben

Gewiss, einige der genannten Einschränkungen ließen sich umgehen. So könnte Octopress auch serverseitig installiert und der Generator nebst Deployment Skript über einen post-receive hook aktiviert werden. Einen Konverter von RST nach Markdown könnte ich mir sicherlich auch zusammenbasteln, um den bestehenden Content in einer Einmal-Aktion zu konvertieren. Die anderen beiden Einschränkungen sind für mich aber nicht so einfach zu umgehen.

Mir widerstrebt es zutiefst, ein externes Kommentarsystem à la Disqus o. ä. einzusetzen (siehe dazu Link 1, Link 2, Link 3, Link 4, Link 5). Ich müsste also einen eigenen Webdienst aufsetzen, der Kommentare per Javascript-API zugänglich macht – nicht unbedingt ideal, und vermutlich auch schwer gegen Mißbrauch abzusichern.

Hinzu kommt, dass Octopress in Ruby geschrieben ist. Nichts gegen Ruby, aber ich kann diese Sprache einfach nicht. Meine Welt (in Sachen Programmiersprachen) besteht aus C und Python, POSIX-Shell ist auch noch drin. So kann ich mir nicht einfach fehlende Plugins selbst schreiben – zumindest nicht, ohne mich erst in eine neue Sprache einzuarbeiten.

Fazit: Octopress kommt einer idealen Lösung schon recht nahe, hat aber einige Schwächen, die mich momentan veranlassen, weiterzusuchen – und notfalls selbst etwas zusammenzustöpseln.

No comments | Defined tags for this entry: blog, Git, Web 2.0

Neues von der Webbug-Front

Posted by Jesco Freund at Sept. 25, 2011 11:23 a.m.

Offenbar waren einige Zeitgenossen naiv genug zu glauben, dass remote eingebundene Webbugs keinen Veränderungen unterliegen können. In diesem Fall war es Facebook, genauso gut hätte es ein beliebiger anderer Tracker sein können. Spannend finde ich den Kommentar eines (angeblichen) Facebook-Mitarbeiters (sinngemäß wiedergegeben):

Wir haben das gemacht, weil wir davon ausgehen, dass unsere User das gerne möchten. Wer das nicht mag, kann es ja nachträglich abschalten.

Sorry Leute, wenn euch so etwas überrascht, dann habt ihr einfach ein paar Jahre tief und fest gepennt. Unternehmen wie Facebook, Google, LinkedIn und wie sie alle heißen leben davon, Daten über euch (und andere) zu sammeln. Schon rein unter ökonomischen Gesichtspunkten könnt ihr nicht erwarten, dass die ihre Dienste an euch verschenken, ohne eine Gegenleistung zu erhalten. Das heißt nicht, dass diese Unternehmen böse sind – es bedeutet schlicht, jeder muss wissen, worauf er sich einlässt, wenn er mit einem solchen Unternehmen eine Geschäftsbeziehung eingeht (nichts anderes ist ein Facebook-Account).

Ein Nachsatz in eigener Sache: Die Geschichte bestärkt mich in meiner Haltung, Webbugs grundsätzlich abzulehnen. Sie zwingen dem Besucher einer Seite etwas auf, das dieser eventuell gar nicht wollte. Ich möchte selbst entscheiden, mit welchem Unternehmen ich eine Geschäftsbeziehung eingehe – und möchte sie nicht heimlich durch einen (unsichtbaren) Tracker untergejubelt bekommen. Die Pest auf Seiten der Website-Betreiber auszurotten habe ich mittlerweile als Utopie zu den Akten gelegt – bleibt also nur noch, browser-seitig gegen allzu viel Neugier aufzurüsten…

No comments | Defined tags for this entry: privacy, Web 2.0, advertising

Website, Quo Vadis?

Posted by Jesco Freund at Sept. 17, 2011 12:01 a.m.

Vor etwas über einem Jahr ging das erste Posting mit der selbst gebauten Software auf Django-Basis online. Einiges hat sich bewährt (z. B. reStructuredText als Eingabeformat für Inhalte), anderes eher nicht (z. B. mehrsprachige Einträge – nutze ich so gut wie nicht, daher hätte ich mir die damit einhergehende Komplexität auch sparen können).

Nun ist auf jeden Fall eine Renovierung fällig. Django hat sich weiter entwickelt, und bis auf kleine Bugfixes habe ich mein Backend nie an die Neuerungen in Django angepasst. Die Kommentarfunktion musste zwischenzeitlich deaktiviert werden, weil ich keine adäquaten Spamschutzmaßnahmen vorgesehen hatte, und die Templates schreien ebenfalls nach Aufmerksamkeit. Auch im Hintergrund ist einiges zu tun: der selbstgestrickte Feedgenerator ist auf Dauer keine optimale Lösung, und die Hacks rund um den RST-Renderer sind ebenfalls dazu angetan, mir einiges Unbehagen zu verursachen. Und nicht zuletzt ist da noch der Ärger mit Redmine, der nach einer Lösung verlangt.

Doch wie soll es weitergehen? An der bestehenden Software weiterflicken, oder zumindest einzelne Teile herausreißen und neu schreiben? RST würde ich gerne weiter beibehalten, aber Textile und Markdown wären eine nette Ergänzung. Ansich ließe sich das problemlos in die bestehende Software integrieren, allerdings spukt mir in letzter Zeit auch eine andere Idee im Kopf herum.

Ausgehend von der Erkenntnis, dass relationale Datenbanken nicht der ideale Speicherort für größere Textdokumente sind, liebäugele ich mit der Idee, die Inhalte der Website einfach als Textdateien in einem SCM wie etwa Git abzulegen. Daraus ergeben sich jedoch neue Fragen und Herausforderungen, etwa wie in so einem Fall Tags realisiert werden können, oder wie genau die Erzeugung von HTML erfolgt – statisch über Hooks beim committen, oder dynamisch bei der Seitenauslieferung? Wie dynamisch muss die Website dabei überhaupt noch sein – und kann dann auf ein Framework wie Django verzichtet werden? Wie steht es dann um andere Bestandteile der Website – existierende und künftig geplante?

Wie man sieht, sind derzeit viele Fragen offen. Vielleicht finden sich im Laufe der nächsten Wochen einige Antworten, vielleicht ergeht es mir am Ende auch wie Kris, der vor einiger Zeit ebenfalls über seinen „Blog-Stack“ nachdachte (Link 1, Link 2) – und am Ende doch alles beim Alten ließ.

No comments | Defined tags for this entry: blog, Django

Redmine ist kaputt

Posted by Jesco Freund at Sept. 14, 2011 8:45 p.m.

Schienen scheinen ein gefährlicher Ort zu sein, um darauf herumzusitzen. So oder so ähnlich sah es wohl auch der Ports-Maintainer für diverse rubygem-Ports (unter FreeBSD), der kurzerhand diverse Versionsupgrades eingespielt hatte – jedoch ohne vorher zu testen, ob die bestehenden RoR-Applikationsports (wie etwa der Redmine-Port) mit den geänderten Versionen klar kommen.

Ergebnis: Kein Eintrag in UPDATING, der auf die drohende Gefahr hinwies, und Redmine mehrere Tage später als BROKEN getagged – da war's aber schon zu spät. Mein Redmine-Jail ist perdu, und auch die Backups nutzen nichts – die Daten und Konfigurationseinstellungen sind ja nicht futsch, sondern die Software selbst. Meine Projekt-Unterseite ist daher bis auf weiteres nicht erreichbar.

OK, das ist kein Beinbruch, damit kann ich leben. Allerdings habe ich auf meinem Server weitere Redmine-Instanzen, darunter RootUtils, die Entwicklungsplattform der RootForum-Community. Zwar habe ich dort das mörderische Upgrade schön bleiben lassen, so dass diese Instanzen weiterhin erst mal funktionieren, aber auf Dauer ist das keine Lösung, da die jetzt installierten alten Versionen über die Ports-Sammlung nicht mehr gepflegt werden. Über kurz oder lang muss also eine andere Lösung her, wobei ich nur ungern die Ports umgehen und Software manuell einspielen möchte – das wäre in Sachen Wartbarkeit eine herbe Einbuße.

No comments | Defined tags for this entry: FreeBSD, ports, rant, Redmine

Chilis für Beastie

Posted by Jesco Freund at Sept. 3, 2011 10:20 p.m.

Das Computer Laboratory der Universität Cambridge hat ein Framework namens Capsicum entwickelt, mit dem das Konzept der Capability-based Security aufgegriffen und neu interpretiert wird. Ähnlich der in Draft 1003.1e vorgeschlagenen POSIX Capabilities (dieser Draft wurde jedoch zurückgezogen) erweitert Capsicum zwei zentrale Kernel-Objekte um mehrere Capability-Eigenschaften, nämlich Prozesse und Dateideskriptoren.

Damit ließe sich schon ein recht effektives Sandboxing umsetzen, aber Capsicum geht noch einen Schritt weiter: neben einem neuen Laufzeit-Linker, der die Umsetzung des Prozess-Sandboxings tatsächlich implementiert, führt Capsicum auch gleich noch eine neue Klasse von Speicherobjekten ein: Anonyme Shared Memory Objekte ermöglichen die Erzeugung anonymer Swap-Objekte, die an einen Capability-kontrollierten Dateideskriptor geknüpft werden. Mit dieser Technik lassen sich auch Applikationen in eine Sandbox stecken, die sonst aufgrund der Nutzung von Shared Memory sogar mit Jails nur schwer in den Griff zu bekommen waren (wie etwa PostgreSQL).

Dass Capsicum mittlerweile mehr als nur Proof of Concept ist, belegt die Tatsache, dass Capsicum Bestandteil der in Vorbereitung befindlichen Version 9 von FreeBSD geworden ist. Natürlich wird sich Capsicum noch in der Praxis bewähren müssen – in der Theorie ist es aber auf jeden Fall eine hochinteressante Sache und ermöglicht, auch die Prozesse an die Kandare zu nehmen, die aus praktischen Erwägungen heraus nicht in einem Jail gekapselt werden können (wie etwa der für den administrativen Zugang laufende sshd).

No comments | Defined tags for this entry: FreeBSD, security

Fedora: Bilanz nach einem Monat

Posted by Jesco Freund at July 31, 2011 8:14 p.m.

Seit etwa einem Monat arbeite ich jetzt mit Fedora auf dem Notebook – Zeit, eine Zwischenbilanz zu ziehen. Vergleichen kann ich Fedora derzeit am besten mit Arch Linux und FreeBSD, die bei mir ebenfalls auf Desktop-Systemen in Betrieb sind.

Neben normalem Office-Kram (E-Mail, Textverarbeitung, Tabellenkalkulation) nutze ich das Notebook vor allem für diverse Internet-Aktivitäten und Software-Entwicklung. Nebenher muss das Gerät auch noch für Entertainment sorgen – sprich: Musik abspielen, und ab und zu mal ein Video zerpflücken.

Zunächst ein Wort zum Paketmanagement, bevor ich auf die einzelnen Teilbereiche eingehe: PackageKit habe ich mir ganz schnell abgewöhnt. Mag sein, dass ich durch portmaster und pacman zu lange verwöhnt wurde – ich empfinde es jedoch um Längen schmerzärmer, yum direkt auf der Kommandozeile zu nutzen.

continue reading Fedora: Bilanz nach einem Monat

No comments | Defined tags for this entry: Fedora, Linux, open source

Fedora wird 15: Lovelock für's Notebook

Posted by Jesco Freund at July 2, 2011 12:58 a.m.

/assets/user/jfreund/img/png/thumb/256x256/screen-fedora15-kraehenfels.png

Heute bekam mein Notebook ein neues Linux spendiert: nachdem zuletzt unter Arch Linux die LXDE-Pakete immer schlechter funktionierten und die Gnome 3 Integration auch nicht ganz so der Hit war, habe ich mich entschlossen, Fedora mal eine Chance zu geben. Für die Ubuntoiden habe ich ja generell nichts übrig, und Ubuntu's Eigenbrödlerei mit Unity ist nicht gerade dazu angetan, daran etwas zu ändern. Doch ich schweife schon wieder ab… ;-)

Gesucht war also eine Linux-Distribution (BSD auf dem Notebook hat dann doch zu viele Ecken und Kanten für den alltäglichen Gebrauch) mit halbwegs aktueller Paketauswahl und einem Gnome-basierten Desktop. Da ich viel mit Kdevelop arbeite, war mir hier ein aktuelles Paket besonders wichtig (4.2.x sollte es schon sein). Außerdem hatte ich mir vorgenommen, um Bastelkram und Exoten einen großen Bogen zu machen – so blieb am Ende nur Fedora 15 (übrigens: der Codename „Lovelock“ bezieht sich auf die gleichnamige Stadt in Nevada).

Vom ersten Eindruck her gefällt mir Fedora. Der Installer ermöglicht auch individuellere Setups mit dm-crypt und Logical Volumes – leider längst keine Selbstverständlichkeit! Außer der Tastaturbelegung musste ich nichts konfigurieren; sämtliche Hardware (incl. Sound, WLAN und Webcam) liefen out-of-the-box. Sogar der per KVM angeschlossene Zusatz-Monitor wurde anstandslos erkannt und automatisch als Zweitdisplay konfiguriert. Außerdem scheint es kein Problem zu sein, das System „zu Fuß“ (also per vi ;-)) zu administrieren – andere Distributionen reagieren da mitunter allergisch drauf.

Von der Paketauswahl scheint alles da zu sein, was ich für die tägliche Arbeit benötige. Gut, ganz so blutige Kante wie Arch Linux ist Fedora nicht, aber dafür wirken die Pakete in ihrer Abstimmung aufeinander etwas runder. Fehlende .desktop-Dateien sind mir bisher jedenfalls noch nicht untergekommen, und auch sonst sind die meisten Pakete unmittelbar nach ihrer Installation benutzbar. Allerdings ärgert mich der Paketmanager ein kleines bisschen: anders als pacman belastet yum die CPU viel stärker und bringt die Lüfter zum jaulen.

Unter'm Strich sieht Fedora momentan recht vielversprechend aus – es funktioniert einfach, erfüllt aber auch individuelle Wünsche. Als besonders wohltuend empfinde ich dabei, dass Fedora die Philosophie der integrierten Pakete (wie etwa Gnome) nicht auf den Kopf stellt, sondern einfach beibehält.

No comments | Defined tags for this entry: Fedora, Linux

Synctory Stepping towards Release

Posted by Jesco Freund at June 19, 2011 8:36 p.m.

Synctory (or libsynctory) is the project I'm currently spending most of my leisure time on. Basically, it implements algorightms similar to librsync. Originally, I developed libsynctory as part of a backup software project, but later decided to continue it as a separate library. The first code was written during my last summer holiday in Denmark, and since then, a lot (of the code) has changed.

Now, after almost one year of rather less steady development, libsynctory is stepping towards release maturity. Today I finally managed to commit a performance test to evaluate how fast libsynctory actually works. Though I immediately discovered a memory leak bug which is not resolved yet, the performance seems to be somewhat satisfactory for a first approach (average runtime in seconds):

+-------------+---------+---------+---------+---------+
|             | small   | big     | huge    | giant   |
+-------------+---------+---------+---------+---------+
| fingerprint |    0.01 |    6.67 |   33.94 |   67.94 |
+-------------+---------+---------+---------+---------+
| diff        |    0.04 |   31.99 |  144.99 |  303.08 |
+-------------+---------+---------+---------+---------+
| synth       |    0.02 |   14.11 |   81.01 |  152.82 |
+-------------+---------+---------+---------+---------+

The test was taken by a constant chunk size (512 bytes) for all four file sizes (0.5 MiB, 0.5 GiB, 2.5 GiB, 5.0 GiB). For me, the results illustrate two main conclusions: First, the algorithms of libsynctory seem to scale linearly with the file size (however I would have been surprised if they didn't), and secondly, bigger files require larger chunk sizes to allow a runtime-friendly processing. Therefore, I think the decision to allow individual chunk size adjustmens was a good one.

The way forward seems to be clear by now – some bugs to fix, some man pages to write, and then I'll hopefully be able to produce a first release of libsynctory. As (almost) always in open source projects, any help is appreciated, particularly I am looking for testers on Linux and OpenSolaris. So if you have some spare time, don't hesitate to contact me!

No comments | Defined tags for this entry: development, open source, synctory

H.A.W.X. 2

Posted by Jesco Freund at June 15, 2011 10:19 p.m.

Als passionierter PC-Pilot (seit MS Flight Simulator 3.0) kam ich an beiden H.A.W.X-Teilen einfach nicht vorbei. Der erste Teil war allerdings eine herbe Enttäuschung: Völlig unrealistische Flugphysik gepaart mit mäßiger Grafik und viel zu einfachen Missionen haben das Teil recht fix wieder in der Schublade verschwinden lassen. Die Flugzeugmodelle unterschieden sich im Flugverhalten so gut wie gar nicht, nur die Höchstgeschwindigkeit und die Bewaffnung war entsprechend unterschiedlich. Ziemlich deutlich, dass dieses Spiel nicht als Flugsimulation, sondern mehr als Ego-Shooter konzipiert war.

Diese Kritik hat sich der Hersteller für den zweiten Teil glücklicherweise zu Herzen genommen – H.A.W.X. 2 hat eine deutlich realistischere Flugphysik. Strömungsabriss infolge überzogener Flugzustände erfolgen nun auch im „normalen“ Modus, und das Zusammenspiel zwischen Quer- und Seitenruder wirkt jetzt wenigstens ein bisschen realistisch. Größtes Manko ist in meinen Augen nun die Schubregelung: de facto regelt man nicht den Schub, sondern die Geschwindigkeit (Schubreduzierung führt zu einer regelrechten Bremsung). Das war im ersten Teil schon genauso schlecht umgesetzt und hat sich im zweiten leider nicht gebessert.

Bei den Sichten und der Grafik hat sich jedoch einiges getan: die Standard-Perspektive ist jetzt die Cockpit-Sicht, mit der Folge, dass die (meisten) Cockpits jetzt detailgetreuer dargestellt werden. Die Flugzeuge unterscheiden sich jetzt auch deutlich in Instrumentierung und Flugverhalten. Geradezu herausragend sind die Geländetexturen: Sehr realistisch und „echt“ – das ist für mich Benchmark, so eine gute Geländedarstellung habe ich bisher in keinem Flugsimulator (ob militärisch oder zivil) zu Gesicht bekommen.

Die Kampagne besteht – ähnlich wie im ersten Teil – aus aufeinander aufbauenden Missionen. Anders als im ersten Teil sind einige der Missionen tatsächlich etwas kniffeliger. Insbesondere die fortgeschritteneren Missionen bieten eine nette Herausforderung; vor allem wenn man sie mit nicht dafür vorgesehenen Flugzeugtypen oder Bewaffnungen absolviert. Allerdings gilt auch hier: die Kampagne ist sehr schnell durchgespielt. Zwar lassen sich alle Missionen mehrfach spielen, aber leider kann man bei einigen nicht mal den Flugzeugtyp wechseln - unter Abwechslung stelle ich mir da etwas anderes vor…

Alles in allem macht H.A.W.X. 2 einen durchwachsenen Eindruck auf mich. Zugegeben, der Spaßfaktor beim rumzischen und -ballern in der grandios dargestellten Landschaft ist hoch, besonders mit selbst zusammengestellter Bewaffnung (mein Favorit: Eurofighter mit 4fach-Geschütz und Luftkampfraketen). Wie lange das Spiel bei mir noch angesagt ist, bleibt allerdings abzuwarten: die Kampagne ist längst durch, alle Flugzeuge sind freigeschaltet und auch die Arkade-Missionen bringen keine Abwechslung mehr. Online-Dogfights wären eine willkommene Abwechslung – leider wird das Spiel wenig online gespielt, so dass man selten mal in eine Partie einsteigen kann.

No comments | Defined tags for this entry: flight simulation, aircraft, computer games

Oneliner für Bogus-IPs

Posted by Jesco Freund at April 30, 2011 11:34 a.m.

Aus der Kategorie „nützliche Oneliner“:

awk '/receive|Invalid/ {print $NF}; /reverse/ {print substr($12,2,length($12)-2)}; /not allowed/ {print $9}' /var/log/auth.log | sort -nu

Damit erzeugt man eine Liste von IP-Adressen, die in letzter Zeit (soweit das Logfile eben reicht) ungebetenerweise Zugriff auf SSH haben wollten. Zugegeben: Der Nutzen einer solchen Liste ist eher begrenzt; man könnte damit (und z. B. in Verbindung mit GeoIP) eine Statistik füttern, automatisierte Abuse-Meldungen verschicken, etc.

alert Auf keinen Fall, unter gar keinen Umständen sollte man auf die blöde Idee kommen, damit automatisch den Zugriff auf SSH zu blockieren – sei es nun per Paketfilter, oder per TCP Wrapper.

No comments | Defined tags for this entry: awk, security, shell