You are completely right. I don’t try to mean that it is a sort of DRM by itself. My concern is rather about making it too easy to implement DRM on the top of GRUB. For example, if the logic is present, it is very straightforward to get a key from somewhere else but an user input (e.g. by using a BIOS call), and hide it from the user. I can think of many nasty ways to hide the key, even if GRUB is free.

…

Nach Schrödinger nimmt die Katze in der Kiste (mit dem zerfallenden Teilchen und der daran gekoppelten Tötungsanlage) ja einen unbestimmten Zustand ein, bis man nachsieht. Ganz falsch:

Schrödinger hat eigentlich nur Glück gehabt, dass das ein Gedankenexperiment war. Hätte er eine echte Katze in einen Kasten gesperrt, wäre die auch ohne atomaren Zerfall in einen relativ angeregten Zustand übergegangen, der auch einfach nur als verdammt wütend bezeichnet werden kann. (Quelle: golem.de-Forum)

…

Ein interessantes Muster für einen Mietvertrag, der nicht binnen 4 Wochen vom BGH kassiert wird, fand ich in den Kommentaren zu einem Artikel im Lawblog - samt einer Diskussion, ob solch ein Vertrag etwas taugt oder nicht.

Ein Freund von mir hatte kürzlich die Partitionierung auf einer externen Festplatte ändern wollen, da diese ab Werk mit mehreren Partitionen ausgeliefert wird (warum auch immer). Leider kam das Programm auf die Idee, dass die NTFS-Partition “C:” nie und nimmer richtig sein könnte, und die dringend reparieren musste, obwohl es dort nichts zu tun hatte (warum auch immer). Naja, aus “reparieren” wurde dann “kaputt-reparieren”, weil es mit Vista-NTFS nicht klar kam.

Mal wieder ein Mail mit Anhang, die OpenPGP-verschlüsselt war. Mal wieder die Fehlermeldung, dass diese Mail zu groß für IMAP und Enigmail sei (“IMAP-Nachricht ist zu gross für die Entschlüsselung bzw. Überprüfung”).

Die Lösung ist dabei recht einfach: Im Menü “OpenPGP-Einstellungen”, “Erweitert”, “Anhänge nur herunterladen, wenn diese geöffnet werden sollen (nur bei IMAP)” - dort muss der Haken weg.

Ich rege mich ja gern über Apple und deren Produkte auf. Eins bekommt man dort aber gut hin: Integration - sowohl APIs, als auch Services.

Bei Services ist Netzwerk wohl das eindrücklichste Beispiel (wobei, das bekommt sogar Windows halbwegs hin - bloß das “Netzwerk-Betriebssystem” UNIX, von dem der ganze Kram stammt, nicht): Auf Solaris gibts “Network Autoconfig Magic” und klassische Konfiguration. Das fällt auch jedem Nutzer von OpenSolaris 2008.05 (alias “Indiana”) auf, es ist eins der häufigsten genannten Probleme im #opensolaris Chat in der letzten Zeit.

Nun ist es endlich soweit: Der Monolith Linux bekommt seine Grafikkartentreiber endlich in den Kernelspace. Zwar bin ich grundsätzlich ein Freund von Microkernelstrukturen und der Verschiebung von Features in den Userspace (Filesysteme, Netzwerkprotokolle), aber die Krücke XFree86 (oder Xorg) mit ihrem eingebauten Root-Hole, um an die Grafikhardware zu kommen, ist doch etwas arg schmerzhaft.

KGI hatte das Problem schon 1998 angegangen, aber damals wollte Linus Grafiktreiber nur “über seine Leiche” (oder so) im Kernel sehen - er fürchtete wohl die Komplexität. Das Design wurde vereinfacht, aber leider weiterhin nicht integriert.

Heute habe ich zum ersten Mal einen Sektor eines in QEmu emulierten USB Mass Storage Devices in GRUB2 gelesen, Yay!

Leider hat QEmu von einigem eine andere Meinung als die USB Specs, so dass der Treiber momentan vermutlich nur in QEmu funktioniert. Aber gut, als nächstes wird der Treiber an GRUB2 angebunden, so dass man auch Dateisysteme lesen kann und überhaupt was sinnvolles mit so nem Gerät anstellen kann.

Mal schauen, vielleicht korrigiere ich den Kram in QEmu mal und versuche, ob ich diesmal einen Patch reinbekomme - es wird allemal leichter sein als bei den GNU-Projekten.

Ich frage mich ja, ob sich der Aufwand lohnt… OS X zu patchen, damit es auf Nicht-Apple Rechnern läuft, bei jedem Apple-Update befürchten müssen, dass es irgendwas kaputt macht, Treiber irgendwoher zaubern für die Hardware..

Wäre es da nicht ziemlich bald effektiver, den Kram einfach nachzubauen?

Klar, das “Artwork” 1:1 übernehmen ist damit nicht möglich, und es ist auch einiger Aufwand (siehe Haiku oder ReactOS) - aber im Gegensatz zu den beiden Systemen wäre das Basissystem (Darwin) ja schon vorhanden, für den Highlevelkram könnte man bei GNUstep oder Cocotron abkupfern und sich die Sachen dann zurechtbiegen, dass sie ihren Gegenstücken in OS X entsprechen…

Nachdem www.coreboot.org heute nachmittag unter Last zusammengebrochen ist (Sekundäres Slashdotting, 3 Webcrawler), habe ich mich mal daran gemacht, die Konfiguration zu optimieren.

Auf dem System läuft (neben diversem anderen) ein Apache2, der unter anderem ein Mediawiki, trac, viewvc und das mailman-Webinterface bereitstellt. Auffällig waren die sehr großen, zahlreichen und ständig neuen apache2-prefork-Prozesse. Wie sich herausstellt, wurde prefork gewählt, weil php5 weiterhin nicht thread-safe ist (bzw. die eine oder andere Library, die eingesetzt wird). Für trac und viewvc wurde mod_python verwendet.