Skip to content

Osterformel nach Gauß und Lichtenberg

In der Wikipedia ist eine praktische Formel zu finden, die in ihrer ursprünglichen Fassung von Carl Friedrich Gauß stammt und die es ermöglicht, das Datum des Ostersonntags für jedes Datum von 1582, dem Jahr der Einführung des Gregorianischen Kalenders, bis weit in die Zukunft zu berechnen.

Da der Ostersonntag stets der erste Sonntag nach dem ersten Frühlingsvollmond ist und sich die Umlaufzeiten von Erde und Mond so schnell nicht ändern, hält sich der Rechenaufwand in Grenzen.

Mond zu Ostern
Die ursprüngliche Gauß-Formel deckte nur einen begrenzten Jahresbereich ab. 1997 ergänzte sie Heiner Lichtenberg so, dass sie für alle Jahre des Gregorianischen Kalenders zu verwenden ist.
Hier die Umsetzung der Gaußschen bzw. Lichtenbergschen Osterformel als Python-Programm:

"Osterformel nach Gauß und Lichtenberg" vollständig lesen

Das Alter von Klimaaktivistinnen

Die bekannteste 16-jährige Schwedin der Welt wurde heute 17 Jahre alt. Damit sind nun alle Texte, die auf die „16-jährige Klimaaktivistin“ verweisen, offiziell veraltet.

Da es für die deutschsprachige Presse bei Klimaaktivistinnen anscheinend immer wichtig ist, wie alt diese sind, habe ich mal gezählt, wie viele Google-Fundstellen es bei der Suche nach der Phrase "n-jährige Klimaaktivistin" für alle n von 1 bis 100 gibt. Falls nur ein Name auf der ersten Suchergebnisseite auftaucht, ist dieser im Diagramm vermerkt.

Diagramm "Das Alter von Klimaaktivistinnen" vollständig lesen

Kommentare zum Python-3-Buch

Im letzten Semester habe ich erstmals mein Buch „Grundlagen der Ingenieurinformatik mit Python 3“ online gestellt. Das Buch steht unter einer Creative-Commons-Lizenz und darf (bei Namensnennung) beliebig weitergegeben werden. Das führt nun dazu, dass es auch von vielen außerhalb der eigentlichen Zielgruppe (den Bauingenieurstudenten der Hochschule Bochum) gelesen wird. Mich interessiert, wie jemand den Text wahrnimmt, der nicht die dazu gehörende Vorlesung besucht hat. In der PDF-Datei befindet sich daher auf der letzten Seite ein Link auf diesen Blogeintrag mit der Bitte um Kommentare – zu denen ich hiermit herzlich einlade.

Rhythmbox-Plugin "edit file" zum Bearbeiten von MP3- und OGG-Dateien

Im Musik-Abspielprogramm Rhythmbox fehlte mir seit jeher eine Funktion, um das gerade ausgewählte Musikstück in einen Editor zu laden. Sei es, um die Lautstärke anzupassen, aus einer Aufnahme unerwünschte Ansagen herauszuschneiden oder um einfach nur mal mit ein paar Filtern herumzuexperimentieren. Eine ausgedehnte Websuche führte mich zwar nicht zum Ziel, wohl aber zum Plugin "Open Folder" von Adolfo González Blázquez. Dieses öffnet den Ordner der gerade ausgewählten Datei mit dem Standard-Dateimanager, z.B. Nautilus. Ich musste lediglich drei Zeilen ändern, um meine lange vermisste Editierfunktion zu bekommen. Ich habe mir in dieser allerersten Version 0.1 (erschienen im Oktober 2009) die Arbeit recht einfach gemacht, indem ich gar nicht erst teste, welches der vom System als Standard vorgesehene Editor für Musikdateien ist, sondern das Plugin ruft einfach "audacity" über seinen Namen auf. Wer mag, darf gerne noch etwas an dem Programm herumfeilen.

Im Mai 2011 wurde für Rhythmbox 0.13 unter Ubuntu 11.04 (Natty Narwhal) eine winzige aber funktionsentscheidende Änderung notwendig. Anstelle von shell.get_property("selected_source") heißt es im Quelltext an einer Stelle nun shell.get_property("selected_page"). Diese Version des Plugins ist unten als rb-edit-file_0.2.zip aufgeführt. Ein großes Dankeschön an Erik Lundmark für den Hinweis auf die Fehlermeldung!

Screenshot Rhythmbox-Plugin "edit file"
Selbstverständlich ist meine Variation ebenfalls wieder Open Source.

