pippovic hat geschrieben:
1. hab ich nur ungefähr die Hälfte von dem kapiert, was du da geschrieben hast und
Mein Fehler - ich hab mich wohl sehr unklar ausgedrück. Wollte mal wieder alles auf einmal machen.
2. sollten wir uns solche Gedanken erst machen, wenn ein "Team" für diese CD gefunden ist. Wenn jetzt außer anworm, dir und mir noch 2-3 Leute definitiv zusagen, können wir loslegen.
Ich denke, die prinzipielle Bereitschaft mitzumachen finden wir. Aber eine ungefähre Vorstellung von den möglichen Aufgaben bräuchten wir schon,
3. Lohnt es sich so eine Cd noch für Warty zu erstellen, oder sollte man bei Hoary einsteigen?
Hoary. Bis wir soweit sind, und alles eingespielt und erprobt ist ist hoary möglicherweise nicht mehr sehr fern.
Ich versuche jetzt mal, einen Teil meiner konfusen Einfälle etwa klarer zu machen.
Da ist zum Beispiel die Idee mit den zusätzlichen Treibern. Nun gibt es bei Treibern zwei Möglichkeiten: Userspace (z.B. Turboprint) oder Kernelmodule. Bei letzteren ist wichtig, daß sie zum jeweils letzten, "sicheren" Kernel passen. Leider gab es bei Warty bereits mindestens zweimal die Notwendigkeit, im Rahmen eines Sicherheitsupdates das "Application binary inteface" zu ändern - das ist glaub ich die Schnittstelle, an der die Module andocken. Man stand vor der Wahl, eine Fehlfunktion mancher Treiber zu riskieren, oder aber die Versionsnummer des Kernels zu ändern (2.6.8.1-3 zu 2.6.8.1-4), so daß sich die alten Module nur noch gewaltwam laden lassen. Mir ist dieses Problem auf einem betreuten Ubuntu-Rechner begegnet, bei dem es ausgerechnet um die AVM-Fritz-Treiber ging. Die wurden nach dem Kernelupdate nicht mehr automatisch geladen, und prompt kan ein Anruf "Mein Internet is kaputt".
Sollten wir also Treiber bereistellen, die Kernelmodule enthalten, müssen wir diese Möglichkeit berücksichtigen. Immerhin glaube ich, daß in Hoary bei solchen Updates eine besser sichtbare Warnung angezeigt wird, was in warty ohne zusätzliche Änderungen nicht möglich war. Aber in jedem Fall sollte es möglich sein,. die aktualisierten Treiber schnell zu bekommen, ohne dazu eine CD runterladen oder bestellen zu müssen. Das würde sonst früher oder später zu berechtigtem Frust führen.
Es wäre also nötig, die auflaufenden Sicherheitsupdates daraufhin zu beobachten. Da wir alle nebenbei noch andere Aufgaben haben und nicht immer zur Verfügung stehen, wäre diese Aufgabe auf mehrere Leute zu verteilen, so daß immer mindestens einer da ist, der sofort handeln kann. Das bedeutet weiterhin, daß wir die Treiber "automatisiert", d.h. per script gegen den aktuellen Kernel bauen müssen. Nur so wäre einigermaßen zu gewährleisten, daß bei einem Treiberupdate kein Fehler passiert.
Sollten Treiber für Modems in Frage kommen, müssten diese mit einem deutlichen Warnhinweis versehen sein.(was ist mit HCF-Modems? LTmodem und avm sind ja in Hoary drin).
Mir scheint das ziemlich kompliziert für den Anfang - vielleicht reichen erstmal unproblematischere Dinge wie das von Dir erwähnte Turboprint. Zumal einige wirklich wichtige in warty fehlende Treiber in Hoary dabei sind: die restricted-modules enthalten jetzt auczh madwifi (atheros) und wie gesagt auch avm und ltmodem.
Nächstes Thema: die Auswahl der zusätzlichen Software. Das ist tatsächlich ein Thema, daß wir im Team diskutieren sollten, sobald das steht. Vertagt...
Ebenfalls später diskutieren können wir das Format der Dokumentation und die Art des Zugangs - ein Menüpunkt unterhalb von "Hilfe" wäre im Systemmenü von Hoary wohl am geeignetsten. Das würde aber eigentlich erfordern, den Punkt "Hilfe" umzubenennen - "Hilfe zur Gnome-Oberfläche" oder so. Nur so als Gedanke, weil ich grad nicht weiß, wie das sauber zu machen wäre.
Noch etwas, was vielleicht schon jetzt interessant ist: Das Traffic-und Bandbreitenproblem.
erste Idee: Bittorrent.
zweite Idee: Jigdo. Lassen sich die beiden eventuell verbinden - Torrent für den ersten Download und Jigdo zur Aktualisierung?
dritte Idee: Angenommen, wir erstellen die CD regelmäßig vollautomatisch mit Hilfe eines Scriptes neu (wegen der Sicherheitsupdates) - warum dann nicht dieses Script anbieten? Natürlich als Debian-Paket (Abhängigkeiten: mindestens debmirror). Praktisch alle Downloads würden dann von den Ubuntu-Servern stattfinden. Dafür brauchen wir jemand, der ein besonders schönes Script mit einer sauberen Fehlerbehandlung schreiben kann (ich eher nicht; da zeigt sich, daß ich eigentlich nicht vom Fach bin).
Die Problematik der Sicherheitsupdates für Zusatzsoftware will ic aber doch nochmal etwas genauer anreißen, weil das unabhängig von weiteren Entscheidungen immer ein kritischer Punkt sein wird.
Ich behaupte: Wir können für Sicherheitsupdates nicht garantieren, weil wir die Pakete nicht erstellen, sondern nur weiterreichen. Dennoch wäre es gut, wenn wir eventuell vorhandene Updates weitergeben würden - dazu müsste zumindest sichergestellt werden, daß immer die neueste Version beispielsweise von Universe-Paketen auf die CD kommt. Bei anderen Quellen ist dagegen Vorsicht geboten - nicht daß da versehentlich eine neue Major Version oder gar eine Beta reinrutscht.
Außerdem bleibt die Frage, ob für automatische Updates die Quellen angeboten werden sollen, aus denen wir die Software haben. Natürlich sollte ach nicht ungefragt an der sources.list rumgepfuscht werden. Und je nach Quelle stellt sich das Problem, daß die vor jedem Update herunterzuladenden Paketlisten geradezu riesig sind - an die drei MB im Fall von Universe. Das ist keinem Modemnutzer zuzumuten.Was tun?
Das wär's erstmal, hoffe, jetzt ist es etwas verständlicher.
Gruß
droebbel
