Liebe Benutzer und Betreiber von mirrors von SYS ! Ich habe in den letzten Tagen ueber die zweckmaessigste kuenftige update- Politik fuer SYS nachgedacht, mit dem folgenden Ergebnis: Erheblicher Teil der Herkunft der Distro und ihrer Motivation war, dass das fruehere Herausschrauben meiner Festplatte und Kopieren meines aktuellen Systemes fuer Freunde und Bekannte, durch dumpen auf ein zurueckinstallierbares DVD ersetzt werden sollte. Prinzip also und am Wichtigsten, so dem Benutzer maximal einfach ein aktualisiertes, fertiges System zur Verfuegung zu stellen; im Idealfall eine Kopie meines eigenen Rechners, was zwar bei einem DVD als Zwischenspeicher an der Groesse scheitert, aber das zumindest mein etwas entruempeltes System, jedenfalls mit denselben stets aktualisierten Programmen wie ich sie selbst verwende, enthalten kann. Nebensaechlich neben dieser rein funktionellen Zweckmaessigkeit und Praktizierbarkeit eines guten bestehenden Systemes statt einer Neuinstallation aus Paketen, sind dagegen Versionen, -nummern, -zyklen oder gar eine Religion derselben wie bei manchen Distros anzutreffen. Deren Praxis, jedes Jahr eine 'neue' Version zusammenzustellen, lange zu testen usw, ist grundsaetzlich verschieden der Philosophie von SYS, es einfach als snapshot und Kopie eines bestehenden, durch mich selbst benutzten, und so automatisch funktionierenden und stets upgedateten System zu liefern, zBsp ganz ohne Versionsnummern und allenfalls mit dem Datum versehen. In dieser Denkweise wurde auch ein SYS Installer entwickelt und separat .tgz-gepackt, der im Prinzip jedes beliebige System auf ein rueckinstallierbares DVD kopieren koennen soll. Mein eigenes System war damals eine Mischung aus Slackware, Kurumin, Mandrake und selbstgemachten .tgz Paketen neuer Programme. Mit der Entwicklung eines Install-DVDs ab November '07 habe ich Versionsnummern eingefuehrt, was sich aber auf den Installer selbst und nicht auf das System bezogen hat; die erste einigermassen funktionierende Version erhielt Nr. 0.10 , das System war dabei noch 'irgendeins' - eine sehr kleine Teilmenge meines eigenen Servers, davor kleine Installationen von Slackware und VectorLinux - nur um den Installer zu testen. Danach wurde dann eine zunehmend groessere (bei Installer 0.16 ca. 1.7 GB auf dem DVD) meines eigenen Systemes, jedenfalls Pakete und Einstellungen wie bei diesem, verwendet. Insbesondere ab V. 0.21 wurde diese Bezeichnung dann aber zur Version der Distro, nicht nur des Installers. Dies war nicht zu vermeiden, da das Projekt inzwischen zu einer formalen Distro wurde und das da so ueblich und von Benutzern so erwartet ist. Ferner wurden fuer die Distro auch zusaetzliche Anstrengungen unternommen, die ich nur fuer meinen eigenen Rechner nicht gemacht haette, und wurde die Herausgabe einer neuen Version auch zum Ansporn vorher noch gewisse Aenderungen durchzudruecken oder Macken zu beheben, die ich nur fuer mein eigenes System, lange ignoriert habe (zBsp die Mischung aus .rpm, .deb, .tgz -Paketen und Source-Installationen zu einer Paketart, letztlich .tgz, zu bereinigen). Ebenso ist jede neue Version ein Grund fuer eine Bekanntgabe in Foren, softpedia usw. Gleichwohl soll im Interesse der Benutzer SYS aber weiterhin seiner urspruenglichen Philosophie treu bleiben, im Gegensatz zu anderen Distros keine Versions-Religion zu machen; maximal schnell und unformal Fehler oder Bemaengelungen der Benutzer entgegenzunehmen und zu beruecksichtigen, und Aenderungen incl. Updates der Programme aufzunehmen. Dies hat sich bereits dadurch geaeussert, dass einhergehend mit den Versionsnummern viele und kurzfristige rc-Vorversionen und -r-Revisionsversionen gemacht wurden; 0.21 hat zBsp nur 3 Tage gehalten bis 0.21-r1 herauskam, weil dies sachlich und fuer die Benutzer so angebracht war. Zusammenfassend kann zwar einerseits eine Versions-Numerierung gemacht werden, die ihre guten Seiten hat, andererseits und hauptsaechlich soll SYS aber weiterhin ein snapshot des momentanen, upgedateten Standes von Linux, Kernel und Programmen, darstellen. Beides ist nur sehr bedingt vereinbar, und wuerde, konsequent betrieben, zu einem totalen Chaos von -rc und -r -Versions-Nummern fuehren, wobei dann noch die Versionen von Installer, lzma-Datei und Install-DVD zu unterscheiden waeren. softpedia wird nicht jeden Tag eine neue -rc / -r -Nr. bekanntgeben und die mirrors nicht jeden Tag manuell eine neue Version aufsetzen wollen, bei denen selbst dann immer noch Korrekturen erfolgen. Andererseits funktioniert das syncen per rsync, auch von .iso 's nach kleinen Aenderungen, sehr gut, und kann (ausser bei dem relativ seltenen Neumachen des .lzma-Files) vollautomatisch im Rahmen der normalen updates stattfinden. Daher beabsichtige ich nun, das Schema zumindest probeweise einmal wie folgt zu aendern, wie es mir im Interesse der Anwender, der mirrors, und auch mir am geeignetesten erscheint: / Fuer den hauptsaechlichen Gebrauch und vorzugsweise fuer neue Installationen zu verwenden, halte ich auf dem Server eine Version SYS-current.iso oder einfach SYS.iso , die laufend aktuell gehalten wird. Darin sind neben dem letzten lzma-File, aktualisierte Pakete die auch auf meinem Server selbst laufen, also getestet sind und wo mir Fehler sofort auffallen wuerden, jedoch nicht alle neuen Pakete sondern nur eine Auswahl, ganz so wie das bisher bei -rc - und -r- DVDs gehandhabt wurde (hauptsaechlich Kernel/glibc und sonstige wichtige Programme upgedated). Ebenso Korrekturen aller mitgeteilten Probleme, zBsp fehlende links oder libs, auf dem DVD entweder in Ordnern speziell dafuer oder aber (vorzugsweise) als Wartungspaket was nach der Installation des lzma-Files zusammen mit den neuen Paketen ueberinstalliert wird. Eine derartige Einrichtung der Install-DVDs hat sich inzwischen gut eingespielt und ist sehr flexibel und angebracht. Meist lasse ich auf den DVDs 50 ... 150 MB Platz fuer solche Nachtraege. Fuer die mirrors (und auch fuer mich) mehrmalige taegliche Aenderungen kein Problem; downzuladen sind meist nur wenige MB (ausser bei neuem Kernel/glibc), und die o.g. Bezeichnung dieses .iso 's bleibt immer gleich, also nicht manuell zu aendern. / Ab und zu ist die Herausgabe einer formalen Version geboten, insbesondere wenn so viele neue Programme kamen sodass ein neues .lzma-File gemacht wird. Bei Vorhandensein eines obigen current-isos sind aber nicht mehr so viele -rc's oder -r's (oder gar noch mehrfache Aenderungen derselben) erforderlich; sobald reif wird das current als -rc / Hauptversion / -r kopiert und die Benutzer um testen bzw updaten wegen wichtigen Aenderungen gebeten. Weiterhin werden bei ihnen aber relativ krasse Fehler korrigiert, zBsp wenn ein DVD bei einer ganzen Klasse von rechnern nicht bootet o.ae. / Fuer einzelne Versionen die viel downgeladen wurden oder besonders stabil sind (insbesondere die letzten -r's eines .lzma) soll Langzeit-Support gegeben werden, das betrifft bisher V. 0.19 , 0.20-rc2 , 0.22, 0.23-rc4. Dies soll nur noch unentdeckte Fehler, aber keine updates von Programmen betreffen, indem Fehler korrigiert und dazu Wartungspakete gemacht werden, die man downloaden und ueberinstallieren kann. Das soll auch so bleiben. Bisher wurden auf dem Server und einigen Mirrors ferner Kopien solcher .iso's aufgehoben, in Analogie wie bei anderen Distros der Fall. Dafuer besteht aber eigentlich weder Grund noch Nutzen. Auch habe ich zunehmend Platz-Probleme. In Anbetracht der Einfuehrung des current-DVDs beabsichtige ich kuenftig neben diesem nur noch eine -rc , Haupt- oder -r-Version aufzuheben, uebergangsweise (es gibt noch Leute mit 56k Modem) waehrend einiger Tage auch noch die vorangegangene. Andererseits ist nichts dagegen einzuwenden wenn mirrors die genuegend Platz haben oder Bestaende auf Magnetbaendern o.ae. archivieren koennen, auch noch andere Versionen aufheben, besonders die o.g. Die Bildung von Paketen neuer Programme oder Versionen soll i.W. weiterhin so bleiben wie bisher. Kuerzlich bin ich von build=pc-gnu-linux zu build=i486-slackware-linux uebergegangen, damit die Pakete problemlos von anderen .tgz-Distros verwendet werden koennen. In diesem Fall sollte auch das neuste glibc incl. der glibc-kernel-header von SYS downgeladen und im anderen System installiert werden, weil bei der Bildung von Paketen fuer SYS stets ein sehr neues glibc und headers benutzt werden, und sie bei Distros mit aelterem glibc / headers ggf. nicht funktionieren. Im Paket linux von SYS sind alle Pakete kernel-* von Slackware enthalten, mit Ausnahme der kernel-headers die bei SYS glibc-kernel-headers heissen und stets zu glibc, nie zum Kernel gehoeren und mit ihm auszutauschen sind; anders als dem Chaos mancher Distros bzgl 'bereinigter' oder denen mit Kernel, glibc oder gcc gelieferten headers, vertritt der Verfasser die Auffassung dass zusammen mit jedem glibc strikt diejenigen headers die zu seiner Uebersetzung genommen wurden zu verwenden sind, nebensaechlich wo sie herkommen (wobei ich immer die mit dem Kernel kommenden vorziehe und nur dort nicht vorhandene von glibc, hilfsweise von gcc, nehme). Dies beachtet, sind linux / kernel sowie glibc zwischen SYS und Slackware (sowie vielen .tgz -Distros) kompatibel und fast beliebig austauschbar. Das .tgz -System hat bekanntlich keine Dependenzenverwaltung, und das ist auch gut so. Als ich kuerzlich bei meinem eee PC die .deb-Pakete fuer deutsche Sprache hinzuinstallieren wollte, sollte ich von abiword bis openoffice alles desinstallieren. Abhaengigkeiten in den hintersten Winkeln und nicht funktionierende ganz nebensaechliche, ggf nie benutzte seltene Funktionen nehme ich lieber in Kauf als fast garnichts mehr machen zu koennen oder beim update mehrerer Programme ewig warten zu muessen. SYS ist keine theoretische sondern eine praktische, auf einfache Funktion ausgelegte Distro. In der Praxis ist es ausreichend, mit libtool oder kleansweep gelegentlich (etwa fuer neue Versionen) zu testen dass keine voneinander abhaengenden Bibliotheken oder Programme fehlen. Sollte einmal ein Programm nicht starten, mrxvt ausfuehren und dort seinen Namen eintippen, aus der Fehlermeldung ist dann das Problem ersichtlich. Hat man eine fehlende Bibliothek nicht zur Hand, reicht es meist sie mit einer aehnlichen zu verlinken, zBsp ln -s libXXX.so.55 libXXX.so.56 . Dauerbrenner fuer Probleme sind python, perl, lisp, aendert sich da nur die Version, funktioniert fast garnichts mehr Update vom Kernel ist bei SYS maximal einfach: neuen Kernel mit installpkg linux-*.tgz installieren, Eintrag in lilo wird automatisch erzeugt. Neu booten in den gerade installierten neuen Kernel, und den alten mit pkgtool oder removepkg linux- loeschen, per Editor in /etc/lilo.conf auch seinen Eintrag. Anschliessend mit updatepkg ggf. Pakete ueberinstallieren die Kernel-Module erzeugen, zBsp fuse, ndiswrapper. Ich bedanke mich vielmals fuer Ihre Benutzung und/oder Hilfe zur Bereitstellung von SYS. Werner Landgraf