Zur Installation unter Ubuntu Linux mit Gnome-Desktop ist lediglich der Inhalt der ZIP-Datei in den Ordner ~/.gnome2/rhythmbox/plugins/rb-edit-file zu entpacken und Rhythmbox neu zu starten. Unter "Bearbeiten – Plugins" muss dann nur noch ein Häkchen bei "Edit file" gesetzt werden. Im Kontextmenü jedes Musikstücks taucht nun der Menüpunkt "Edit file" auf.

Download
rb-edit-file_0.2.zip (Rhythmbox 0.13 ab Ubuntu 11.04 Natty Narwhal)
rb-edit-file_0.1.zip (Rhythmbox 0.12 bis Ubuntu 10.10 Maverick Meerkat)

Fortschrittsanzeige für dd beim Backup großer Festplatten

Wer schon einmal komplette Festplatten mittels dd kopiert hat (siehe unten), fragte sich wahrscheinlich nach spätestens einer halben Stunde, ob das Programm wirklich was tut und wenn ja, wie lange noch. Das unkomplizierteste aller Backupprogramme zeigt leider weder Fortschrittsbalken noch andere Statusinformationen an. Man kann es aber dazu bringen, eine Meldung über die bereits kopierte Datenmenge, die verstrichene Zeit und den durchschnittlichen Datendurchsatz auszugeben. Dazu öffnet man ein zweites Terminalfenster und gibt dort folgendes ein:
sudo kill -SIGUSR1 $(pidof dd)

Um alle 10 Sekunden über den Verlauf der Datensicherung informiert zu werden, kann man den Aufruf auch in eine kleine Schleife packen:
while /bin/true; do sudo kill -SIGUSR1 $(pidof dd); sleep 10; done

Nun gibt dd solange Statusmeldungen aus, bis die Schleife mittels Strg-C abgebrochen wird.

Nachtrag (24. Mai)
Den Referrern nach zu urteilen, schickt Google mir gerade etliche Anwenderinnen und Anwender, die wissen möchten, wie man komplette Festplatten unter Linux kopiert. Das ist ganz einfach. Angenommen, die vorhandene Festplatte, die kopiert werden soll, heiße /dev/sda und die Platte, auf die kopiert werden soll, sei /dev/sdg, so lautet der Kopierbefehl schlicht:
sudo dd if=/dev/sda of=/dev/sdg

Die Namen der Festplatten bekommt man beispielsweise mittels
sudo fdisk -l
heraus.

Beim Kopieren muss unbedingt darauf geachtet werden, dass die neue Festplatte mindestens so groß ist wie die alte. Und, ganz wichtig: dd fragt nicht "sind Sie sicher?" - es fängt einfach an zu kopieren. Wer sich mit der Angabe der Zielfestplatte vertut, ruiniert innerhalb von Sekunden sämtliche Daten, die dort gespeichert sind.

Wie man Google Maps ganz einfach in ein Blog einbinden kann

Um Kartenausschnitte aus Google Maps in ein Blog einzubinden, gibt es drei Möglichkeiten, die bisher mehr oder weniger problematisch waren.

Am einfachsten und dümmsten ist das Anfertigen und Hochladen von Bildschirmkopien, was in der Vergangenheit bereits zu Abmahnungen in vierstelliger Höhe geführt hat, weil der feine Unterschied zwischen einer kopierten Grafikdatei und eingebundenen Serverdaten nicht beachtet wurde.

Die zweite Möglichkeit, zu der Google selbst einlädt, ist das Einbinden eines HTML-Code-Schnipsels, der – vereinfacht ausgedrückt – ein Fenster (Iframe) auf das Google-Maps-Angebot öffnet. Diese Methode ist jedoch auf nichtgewerbsmäßige Webauftritte beschränkt. Es gibt daher ein Problem, sobald der eigene Webauftritt durch Werbung unterstützt wird. Unabhängig davon, ob die Werbeeinnahmen aufs eigene Konto gehen oder in die Taschen eine "Gratis"-Hosters fließen, können solche Seiten als gewerbliche Webauftritte zählen.

