Volker, der Entwickler von tellmatic war in Paris und hat uns eine Sammlung von (historischen) Facepalm-Bildern mitgebracht.
Die Bilder stehen allesamt unter einer Creative-Commons-Lizenz: Namensnennung – Weitergabe unter gleichen Bedingungen 3.0
Volker, der Entwickler von tellmatic war in Paris und hat uns eine Sammlung von (historischen) Facepalm-Bildern mitgebracht.
Die Bilder stehen allesamt unter einer Creative-Commons-Lizenz: Namensnennung – Weitergabe unter gleichen Bedingungen 3.0
In Sachen DRM bin ich ja grundsätzlich geneigt, jegliche DRM-Techniken abzulehnen. Daher wollte ich ich Alex auch gar nicht wiedersprechen, als er (genau wie ich auch schon) über das möglicherweise kommende HTML5-DRM gerantet hat.
Nun ist seitdem etwas Zeit vergangen und ich habe mir ein paar mehr Gedanken dazu gemacht.
Wenn man davon ausgeht, dass das DRM in HTML5 ein Standard sein soll, der es ermöglicht, Content (z.B. Streaming-Musik oder Filme) “sicher” vor Mitschnitt anzubieten, könnte das durchaus genug Potential bieten um lästigen Brückentechnologien wie Flash und Silverlight endlich den Gar auszumachen. Voraussetzung ist dabei natürlich, dass die Inhalte in möglichst offenen bzw. Plattformübergreifend funktionierenden Formaten übertragen werden.
Wenn ich mit plattformübergreifenden Standards das gleiche erreichen kann, wie aktuell mit Flash oder Silverlight, dann werden auch Nischenplattformen attraktiv. Ich kann auf Linuxrechnern mit einfachsten Mitteln Streaming-Angebote wahrnehmen, die sonst proprietäre Browser-Plugins benötigen. Oder mit BSD. Im Endeffekt: Meine Zielgruppe wächst um vermutlich 5-10% in eine Nische, die in der Regel als “nicht wirtschaftlich” eingeordnet wurde. Bietet dieser Nische die Möglichkeit, Paid Content wahrzunehmen. Kickstarter und andere Crowdfunding-Plattformen haben es gezeigt, dass hier ein Markt ist, der auch Geld auszugeben bereit ist.
Ich persönlich würde mich über eine flashfreie Version von z.B. RDIO oder Spotify mehr freuen als über eine Linux-App dafür. Und um hier mal einen Stallman zu pullen: Mir ist ein standardisiertes DRM, welches allen die Möglichkeit gibt, den Content zu nutzen lieber, als dieser Plugin-Wildwuchs mit vorprogrammierten (sic!) Sicherheitslücken.
[red_box]Lieber wäre mir auch, wenn gar kein DRM eingesetzt würde. Aber ich bin Realist genug, um zu sehen, dass das auf längere Zeit nicht verschwinden wird. Und dann lieber auf diese Weise.[/red_box]
Writing programs using ordinary language
Alleine das RexEx-Beispiel zeigt, wie dringend so etwas gebraucht wird.
Als Webentwickler kennt man das vielleicht: Für das x-te Kundenprojekt legt man eine neuen Ordner in seinem WWW-Root an und fängt an, entweder “localhost/kundenprojekt.de” zu nutzen oder lustige Spielereien mit VirtualHost-Konfigurationen und der Hosts-Datei zu veranstalten (“127.0.0.1 kundenprojekt.de”).
Das muss nicht mehr sein! Zumindest unter Linux, BSD und vermutlich Mac OSX.
Der Apache-Part funktioniert ohne Probleme auch unter Windows, das Problem ist hier das generische Domain-Auflösen. Wenn jemand dafür eine Lösung hat, her damit!
apt-get install dnsmasq
” bzw. “aptitude install dnsmasq
“Dnsmasq is a lightweight, easy to configure DNS forwarder and DHCP server.
So weit, so gut. Dnsmasq kann einiges mehr und besonders interessieren wir uns für die Funktion, die in der Manpage mit “–address” beschrieben ist. Sehr unscheinbar, aber das ElDorado für uns. Die Option besagt, dass jede Domain, die in das Muster passt, mit der definierten IP aufgelöst wird.
Dafür legen wir unter Debian/Ubuntu die Datei /etc/dnsmasq.d/localdev.conf
an. In diese kommt folgender Inhalt:
address=/localdev/127.0.0.1
Unter Windows bearbeitet man die Datei “AcrylicHosts” und fügt dort die Zeile “127.0.0.1 *.localdev” ein.
Man könnte auch eine beliebige andere TLD nehmen (“erfinden”), z.b. “.dev” oder “.locales-netz-von-chris”.
Damit werden alle Domains, die auf “localdev” enden, auf die lokale IP aufgelöst.
Dnsmasq löst nun Domains wie “kunde.localdev” und “kunde2.localdev”, alle auf den lokalen Webserver um.
Normalerweise hätte man dann ja immer noch das Problem, dass man mit den VirtualHost-Konfigs basteln müsste. Hierfür hat Uberspace eine super Lösung präsentiert:
Die Apache-Config wird in der VirtualHost-Direktive erweitert. XAMPP/LAMPP/MAMPP-User müssen diese erst erzeugen.
RewriteEngine On
# If there is a host-specific pseudo-DocumentRoot, use it instead of the default one
RewriteCond %{REQUEST_URI} !^/f?cgi-bin/
RewriteCond /var/www/%{HTTP_HOST} -d
RewriteRule (.*) /var/www/%{HTTP_HOST}/$1
Dieser nette Trick erlaubt folgendes: Wenn ein Verzeichnis existiert, welches den gleichen Namen hat, wie die URL, die aufgerufen wird, wird es als “DocumentRoot” verwendet. Bei der Verwendung von .htaccess-Rewrites innerhalb des Verzeichnisses muss allerdings ein “RewriteBase /
” stehen.
Ich muss in Zukunft nur noch ein Verzeichnis “kunde123.localdev” anlegen und schon kann ich darin loslegen. Ich habe eine Top-Level-Domain und muss am Ende beim Umzug auf die Live-Seite nicht mehr soviel ändern. Im Falle von WordPress muss ich nur beispielsweise noch in der Datenbank das “.localdev” durch “.de” ersetzen und schon kann das Projekt live gehen.
Außerdem ist mein /var/www/ -Verzeichnis dann auch zwangsläufig gut organisiert.
Im Übrigen: eine spezifische Auflösung in der resolv.conf oder der Hosts-Datei hat Vorrang vor der Dnsmasq-Auflösung.
[green_box] Update
Ein Tool für Windows wurde nachgetragen
[/green_box]
[grey_box]
Dieser Eintrag entstand durch eine Verkettung von Inspirationen: Ich habe Alex zum testen von Uberspace inspiriert, deren VirtualHost-Konfiguration hat Alex zum testen von Dnsmasq (Wikipedia) auf seinem Notebook inspiriert und seine Demonstation davon hat mich zu diesem Eintrag inspiriert. Soviel zum Thema “geistiges Eigentum”.
[/grey_box]