Naja, Microsoft erhält mittlerweile von 70% aller verkauften Android-Geräte Lizenzgebühren. Nach Samsung, LG, HTC,... fehlt eigentlich nur noch Motorola in der Liste. Nur Barnes & Noble lehnt sich gegen dieses Patentgebahren auf. Laut B&N ist Microsoft nur im Besitz einer Reihe unwichtigerer Patente, die sie aber massiv durchsetzen.
Das beantwortet meine Frage nicht! Wieso besteht ein kausaler Nexus zwischen der Portierung / Benutzung von Calligra auf Android und den Lizenzgebühren, die MS von einigen Herstellern verlangt?
Das ist fraglich. Erstmal ist es eine Menge Arbeit, und dann würde diese Arbeit hauptsächlich daraus bestehen, Komponenten aus kdelibs zu reproduzieren. Am Ende gewinnt man dadurch nicht, weil man Mehrarbeit in Form von neuem Code, Maintainance, Bugfixing produziert. Das Ersparnis wäre, dass man unbenutzte Teile aus kdelibs nicht als Abhängigkeit dazubekommt, weil kdelibs selber im Moment von der Installation her mehr oder weniger "all-or-nothing" ist.
Die Strategie ist daher, kdelibs zu splitten in einzelne Libraries, und die Abhängigkeiten untereinander zu verringern, sodass so etwas wie Calligra nur die Abhängigkeiten hat, die absolut notwendig sind. Dieses Splitten von kdelibs passiert im Moment schon, unter dem Namen "KDE Frameworks 5". Dieser Name gibt hier an, dass es nicht eine einzelne, grosse Library ist, sondern mehrere Frameworks, die zusammen quasi das traditionelle kdelibs ersetzen, bzw. deren Funktionen liefern.
Auf diese Art haben alle KDE Apps die Vorteile, die sich daraus ergeben, es wird einfacher Apps auf "anderen Systemen" zu deployen, und Entwickler von 3rd Party Apps können aus kdelibs cherry-picken, ohne dabei direkt die vollen Abhängigkeiten (under deren Abhängigkeiten) abzubekommen.
Dieser Sprung wird kurz nach dem Erscheinen von Qt5 dann gemacht, da die neue Majorversion von Qt eh zu einigen Source- und Binary Interface (API + ABI) führen wird. Für App Entwicker ist das allerdings grösstenteils transparent, d.h. dort werden keine grösseren Änderungen nötig sein. (Also auf keinen Fall sowas wie Qt 3->4 oder KDE 3 -> 4, wo sich sehr viel an der Architektur geändert hat.)
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 13. Jan 2012 um 16:25.
Prima, dass die KDE Libs nur 5009 EBN issues haben. http://ebn.kde.org/krazy/index.php?component=kde-4.x&module=kdelibs Da sieht man die Wertarbeit. Das gleich nochmal wieder aufrupfen ist eine super Idee! Wird ja langweilig, wenn alles glatt und rund wäre. Open Source lebt bekanntlich von ungefixten elementaren Bugs, die zur Mitarbeit motivieren, und Firmen zum hoffnungsfrohen Zahlen von Support nötigen.
Das gleich nochmal wieder aufrupfen ist eine super Idee! Wird ja langweilig, wenn alles glatt und rund wäre.
Hast Du den Sinn dahinter nicht kapiert? Genau dadurch wird doch alles leichter wartbar und Du kannst viel schneller Patches einarbeiten. Zudem finden sich dann ja eher Leute, die ein Patch einreichen; denn wenn man nur eine Lib zu Hause kompilieren muss und nicht einen Trumm von Zeug, das man nicht für seine App benötigt, dann ist die Chance, sich da selber zu engagieren deutlich höher. Wenn Du das anders siehst, dann begründe Deine Statements doch wenigstens. Denn es ist mir nicht offensichtlich, wieso eine Splittung von vorhandenem Code etwas verschlimmbessern soll...
Das stimmt natürlich, aber wenn ohne dass die Tests sich ändern es mehr Issues werden, dann stimmt doch was nicht mit dem Entwicklungsprozess. Und das in den KDE Libs auf denen doch alle anderen Teile der Plattform aufbauen müssen. Ein weiches Fundament.
Normalerweise würde man ja auch auf allen Plattformen builden, und dann gleich sehen, wo was bricht. Bei KDE ist das alles anders. Da klatscht man alles zusammen, macht dann Ports, die einem bei der nächsten Version wieder um die Ohren fliegen. Da werden Qualitätsprobleme unterdrückt.
Da rotzt man den Code hin, der noch genauso buggy ist wie gestern, und macht neue Spirenzchen, und der alte Code rottet statt zu reifen, weil keiner Bugs tatsächlich fixt.
EBN Issues sind ja z.B. dafür da um Portabilität zu verbessern, um Fehleranfälligkeit zu verringern.
Da geht es höchstens um die Lesbarkeit und Einheitlichkeit des Codes.
So ist es. Quasi wie Bonusziele
Die gefundenen Punkte haben keinen Einfluss auf die Korrektheit, es sind Vorschläge zur Verschönerung des Codes.
Wenn man dem Link zu den Ergebnissen für kdelibs folgt, sieht man z.B. dass für kdecore ca 400 Verbesserungsvorschläge gibt. Davon sind dann zum Beispiel 43 (also ca 10%) Kandidaten für einfachere Schreibweisen (Normalisierung) von QObject connect Aufrufen. Die connect Funktion macht ohnehin selbt eine Normalisierung, d.h. das Resultat des Aufrufs ist davon nicht betroffen.
Aber es zeigt eben, dass der Code keine Liebe erhält durch die Entwickler.
Und KDElibs ist ja auch nur die "solide Basis", wir sprechen ja nicht auf dem ganzen anderen Krams, oder solche ewig entwickelten Sachen wie Akonadi, und ihre angeblichen Konfigurationsprobleme usw.
Aber es zeigt eben, dass der Code keine Liebe erhält durch die Entwickler.
Das würde ich so nichtt sagen. Ich denke es zeigt viel mehr, dass die vorhandenen Ressourcen für Entwicklung und Wartung der Funktionalität gebraucht wurden und zumindest derzeit keine für mehr oder weniger kosmetische Veschönerungen zur Verfügung stehen.
Es kommt durchaus vor, dass neue Entwickler EBN Vorschläge als Startpunkt für ihre Mitarbeit wählen, weil es eben relativ unkritische Änderungen sind.
Also ist alles auf einer Basis gebaut, die unter Entwicklermangel leidet. Nicht einmal die Basis, die kdelibs, sind entbuggt und ihnen wird Liebe geschenkt, dementsprechend werden diese lausigen Qualitätsstandards des Kerns auch von den abhängigen Applikationen verfolgt. Und bei neuem Code kümmert sich auch keiner um eine Verbesserung.
Aber wahrscheinlich haben die Anwender ja Unrecht, und das sind die Größten, wie man an dem Marketing Babbelsprech sieht.
Also ist alles auf einer Basis gebaut, die unter Entwicklermangel leidet.
Nein. Ich habe geschrieben, dass für Entwicklung und Wartung ausreichend Ressourcen zur Verfügung stehen, nur nicht für kosmetische Verschönerungen. Zusätzlich steht dort auch, dass das Aufzeigen von möglchen Verschönerungen schon durchaus zu einem Zuwachs von Ressourcen geführt hat, weil neue Entwickler sich dadurch mit der Codebasis vertraut machen können ohne direkt die Funktionalität zu beeinflussen.
Und die Leute, die Calligra vielleicht unter Unity oder Gnome hinzuinstallieren möchten, denen haut man so mit Akonadi gleich den ganzen KDE4 um die Ohren, vielleicht noch zusammen mit Nepomuk/Strigi und das, obwohl vielleicht schon Zeitgeist bzw. Tracker und Evolution-Data-Server aktiv sind? Von daher finde ich, dass die Bestrebungen, zumindest die KDE4-Abhängigkeiten zu verschlanken (siehe das obige Posting von sebas), ein erster richtiger Schritt sind. Calligra sollte keinesfalls nur auf KDE beschränkt bleiben.
akonadi hat keine weitreichenden KDE Abhängigkeiten (eigentlich gar keine, wenn man automoc nicht zählt), schon gar nicht nepomuk oder Strigi. Es benötigt neben automoc: cmake, mysql, Qt4, boost, libxslt, soprano und shared-mime-info. Jedenfalls benötigt es keine kdelibs o.ä. Gegenüber einem reinen Gnome-System würde also zusätzlich zu calligra mysql hinzukommen. Mit KDE hat das aber definitiv nichts zu tun.
Mir ist aber nicht klar, was calligra mit akonadi soll.
Doch, akonadi benötigt mysql. sqlite ist eine Alternative für das storage backend, aber laut Entwickler ist das backend momentan noch nicht geeignet. mysql ist das einzige wirklich unterstützte backend.
Das schlägt sich auch im build system von akonadi nieder, denn dort heißt es: find_program( MYSQLD_EXECUTABLE mysqld /usr/sbin /usr/local/sbin /usr/libexec /usr/local/libexec /opt/mysql/libexec /usr/mysql/bin /opt/mysql/sbin ) if( MYSQLD_EXECUTABLE) message( STATUS "MySQL Server found." ) else ( MYSQLD_EXECUTABLE ) message( STATUS "MySQL Server wasn't found. it is required to run Akonadi" ) endif( MYSQLD_EXECUTABLE )
Wenn du also akonadi mit sqlite nutzen willst (was angeblich nicht sonderlich gut funktioniert, getestet habe ich es nicht), dann wirst du wohl sqlite und mysql installieren müssen. Es kann aber natürlich sein, dass manche Distributionen da rumpatchen um mysql rauszubekommen, das weiß ich nicht. Von offizieller Seite wird mysql allerdings benötigt.
mysql ist das einzige wirklich unterstützte backend.
Schnuck hat schon recht, Akonadi unterstützt auch SQLite und PostgreSQL. QSLite wird aufgrund verschiedener Einschränkungen nicht empfohlen, aber PostgreSQL sollte da kein Problem sein. MySQL ist der Default und daher auch das meist genutzte und am besten getestete Backend.
Das schlägt sich auch im build system von akonadi nieder
Hmm, ja, müsste dort vermutlich nicht abgeprüft werden. mysqld ist ja schließlich nur einen Laufzeitabhängigkeit. Ich schätze das ist da drinnen, um Leuten die selbst kompilieren den zusätzlichen Hinweis zu geben, dass sie neben den Clientbibliotheken auch den Server benötigen.
aha, damit verdient nun microsoft auch dann, wenn jemand kein ms office verwendet, sondern koffice. siehe android lizenzgebühren.
Hä? Wo ist denn da die Logik? Wieso "damit"?
Naja, Microsoft erhält mittlerweile von 70% aller verkauften Android-Geräte Lizenzgebühren. Nach Samsung, LG, HTC,... fehlt eigentlich nur noch Motorola in der Liste. Nur Barnes & Noble lehnt sich gegen dieses Patentgebahren auf. Laut B&N ist Microsoft nur im Besitz einer Reihe unwichtigerer Patente, die sie aber massiv durchsetzen.
Du bist leider im falschen Thread gelandet.
nein, hat er ja erklärt warum ers hier schreibt
Nein, hat er eben nicht!
denk nach, du schaffst den link im kopf
Nee, ich erkenne die Logik nicht - siehe auch meine Nachfrage unten.
Das beantwortet meine Frage nicht! Wieso besteht ein kausaler Nexus zwischen der Portierung / Benutzung von Calligra auf Android und den Lizenzgebühren, die MS von einigen Herstellern verlangt?
Die Frage stelle ich mir auch.
Wäre denn ein Qt4-only Calligra-Port prinzipiell möglich?
IMHO würde Calligra erst dann richtig durchstarten.
Das ist fraglich. Erstmal ist es eine Menge Arbeit, und dann würde diese Arbeit hauptsächlich daraus bestehen, Komponenten aus kdelibs zu reproduzieren. Am Ende gewinnt man dadurch nicht, weil man Mehrarbeit in Form von neuem Code, Maintainance, Bugfixing produziert. Das Ersparnis wäre, dass man unbenutzte Teile aus kdelibs nicht als Abhängigkeit dazubekommt, weil kdelibs selber im Moment von der Installation her mehr oder weniger "all-or-nothing" ist.
Die Strategie ist daher, kdelibs zu splitten in einzelne Libraries, und die Abhängigkeiten untereinander zu verringern, sodass so etwas wie Calligra nur die Abhängigkeiten hat, die absolut notwendig sind. Dieses Splitten von kdelibs passiert im Moment schon, unter dem Namen "KDE Frameworks 5". Dieser Name gibt hier an, dass es nicht eine einzelne, grosse Library ist, sondern mehrere Frameworks, die zusammen quasi das traditionelle kdelibs ersetzen, bzw. deren Funktionen liefern.
Auf diese Art haben alle KDE Apps die Vorteile, die sich daraus ergeben, es wird einfacher Apps auf "anderen Systemen" zu deployen, und Entwickler von 3rd Party Apps können aus kdelibs cherry-picken, ohne dabei direkt die vollen Abhängigkeiten (under deren Abhängigkeiten) abzubekommen.
Dieser Sprung wird kurz nach dem Erscheinen von Qt5 dann gemacht, da die neue Majorversion von Qt eh zu einigen Source- und Binary Interface (API + ABI) führen wird. Für App Entwicker ist das allerdings grösstenteils transparent, d.h. dort werden keine grösseren Änderungen nötig sein. (Also auf keinen Fall sowas wie Qt 3->4 oder KDE 3 -> 4, wo sich sehr viel an der Architektur geändert hat.)
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 13. Jan 2012 um 16:25.Prima, dass die KDE Libs nur 5009 EBN issues haben.
http://ebn.kde.org/krazy/index.php?component=kde-4.x&module=kdelibs
Da sieht man die Wertarbeit. Das gleich nochmal wieder aufrupfen ist eine super Idee! Wird ja langweilig, wenn alles glatt und rund wäre. Open Source lebt bekanntlich von ungefixten elementaren Bugs, die zur Mitarbeit motivieren, und Firmen zum hoffnungsfrohen Zahlen von Support nötigen.
"Hast Du den Sinn dahinter nicht kapiert? Genau dadurch wird doch alles leichter wartbar und Du kannst viel schneller Patches einarbeiten."
Ich dachte die leichtere Wartbarkeit kriegt man durch die Integration?
EBN ist kein Bugtracker. Da geht es höchstens um die Lesbarkeit und Einheitlichkeit des Codes.
Das stimmt natürlich, aber wenn ohne dass die Tests sich ändern es mehr Issues werden, dann stimmt doch was nicht mit dem Entwicklungsprozess. Und das in den KDE Libs auf denen doch alle anderen Teile der Plattform aufbauen müssen. Ein weiches Fundament.
Normalerweise würde man ja auch auf allen Plattformen builden, und dann gleich sehen, wo was bricht. Bei KDE ist das alles anders. Da klatscht man alles zusammen, macht dann Ports, die einem bei der nächsten Version wieder um die Ohren fliegen. Da werden Qualitätsprobleme unterdrückt.
Da rotzt man den Code hin, der noch genauso buggy ist wie gestern, und macht neue Spirenzchen, und der alte Code rottet statt zu reifen, weil keiner Bugs tatsächlich fixt.
EBN Issues sind ja z.B. dafür da um Portabilität zu verbessern, um Fehleranfälligkeit zu verringern.
So ist es. Quasi wie Bonusziele
Die gefundenen Punkte haben keinen Einfluss auf die Korrektheit, es sind Vorschläge zur Verschönerung des Codes.
Wenn man dem Link zu den Ergebnissen für kdelibs folgt, sieht man z.B. dass für kdecore ca 400 Verbesserungsvorschläge gibt. Davon sind dann zum Beispiel 43 (also ca 10%) Kandidaten für einfachere Schreibweisen (Normalisierung) von QObject connect Aufrufen.
Die connect Funktion macht ohnehin selbt eine Normalisierung, d.h. das Resultat des Aufrufs ist davon nicht betroffen.
Aber es zeigt eben, dass der Code keine Liebe erhält durch die Entwickler.
Und KDElibs ist ja auch nur die "solide Basis", wir sprechen ja nicht auf dem ganzen anderen Krams, oder solche ewig entwickelten Sachen wie Akonadi, und ihre angeblichen Konfigurationsprobleme usw.
Das würde ich so nichtt sagen. Ich denke es zeigt viel mehr, dass die vorhandenen Ressourcen für Entwicklung und Wartung der Funktionalität gebraucht wurden und zumindest derzeit keine für mehr oder weniger kosmetische Veschönerungen zur Verfügung stehen.
Es kommt durchaus vor, dass neue Entwickler EBN Vorschläge als Startpunkt für ihre Mitarbeit wählen, weil es eben relativ unkritische Änderungen sind.
Also ist alles auf einer Basis gebaut, die unter Entwicklermangel leidet. Nicht einmal die Basis, die kdelibs, sind entbuggt und ihnen wird Liebe geschenkt, dementsprechend werden diese lausigen Qualitätsstandards des Kerns auch von den abhängigen Applikationen verfolgt. Und bei neuem Code kümmert sich auch keiner um eine Verbesserung.
Aber wahrscheinlich haben die Anwender ja Unrecht, und das sind die Größten, wie man an dem Marketing Babbelsprech sieht.
Nein. Ich habe geschrieben, dass für Entwicklung und Wartung ausreichend Ressourcen zur Verfügung stehen, nur nicht für kosmetische Verschönerungen. Zusätzlich steht dort auch, dass das Aufzeigen von möglchen Verschönerungen schon durchaus zu einem Zuwachs von Ressourcen geführt hat, weil neue Entwickler sich dadurch mit der Codebasis vertraut machen können ohne direkt die Funktionalität zu beeinflussen.
Bevor Akonadi nicht integriert ist,wird das sowieso nix und bleibt eine halbgare und unmoderne/unflexible Software. (;))
Und die Leute, die Calligra vielleicht unter Unity oder Gnome hinzuinstallieren möchten, denen haut man so mit Akonadi gleich den ganzen KDE4 um die Ohren, vielleicht noch zusammen mit Nepomuk/Strigi und das, obwohl vielleicht schon Zeitgeist bzw. Tracker und Evolution-Data-Server aktiv sind?
Von daher finde ich, dass die Bestrebungen, zumindest die KDE4-Abhängigkeiten zu verschlanken (siehe das obige Posting von sebas), ein erster richtiger Schritt sind.
Calligra sollte keinesfalls nur auf KDE beschränkt bleiben.
akonadi hat keine weitreichenden KDE Abhängigkeiten (eigentlich gar keine, wenn man automoc nicht zählt), schon gar nicht nepomuk oder Strigi.
Es benötigt neben automoc: cmake, mysql, Qt4, boost, libxslt, soprano und shared-mime-info. Jedenfalls benötigt es keine kdelibs o.ä.
Gegenüber einem reinen Gnome-System würde also zusätzlich zu calligra mysql hinzukommen. Mit KDE hat das aber definitiv nichts zu tun.
Mir ist aber nicht klar, was calligra mit akonadi soll.
Akonadi braucht kein mysql. Das verkauft Deine Distribution Dir nur so. sqlite tuts auch.
Doch, akonadi benötigt mysql. sqlite ist eine Alternative für das storage backend, aber laut Entwickler ist das backend momentan noch nicht geeignet. mysql ist das einzige wirklich unterstützte backend.
Das schlägt sich auch im build system von akonadi nieder, denn dort heißt es:
find_program( MYSQLD_EXECUTABLE mysqld /usr/sbin /usr/local/sbin /usr/libexec /usr/local/libexec /opt/mysql/libexec /usr/mysql/bin /opt/mysql/sbin )
if( MYSQLD_EXECUTABLE)
message( STATUS "MySQL Server found." )
else ( MYSQLD_EXECUTABLE )
message( STATUS "MySQL Server wasn't found. it is required to run Akonadi" )
endif( MYSQLD_EXECUTABLE )
Wenn du also akonadi mit sqlite nutzen willst (was angeblich nicht sonderlich gut funktioniert, getestet habe ich es nicht), dann wirst du wohl sqlite und mysql installieren müssen.
Es kann aber natürlich sein, dass manche Distributionen da rumpatchen um mysql rauszubekommen, das weiß ich nicht. Von offizieller Seite wird mysql allerdings benötigt.
Schnuck hat schon recht, Akonadi unterstützt auch SQLite und PostgreSQL. QSLite wird aufgrund verschiedener Einschränkungen nicht empfohlen, aber PostgreSQL sollte da kein Problem sein.
MySQL ist der Default und daher auch das meist genutzte und am besten getestete Backend.
Hmm, ja, müsste dort vermutlich nicht abgeprüft werden. mysqld ist ja schließlich nur einen Laufzeitabhängigkeit. Ich schätze das ist da drinnen, um Leuten die selbst kompilieren den zusätzlichen Hinweis zu geben, dass sie neben den Clientbibliotheken auch den Server benötigen.