Delphi 10.2 LINUX Entwicklung

[MEissing]

Zitat:

Zitat von Codehunter (Beitrag 1383999)

( @MEissing liest du mit? )

Ja. Es ist aber schon alles gesagt. Vielleicht nur noch nicht von jedem....

[MichaelT]

Du fährst selbst mit RAD Studio Enterprise mit Wartungsvertrag über die Zeit günstiger.

Allein wird man sich hart tun die Matrix Programmiersprache + OS dick zu besetzen. Das ist der kleine Wermutstropfen.

Der RAD-Studio SA ist die obere Grenze des als solches wahrgenommenen GWG (teuerster Verbrauch).

Ab der Maschine (bei ca. 7k EURO) und rund um die 1.4k pro Jahr ist es für einen Hersteller halbwegs 'einfach' viel 'qualitatives' Wachstum abzubilden. In Mitteleuropa hat sich seit der Trennung der Güter in zinstragende (Maschinen) und nicht zinstragende (Verbrauch) nicht viel geändert.

Denk an ein altes Auto. Preis/Leistung ist bei 8k im Peak (neu) oder andere Variante ist um ein paar hundert EURO einen gebrauchten Kübel. Am Marktplatz war der Preis egal, da die oben genannte Unterteilung nicht relevant war und sowieso eher Werkzeuge wurden gehandelt und nicht Maschinen. Es hat auch keiner mit der Steuerung der Einkommenshöhe bezogen auf den Privatkonsumenten dafür sorgen müssen, dass kein Privathaushalt Maschinen im Eigentum kann übernehmen. Sonst kollabiert die Linienlogik, da du aus Sicht der 'Wirtschaft' mit deinem Konsumenten schon auf der Müllhalde stehst und nur Müll produzierst.

---

Preis/Leistungsverhältnis bei RAD-Studio Architekt und RAD Studio Enterprise Wartung ist vermutlich in der Spitze.

Delphi Prof. Wartung kostet praktisch gar nichts. Delphi Prof SA ist 315 EURO Netto und für FireDAC kommen 168 EURO ca. hinzu.

Ich bin eher auf der kleinen Variante im Moment.

Es gibt keine nicht kommerziellen Software-Tools und am Ende werden alle teuer, deswegen werden sie vom 'Staat' oder großen Schuppen bereitgestellt.

Zitat:

Zitat von jaenicke (Beitrag 1384088)

Zitat:

Zitat von Codehunter (Beitrag 1383999)

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)... ;-)

[Codehunter]

Die Diskussion gleitet jetzt so ein bissi ab. Der Kernpunkt meinerseits sollte eigentlich sein, dass der Linux-Compiler entweder in die Pro-Edition gehört oder der Mac-Compiler da raus und in die Enterprise. Ich seh es halt aus meiner bescheidenen Perspektive. Einerseits habe ich einen Compiler für eine Edeldödelkiste den ich nie brauche, andererseits könnt ich den Linuxcompiler gut brauchen und komm nicht ran weil mein Brötchengeber des anders (rein absolut monetär) sieht.

Und so ganz unrecht hat er ja nicht: Mit einer Subscription bekämen wir immer das frischeste Delphi. Ob wir das jedesmal installieren oder nicht sei mal dahin gestellt, aber es wäre ja blöd sich das auf Halde zu legen. Nur jedes (oder fast jedes) Delphi-Update zieht auch gleich wieder einen ganzen Rattenschwanz an Drittanbieter-Updates nach sich die ebenfalls wieder Kosten verursachen.

Vielleicht hat uns der Deutschland-Vertrieb ja auch nur schlechte Angebote gemacht? Jedenfalls lagen diese um einiges höher als die Zahlen die hier so kolportiert wurden. Egal. Ist wie es ist.

Liebe Marketing-Strategen von Embarcadero: Nehmt es einfach als Anregung, den Weg von Delphi Richtung Linux zu fördern und den Compiler in die Pro zu verlegen.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1384129)

Der Kernpunkt meinerseits sollte eigentlich sein, dass der Linux-Compiler entweder in die Pro-Edition gehört oder der Mac-Compiler da raus und in die Enterprise. Ich seh es halt aus meiner bescheidenen Perspektive.

Das ist wohl der Grund weshalb es kein FMX für Linux gibt. Denn dass es technisch kein Problem ist, sieht man ja an fmxlinux (und VGScene hat es ja auch schon unterstützt). Deshalb vermute ich leider, dass der Verzicht darauf eine politische Entscheidung war.

Denn so kann man argumentieren, dass Serverprodukte in die Enterprise gehören und Desktop-Plattformen in die Professional. Dem stimme ich auch zu. Aber wenn dann um so argumentieren zu können auf Features verzichtet wird, finde ich das schon sehr schade. Und nicht gerade fair den Benutzern gegenüber, weder denen mit Enterprise noch denen mit Professional...
Auch für uns wäre FMX für Linux interessant, allerdings widerstrebt es uns etwas dafür nun ein separates Produkt zu erwerben.

Dass niemand von Embarcadero dieser Vermutung widerspricht, spricht leider nicht gerade dafür, dass ich mich irre.

[Codehunter]

Für mich ist der Compiler schlicht Basistechnologie. Aus der Möglichkeit, ELF-Binaries zu backen wird ja noch lange kein fertiges Produkt. Und sowohl FMX als auch CrossVCL adressieren ja den Desktop und nicht den Server. Insofern würde ich vollkommen zustimmen, dass Emba High-Level-Server-API in die höheren Delphi-Editions packt.

Aber so wie es jetzt gestaltet ist, produziert man ein Henne-und-Ei-Problem: Delphi ist historisch eine Umgebung die sich mit Frontends befasst. Also Client, Desktop. Will man den Fuß in den Bereich Linux bekommen, sollte man IMHO den Delphi-Weg gehen. Die Basistechnologie (Compiler) für alle, die Luxusfeatures kosten extra. Wenn man die Clients (DB-Frontends in der Regel) auf den Linux-Desktop gebracht hat, wächst der Bedarf an serverseitigen Techniken prinzipbedingt nach.

