Linux im Bundestag

General
1

Hallo,

wie sehr dieses Thema zur Zeit diskutiert wird, zeigt zum Beispiel die rege Beteiligung zu diesem Thema. Ich hatte am 13. Februar ein Posting mit dem Titel "Linux im Bundestag" unter
de.comp.os.unix.linux.misc gesetzt.

Den dazugehörigen Text möchte ich euch natürlich nicht vorenthalten:

2

Hallo Hansjörg,

Bin grundsätzlich Deiner Meinug, muß aber leider feststellen, daß es unter Linux bis jetzt leider noch kein Tool gibt, welches MSAccess ersetzten könnte. Dies ist bedauerlich, speziell für, wie Du sie nennst "...kleinen Handwerker...".

Vielleicht entwickelt sich ja "rekall" in diese Richtung. (http://www.thekompany.com/projects/rekall/)

Grundsätzlich täte aber schon eine Diskussion über die Beschaffungspolitik der Öffentlich-rechtlichen Körperschaften sicher gut. Allerdings würde ich dann andere Gesichtspunkte vor die ökonomischen stellen...

by

sepp

3

Bin grundsätzlich Deiner Meinug, muß aber leider

feststellen, daß es unter Linux bis jetzt leider noch
kein Tool gibt, welches MSAccess ersetzten könnte. Dies
ist bedauerlich, speziell für, wie Du sie nennst
"...kleinen Handwerker...".

Vielleicht entwickelt sich ja "rekall" in diese Richtung.
(http://www.thekompany.com/projects/rekall/)

Grundsätzlich täte aber schon eine Diskussion über die
Beschaffungspolitik der Öffentlich-rechtlichen
Körperschaften sicher gut. Allerdings würde ich dann
andere Gesichtspunkte vor die ökonomischen stellen...

Ich denke da vor allem an die Themen Sicherheit,
Ressourcenbedarf und Benutzerverwaltung. Anbetracht der
Tatsache, dass die meisten User an Windows und Ms office
gewöhnt sind, ist die Zukunft von Linux als OS für den
Anwender (Client) noch offen.

Martin Senoner
http://www.emsis.it/

4

Möchte zum Thema Recall und DB-RAID-Tools ein paar Gedanken verlieren.
Dies soll eine kritische Mail sein, es würden mich nämlich sehr Eure
Meinungen zu den aufgeworfenen Themen interessieren!

DB-RAID-Tools:
Ich bin prinzipiell gegen der Anwendungsentwicklung mit DB-Tools dieser
Art, da diese Tools zu einer Entwicklungsmethodik verleiten, ja sie fast
aufzwingen, welche nur bei Projekten der Größenordung eines sehr
vereinfachten Adressbuches brauchbar ist. Also für jedes seriösere
Projekt, welches eine Lebensdauer von mehr als 1-2 Jahren haben sollte,
sind diese Tools zu vergessen. Ausnahme könnte höchstens eine
Individuallösung sein, welche von einem Programmierer als
Vollzeitbeschäftigung für maximal 10 Kunden betreut und weiterentwickelt
wird. Vom kommerziellen Aspekt zum Scheitern verurteilt.
Will nun jemand für sich privat eine kleine Schallplattenverwaltung
schreiben, also nichts _MISSION_CRITICAL, und hat diese Person keinen
Internetanschluss, bzw. noch nie was von freshmeat gehört, so könnte so
ein Tool interessant werden.

DB-Unabhängigkeit:
Recall rettet sich nur durch seine Datenbankunabhängigkeit, wobei diese
noch in der Praxis zu überprüfen ist. Jeder der mal auf verschiedene
Datenbanksysteme eine SQL-Abfrage abgeschickt hat, hat sich schon
gewundert, dass SQL als ein Standard bezeichnet werden darf. Daher
schätze ich, wird es nicht einfach sein, eine auf ein bestimmtes DBMS
entwickelte Anwendung auf ein anderes DBMS einzusetzen. Ich meine das
beliebige Austauschen des DBMS.

Datenbankschweitzermesser:
Was interessant sein kann, ist ganz einfach und schnell ein paar Reports
auf einer bestehenden Datenbankstruktur zu erstellen. Also Recall als
eine Art Datenbankschweitzermesser um schnell Auswertungen
hinzuzubasteln. Dies ist wiederum nur bei nicht zu umfangreiche
Datenbankmodelle möglich. Bei kompliziertere Modelle wäre ein
Dummy-User, bzw. Hobbyprogrammierer bald überfordert und würde nur
fehlerhafte Ergebnisse erziehlen. Bei Auswertungen kann dies für ein
Unternehmen auch den Tod bedeuten. Und der Programmierer, welcher sich
mit den gesamten Datenmodell beschäftigt hat, ja der wird ein anderes
System bevorzugen. Diese DB-RAD-Tools haben nämlich als Zielgruppe eben
Hobbyprogrammierer.

Scheinfeatures:
Die anderen Scheinfeatures, wie ein Form-Editor, sind eben nur
Schein. Diese Tools sind keine Hilfe, ich würde sie eher als ein
gigantisches Adventurespiel voller Fallen bezeichnen. Der
Form-Editor verschmilzt das Datenmodell mit der graphischen Oberfläche.
Horror für zukunftsorientierte Entwickler: Was ist wenn wir mal die
Daten per Web-Interface zur Verfügung stellen müssen? Außerdem die
Zerstückelung und Zerstreuung der Businesslogik auf die Elemente der
Formulare macht eine Wartung zum Alptraum.
Ein erfahrener Accessprogrammierer wird jetzt kontern, es ist nur eine
Frage der Organisation, man kann Module benutzen, u.s.w. Was er noch
nicht erkannt hat, er hat sich den klassischen Entwicklungsstil
angeeignet, welcher als zu kompliziert bezeichnet wird und den diese
Tools vereinfachen sollten. Ich muss weiteres sagen, dass ich
Programmierer, welche es geschafft haben durch Erfahrung vom
DB-RAID-Tool-Entwicklungsmodell auf das klassische Modell zu
kommen, sehr schätzte. Es ist nämlich sehr schwierig und daher bin ich
strickt gegen die Schulung dieser Tools auf Schulen, denn man verblödet
potenziell fähige Programmierer!
Der Abfragen-Editor, hmmm, wer benutzt da wirklich noch nicht die
SQL-Ansicht?

Fazit:
Die heutige komplexität auch einfacher Anwendungen und die höhe der
ihnen gestellten Anforderungen (Tendenz steigend), eingeschlossen
"kleine" Lösungen für die kleinen "ein Mann" Handwerksbetriebe, macht
den Bedarf dieser DB-RAID-Tools meines Erachtens für eine Neuentwicklung
überflüssig. Das einzige Interessante wäre die Möglichkeit auf alte oder
fremde Datenbankbestände zuzugreifen. Man bräuchte unter GNU/Linux ein
Tool um auf die Daten einer mdb zugreifen zu können. Ich kenne zur Zeit
kein Tool, welches dazu im Stande ist. Das einzige ist MS-Access unter
Wine, VMWare oder ähnliches auszuführen, wobei man dann aber noch nicht
von nativen Linuxanwendungen aus auf die enthaltenen Daten zugreifen kann.

Eine Krückenlösung könnte es sein, MS-Access in VM-Ware auszuführen und
mittels ODBC über die virtuelle Netzwerkverbindung zuzugreifen. Diese
Lösung wird zwar funktionieren, aber man bracuht dafür 3 kommerzielle
Lizenzen:
1) VM-Ware ist nicht frei (hier könnte es vielleicht Alternativen geben)
2) Windows ist wie wir alle wissen auch nicht frei
3) MsAccess ist Teil des nicht freien MsOffice-Pakets, man braucht sogar
die teuerste Variante.

