Protokoll der Arktur-Entwicklungstagung, 20. und 21. Mai 2006, in Magdeburg

(3231 Worte insgesamt im Text)
(13441 mal aufgerufen)  Druckerfreundliche Ansicht

Hallo Liste, liebe Tagungsteilnehmer!

Die Darstellung der Tagung ist in klassischer Protokollform kaum möglich. Nicht bezüglich der Ergebnisse, erst recht nicht bezüglich des Ablaufes. Deshalb sei hier ein Versuch gemacht, in Form einer Mischung aus deskriptivem Protokoll und sachbezogener Erzählung. Unberührt bleibt dabei der Anspruch auf Richtigkeit und auf wertfreie Formulierung.

Es waren bei der Tagung anwesend: Andreas Seidel, Axel Kossel, Erwin Flohr, Harry Jede, Helmut Hullen, Olaf Sohnekind, Philipp Flesch, Reiner Klaproth, Reinhold Dorn, Thomas Litsch, Uwe Schoffer, Volkmar Hinz

Philipp nahm nur am Sonnabend teil. Auch andere der gelisteten Personen waren zeitweise nicht anwesend. Die Veranstaltung verlief ausschließlich im Plenum. Was in Kaffeepausen oder beim Essen besprochen wurde dürfte nicht unwichtig gewesen sein, - wird hier aber nicht wiedergegeben.

Wir begannen am Sonnabend um 9:00 Uhr mit einem ausgedehnten Frühstück (Buffet) zu dem die Anreisenden nach und nach dazu kamen (vgl. Schaubilder) Etwa um 11:00 Uhr waren wir vollzählig. Wir begannen um 11:20 Uhr mit der Tagung, indem wir die Tagesordnung für den ersten Tag verabredeten. Selbige hatte nur teilweise Einfluß auf den weiteren Ablauf, sei aber trotzdem erwähnt. Die Reihenfolge der Liste sagt dabei nichts über die tatsächliche zeitliche Folge aus. Ein angeregter, zwischen diversen Sachpunkten hüpfender Themenverlauf schien den Beteiligten günstiger und zielführender als eine konsequente Erörterung von fest gereihten Themenpunkten:

  1. Zusammenarbeit, Gemeinnützigkeit, AGSS
  2. Kooperation, Teamentwicklung, Team-Server
  3. Arktur-5-Entwicklung
    • techn. Schichtung, Struktur
    • Modularisierung
    • Basis-System
    • Dokumentation
    • Oberflächen
    • Arbeitsaufteilung /-Organisation
  4. Öffentlichkeitsarbeit

Gleich zu Begin formulierte Axel den Anspruch der Zeitschrift c't auf _Nichtkommerzialität_ des Arktur-Projektes. Er begründete dies mit der Notwendigkeit zur Neutralität und Unabhängigkeit der c't-Redaktion, welche keine Beteiligung an einem kommerziellen Projekt ermöglicht! Entsprechend stellte er allgemein frei, die Weiterführung ohne eine c't-Beteiligung zu organisieren. Alle Anwesenden stimmten dem Verlangen jedoch zu, bestätigten die Notwendigkeit, und sahen ihre eigenen Interessen nicht beeinträchtigt, bzw. sahen diese in Einklang.

Weiter wurde eingangs bemerkt dass in Hannover die Planung der Version 5 bereits besprochen worden sei und dass nunmehr (unter anderem wegen dem bevorstehenden Abschluss von Version 4) ein günstiger Zeitpunkt sei, um mit der Arbeit zu beginnen. Zum Vergleich zitiere ich aus der Tagesordnung von Hannover, vor zweiundeinhalb Jahren, vom 15. Nov. 2003. Aktuelle Vorschläge zur Planung von Arktur 5 sind dann im letzten Teil des Protokolls zu finden:

13:15 Version 5 a) Welche Basis b) Welche Admin- und User-Interfaces c) Welche Haupteigenschaften 14:00 d) Welches tech. Design - Modell zur User-Verwaltung u.A. (Vortr. A. Schürheck) e) Zukünftige (Team-)Arbeitsweise - Konzeption, Formalia, Skripte (Vortr. Andreas Seidel) - CVS-gestützte Entwicklungsweise (Vortr. Erwin Flohr)