Möglicherweise hat auch niemand damit gerechnet, dass FMXLinux und CrossVCL von extern kommen würden und der Linux-Desktop so herum in die Diskussion rutschen würde.

[MichaelT]

Die 'monetäre' Sicht ist wohl relevant, eher seitens EMB, da nicht beliebige Preise erzielt werden können und der Rahmen deswegen zwangsläufig anders abgesteckt wird.

Das gilt für jedes Produkt. Du weißt ja nicht, ob du einen Chancenraum oder die Büchse der Pandora öffnest :-D.

Richtig ist mal, dass jedes Produkt (Gut) isoliert betrachtet werden muss. In dem Sinne ist sogar Delphi Prof. genauso wie Delphi Enterprise ein anderes Gut auf jeden Fall.

Damit verbleibt eher die Entscheidung, was macht ein Benutzer von Delphi Prof. mit Delphi Linux Unterstützung ohne GUI. EMB wird das vermutlich eher wegen MS und Linux Subsystem machen. Borland ist und war ein MS Shop und das hat sich nicht geändert, egal wer wem welches Mascherl umhängt.

Der sog. 'Brötchengeber' wird sich nicht leicht tun. Der ist in Mitteleuropa, insbesondere in Deutschland, was Werkzeuge betrifft, halbwegs eingeschränkt. Delphi Enterprise zahlt sich sofort aus, sobald man sich Software für sich selbst schreibt und den ganzen Overhead (das war eben die Idee VB Rad) mit Entwicklern einspart. Aber keine Sorge auch in der Schweiz ist mit mehr als ein paar hundert EURO pro Jahr und Arbeitsplatz der Zenith eilig überschritten.

In dem Umfeld spielen zwei Erfahrungen aus den 90ern mit. Wenn Produkte teuer wurden, verschwanden sie damals eilig vom Markt und 1000 Leute mit der Hand graben zu lassen anstatt Bagger zu bemühen ist in unseren unsinnigen Modell der soz. Marktwirtschaft noch immer verlockend.

Es gab mal vor 2k Studien, dass ein IT Entwickler Arbeitsplatz mal (damals) mit ca. 12 EURO gerechnet werden muss.

Du kannst erst als Selbstständiger von RAD profitieren, da du an sich dein Einkommen frei kannst gestalten. Du hast den Privatkonsumenten und den Konsumenten deines 'Unternehmens'. Im nächsten Schritt profitierst du von der Vorwegnahme von Effizienzzugewinnen durch Arbeitsteilung im Unternehmen. Delphi verbindet dann doch noch den C/C++ Programmierer mit dem VB Programmierer, wenn man in der traditionellen Begriffswelt will verweilen.

Ich persönlich hätte auch mehr Freude mit Linux als mit Mac. Aber ich sowieso Zugriff auf FPC/Laz als Lösung aus der Free resp. Open-Source Welt und damit befriedigt den Teil ein anderes Delivery resp. Bewirtschaftungsmodell. GCC?

In anderen Teilen der Erde ist ein Delphi Enterprise Lizenz nicht wirklich teuer. Ein Auto in Singapur kostet mehr als ein Haus bei uns in Summe. Auch dein 'Brötchengeber' wird mal nach Taschlowitz fahren müssen.

Sobald ein Wirtschaftsbereich industrialisiert wird, liefert am Ende der Hersteller der Plattform die Werkzeuge genauso. Nicht da diese Unternehmen davon so begeistert wären, aber die haben gar keine Wahl. Ein digitales Gut ist in etwa zu sehen wie ein Gut der Realwirtschaft das praktisch jeden Kunden hat gefunden. Das wäre bei einer Wohnung der Zustand, dass du für eine schöne Wohnung soviel Miete müsstet zahlen, dass du dir keine Möbel mehr leisten kannst. Dann ist die Lösung aber nicht mehr Einkommen, sondern das Mobiliar wird reingestellt. Qualitatives Wachstum:-D.

Kommt dir das bekannt vor? (GetIt).

Die DB Hersteller müssen genauso die .net Treiber liefern, obwohl die Logik sagt, dass der IDE Provider die Treiber liefert. Das wäre der 'normale' Weg.


Du argumentiert, keine Schelte, aus der Logik der Open Source Linux und Windows Welt im Rahmen beginnenden Industrialisierung der IT. Wir können uns viel wünschen, aber das Bundling des Produkts ist Sache von EMB. EMB weiß was die Kunden brauchen. Delphi Prof. Wartung selbst ist annähernd gratis, du zahlst für das Mehr rundherum.

Du bist aus Sicht der Rechnung deines Brötchengebers eher im Maschinenpark angesiedelt. Das wollen wenige Menschen wahrhaben. Die erfolgreiche Anwendung von Talent auf gegebenes Material im Rahmen der erworbenen Fähigkeiten (unter Zuhilfenahme von Werkzeugen) ist die Definition von Arbeit. Das ist im Industriemodell immer die Maschine. Wenn dein Brötchengeber eine IDE als Gemeinkosten auf der Kostenstelle anschaut rechnet er falsch. Aber das passiert in Österreich genauso noch ...

Aber keine Sorgen, die Pfennigfuchser regen sich bei 900 EURO jährlich für BW Entwickelerarbeitplatz Lizenzen auch schon auf. Es gibt zuwenige Unternehmer und zuviel in Miete hausender unselbstständig Erwerbstätige die eher für das liebe Geschau bezahlt werden.

Auf die Idee Delphi für Linux in die Prof. zu geben sind EMB Leute bestimmt von allein schon gekommen.

Zitat:

Zitat von Codehunter (Beitrag 1384129)

Die Diskussion gleitet jetzt so ein bissi ab. Der Kernpunkt meinerseits sollte eigentlich sein, dass der Linux-Compiler entweder in die Pro-Edition gehört oder der Mac-Compiler da raus und in die Enterprise. Ich seh es halt aus meiner bescheidenen Perspektive. Einerseits habe ich einen Compiler für eine Edeldödelkiste den ich nie brauche, andererseits könnt ich den Linuxcompiler gut brauchen und komm nicht ran weil mein Brötchengeber des anders (rein absolut monetär) sieht.

