[foobar]

Also ob Linux das bessere Windows ist, ist fraglich.

Deshalb auch das „nicht” in meiner Aussage.

Man darf halt nicht erwarten, dass man ein OS kriegt, das wie Windows ist – nur ohne die Nerverei von MS und ohne Spionage und so weiter.

Ich würde den umstieg von Linux zu Windwos als deutlich einfacher betrachten als von WIndows zu Linux.

Das liegt daran, dass du Windows gewohnt bist und es deshalb als einfacher ansiehst. Tatsächlich gibt es Untersuchungen von Leuten, die zu Windows wechseln und dort ähnliche Schwierigkeiten haben. Egal, von welchem OS sie kommen, sie regen sich darüber auf, dass das alles unter dem System, das sie gewohnt waren, aber viel einfacher ging.

[Foodin]

Deshalb auch das „nicht” in meiner Aussage.

Man darf halt nicht erwarten, dass man ein OS kriegt, das wie Windows ist – nur ohne die Nerverei von MS und ohne Spionage und so weiter.



Das liegt daran, dass du Windows gewohnt bist und es deshalb als einfacher ansiehst. Tatsächlich gibt es Untersuchungen von Leuten, die zu Windows wechseln und dort ähnliche Schwierigkeiten haben. Egal, von welchem OS sie kommen, sie regen sich darüber auf, dass das alles unter dem System, das sie gewohnt waren, aber viel einfacher ging.

aber bei windows läuft ja deutlich mehr, ohne das man handanlegen muss. Veile hürden die man bei linux hat, die hat man bei windwos überhaupt gar nicht. Ich mach an und selbst die soundkarte wird ohne hersteller treiber ausgeführt.

BSP: Nevdia treiber nimmt linux auch nicht einfach so. Da muss ich jetzt auch erst mal noch was dazu holen. Beiwindows wäre die sche ohne groß nachzudenken erlegbar.

[foobar]

aber bei windows läuft ja deutlich mehr, ohne das man handanlegen muss.

Das ist sehr unterschiedlich. Beispielsweise bringt Linux viele Treiber bereits mit, während man sie unter Windows erstmal suchen, herunterladen und installieren muss. Klemmen kann es natürlich immer mal.

Dass du z.B. keinen Sound hattest, ist eine klare Ausnahme. Bei mir ist es genau umgekehrt: Meine Soundkarte läuft unter Linux einfach so, ohne irgendwelche Nacharbeiten. Aber unter Windows bleibt sie stumm, solange ich keine Treiber installiere. Welche übrigens schwer zu finden sind, weil der Hersteller keine Lust mehr hat. Der einzige offizielle Windows 10 Treiber für meine Karte ist eine Betaversion von 2015. Für Windows 11 gibt es gar nix.

Und auch normale Anwendungssoftware lässt sich bequem über die Paketverwaltung installieren (und aktuell halten!), anstatt dass man jedes Programm einzeln kaufen bzw. herunterladen und von Hand installieren muss. Und wo dann jedes Programm seinen eigenen Updater mitbringt, von denen jeder anders zu bedienen ist und zu einer anderen (und natürlich immer unpassenden) Zeit zu quengeln anfängt. Die Paketverwaltung aktualisiert alles einheitlich und bequem in einem Rutsch.

BSP: Nevdia treiber nimmt linux auch nicht einfach so. Da muss ich jetzt auch erst mal noch was dazu holen. Beiwindows wäre die sche ohne groß nachzudenken erlegbar.

Bei vielen Distris kann man die NVidia-Treiber auch einfach über die Paketverwaltung (alternativ die Treiberverwaltung) nachinstallieren. Der Grund, warum man das manuell anstoßen muss, liegt in der Tatsache begründet, dass die offiziellen NVidia-Treiber nicht Open Source sind.

Bis vor Win10 musste man auch unter Windows die Treiber manuell laden und installieren. Erst seit Win10 installiert Windows Update manche (aber nicht alle) Treiber automatisch, doch selbst hier ist Linux eigentlich im Vorteil. Denn man kann sich aussuchen, welche Version man haben möchte. Windows installiert immer die Version, von der MS meint, sie wäre die passende. Bei Linux darf man selbst entscheiden, welche Version den besten Support liefert. Bei mir sieht es zum Beispiel so aus.

Wie oft sieht man alleine hier im Forum (geschweige denn im ganzen Web) Leute darüber lamentieren, dass Windows Update ihnen ungefragt und automatisch irgendwelche Treiber reinklatscht, die dann nicht richtig funktionieren? Und wo dann dieser Trick mal ging, aber nun nicht mehr. Und dann jener Tipp erfolglos bleibt und anschließend verzweifelt alles abgeschaltet werden muss, damit das Elend ein Ende hat?

[Foodin]

ok kannst da gut recht haben. Ich habe es ggf. zu oberflächlich betrachtet. der termin war wohl doch um 12. alles geklappt. Puh. Laptop hat gesavet, gut das ich den habe, da ohne wäre es nicht gut gegangen.

Laptop ist auch wieder keine gurke mehr. War wohl zu viel Schadsoftware oder so drauf. zumindest könnte ich es mir nicht anders erklären, weil ich bei Desktop nie so einen gurkenmodus hatte und der laptop jetzt nicht so schwach ist. (quadcore ohne stromsparversion, 8gb RAM dezidierte GPU mit 1GB VRAM).
Ich hatte den ja eh nur für die ausbildung geholt gehabt und genutzt gehabt. Das waren zeiten, in der berufsschule gezockt