Als nächstes wurde hauptsächlich der Punkt _Öffentlichkeitsarbeit_ besprochen. Es gab dabei einige Ideen, die für gut befunden wurden:

- Um die Supportmöglichkeiten zu fördern, aber auch um die breite, regionale Kraft des Nutzerkreises zur gegenseitigen Unterstützung deutlich zu machen soll eine Datenbank mit Referenzschulen und mit möglichen lokalen support-Partnern aufgebaut werden, bzw. es sollen geeignete Ergänzungseinträge in der Datenbank der Arktur-Schulen eingefügt werden. Uwe und Philipp werden dazu die Umsetzung vorantreiben.

- Es soll eine mailing-Liste "Marketing und Öffentlchkeitsarbeitsarbeit" eingerichtet werden (durch die c't). Zudem wird zur Gründung einer Gruppe "Öffentlichkeitsarbeit" (ca. 3 bis 5 Leute) aufgerufen, die sich um die Arbeit kümmern soll. An der mailing-Liste selbst sollten sich alle diejenigen beteiligen die kontinuierliche Bereitschaft zu regionalem support, zur Vorführung ihrer Arktur-Installation und zu kleinen Vorträgen haben. Die Liste soll mit vermittelten Anfragen versorgt werden. Sei es durch Weiterleitung von Anfragen aus der user-Liste, sei es durch geeignete support-Anfragen an die c't oder durch direkte schriftliche Zusendungen. Entsprechend könnte für professionalisierten support geworben werden. Telefax-Botschaften oder Briefe sollen durch c't (idR. Erwin) in PDF-Dokumente konvertiert und in die Liste geleitet werden.

- Wir benötigen einen grafisch aufgepeppten Info- und Werbezettel der bei Messen und anderen öffentlichen Veranstaltungen verteilt werden kann. Axel wird für die Produktion dessen sorgen. Zettel und CDs können dann für die (lokale) Öffentlichkeitsarbeit bei der c't angefordert werden.

- Die Vertretung auf Linux-Messen schafft nur zum kleinen Teil eine Verbindung zum Zielpublikum (Lehrer/innen, Bildungsträger). Andere Kanäle der (Be-)Werbung könnten gesucht und erprobt werden. Gezielte promotion bei Schulausrüstern, EDV-Dienstleistern, zentralen Schulverwaltungsorganen, Pädagogik-Dachverbänden, Stadtverwaltungen, Fortbildungsstellen, etc., wird vorgeschlagen.

- Linux-Produkte haben es schwer bei klassischen EDV-Dienstleistern. Trotz vielfachem Interesse besteht beim Fachgewerbe zugleich Unsicherheit; das know-how liegt typischer Weise im MS-Windows-Bereich. support-Bereitschaft und -Qualität wären demnach förderbar durch eine technische Dokumentation und durch eine Admin-Dokumentation die speziell für professionelle ( und auch für nichtkommerzielle) Dienstleister gemacht ist.

Philipp bot einen kurzen Vortrag über die _ArbeitsGemeinschaft_ _SchulServer_ (AGSS). Ziel ist es, Möglichkeiten der Zusammenarbeit und der Koordination für die verschiedenen Schulserver- und die Schul-software-Anbieter zu fördern. Auch ein gemeinsames öffentliches Auftreten liesse sich darüber verabreden. Gedacht sei hier vor allem an die Gemeinsamkeit der open-source-basierten Projekte und an Produkte für die ein gemeinsames Sprachrohr nützlich wäre. (vgl. http://agss.schul-netz.de/index.php/Hauptseite)

Im Ideal ist erwünscht dass zwei Vertreter von jedem Projekt einer regelmäßigen Arbeitsgruppe angehören, dass somit paritätische Verhandlungen und Gespräche stattfinden können. Bei der Gründung und unmittelbar danach waren diese Bedingungen nicht realisierbar. Die noch junge AGSS kann und soll sich aber weiterentwickeln.

Im technischen Bereich sollen Normen und Rahmenspezifikationen erarbeitet werden, die es Anwendungs- und Inhalteanbietern erleichtern würden, ihre Produkte in die Systeme zu integrieren bzw. auf jenen aufzusetzen. Klassische Lehrmittelverlage hätten ein Interesse daran; den Schulen käme es ebenfalls zugute. Arktur würde sich dementsprechend als Plattform interessanter machen, bzw. sich interessant halten.

In der Diskussion werden auch Zweifel geäussert an der Nützlichkeit der AGSS und an der Tragfähigkeit der Ziele. Der Einfluss verschiedener Partner sei ungleich und die Arbeit nicht genügend transparent. Sie würde vorwiegend den kommerziellen Interessen helfen. Das Arktur-Projekt sei hier als non-profit-Partner nicht zwangsläufig Nutzniesser.

Die Anwesenden sind mit 9 Zustimmungen und zwei Enthaltungen dafür dass Reiner und Uwe das Arktur-Projekt bis auf weiteres offiziell bei der AGSS vertreten. Es soll von beiden in Zukunft der Informationsfluss zu den anderen Entwicklern (über Berichte in der dev.-mailing-Liste, etc.) gewährleistet werden. Uwe und Reiner erklären sich einverstanden die Arktur-Vertretung bei der AGSS zu machen. Diese Regelung dürfte vorbehaltlich dessen gelten, dass kein anderer Entwickler des 'Arktur-Teams' dagegen Widerspruch erhebt. Erwin wird die Delegation in der dev.-mailing-Liste bekannt machen.

Das Mittagessen fand gegen 13:30 Uhr in der Kantine des Hauses Statt, nicht weit von den Tagungsräumen enternt. Serviert wurden Kotelett mit Spargel und zum Nachtisch Eiscreme mit warmen Früchten.

Im Anschluß an die Mittagspause erfolgt ein Vortrag von Dr. Henry Herper aus Magdeburg über die Fachlehrerausbildung_im_Bereich_Informatik_ an der Uni Magdeburg. Er spricht die Probleme an, welche durch Anpassung der Ausbildungskapazität und durch Umstrukturierung der Studiengänge entstehen (Verkürzung der Studiendauer, Trennung der Abschlüsse in Bachelor und Master).

Weiter folgt eine Praxis-Beschreibung für eine _X-Terminal-__/ Application-Server-Lösung_ auf Basis von hardware und software von Sun. Volkmar Hinz beschreibt beispielhaft die Ausstattung des Fachbereiches, die Erweiterungsplanungen, die Leistungsgrenzen und die spezifischen Vor- und Nachteile, welche eine solche Ausrüstung bietet.

Die Anpassung der Lösung an einen Arktur als Anwendungsserver wäre im Prinzip möglich. Besonders problematisch ist die Nutzung von lokalen Geräten (Drucker, Audio, CD-Laufwerke, etc.), welche ggf. den entfernten Anwendungen zur Verfügung gestellt werden müssen. Das Durchreichen von Daten verursacht Rechenlast und Latenzzeiten (vgl. Schaubilder)

Pläne zur Ausrüstung des _Team-Server_ und dessen theoretische Möglichkeiten werden von Harry beschrieben und von Erwin illustriert (vgl. Schaubilder). Dieser Server ist als 'root server' bei Strato gemietet und bietet ein vollständig autonomes handling, einschliesslich Zugang zu einer seriellen Konsole und der Möglichkeit in Notfällen ein 'rescue system' zur Meta-Administration zu starten.

Das System (dessen Rechenleistung und hardware) soll in virtuelle Umgebungen aufgeteilt werden (Systempartitionierung). Das wird vorzugsweise mit Hilfe von UML und QEMU geschehen. Mit Blick auf die Bedürfnisse der user ist die Einrichtung einer kommerziellen VM-Ware-Server-Umgebung im Gespräch; primär sollen die Wünsche aber mit freien Virtualisierungssystemen realisiert werden.

Neben dem Basis-System, welches nur der Administration dient, sind mehrere Systeme vorgesehen: I/O, firewall- und routing, server space, user work space, Entwicklungs-Test-Umgebung(en), (bis hin zu einem virtuellen netzwerk mehrerer virtueller Rechner). Die Nutzung des Team-Server kann dabei nur über eine geschützte (getunnelte) Verbindung vom lokalen Arbeitsplatz-PC zum Server realisiert werden.

Der host soll keine öffentlichen Dienste anbieten. Er soll neben den Test-Umgebungen vor allem den pool an Entwicklungs-ressourcen beherbergen. Von diesen aber vorerst nicht die Dokumentation. Auch sollen dort soweit vermeidbar keine Dienste bereitstehen, welche der Team-internen oder der kooperativen Kommunikation zwischen einzelnen Entwickern dienen. Selbige sollen auf anderen, auf öffentlich zugänglichen hosts eingerichtet werden. Serverseitige Daten über die informiert und kommuniziert werden muss sollen deshalb vom Server auf externe Systeme ausgelagert, gespiegelt, oder selektiv herauskopiert werden.

Andererseits soll der Rechner mit einem Entwicklungsmanagement-System ausgestattet werden, welches Übersicht über Arktur-Komponenten, Zuständigkeiten, Entwicklungsstatus, Fristabschätzungen, den gemeinsam zu aktualisierenden Allgemeinstatus und dergleichen beschreibt. Zudem erhält der host einen Mechanismus, der auf einfache Weise die Durchführung von Abstimmungen ermöglichen soll.

Die konkrete Gestaltung wird sich nur in Schritten und nur anhand der Wünsche (!) der Team-user, sowie der Erfahrungen herausbilden. Intensive Beteiligung der Arktur-Entwickler ist deshalb erbeten. Die derzeit tätigen Admins des Teamserver (Alex und Harry) versuchen allen Wünschen so gut wie möglich zu entsprechen.

Ein komplexer Dialog entwickelte sich zum Thema _Teamentwicklung_. Die Anwesenden waren sich weitgehend darin einig dass dies eine sehr wichtige Bedingung für den möglichen Erfolg einer Arktur-fünf-Version werden wird. Auch sehen alle, dass die Arbeiten und der Umgang miteinander in der Vergangenheit viele Wünsche offen liessen. Das Image des Arktur-Projektes wird als gegenwärtig negativ und als nach unten tendierend gesehen! Verwunderung besteht darüber bei den Anwesenden nicht. Es gab in Vergangenheit ausreichend viele Probleme. Zudem wurden diese oft in unvorteilhafter, selbstzerstörerischer Weise öffentlich gemacht. Und es gibt keine klar erkennbare Richtung. Die Langfristigkeit und Zuverlässigkeit der Arktur-Entwicklung steht allgemein im Zweifel.

Es wurde entsprechend intensiv nach Änderungs- und Verbesserungsmöglichkeiten gesucht. Dennoch wurde (in gewohnt schlechter Tradition) zwischendurch immer wieder auch über technische Gretchenfragen diskutiert, was jeweils nicht weiterführte. Letztlich gab es eine Reihe sehr guter Ideen und empfehlende Vereinbarungen:

Ein von Hans-Dietrich Kirmse stammender Vorschlag soll es für Aussenstehende einfacher machen zur Entwicklung beizutragen. Es soll ihnen die Möglichkeit geboten werden _eigenständige_Arktur-Ergänzungen_ zu produzieren, die dann in die software-Kollektion aufgenommen werden. Diese Lösungen sollen zusammen mit dem Server angeboten werden. Sie sollen also möglichst im download-Bereich mit aller anderen Arktur-software bereit gelegt werden. Sie sollen in geeigneten Listen geführt werden und sollen in angemessenem Umfang mit vermarktet werden.

Support und Fehler-/Update-Management kann auf die eigenständigen Ergänzungen ausgedehnt werden. Über eine mögliche Aufnahme auf die Arktur-CD, bzw. in das CD-image soll erst zu späterer Zeit beraten werden. Zunächst bleiben die freien Ergänzungen grundsätzlich ausserhalb der CDs.

Alle software der erweiterten Kollektion soll natürlich gewissen Bedingungen entsprechen. Sie muss unkommerziell und offen sein wie Arktur selbst. Die software muss sich integrieren in das gesamte System, darf keine Konflikte mit anderen Komponenten oder Features bereiten. Sie sollte keine Manipulationen am Grundsystem vornehmen die den Spezifiaktionen der jeweiligen Arktur-Version widerspräche. Sie sollte an (noch bereitzustellenden) regulären Schnittstellen anbinden und möglichst selbst (Arktur-) richtlinienkonform konzipiert und kodiert sein. Kommerzielle software sollte passive Hilfestellung erhalten, durch klare und geeignete Schnittstellen, durch ausreichende Dokumentation und durch Langfristigkeit der Arktur-Konzepte.

Die Erwartung der Tagungsteilnehmer ist, dass anhand dieser kooperativen Haltung einerseits die Leistungsfähigkeit des Schulservers erhöht wird, dass andererseits zu einer Beteiligung im 'Arktur-Team' angeregt wird. Die Einstiegshürde wird gewissermassen gesenkt. Interessierte müssen nicht gleich richtig einsteigen, können aber jederzeit in das Team aufgenommen werden. Im Verlaufe einer erfolgreich koexistenten Entwicklung dürfte es zu einer Annäherung kommen, die eines Tages die Aufnahme der Komponente in den Grundbestand naheliegend macht. Zudem dürfte es bei den unabhängigen Entwickern und Entwicklerinen zur Verbesserung ihres technischen Arktur-Wissens und zu persönlichen Beziehungen mit Team-Mitgliedern führen. Also wäre die Übernahme von Teilverantwortung (im Team) für das ganze Projekt nach gewisser Zeit nur noch ein kleiner Schritt.

Die zum Stichwort Öffentlichkeitsarbeit besprochenen Empfehlungen zählen aufgrund von Nebeneffekten ebenfalls zu den Team-fördernden Massnahmen. Die Bemühung um ein _gemeinsames_Sprachrohr_ und die Ideen der besseren Vermarktung fördern (und erfordern) eine allseitige Zusammenarbeit.

_Neue_Entwicklungsrichtlinien_ werden als zwingend notwendig erachtet, weil nur so eine aufwandsarme und halbwegs reibungslose Zusammenarbeit möglich ist. Die verbindliche Anwendung wird gefordert! Für die gestaltete software wird eine _technische_Entwickler-Doku_ gewünscht. Sie muss es möglich machen die Arbeitsweise einzelner Funktionen leicht zu verstehen und die Zusammenarbeit verschiedner Komponenten schnell zu überblicken.

Egalitäre Team-Arbeit macht häufige Gemeinschaftsentscheidungen notwendig. Zur Erleichterung von Beschlüssen soll ein _Abstimmungs-Mechanismus_ eingerichtet werden. Erwin wird auf dem Team-Server einen Service einrichten, der unkomplizierte, freie und offene Stimmauszählung ermöglicht. Teilnahmeberechtigt wären automatisch die auf dem Server mit account versehenen Mitglieder des Arktur-Team.

Auch das Für und Wieder einer _Institutionalisierung_ des Arktur-Team wurde erörtert. Neben den möglichen Vorteilen (Geschäftsfähigkeit, Haftungsübernahme, Verfassung, Weisungsrecht, etc.) werden die Nachteile (organisatorischer Aufwand, Unbeweglichkeit, Invasionsgefahr, usw.) gesehen.

In Frage kämen laut Gespräch die Gründung eines Vereines, einer Gesellschaft, Stiftung und dergleichen. Alternativ zur Idee der Selbstgründung erfolgte der Vorschlag, mit einer vorhandenen (unabhängigen) Institution eine Übernahme der Team-Vertretung auszuhandeln, sicherlich unter Abgabe eines gewissen Teils der Autonomie, aber vermutlich unter Erhalt von mehr Stabilität und von zusätzlichen Handlungsoptionen. Zuletzt waren sich die Anwesenden einig, dass es gegenwärtig zu früh wäre diesen Weg in irgend einer besprochenen Richtung zu beschreiten. Die Klärung wurde deshalb auf unbestimmte Zeit verschoben.

Das _Abendprogramm_ begann (ca. 18:00 Uhr) mit einem geschlossenen Spaziergang der Gruppe durch Parkanlagen und zu einem Strandrestaurant. Einem toller Blick auf die Elbe und auf die variationsreich vorbeiziehenden Schiffe war von hier möglich. Manches Thema, welches am Tage etwas kurz gekommen war wurde hier von einzelnen Teilnehmern vertieft. Im Vordergrund standen natürlich bei allen der persönliche Austausch und privates Kennenlernen und feiern.

Im individuellen Programm war anschließend ein Besuch der "Nacht der Wissenschaften" möglich. Auf dem weit ausgedehnten Uni-Campus wurde in zahllosen Instituten erstaunliches gezeigt. Es war erkennbar dass diese Schau bei der jüngeren Bevölkerung auf großes Interesse stieß. ..Ständig verkehrten Busse in Sonderfahrten zwischen den einzelnen Standorten der Hochschule und saugten Besucher auf oder spuckten sie wieder aus. Das Hochschulgelände glich einem Flughafen zur Sommer-Reisezeit.

Im Fachbereich Informatik (FIN) wurden rollende und kriechende Roboter, (autonome Roboter und Telerobotik), e-learning-Komponenten, interaktive und adaptive Sprachsysteme, Filme und vieles andere gezeigt. Im Fachbereich Chemie wurden Werkstoffkunde an Siliziumchipoberflächen und alle Arten von Spektroskopie und Rastermikroskopie alltagsnah vorgeführt. (vgl. Schaubilder)

Ein schlanker _Basis-Arktur_+_Modularisierung_ wird für die Version 5 vorgeschlagen. Das wurde allseitig begrüßt. Ziel ist dabei, das ursprüngliche Konzept von Arktur als einfachem und leicht handhabbaren System zu erhalten. Es ist davon auszugehen, dass dies für die allermeissten Nutzer nach wie vor die wichtigste Eigenschaft ist und das so bereits 90 Prozent aller funktionalen Wünsche erfüllt sind. Bezogen auf die wichtigsten älteren Distirbutionen sollten unbedingt Migrations- mechanismen bereitgestellt werden.

Um der Verwässerung des alten Konzeptes, also einer Abkehr der treuen Nutzer zu entgehen sollen, soll eine immer stärker geforderte und immer besser realisierbare, erweiterte Funktionalität von Arktur 5 bevorzugt in modularer Form angeboten werden: Zum einen sollte bereits bei der Installation zwischen verschiedenen Leistungs-level gewählt werden können, zum anderen sollte es später möglich bleiben features anhand einer Modul-Liste hinzuzufügen, indem die Installations-CD erneut angewendet wird. Alternativ könnten Module natürlich auch via download service bereitgestellt und dann eingebunden werden.

Alle Module sollen sich nahtlos in die Bedienoberfläche(n), die Dokumentation, in die Konfiguration und die Gesamtfunktion einpassen. Das integrierte äussere Bild von Arktur soll also trotz Baukastentechnik erhalten bleiben! In diesem Punkt sind Arktur-Module von eigenständigen Ergänzungen (von Aussenstehenden entwickelt) zu unterscheiden. Für letztere kann keine enge Integration gefordert oder ermöglicht werden.

Eine _Arbeitsgruppe_Struktur_und_API_ schien den Tagungsbesuchern notwendig. Sie wird von einigen Anwesenden (Harry, Andreas, Helmut) initiert. Eine Beteiligung weiterer Interessenten ist erwünscht! Informationen zur Arbeitsweise und zu Zugangsmöglichkeiten dürften von den Gründern noch bekannt gemacht werden.

Die Gruppe müsste sich nach Vorstellung der Tagungsteilnehmer zukünftig um die Erarbeitung der Serverstruktur und um eine Spezifizierung von Schnittstellen, sowie um die Erklärung des programming interface zur Arktur-eigenen Bibliothek kümmern. In späteren Schritten könnte die Gruppe die lib-Routinen beschreiben und für deren Erstellung sorgen.

Primäres Ziel ist jedoch die Deklaration von formal unabhängigen Teilbereichen:

Für die Teamarbeit ist es wichtig, klären zu können, in welche Aufgabenbereiche eine Angelegenheit fällt, bzw. welche Bereiche bei software-änderungen jeweils betroffen sind. Auch für die Designphase ist das natürlich essentiell wichtig. Parallele Entwicklungsarbeit vieler Leute dürfte ohne eindeutige und übersichtliche Abgrenzung von Teilbereichen kaum Erfolg haben (vgl. Schaubild). Hinzu kommt, dass Arktur nicht durch eine hohe Zahl von Gruppenleitern und controlling-Mitarbeitern überwacht wird, - ganz anders als es im kommerziellen Umfeld bei so großen Projekten üblich wäre. Die Selbstverantwortlichkeit der einzelnen Designer(innen) erfordert demgegenüber eine klare Gliederung.

Es wurde einige Male intensiv über die richtige _Basis-Distribution_ und über das allerbeste _Paketmanagement_ gesprochen. Ob ein Management notwendig ist, mag dabei eine definitorische Scheinfrage gewesen sein. Letztlich hielten alle Anwesenden eine klassische Linux-übliche Paketierung bei Arktur für notwendig! Ein Management in Eigenbau (mit TGZ-Paketierung) und RPM- bzw. DEB-Managementmechanismen, sowie Kooperation mit einem handveredelten, bereits fertig für Serverbetrieb selektierten Eisfair-System (vgl. www.eisfair.org), wurden genannt.

Aus welcher fremden Distribution die Server-Basis gebaut werden sollte, dazu gab es auch auf der Tagung keine Einigung. Das Problem konnte aber gelöst werden durch die mehrheitliche Forderung, auf beliebige Distributionen aufsetzten zu können. So entfiele eine Entscheidung.

Nun macht es aber kaum Sinn, ein anderes als das in der Baisis-Distribution bereits integrierte Managementsystem auch für die Pflege im Schulserver zu verwenden. Um Arktur für alle Trägersysteme offen zu halten wären demnach beliebige Paket-Managementmechanismen zu unterstützen. Keine leichte Sache. Sollte es nicht gelingen, so bestünde nur eine vorläufige Lösung und das Problem würde in neuer Gestalt wieder auftauchen.

Mit großer Mehrheit plädieren die Anwesenden für die Verwendung von _LDAP-Techniken_ in Arktur 5. Dies wird als wichtig erachtet, da es in Linux-Servern zum allgemeinen Standard zu werden scheint. Wegen der funktionalen Wünsche die an Arktur bestehen, scheint es zudem eine gut geeignete Lösung zu sein. Umsichtige Stimmen erwähnten dass es auch andere, vergleichbare Techniken gäbe. Kritische halten gar einen LDAP-Verzicht und die weitere Nutzung der klassischen Unix-Mittel (/etc, und so) für ausreichend. Ein Kompromiss konnte hier leider nicht gefunden werden; LDAP (nur) als optionale Komponente wird weitgehend als unbrauchbar betrachtet.

Reiner wurde per Abstimmung (bei zwei nein-Stimmen) gebeten eine _Portierung_für_einen_Arktur_5 auf Basis von SUSE als Trägersystem zu erarbeiten. Gleichzeitig wird öffentlich dazu aufgerufen entsprechendes mit Debian oder mit anderen Distributionen zu machen. Missverständlicher Weise ist noch gar keine Version 5 spezifiziert oder gar entwickelt, so dass es auf den ersten Blick unmöglich erscheint.

Der unterstützte Vorschlag sieht jedoch im Detail vor dass Reiner zunächst (im Juni) die nötige Zeit nimmt Version 4 fertigzustellen.

Danach will er diese erstmal zu einer Version 4.5 erweitern, was bis etwa September fertig sein soll. Der Arktur-4.5 soll danach als Realisierungsstudie, vorbehaltlich seiner Eignung, von Reiner als Grundlage für Arktur-5 ausgebaut werden. Zumindest für die eine Portierung läge also ein rudimentär fertiges System vor, wenn auch (vermutlich) erst gegen Ende des Jahres.

Prüfung und Nachbesserung der Machbarkeits-Studie mögen dann noch etwas Zeit brauchen. Danach wäre der Weg frei, Arktur-5 im Team zu entwickeln. Falls nicht doch konkurierende Studien vorliegen. Gegebenenfalls müsste die beste Alternative in weiteren Prüfungen gefunden werden. Dann aber können alle Arktur-Entwickler(innen) die breite Kreativität voll auf ein System konzentrieren. Die unterlegenen Systemstudien dagegen sollen nach allgemeiner Meinung auf Eis gelegt werden, denn alle Team-Entwickler wünschen sich am Ende einen einzigen Arktur.

*Die im Text angesprochenen Anlagen und weitere aktuelle Dokumente sind demnächst zu finden via "http://www.heise.de/ct/schan/devel/.*"
--
MfG (Erwin Flohr)
Projekt "Schulen ans Netz", Redaktion c't

-----------------------------------------------------
c't - Magazin fuer Computertechnik
Heise Zeitschriften Verlag Tel.: +49 511 53 52 -300
Helstorfer Str. 7 Fax: -417
30625 Hannover



Kommentare

Einen Kommentar hinzufügen



 Suchen:


 Umfrage

(Nur für angemeldete Benutzer)

Was wird hier am meisten vermisst?

[ Ergebnis | Umfragen ]

Stimmen: 621
Kommentare: 0

 Zitate

O Herr, schmeiss Hirn vom Himmel, und schenke es meinem PC.

-- anonymous