Arktur-Tagung in Magdeburg 20. bis 21. Mai 2006

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

(Veröffentlicht am 25.Juni 2006 in schan-developer)

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äch 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 Verbesserungs-
möglichkeiten gesucht. Dennoch wurde (in gewohnt schlechter
Tradition) zwischendurch immer wieder auch über ü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 Arktur-wiki

--
  MfG (Erwin Flohr)
  Projekt "Schulen ans Netz", Redaktion c't