[Allegro] update.exe / 32 bit

[Thomas Berger]

Lieber Herr Wolf,

> Zur Antwort von Thomas Berger:
> 
>> "Andererseits ist es befremdlich (aber natuerlich real), dass Anwender
>> anscheinend allerorten erstens selbstgestrickte .bat-Dateien haben, in denen
>> die Aufrufe fuer Exporte nicht durch ein allgemeines allegro-Upgrade von
>> selbst umgestellt werden, und zweitens dann irgendwie nicht in der Lage
>> sind, diese selbstgemachten Dateien ausfindig zu machen und anzupassen."
> 
> Was ist daran eigentlich befremdlich oder merkwürdig ? 
> 
> Ich habe in 'meinen' Bibliotheken eigentlich noch nie eine andere Situation
> vorgefunden. Und gerade wegen der Anpassungsfähigkeit und dem
> Alleinstellungsmerkmal 'Flex' wird allegro-C ja eingesetzt. 
> 
> Und ich verweigere mich auch als Supporter der kompletten Angleichung an
> irgendein definiertes System, auch wenn dies aus Supportsicht vernünftiger
> wäre. Aus Bibliothekssicht wäre es unvernünftig. Ein wenig Anarchie in der
> ansonsten immer restriktiveren Bibliothekswelt muß sein und wird bleiben.

Sie haben recht, das Phaenomen betrifft nicht nur .bat-Dateien.

"Normal" finde ich eigentlich die beiden folgenden Faelle:
Ein Anwender ist in der Lage, mittels inst-all allegro zu installieren,
und er ist es zu einem spaeteren Zeitpunkt ebenfalls (desgleichen in
aufsteigender Schwierigkeit: .Bat-Dateien anpassen, Parameterdateien
anpassen, mehrstufige Listenproduktionen zu implementieren, komplexe
Datenfluesse zu organisieren, im Keller ein Protonensynchroton zu bauen).

Oder: Der Anwender holt sich beim ersten Mal bereits Hilfe dazu, spaeter
dann wieder.

Bekannt sind Faelle "hoeherer Gewalt", wenn etwa die Netzwerkadministration
ausgesourct wird, die Fremdfirma die Schrauben anzieht und daraufhin
staerker auf Fremdfirmen zurueckgegriffen muss, um die die Anwendungen
zu aktualisieren, die man vorher selber aktualisieren konnte und nun nicht
mehr *darf*. Oder wenn der Mitarbeiter verrentet wurde, der sich damit
auskannte und andere Faelle von institutionellem dumbing-down.

"Kritisch" finde ich die Faelle, wo man anfangs viele Aenderungen gemacht
hat und sich nun ausserstande sieht, bei einem Upgrade diese Aenderungen
zu beobachten und ggfls. zu korrigieren und daher (scheinbar) in einer
Situation ist, wo weder Software- noch Hardware- bzw. Betriebssystem-
aktualisierungen moeglich sind (die von mir vorhin erwaehnte Bibliothek
mit Version 13 kann z.B. immer noch nicht von Win'9x auf eine NT-basierende
Plattform migrieren). Nachgerade putzig (oder tragisch) die Variante, wo
man initial viel in externe Hilfestellungen investiert hat und dann in
einer Update-Sackgasse steckt. Erfahrungsgemaess werden spaetestens nach
fuenf Jahren irgendwelche Rechner ausgetauscht oder Betriebssysteme
aktualisiert und jede noch so gute und kontrollierte Installation zeigt
Verfallserscheinungen. Und selbst der Enthusiast, der dort vielleicht
sogar voellig umsonst eine blinkende und blitzende Umgebung aufgebaut
hat, ist frustriert, wenn er mit ansehen muss, wie "seine" Installation
langsam den Bach herunter geht und die Anwender anfangen zu schimpfen,
dass "allegro" nichts taugt (gut fuer allegro: Diese Anwender zahlen
oft jahrzehntelang die Abo-Gebuehren ohne ein einziges mal die Software
zu aktualisieren. Schlecht fuer allegro: Sie erwarten dennoch, dass
irgendwie alles von selbst besser wird). Es scheint dann manchmal zu einem
Befreiungsschlag zu kommen, d.h. jahrzehntelang wurde nichts getan, dann
aber teuer ein anderes Bibliothekssystem eingefuehrt, weil das moderner ist
(das ist dann oft auch schlecht fuer die Bibliothek, weil ich ebenfalls
fuer wichtig halte, was Sie oben "Anarchie" genannt haben, ich aber
eher autokephal nennen wuerde).

