wosx schrieb:
Nein. Er beschreibt nur, dass das "Vendor Lock-In" Risiko bei diesen höher ist,  weil die Wahrscheinlichkeit einer Geschäftsaufgabe dort höher ist. Es liegt in der Natur der Sache und ist ihnen nicht vorzuwerfen, und das war auch glaubich nicht seine Absicht.

Jetzt, wo ich Deine Erläuterung dazu lese, denke ich, dass ich mich wohl "verlesen" bzw. zu viel zwischen den Zeilen hereininterpretiert haben muss. Aber war ohnehin nicht persönlich gegen @edhs gerichtet. Sofern es so rüber kam, sorry.

Ich muss sagen, dass ich seinen Beitrag jetzt - also knapp eine Woche später - wesentlich harmloser empfinde ^^ ;)

sukram schrieb:
etzt, wo ich Deine Erläuterung dazu lese, denke ich, dass ich mich wohl "verlesen" bzw. zu viel zwischen den Zeilen hereininterpretiert haben muss. Aber war ohnehin nicht persönlich gegen @edhs gerichtet. Sofern es so rüber kam, sorry

Guten Morgen Markus,

ich wollte noch auf Deine Einlassung antworten (aber bei dem Wetter war Fliegen priorisiert), das hat sich dann ja erledigt.

Eure Interpretation war schon richtig. Viele APP's entstehen und "vergammeln" dann.  Manche sind so schlecht programmiert, dass sie das nächste Betriebssystem-Update nicht überstehen. Nur wenige werden kontinuierlich gepflegt und angepasst, ganz sicher auch eine Frage des finanziellen Erfolges bzw Misserfolges. Wenn sich die APP nicht rechnet kann man das keinem Entwickler verdenken, wenn er die Pflege einstellt.

Für uns User stellt sich aber immer die Frage nach der Qualität und der Langlebigkeit der APP's denen wir unsere Daten anvertrauen. Besonders natürlich dann, wenn Langzeitspeicherungen zu den Anforderungen gehören (was bei einem Flugbuch ja wohl ganz sicher der Fall ist). Und da liegt, nicht nur bei den APP's, sondern auch in der gesamten EDV ein riesiges Problem. Viele Datensicherungen können drei- oder vier Versionen später garnicht mehr eingelesen werden !!. Oder die Datenträger werden unbrauchbar, oder , oder. Also ein wirkliches Problem. Da hilft nur Papier, bzw Ausdrucke als Sicherung und die Konvertierung in gebräuchliche Dateiformate.

In meinem Fall ist das Flugbuch wohl ziemlich gut programmiert und lange ohne Updates ausgekommen (schon eine Seltenheit denke ich). Auch eine Exportfunktion in einem gängigem Format ist implementiert (csv). Nur funktioniert diese Exportfunktion  bei mir nicht richtig, womit der Wert der APP für mich unter Android 11 hinfällig ist. Ich hatte dem Entwickler, Herrn Hölter (der VRNav programmiert) geschrieben und er hat geantwortet. Mal sehen ob sich das Problem lösen lässt.

Ansonsten lieber Markus gingen Deine vorwurfsvollen Worte an mir vorbei. Die APP's die ich nutze, die bezahle ich auch. Klar, you get what you pay for. Diese APP aber war kostenlos ins Netz gestellt. Deswegen stellte ich meine Fragen ohne jeden Vorwurf. Wäre auch noch schöner, kostenlose Leistungen abfordern und dann noch meckern ....

Nun sind wir wieder gut zueinander .... aber das Problem bleibt generell bestehen, oder?

Gerd

edhs schrieb:
aber das Problem bleibt generell bestehen, oder?

Ich denke, dass das Problem generell bestehen bleibt. Bei uns ist es z.B. so, dass wir tägliche Datensicherungen machen. Da wir diese natürlich stets mit aktuellen Lösungen durchführen, sind die Daten auch mit aktuellen Systemen lesbar und kompatibel. Auf eine Abwärtskompatibilität legen wir da gar keinen Wert, weil auch die Server immer auf einem aktuellen technischen Stand, nie aber auf einem Stand von vor mehreren Monaten/Jahren sind.

Deswegen stellt sich auch die Frage, inwiefern die jeweiligen User eigentlich selbst für die Sicherheit der eigenen Daten verantwortlich sind. Würde ich zum Beispiel ausschließlich digitale Flugbücher führen, würde ich mich ehrlich gesagt auch um meine Daten kümmern und diese zusätzlich zum Service sichern. Ich würde sie vermutlich mindestens monatlich Exportieren und "weglegen" bzw. verwahren. 

Denn rein theoretisch sichern wir die Daten nicht als Service, wo jeder prinzipiell ankommen und sagen könnte: "Hi, habe mich vor zwei Jahren bei einer Flugzeit vertan. Könnt ihr mir sagen, was ich da ursprünglich stehen hatte?". Das ist meines Erachtens nach eher eine Aufzeichnungspflicht des Users selbst. Unsere Sicherungen sind eher für globale Schäden, wie z.B. Server brennt ab, Komet stürzt auf Rechenzentrum o.ä., gedacht.

Aus diesem Grund denke ich, dass es essenziell ist, dass Exportmöglichkeiten in ein gängiges Format wie z.B. CSV zur Verfügung stehen. Ob diese nun kostenpflichtig oder kostenlos sind, ist ja erstmal zweitrangig. Und aus diesem Grund arbeiten wir gerade zum Beispiel an einer API, sodass jeder User seine Daten auch easy (und automatisiert) per JSON ziehen kann. Würde der Service dann eingestellt werden (ich wüsste selber nicht warum ich das tun sollte), dann hätte man immerhin den aktuellen Auszug in einem Datenformat, das man absolut beliebig formen und in vermutlich jedwede andere Lösung importieren könnte. Aus diesem Grund habe ich z.B. gar keine Angst. Denn auch ich nutze die Lösung als User und fühle mich damit absolut sicher.

Aber man wird sehen, wo es die Technik hin verschlägt. Ich bin zumindest der Meinung, dass es irgendwann, also, wenn die Digitalisierung des Flugbuchs tatsächlich zu 100% akzeptiert wird, wichtig für das Kontrollorgan ist, dass die Daten in einem sinnvollen Format, entsprechend der aktuellen Gesetzgebung jederzeit verfügbar sind und die Integrität insofern gewährleistet ist, als dass es sich um ein weitestgehend anerkanntes Produkt handelt. Und ob man dann z.B. einem eingebauten Navi in einem UL trauen kann, das vielleicht von einer großen Zahl Piloten geflogen wird und dessen Daten nur lokal zur Verfügung stehen, ist sehr fraglich. Wir bereiten unseren Dienst zumindest gerade so vor, dass er fälschungssicher (im Sinne von sicherer) wird, indem wir vorhergegangene Flugdaten auf eine bestimmte Weise hashen, um diese in den nächsten Eintrag mitzunehmen. Also quasi blockchainartig, allerdings bisher nur insofern, als dass immer der jeweils vorletzte Eintrag zumindest aus digitaler Sicht "dokumentenecht" wäre. 

We will see :)