Und so ganz unrecht hat er ja nicht: Mit einer Subscription bekämen wir immer das frischeste Delphi. Ob wir das jedesmal installieren oder nicht sei mal dahin gestellt, aber es wäre ja blöd sich das auf Halde zu legen. Nur jedes (oder fast jedes) Delphi-Update zieht auch gleich wieder einen ganzen Rattenschwanz an Drittanbieter-Updates nach sich die ebenfalls wieder Kosten verursachen.

Vielleicht hat uns der Deutschland-Vertrieb ja auch nur schlechte Angebote gemacht? Jedenfalls lagen diese um einiges höher als die Zahlen die hier so kolportiert wurden. Egal. Ist wie es ist.

Liebe Marketing-Strategen von Embarcadero: Nehmt es einfach als Anregung, den Weg von Delphi Richtung Linux zu fördern und den Compiler in die Pro zu verlegen.

[bytecook]

Hat wer schon Erfahrungen gesammelt mit Oxygene in Verbindung mit Island?

Link: http://www.elementscompiler.com/elements/Island/

Scheinbar kann man nun mit Island nun auch Native Code erzeugen, Zielplattformen sind derzeit Windows und Linux.
Unterstützt werden damit x86, x64 sowie ARM Prozessoren.

[Fritzew]

Zitat:

Zitat von bytecook (Beitrag 1384152)

Hat wer schon Erfahrungen gesammelt mit Oxygene in Verbindung mit Island?

Link: http://www.elementscompiler.com/elements/Island/

Scheinbar kann man nun mit Island nun auch Native Code erzeugen, Zielplattformen sind derzeit Windows und Linux.
Unterstützt werden damit x86, x64 sowie ARM Prozessoren.

Das funktioniert, aber Du hast keinerlei Gui support in Form von Bibliotheken oder ähnlichem. Im moment vor allem mit Dataabstract
in Verbindung als Server Plattform.
Die Spracherweiterungen sind echt klasse. Und das mixen von Swift, Java, C# und Pascal innerhalb eines Projektes.
Ich finde es toll was die Jungs von Remobects da bieten

[bytecook]

Zitat:

Zitat von Fritzew (Beitrag 1384159)

Zitat:

Zitat von bytecook (Beitrag 1384152)

Hat wer schon Erfahrungen gesammelt mit Oxygene in Verbindung mit Island?

Link: http://www.elementscompiler.com/elements/Island/

Scheinbar kann man nun mit Island nun auch Native Code erzeugen, Zielplattformen sind derzeit Windows und Linux.
Unterstützt werden damit x86, x64 sowie ARM Prozessoren.

Das funktioniert, aber Du hast keinerlei Gui support in Form von Bibliotheken oder ähnlichem. Im moment vor allem mit Dataabstract
in Verbindung als Server Plattform.
Die Spracherweiterungen sind echt klasse. Und das mixen von Swift, Java, C# und Pascal innerhalb eines Projektes.
Ich finde es toll was die Jungs von Remobects da bieten

Hmmm, hört sich extrem interessant an. Gui Support benötige ich nicht wirklich, da ich alle meine Visualisierungen selber entwickle.

Habe mir in den letzten zwei Jahren ohnehin meine eigene vektorbasierte Runtime Gui geschrieben, die derzeit als Basis eine erheblich modifizierte Gaphics32 als Grundlage verwendet.

Die eigentliche Gui hat noch eine Abstraktionsebene zwischen Gr32, könnte aber auch OpenGl/Vulkan verwenden. Mal sehen, ob ich da kommendes Jahr was machen kann...

[Codehunter]

Zitat:

Zitat von MichaelT (Beitrag 1384146)

Aber keine Sorgen, die Pfennigfuchser regen sich bei 900 EURO jährlich für BW Entwickelerarbeitplatz Lizenzen auch schon auf. Es gibt zuwenige Unternehmer und zuviel in Miete hausender unselbstständig Erwerbstätige die eher für das liebe Geschau bezahlt werden.

Als Nicht-Schweizer: Was ist "das liebe Geschau"? :)

Wie ich vormals schon schrieb, jeder hat seine eigene Sicht der Dinge. Sicher liegt auch auf unserer Seite (Brötchengeber) einiges im Argen. Letztendlich breche ich es mal auf die Frage herunter, ob der Bedarf an Funktionalität entwicklerseitig mit dem Zugewinn an Features und Preisen delphiseitig skaliert. Zumindest was uns betrifft, geht da die Schere immer weiter auseinander.

Interessant wäre die Frage, was passieren würde wenn Emba sein Lizenzmodell auf so ein Adobe-like Abo umstellen würde. Quasi Subscription für alle. Könnte mir vorstellen dass es dann günstiger werden müsste, weil man solche "Geizkrägen wie mich" mit ins Boot holen würde die sonst nur alle 5 Jahre mal eine Lizenz kaufen.

[bytecook]

Zitat:

Zitat von Codehunter (Beitrag 1384184)

Zitat:

Zitat von MichaelT (Beitrag 1384146)

Aber keine Sorgen, die Pfennigfuchser regen sich bei 900 EURO jährlich für BW Entwickelerarbeitplatz Lizenzen auch schon auf. Es gibt zuwenige Unternehmer und zuviel in Miete hausender unselbstständig Erwerbstätige die eher für das liebe Geschau bezahlt werden.

Als Nicht-Schweizer: Was ist "das liebe Geschau"? :)

Wie ich vormals schon schrieb, jeder hat seine eigene Sicht der Dinge. Sicher liegt auch auf unserer Seite (Brötchengeber) einiges im Argen. Letztendlich breche ich es mal auf die Frage herunter, ob der Bedarf an Funktionalität entwicklerseitig mit dem Zugewinn an Features und Preisen delphiseitig skaliert. Zumindest was uns betrifft, geht da die Schere immer weiter auseinander.