Was Linux fehlt ist eine Datenbankschicht, welche mdb-Dateien
interpretieren kann. OpenOffice und seine Komparen haben die anderen
Formate im Griff aber keiner hat sich noch für die mdb-Dateien interessiert.

Falls jemand von ein solches Projekt hört, einfach eine Mail schicken!

mfg.
Patrick

joastner(a)dnet.it wrote:

5

Hallo Patrick,

super Statement, das ist ja schon fast eine Dissertation geworden :=); aber ich weiss, dass das Thema für dich als Profiprogrammierer interessant ist und ich oft den "advocatus diaboli" abgebe...

Du weisst, dass ich bei Gott kein MS-Fanatiker bin, aber ich will mal auf MSAccess eingehen, weil ich es einigermassen zu kennen glaube:

Was bietet MSAccess: Einen graphischen Tabelleneditor (inklusive graphischer Verknüpfungsmöglichkeit), Einen graphischen Query-editor mit Umschaltmöglichkeit auf SQL-Fenster, einen Formeditor (á la "drag&drop)mit Master-detail, Unterformulare(Masken) einen Reporteditor mit Master-Detail Unterberichte(Reports), beliebig viele Bänder für Gruppierungen, einen graphischen Menüeditor, einen graphischen Makroeditor, einen Codeeditor für Visual-(oder Access-Basic?? weis nicht mehr...)Basic, einen Debugger (wenn man das "Direktfenster" so bezeichen kann), eine Organisationssicht auf die Datenbank (Tabellen, Forms, Reports, Makros, Module).

So ich glaube das ist schon mal was, und für mich als Dummy-User durchaus zu gebrauchen.

Ich glaube wir sollten in unserer Diskussion auch scharf trennen: Professionelle Anwendungsentwickler auf der einen Seite und ad-hoc Problemlöser im Büroalltag auf der anderen Seite. Das sind zwei komplett verschiedene Sachen, wo der eine mit dem Herangehen an die Problemlösung des anderen NICHT einverstanden sein KANN!

Warum?:

Ein Programmierer wird in seiner Problemanalyse die Größe der zu erwartenden Datenmenge, die Anzahl der Benutzer, die notwendigen Schnittstellen zu Fremdsystemen, die Flexibilität des Systems für zukünftige Aufgaben, die Wartbarkeit des Paketes u.v.m. berücksichtigen, um ein professionelles Produkt abzuliefern. Dies hat natürlich den entsprechenden Ressourcenanspruch zur Folge.

Der ad-hoc-Problemlöser hat diese Ressourcen schlicht und einfach nicht! Da wird verlangt, daß bis zum Montag der Quartalsbericht, oder das Rundschreiben an alle 526 Kunden außer an jene, welche im letzten Quartal weniger als für x EURO eingekauft haben, fertig ist, und natürlich mit ein par Charts angereichert präsentiert wird. Da muß in Ermangelung einer konsistenten Datenbasis des Betriebes halt "gezaubert" werden, und derjenige ist gut daran beraten, wenn er sich die benötigten Daten so unter's Jahr laufend mitführt, daß es sie dann am Stichtag parat hat (sischt wearsch narrisch..). Und das geht halt gut mit MSAccess, weil man sich die Daten dann direkt nach MSExcel exportieren und die Charts machen und einige Sachen wie Adressen usw. aus MSAccess mit der Serienbrieffunktion in MSWord bearbeiten kann usw.
Das ist halt der Büroalltag, speziell in Kleinbetrieben (aber nicht nur), wo ein Windowsrechner mit Officepaket (meist eh nicht mit MSAccess) steht und wo gesagt wird "arrangiati", und dann heisst's eben "zaubern" (siehe oben).
Dass dies eher einem "Gewurschtle" als einer professionellen Datenhaltung gleicht, ist eh klar, aber nach meiner persönlichen Erfahrung viel öfter anzutreffen als man glaubt.

Aber zurück zu unserer Frage ob es DB-RAD-TOOLS braucht.

Ich glaube Patrick, daß du recht hast wenn du sagst, daß solche Tools zu Ausbildungsbeginn für einen Profiprogrammierer kontraproduktiv sind. Vielleicht können sie später hilfreicher sein, wenn der Programmierer weiss was er tut (und auch weiss was das Tool tut :=)...), etwa für die schnelle Generierung von Prototypen o.ä.