[jabu]

Wie oft sieht man alleine hier im Forum (geschweige denn im ganzen Web) Leute darüber lamentieren, dass Windows Update ihnen ungefragt und automatisch irgendwelche Treiber reinklatscht, die dann nicht richtig funktionieren? Und wo dann dieser Trick mal ging, aber nun nicht mehr. Und dann jener Tipp erfolglos bleibt und anschließend verzweifelt alles abgeschaltet werden muss, damit das Elend ein Ende hat?

So ist es. Man hat sich als Windows-Benutzer über die Jahre hinweg so viele fummelige Tricks angeeignet und die so internalisiert (in einem mit viel Zeitverschwendung einhergehenden Lernprozess), dass man irgendwann gar nicht mehr merkt, wie nervig und anstrengend das mal war, bevor man es so internalisiert hatte.

Ich ertappe mich mittlerweile fast regelmäßig dabei, dass ich auf einfachste Fragen im Forum zu Windows spontan keine Antwort geben kann und die Probleme, die die User haben, nicht mehr kenne, da ich von vornherein alles günstig durchkonfiguriere. Seit ich Windows nur noch für mich selber konfigurieren muss, muss ich nichts mehr spontan beantworten können. Wenn Fragen im Forum aufschlagen, muss ich mich erst mal fragen: "Wie war das noch mal?" Dabei merke ich, wie umständlich so manches ist.

Bei meinem Eigengebrauch merke ich es wegen der Verbindung aus Erfahrung und Faulheit*, die dazu führt, dass ich Probleme präventiv wegschaffe (und mir erstaunlich wenige Gedanken mache), dagegen meistens nicht. Aber wie lange hat es gedauert, und wieviele Nächte hat es mich gekostet? Zu lange bzw. zu viele. Das wird gerne vergessen, nachdem man es hinter sich hat.

*Diese Faulheit ist natürlich als Kompensation für vergangene Bemühungen und Schmerzen zu verstehen und daher sozusagen verdient. Wenn man nicht irgendwann "faul" werden kann, läuft was falsch. Für meinen Geschmack könnte gerne noch mehr Faulheit drin sein, denn sich mit anderem beschäftigen zu können, ist doch Zweck von Automatisierung. Und darin brilliert Windows gerade nicht, da es einen mit seinem autoritären Eigenleben doch immer wieder mal zum Eingreifen zwingt (verschwindet nicht ganz, auch nachdem man es im sinnvollen Rahmen präventiv minimiert hat).

[Xarthor]

Der Umstieg von Linux auf Windows kann deshalb einfacher sein, weil Open Source Programme oft auch auf Windows angepasst werden. Kann man bei Closed Source halt nicht machen - oder zumindest nicht so einfach. Damit ist der vermeintlich einfachere Umstieg ebenfalls Linux gutzuschreiben.

[jabu]

Der Umstieg von Linux auf Windows kann deshalb einfacher sein, weil Open Source Programme oft auch auf Windows angepasst werden. Kann man bei Closed Source halt nicht machen - oder zumindest nicht so einfach. Damit ist der vermeintlich einfachere Umstieg ebenfalls Linux gutzuschreiben.

Bei Closed Source geht das übrigens auch gut. Man muss dann "bloß" u.U. Lizenzgebühren bezahlen, z.B. für ein komplexes GUI-Framework. In anderen Fällen darf man bestimmten Code nicht verwenden und muss sich nach Alternativen umgucken, z.B. Code, der unter der MIT-Lizenz steht. Auch dabei ist das Betriebssystem an sich irrelevant.