Interessant wäre die Frage, was passieren würde wenn Emba sein Lizenzmodell auf so ein Adobe-like Abo umstellen würde. Quasi Subscription für alle. Könnte mir vorstellen dass es dann günstiger werden müsste, weil man solche "Geizkrägen wie mich" mit ins Boot holen würde die sonst nur alle 5 Jahre mal eine Lizenz kaufen.

Bring die Embas nicht auf dumme Ideen :P Ich hab nach wie vor CS6 Extended, und arbeite neuerdings mit Affinity Designer sowie Affinity Photo als Ersatz für CS Live. Ein Adobemodell würde eher kontraproduktiv wirken, eine Subscription parallel zum derzeitigen Maintenance Modell wäre denkbar (Siehe Modo Lizenzmodelle, http://Foundry.com). Als vorbildliches Bezahlmodell sehe ich das "Substance Live Model" von http://www.allegorithmic.com/

Und - aus dem Unternehmerblickwinkel betrachtet - hängt der Einsatz eines teureren Produktes nur vom Mehrwert für das Unternehmen ab. Bin kein "Centfuchser", aber ich habe heuer sogar unsere VisualStudio Lizenz gedroppt, weil es entwicklungtechnisch kaum mehr Sinn macht. (Wir verwendeten VS nur zur Entwicklung von Win CE 7 Applikationen).

[Codehunter]

Zitat:

Zitat von bytecook (Beitrag 1384190)

Bring die Embas nicht auf dumme Ideen :P

Ich bin sicher, die brauchen mich Querulanten nicht dazu ;-)

Zitat:

Zitat von bytecook (Beitrag 1384190)

Und - aus dem Unternehmerblickwinkel betrachtet - hängt der Einsatz eines teureren Produktes nur vom Mehrwert für das Unternehmen ab. Bin kein "Centfuchser", aber ich habe heuer sogar unsere VisualStudio Lizenz gedroppt, weil es entwicklungtechnisch kaum mehr Sinn macht. (Wir verwendeten VS nur zur Entwicklung von Win CE 7 Applikationen).

Für WinCE hatte ich mal kurzzeitig Lazarus ins Auge gefasst. Allerdings löste sich das Problem rechtzeitig durch die Hintertür, weil sich bei dem betreffenden, überalterten Gerätepark die nicht mehr beschaffbaren Akkus verabschiedeten. Danach konnte ich das Ganze zum Glück Richtung Android abbiegen, was mir wenigstens ein XE4 mit Mobile Addon einbrachte :-)

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1384184)

Interessant wäre die Frage, was passieren würde wenn Emba sein Lizenzmodell auf so ein Adobe-like Abo umstellen würde. Quasi Subscription für alle. Könnte mir vorstellen dass es dann günstiger werden müsste, weil man solche "Geizkrägen wie mich" mit ins Boot holen würde die sonst nur alle 5 Jahre mal eine Lizenz kaufen.

Eigentlich haben wir das ja bereits. Aktuell kann man keine neue Version und kein Update erwerben, ohne das erste Jahr Update Subscription mit dazu zu bekommen (und natürlich auch zu bezahlen). Ziel dabei ist es natürlich, daß diese Kunden ihre Subscription auch regelmäßig verlängern. Wie ja schon mehrfach von verschiedenen Seiten hier dargelegt wurde, ist das auch mit Abstand die günstigste Variante um auf dem Stand zu bleiben. Die Preisgestaltung der Updates und der update-fähigen Versionen ist auch bewusst darauf ausgelegt. Lediglich im Zuge eines Amnesty-Updates, bei dem auch ältere Versionen upgrade-berechtigt sind, kann man noch halbwegs ein Schnäppchen machen. Dabei sind die oben angesprochenen 5 Jahre durchaus realistisch bis knapp anzusehen. Allerdings muss man dann auch wirklich diese asketische Haltung durchziehen und sich ein Update innerhalb dieses Zeitraums verkneifen; andernfalls zahlt man drauf.

Ganz außer Acht gelassen ist dabei aber der sich aufstauende Portierungsaufwand bei so großen Versionswechseln. Was sonst eher fließend bzw. auf mehrere Jahre verteilt abläuft, muss in so einem Fall in einem oft recht umfangreichen Portierungsprojekt durchgeführt werden, für das eigentlich im täglichen Geschäft keine Zeit bleibt. Nicht selten wird dabei dann auf externe Helfer ( 8-) ) zurückgegriffen, wobei sowas dann ja auch nicht kostenneutral bleibt.

Untern Strich halte ich eine Update-Subscription, bei der man seine Projekte natürlich auch weitestgehend zeitnah aktuell hält, für die kostengünstigere und stressfreiere Alternative. (Obwohl eine solche Aussage eigentlich schon geschäftsschädigend ist, da ich ja unter anderem auch gerade mit solchen Projekten mein Geld verdiene.)

[jaenicke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1384201)

Obwohl eine solche Aussage eigentlich schon geschäftsschädigend ist, da ich ja unter anderem auch gerade mit solchen Projekten mein Geld verdiene.

Fehlt dann nur noch eine Update-Subscription von dir, bei der Du die Änderungen für den Versionswechsel bei der direkten Folgeversion übernimmst (Preis natürlich trotzdem projektspezifisch). :stupid:

[Codehunter]

Ich könnte nicht behaupten, dass es einen exzessiven Portierungsaufwand nach sich gezogen hätte als ich von D7 -> XE4 -> Seattle migriert bin. Aber das ist seeeeehr subjektiv und arg von den Projekten abhängig. Darum stimme ich euch schon zu, dass es sicher auch Fälle gibt wo eine Subscription allein schon unter diesem Gesichtspunkt sinnvoll wird. Wenn man schon Geld ausgibt, dann lieber nicht für sinnlos verplemperte Arbeitsstunden.

Leider gefällt sich mein Chef in der Rolle des Frosches im Kochtopf. Etwas fertiges einzukaufen ist verdammt heißes Wasser. Während die Neuerfindung diverser Räder durch die Mitarbeiter eher zu einer langsamen Erwärmung führt. Und unseren Frosch will niemand aus seinem Topf hüpfen sehen :-(

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1384204)

Leider gefällt sich mein Chef in der Rolle des Frosches im Kochtopf. Etwas fertiges einzukaufen ist verdammt heißes Wasser. Während die Neuerfindung diverser Räder durch die Mitarbeiter eher zu einer langsamen Erwärmung führt. Und unseren Frosch will niemand aus seinem Topf hüpfen sehen :-(

Vielleicht sollte mal jemand vorrechnen was die eigenen Mitarbeiter in der Zeit gekostet haben im Vergleich zu einer meist noch deutlich umfassenderen Fremdlösung. Ich bin auch eher dafür viel selbst zu machen, aber dabei sollte man eben nicht vergessen, dass die eigenen Mitarbeiter zwar konstante Kosten verursachen, aber in der Zeit auch produktiveren Tätigkeiten nachgehen könnten und damit am Ende mehr kosten.

Aber ich kenne diese Argumentationen natürlich und gehe davon aus, dass auch dir das alles klar ist.

Es gibt für Delphi ja auch diverse Produktivitätstools, mit denen man schlicht das selbe Ziel deutlich schneller erreichen kann. Im Vergleich zur gesparten Zeit sind diese sehr billig, aber trotzdem sind es zusätzliche Ausgaben, so dass auch da wiederum oft eher gespart wird.

// EDIT:

Zitat:

Zitat von Codehunter (Beitrag 1384204)

Ich könnte nicht behaupten, dass es einen exzessiven Portierungsaufwand nach sich gezogen hätte als ich von D7 -> XE4 -> Seattle migriert bin. Aber das ist seeeeehr subjektiv und arg von den Projekten abhängig.

Oh ja. Bei uns war das eine sehr umfangreiche Baustelle bei der Umstellung Delphi 5 --> Delphi XE wegen Unicode. Manche Folgefehler sind auch erst Jahre später aufgefallen.

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1384214)

Vielleicht sollte mal jemand vorrechnen was die eigenen Mitarbeiter in der Zeit gekostet haben im Vergleich zu einer meist noch deutlich umfassenderen Fremdlösung. Ich bin auch eher dafür viel selbst zu machen, aber dabei sollte man eben nicht vergessen, dass die eigenen Mitarbeiter zwar konstante Kosten verursachen, aber in der Zeit auch produktiveren Tätigkeiten nachgehen könnten und damit am Ende mehr kosten.

Powerpoint, BWL, Youtube-Video, Whiteboard, Schmierzettel, Fachliteratur, Steuerberater. Ich hab da mein Pulver vergeblich verschossen. Hast du vielleicht andere Ansätze? ;-)

Zitat:

Zitat von jaenicke (Beitrag 1384214)

Bei uns war das eine sehr umfangreiche Baustelle bei der Umstellung Delphi 5 --> Delphi XE wegen Unicode. Manche Folgefehler sind auch erst Jahre später aufgefallen.

Ehrlich gesagt irritieren mich all die Horrorgeschichten rund um Unicode schon seit Jahren ein wenig. Auch das mag fallspezifisch sein aber bei uns gab es da nur an der Schnittstelle zu diversen Datenbanken Reibereien und war mit dem Umstieg auf Unidac und aktuellere DBMS ratzfatz erledigt. Allerdings war der Umbau von BDE zu Unidac damals ein Kraftakt.

Vor XE4 wurde mir jahrelang meine Marotte vorgehalten, dass ich SQL-Querystrings in Ressourcen-DLLs ausgelagert habe. Seit der Umstellung machen das hier alle so. Wie das nur kommt ^^

[sh17]

Hmm, also ich finde es ja nicht schlecht, das Embarcadero 3th-party FMXLinux supportet, ich hoffe nur dass das irgendwann integraler Bestandteil von Delphi wird.

http://forms.embarcadero.com/WebinarFMXLinuxandDelphi

[Codehunter]

Zitat:

Zitat von sh17 (Beitrag 1386483)

Hmm, also ich finde es ja nicht schlecht, das Embarcadero 3th-party FMXLinux supportet, ich hoffe nur dass das irgendwann integraler Bestandteil von Delphi wird.

Da brauch ich keine :glaskugel: um zu ahnen, dass das keine gute Idee ist. Eigentlich wie mit Microsoft und Windows: Je mehr aufgekauft und integriert wird, umso pottiger, aber teurer wird das Gesamtkonstrukt. Beide Firmen ( E und M ) haben nicht den nötigen Elan dafür. Kleinere Features fallen aus dem produktstrategischen Fokus. Frei am Markt haben die Entwickler viel mehr Interesse daran, ihre Lösungen zu verbessern. Aber es scheint ja zur Zeit Mode zu sein, 3rd Party-Lösungen gerade so weit zu entwickeln, dass Embadera neugierig wird, nur um dann gewinnbringend abzustoßen. Das mag Delphi als IDE augenscheinlich aufwerten, Delphi als Ökosystem ist es dagegen abträglich.

[Harry Stahl]