Aber wir sollten den Blick etwas weiter fassen:

Schauen wir uns die Softwareindustrie im Vergleich zur Autoindustrie an (Autoindustrie als Schlüsselprodukt der Vergangenheit und Softwareindustrie als Schlüsselprodukt der Zukunft).
Das Produkt Automobil hat in seiner Entwicklung von der einfachen Benzinkutsche zum seriengefertigten Hi-Tech Produkt auch eine parallele Entwicklung der Fertigungstechnik bedingt. Waren die ersten Automobile noch Einzelanfertigungen aus einer Hand, so sind sie im Laufe der Zeit, über die Serienfertigung (Amerika Ford-T Modell) und laufende Spezialisierung durch Arbeitsteilung zu assemblierten (?) Fertigprodukten geworden, welche viele Väter (und Mütter) haben. Die heutigen Autohäuser (Hersteller Ford, BMW, Fiat) sind "nur" mehr Systemintegratoren, welche sogar die Lagerhaltung (Just-in-time) ausgelagert haben. Deshalb ist auch die Qualitätssicherung der Zulieferer ("Zertifizierung") von enormer Bedeutung, damit der Autohersteller gegenüber dem Endverbraucher haften kann.

In der Softwareindustrie sind wir noch nicht soweit, oder habt Ihr schon einmal von einer Softwarefirma gehört, welche für das Funktionieren Ihres Produktes garantiert, oder gar eine Haftung übernimmt?
Aber es ist auch hier (wie einst in der Autoindustrie) eine laufende Entwicklung zur Spezielisierung durch Arbeitsteilung zu beobachten. Wie sollte es auch anders sein, da sich die Softwareindustrie wie jeder andere Fertigungsprozess auch in dem ein und demselben wirtschaftlichen Kontext abspielt.

Ich persönlich habe die Vorstellung von einem Softwaresystem in welchem ich als Firma (Benutzer), also als Anwender, mir mein System aus (in weltweiter Arbeitsteilung) vorgefertigten Modulen aus dem Netz zusammenstellen kann, wobei mir durch den Systemintegrator (=Automobilindustrie=Hersteller) das Funktionieren des Gesamtsystems garantiert wird.
Der Programmierer ist dann der Zulieferer (wie in der Autoindustrie), welcher dem Systemintegrator (= in der Autoindustrie der Hersteller) durch Qualitätssicherung in der Softwareentwicklung das Funktionieren der Komponenten garantiert, sodaß der Systemintegrator wiederum mir als Endverbarucher gegenüber in Haftung treten kann.

Wenn man die Arbeit des Programmierers in diesem (zukünftigen) Kontext betrachtet, dann haben RAD-TOOLS dort wirklich nichts verloren, aber bis dahin...

by

sepp