Für all jene Webschaffenden, die nicht über vollkommen einnahmenfreie Seiten verfügen, hat Google eine Programmierschnittstelle entwickelt, das sogenannte Google Maps API. Dieses wird nicht nur für rechtlich unbedenklich gehalten (auch von mindestens einem Juristen) und ist deutlich vielseitiger in den Gestaltungs- und Interaktionsmöglichkeiten, sondern hier wird auch jedem Webmaster ein eindeutiger Schlüssel zugeordnet, sodass Google die volle Kontrolle über die Auslieferung oder Nichtauslieferung der Karteninhalte behält und bei zu intensiver Nutzung Ausgleichszahlungen aushandeln oder aber gezielt Inhalte sperren kann. Diese dritte Lösung wäre perfekt für Blogs geeignet, eröffnet aber wiederum das Problem, dass Javascriptcode sowohl in den unsichtbaren Kopf- als auch in den Inhaltsbereich der Seite eingefügt werden muss. Wer mit einer fertigen Blogsoftware arbeitet, möchte aber wahrscheinlich nur ungern Googles Javascriptdateien in die Vorlagendateien einbinden, damit nicht bei jedem Seitenaufruf erst einmal haufenweise fremder Code durch die Gegend geschoben werden muss, der zudem nur dann wirklich benötigt wird, wenn auf der jeweiligen Blogseite tatsächlich auch ein Kartenausschnitt dargestellt wird.

Für die von mir verwendete Blogsoftware (Serendipity) gibt es zwar ein fertiges Google-API-Plugin von Zoran Kovacevic, das erlaubt jedoch nur die Darstellung eines für alle Seiten gleichen Kartenausschnitts in der Seitenleiste. Das ist nett für Blogs, die sich mit einem geografisch eng begrenzten Gebiet befassen, ich fand es jedoch für meine Zwecke ungeeignet.

Um aus dieser Zwickmühle zu entkommen, kann man nun die Möglichkeiten, die Google mit der Nutzung des API anbietet, mit der Einfachheit, die das Iframe-Codeschnipsel der bekannten Google-Maps-Seite bietet, kombinieren. Man benötigt dazu nur eine einzige zusätzliche Datei im Startverzeichnis des Blogs, die den ganzen API-Code enthält.

Der folgende Code könnte beispielsweise unter dem Namen "map.php" auf dem Webserver des Blogs abgelegt werden:

<head>
<script
 src="http://maps.google.com/maps?file=api&amp;v=2&amp;key=LANGEKRYPTISCHEZEICHENFOLGE"
 type="text/javascript">
</script>
<script
 type="text/javascript">
 function initialize() {
 if (GBrowserIsCompatible()) {
  var map = new GMap2(document.getElementById("karte"));
  map.setCenter(new GLatLng(<?php echo $_GET['ll']; ?>), <?php echo $_GET['z']; ?>);
  map.setMapType(G_NORMAL_MAP);
  map.addControl(new GSmallZoomControl());
  }
 }
</script>
</head>
<body onload="initialize()" onunload="GUnload()">
<div id="karte" style="width: 100%; height: 100%"></div>
</body>


Im Blogeintrag selbst ist dann nur noch folgende Codezeile einzufügen:

<iframe width="400" height="300" src="map.php?ll=51.472973,7.472579&z=24"></iframe>

Die Koordinaten (ll=51.472973,7.472579) und den Zoomfaktor (z=24) kann man einfach aus Google Maps übernehmen. In diesem Fall sollten die Pinguine des Dortmunder Zoos erkennbar sein:



Hier zum Vergleich der entsprechende Ausschnitt bei Google Maps

Jetzt sollte man noch dafür sorgen, dass nicht jeder die Datei map.php in seinem eigenen Webauftritt einbinden kann. Auch dafür gibt es eine einfache Lösung – aber das ist eine andere Geschichte.

Wegen der unklaren und in meinen Augen widersprüchlichen Angaben zur Zulässigkeit von Luftbildern in der Anfangsdarstellung der Karten empfehle ich momentan, das Aktivieren der Satelliten- oder Hybriddarstellung dem Nutzer der Seite zu überlassen. Der Spiegel hat zwar am 29. Februar 2008 eine Aussage von Google-Sprecher Kay Oberbeck dazu veröffentlicht, ob die im Ernstfall rechtlichen Bestand hätte, weiß ich jedoch nicht zu sagen. Auf die Frage "Wer darf Karten und Luftbilder von Google Maps per API eingebettet zeigen?" erhielt Spiegel-Redakteur Konrad Lischka jedenfalls die eigentlich positive Antwort: "Die kostenfreie Google Maps API darf auf Seiten angezeigt werden, welche für jedermann frei zugänglich sind, unabhängig davon ob es sich dabei um gewerbliche oder nicht-gewerbliche Seiten handelt. Ansonsten wird eine kostenpflichtige Google Maps Enterprise Lizenz benötigt." Auch von der Firma GeoContent gibt es laut einem Kommentar in Robert Basics Blog inzwischen grünes Licht für die API-Verwendung.