Bei unserem letzten Delphi-Frühstück in Köln (http://wiki.delphitreff.de/) habe ich einen kurzen Vortrag über FMXLinux gehalten. Ich habe die wesentlichen Inhalte dazu jetzt auch als neuen Blog-Eintrag (Nr. 15, "Kurze Einführung zu FMXLinux") in meinem Firemonkey-Blog online gestellt, evtl. ist es ja auch für den einen oder anderen hier von Interesse:

http://www.devpage.de/blog/firemonkey.htm

[wschrabi]

Lieber Hr Stahl,
besten DANK für diese super heiße INFO. Auch werde ich mir Ihr Buch kaufen - damit einer LINUX Prg Erstellung mit Tokyo nichts mehr im Wege steht.
mfg
Schrabi :thumb:

Frage:

Zitat:

Wie sieht es mit der Unterstützung von FMXLinux seitens Komponentenherstellern aus?
Hier wächst die Unterstützung. TMS-Software war schon sehr früh dabei, ich verwende auch einige Komponenten des TMS FMX-UI-Packs in meinen Cross Platform Projekten.

Auf der Seite des Herstellers finden Sie eine Liste:

https://fmxlinux.com/tlist.html

Unter diesem Link https://www.tmssoftware.com/site/tmsfmxpack.asp sehe ich aber kein LINUX ICON. Wo/welche Version kann ich kaufen damit ich FMX UI für Linux habe?

[Harry Stahl]

Danke für die Rückmeldung.
Prima, als begeisterter Linux-Fan freut mich jedes zusätzliche Linux Programm, das mit Delphi entwickelt wurde...:thumb:

[Harry Stahl]

Zitat:

Zitat von wschrabi (Beitrag 1402532)

Auf der Seite des Herstellers finden Sie eine Liste:

https://fmxlinux.com/tlist.html
Unter diesem Link https://www.tmssoftware.com/site/tmsfmxpack.asp sehe ich aber kein LINUX ICON. Wo/welche Version kann ich kaufen damit ich FMX UI für Linux habe?

Kann sein, dass TMS hier noch kein Linux-Symbol aufgenommen hat, weil wohl noch nicht alle Komponenten zu 100% unterstützt werden. Ich werde Bruno Fierens hier mal ansprechen, ob er nicht mal eine Liste machen kann, welche seiner FMX-UIPack-Komponenten jetzt wirklich zu 100% unterstützt werden, damit man das nicht selber rausfinden muss.

Ich habe selber hier z.B. die RichEditor-Komponente im Einsatz, die funktioniert soweit, allerdings (jedenfalls bei mir) hat sie Probleme mit Bulletpoints. Da wollte ich Bruno auch noch mal drauf ansprechen. Einige der anderen Kompos habe ich mal so spielerisch ausprobiert, das meiste machte davon einen guten Eindruck.

Wenn ganz bestimmte Kompos für FMXLinux benötigt werden, würde ich bei TMS zur Sicherheit vorher nachfragen, ob die auch wirklich unter FMXLinux unterstützt werden. Soweit ich das sehe, hat TMS auch Interesse daran, FMXLinux zu unterstützen und sind auch bereit, daran weiter zu arbeiten, allerdings sind die wohl gerade mit dem TMSWeb sehr beschäftigt.

[wschrabi]

Schönen DANK, Hr Stahl! Wirklich super Service von Ihnen so kompetent und schnell zu antworten.
:P:thumb:

[wschrabi]

hallo Hr Stahl,
müßte der PAServer für Linux auch unter SUSE gehen oder nur unter Ubuntu?
Ich hab ihn mir von hier geholt:
http://docwiki.embarcadero.com/RADSt...nt_unter_Linux

Leider noch nicht Realease 3 von 10.2 sondern das erstere.

Doch ich bekomme nach tar -xvf <filename>.tar.gz und ausführen von ./paserver
dass er die bin nicht ausführen kann. (Siehe Bild als attachment)

Können Sie mir da weiterhelfen?
DANKE
Walter

[wschrabi]

Liebe Leute, hab grad das hier gesehen:


Delphi Linux Distributions coverage
10.2 supports Ubuntu LTS Version 16.04 and RedHat Enterprise Version 7.

The choice of Ubuntu (Debain based) and RedHat (Fedora, CentOS) has proven in the beta forums to offer a much wider coverage than the official support distributions, that will I’m sure grow in time.

Marco recently commented that these distro’s were chosen based on the feedback from surveys and wider Linux Usage. SUSE is not currently supported, but if you are desperate to use SUSE, then you can always put InterBase 2017 on there for now 🙂

[Harry Stahl]

Zitat:

Zitat von wschrabi (Beitrag 1402589)

hallo Hr Stahl,
müßte der PAServer für Linux auch unter SUSE gehen oder nur unter Ubuntu?

Um welche Suse Version handelt es sich?
Sicher auch 64-Bit?

Jedenfalls unter Suse Open Leap 42.3 läuft der PAServer, siehe anliegenden Screenshot.
Mit Delphi erzeugte Programme laufen da auch, siehe zweiten Screenshot.

Dennoch würde ich nach Möglichkeit unter Ubuntu-64 (16.04) entwickeln, das ist offiziell und sicher auch die größte Userbasis.

[wschrabi]

Schönen DANK,
es war ein openSUSE 13.1 Bottle i386 also kein 64bit.

Nun habe ich auch zZ einen Debian wo der PAserver läuft.
Doch mein 1. Prg macht Errors.
Hätten Sie vielleicht ein Prg zum Testen? Ich hatte einen OPENDIALOG und ein MEMO Fenster verwendet. Geht das damit nicht?
Ich bekomme erst Ihr BUch, wo ich mir einiges vorher durchlesen werde.

Kann ich PRg die auf Debian PA SERVER entwicklet werden auch auf UBUNTU 16.04 dann laufen lassen?
Wird alles in ein File gepackt, das dann ausgeführt werden kann, oder muss wo noch was installiert werden?

DANKE HERZLICHST
Schrabi

PS: bekomme in PAServer diese Msgs

[MichaelT]

Ich bin kein Schweizer :-D. Das liebe Gschau ...

Nach langem Plagen muss ich eingestehen ich fand keine Übersetzung ins Hochdeutsche.

Lieb dreinschauen ... und ambitioniert nichts weiterbringen, ... käme so in etwa hn.

---

In diesem Forum ist aus meiner Sicht schon die Creme de la Creme von Softwareentwicklung im Anwendungsumfeld versammelt. Österreich kennt kaum Individualentwicklung. Unsere Unternehmer haben im Prinzip eine Kernanwendung und das ist genau jene die ihr Geschäft ganz massiv nach vorne bringt. Eine Klein- resp. mittelständische Struktur tut besser daran kontinuierlich voranzuschreiten. Wobei Österreich von 'global' schon profitiert aus Sicht der Wirtschaft und teils auch von der guten Ausbildung in der FH. Die beiden Entwicklungen kommen im Moment zusammen.

Linz (Donau) wo ich herkomme ist ein eigener Fall, eine ganz eigene Mischung.

Softwareentwicklung läuft mehr oder weniger in der Off Shore. Ich persönlich sehe es auch so. Wenn ein Team in einem niedrigeren Preisniveau sich mit neuen Sachen selbst unter Tags kann beschäftigten solle es gut sein. Das geht in Österreich, wenn nicht schon ein Produkt da ist eher noch, aber sonst gar nicht. Teilweise sitzen bei uns gute Systemprogrammierer in der Administration bei den ganz großen Schuppen. Die Allokation im Sinne von es ginge viel mehr ist im Moment eher eine Fehlallokation.

---

Ich habe kein Problem mit Kosten für Tools solange sie nicht aufhalten.

VS ist im Moment für mich keine Option. Ich habe VS 2017 Community installiert und freue mich erstaunt darüber was man nicht alles wie schreiben kann. Ist eh geil. Als C# kam war ich schon höchst erfreut. ADA 2012 ist so meine Welt. Delphi ist schön in der Mitte zwischen die zwei.

Ich tue mir im Moment mit dem Nutzen von Win10 und VS in Kombination etwas hart. Wo wenig berauschend war die MS beim Enduser schon lange nicht mehr beieinander. Selbst bei Solus muss man hie und da eine Recovery des Package Verzeichnis machen, aber dann funktioniert wieder irgendetwas. Was bei der MS morgen sein wird sollte einem zu 95% egal sein. Egal was heute funktioniert, es arbeiten zuviele dran, dass morgen wieder nichts mehr geht. .net/C# war eigentlich die rühmliche Ausnahme.

---

RAD Studio ist ganz gut an sich. In der Liga sind die vergleichbaren Alternativen ja weit abgeschlagen. Die EMB hat schon viel weitergebracht. Schimpfen darf man nicht. EMB unterstützt ganz bewusst was morgen vermutlich noch da ist. Der Teil nimmt sich in der IT immer eher bescheiden aus und eher altertümlich. So schaut IT immer aus im Kern.

Das Web ist am Ende und war seit Beginn auch nur eine Opfergabe einer Generation an Kindern um den großen Drachen im Büro durch buntes Trallala zu besänftigen bis im Hintergrund nach 30 Jahren es endlich so lala gelungen ist irgendwie den 'Mainframe' abzulösen. Allein hat sich das Umfeld in eine Industrie ausgewachsen.


[QUOTE=bytecook;1384190]

Zitat:

Zitat von Codehunter (Beitrag 1384184)

Zitat:

Zitat von MichaelT (Beitrag 1384146)

Aber keine Sorgen, die Pfennigfuchser regen sich bei 900 EURO jährlich für BW Entwickelerarbeitplatz Lizenzen auch schon auf. Es gibt zuwenige Unternehmer und zuviel in Miete hausender unselbstständig Erwerbstätige die eher für das liebe Geschau bezahlt werden.

Als Nicht-Schweizer: Was ist "das liebe Geschau"? :)


Und - aus dem Unternehmerblickwinkel betrachtet - hängt der Einsatz eines teureren Produktes nur vom Mehrwert für das Unternehmen ab. Bin kein "Centfuchser", aber ich habe heuer sogar unsere VisualStudio Lizenz gedroppt, weil es entwicklungtechnisch kaum mehr Sinn macht. (Wir verwendeten VS nur zur Entwicklung von Win CE 7 Applikationen).

[Harry Stahl]

Zitat:

Zitat von wschrabi (Beitrag 1402593)

Nun habe ich auch zZ einen Debian wo der PAserver läuft.
Doch mein 1. Prg macht Errors.
Hätten Sie vielleicht ein Prg zum Testen? Ich hatte einen OPENDIALOG und ein MEMO Fenster verwendet. Geht das damit nicht?

Doch, das sollte normalerweise gar kein Problem sein. Bislang war es nicht ganz unwichtig, dass verwendete Delphi-Version die aktuellste ist (also 10.2.3), ob die Demo FMXLinux mit 10.2. ohne Probleme geht, kann ich im Moment leider nicht sagen, da ich kein 10.2. mehr habe, wo ich das testen könnte.

Zitat:

Zitat von wschrabi (Beitrag 1402593)

Kann ich PRg die auf Debian PA SERVER entwicklet werden auch auf UBUNTU 16.04 dann laufen lassen?

Wie gesagt, ich kann aus eigener Erfahrung aus der Entwicklung nur von Ubuntu 16 berichten. Debian ist zwar eng mit Ubuntu verwandt, ist aber nicht so aktuell, daher könnte es vielleicht Probleme geben.

Wie gesagt, da Ubuntu und Red Hat die offiziellen Entwicklungs-Linuxe sind, würde ich damit arbeiten. Das fertige Programm läuft dann i.d.R. auch auf vielen anderen Linux-Distubutionen.

Zitat:

Zitat von wschrabi (Beitrag 1402593)

Wird alles in ein File gepackt, das dann ausgeführt werden kann, oder muss wo noch was installiert werden?

Ich packe das alles in eine ZIP-Datei mit einer bestimmten Struktur, der Anwender muss diese Datei dann mit der entsprechenden Struktur in seinem Homeverzeichnis entpacken und kann dann in den APP-Ordner wechseln und die Anwendung starten.

In der Anlage mal ein Screenshot, der das mit der Struktur verdeutlicht.

Hier ein kleines Video von meiner Homepage, das dem User erklärt, wie der User das Linux-Programm installiert. http://www.hastasoft.de/pcadress/Vid.../pcalinux.html

Edit: Sehe gerade, das Video ist schon 7 Jahre alt und etwas überholt, den Link kann man heutzutage viel einfacher anlegen. Fast in jeder Linux-Distribution kann man, wenn das Programm läuft, in der dortigen Taskleiste mit der rechten Maustaste drauf klicken und sagen, dass das Programm im Starter / Im Startbereich bleiben soll.

Aber davon abgesehen, ist die Vorgehensweise bei der Installation immer noch die gleiche.

[wschrabi]