Der Hauptgrund, warum weniger von Windows zu Linux portiert wird als andersherum, ist einer Strategie von Microsoft geschuldet, die darin besteht, Entwickler mit proprietären oder eng mit Windows verbundenen Programmierwerkzeugen und Frameworks zu verführen (grob gesagt, die C#/CLI/.NET-Schiene). Aufgrund ihrer hohen Produktivität und geringen Einstiegshürden sind sie so verführerisch. Später kommen nicht mal mehr alte Hasen davon weg. Der Kram ist nicht oder nur teilweise mit realistischem Aufwand zu Linux portierbar.

Dabei ließe sich das leicht aufknacken, wenn es zu C++ (also erst mal kein C#/CLI/.NET) ein kostenloses plattformübergreifendes GUI-Framework mit ungefähr dem halben Umfang wie Qt geben würde (Konzentration auf das Wesentliche). Den Rest um das nackte C++ herum erledigen schon lange größtenteils die Boost-Libs. Qt kliegt KDE zugrunde, ist aber nicht immer kostenlos verwendbar. Qt hat ein zwittriges Lizenzmodell, welches über die GPL-Variante ein süßes Gift für GNU/Linux ist. Für kleine Entwickler, die voll haften und von ihrer Arbeit leben müssen, ist die kommerzielle Lizenz von Qt über eine Knebeligkeit mit großen finanziellen Gefahren verbunden, die leicht dazu führen können, dass ein Entwickler verarmt oder sich verschulden muss. Also bleiben die häufig lieber bei Microsoft, wo die Lizenzmodelle für kleine Entwickler weitaus risikoärmer gestaltet sind. Deswegen ist Qt sozusagen ein Element von Co-Abhängigkeit.

Freiheit bekommen wir erst, wenn es einen guten Ersatz für Qt gibt. Das wird aber nicht so leicht passieren, da die kommerzielle Lizenz von Qt gut zu großen Fimen passt.

Wer eher mit C#/CLI/.NET und Windows vertraut ist, müsste sich nicht grämen, da er nach Erringen der Freiheit das neue GUI-Framework, wenn es erst mal da ist, auch von dort aus aufrufen könnte. Es würden zur Erleichterung dessen schnell Bindings entstehen.

Die C++-Community ist sich durchaus bewusst, dass das Hauptproblem im fehlenden freien GUI-Framework liegt, insbesondere was die Attraktivität für Einsteiger anbelangt. Es kommt auf Konferenzen immer wieder mal zur Sprache. Aber ohne Moos nix los. In den Sprachstandard gehört das nicht hinein, aber begleitend wäre es gut.

[foobar]

wenn es zu C++ [...] ein kostenloses plattformübergreifendes GUI-Framework mit ungefähr dem halben Umfang wie Qt geben würde
[...]
Freiheit bekommen wir erst, wenn es einen guten Ersatz für Qt gibt. Das wird aber nicht so leicht passieren, da die kommerzielle Lizenz von Qt gut zu großen Fimen passt.

Wobei es durchaus plattformunabhängige Alternativen zu Qt gibt. wxWidgets, U++, FLTK, gtkmm – um nur ein paar zu nennen. Der bekannte Audio-Editor Audacity beispielsweise setzt auf wxWidgets. Ob der Umfang jetzt genau die Hälfte von Qt ist...

[jabu]

Wobei es durchaus plattformunabhängige Alternativen zu Qt gibt. wxWidgets, U++, FLTK, gtkmm – um nur ein paar zu nennen. Der bekannte Audio-Editor Audacity beispielsweise setzt auf wxWidgets. Ob der Umfang jetzt genau die Hälfte von Qt ist...

Richtig, ist mir bekannt, und mit wxWidgets habe ich auch schon etwas gemacht. Sogar U++ habe ich schon probiert. Mir persönlich genügt meistens, was die bieten - anderen aber nicht, und da liegt der Hase im Pfeffer.

Das ist z.B. so neumoderner Kram, wo man einen Browser mit einbetten will. Als ich zuletzt für eine umfangreichere Idee wxWidgets verwendete, musste ich den IE einbetten, weil wxWidgets für Windows nichts anderes konnte. Das war so gruselig, dass man freiwillig davon Abstand nimmt. Das mag heute vielleicht anders aussehen (müsste mal recherchieren), war aber bis vor kurzem noch so. Der heutige Edge ist sicher auch nicht die erste Wahl, aber es wäre ressourcenschonend, den zu nehmen. Aber dann diktiert der wieder, was geht und was nicht und wie es geht.

Das ist eben der Kram, den viele andere Leute brauchen. Und dann gehen sie (leider!) weg von wxWidgets und hin zu Qt. Auch bei Forks von Audacity wurde diskutiert, zu Qt wechseln zu wollen (vielleicht kannst du dich erinnern, ich wurschtelte mich da mal rein), weil das moderner sei und mehr böte.

Also nein, wxWidgets kommt leider nicht auf die Hälfte von Qt (obwohl es mir sympathisch ist, aber das hilft leider nicht, damit sich das durchsetzt). Das war von mir natürlich stark vereinfacht ausgedrückt, da ich nicht so viele Fässer aufmachen wollte, aber schon weiß, woran es hakt. Leute, die Qt erlernen, haben damit etwas an der Hand, womit sie fast alles machen können. Dann wollen viele von ihnen nie wieder zurück. Die Sogwirkung ist extrem. Qt ist zu mächtig. Sprachlokalisierung mit Qt ist ein Klacks, verglichen mit vielen anderen Frameworks (etc.). Edit: Die Performance ist oft woanders besser.

[Xarthor]

Bei Closed Source geht das übrigens auch gut. Man muss dann "bloß" u.U. Lizenzgebühren bezahlen, z.B. für ein komplexes GUI-Framework. In anderen Fällen darf man bestimmten Code nicht verwenden und muss sich nach Alternativen umgucken, z.B. Code, der unter der MIT-Lizenz steht. Auch dabei ist das Betriebssystem an sich irrelevant.

Mein Punkt ist eher, dass du die freie Software von Linux oft auch auf Windows findest und dort weiterverwenden kannst. Auf Windows kostet ähnliche Software, die nicht von Linux portiert wurde, oft Geld, ist proprietär und wenn man sie nutzt, muss man sich bei einem Umstieg zu Linux auch an neue Programme für die selben Aufgaben gewöhnen.

Das OS mag zwar erstmal irrelevant sein, aber die jeweiligen Systeme ziehen bestimmte Lizenzmodelle an (oft GPL bei Linux) und wenn der Hauptentwickler da nichts an andere Systeme anpassen will, können es in dem Fall andere Leute machen. Bei proprietären Programmen geht das nicht so einfach und wird deshalb oft nur über solche Workarounds gemacht, wie man sie z.B. von WINE kennt (um mal ein bekanntes Beispiel zu nennen). Wie gut es am Ende funktioniert ist dann fraglich. Also ist das OS zumindest indirekt relevant.

[jabu]

Mein Punkt ist eher, dass du die freie Software von Linux oft auch auf Windows findest und dort weiterverwenden kannst. Auf Windows kostet ähnliche Software, die nicht von Linux portiert wurde, oft Geld, ist proprietär und wenn man sie nutzt, muss man sich bei einem Umstieg zu Linux auch an neue Programme für die selben Aufgaben gewöhnen.

Das OS mag zwar erstmal irrelevant sein, aber die jeweiligen Systeme ziehen bestimmte Lizenzmodelle an (oft GPL bei Linux) und wenn der Hauptentwickler da nichts an andere Systeme anpassen will, können es in dem Fall andere Leute machen. Bei proprietären Programmen geht das nicht so einfach und wird deshalb oft nur über solche Workarounds gemacht, wie man sie z.B. von WINE kennt (um mal ein bekanntes Beispiel zu nennen). Wie gut es am Ende funktioniert ist dann fraglich. Also ist das OS zumindest indirekt relevant.

Wir sind da nicht weit voneinander weg (z.B. indirekte Relevanz ist klar). Mir ging es um die Gründe, warum das immer noch so aussieht und wie man es ändern könnte. Oft wird eine Zwangsläufigkeit unterstellt, die nicht so da ist und eher etwas mit Strategie, Marktgeschehen und Vormacht als mit den Systemen an sich zu tun hat. Indem man das aufknackt, könnte man Microsoft den Hebel nehmen.

Würde von einem Tag auf den anderen Qt kostenlos wie Freibier werden oder einen entsprechenden Gegenspieler bekommen, so würde etwas stark ins Wanken geraten. Microsoft Visual Studio würde nicht mehr so oft zum Erstellen von Software auf der Grundlage von spezifischen Microsoft-Technologien und von manchen Entwicklern gar nicht mehr verwendet werden, da es den Qt Creator gibt, der auch nicht schlecht ist. Das nur mal zum Beispiel, wie es laufen könnte.

Ein anderes Beispiel wäre die Erweiterung von wxWidgets auf ein gewisses Mindestlevel, sodass man damit fast alles machen kann (wie bei Qt). Womit startest du dann deine Projekte unter Visual Studio? Doch wohl eher mit wxWidgets als mit Microsoft-Kram, da das später leicht portiert werden kann.

Wenn alles in alle Richtungen geht, dann besteht der Wettbewerb wieder zwischen den Betriebssystemen an sich, wo Microsoft leicht den Kürzeren ziehen könnte. Die Frage bei solchen Sachen ist immer, wie man zur kritischen Masse kommt. Keiner opfert sich gerne, indem er den Anfang macht und dafür in die Insolvenz schlittert.

Edit:
Das Kritischste ist doch das Lernen. Auf welches Pferd sollte man setzen? Lange war C#/CLI/.NET beinahe einzig zum Sichern des Lebensunterhaltes von Entwicklern geeignete Toolset. Auf eine Stelle für C++ kommen (Embedded ausgenommen) zig für C#/.NET. Und damit hat Microsoft leider gewonnen! Eine Ausnahme bildet Embedded, aber das passt nicht in diesen Vergleich hinein. Mit C und C++, was bei Linux gerne verwendet wird, gehste auf'm Desktop ins Armenhaus. So langsam bessert sich das etwas, ist aber vom Embedded-Aufschwung herübergeschwappt und genügt längst nicht. Spiele-Engines, wo C++ seinen Platz hat, sind eine Nische, mit deren Entwicklung nicht viele Leute ihr Brot verdienen können.

[Xarthor]

Ich habe zu dem Anderen nichts gesagt, weil ich da nichts hinzuzufügen oder kritisieren hatte (zumal du dich da auch besser auskennen dürftest als ich). Daher wollte ich nur nochmal etwas näher ausführen, warum ich das so geschrieben habe. Ich wusste übrigens auch nicht, dass Qt so problembehaftet ist ... zumindest was Lizenzen betrifft. Von daher auch nochmal danke für die Aufklärung.

Am Ende ist es aber auch wie foobar schon sagte: der Umstieg ist von jedem zu jeden System schwierig. Wie ein Anfänger habe ich mich damals nicht gefühlt, als ich zu Linux gewechselt bin, aber es war schon so man sich Vieles neu erarbeiten musste. Das ist übrigens auch einer der Gründe, warum ich aufs Librem 5 warte - da ich jetzt eine längere "Linuxpause" hatte, wird das mein "softer Einstieg", damit ich dann vor Win11 auch mit dem PC problemlos wechseln kann. Diesbezüglich fand ich übrigens ein Preview witzig, bei dem derjenige schrieb, dass er nach 2 Jahren Nutzung endlich Andbox nutzen konnte (damit laufen Android Apps mehr oder weniger) und dann gar nicht mehr wusste, was er damit soll. Mit der Zeit gewöhnt man sich halt auch so sehr an die Systeme, dass man die anderen Dinge gar nicht mehr unbedingt braucht.

[jabu]

Ja, mit Qt ist das so eine Sache. Erst mal kannst du damit unter bestimmten Bedingungen kostenlos anfangen. Ich muss mich etwas korrigieren, das Lizenzmodell ist nicht nur zwittrig, es ist noch komplizierter (gut gemeint, schlecht gemacht), würde aber wieder ein Fass aufmachen...

Aber wenn du damit deine Brötchen verdienen willst, und zwar nicht mit Gefrickel, wo du die unveränderten fetten DLLs beim Kunden auskippst, sondern mit gutqualitativer Software, dann bist du plötzlich mit einem Lizenzmodell konfrontiert, wo du blechen musst. Das ist auch legitim. Aber du musst blechen, solange du die Software verbreitest und zwar auch dann, wenn längst kein Geld mehr damit verdient wird. Hast du die Kontrolle über die Verbreitung verloren, musst du unter einigen Umständen blechen. Lieferst du, wie es sich gehört, jahrelangen Support, auch wenn du nichts mehr damit verdienst, musst du weiterblechen. Das ist übrigens ein häufiger Grund, weswegen plötzlich Support wegfällt.

Ich bin da vielleicht mehr als üblich strategiefixiert. Das dürfte daran liegen, dass ich früher mal eine ganze Reihe an Technologien und Frameworks auf ihre Tauglichkeit für meine Zwecke hin evaluiert habe, immer brav mit der Hoffnung, später zu Linux portieren zu können. Wirklich nichts davon war tauglich. Es gab immer irgendeine Kröte zu schlucken. Bei solchen Frameworks ist ein Problem, dass man nicht mal eben beliebige fehlende Bestandteile integrieren kann. Es muss zu viel korrekt ineinandergreifen, z.B. für diverse Events, Resizing, Rendering etc. Das ähnelt einem kleinen Betriebssystem.

Die kleinste zu schluckende Kröte ist leider häufig, auf Linux zu verzichten und das fette .NET-Framework, mit dem man fast alles machen kann, zu nutzen. Qt kann man ungefähr (nicht hundertprozentig rein) als einen C++-Gegenspieler dazu ansehen. Es gibt nur diese beiden großen Lösungen. Alles andere kommt mit einem riesigen Abstand, ausgenommen vielleicht noch die Lösungen von Embarcadero (geht auf Borland zurück), aber die kannst und willst du nicht bezahlen, wenn du als Normalsterblicher mit irgendwas anfangen musst. Dafür ist das Risiko einfach zu groß.

[foobar]

Ich wusste übrigens auch nicht, dass Qt so problembehaftet ist ... zumindest was Lizenzen betrifft.

Wobei das Problem mit Qt halt nur die klassische unfreie Verwertung betrifft. jabu hatte das ja bereits angesprochen. Solange man seine Software auch wieder als (L)GPL veröffentlicht, kann man auch die GPL-Lizenz von Qt wählen. Und das durchaus auch kommerziell verwerten. Auch GPL-Software darf verkauft oder anderweitig kommerzialisiert werden.

Abgeschreckt werden hingegen Entwickler, die ihren Programmcode geheim halten und dem Nutzer das Ändern des Programmcodes (und die Weitergabe dieser Änderungen) untersagen wollen.

Wobei es natürlich dennoch möglich ist, plattformübergreifende, kommerzielle, unfreie Software zu entwickeln und an den Mann zu bringen. Bitwig Studio wäre ein Beispiel. Die Berliner Entwickler hatten den Vorteil, bei Null anzufangen und konnten die Plattformunabhängigkeit von Anfang an ins Konzept einbeziehen. Und es scheint zu funktionieren. Die mussten halt keinen jahrelang nur für Windows entwickelten, mit Altlasten versehenen Code mühsam portieren und dann in der Folge zwei getrennte Entwicklungsstränge pflegen.

Die Softmaker GmbH aus Nürnberg bietet ihr Office-Paket ebenfalls mit scheinbarem Erfolg an. Dito für PDF Studio von Qoppa aus den USA.

Die vielen Spiele auf Steam ignorieren wir mal, da die GUI dort in der Regel nicht mit Desktop-Software vergleichbar ist.

[Zankro]

Also derzeit bin ich zufrieden mit meiner 7900xtx, meine alte 3080 für ca 620 € weiter verkauft daher 80 € verloren.

Nur ging das Geld direkt für mein Auto wieder drauf, Bremsklötze und Bremsen hinüber

[jabu]

Wobei das Problem mit Qt halt nur die klassische unfreie Verwertung betrifft. jabu hatte das ja bereits angesprochen. Solange man seine Software auch wieder als (L)GPL veröffentlicht, kann man auch die GPL-Lizenz von Qt wählen. Und das durchaus auch kommerziell verwerten. Auch GPL-Software darf verkauft oder anderweitig kommerzialisiert werden.

Abgeschreckt werden hingegen Entwickler, die ihren Programmcode geheim halten und dem Nutzer das Ändern des Programmcodes (und die Weitergabe dieser Änderungen) untersagen wollen.

Das klingt für mich fast wie Boshaftigkeit oder Dummheit als Motiv für Closed Source. Für kleine Entwickler, die sich kein Klagen vor Gerichten leisten können, ist es aber eine Frage der blanken Existenz, sich nicht die jahrelangen Mühen wegnehmen zu lassen, z.B. durch unerlaubte Forks, denen man das vielleicht nicht auf den ersten Blick ansieht, z.B. weil diese nicht quelltextoffen sind.

Wobei es natürlich dennoch möglich ist, plattformübergreifende, kommerzielle, unfreie Software zu entwickeln und an den Mann zu bringen.

Sicher ist es möglich, aber nicht unbedingt im konkreten individuellen Fall. Welche Features du brauchen wirst, weißt du nicht vorher. Mit dem Survivorship Bias, den wir hier bei deinen Beispielen unvermeidbar mit im Gepäck haben, sind ja schon diejenigen Fälle aussortiert, wo die Konstellation weniger glücklich ist, z.B. indem Zweigleisigkeit (z.B. aufgrund spezifischer Anforderungen des Projektes) zu aufwändig wurde und eingestellt werden musste oder wo von vornherein plattformspezifische Werkzeuge eingesetzt wurden. Alle Fälle kompletten Scheiterns fehlen ebenfalls, darunter auch solche, wo man sich das Leben hätte leichter machen können, anstatt nobel zugrundezugehen. Man sieht auf den ersten Blick nicht, wo bei denen doch eine Qt-Lizenz erworben wurde, z.B. weil jemand das Risiko nicht scheute oder weil von vornherein klar war, dass die Entwicklertätigkeit auf der Basis immer so weiterlaufen würde, sodass absehbar war, dass es sich lohnt. Unter anderen (eigenen, individuellen) Umständen, wäre das nicht unbedingt glattgegangen, weswegen es schon zur Risikovermeidung nicht zustandegekommen wäre.

Jedes Projekt und jede Festlegung auf Werkzeuge ist eine Wette auf die Zukunft, mal größer, mal kleiner. Man wird gezwungenermaßen zum Spieler. Vor dem Hintergrund meinte ich das.

Ich hoffe, dass ich nicht falsch verstanden werde. Ich plädiere keinesfalls gegen plattformübergreifende Lösungen. Ferner weiß ich auch, dass man z.B. mit OpenGL oder mit plattformübergreifenden Wrappern dafür oder etwas komplexerem Gedöns auf der Basis viel machen kann, z.B. komplette GUIs. Aber damit ist man schon darauf festgelegt, dass man gewisse größere Aufwände durchziehen muss, auch wo schon viel vorgefertigt ist. Es ist auch eine allgemeine Anforderung, ob man ein Werkzeug an der Hand hat, das auch kurzfristig geänderten oder erst später entdeckten Anforderungen entsprechen kann und ferner, dass man damit möglichst wenig Bugs fabriziert.

Es ist nicht gesagt, dass man (wenn man viel selber machen muss) ein über Jahre hinweg aufwändig erstelltes Eigengewächs wiederverwenden kann. Es hat recht wahrscheinlich für andere Fälle viel zu wenig zu bieten, da sie sehr verschieden sein können. Es ist ein Glücksfall, wenn jemand immer an seinem "Baby" dranbleiben und das immer weiter ausbauen und verbessern kann. Sicher hat es manchmal auch etwas mit Strategie zu tun, aber das Leben führt schnell mal woanders hin, ohne dass man es steuern könnte. Dort, wo das "Baby" schön weitergepflegt werden konnte, hat man es automatisch im Survivorship Bias mit drin.

Einem x-beliebigen anderen Entwickler ergeht es anders. Er hat jahrelang ein Pferd gefüttert und braucht plötzlich ein Schaf, wobei der Stall und die Fütterungsanlage bleiben dürfen und die den Job bestechend gut machen. Ein fettes Framework kann es bieten. Weil Leute das ahnen oder Arbeitgeber schon ihre Erfahrungen damit haben und bestimmte fette Frameworks viel öfter als andere fordern, setzen sie darauf.

Mir widerstrebt diese opportunistische Denkweise (wobei sie manchmal doch klug ist), und ich mag fette Frameworks manchmal nicht, z.B. wenn sie einen in etwas hineinzwängen, wo man selber nur noch schwer qualitative Mängel fixen kann, z.B. beim Timing. Für den Anfang ist es gut, aber wenn es richtig gut werden soll, dürfte manchmal gefühlt kein Stein auf dem anderen bleiben.

[foobar]

Das klingt für mich fast wie Boshaftigkeit oder Dummheit als Motiv für Closed Source. Für kleine Entwickler, die sich kein Klagen vor Gerichten leisten können, ist es aber eine Frage der blanken Existenz, sich nicht die jahrelangen Mühen wegnehmen zu lassen, z.B. durch unerlaubte Forks, denen man das vielleicht nicht auf den ersten Blick ansieht, z.B. weil diese nicht quelltextoffen sind.

Wie alles im Leben hat die Sache natürlich zwei Seiten. Ich kann verstehen, dass ein kleiner Entwickler Angst um seine Existenzgrundlage (den Code) hat. Auf der anderen Seite kann man aber auch fragen, wie begründet diese Angst denn tatsächlich ist. Denn gerade für kleine Firmen oder Einzelentwickler ist Open Source auch ein Verkaufsargument.

Software hat immer einen Lock-In-Effekt. Der Nutzer steckt viel Zeit und Geld hinein, hat seine Daten darin hinterlegt, ggf. interne Dokumentation und Schulungen dazu erstellt, etc. Müsste er die Software wechseln, wäre das alles neu zu machen. Was mitunter ein Vielfaches der eigentlichen Lizenzgebühren kosten kann. Also möchte er ein Produkt, von dem er sicher sein kann, dass es ihn langfristig begleitet. Kommt die Software von einem Einzelentwickler, dann hängt alles an dieser einen Person, die damit zu einem Single-Point-Of-Failure wird. Passiert dem etwas oder verliert er die Lust oder geht in Rente, dann wird’s teuer.

Absolute Garantien gibt es nie, aber bei Großkonzernen wie Microsoft oder Adobe kann man relativ sicher sein, dass es schon irgendwie weiter gehen wird mit der Software (und wenn es über ein nerviges Abo-Modell ist). Aber bei Einzelkämpfern kann mit einem Schlag alles zu Ende sein. Ist die Software aber Open Source, kann ich selbst bei einem Einzelentwickler (oder einer kleinen Softwareklitsche) sicher sein, dass ich am Ende nicht im Regen stehe. Denn ich habe das unwiderrufliche Recht, mir selbst zu helfen, mich mit Leidensgenossen zusammen zu tun oder andere Programmierer für die Weiterpflege zu bezahlen. Das ist sogar besser als proprietäre Software von einem Megakonzern (siehe Abo-Modell)!

Dadurch minimiert sich das Risiko, was insbesondere für Leute interessant ist, die mit der Software ihrerseits Geld verdienen wollen (Firmen, Gewerbetreibende, etc). Und gerade das sind die Kunden, die am ehesten bereit sind, auch für Lösungen zu bezahlen. Wenn Zeit Geld ist, dann sagt man sich: „Ja, wir könnten die Software selbst kompilieren und einrichten und unsere Leute schulen. Oder wir geben einfach dem Entwickler einen Batzen Geld, damit er uns alles schlüsselfertig einrichtet und wir gehen in der Zwischenzeit Geld verdienen.”
Die wollen nicht nur eine Software, sondern auch den Support und einen Ansprechpartner, der bei Problemen schnell reagiert (Zeit = Geld). Selbst, wenn es einen Fork gäbe: Der eigentliche Entwickler kennt die Software am besten und kann am ehesten Support geben.

Solange der Fork nicht besser ist als die ursprüngliche Software, gibt es keinen Grund, dorthin zu wechseln. Ist er besser, funktioniert das Copyleft der GPL auch zu den eigenen Gunsten: Dann kann man die Verbesserungen kostenlos übernehmen und in die Ursprungssoftware einbinden. Und schon ist der Fork wieder nicht besser.

Und das sieht man auch in der Realität. Die meisten Forks verkümmern ohne großes Interesse. Erfolgreiche Forks sieht man eigentlich nur dann, wenn es irgendwelche Probleme mit dem ursprünglichen Entwickler gibt.

Open Source ist also für den Nutzer ein Kaufgrund und hilft kleinen Entwicklern, sich am Markt gegen die Großen durchzusetzen.

[jabu]

Wie alles im Leben hat die Sache natürlich zwei Seiten. Ich kann verstehen, dass ein kleiner Entwickler Angst um seine Existenzgrundlage (den Code) hat. Auf der anderen Seite kann man aber auch fragen, wie begründet diese Angst denn tatsächlich ist. Denn gerade für kleine Firmen oder Einzelentwickler ist Open Source auch ein Verkaufsargument.

Es kommt natürlich auf das Produkt und den Kunden an. Wer das Glück hat, Produktivsoftware für einen bestimmten, bereits gesicherten, Kundenkreises, der gut zahlt, entwickeln zu dürfen, den muss es i.d.R. nicht stören, wenn Firmen "in Timbuktu" die (illegal) kostenlos benutzen können. Mit denen würde man sowieso keine Verträge machen, und die eigene Software würde denen nicht einen so großen Durchbruch in der Produktivität bescheren, dass dadurch Konkurrenz gegenüber dem eigenen Kunden entstehen könnte. Das ist also dieses traditionelle Brot- und Buttergeschäft mit Mittelständlern, die noch so klein sind, dass sie nicht woanders hingehen, aber schon so groß sind, dass sich für sie Entwicklung einer spezifischen Software lohnt. Bei diesen wenigen Kunden muss man den Quelltext nicht am Marktplatz aushängen, und er gelangt auch nicht so leicht dorthin, obwohl grundsätzlich jeder hineingucken darf. Und wenn er dort angelangt ist, dann ist nicht gleich ersichtlich, was man davon hätte. Womöglich passt das in einem anderen Unternehmen nicht so gut, und erklärungsbedüftig ist das Produkt auch noch. Dort funktioniert ziemlich gut, was du sagtest.

Leider ist dieser Bereich besonders hart umkämpft. Ohne Vitamin B und ohne Kenntnis der Prozesse kommt man da als einzelner Entwickler nicht rein, auch weil Überforderung erwartet wird. Um wieder den Survivorship Bias zu bemühen: Die meisten Entwickler, die solche Unternehmen begleiten (was wie eine Widerlegung aussähe), haben sich auch vorher schon in dem Umfeld oder in einem sehr ähnlichen Umfeld bewegt. Sie kennen die Prozesse. Nicht selten handelt es sich um ehemalige Beschäftigte dieser Unternehmen. Damit haben sie ein Aushängeschild, mit dem sie den nächsten Kunden beeindrucken können usw., falls es mal nötig sein sollte. Das Henne-Ei-Problem bekommt ein einzelner Entwickler kaum aufgeknackt. "Der Klaus hat es auch geschafft" wäre also kein Argument.

Also sind andere Betätigungsfelder nötig. Das betrifft z.B. Fälle, bei denen die Software nicht gleich Brot bringt, z.B. weil es nicht von Anfang an ein bezahltes Dienstleistungsverhältnis gibt und wobei kein Geld mit Schulungen verdient werden kann, z.B. weil sich darin keine komplexen Unternehmensprozesse widerspiegeln und die Software eher mit Alleinstellung wirkt und die Kunden selber technisch interessiert sind und keine Lehrgänge brauchen und die Software tatsächlich auch nach "Timbuktu" verkauft werden muss, z.B. als Bestandteil einer umfassenderen Produktentwicklung, in die Jahre an Entwicklungszeit geflossen sind und die man nicht plagiiert wissen will, da bei zu geringer Stückzahl das Investment nicht aufgeht.

Man könnte zwar mit dem eigenen Vorsprung argumentieren, aber woanders gibt es mehr Menschen, sodass sie ihn locker überholen könnten, nachdem sie die Nuss geknackt haben. Es ist dann besser, wenn sie den Quelltext nicht haben und das Vorbild mit einer eigenen Entwicklung nachbauen müssen, was einem Zeit gibt, um bis zur nächsten Investitionsrunde nicht das Wasser abgegraben zu bekommen. Start-ups, die sich komplexen Kram mit Alleinstellungsmerkmal ausdenken, brauchen manchmal ein paar Jahre Schutz. Ob man später den Quelltext veröffentlichen möchte, z.B. damit Kunden eigene Anpassungen vornehmen können, kann man immer noch entscheiden.

Die Nachahmer starten schon mit dem Vorteil, dass sie sehen, dass die Idee gut ist. Also können sie viel Personal darauf ansetzen. Mehr Geld oder billigere Kräfte haben immer andere Leute. Also läuft das Team des Plagiators schneller als man selber los. Schenkt man ihm den Quelltext, so kapiert es zu früh, was dem Produkt seine besonderen Eigenschaften verleiht. Das kann auch passieren, wenn es sich z.B. lediglich um eine Software zum Steuern und Überwachen des Hauptteils des Produktes (z.B. eine Maschine) handelt, z.B. indem diese Steuerungssoftware bestimmte Kalkulationen vornimmt, die allgemein nicht üblich sind oder die teils auf der Basis anderer Daten zu erwarten wären. Je komplizierter das Reverse-Engineering beim Plagiator wird, desto länger braucht der, bis er die Kniffe begriffen hat, und so lange hat man Schutz vor zu guten Plagiaten.

Da man von irgendwelchen Leuten Geld einsammeln muss oder bei denen auf der Gehaltsliste steht, bekommen die Zugang zum Quelltext. Die Software ist dann zwar nicht für die Außenwelt quelltextoffen, kann aber überprüft werden und weiterleben. Es kann auch festgelegt und entsprechend dokumentiert werden (bevor es zu spät ist) unter welchen Bedingungen der Quelltext offengelegt wird, z.B. wenn das Projekt zu scheitern droht und schon Einheiten verkauft worden sind. Man kann mit einer Karenzzeit sicherstellen, dass die Veröffentlichung nicht verfrüht geschieht. Man kann den Quelltext dann exklusiv den eigenen Kunden zur Verfügung stellen. Aber ab dem Zeitpunkt ist klar, dass die sich zusammentun können, um einen auszubooten, sodass man nie wieder auf die Füße kommt.

Privatkunden hatte ich vorerst ausgeklammert. Aber die können durchaus interessant sein, da es dabei nicht nötig ist, erst die Unternehmen der Kunden (mitsamt Menschen) kennenzulernen. Man kann im eigenen Kontrollbereich alles schön überschauen und möglichst perfekt machen. Bei Privatkunden ist die Hemmschwelle, sich an illegalen Forks zu bedienen, vergleichsweise gering (da ihnen normalerweise keiner in die Karten guckt und da bei Entdeckung wenig auf dem Spiel stünde), zumal die das meistens gar nicht merken. Der wird dann z.B. maximal für die Hälfte verkauft, geht wunderbar, da weniger Zeit investiert werden musste. Der Mensch dahinter legt den modifizierten Code nicht offen, sodass man davon nichts lernen kann. Ein illegaler Fork führt nicht zwangsläufig dazu, dass man ihm dieses ansieht. Perfektion an der Oberfläche bietet etwas Schutz, da der Plagiator diese teils mit anderen Mitteln umsetzen muss, um sich nicht verdächtig zu machen. Aber wenn er die Idee dahinter begriffen hat, dann würde ich nicht darauf wetten, dass ihm dieses nicht gelingt. Es sei dem Plagiator gegönnt, zu lernen, aber wenn er 3/4 des Unterbaus einfach übernommen hat und lediglich hier und dort mal eine Kleinigkeit ersetzt hat (z.B. verdächtige Aufrufe in externe Libs hinein) und damit durchkommt, dann ist das schon bitter.

[Zankro]

Uuuuund die 7900xtx ist gestorben, produziert Artefakte bei hohen VRAM gebrauch... :/

Immerhin waren das tolle 2 Wochen

[Nobbi Habogs]

Uuuuund die 7900xtx ist gestorben, produziert Artefakte bei hohen VRAM gebrauch... :/

Immerhin waren das tolle 2 Wochen

Naja, du warst ehrenwerter Beta-Tester, ist dir das nichts wert?