a30 koennte ein Ausweg aus diesem Dilemma sein, weil es ueberhaupt
keine Voraussetzungen mehr an Arbeitsplaetze stellt, einige
Bibliotheksverbuende haben sich ja auch bereits das remote Hosting
von Bibliotheksanwendungen als Arbeitsfeld erschlossen, dann braucht
die Bibliothek auch keine Server mehr. (Der erste Versuch ist
allerdings, der Bibliothek eine Verbundteilnahme schmackhaft zu
machen, weil sie dann angeblich ueberhaupt kein Lokalsystem mehr braucht)

allegro kann da a priori schon nicht mithalten, einerseits sind die
Einstandskosten nie so hoch, dass Investitionssicherung zum Thema wird,
und andererseits ist es sowieso wegen niedrigem Betreuungsaufwand und
niedriger laufender Kosten bekannt. Und jeder (personelle oder
finanzielle) Aufwand, der nicht mindestens einmal jaehrlich eingeplant
werden kann, ist ein administrativer GAU...

 --

Ein Supporter hat allerdings Arbeitsvermeidung als Prinzip verinnerlicht
(vgl. etwa auch die drei Tugenden des Perl-Programmierers: Ungeduld,
Faulheit und Ueberheblichkeit), aber idealerweise das Instrumentarium,
so dass er weder in Update-Sackgassen stecken bleiben noch die Zahl
der Aenderungen mit der Zahl der betreuten Installationen multiplizieren
muss. Und es geht ihm wie dem Versicherungsvertreter: Wenn es nie
hagelt, schliessen die Kunden auch keine Policen ab, wenn es zu oft
hagelt, ist es auch schlecht fuers Geschaeft...

Jedenfalls muss es nicht das eine Standardsystem geben (insbesondere
nicht das, auf das wir alle immer so gerne schimpfen), andererseits
wird aber insbesondere jeder Supporter "seine" Art und Weise gefunden
haben, gewisse Dinge zu organsieren, so dass er Synergien aktivieren
kann, auch in Faellen, wo ein Einzelanwender vielleicht doch das Rad neu
erfinden wuerde oder muesste.

Speziell ein allegro-Supporter ist eigentlich ein wandelndes Paradoxon,
denn die allegro-Idee ist bekanntlich, dass die Anwender alles selber
machen koennen, wozu also noch extra Support? Die Anstrengungen, allegro
open-Source zu machen, bringen uns aber in Kontakt mit einem anderen
Bereich (naemlich dem der Open-Source-Software), wo das ebenfalls gilt.
Allerdings haben weder ich noch Millionen anderer Anwender etwa des
Apache-Servers jemals dessen Quellcode auch nur angeschaut, und dennoch
profitieren wir von dieser theoretischen Moeglichkeit, indem wir das
nachnutzen, was andere durch Wahrnehmen gerade dieser Moeglickeit
haben realisieren koennen. Und Apache und anderes wird ja nicht
unbedingt von Hobbyprogrammierern vorangetrieben, die tagsueber
Bluemchen verkaufen um Geld zu verdienen und abends einen Ausgleich
suchen. Ich gehe eigentlich davon aus (weiss es aber nicht sicher),
dass grosse Anwender einen Teil der Kostenersparnis durch Open Source
in Personal umsetzen bzw. spezialisierte Supporter / Entwicklerl
beauftragen bzw. die Apache Foundation mit mitteln ausstatten, so
dass die Entwicklung getragen wird von Leuten, die als Hauptberuf
Apache kennen (so dass sie im Fall eines Security incidents oder
eines Feature requests sofort eingreifen koennen).

viele Gruesse
Thomas Berger