Danke Hr Stahl, habe mir Ihr Video angesehen. Ist die Reg Nummer im Buch dabei? Oder wo kann man Ihr PC-Adress Prg für UBUNTU saugen?

PS: Hab grad gesehen: Auf Ihrer HP kann man die LINUX Reg NUmmer kaufen. Ist sehr günstig, und werde ich auch machen, wenn ich mit den 60 DemoStarts nicht auskommen sollte. Ich bräuchte sie ja nur zum Testen wie Sie das mit Linux so machen :)
DANKE


ist auch das *.so in dem APP order dabei, oder ist das in dem APP-Prog-File irgenwie included. Denn im Video hat man nur das Man iPrg im APP Folder gesehen.
DANKE
mfg
WS

[wschrabi]

Liebe Experten,
ich (und mein Bekannter mit dem ich zusammenarbeiten möchte) wollte jetzt für Debian 8 (Jessi) ein einfaches HELLO WORLD! Label auf einem Form darstellen lassen.
Habe FMXLINUX (neuste Version) installiert.
Doch bekomme ich (keine Err oder Warnings in Delphi) aber auf der Console im PA Server folgende Errors.
(Attachment)

Kann mir jemand sagen was ich machen muss, damit er im Form Hello World schreibt?
DANKE

[MichaelT]

Ich habe keine Linux Unterstützung in Delphi, aber da fliegt vermutlich die gtk_init

Schau ob die DISPLAY Variable gesetzt ist und mach mal ein XHOST+ zur Vorsicht.

Zitat:

Zitat von wschrabi (Beitrag 1402660)

Liebe Experten,
ich (und mein Bekannter mit dem ich zusammenarbeiten möchte) wollte jetzt für Debian 8 (Jessi) ein einfaches HELLO WORLD! Label auf einem Form darstellen lassen.
Habe FMXLINUX (neuste Version) installiert.
Doch bekomme ich (keine Err oder Warnings in Delphi) aber auf der Console im PA Server folgende Errors.
(Attachment)

Kann mir jemand sagen was ich machen muss, damit er im Form Hello World schreibt?
DANKE

[Harry Stahl]

Zitat:

Zitat von wschrabi (Beitrag 1402622)

Danke Hr Stahl, habe mir Ihr Video angesehen. Ist die Reg Nummer im Buch dabei? Oder wo kann man Ihr PC-Adress Prg für UBUNTU saugen?

PS: Hab grad gesehen: Auf Ihrer HP kann man die LINUX Reg NUmmer kaufen. Ist sehr günstig, und werde ich auch machen, wenn ich mit den 60 DemoStarts nicht auskommen sollte. Ich bräuchte sie ja nur zum Testen wie Sie das mit Linux so machen :)
DANKE

ist auch das *.so in dem APP order dabei, oder ist das in dem APP-Prog-File irgenwie included. Denn im Video hat man nur das Man iPrg im APP Folder gesehen.
DANKE
mfg
WS

Das Programm PC-Adreßzz! hat mit dem Buch nichts zu tun.

Wenn, dann würde ich mir aber das Programm PC-Database oder PC-Rechnung ansehen, da bislang nur diese mit Delphi und FMXLinux erstellt wurden (andere Linux-Programme werden (noch) mit Lazarus erstellt).

Die *.so Datei muss im Anwendungsordner sein, da das Programm die Datei dort erwartet.

[Harry Stahl]

Zitat:

Zitat von wschrabi (Beitrag 1402660)

Liebe Experten,
ich (und mein Bekannter mit dem ich zusammenarbeiten möchte) wollte jetzt für Debian 8 (Jessi) ein einfaches HELLO WORLD! Label auf einem Form darstellen lassen.
Habe FMXLINUX (neuste Version) installiert.
Doch bekomme ich (keine Err oder Warnings in Delphi) aber auf der Console im PA Server folgende Errors.
(Attachment)

Kann mir jemand sagen was ich machen muss, damit er im Form Hello World schreibt?
DANKE

Wie gesagt, offiziell werden nur Ubuntu 16 und Red Hat Enterprise 7 für die ENTWICKLUNG unterstützt. Kann daher nur noch mal wiederholen, hier mit Ubuntu zu entwickeln, da dürfte wohl die größte Unterstützung zu erwarten sein.

Davon abgesehen: Schon mal das Linux-SDK aktualisiert und dabei auch alte Dateien von neuen überschreiben lassen?

[mkinzler]

Ubuntu 16 basiert auf Debian Stretch ( Version 9)

[Harry Stahl]

Zitat:

Zitat von mkinzler (Beitrag 1402683)

Ubuntu 16 basiert auf Debian Stretch ( Version 9)

Ja, eben "basiert". Wer weiß schon genau, was dann doch anders ist. Die Debian Linuxe sind zwar angeblich sehr stabil, aber deswegen immer ein wenig (oder mehr) älter und haben eben nicht die aktuellen Features an Bord.

[jobo]

Ich glaube, Debian hat strengere Bestimmungen, was die Einbindung 'nicht freier' Pakete angeht.
Ubuntu weniger und damit kommt es "lockerer" daher, schon bei der Hardware-Treiber Anbindung usw.
Aber wie immer bei Linux, bindet man andere Paketquellen ein, kommt man häufig doch zum Ziel (oder in Teufelsküche-wenn man nicht weiß was man tut), spätestens bei Distributionsupgrades etc.. Die widerum will man mit einer "eingefrorenen" Entwicklungsumgebung aber vielleicht gar nicht. Am besten alles per VM mit Snapshots, ..
So oder so, ich würde aus verschiedenen Gründen jeweils die aktuelle Version verwenden, also heute z.B. nicht Debian 8, sondern 9.

[MichaelT]

Debian sind eher pingelig was unfreie Pakete angeht.

Debian hat lange, weiß nicht ob sie das noch immer tun, die Neuerungen in der stdlibc sehr vorsichtig unter die Leute gebracht. Mit der steht und fällt alles.

Zitat:

Zitat von jobo (Beitrag 1402687)

Ich glaube, Debian hat strengere Bestimmungen, was die Einbindung 'nicht freier' Pakete angeht.