Re: Stellungnahme zum Suse-Handbuch
Hallo,
bin gerade aus dem Urlaub zurück und konnte deshalb nicht eher auf diese
Mail reagieren. Da aber genau Mails von mir für eine Negativwertung eines
anderen Schulservers (Arktur) herhalten mußten, möchte ich doch dazu eine
Darstellung aus meiner Sicht abgeben.
Peter Voigt schrieb:
>
> Denn auch bei Arktur schlagen Vorentscheidungen bei der Auslegung des
> Schulservers auf das Handbuch durch. Die grundsätzliche Problematik stellt
> sich ähnlich dar wie bei Suse.
Aber sicher doch. Natürlich soll das Handbuch zum Server passen, also
MÜSSEN Vorentscheidungen bei der Auslegung des Schulservers auf das Handbuch
durchschlagen. Weiteres zur Wertung des SuSE-Handbuchs in einer 2. Mail.
> Das Arktur-Handbuch beschreibt allein die Server-Funktionalitäten, weil Akrtur
> nur solche Funktionalitäten anbietet.
Es ist sicher korrekt, dass Arktur _nur_ einen lehrersicheren Server
bereitstellt, aber der ist für Anwender doch recht umfassend dokumentiert.
und es ist ebenfalls dokumentiert, wie man Linux-, Mac- und Windows-Clients
anbindet und weiterhin, wie man bestimmte Programme (Netscape, Mozilla,
IRC-Client u.a.m.) konfiguriert. Das bedeutet für mich, dass das Handbuch
_deutlich_ mehr als nur Serverfunktionalität beschreibt.
> Skolelinux bietet weitaus mehr, nämlich eine Komplett-Lösung mit Server,
> Terminalserver, netzwerk-angebundenen Workstationen und netzwerk-unabhängigen
> Workstationen.
Es ist natürlich richtig, dass Skolelinux eine Komplettlösung auf einer CD
bietet. Es sollte aber nicht der Eindruck entstehen, dass man das mit Arktur
und dem LTSP-Projekt nicht genauso einfach auf die Reihe bekommt. m.E. ist
der LTSP-Server genausogut wie Arktur verfügbar und ist gut dokumentiert.
Das einzige was offen war ist die Anbindung von solchen Terminalservern an
Arktur. Deswegen bin ich Dieter Kroemer sehr dankbar, dass er auf meine
Bitte einen Arktur 3.5 gezogen hatte und die Anbindung eines Terminalservers
an Arktur dokumentiert hat. (Diese Doku ist ab der Version 3.5rc4 dabei.)
Natürlich ist eine solche Lösung nicht auf einer einzigen CD, aber ob
dieser Nachteil sooooo tragisch ist?
> Da scheint mir ein Vergleich der Handbücher nicht wirklich sinnvoll zu sein.
> Dafür würden sich nur Äußerlichkeiten anbieten, etwa in der Art, wer die
> bunteren Bilder hat.
warum soll denn überhaupt verglichen (und gewertet) werden? Wenn jemand
wie z.B. Lars das Handbuch bereitstellt, dann ist es doch sicher als ein
Angebot zu verstehen, dass _eigene_ Handbuch verbessern zu können.
Als Motiv für dieses unbedingte Vergleichen wollen sehe ich den Wunsch, sich
selbst (gut) darzustellen. Wenn dem so wäre, dann würde man natürlich auch
versuchen, auf (vermeintliche) Fehler von anderen hinzuweisen oder noch
extremer, diese zu werten - natürlich aus der eigenen Sicht heraus.
Ich denke, obwohl Vergleiche zum geeigenten Zeitpunkt sehr sinnvoll sein
könnten, dass in der momentanen Situation insbesondere in Hinblick der
anvisierten Zusammenarbeit/Kooperation solche Vergleiche insbesondere
Wertungen derzeit nicht erfolgen sollten.
> Der zur Zeit auf der Arktur-Developer-Liste stattfindende Mailverkehr über
> Probleme, die Folge des aktuellen Versionssprunges sind, belegt
> eindrucksvoll, dass der Versuch einer funktionalen Begrenzung der
> Benutzeroberfläche zwar gewisse Erleichterungen in der täglichen Praxis
> bietet, bei "richtigen" Problemen aber versagt.
Ich gehe davon aus, dass die Mails um die Nutzung der ACLs gemeint sind. Da
auf genau diesen angeblichen Problemen eine Kette von Schlussfolgerungen
abgeleitet wurden, möchte ich diesen "Mailverkehr" jetzt aus Sicht des
Verursachers darstellen.
Anlass für diese Mails (und auch anderer Threads) war folgender:
Es sollte die Dokumentation von Arktur 3.5 um "wichtige" Lösungen und
Tools erweitert werden. Der Ergebnis dieser Bemühungen kann man unter
http://www.arktur.th.schule.de/doku11/kap11.htm
nachvollziehen. Leider wurde bis zu diesem Zeitpunkt nicht alles geschafft,
insbesondere das Peter-Somm-Script stand auf der Defizit-Seite.
Es war mein Fehler angenommen zu haben, dass Peter Somm den Arktur 4 nutzt
und habe deshalb Rudolf gebeten, das Script anzupassen und diese Doku zu
erstellen. Da er ja auch noch einen anderen Thread (Zugriff auf den Server
mit SSH - eigentlich eine Standardlösung) von massiven Problemen
berichtete, ist die von ihm angegebene Erklärung mit Hardware-Problemen
durchaus nachvollziehbar. In Hinblick auf den Thread bedeutet das m.E.,
dass die Probleme von Rudolf getrost ignoriert werden können.
Peter Somm hat aber kurzfristig die Anpassung vorgenommen und diese Doku
erstellt und ich habe diese noch vor meinen Urlaub an Thomas Litsch
weiterreichen können.
Das Problem was ICH mit dieser Lösung hatte, ist eindeutig meinem fehlenden
Verständnis für Linux-Clients zu schulden. Aber einer der Entwickler (Karl-
Ernst Gruhler) hat mit Geduld mir dann klarmachen können, wo mein
Denkfehler liegt (diese Bereitschaft der Entwickler scheint mir genau die
zu sein, die in dieser Liste öfters vermisst wird - oder irre ich mich?).
Ohne mich jetzt dafür entschuldigen zu wollen, es ist aber durch diesen
Thread "herausgearbeitet" worden, dass für Linux-Clients (und vermutlich
auch für win2k-clients) das Konzept der Fachlehrergruppe hinfällig ist.
Als diese Fachlehrergruppe eingeführt wurde, war weder an win2k und auch
nicht an Linux-Clients (zumindest in größerem Umfang) noch nicht zu denken.
Zum Umfang des Threads hat auch die alternative Lösung von Helmut
beigetragen. Diese ist zweifellos ebenfalls sicher, erfüllt aber nicht
die Zielsetzungen für Arktur 3.5. Dort ging es darum, eine vorhandene
Version zu stabilisieren. Aber es ging nicht darum, diesen umzustricken.
Die ACL-Lösung ist sicher und ist zudem für die Anwender völlig
transparent. Bedeutet, ein Anwender braucht von ACLs keine Ahnung zu haben.
Das funktioniert trotzdem zuverlässig. Weiter: die Doku braucht sich nicht
zu ändern und für Umsteiger von Version < 3.5 gibt es diesbezüglich
kein "Umstellungsproblem".
Bei diesen Mailverkehr wurde noch in die Waagschale geworfen, dass die
ACLs für Arktur 3.5 nicht dokumentiert seien. Auch dieses "Problem" sollte
mit der angegebenen URL vom Tisch sein.
> Das ist meine Wahrnehmung aus der Ferne. Ich will aber gerne zugestehen, dass
> ich die technischen Details dessen, was derzeit an Problemen auf der
> Arktur-Liste erörtert wird, nicht nachgehalten habe. Und womöglich gelingt es
> ja, diese Probleme noch in den Griff zu bekommen.
Zusammengefaßt: es gab keine Probleme mit den ACLs bzw. Arktur 3.5, sondern
einzig und allein Probleme mit einem Tool, welches an Arktur 3.5 angepasst
und dokumentiert werden sollte. Alle aufgetretenen Fragen wurden geklärt
und das Tool (immerhin 3 Versionen!) wurde vom Entwickler angepasst,
getestet und dokumentiert. (wurde aber nicht auf der Seite bereitgestellt)
> Bei Skolelinux kann es solche Probleme aufgrund des anderen technischen
> Ansatzes nicht geben.
soll ich jetzt schlussfolgern, dass es kein html_public-Verzeichnis für
jeden Anwender gibt? Denn nur dann kann es dieses Problem nicht geben!
> Dafür bürgt schon der Umstand, die Funktionalität von
> Skolelinux nahtlos in das Package-System von Debian einzubinden.
Wenn man ein solches html_public-Verzeichnis bereitstellt, dann gibt es
immer die Problemstellung, wo und wie ich das bereitstelle. Entweder ich
plaziere das im Homeverzeichnis, dann habe ich zwar alle Dateien der User
an einer Stelle, aber dann muss ich dafür sorgen, dass der Apache ins
Homeverzeichnis reinkommt. Wenn ich das nicht so will, dann lege ich
dieses Verzeichnis eben woanders hin. Dann muss ich dafür sorgen, dass der
User bequem auf seine Dateien zugreifen kann (mein Favorit wäre da web-dav,
aber auch da gibts "Probleme" mit den Rechten). Auf jeden Fall sind in
Hinblick "Handling" neue Überlegungen fällig und es wird sicher bestimmte
Lösungen nach sich ziehen. Aber das ist normal. jedes System hat Vorteile
und Nachteile. Wenn man die Vorteile zum Tragen bringt und die Nachteile
kompensiert, dann ist es (fast) egal welche Lösung man nimmt.
Aber, dass hat mit dem Package-System von Debian absolut nichts zu tun!
:
> Das Entwicklungsmodell von Arktur, alles auf ganz wenige Personen zu
> konzentrieren und sich nicht an das Package-System der Basis-Distribution
> auszurichten, halte ich für problematisch. Was ist, wenn die maßgebliche
> Person (aus welchen Gründen auch immer) ausfällt und ein neues
> Sicherheitsloch akut wird.
im Archiv könntest du nachlesen, dass dieses Problem schon intensiv
besprochen wurde. Die Marschrichtung scheint bei den Entwicklern der
Version 3.5 und der Version 4 ebenso wie bei Heise klar zu sein.
Wie das dann bei einer Version 5 umgesetzt wird, das wird zum gegebenen
Zeitpunkt schon geklärt werden.
wo ich mir Sorgen mache könnte: Beim Entwicklertreffen ging es doch um
Zusammenarbeit, Kooperation ... . Wäre es da nicht angebracht, statt auf
vermeintlichen Schwächen und Problemen die Gemeinsamkeiten und noch besser
die gemeinsamen Ziele ins Auge zu fassen. Bei gegensätzlichen Ansichten
sollte in erster Linie Toleranz das entscheidende Wort sein oder wenn man
sich mit gegensätzlichen Ansichten auseinandersetzt, dann aus der Sicht
der anderen, sonst wird das Murks. Irgendwie vermisse ich das hier und
die Kooperation (trotz vorhandener gemeinsamer Ziele) sehe ich einfach
nicht in Gang kommen - leider.
/"\
Mit freundlichen Grüßen \ / ASCII ribbon campaign
Hans-Dietrich X against HTML mail
/ \ and postings
Reply to: