Ich sehe das nicht als Rechtfertigung. Eher als Klarstellung, da es doch offenbar sehr viele falsche Vorstellungen gibt und diese dann auch meist als Tatsache weiter verbreitet werden. Ob das nun das Konzept zu Plasma oder eben Akonadi und Nepomuk ist, spielt da keine Rolle mehr.
Ich finde diese etwas "offensivere" Kommunikationsstrategie durchaus gut. Man könnte fast meinen die Leute von KDE haben aus dem Kommunikationsdebakel (aka 4.0, 4.1, 4.2, ...) gelernt
Auf jeden Fall fallen dabei auch technisch interessante Artikel raus.
Das neueste Pamphlet ist eher eine Antwort auf die zum Teil sehr schlechten Reaktionen der Nutzer auf die KDE 4.5.x-Veröffentlichung. Nach KDE 4.0 bis 4.2 waren KDE4-Nutzer mit KDE 4.3 und 4.4 ganz glücklich. Und jetzt geht dieses ganze Entwicklungsgefrickel, das schon leichte enlightenmentartige Züge trägt, schon wieder los (Akonadi und OpenGL2).
Macht es denn für einen Desktop Sinn, mehr OpenGL-Features einbinden zu wollen als die freie Xorg-Grafikkartentreiberwelt zur Zeit an OpenGL-Funktionalität hergibt?
Das ist leider die Linux-Achillesferse schlechthin, nämlich die langsame Mesa-3D-Treiberentwicklung, die zur Zeit auch noch in zwei Entwicklungsstränge aufgesplittet ist, den Strang mit den klassischen Mesa3D/Dri-Treibern und den Gallium-Strang. Zur Zeit ist kaum etwas wirklich fertig, es fehlt vor allen Dingen an Entwicklern. Auch KDE4 und Gnome3 sollten dafür Verständnis aufbringen.
"Macht es denn für einen Desktop Sinn, mehr OpenGL-Features einbinden zu wollen als die freie Xorg-Grafikkartentreiberwelt zur Zeit an OpenGL-Funktionalität hergibt?"
So ist es ja nicht. Einige Treiber sagen das die Funktion X oder Y können damit sie die OGL Version Z beherrschen obwohl sie es nicht können oder nur Fehlerhaft.
Der Grund ist das viele Programme nur nach der OGL Version fragen und nicht nach den Erweiterungen bzw. was die Karte alles kann.
So ist es ja nicht. Einige Treiber sagen das die Funktion X oder Y können damit sie die OGL Version Z beherrschen obwohl sie es nicht können oder nur Fehlerhaft.
Wird das tatsächlich mit Absicht gemacht? Gibt es dafür irgendwo Belege? In dem Fall könnten sich die kwin-Entwickler die ganzen Abfragen die sie momentan machen eigentlich auch gleich sparen.
Wenn man einen derartigen Workaround anbieten will, dann kann man das ja gerne in Anwesenheit einer Umgebungsvariable alla OPENGL_VERSION_HACK machen aber doch bitte nicht als Default.
Als Beispiel können die r100-r400 und NV30 kein GL_ARB_texture_non_power_of_two bzw nur eingeschränkt was aber ab der Version 2.0 vorgeschrieben ist. PS: Auch die Blobs von Nvidia und ATI Melden hier OGL 2.1
Das mit dem OpenGL ist mir relativ unwichtig. Das kann man abschalten.
Aber das KDEPIM ist dank dem unsäglich vergurktem Akonadi Schrott völlig unbrauchbar und critical broken. Das betrifft im besonderem kmail/kontact. Wer hat schon Lust bei jedem 2. Login seinen kompletten Datenbebestand anb Adressen und Terminen komplett zu verlieren ? Allein dies hier spricht Bände: https://bugs.kde.org/buglist.cgi?quicksearch=akonadi Nichts gegen PreAlpha Entwickler Versionen. Aber dann kennzeichnet man diese als solche und verursacht keine solchen IRREN Schäden
Der zurzeit einzig stabil nutzbare eMailclient in KDE4-Umgebungen ist "Thunderbird".
Besonders bei Setups in Firmen, die zentrale Home NFS Server haben und ein kooperatives UMASK (002) nutzen.
In diesem Setup löscht man morgens nach login "rm -rf .config/akonadi ; rm -rf .local/akonadi" um überhaupt kmail oder kontact starten zu können.
Nein, Leute AKONADI ist ein riesen Problem.
Konzeptionell vielleicht nett, aber nicht fertig. Ich würd dem ganzen die Versionsnummer 0.0000000001 geben.
Die Kritikpunkte im einzelnen: 1. embedded MySQL -> Schrott, zerstört sich selber beim 2. Login. 2. keine Möglichkeit eine externe DB Resource anzugeben (nein, die Postgres Option versucht hirnrissiger Weise einen eigenen lokalen PostGres Server zu starten, unter $HOME/.local/...
Warum gibt man nicht einfach die Möglichkeit einen zentralen PostGres (oder auch meinetwegen) zentralen MySQL Server als DB_Backend zu Nutzen ?
Ich möcht wirklich wissen, welches Kraut die beim Akonadi Team rauchen, aber das muss die Realitäten völlig verzerren.
Die KDE-Entwickler sehen sich scheinbar immer häufiger gezwungen sich rechtfertigen zu müssen. Beispiele:
Und jetzt das "KWin-Treiber-Dilemma".
Ich denke nicht, dass Open-Source-Entwickler sich rechtfertigen müssen.
Ich sehe das nicht als Rechtfertigung. Eher als Klarstellung, da es doch offenbar sehr viele falsche Vorstellungen gibt und diese dann auch meist als Tatsache weiter verbreitet werden. Ob das nun das Konzept zu Plasma oder eben Akonadi und Nepomuk ist, spielt da keine Rolle mehr.
Ich finde diese etwas "offensivere" Kommunikationsstrategie durchaus gut. Man könnte fast meinen die Leute von KDE haben aus dem Kommunikationsdebakel (aka 4.0, 4.1, 4.2, ...) gelernt
Auf jeden Fall fallen dabei auch technisch interessante Artikel raus.
Dem stimme ich mit Gesang und Tanzeinlage zu
Das neueste Pamphlet ist eher eine Antwort auf die zum Teil sehr schlechten Reaktionen der Nutzer auf die KDE 4.5.x-Veröffentlichung.
Nach KDE 4.0 bis 4.2 waren KDE4-Nutzer mit KDE 4.3 und 4.4 ganz glücklich. Und jetzt geht dieses ganze Entwicklungsgefrickel, das schon leichte enlightenmentartige Züge trägt, schon wieder los (Akonadi und OpenGL2).
Macht es denn für einen Desktop Sinn, mehr OpenGL-Features einbinden zu wollen als die freie Xorg-Grafikkartentreiberwelt zur Zeit an OpenGL-Funktionalität hergibt?
Das ist leider die Linux-Achillesferse schlechthin, nämlich die langsame Mesa-3D-Treiberentwicklung, die zur Zeit auch noch in zwei Entwicklungsstränge aufgesplittet ist, den Strang mit den klassischen Mesa3D/Dri-Treibern und den Gallium-Strang.
Zur Zeit ist kaum etwas wirklich fertig, es fehlt vor allen Dingen an Entwicklern.
Auch KDE4 und Gnome3 sollten dafür Verständnis aufbringen.
"Macht es denn für einen Desktop Sinn, mehr OpenGL-Features einbinden zu wollen als die freie Xorg-Grafikkartentreiberwelt zur Zeit an OpenGL-Funktionalität hergibt?"
So ist es ja nicht. Einige Treiber sagen das die Funktion X oder Y können damit sie die OGL Version Z beherrschen obwohl sie es nicht können oder nur Fehlerhaft.
Der Grund ist das viele Programme nur nach der OGL Version fragen und nicht nach den Erweiterungen bzw. was die Karte alles kann.
Wird das tatsächlich mit Absicht gemacht? Gibt es dafür irgendwo Belege? In dem Fall könnten sich die kwin-Entwickler die ganzen Abfragen die sie momentan machen eigentlich auch gleich sparen.
Wenn man einen derartigen Workaround anbieten will, dann kann man das ja gerne in Anwesenheit einer Umgebungsvariable alla OPENGL_VERSION_HACK machen aber doch bitte nicht als Default.
Als Beispiel können die r100-r400 und NV30 kein GL_ARB_texture_non_power_of_two bzw nur eingeschränkt was aber ab der Version 2.0 vorgeschrieben ist.
PS: Auch die Blobs von Nvidia und ATI Melden hier OGL 2.1
Das mit dem OpenGL ist mir relativ unwichtig. Das kann man abschalten.
Aber das KDEPIM ist dank dem unsäglich vergurktem Akonadi Schrott völlig unbrauchbar und critical broken.
Das betrifft im besonderem kmail/kontact.
Wer hat schon Lust bei jedem 2. Login seinen kompletten Datenbebestand anb Adressen und Terminen komplett zu verlieren ?
Allein dies hier spricht Bände:
https://bugs.kde.org/buglist.cgi?quicksearch=akonadi
Nichts gegen PreAlpha Entwickler Versionen. Aber dann kennzeichnet man diese als solche und verursacht keine solchen IRREN Schäden
Der zurzeit einzig stabil nutzbare eMailclient in KDE4-Umgebungen ist "Thunderbird".
Besonders bei Setups in Firmen, die zentrale Home NFS Server haben und ein kooperatives UMASK (002) nutzen.
In diesem Setup löscht man morgens nach login "rm -rf .config/akonadi ; rm -rf .local/akonadi" um überhaupt kmail oder kontact starten zu können.
Nein, Leute AKONADI ist ein riesen Problem.
Konzeptionell vielleicht nett, aber nicht fertig. Ich würd dem ganzen die Versionsnummer 0.0000000001 geben.
Die Kritikpunkte im einzelnen:
1. embedded MySQL -> Schrott, zerstört sich selber beim 2. Login.
2. keine Möglichkeit eine externe DB Resource anzugeben (nein, die Postgres Option versucht hirnrissiger Weise einen eigenen lokalen PostGres Server zu starten, unter $HOME/.local/...
Warum gibt man nicht einfach die Möglichkeit einen zentralen PostGres (oder auch meinetwegen) zentralen MySQL Server als DB_Backend zu Nutzen ?
Ich möcht wirklich wissen, welches Kraut die beim Akonadi Team rauchen, aber das muss die Realitäten völlig verzerren.
Das musste mal Raus!
Jojo