[Allegro] Quellensituation und Zukunftsfähigkeit

Mo Jan 12 12:57:03 CET 2015

Guten Tag Herr Eversberg,
danke für Ihre Nachricht.
Am Montag, 12. Januar 2015 um 09:03 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

A und B mag ich nicht kommentieren
aber zum "schlusslink" (m)eine anmerkung:

> Ausführliche Hinweise zu den Microsoft-Plänen:
> http://www.focus.de/digital/computer/windows/noch-zwei-wochen-support-ende-fuer-windows-7-das-muessen-sie-jetzt-tun_id_4382819.html
also, die quelle ist der focus.
dann gibt es noch etw3as ähnliches auf chip
http://www.chip.de/news/Notfall-Patch-fuer-Windows-Kritische-Luecke-jetzt-schliessen_74346377.html?obref=outbrain-www-fol
das ist alles mehr oder weniger MURKS und panikmache.

wenn, dann sollte man auf golem oder ct (heise) schauen. ich halte 
diese für objektiver und neutraler

egal:
der obige link vermittelt einem normalen leser ein falsches bild.
hier die info:
updates für vista gibt es ca 2-3 jahre noch.
updates für windows wird es 4-5 jahre geben.

hier, ich wusste es doch, es gibt eine offizielle mitteilung 
von microsoft:
http://windows.microsoft.com/de-de/windows/lifecycle
so falsch habe ich also nicht gelegen, mit meinen obigen 
zeitschätzungen ;-)
also: mit http://windows.microsoft.com/de-de/windows/lifecycle kann 
man rechnen! und nicht mit den hanswurstmeldungen von focus und co.

grüße aus radebergh
ihr klaus lehmann

> B.Eversberg

> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro

-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden;
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: Bolero 64bit. Fußige Noten aufgeblättert (=Die Fußnotendoku)
* 2014: allegro-zdb: endlich. Die Wiedervereinigung! + eBooks
* 2015: allegro-vufind. Endlich! Noch moderner! Web2 auch für Ihren Katalog?

Am Montag, 12. Januar 2015 um 09:03 schrieben Sie:

> Neben der Vorbereitung einer V35.1 kuemmern wir uns momentan um eine
> weitere und sehr notwendige Verbesserung der Quellensituation, d.h.
> der C++-Programme.

> Dazu und zur Frage der Zukunftsfähigkeit von allegro ein paar plakative
> Anmerkungen. Zeit für eine längere Abhandlung ist gerade nicht, aber
> zum Lesen einer solchen vielleicht auch nicht.

> Jede Software, die nicht sofort perfekt ist, also jede, wird
> irgendwann revisionsbedürftig. Das haben wir 1985 erlebt, als wir
> auf eine ganz andere Programmierplattform wechseln mußten (von
> Basic + Assembler auf C), und dann haben wir es 1995 erlebt, als
> es nötig wurde, nach langer Zeit der Unklarheiten ein Windows-Programm
> auf die Beine zu stellen, weil DOS unbeliebt wurde.
> 1985 mußte notgedrungen alles neu programmiert werden, aber der Umfang
> war noch nicht gewaltig groß. Außerdem: 1985 gab es noch nicht viele
> Anwender. Wir konnten deren Daten von der obsoleten Plattform auf die
> neue überführen und die Weiterarbeit ermöglichen.
> 1995 fand zwar intern eine erhebliche Umstrukturierung statt
> (Objektorientierung, Klassenbibliothek!), aber im Ergebnis mußten
> keine Nutzerdaten umstrukturiert werden, d.h. der Umstieg war
> in der Hinsicht schmerzlos. Das ist nicht normal, sondern bei einem
> größeren Versionswechsel ist oft eine Umwandlung der Nutzdaten in
> eine neue Struktur fällig. Es führt dann leicht dazu, daß Anwender
> den Wechsel scheuen und lange hinausschieben oder im Extremfall
> gar nicht mitvollziehen können, weil es als zu aufwendig empfunden
> wird und damit auch zu kostspielig. Wir sehen es z.B. bei MyCore und
> bei VuFind, daß eine deutlich bessere Neuversion sehr lange braucht,
> bis sie an der Basis "angekommen" ist. Seit 1985 haben wir keinen
> solchen Bruch riskiert. Gleichwohl gibt es immer noch Anwender,
> die mit 10 Jahre alten Versionen leben, obwohl sie ihre Daten mit
> der aktuellsten Version unverändert weiterbenutzen könnten, und nicht
> nur die Daten, auch alle Parameter etc. Aber irgendeinen Zwang zum
> Wechsel können und wollen wir schließlich auch nicht ausüben.
> Auch in diesem Jahr, mit V35, wird es so etwas nicht geben.

> Nun kommt aber auf der Welt weniges ohne Nachteile daher, und über
> die ist zu reden:

