Konzertierte Aktion gegen frei zugängliche Noten und Songtexte
MPA-Präsident Lauren Keiser zeigte sich gegenüber der BBC äußerst verärgert über die seiner Ansicht nach illegalen Seiten mit Gitarren-Licks und Notenvorlagen und sähe deren Betreiber vorzugsweise hinter Gittern. Grundsätzlich unterliegt Musik nicht nur als konkrete Aufführung, sondern auch in jedweder gedruckter Notation dem Urheberrecht.
Demnächst landeste im Knast, wenn du versehentlich im Takt von Alle-Meine-Entchen furzt ...
UCI-Reaktionen auf die Grand Tours Wertungsidee der drei grossen Touren:
"Als einziger Akteur dieser Reform, der selbst keine eigenen ökonomischen Interessen verteidigen oder fördern will, wird die UCI niemals eine solche überflüssige und gefährliche Vision teilen, die der Entwicklung des Radsports schadet", hieß es in einem offiziellen Statement. Die Einführung oder Änderung des Reglements stehe allein dem internationalen Verband zu.
Man sieht schon wie sich die Truppen der UCI formieren, um in die Leitungsbüros der drei grossen Tourorganisationen einzudringen und die Rädelsführer festzusetzen. Danach gibts dann ein Straflager für renitente Tour-Organisatoren, die sich der UCI nicht unterordnen wollen. Vielleicht kriegen sie ja auch Unterstützung von 'Mad Eye' Serlet?
Die US of A, Land der Freien und Verblödeten, gibt mal wieder den Ober-Rüpel:
Hinter vorgehaltener Hand sind selbst erfahrene Gipfelteilnehmer aus Westeuropa schockiert über die pöbelhafte Verhaltensweise der amerikanischen Chefverhandler, die hier agieren wie John Bolton in der UN, und "ihre akademische Bildung gut verbergen".
Schockiert bin ich höchstens über die Blauäugigkeit der Politiker, die sich so verwundert über das Verhalten Amerikas geben - als ob die aktuellen Berichte nicht eine sehr deutliche Sprache sprechen, das die derzeitige US-Administration sich einen feuchten Furz um die Wünsche anderer kümmmert und selbst internationales Recht für sie keine sonderlich wichtige Stellung einnimmt. Warum sollten die sich auf dem Klimagipfel anders verhalten?
Ganz besonders schockierend dann aber, wie ständig das Merkel davon labert, das die Beziehungen zur USA verbessert werden müssten - wegen meiner gerne, aber bitte erst mit einer nächsten, möglicherweise rationalen Argumenten zugänglichen, Administration. Die derzeitige ist nicht koalitionstauglich, um mal einen Begriff aufzugreifen, der hierzulande gerne für sowas harmloses wie die PDS benutzt wird ... (Angst vor blass-rot angestrichenen Ossies haben, aber mit sowas wie Bush zusammen wollen - sowas nenn ich schockierend)
A rather ugly - but still useful - monkeypatch:
# monkey-patch for auth.users
from django.models.auth import User
def user_pre_save(self):
if not self.password.startswith('sha1$'):
self.set_password(self.password)
User._pre_save = user_pre_save
Put this into your model file (or somewhere else that is loaded early on) and you will be able to set passwords in the admin by entering clear text passwords. If the password starts with 'sha1$', it is seen as already encrypted and nothing happens. If it doesn't start with that string, it is converted using the standard Django function for password encryption.
No, this isn't something that should go into core - it's far too ugly for that. But at least it allows you to set passwords through the admin, without requiring the user to calculate the actual password hash.
Sony caught in another DRM snafu
Stop me if you've heard this one before. A record label uses DRM to sort of keep its customers from copying the music. It turns out that the software poses a threat to the user's PC. So the label issues a patch... which opens up another security hole. If you guessed that the label in question is Sony, you'd be correct. If you guessed that I'm recapping last month's rootkit debacle, you'd be wrong.
Tja. Selten dämlich bei Sony. Ob die es irgendwann überhaupt noch mal lernen?
Oh, und das ich jetzt vermutlich keinen Aibo angeboten bekomme, ist mir ehrlich gesagt ziemlich wurscht
Immer wieder gerne genommen: SystemExit. Eine Python-Exception, die viele nicht kennen. Das besondere an dieser Exception: sie ist kein Fehler. Sie tritt auch nicht unerwartet auf. Sie wird nämlich einfach von sys.exit ausgelöst. Die Idee dahinter ist, das man so im dynamischen Ablauf eine Ende-Bearbeitung einhängen kann (z.B. irgendwelche Dateibereinigungen), ohne sich in globale Exitbearbeitung einzuklinken (mit all den Problemen die das hat).
Das Problem ist jetzt, das viele Programme und Bibliotheken einen globalen Exception-Handler installieren. Einen, der jeden Fehler abfängt und hübsch formatiert per Mail verschickt, irgendwo logged oder ähnliches. Mache ich auch ständig. Geht auch klasse - ausser wenn man in seinem Programm tatsächlich mal explizit ein vorzeitiges Ende einleiten will. Dann klappt da garnix mehr - denn man erhält entsprechende Fehler für einen Nicht-Fehler.
Besonders kritisch wird das ganze im Zusammenhang mit mehreren Prozessen. Wenn man nämlich im Laufenden Betrieb einen Prozess anstartet, will man diesen auch beenden, ohne das eventueller nachgelagerter Code ausgeführt wird. Am besten sieht man das an einem Beispielprogramm:
import signal
import os
try:
pid = os.fork()
if pid:
print "Elternprozess", os.getpid()
else:
print "Kindprozess", os.getpid()
sys.exit(0)
except:
print 'Fehler aufgetreten in Prozess', os.getpid()
print "Das darf nur der Elternprozess ausführen", os.getpid()
Dieser Code hat einfach einen globalen Fehlerbehandler, der Fehler recht unspezifisch abfängt. Innerhalb des Codes wird ein paralleler Prozess mit fork gestartet. Dadurch, das SystemExit wie alle anderen Exceptions behandelt wird, wird aber der Kindprozess nicht korrekt beendet - ein Prozess kopiert den gesamten Zustand des Elternprozesses, inklusive Rücksprungadressen, offene Fehlerbehandlungen, Dateien, Datenbankverbindungen und so weiter.
Das ist natürlich fatal - denn hier wird ja sys.exit abgefangen. Es gibt also eine Fehlermeldung für den ganz normalen sys.exit(0) Aufruf. Und noch schlimmer: da SystemExit nicht extra behandelt wird, gehts danach normal weiter - und der Kindprozess rennt in Code für den Elternprozess rein. Code läuft also doppelt, was unter Umständen kritische Ergebnisse haben kann.
Wenn man den ganzen Stack an Software voll kontrollieren kann, ist die Lösung einfach:
import signal
import os
try:
pid = os.fork()
if pid:
print "Elternprozess", os.getpid()
else:
print "Kindprozess", os.getpid()
sys.exit(0)
except SystemExit:
raise
except:
print 'Fehler aufgetreten in Prozess', os.getpid()
print "Das darf nur der Elternprozess ausführen", os.getpid()
Dadurch wird einfach der SystemExit neu geworfen - also neu ausgelöst - ohne eine Meldung zu machen. Im Regelfall wird dann die Standardbehandlung von Python zuschlagen und den SystemExit in eine normale Beendigung umsetzen.
Was aber machen, wenn man mehrere gestapelte Varianten des falschen Fehlerhandlings hat? Ich hab sowas zum Beispiel bei Django und FLUP (dem FCGI/SCGI Server für Python). In Django hab ich es geändert, dann hat der Fehler im FLUP zugeschlagen. Was macht man dann?
Die Lösung ist ein wenig brutaler:
import signal
import os
try:
pid = os.fork()
if pid:
print "Elternprozess", os.getpid()
else:
print "Kindprozess", os.getpid()
os.kill(os.getpid(), signal.SIGTERM)
except:
print 'Fehler aufgetreten in Prozess', os.getpid()
print "Das darf nur der Elternprozess ausführen", os.getpid()
Letzten Endes begeht der Prozess einfach Selbstmord - er schickt sich selber ein SIGTERM, also ein Beendigungssignal. Das gleich, das man normalerweise von der Shell schicken würde. Allerdings muss man dann sicherstellen, das alle eventuell nötigen Nachbereinigungen entweder schon gemacht sind, oder dann in einer SIGKILL Behandlungsroutine laufen - sonst hat man unter Umständen Problemen (z.B. sollten Datenbanktransaktionen schon commited sein).
Auch bei dieser Lösung muss man aufpassen, das nicht irgendwelche offenen Resourcen den Prozess blockieren - sonst produziert man unter Umständen Zombiprozesse. Oftmals ist es daher besser für solches Multiprozessing einen Verwaltungsprozess sehr viel früher im System zu starten - ausserhalb der Fehlerbehandlungskette - und diesen dann zu benutzen um Bearbeitungsprozesse zu starten. Allerdings hat das dann den Nachteil, das diese solcherart gestarteten Prozesse nicht die Umgebung des Elternprozess erben. Man muss daher dann in der Regel mehr Vorbereitungen treffen, um die gewünschten Aktionen auszuführen. Einen ähnlichen Ansatz verfolgt übrigens Apache - dort werden die Prozesse aus einem sehr frühen Basiszustand heraus erzeugt, so das sie möglichst Resourcenfrei daherkommen.
Sie lebt? Jedenfalls gibts Gerüchte dazu. Wobei mich allerdings Sätze wie diese hier:
Leiter des Dharma-Projekts soll Bertrand 'Mad Eye' Serlet sein, Senior Vice President of Software Engineering bei Apple, der auch schon an der Entwicklung von iCal und iSync beteiligt gewesen sein soll.
ein wenig irritieren. Ich mein, also hallo, was sind das für Namen? Mafia? Söldner? Verirrte Wild-West-Figuren?
