Fettarme H-Milch schrieb am 27. April 2014 04:30
> Tamaskan schrieb am 26. April 2014 20:46
>
> > Dann sind die KDE-Entwickler ja auch Trottel, denn schließlich haben
> > die Probleme mit Nepomuk eingeräumt.
> Es gibt einen Unterschied zwischen „ständig schimpfen“ und dem
> Einräumen von Problemen. Keine Software ist ohne Probleme.
Und wenn man über Probleme schimpft, ist man gleich ein Trottel?
> > Es gibt nämlich auch Abhängigkeiten auf
> > Quelltextebene.
>
> Nein.
Natürlich, gibst du doch gleich selber zu.
> > Wenn ich z.B hier auf meinem Fedora mit GNOME "yum
> > install dolphin" ausführe, dann zieht er mir Nepomuk, Strigi und
> > Virtuoso mit rein.
>
> Die Pakete sind mit entsprechenden Flags kopiliert, denn es ist eine
> Compiler-Option. Eine Option ist trotzdem eine Option.
Abgesehen von Gentoo werden Pakete als Binaries ausgeliefert, sodass
der Nutzer eben *nicht* die Wahl hat. Die KDE-Entwickler hätten die
Abhängigkeit auch zur Laufzeit realisieren können.
> > Mit KDE 5 wurde ja nicht umsonst daran gearbeitet,
> > diese Abhängigkeiten zu reduzieren, und das meines Wissens recht
> > erfolgreich.
>
> Es gibt kein KDE 5 und das wird's auch niemals geben.
Ich meine KDE Frameworks 5 und Plasma Workspaces 2. Die gibt es
wirklich:
http://www.heise.de/open/meldung/Plasma-Next-Die-naechste-Generation-der-KDE-Oberflaeche-2162405.html
Ob das jetzt als KDE SC 5.x veröffentlicht wird oder 4.x fortgesetzt
wird, ist komplett irrelevant.
> Wenn du mir massig Probleme des aktuellen (!) Plasma-NM beweist,
> werde ich das einsehen.
Das wird schwer sein, da müssten wir uns physisch treffen und ich
müsste dir das dann vorführen. Alternativ kannst du einfach annehmen,
dass wenn Nutzer schreiben, dass die Probleme mit Software xy haben,
dass diese dann nicht alle lügen.
Ich finde es auch witzig, wie du die das "aktuelle" betonst. Oft höre
ich den Tenor, dass nur ältere KDE-Versionen Bugs haben und in der
neuen alle Probleme behoben wurden, also "KDE 4.y hat diese Probleme
nicht, selbst schuld, wenn du noch KDE 4.x benutzt".
> Du behauptest, dass ein Community-Management freiwilligen
> Hobby-Programmierern vorschreiben könnte, woran sie arbeiten.
> Können sie nicht, da es sich um freiwillige Arbeit handelt.
Nein, das habe ich nicht behauptet. Und mir ist das Problem bekannt
und ich habe das auch schon angedeutet (da, wo du mein Zitat gekürzt
hast). Allerdings könnte KDE auch bezahlte Entwickler anstellen, so
wie GNOME das macht. Anscheinend ist KDE als Enterprise Desktop halt
uninteressant.
> Ändert nichts daran, dass Qt trotzdem im Mobil-Bereich nicht weniger
> Stark als vorher ist.
Da wäre ich skeptisch. Nokia ist jetzt ja von Microsoft geschluckt
worden, und die jetzigen Qt-Plattformen gehören irgendwelchen
Startups, die nicht mit Nokia zu vergleichen sind.
> Android- und iOS-Support seitens Qt ist auch nun dabei. Bähm.
Ach, das war ja das, wo eine Qt-App für Android beim ersten Start
erstmal die ganzen Qt-Libaries aus dem Netz nachladen musste, und wo
es keine nativen Widgets gibt, sodass sich die App wie ein
Fremdkörper anfühlt. Und gerade die iOS-Nutzer legem da extrem Wert
drauf.
Und Qt ist nicht gleich Qt, es gibt auf den jeweiligen Plattformen
spezifische APIs, eine App für Ubuntu Touch läuft nicht einfach auf
BlackBerry.
Da ist es sinnvoller, eine native Android und eine native iOS-App zu
schreiben und du hast alle Plattformen abgedeckt.
> Nicht irrelevanter als Qt nur unter MeeGo und ohne offiziellen
> Android- und iOS-Support.
MeeGo war ja diese Vaporware. Das zu übertreffen ist ja nicht schwer.
> Weniger Bugs.
Mehr, wegen der dynamischen Typisierung. JavaScript erlaubt sogar,
zur Laufzeit Objektstrukturen zu verändern. Ich freu mich schon auf
die lustigen Bugs.
> Wenn die Plasma-Widget-Maintainer sagen, dass die QML-Version
> wartbarer ist, ist sie wartbarer und dein geratenes Gesabbel ändert
> nichts daran.
Die Götter haben gesprochen und meine Reden sind Blasphemie, ich
verstehe (da heißt nicht, dass die QML-Version nicht tatsächlich
wartbarer ist, deine Argumentation ist nur daneben).
> Klar ist Gnome Shell im Classic-Modus ein Rewrite des alten GUIs.
> Erst wurde das Panel von GTK2 auf GTK3 protiert. Dann wurde dieser
> Fallback-Modus weggeschmissen und durch Extensions für Gnome Shell
> ersetzt.
Das war unnötig, ja.
> Rewrite, Konzeptlosigkeit, yaddayaddayadda.
Ich sage ja nicht, dass es bei anderen Projekte keine konzeptionellen
Fehler gibt, bei KDE ist es halt extrem. Und in der Zeit, in der man
irgendwelche Ports und Rewrites durchführt kann man keine Bugs fixen
oder neue Features entwickeln.
Dieses "yaddayaddayadda" solltest du sein lassen, das wirkt ziemlich
kindisch. Auch ein deutsches "blablabla" würde es nicht besser
machen.
> > und hat dann proprietäre
> > Erweiterungen wie z.B Klassen hinzugefügt.
>
> QML ist nicht reines JavaScript.
Nein, QML ist erstmal gar kein JavaScriot, sondern "nur" ein
proprietäres JSON, und Qt Quick insgesamt hat dann seinen eigenen
JavaScript-Dialekt. Ähnlich wie gjs.
> > Glücklicherweise ist der Rest von GNOME immer noch in C, Vala oder
> > Python geschrieben.
>
> Gnome Maps nicht, anderes Zeug auch nicht.
# repoquery --whatrequires gjs
gjs-devel-0:1.38.1-1.fc20.i686
gjs-devel-0:1.38.1-1.fc20.x86_64
gnome-documents-0:3.10.1-1.fc20.x86_64
gnome-documents-0:3.10.2-1.fc20.x86_64
gnome-maps-0:3.10.2-1.fc20.noarch
gnome-shell-0:3.10.2.1-2.fc20.x86_64
gnome-shell-0:3.10.4-2.fc20.x86_64
gnome-weather-0:3.10.1-1.fc20.x86_64
libpeas-0:1.9.0-2.fc20.i686
libpeas-0:1.9.0-2.fc20.x86_64
sushi-0:3.10.0-1.fc20.x86_64
Also bis auf die Shell nur irrelevante Anwendungen. Und auch neue
Apps werde nicht immer in JavaScript geschrieben, GNOME Music ist z.B
in Python. Die ganzen Bibliotheken sind alle in C oder Vala, die
Anwendungen üblicherweise in C, C++, Vala oder Python. Aber du kannst
deine GNOME App auch in Haskell schreiben, wenn du willst.
> > Nicht alle Bugs betreffen mich bzw. sind so fatal, dass Daten
> > verloren gehen. Für manche Leute ist es sehr problematisch, Mails zu
> > verlieren und die müssen halt eine Software einsetzen, die auf
> > gewisse Qualitätsstandards achtet.
>
> Wo gehen in aktuellen Versionen Daten verloren?
Oh, ich vergaß, dass die aktuelle Version immer fehlerfrei ist. Das
Problem besteht nur in den alten Versionen und ab jetzt wird es nie
wieder irgendwelche Probleme geben.
> > KDE-PIM ist hier einfach nicht
> > mehr vertrauenswürdig.
>
> Wird von dir als Fakt dargestellt, obwohl du keinen Plan von der
> Materie hast…
Es gab in KDE-PIM und Akonadi bisher sehr schwere Bugs, die zu
Datenverlusten geführt haben. Eine solche Software möchte man dann
einfach nicht mehr einsetzen, weil man den Entwickler nicht vertraut,
erneut solch schwere Fehler einzubauen.
> Tamaskan schrieb am 26. April 2014 20:46
>
> > Dann sind die KDE-Entwickler ja auch Trottel, denn schließlich haben
> > die Probleme mit Nepomuk eingeräumt.
> Es gibt einen Unterschied zwischen „ständig schimpfen“ und dem
> Einräumen von Problemen. Keine Software ist ohne Probleme.
Und wenn man über Probleme schimpft, ist man gleich ein Trottel?
> > Es gibt nämlich auch Abhängigkeiten auf
> > Quelltextebene.
>
> Nein.
Natürlich, gibst du doch gleich selber zu.
> > Wenn ich z.B hier auf meinem Fedora mit GNOME "yum
> > install dolphin" ausführe, dann zieht er mir Nepomuk, Strigi und
> > Virtuoso mit rein.
>
> Die Pakete sind mit entsprechenden Flags kopiliert, denn es ist eine
> Compiler-Option. Eine Option ist trotzdem eine Option.
Abgesehen von Gentoo werden Pakete als Binaries ausgeliefert, sodass
der Nutzer eben *nicht* die Wahl hat. Die KDE-Entwickler hätten die
Abhängigkeit auch zur Laufzeit realisieren können.
> > Mit KDE 5 wurde ja nicht umsonst daran gearbeitet,
> > diese Abhängigkeiten zu reduzieren, und das meines Wissens recht
> > erfolgreich.
>
> Es gibt kein KDE 5 und das wird's auch niemals geben.
Ich meine KDE Frameworks 5 und Plasma Workspaces 2. Die gibt es
wirklich:
http://www.heise.de/open/meldung/Plasma-Next-Die-naechste-Generation-der-KDE-Oberflaeche-2162405.html
Ob das jetzt als KDE SC 5.x veröffentlicht wird oder 4.x fortgesetzt
wird, ist komplett irrelevant.
> Wenn du mir massig Probleme des aktuellen (!) Plasma-NM beweist,
> werde ich das einsehen.
Das wird schwer sein, da müssten wir uns physisch treffen und ich
müsste dir das dann vorführen. Alternativ kannst du einfach annehmen,
dass wenn Nutzer schreiben, dass die Probleme mit Software xy haben,
dass diese dann nicht alle lügen.
Ich finde es auch witzig, wie du die das "aktuelle" betonst. Oft höre
ich den Tenor, dass nur ältere KDE-Versionen Bugs haben und in der
neuen alle Probleme behoben wurden, also "KDE 4.y hat diese Probleme
nicht, selbst schuld, wenn du noch KDE 4.x benutzt".
> Du behauptest, dass ein Community-Management freiwilligen
> Hobby-Programmierern vorschreiben könnte, woran sie arbeiten.
> Können sie nicht, da es sich um freiwillige Arbeit handelt.
Nein, das habe ich nicht behauptet. Und mir ist das Problem bekannt
und ich habe das auch schon angedeutet (da, wo du mein Zitat gekürzt
hast). Allerdings könnte KDE auch bezahlte Entwickler anstellen, so
wie GNOME das macht. Anscheinend ist KDE als Enterprise Desktop halt
uninteressant.
> Ändert nichts daran, dass Qt trotzdem im Mobil-Bereich nicht weniger
> Stark als vorher ist.
Da wäre ich skeptisch. Nokia ist jetzt ja von Microsoft geschluckt
worden, und die jetzigen Qt-Plattformen gehören irgendwelchen
Startups, die nicht mit Nokia zu vergleichen sind.
> Android- und iOS-Support seitens Qt ist auch nun dabei. Bähm.
Ach, das war ja das, wo eine Qt-App für Android beim ersten Start
erstmal die ganzen Qt-Libaries aus dem Netz nachladen musste, und wo
es keine nativen Widgets gibt, sodass sich die App wie ein
Fremdkörper anfühlt. Und gerade die iOS-Nutzer legem da extrem Wert
drauf.
Und Qt ist nicht gleich Qt, es gibt auf den jeweiligen Plattformen
spezifische APIs, eine App für Ubuntu Touch läuft nicht einfach auf
BlackBerry.
Da ist es sinnvoller, eine native Android und eine native iOS-App zu
schreiben und du hast alle Plattformen abgedeckt.
> Nicht irrelevanter als Qt nur unter MeeGo und ohne offiziellen
> Android- und iOS-Support.
MeeGo war ja diese Vaporware. Das zu übertreffen ist ja nicht schwer.
> Weniger Bugs.
Mehr, wegen der dynamischen Typisierung. JavaScript erlaubt sogar,
zur Laufzeit Objektstrukturen zu verändern. Ich freu mich schon auf
die lustigen Bugs.
> Wenn die Plasma-Widget-Maintainer sagen, dass die QML-Version
> wartbarer ist, ist sie wartbarer und dein geratenes Gesabbel ändert
> nichts daran.
Die Götter haben gesprochen und meine Reden sind Blasphemie, ich
verstehe (da heißt nicht, dass die QML-Version nicht tatsächlich
wartbarer ist, deine Argumentation ist nur daneben).
> Klar ist Gnome Shell im Classic-Modus ein Rewrite des alten GUIs.
> Erst wurde das Panel von GTK2 auf GTK3 protiert. Dann wurde dieser
> Fallback-Modus weggeschmissen und durch Extensions für Gnome Shell
> ersetzt.
Das war unnötig, ja.
> Rewrite, Konzeptlosigkeit, yaddayaddayadda.
Ich sage ja nicht, dass es bei anderen Projekte keine konzeptionellen
Fehler gibt, bei KDE ist es halt extrem. Und in der Zeit, in der man
irgendwelche Ports und Rewrites durchführt kann man keine Bugs fixen
oder neue Features entwickeln.
Dieses "yaddayaddayadda" solltest du sein lassen, das wirkt ziemlich
kindisch. Auch ein deutsches "blablabla" würde es nicht besser
machen.
> > und hat dann proprietäre
> > Erweiterungen wie z.B Klassen hinzugefügt.
>
> QML ist nicht reines JavaScript.
Nein, QML ist erstmal gar kein JavaScriot, sondern "nur" ein
proprietäres JSON, und Qt Quick insgesamt hat dann seinen eigenen
JavaScript-Dialekt. Ähnlich wie gjs.
> > Glücklicherweise ist der Rest von GNOME immer noch in C, Vala oder
> > Python geschrieben.
>
> Gnome Maps nicht, anderes Zeug auch nicht.
# repoquery --whatrequires gjs
gjs-devel-0:1.38.1-1.fc20.i686
gjs-devel-0:1.38.1-1.fc20.x86_64
gnome-documents-0:3.10.1-1.fc20.x86_64
gnome-documents-0:3.10.2-1.fc20.x86_64
gnome-maps-0:3.10.2-1.fc20.noarch
gnome-shell-0:3.10.2.1-2.fc20.x86_64
gnome-shell-0:3.10.4-2.fc20.x86_64
gnome-weather-0:3.10.1-1.fc20.x86_64
libpeas-0:1.9.0-2.fc20.i686
libpeas-0:1.9.0-2.fc20.x86_64
sushi-0:3.10.0-1.fc20.x86_64
Also bis auf die Shell nur irrelevante Anwendungen. Und auch neue
Apps werde nicht immer in JavaScript geschrieben, GNOME Music ist z.B
in Python. Die ganzen Bibliotheken sind alle in C oder Vala, die
Anwendungen üblicherweise in C, C++, Vala oder Python. Aber du kannst
deine GNOME App auch in Haskell schreiben, wenn du willst.
> > Nicht alle Bugs betreffen mich bzw. sind so fatal, dass Daten
> > verloren gehen. Für manche Leute ist es sehr problematisch, Mails zu
> > verlieren und die müssen halt eine Software einsetzen, die auf
> > gewisse Qualitätsstandards achtet.
>
> Wo gehen in aktuellen Versionen Daten verloren?
Oh, ich vergaß, dass die aktuelle Version immer fehlerfrei ist. Das
Problem besteht nur in den alten Versionen und ab jetzt wird es nie
wieder irgendwelche Probleme geben.
> > KDE-PIM ist hier einfach nicht
> > mehr vertrauenswürdig.
>
> Wird von dir als Fakt dargestellt, obwohl du keinen Plan von der
> Materie hast…
Es gab in KDE-PIM und Akonadi bisher sehr schwere Bugs, die zu
Datenverlusten geführt haben. Eine solche Software möchte man dann
einfach nicht mehr einsetzen, weil man den Entwickler nicht vertraut,
erneut solch schwere Fehler einzubauen.