Saab 340 kurz vor Veröffentlichung

[Groucho 3]

Das posting ist obsolet, sorry. Ich kann es gerade nicht löschen.

[Mario Donick 271]

Deswegen sollten ja alle, die sich Linux-Unterstützung wünschen, Ben überzeugen, seine Linux-Experimente erfolgreich zu Ende zu führen! Leider muss man sich dafür in dem Forum anmelden, was wohl viele davon abhalten wird. :-/

[KarstenS 180]

Bei der JetStream 32, Sherpa, etc. Ich habe nicht behauptet, dass es für die Saab gilt.

Bei der Jetstream entspricht das ohne weiteres den Tatsachen, denn sie sitzt nicht auf Gizmo oder anderen externen Programmen sondern auf Javiers eigenen Code und den schreibt (oder schrieb) er auf dem Mac eben mit dem gcc der auch unter Linux dafür verantwortlich wäre.

Das Problem ist: diese absolute Kompatibilität verschwindet gerade (gcc ist auf dem Mac deprecated, aus guten Grund, wenn man sich die Performance von clang ansieht und während Linux sich schon immer in Deutschland großer Beliebtheit erfreite spielte es in den USA eine weitaus kleinere Rolle. Das Problem ist auch das die Beschwerden die Cameron erhielt sich im erwarteten sehr geringen Rahmen bewegten. Und wenn man zwischen den Zeilen las konnte man auch bei Ben Supnik eine deutliche Zurückhaltung gegenüber Linux erkennen. , was verst#mdlich ist, denn eine Ülattform mit aktiven Benutzern im niedrigen einstelligen Prozentbereich darf keine zweistellige Prozentzahl bei den SUpport-Aufwendungen darstellen. Es sei denn diese Plattform hat irgend etwas besonderes zu bieten und wenn ich ehrlich nim, dieses Element sehe ich nicht.

Wenn man mir erlaubt mal wieder meine Entwicklerbrille aufzusetzen:

Windows ist aufgrund seiner Nutzerzahlen sakrosankt und man kann sagen was man will: Windows macht vieles anders als Linux, aber wer unter Windows etwas anderes als Visual Studio nahm hatte keine Ahnung! Dessen Performance ist deutlich über der Konkurrenz. Mac Os X fiel immer stärker zurück (erst recht in der X-Plane Welt aufgrund der kritischen Modellpolitik) doch mit LLVM/clang steigert sich die Performance merklich auch wenn man immer noch weit von Windows entfernt ist, doch dafür hat man mit instruments eine Performance suit bei der Hand die doch eine andere Kategorie als zum Beispiel Valgrind unter Linux ist. Wenn man Linux Vorteile bescheinigen will, liegen diese auf den ersten Blick im Bereich der NSA-Sicherheit, doch diese Argumente spielen bei X-Plane keine echte Rolle und Expeerten waren weder besonders überrascht. Statt dessen haben duie Sicherheutsbehörden jetzt das Problem das keine Firma noch auf die reinen OSRoutinen von amerikanischen Hestellern vertraut. Sowohl Windows wie auch MacOsX werden schleunigst intern auf OpenSource Randomizer und ähnliches setzen.. Da konnen Geheimdiesnte noch so viel maulen iMan wird intern nur noch das nötigste tun und auf ausländische Plug-ins bauen.

[Groucho 3]

Das Problem ist: diese absolute Kompatibilität verschwindet gerade (gcc ist auf dem Mac deprecated, aus guten Grund, wenn man sich die Performance von clang ansieht und während Linux sich schon immer in Deutschland großer Beliebtheit erfreite spielte es in den USA eine weitaus kleinere Rolle. Das Problem ist auch das die Beschwerden die Cameron erhielt sich im erwarteten sehr geringen Rahmen bewegten. Und wenn man zwischen den Zeilen las konnte man auch bei Ben Supnik eine deutliche Zurückhaltung gegenüber Linux erkennen. , was verst#mdlich ist, denn eine Ülattform mit aktiven Benutzern im niedrigen einstelligen Prozentbereich darf keine zweistellige Prozentzahl bei den SUpport-Aufwendungen darstellen. Es sei denn diese Plattform hat irgend etwas besonderes zu bieten und wenn ich ehrlich nim, dieses Element sehe ich nicht.

Auf der anderen Seite bin ich gerade über Ben Russel und Camerons Aussagen hinsichtlich Gizmo gestoßen (http://forums.x-pilot.com/topic/4238-gizmo-64bit/page-3):

Ben Russell:

"Linux is significantly easier in this department as it is, at its heart, a programmers operating system.

The tools are trivial to install.

Minutes and hours, all automated. Windows could be a few days of manual tweaking."

"It also means that providing and maintaining support for Linux and Windows into the future should be trivial."

"I have no words to adequately express how much I hate Windows."

Cameron:

"You've got this correct. That said, our philosophy on this is that Linux is going to be at your own risk. We will "support" Ubuntu LTS officially. While it may and probably will work on other variants, choosing to use those variants and figuring out hiccups along the way will have to be up to you."

Das klingt jedenfalls nicht danach, als wollte man das fallen lassen. Vermutlich sollte man die Jungs noch mal etwas schubsen Es gäbe immerhin noch die Möglichkeit, Porting und Testing an die Community auszulagern. Entsprechende NDAs hinterlegt sollte das auch urheberrechtlich kein Problem sein.

Javier Rollon hatte ich das bereits angeboten, aber die Antwort war noch recht spärlich.

[Mario Donick 271]

Danke für den Hinweis -- stimmt, noch im März gab man sich wesentlich optimistischer, was Linux-Gizmo angeht. Ich frage mich, was zwischenzeitlich passiert ist.

Die offizielle Begründung ist ja, dass sie anhand der "nach Hause telefonierenden" Installer ihrer Produkte sehen können, dass nur sehr sehr wenig Leute jemals die Linux-Versionen runtergeladen und installiert haben, und es sich einfach nicht lohnen würde, da Arbeit reinzustecken.

Vielleicht ist es aber nur Unlust auf Bens Seite. Er hat neulich auch geschrieben, dass er für X-Plane eigentlich gerade gar keine Zeit hat.

Auf jeden Fall wäre es, so lange X-Plane offiziell Linux unterstützt, sehr gut, wenn alle Addon-Anbieter das ebenfalls tun würden, denn man sieht im "A Linux Crusade?"-Thread bei x-plane.org sehr schön, wie da der Unmut bei vielen Leuten wächst.

Gilt übrigens auch für das SkyMAXX-Addon, das zwar sehr vielversprechend aussieht, aber ebenfalls nur für Mac und Windows verfügbar sein wird.

[KarstenS 180]

Auf der anderen Seite bin ich gerade über Ben Russel und Camerons Aussagen hinsichtlich Gizmo gestoßen (http://forums.x-pilot.com/topic/4238-gizmo-64bit/page-3):

Ben Russell:

"It also means that providing and maintaining support for Linux and Windows into the future should be trivial."

"I have no words to adequately express how much I hate Windows."

Ich weiss das er damals gesagt hat, aber ich kann dir auch genau sagen was sein Problem unter Windows war:

Er war so DUMM (anders kann ich es wirklich nicht sagen) unbedingt auf Open Source Produkte setzen zu wollen, die aber von Haus aus an Linux angelehnt waren und das ist ganz einfach Unsinn. Ich habe selbst miterlebt, was für ein Aufwand es ist die Programme zunächst umzustellen, weil ich einer der Hauptverantwortlichen der Windows-Portierung war. Damals gefiel mir vieles nicht! Auch heute kann es noch manchmal ein Problem sein, doch wenn man sich erst mal daran gewöhnt hat stellt man verblüfft fest das die eigenen Produkte unter Windows (eine Portierung!) plötzlich dem Original unter Linux davon rennen und gleichzeitig der Compiler beim Debuggen teilweise ganz andere Schwächen aus den Programmen heraus tüftelt.

Ben Russell musste erst einmal lernen dass es zu Visual Studio unter Windows KEINE Alternative gibt (als Backend kann man vielleicht auch mal auf den Intel Compiler ausweichen aber das war es fast). Es ist eine harte Lernkurve, das muß man zugeben und Windows ist teilweise extrem unübersichtlich.

Was außerdem erst danach geschah war das extrem demonstrative Abrücken von Mac Os X vom gcc, während unter Linux mit dem LLVM ziemlich gefremdelt wird.

Sie versuchten zwar schon vorher unter X-Code einiges an Performancetools anzubieten, doch inzwischen sind diese Tools unabhängig von X-Code und lassen sich damit wesentlich einfacher auch für Multiplattform-Entwicklungen nutzen die eben nicht unter Coco laufen.

Es ist unübersehbar das Mac Os X sich von seinen BSD Wurzeln und damit von der Linux Verwandschaft löst. Das ist das Problem. Bislang konnte man Mac Os X und Linux mit ein paar Unterschieden nahezu identlich laufen lassen, während Windows der Fremdling war.

Zu dem Zeitpunkt wo sich Ben Russell und Cameron dazu äußerten war das in der Form nicht wirklich absehbar. Ich habe mich auch erst vor kurzen in LLVM und instruments hinein gearbeitet. Es ist eine nicht zu unterschätzende Umgewöhnung und Umstellung.

[Mario Donick 271]

@Karsten, weißt du das alles genau, oder überträgst du nur deine Erfahrungen auf X-Plane?

[KarstenS 180]

@Karsten, weißt du das alles genau, oder überträgst du nur deine Erfahrungen auf X-Plane?

Teils teils. Ben Russell hatte selbst mit etwas Verzögerung schließlich gemerkt, das sein Compiler unter Windows nicht in der Lage war 64 Bit Lauffähigen Code zu generieren (weil ein bestimmtes Schema von Linux unter Windows nicht verwendet wurde). Bei uns in der Firma galt schon immer dass das Build-System native Compiler verwenden sollte. Sein Compiler war eben nicht native, sondern eine Portierung.

Was die Unterschiede der Architekturen angeht, dass ist für mich mein tägliches Brot. Unsere Software hat weder etwas mit X-Plane noch mit Spielen zu tun. doch im Endeffekt spielt es keine besonders große Rolle ob du ein X-Plane Plug-in vor dir hast oder etwas anderes. Wenn es in C, C++ oder etwas anderen geschrieben wurde, stehen alle Entwickler vor den gleichen Problemen. Und unser Code läuft eben unter Mac Os X, Linux, Solaris, Windows und noch ein paar Architekturen, daher haben wir immer wieder die gleichen oder ähnliche Probleme, Nur wie du weißt haben wir es unter X-Plane immer noch sehr stark mit Hobby bis Semiprofessionellen Entwicklern zu tun. Die Firma für die ich arbeite ist zwar klein, aber nicht so klein wie Laminar so dass wir mehr Resourcen und Connections haben.

[Groucho 3]

Wenn es in C, C++ oder etwas anderen geschrieben wurde, stehen alle Entwickler vor den gleichen Problemen.

Ich würde mal vermuten, dass die genannten Architekturen eher inhomogen sind und aus verschiedenen Technologien und Bibliotheken bestehen. Vermutlich noch C und C++ gemischt, eventuell auch noch andere mit im Spiel. Und das ganze historisch gewachsen.

In dem Fall würde ich sagen liegt es nicht ausschließlich am Tooling, sondern auch daran, dass versäumt wurde, die architektonischen Grundlagen für Cross-platform zu legen und zu wahren.

Bei entsprechender Homogenität gibt es da auch bei steigender Komplexität deutlich weniger Probleme.

Bspw. habe ich hier eine mittlerweile recht komplexe Anwendung, die fast ausschließlich auf Qt basiert. Da sie auf keiner Plattform spezifische Probleme macht kann ich mich voll auf die Logikfehler konzentrieren. Wohlgemerkt auch mit 64-bit unter Windows und Linux. Visual Studio spielt dabei überhaupt keine Rolle, sondern ausschließlich Standard-Toolchains.

Es geht. Man muss sich eben die Frage stellen, von welcher Seite man das Problem angeht. Und das Cross-platform nicht von selbst kommt, insbesondere bei Legacy, ist auch klar.

Oliver

[KarstenS 180]

Ich würde mal vermuten, dass die genannten Architekturen eher inhomogen sind und aus verschiedenen Technologien und Bibliotheken bestehen. Vermutlich noch C und C++ gemischt, eventuell auch noch andere mit im Spiel. Und das ganze historisch gewachsen.

Das ist weitaus weniger problematisch als du dir vorstellst. Die Dinger sind recht gut beherrschbar. Tatsächlich sind heute die meisten Plattformspezifischen Probleme

entweder Compilerfehler (vor allem Solaris fällt da seit einiger Zeit häufig auf) oder Bugs die dort schlichtweg zufälligerweise (bzw. spezifische Speicher- und Prozessaufteilung) bevorzugt auftraten. Wenn man mal von Standardproblemen wie die sehr kurze Halbwertszeit von Standards bei Apple einmal absieht.

Allerdings verstehe ich persönlich nicht wie deiner Meinung nach Qt bei X-Plane Plug-ins helfen könnte. Für Grafiken sind sie schließlich vollkommen X-Plane unterworfen. Was Multiplattformumgebungen angeht müßte man sogar noch vorher Java anführen wo die meisten Leute nicht einmal ahnen wie verbreitet es ist und was intern auf Java aufbaut auch abseits Multiplattform.

Tatsache ist das schlichtweg zahlreiche Addon Anbieter nicht einsehen eine Linux-Version einzurichten aufgrund der geringen Nutzerzahlen. Wenn da nicht massiv mit Geld gedroht wird, wird es auch kaum besser werden.

[Groucho 3]

Das ist weitaus weniger problematisch als du dir vorstellst. Die Dinger sind recht gut beherrschbar. Tatsächlich sind heute die meisten Plattformspezifischen Probleme

entweder Compilerfehler (vor allem Solaris fällt da seit einiger Zeit häufig auf) oder Bugs die dort schlichtweg zufälligerweise (bzw. spezifische Speicher- und Prozessaufteilung) bevorzugt auftraten. Wenn man mal von Standardproblemen wie die sehr kurze Halbwertszeit von Standards bei Apple einmal absieht.

Allerdings verstehe ich persönlich nicht wie deiner Meinung nach Qt bei X-Plane Plug-ins helfen könnte. Für Grafiken sind sie schließlich vollkommen X-Plane unterworfen. Was Multiplattformumgebungen angeht müßte man sogar noch vorher Java anführen wo die meisten Leute nicht einmal ahnen wie verbreitet es ist und was intern auf Java aufbaut auch abseits Multiplattform.

Tatsache ist das schlichtweg zahlreiche Addon Anbieter nicht einsehen eine Linux-Version einzurichten aufgrund der geringen Nutzerzahlen. Wenn da nicht massiv mit Geld gedroht wird, wird es auch kaum besser werden.

Ich bin ja nun schon eine Weile in der Ecke unterwegs und habe in den letzten 20 Jahren viele Architekturen gesehen und einige davon wieder auf die richtigen Gleise gebracht. Daher habe ich eine ziemlich gute Vorstellung von der Realität.

Das Statement "Wir beherrschen das recht gut" ist tatsächlich eines der häufigsten dabei. Daß das Problem an der Komplexität liegt, fällt zumeist nicht auf, weil man mit der Komplexität mitgewachsen ist und die Probleme schleichend entstehen. Schöne Beispiele sind unterschiedliche Build-Environments (oder Versionen) auf unterschiedlichen Plattformen und Bibliotheksversionen, die dort in unterschiedlichen Versionen vorliegen.

Solaris ist da mit Sicherheit auch ein gutes Beispiel, da es als aussterbende Plattform nicht mehr die Liebe und Pflege des Herstellers und der Entwickler erhält, um mit aktuellen Standards mithalten zu können.

Was Qt angeht habe ich es nicht spezifisch auf X-Plane bezogen, sondern als Beispiel dafür, wie eine homogene Infrastruktur aus einer Hand plattformspezifische Probleme minimiert. Es ist sicher nicht die eierlegende Wollmilchsau, die man sich wünscht, leistet aber gerade auch abseits des UI sehr gute Dienste.

Meines Wissens gibt es (zu meinem Bedauern) auch keine JAVA-Schnittstelle in X-Plane, damit fällt das Thema sowieso flach. Abgesehen davon hat JAVA seine Stärken und Verbreitung mittlerweile eher im Backend- und Mobile-Bereich, daher ist es wohl nicht verdächtig, bei X-Plane im Einsatz zu sein. Wir schweifen aber nun gewaltig ab.

Um zum Thema zurückzukommen: Bei einigen der Anbieter, deren Linux-Version nicht vorhanden ist, steht groß und breit "Not yet" auf der Produktseite bzw. wird vollmundig in Foren erklärt, daß sie Linux supporten. Sie sollten dann aber auch klar Stellung beziehen, daß sie die Strategie geändert haben und diese Statements entsprechend anpassen. Bzw. ggf. die Portierung in die Community geben, wie gesagt kann man das rechtliche über NDAs regeln.

Dieses ständige "Wir arbeiten dran" oder "Wir machen noch eine" ohne Terminierung ist gelinde gesagt nicht besonders kundenfreundlich.

Von Javier Rollon habe ich immerhin die Zusage, daß er in den nächsten Tagen anfängt, die Jetstream 32 zu portieren.

[Mario Donick 271]

Auch Ben Russell hat wie erwähnt eine Linux-Gizmoversion in Arbeit.

Ob diese aber von Cameron (X-Aviation-Betreiber) offiziell unterstützt bzw. genutzt wird, bleibt abzuwarten.

Nachdem Ben übrigens seinen Abstimmungsthread in "Linux sucks" umbenannt hat, haben noch drei Leute mehr abgestimmt. *fg*

[Schorle 6]

Gibt's ne Möglichkeit Autopilot on/off auf eine Taste zu legen (bzw. Joystick-Knopf)? Der Switch zum Ein- Ausschalten liegt sehr ungünstig, wenn man immer mit der Maus bedienen muss.

[Hobelflieger 42]

Gibt's ne Möglichkeit Autopilot on/off auf eine Taste zu legen (bzw. Joystick-Knopf)? Der Switch zum Ein- Ausschalten liegt sehr ungünstig, wenn man immer mit der Maus bedienen muss.

Ja, gibt es: Menü Einstellungen, Joystick, Tastatur und Geräte, FDir down und FDir up.

[Schorle 6]

Ja, gibt es: Menü Einstellungen, Joystick, Tastatur und Geräte, FDir down und FDir up.

Funktioniert leider nicht.......was mache ich falsch?

[Heinz Flichtbeil 1609]

Hallo Schorle,

Den AP kann man auch im Menü Einstellungen - Joystick, Tastatur und Geräte - Buttons: Extra finden.

Hier gibt es im mittleren Feld den Radio Button "autopilot". Und im rechten Feld kann man dann den AP mit dem Button "servos_toggle" z.B. an und abschalten.

Viele weitere Funktionen zum AP sind dort auch verfügbar.

Also erst den Joystick Button drücken, den Du für den AP verwenden willst und dann im Menü die Funktion wählen.

Dann sollte es klappen.

Es kommt natürlich auch auf die Möglichkeiten und die Art des AP an, der im Flugzeug vorhanden ist.

Mit der Saab kann ich es nicht testen, da ich sie noch nicht besitze

Gruß

[Hobelflieger 42]

Au, ich kann leider nicht durchs Kabel gucken ... Deshalb kann ich Dir nur beschreiben, wie man es richtig macht.

Du schaust Dir zwei Knöpfe am Joystick aus.

Einer ist für rauf: off --> fdir (Bereitschaft) --> on

Der Andere für runter: on --> fdir (Bereitschaft) --> off

Soweit klar?

Dann öffnest Du das Menü Einstellungen, wählst Joystick, Tastatur und Geräte, und jetzt wichtig: Du drückst den Knopf den Du belegen möchtest, erst danach im Menü die Option FDir up. Das Gleiche machst Du mit den zweiten Knopf für FDir down.

[Schorle 6]

Das mit dem Zuweisen ist mir schon klar.........nur funktioniert das bei der Saab nicht. Bei anderen Flugzeugen geht es.

[Hobelflieger 42]

Schorle, schon Klasse,

da tippt man sich die Finger wund und der "Fliegerkamerad" Schorle kommt mit den Informationen häppchenweise rüber - schon super!

Also, bei mir klappt es mit der Tastenbelegung am Yoke bei der Saab 340 A. Der Autopilot macht brav rauf und runter.

[Franz008 11]

Ich habe die Saab zwar nach einigen kurzen Tests wieder ins Hangar zurückgebracht und die Türe geschlossen (jedoch nicht GANZ verschlossen)...aber bei den Tests war es so, dass nach Aktivierung vom Autopiloten ab 500ft und Drücken der "CLIMB"-Taste die Maschine einen Stürzflug einlegte...irgendwie griff die Steig-Geschwindigkeit erst nachdem das Flugzeug über 180 kts erreicht hatte (dabei war meine Geschwindikeit ca. 125kts). Deshalb zuerst das Absinken...erscheint mir aber nicht normal.

[Mario Donick 271]

Ich habe die Saab zwar nach einigen kurzen Tests wieder ins Hangar zurückgebracht und die Türe geschlossen (jedoch nicht GANZ verschlossen)...aber bei den Tests war es so, dass nach Aktivierung vom Autopiloten ab 500ft und Drücken der "CLIMB"-Taste die Maschine einen Stürzflug einlegte...irgendwie griff die Steig-Geschwindigkeit erst nachdem das Flugzeug über 180 kts erreicht hatte (dabei war meine Geschwindikeit ca. 125kts). Deshalb zuerst das Absinken...erscheint mir aber nicht normal.

Was hast du denn als Steiggeschwindigkeit eingestellt? 125 Knoten sind ja bei einer Reisegeschwindigkeit der 340A von 250 bis 270 Knoten (je nachdem, wo man guckt) ziemlich langsam.

[Hobelflieger 42]

Ich habe die Saab zwar nach einigen kurzen Tests wieder ins Hangar zurückgebracht und die Türe geschlossen (jedoch nicht GANZ verschlossen).

...

Schade und ärgerlich zugleich. Denn 55 USD wirft man am Abend nicht mal eben in die Musikbox.

Aber, wenn das erste Update kommt, öffnest Du die Hangartür bestimmt wieder und der Flieger kommt dann wieder zu Ehren.

Ich habe heute 8,5 Stunden (zum Glück gibt es den Autopiloten und das KLN90B) auf zwei Flügen mit der Saab zugebracht, ohne besondere Vorkommnisse. Als alter DC-3-Hase wähle ich jedoch immer aus Gewohnheit die VS-Einstellung des Autopiloten, so das ich keine Erfahrungen mit der Climb-Funktion zusteuern kann.

[Franz008 11]

Die Steig-Geschwindigkeit lag bei ca 140 kts. Ich denke das ist kurz nach dem Start eher üblich so, auch wenn nachher die Steig-Geschwindigkeit langsam erhöht werden soll.

Was hast du denn als Steiggeschwindigkeit eingestellt? 125 Knoten sind ja bei einer Reisegeschwindigkeit der 340A von 250 bis 270 Knoten (je nachdem, wo man guckt) ziemlich langsam.

[Franz008 11]

Schade und ärgerlich zugleich. Denn 55 USD wirft man am Abend nicht mal eben in die Musikbox.

Aber, wenn das erste Update kommt, öffnest Du die Hangartür bestimmt wieder und der Flieger kommt dann wieder zu Ehren.

Ich habe heute 8,5 Stunden (zum Glück gibt es den Autopiloten und das KLN90B) auf zwei Flügen mit der Saab zugebracht, ohne besondere Vorkommnisse. Als alter DC-3-Hase wähle ich jedoch immer aus Gewohnheit die VS-Einstellung des Autopiloten, so das ich keine Erfahrungen mit der Climb-Funktion zusteuern kann.

Es war halt Neugier, da eh nichts "gescheites" rauskam in letzter Zeit. Ja mal schauen, vielleicht fliege ich sie wieder ;-) Aber ich muss gestehen, dass es andere Flieger gibt wie die J32 die ich sogar kein einziges mal geflogen bin (!). Da ich sie ganz einfach extrem hässlich finde und ich deshalb demotivert war, als es darum ging den ersten Flug zu absolvieren. Auf den Bildern sah sie besser aus. Aber das ist persönlicher Geschmack. Und wie gesagt, ich bin mehr der Heavy-Flieger und freue mich deshalb auf die B733 sowie B757.

[simHeaven 1664]

Ich kann das nachvollziehen, mein Traumflieger ist die Saab 340 auch nicht und bei dem Preis müsste sie mich sehr begeistern, damit ich sie kaufe. Doch so ein richtiges Einsatzgebiet hätte ich eh nicht - außer vielleicht Zubringerflüge oder Inselhüpfen. Doch für letzteres sind die Starteigenschaften etwas schlecht, Helgoland wird da schon knapp...

Vielleicht versteht mich jetzt der eine oder andere besser, als ich damals schrieb, ich warte erstmal ab. Ich denke mein nächster Flieger ist die 757, wenn die dann keine großen Mängel haben sollte. Oder wenn es mal die C208C geben sollte und die noch anständig auf dem Wasser rumhüpft.