> A.
> Anwender fragen: Ist eine in der Kernstruktur so alte Software noch
> zukunftsfähig?
> Da gibt es drei wichtige Aspekte:
> 1. Entspricht sie noch heutigen und künftigen Nutzererwartungen?
>     Zu unterscheiden ist natürlich zwischen den Erwartungen der
>     Bibliothekare und der Endnutzer. Letztere sind geprägt von Google-
>     Erfahrungen, also von Suchmaschinentechniken. Diesen Erwartungen
>     kann man entsprechen durch Auslagerung der OPAC-Funktion in eine
>     angekoppelte VuFind-Umgebung. Was aber nicht heißt, daß man die
>     alcarta-, PHPAC- oder a35-Oberfläche dann aufgeben müßte, obwohl
>     vom Blättern in alphabetisch sortierten Listen ganz allgemein nichts
>     mehr gehalten wird.
> 2. Wie lange bleiben die Programme überhaupt noch funktionsfähig?
>     Windows 8 wird von Microsoft bis zum 1.4.2023 garantiert (s.u.).
>     Windows 10 wird evtl. etwas länger "leben", aber das weiß noch
>     keiner - 2025 ist aber wohl nicht zu hoch gegriffen.
>     Für Linux deutet sich kein solcher Meilenstein an; die GNU-Compiler
>     jedenfalls werden ganz sicher kompatibel bleiben.
> 3. Wird allegro Schritt halten mit dem neuen Umfeld RDA+BIBFRAME?
>     (Betrifft nur die normale Anwendung "Katalogisierung", und auch
>     diese nur, soweit RDA-Konformität gewünscht ist.)
>     RDA ist kein wirkliches Problem! Man kriegt nur hier und da neue
>     Uneinheitlichkeiten in den Fremddaten, aber davon gibt's ja immer
>     schon eine Menge.
>     BIBFRAME? Experten reden jetzt von 10 Jahren, bevor es ernsthaft,
>     also auf breiter Basis, MARC ablösen kann.
>     Das würde zu A.2. passen! Denn zwar nicht BIBFRAME selbst, aber die
>     damit verbundenen Erwartungen und Ansprüche werden ganz andersartige
>     Systeme fordern und diese werden entstehen. *Vorher* schon allegro
>     abzulösen durch etwas anderes, was *jetzt* schon existiert, das
>     ergibt deshalb wenig Sinn - es sei denn, andere Gründe als einfach
>     nur Zweifel an allegro sprechen für eine vorzeitige Ablösung, etwa
>     ein Verbundbeitritt. Denn man würde sich sonst nur auf eine anders-
>     artige Zwischenlösung einlassen, deren Tage gleichfalls schon
>     gezählt sind.

> B.
> Entwickler fragen: Ist eine so alte Software nicht im Kern auch
> softwaretechnisch veraltet?
> Klar ist sie das. Die wichtige Frage ist: Macht das was aus?
> Da gibt es ebenfalls zwei Aspekte:
> 1. Bleibt das Kompilieren auf neuen Windows- und Linux-Plattformen
>     noch möglich?
>     Nach allen bisherigen Erfahrungen: ja.
> 2. Werden unabhängige Entwickler die Programme noch genügend weit
>     durchschauen können, um Änderungen ausführen zu können?
>     Da liegt das größte Problem, denn die formale Struktur entspricht
>     ganz und gar nicht den heute gängigen Standards und Konventionen.

> Die Problematik B.2. ergibt sich aus der langen Vorgeschichte:
> Der Einstieg 1995 in die objektorientierte Programmierung war ein
> Kraftakt, aber es ging dann nicht auf gleichem Niveau weiter: die C++-
> Klassen hätten konsequent weiterentwickelt werden müssen und ihre
> Anwendung in a99 und acon ebenfalls konsequent klassentechnisch
> durchgeführt.
> Dazu fehlte definitiv die Zeit. Sowohl a99 wie avanti+acon entstanden
> zunächst als hastig zusammengebastelte prozedurale Programme unter
> Nutzung der Klassen, auch um deren Funktion gründlicher auszutesten.
> Aber dann verselbständigten sie sich, weil ihre Leistungen dringend
> gebraucht wurden, und ein fast grotesker Wildwuchs nahm seinen Lauf...
> Gleichwohl ist es bis heute ja gelungen, die Programme mehrfach um
> substantielle Leistungen (zuletzt HFM) zu erweitern, und zwar auch
> die strukturell noch älteren und viel schlimmeren Hilfsprogramme (srch,
> index, import, qrix).

> Fazit: Zwar bleiben die Programme, so wie sie jetzt sind bzw. Ende 2015
> sein werden, noch mindestens 10 Jahre lauffähig, auch wenn gar keine
> Änderungen mehr gemacht werden. Wenn aber aus irgendwelchen Gründen
> welche gemacht werden müssen, *könnte* es wegen B.2. schwierig werden.
> Daher werden wir in diesem Jahr einige Bemühungen auf Punkt B.2.
> konzentrieren. Das ist bereits angelaufen und erste Ergebnisse werden
> in Kürze vorgestellt. Desgleichen eine weiter verbesserte Dokumentation
> zur VuFind.Implementierung incl. Einbindung externer Ressourcen.

> Ausführliche Hinweise zu den Microsoft-Plänen:
> http://www.focus.de/digital/computer/windows/noch-zwei-wochen-support-ende-fuer-windows-7-das-muessen-sie-jetzt-tun_id_4382819.html

> B.Eversberg

> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro