Delphi 10.2 LINUX Entwicklung

[Codehunter]

Mir war CrossVCL bis dato nicht bekannt und habe erst heute davon erfahren. Habe mir die Videos angeschaut. Der erste Gedanke: Heureka! Der zweite Gedanke: Star Citizen for Business. Dritter Gedanke: Mist - Linux Compiler gibts erst ab Architekt.

Dann fing ich an darüber zu philosophieren, was hat Eugene Kryukov bewogen, ein solches Projekt anzugehen? Dass er etwas auf dem Kasten hat, das hat er ja schon bewiesen. Aber die VCL X-Plattform zu machen, das wirkt erstmal so aberwitzig. Vorallem angesichts der Entwicklungszeit, die zuvor schon in CLX und FMX geflossen ist. Gerade das Kylix-Desaster hätte eigentlich Warnung genug sein sollen.

Allerdings ist inzwischen die VCL auch nicht mehr die selbe wie sie vor gut 20 Jahren zu Kylix-Zeiten war. Die wilden API-Calls innerhalb der visuellen Komponenten sind weitgehend verschwunden. Alles wurde zentralisiert, auch oder gerade wegen der Theme Engine. Deshalb denke ich an der Stelle schon, dass es möglich ist mit der heutigen VCL sowas zu bauen. Die Entwicklungsumgebung (Delphi) an sich muss doch gar nicht auf Linux oder MacOS laufen. Das war auch so ein Fehler der damals bei Kylix gemacht wurde.

Um mal ein Beispiel aus der Praxis zu bemühen: In München wird gerade mit viel Aufwand das LiMux-Projekt beerdigt, das zuvor jahrelang mit viel Aufwand gepäppelt wurde. Gescheitert ist es dem Vernehmen nach vorallem an Fachanwendungen, die von kleinen Softwareschmieden geliefert wurden und die keine Möglichkeit hatten, diese mit vertretbarem Aufwand nach Linux zu portieren. Mit Wine läuft eben vieles, aber nicht alles.

In der Regel waren das Datenbank-Frontends mit komplexen Reportgeneratoren. Mal angenommen (ich weiß es nicht!), diese Anwendungen wären mit Delphi erstellt und Softwareschmiede XYZ hätte nur in ein Delphi Architekt und eine CrossVCL-Lizenz investieren müssen. Sagen wir mal 5000 Euro Investition, um ein Millionenprojekt zu retten. Wäre das nicht wirtschaftlich sinnvoll gewesen?

Ich finde das gerade deshalb so interessant, weil ich in letzter Zeit einige Experimente mit Linux beim Endkunden mache. Dabei geht es weniger um fallspezische Lösungen. Vielmehr hat mich interessiert, wie ganz normale Büroanwender reagieren, wenn sie statt einem Windows ein Linux (Mint 18.2) vorgesetzt bekommen. Dabei war ich ganz erstaunt, wie "änderungstolerant" die Leute geworden sind. Vor 10, 15 Jahren war das undenkbar. Bis Windows XP waren die Denkmuster festgefahren. Aber seitdem verändert sich Windows rasant, insbesondere Win10. Die Leute haben sich daran gewöhnt, dass sich Startmenü & Co. von einem Tag zum anderen verändern können, wenn über Nacht mal wieder ein großes Update eingespült wurde. Auf einmal bleibt der Kulturschock aus, wenn sie plötzlich vor einem Linux sitzen.

Viele Business-Delphi-Anwendungen sind dröge Datenbank-Frontends. Seit Jahr(zehnt)en gewachsen, am Markt etabliert und stabil. Warum bei sowas noch mal mit viel Aufwand bei 0 (oder 10) anfangen, zig hundert Stunden investieren und X-Plattform (FMX) bauen, wenn man mit überschaubaren Beträgen so etwas wie CrossVCL verwenden könnte? Die Kunden mit ganz viel Geld können die Anwendung dann nativ auf ihrem Mac laufen lassen, die Kunden mit ganz wenig Geld setzen Linux ein und alle dazwischen verwenden Windows.

Mal ehrlich, gibt es nicht viele Delphianer, die seit vielen Jahren VCL-Anwendungen schreiben und schlicht keine Lust haben, von Grund auf mit FMX noch mal neu zu lernen? Seit Jahren dreht sich diese Diskussion doch schon im Kreis. FMX ist ein tolles Framework und es funktioniert inzwischen auch recht gut. Allerdings ist eben allein schon das Benennungsschema der Properties im Objektinspektor so fundamental anders, dass man anfangs ungemein viel Zeit in der Onlinehilfe verbringt. Mein "Lieblingszitat" ist da inzwischen: "Embarcadero Technologies verfügt zurzeit über keine zusätzlichen Informationen. Bitte unterstützen Sie uns bei der Dokumentation dieses Themas, indem Sie Ihre Kommentare auf der Diskussionsseite eingeben.".

Aber auch abseits persönlicher Befindlichkeiten gibt es handfeste Argumente gegen eine Portierung bestehender Anwendungen nach FMX. Das treffendste ist immer die Geldfrage. Wenn man viele Mannstunden aufwendet, um ein Programm auf den Mac zu bekommen, nur um dann festzustellen dass es an einer bescheidenen Komponente scheitert, die mal zugekauft war und nicht mehr supportet wird. Da würde mir mein Chef mit dem nackten Arsch ins Gesicht springen. Wenn nicht Android und iOS das Ziel sind sondern ausdrücklich Desktop-Anwendungen, dann spricht nicht viel für eine FMX-Migration.

Dass die jahrelang gerade aus Richtung Redmond propagierte Konvergenz aus Mobil und Desktop gescheitert ist, das haben die Leute bei Microsoft inzwischen selbst einsehen müssen: "Of course we'll continue to support the platform.. bug fixes, security updates, etc. But building new features/hw aren't the focus." (Joe Belfiore über Windows 10 Mobile). Unter diesem Paradigma könnte man auch FMX sehen: Als Framework für mobile Anwendungen definitiv ja, als Grenzgänger zwischen Mobil und Desktop dagegen nicht. Das wollen die Nutzer schlichtweg nicht weil Maus- und Touchbedienung eben zwei völlig verschiedene Konzepte sind. Der Versuch, diese zu vereinen, wird IMHO scheitern - siehe eben Windows 10 Mobile, aber auch RemixOS (Android), Unity (Ubuntu Linux), Chrome OS oder die jüngsten iTunes-Updates. Die Zeichen stehen im Moment eher auf Trennung zwischen Mobil und Desktop statt auf Vereinigung.

In einem eng abgesteckten Rahmen finde ich das Projekt CrossVCL sehr faszinierend. Fokus ausschließlich auf den Desktop, auf Businessanwendungen, DB-Frontends usw. Dass es inzwischen einen VST-Port gibt, finde ich ja schon mal ganz toll. Nur müsste der mit dem Main-Branch gemerged werden. Sonst ist all die Müh' vergebens wenn das nächste VST-Update von JAM Software kommt. Dass z.B. UniDAC von Devart wunderbar X-Plattform funktioniert weiß ich schon aus eigener Erfahrung. Deshalb sind X-Plattform-DB-Aware-Komponenten ja so wichtig.

[jaenicke]

Zitat von Codehunter:

Dritter Gedanke: Mist - Linux Compiler gibts erst ab Architekt.

Ab Enterprise gibt es den bereits.

[Codehunter]

Zitat von jaenicke:

Zitat von Codehunter:

Dritter Gedanke: Mist - Linux Compiler gibts erst ab Architekt.

Ab Enterprise gibt es den bereits.

Danke für die Berichtigung. Dennoch sehe ich gut 2500 Euro Aufpreis, die nicht zu rechtfertigen sind wenn der Linux-Compiler das einzige Feature ist, das ich mehr benötigen würde im Vergleich zur Professional. Diese Preise tun ja inzwischen sogar Mittelständlern schon weh, wenn sie hauptsächlich für den Hausgebrauch entwickeln.

[jaenicke]

Zitat von Codehunter:

Dennoch sehe ich gut 2500 Euro Aufpreis, die nicht zu rechtfertigen sind wenn der Linux-Compiler das einzige Feature ist, das ich mehr benötigen würde im Vergleich zur Professional.

Ja, der Umstieg ist leider sehr teuer, was ich auch sehr kritisch sehe. Denn wenn man schon einige Jahre mit Wartungsvertrag unterwegs ist und dementsprechend niedrige Preise hat, verliert man in mehrerer Hinsicht...

Dann muss man nun erstens den Wechsel durch ein Update bezahlen und steigt dann auch noch deutlich teurer in den Wartungsvertrag für die höhere Edition ein.

An der Stelle bin ich froh, dass wir damals nicht den Fehler gemacht haben und die Professional genommen haben. In der Sackgasse stecken leider einige, die ich kenne.

[sh17]

Sollte sich CrossVCL als stabil in Anwendung und Support erweisen (nützt nix, wenn es nächstes Jahr wieder weg ist), würde ich auch den Schritt zu Enterprise wagen.

[Harry Stahl]

Das FMXLinux ist schon echt gut brauchbar. Probleme werden recht zügig innerhalb weniger Stunden oder weniger Tage behoben.

CrossVCL habe ich mir auch schon geholt. VCL-Anwendungen auf FMX umzustellen ist langwierig und fehleranfällig. Insofern könnte CrossVCL eine echte Alternative sein, um VCL-Anwendungen zum MAC oder zu Linux zu bringen, denn die grundsätzliche Programmlogik bleibt erhalten.

Bin gerade dabei, eine Server-Anwendung mit CrossVCL auf MAC und Linux umzustellen. Noch funktionieren eine Reihe von Dingen nicht (ist ja auch noch nicht die endgültige Version), aber dennoch ist man erstaunt, was schon alles geht.

[Codehunter]

Zitat von jaenicke:

Ja, der Umstieg ist leider sehr teuer, was ich auch sehr kritisch sehe. Denn wenn man schon einige Jahre mit Wartungsvertrag unterwegs ist und dementsprechend niedrige Preise hat, verliert man in mehrerer Hinsicht...

Dann muss man nun erstens den Wechsel durch ein Update bezahlen und steigt dann auch noch deutlich teurer in den Wartungsvertrag für die höhere Edition ein.

An der Stelle bin ich froh, dass wir damals nicht den Fehler gemacht haben und die Professional genommen haben. In der Sackgasse stecken leider einige, die ich kenne.

Interessant. Dieser Umstand war mir noch gar nicht so bewusst, da ich NIE mit Wartungsvertrag unterwegs bin sondern in ungleich größeren Abständen migriere wenn es wieder einmal ein Killerfeature gibt. FMX war z.B. mal so eins, weil ich unbedingt eine Android-Anwendung brauchte. x64 war auch so eins, weil die Anwender nach x64 schrien (obwohl das effektiv kaum einen Unterschied zu x86 macht). Inzwischen liefere ich nur noch x64 aus und bin so auch gleich ein paar lahme Uraltkisten beim Anwender los geworden.

Einfach gesagt ich kaufe statt zu leasen. Dass Emba hier aber sogar die treuen Stammkunden so ungeniert abschöpft erschreckt mich ein wenig und lässt mich eher von dem Gedanken noch weiter abrücken, jemals eine Subscription abzuschließen.

( @MEissing liest du mit? )

Den Linux-Compiler in der Oberklasse einzusortieren halte ich für einen strategischen Fehler seitens Embadera. MacOS x86 bekommt man schon ab der Pro, Linux nur ab Enterprise. Das finde ich widersprüchlich. Linux auf dem Desktop sollte man mit allen Mitteln fördern, statt mit hohen Preisen zu torpedieren. Ich glaube, Emba scheint noch gar nicht so ganz klar zu sein, was Delphi+CrossVCL bedeuten würde: Es wäre eine Alternative zu Qt, GTK und Java. Ich meine damit nicht technisch sondern eher produktstrategisch. Auf einmal ließen sich eine ganze Reihe bestehender Anwendungen mit überschaubarem Aufwand nach Linux migrieren.

Mein früheres LiMux-Beispiel kommt ja nicht von ungefähr. Viele Augen haben da auf München geschaut. In vielen Verwaltungen rumort es. Man sagt mehr oder weniger offen, dass man weg will von Microsoft und den USA. Ich kann zwar nicht für München sprechen, wohl aber für hiesige Verwaltungen. Und da sehe ich eine ganze Reihe von Fachanwendungen, die mit Delphi geschrieben sind. Eine der hakeligsten darunter ist das Kataster. Der Hersteller hat irgendwie die Entwicklung verschlafen, ist bei Windows XP hängen geblieben und werkelt seit 10 Jahren an einer Nachfolgeversion die auch unter Win7+ läuft. In der Not haben die Verwaltungen ein XP virtualisiert laufen weils nicht anders geht. Ein alternativer Anbieter steht in den Startlöchern, dessen Anwendung auch in Delphi geschrieben ist. Es hapert nur an der Datenmigration. Nun war aber auch in der Verwaltung jemand so schlau und hat mal Linux ins Pflichtenheft geschrieben. Zwar unter nice-to-have aber immerhin.

Gestern habe ich interessenhalber mal bei eben diesem Anbieter angerufen und nachgefragt, ob man denn CrossVCL auf der Agenda hätte. Denen ging es wie mir: Noch nie gehört und man merkte sofort, da war jemand vom Hocker gefallen. Ich bin dann bis zum Leiter der Entwicklung verbunden worden. Der hat mir klipp und klar gesagt: Das was Windows in den Verwaltungen hält sind Bestandsanwendungen, die sich nicht mit vertretbarem Aufwand migrieren lassen. FALLS CrossVCL mehr sein sollte als ein Sturm im Wasserglas, dann würde das in seiner Firma einiges radikal verändern. Denn er hätte inzwischen einen meterhohen Stapel an Anfragen von Stadtverwaltungen zu einem Linux-Client.

Ich hab dann interessenhalber mal gefragt, mit welcher Edition die denn arbeiten. Und siehe da: Überwiegend Professional, Architekt nur auf einer einstelligen Zahl Arbeitsplätze. Wird man auch nicht ändern, aus Kostengründen.

Also, @Emba: Packt doch bitte den Linux-Compiler in die Pro-Edition. Lasst das Kind doch erst mal groß werden und in ein paar Jahren schauen wir noch mal neu.

[bytecook]

Hmmm, ich brauch eigentlich nur die Professional Version für unsere Entwicklung, nur für den Linux Support ist mir der Aufwand "Enterprise" auch zu hoch.
Ein Linux-Addon plus Maintenance für die Pro Variante könnte ich mir hingegen gut vorstellen. Derzeit setze ich zur Linux Unterstützung Lazarus parallel zu Delphi ein.

[Codehunter]

Zitat von bytecook:

Derzeit setze ich zur Linux Unterstützung Lazarus parallel zu Delphi ein.

Ja, das habe ich mir auch angeschaut. Da kamen so nostalgische Gefühle hoch. Delphi 5 und so... Also für kleinere Projekte kann man Lazarus durchaus her nehmen. Aber eine Migration einer bestehenden Anwendung zu Lazarus/FPC ist ein ähnlich hoher Aufwand wie zu FMX. Allerdings werde ich immer mehr ein Fan neuerer Delphi-Sprachfeatures wie Generics und anonymer Methoden. Erstere gehen mittlerweile in FPC, letztere wohl noch nicht (hab aber auch nicht mehr nachgeschaut).

Bei einem neuen, großen Projekt völlig auf Lazarus zu setzen, halte ich für gewagt. Denn machen wir uns nichts vor: So toll die IDE inzwischen auch ist, es fehlen viele kommerzielle Komponenten. Die freien Alternativen können da schlicht nicht mithalten. Und für Leute die mit dem Coding Geld verdienen müssen ist es eine Pest, wenn sie ein Rad neu erfinden müssen.

[jaenicke]

Zitat von Codehunter:

Dieser Umstand war mir noch gar nicht so bewusst, da ich NIE mit Wartungsvertrag unterwegs bin sondern in ungleich größeren Abständen migriere wenn es wieder einmal ein Killerfeature gibt.

Mich würde interessieren wie viel du dafür ungefähr über die Jahre dann ausgegeben hast. Ich kenne mehrere Beispiele, in denen für die Professional Version durch diese Strategie mehr ausgegeben wurde als mit Subscription für die Enterprise fällig gewesen wäre (von der Subscription für die Professional ganz zu schweigen)...