Changes between Version 14 and Version 15 of SoftwareKeplerReleases/Albrecht

Timestamp:

Dec 22, 2015, 2:03:32 PM (11 years ago)

Author:

Rüdiger Kupper

Comment:

Text überarbeitet

SoftwareKeplerReleases/Albrecht

@@ -4 +4 @@
 
 Liebe Kollegen,
-am 19. Dezember 2015 haben wir auf den Linuxrechnern des Kepler-Gymnasiums unser aktuelles Release des Betriebsystem-Images (Codename: "Ambitionierter Albrecht") ausgerollt. 
+am 19. Dezember 2015 haben wir auf den Linuxrechnern des Kepler-Gymnasiums ein neues Betriebsystem-Images ausgerollt (Codename: "Ambitionierter Albrecht"). 
 Es ist das erste in einer geplanten Reihe vierteljährlicher Releases.
 
@@ -10 +10 @@
 == Von //rolling releases// zu //point releases//
 
-Aus den Zeiten, in denen unser Netzwerk als //Linux Terminal !Server/Clients // (![1]) betrieben wurde, waren Sie es gewohnt, dass die Software auf unseren Linux-Rechnern kontinuierlich und im laufenden Betrieb aktualisiert wird (//rolling releases//). Die Software lief zentral auf unseren sieben LTSP-Servern, die Klassenraumrechner dienten nur als "Sichtgeräte".
-Das hatte den Vorteil, dass Sie von Sicherheits- und Betriebssystemaktualisierungen immer zeitnah profitiert haben; die Bereitstellung neuer Software war auf den Servern kurzfristig möglich.
+Aus den Zeiten, in denen unser Netzwerk als //Linux Terminal !Server/Clients // ![1] betrieben wurde, waren Sie es gewohnt, dass die Software auf unseren Linux-Rechnern kontinuierlich und im laufenden Betrieb aktualisiert wird (//rolling releases//). Die Software lief zentral auf unseren sieben LTSP-Servern, die Klassenraumrechner dienten nur als "Sichtgeräte".
+Das hatte den Vorteil, dass Sie von Sicherheits- und Betriebssystemaktualisierungen immer zeitnah profitiert haben; neue Software konnte auf den Servern von jetzt auf gleich bereitgestellt werden.
 
-Da das !Client/Server-System wegen seines eingeschränkten Benutzerkomforts gern kritisiert wurde, und mit Verfügbarkeit finanzieller Mittel und günstiger Hardware, haben wir in den vergangenen Jahren auf ein Netzwerk aus Einzelplatzrechnern umgestellt, die einmal ein Betriebssystem-Image vom Server beziehen, das dann lokal installiert und betrieben wird.
+Das !Client/Server-System wurde wegen seines eingeschränkten Benutzerkomforts gern kritisiert. Mit der Verfügbarkeit finanzieller Mittel und günstiger Hardware haben wir daher auf ein Netzwerk aus Einzelplatzrechnern umgestellt, die nur punktuell ein Betriebssystem-Image vom Server beziehen, welches dann lokal installiert und betrieben wird.
 Das hat den Vorteil, dass die Rechner eher das Verhalten zeigen, das Sie von zuhause gewohnt sind (grafisches Feedback, 3d-Fähigkeit, Wiedergabe von CDs/DVDs, etc.).
 
-Die Bereitstellung der Software ist damit allerdings umständlicher geworden. Wir müssen bei jeder Änderung ein vollständiges neues Betriebssystem-Image erstellen und an alle  Rechner im Kepler-Gymnasium verteilen. Das bedeutet u.a., dass wir jeden Rechner, der nicht dauerhaft an Netzwerk und Netzstrom angeschlossen ist (Fachräume, Notebooks, ...), physikalisch aufsuchen, aufbauen, anschließen, aktualisieren, wieder abbauen und verstauen müssen. Das ist einerseits aufwändig und birgt andererseits die Möglichkeit, dass beim Verteilen des Images etwas schief läuft. Möglicherweise waren die Rechner noch mit dem Herunterladen des Images beschäftigt, wenn Sie morgens in den Klassenraum kamen. Bei manchen schlug die Aktualisierung fehl, so dass sie mit einem veralteten Image weiter liefen, was für uns aber kaum zu bemerken ist, da wir nicht jeden einzelnen Rechner kontrollieren können. Zudem birgt die laufende Verteilung von Updates immer die Gefahr von Regressionen (etwas, was eben noch ging, funktioniert plötzlich nicht mehr).
+Die Bereitstellung der Software ist damit allerdings umständlicher geworden. Wir müssen bei jeder Änderung ein vollständiges neues Betriebssystem-Image erstellen und an alle  Rechner im Kepler-Gymnasium verteilen. Das bedeutet u.a., dass wir jeden Rechner, der nicht dauerhaft an Netzwerk und Netzstrom angeschlossen ist (Fachräume, Notebooks, ...), physikalisch aufsuchen, aufbauen, anschließen, aktualisieren, wieder abbauen und verstauen müssen.
+
+Das ist nicht nur aufwändig, sondern birgt auch die Möglichkeit, dass beim Verteilen des Images etwas schief läuft: Möglicherweise waren die Rechner noch mit dem Herunterladen des Images beschäftigt, wenn Sie morgens in den Klassenraum kamen. Bei manchen schlug die Aktualisierung fehl, so dass sie mit einem veralteten Image weiter liefen. Zudem treten bei laufender Verteilung von Updates zuweilen Regressionen auf (etwas, was zuvor noch ging, funktioniert plötzlich nicht mehr).
 
 Um einerseits diese Unwägbarkeiten für Sie zu minimieren und andererseits den Wartungs- und Kontrollaufwand für das Netzwerkteam zu reduzieren, werden wir zukünftig aktualisierte Betriebssystem-Images im Quartalsabstand verteilen (//point releases//).
@@ -22 +24 @@
  - Die Software und das Nutzer-Interface bleiben über drei Monate lang stabil.
  - Dadurch können Sie leichter Routinen für den täglichen Gebrauch und den Unterricht entwickeln.
- - Wir müssen den Aufwand, alle Rechner einmal zu aktivieren und zu aktualisieren (dies benötigt die Arbeit mehrerer Tage) nur einmal in zwölf Wochen betreiben.
- - Wir durchlaufen vor dem Ausrollen die üblichen Phasen (//feature freeze, release candidate, beta test, regression tests//), was die Qualität der ausgerollten Images verbessert.
+ - Wir müssen den Aufwand, alle Rechner einmal zu aktivieren und zu aktualisieren (dies benötigt die Arbeit mehrerer Tage) nur einmal in zwölf Wochen bewältigen.
+ - Vor dem Ausrollen durchlaufen wir die üblichen Phasen des Qualitätsmanagements (//feature freeze, release candidate, beta test, regression tests//), was die Qualität der ausgerollten Images verbessert.
  - Sollte die Aktualisierung bei einem Rechner fehlschlagen, so können Sie dies direkt erkennen und zurückmelden, weil wir Sie zu diesem Zeitpunkt über den neuen Release informieren.