Ich bin zwar absoluter KDE Fan aber die letzten Jahre waren doch eine harte Geduldsprope. In 4.6 wird wohl KDEPIM endlich auf Akonadi umsteigen. Darauf warte ich im Prinzip schon sehr lange aber es wird wohl wieder auf kryptische Akonadi-Fehlermeldungen hinauslaufen. Besonders wenn man etwas exotischere Konfigurationen verwendet wie z.B. Disconnected IMAP und IMAP-Storage um Termine und Kontakte ebenfalls auf dem IMAP-Server zu speichern.
KDE sollte wirklich ihre Beta- und RC-Versionen als einfach zu installierende Pakete für die gängigsten Distributionen anbieten. Dann würden die Bugs vielleicht auch mal vor der Release gefunden werden.
Also ich habe die beta1 vor einer Woche mal getestet. Vor allem KMail mit Akonadi über meinen IMAP-Account meiner Firma. Zusätzlich auch den Kalender mit ical, wo ich neben meinem persönlichen Kalender auch die Belegungen der Meeting-Räume in weiteren Kalendern eingebunden habe. In der Firma benutzen wir für die Mails und Termine "Zimbra".
Ich war überrascht dass es doch ganz ordentlich lief. Mein erster Test über Akonadi vor einigen Monaten endete da oft in einigen Fehlermeldungen und 100% ausgelastetem Akonadi. Aktuell hingegen ist es zwar nicht das schnellste, aber dafür doch recht stabil. Fehlermeldungen hatte ich noch keine.
Was ich aber schon mal als einen Vorteil der Akonadi-Anbindung sehe, ist dass sich KMail nun endlich auch dann Benutzen lässt, auch wenn im Hintergrund die Konten abgerufen werden. Bisher musste ich da vor allem daheim immer warten bis KMail alles abgerufen hatte.
Kann das vom Vorposter nur bestätigen! Nutze ebenfalls schon die 1. und nun auch die 2.Beta und bin Positiv überrascht wie Akonadi mit Kmail samt Gefolge trotz des Beta Status zusammen arbeitet. Funktioniert soweit recht ordentlich das ganze!
"KDE sollte wirklich ihre Beta- und RC-Versionen als einfach zu installierende Pakete für die gängigsten Distributionen anbieten."
Das Bereitstellen von Paketen ist die ureigenste Aufgabe der Distributionen, und manche, wie OpenSuse oder Arch, kriegen es ja auch problemlos hin.
Zum Thema: Ich habe Beta1 ein bisschen getestet, läuft für eine Beta ziemlich rund, zudem setzt sie bei mir auf einer Distributions-Alpha (OpenSuse 11.4 Milestone 4) auf. Auf Akonadi in Beta2 bin ich gespannt, bisher hatte ich da ein Problem mit der Aktualisierung meines IMAP-Kontos.
Das Bereitstellen von Paketen ist die ureigenste Aufgabe der Distributionen...
Das ist mir als "Kunde" völlig egal wessen Aufgabe das ist. Da es viele Distributionen nunmal nicht machen sollte es im Interesse von KDE sein, selbst Pakete bereitzustellen. Schliesslich ist es deren Ruf, der unter den ganzen Bugs leidet.
Ich bin ja gerne mal bereit eine Beta zu testen und Bugs zu melden. Allerdings werde ich dafür nicht den Compiler anwerfen. Sollte sich 4.6 als Katastrophe herausstellen, wechsle ich einfach wieder zurück zu 4.5. Für mich als User macht das weniger einen Unterschied. KDE hingegen darf dann mit der schlechten Presse leben und das alles nur, weil nicht genug Leute die neue Release testen konnten.
Es gibt kaum eine Distribution, die entsprechende Pakete nicht anbietet und die sind genau da wo sie hingehören: im Entwicklungszweig der jeweiligen Distribution.
Willst du also KDE 4.6 Beta testen, empfiehlt es sich so oder so, dafür eine eigenes System zu nutzen anstatt mit dem Produktivsystem zu arbeiten und dann kannst du auch dort gleich den gesamten Entwicklungszweig nutzen.
Ich gehe im Übrigen davon aus, dass das Bereitstellen von Paketen für die gängigsten Distributionen für eine stabile Version dieser Distribution keinen Nennenswerten Vorteil bringen würde.
Die meisten die KDE testen, Bugs finden und melden wollen, tun das im Zuge der Entwicklung ihrer bevorzugten Distribution. Diejenigen, die KDE Beta auf einer stabilen Distribution nutzen würden, würden es kurz testen/nutzen aber kaum Feedback geben. Ausnahmen mag es geben aber das dürfte ein vernachlässigbarer Teil sein.
Und dann übersteigt der Aufwand den Nutzen um Weiten.
Dann gucke doch mal in die Praxis, Clementine (Amarok 1.4+) rockt http://code.google.com/p/clementine-player/ weil man ständig baut.
Amarok 2.x läuft auch nur, wenn man viel baut, was mittlerweile auch passiert.
Dank Buildservern und Builtbots geht heute viel mehr als früher. Wenn man viel baut, werden die ganzen Fehler schon in der betaphase gefunden, weil die Leute mehr testen und mehr Fehler finden.
Das Typische ist doch die Live-CD bei der man innerhalb von 2 Minuten Fehler im Programm findet. Leider ist die Live-CD erst für den release candidate da.
Das ist so ähnlich wie bei Xorg. Auch dort gibt es keine Binaries mehr wie noch zu XFree-Zeiten. Folge: Fast alle Nutzer testen keine Xorg-Originalsoftware mehr.
KDE hat noch nie Binaries zum Testen bereitgestellt. Aber wenn's Dir so wichtig ist: openSUSE wurde als Referenzplattform auserkoren und OBS erstellt auch ständig neue Live-ISOs.
Schau mal in die Archive der KDEPIM-Mailingliste. So sicher, dass KMail2 mit SC 4.6 ausgeliefert wird, ist's nämlich gar nicht mal.
Das Projekt krankt im Moment stark. Die Entwickler arbeiten alle für eine einzige Firma und dieser Firma ist Kontact für MeeGo-Smartphones wichtiger. Würde mich nicht wundern, wenn die Distributoren weiter Kontact 4.4 ausliefern -- wird ja nichtumsonst weiter mit Bugfixes versorgt.
Ich hab mich seit kurzem dem KDE trinity Projekt angeschlossen und stelle unter anderem einen Mirror zur verfügung. Ich selbst benutze es und entwickel mit. Nachdem wir die offenen Bugs behoben haben, steht für die nächste große Version steht ein update auf Qt4 an. Außerdem wurden schon diverse Komponenten auf cMake umgestellt. http://trinity.pearsoncomputing.net/
KDE 3.5 hat mit KDE 4.6b2 mehr zu tun als Gnome, XFCE oder E17 mit KDE 4.6b2 zu tun haben, du Nase. Und nein, das hat Nichts mit Nokia zu tun - falls du es noch nicht bemerkt haben solltest: es geht hier um das Aufrechterhalten des KDE 3 Entwicklungszweiges für alle diejenigen, die nicht zum 4er Zweig wechseln wollen. Ein Wechsel zu den von dir genannten Applikationen kommt meistens sowieso nicht in Frage.
Sicher hat KDE 3 mehr mit SC 4 zu tun als mit Gnome, aber wie nett ist es, in einer irgendwann kommenden Nachricht zur aktuellen Version von Trinity einen eigenen Diskussionsfaden zur neuesten Entwicklungsversion von SC 4 aufzumachen?
Ein Update auf Qt4 ist zwar prinzipiell löblich, weil es damit leichter möglich ist, zu paketieren und man zudem von Patches für Qt4 profitiert.
Allerdings sehe ich da doch einige Probleme auf Euch zukommen, da der Sprung von Qt3 auf Qt4 nach meinem Gefühl der größte war in der bisherigen Qt-Historie. Da werden viele viele K-Komponenten extrem umgeschrieben werden... viel Erfolg dabei dennoch.
Dennoch freue ich mich auf die nächste KDE SC KDE3 war toll, ich vermisse es aber nicht mehr, sondern liebe die 4er Serie mittlerweile seit längerer Zeit (ab 4.2).
Vielleicht entwickelt sich ja Trinity auch zu einer leichtgewichtigen Qt DE, für all jene, denen KDE4 zu überladen ist. Sprich KDE3 auf Qt4 portieren und eventuell um einige Funktionen bereinigt, die vielleicht wenig Nutzen bringen aber sehr aufwändig sind.
Ich könnte mir vorstellen, dass es dafür schon eine nicht all zu kleine Nutzerschicht gibt.
Ich hatte mir das vor ein paar Monaten angeschaut, aber dann doch die Finger davon gelassen, weil das nach einer 1- Mann- Veranstaltung aussah, die auch nicht wirklich Zukunft hat, da Qt3 nicht mehr gepflegt wird.
Wenn der Wechsel auf Qt4 erfolgreich verläuft, wäre das ne super Sache!
Toll. Jetzt ist Trinity eine 3-Mann-Veranstaltung. Drei Leute für eine komplette Desktop-Umgebung mit unzähligen Anwendungen. Das kann ja nur gelingen.....
Schön zu hören. Wenn Ende 2011 Debian Lenny mit KDE3 aus dem Support läuft, dann stünde ich wirklich vor einem kleinen Problem. Ich bin Deinem Link gefolgt und habe erfreut festgestellt, dass es einen Trinity-KDE3-Port für Debian Squeeze gibt bzw. geben wird. Ein Glück! Dieser KDE3-Forward-Port müsste jetzt nur noch in die offiziellen Squeeze-Backports wandern.
Klar wird die konservative Debian-Distro ein Projekt offiziell aufnehmen, an dem läppische drei Leute Jahre lang Support für ein Riesenprojekt übernehmen sollen.... klar...
Schau doch mal ins SVN-Repo: http://websvn.kde.org/branches/trinity/ Rasante Entwicklung sieht anders aus... Dann doch lieber die Arbeitszeit darin stecken, KMail2 auf Vordermann zu kriegen und die handvoll (aus KDE3-Sicht) "fehlenden" Plasma-Features nachzurüsten. Aber wenn man sich Interviews von Pearson durchliest, merkt man direkt, dass er die KDE Plasma Workspaces höchstens von Screenshots her kennt. Da stehen so viele Falschaussagen drin, dass man den Typen einfach nicht ernst nehmen kann (angeblich könnte man ja z.B. bei Plasma keine Icons auf dem Desktop ablegen... was'n Schwachsinn...)
Das Unwissen um Plasma ist nicht so schlimm. Wenn man als begeisterter KDE3-Nutzer KDE4 neu erfinden wollte, wäre Plasma das erste, was weggelassen und neu bzw. völlig anders geschrieben werden müsste. Ob das allerdings jemals passieren wird? Das steht doch zu bezweifeln.
Ein Update auf Qt4 ist aber auch nicht wirklich notwendig. KDE3 Trinity verträgt sich nämlich problemlos mit einem bereits installierten KDE4-Desktop und natürlich auch mit QT4. Der Benutzung von KDE3 Trinity zusammen mit aktuellen KDE4-Anwendungen steht so nichts im Wege.
Es ist übrigens auch so, dass OpenSuse (abseits vom Trinityprojekt) selbst noch für die aktuelle 11.3-Distro einen kompletten KDE3 über den Buildservice bereit stellt, der ebenfalls mit einem bereits installierten KDE4-Desktop ohne Probleme zusammenarbeitet. So kann man auch sehr gut ermessen, was mittlerweile besser und was schlechter geworden ist. Nach meinem Dafürhalten sind KDE3-Konsole und sämtliche KDE3-Editoren klar besser als ihre KDE4-Pendants. Demgegenüber hat KDE4-Konqueror als Webbrowser große Fortschritte gegenüber seinem KDE3-Kollegen gemacht. KDE4-K3b ist ein sehr guter Ersatz für KDE3-K3b (es gibt hier keinerlei Verlust an Funktionalität durch die Qt4-Portierung), während ich immer noch Amarok 1.4.10 gegenüber Amarok 2.x bevorzuge.
Diese Vergleichsmöglichkeiten werde ich dank Trinity nun auch noch in Debian Squeeze haben. Vielen Dank dafür.
>> Das Unwissen um Plasma ist nicht so schlimm. Wenn man als begeisterter KDE3-Nutzer KDE4 neu erfinden wollte, wäre Plasma das erste, was weggelassen und neu bzw. völlig anders geschrieben werden müsste. Ob das allerdings jemals passieren wird? Das steht doch zu bezweifeln. < <
Dann erzähl doch mal was du als begeisteter KDE3-Nutzer an Plasma ändern bzw. was du daran "anders schreiben" würdest?
Was stimmt denn aus rein technischer Sicht mit Plama nicht? Dem Plasma-Framework fehlt genau ein Feature, das Kicker noch hatte: Die Ausblend-Buttons. Will Stephenson von SUSE hat das Feature entwickelt, hatte dann aber AFAIK nicht genügend Zeit gehabt, um das schon für KPW 4.6 fertigzustellen, da andere Dinge grad Vorrang. Das wäre aber genau so ein Feature, das die drei Trinity-Leute weiterentwickeln könnten, statt das Rad neu zu erfinden: http://reviewboard.kde.org/r/3121/
Ich könnte hier jetzt wieder endlos herummeckern und KDE3 mit KDE4 vergleichen. Es ist aber alles schon gesagt, das macht keinen Sinn. Abseits von aller Kritik ist KDE4 allerdings gut benutzbar, jedoch nicht auf älterer Hardware. Letztendlich fehlt meiner persönlichen Meinung nach ein Plasma-Ersatz. Man kann Plasma zur Zeit leider nicht so austauschen wie z.B. KWin gegen OpenBox. Dass Trinity so etwas entwickeln wird, halte ich aber für eher unwahrscheinlich.
Du kannst die Frage nach den angeblichen technischen Defiziten von Plasma nicht beantworten. Sag' es doch gleich, dass Du dazu nicht in der Lage bist, an einer kleinen 3MB-Bibliothek fundiert Kritik zu üben und Du einfach nur aus stumpfer Antipathie Plasma nicht magst.
Von völlig_unnötige_und_obsolete_D am Di, 14. Dezember 2010 um 00:26 #
Das hat mit angeblich "technisch sinnvoll" nichts zu tun. Plasma ist mir von Anbeginn ein Graus gewesen (seit KDE 4.0), rein aus Benutzungsgründen. Wofür ich in KDE3 einen Mausklick/eine Aktion brauchte, benötig(t)e ich in KDE4 oft wenigstens zwei oder mehr. Von den regelmäßigen Plasma-Abstürzen (bis einschließlich KDE 4.2) ganz zu schweigen. Ich habe hierzu schon oft genug kommentiert. Die ständigen Wiederholungen bringen nichts. Du kannst Dir ja die Prolinuxarchive durchlesen, hier tauchen sämtliche Argumente auf.
Wenn man also KDE3 auf Qt4 erneut portieren wollte, dann müßte man das IMO unter völliger Verwerfung des Plasmakonzeptes tun, das ich ganz persönlich für einen Designfehler halte. Eine Mitarbeit am eigentlichen KDE4-Projekt wäre in diesem Fall also gar nicht möglich. Ob man überhaupt die Fähigkeiten, die Zeit und die Manpower zu solch einer Anstrengung besäße, das steht natürlich auf einem ganz anderen Blatt.
Du hast also kein einziges technisches Argument. Du beschränkst Dich auf "Benutzungsgründe", die kein Argument gegen Plasma sind. Das ist ein Argument dafür, dass die Trinity-Leute Veränderungen an der Plasma-Oberfläche vornehmen sollten, statt den ganzen alten Rotz zu forken.
Mein Eindruck ist eher, dass viele User das Konzept hinter Plasma bis heute nicht verstanden haben und es auch nicht verstehen wollen. Sie denken immer noch in den traditionellen Bahnen (die die aktuelle Beispielkonfiguration von Plasma am KDE4-Desktop auch bedient). Plasma ist extrem modular und fast beliebig konfigurier- und anpassbar. Allein deshalb gibt es schon Oberflächen für Netbooks und Smartphones ohne alles neu programmieren zu müssen. Das ist ein wesentlicher Vorteil. Das konnte der alte Desktop mit kicker und kdesktop nicht leisten. Nicht flexibel genug. Ich gebe dem Trinity-Projekt keine langen Überlebenschancen. Dennoch viel Erfolg dafür!
"Mein Eindruck ist eher, dass viele User das Konzept hinter Plasma bis heute nicht verstanden haben und es auch nicht verstehen wollen."
Mir ist schleierhaft, wie Ihr als KDE4-Begeisterte annehmen könnt, dass sich der Großteil der Nutzer länger als zehn Sekunden mit dem Plasma- bzw. KDE4-Desktop beschäftigt. Entweder er "funktioniert" so wie er ist oder aber man lehnt ihn ab.
"Sie denken immer noch in den traditionellen Bahnen (die die aktuelle Beispielkonfiguration von Plasma am KDE4-Desktop auch bedient)"
Die meisten Nutzer ändern diese Standardkonfiguration gar nicht. Von daher empfinde ich die Kritik, "dass viele User das Konzept hinter Plasma bis heute nicht verstanden haben und es auch nicht verstehen wollen", unberechtigt. Ihr habt "das Neue", das mit Plasma kommt, doch gerade aus Angst vor einer möglicherweise zu negativen Nutzerreaktion in einer Art "Traditioneller Desktop-Schafspelz" versteckt. Nur zu, stellt die Plasmafähigkeiten mehr in den Mittelpunkt.
>Mir ist schleierhaft, wie Ihr als KDE4-Begeisterte annehmen könnt, dass sich der Großteil der Nutzer länger als zehn Sekunden mit dem Plasma- bzw. KDE4-Desktop beschäftigt. Entweder er "funktioniert" so wie er ist oder aber man lehnt ihn ab.
Richtig, muss man nicht. Der Desktop funktioniert auch ohne zu wissen, wie Plasma das erledigt. Mein Kommentar bezieht sich auf die User, die Plasma als "Dreck" bezeichnen. Da dies eine Wertung ist, gehe ich davon aus, dass man sich minimal mit Plasma auseinandergesetzt hat. Insofern ist meine Kritik allemal berechtigt, wenn sich dann herausstellt, dass man zwar etwas bewertet hat, aber sich die Mühe zum Verständnis erspart hat. Dabei sei jedem eine Wertung erlaubt. Ob er nun sich die Mühe zum Verständnis gemacht hat, oder nicht. Wenn nicht, ist es halt nur labern oder sogar trollen.
Update auf Qt 4, Wechsel auf CMake.... klingt nach KDE SC 4 mit Kicker, statt Plasma. Ist alles sicher auch weniger Arbeit, als einfach die paar fehlenden Plasma-Features dort nachzurüsten....
Jepp, und MS4 läuft bei mir auch ganz rund (bekomme sogar 3D für Intels GMA-Grafikchips, was ich bei den aktuellen stabilen Distros nicht hingekriegt habe). Ich denke, spätestens morgen sind auch die Pakete für Beta2 im Repository.
"Die SUSE - LIVE CD funktionier bei mir nie, weder auf Virtualbox noch nativ gebootet. Ich kriege nie ein X."
Vielleicht irgendein NVidia-Chip, den Nouveau noch nicht ansprechen kann? Oder ein Monitorerkennungsproblem? Virtualbox hat manchmal temporäre Probleme mit neuesten Linuxversionen.
Es ist mittlerweile der Hauptnachteil von OpenSuse, dass es keine richtigen Installations-CDs mehr gibt, die z.B. wie die Ubuntu-Alternate- bzw. Debian-Installations-CDs funktionieren und gegebenenfalls nur noch die Sprachpakete aus dem Internet nachladen müssen.
LIve-CDs sind einfach zu störanfällig und benötigen viel zu viel Ressourcen. So macht eine OpenSuse-LXDE-Live-CD kaum Sinn, die etwa 1GB RAM zum reibungslosen Funktionieren braucht.
Die OpenSuse-Netzwerkinstallations-CD umfasst nur knapp über 100MB, man müßte also bei jeder Installation fast alles komplett aus dem Internet herunterladen.
Andererseits: Warum sollte man eine 4,4GB-DVD herunterladen, nur um OpenSuse auszuprobieren?
Es fehlt hier der goldene Mittelweg, eine 700MB-Installations-Nicht-Live-CD.
Folge: Bevor man sich damit herumschlägt, installiert man lieber gleich Debian oder Ubuntu.
Für OpenSuse ist das besonders schade, weil OpenSuse nach der Installation immer einen sog. Failsafe-Modus anbietet, mit dem man fast jeden Rechner zumindest hochfahren kann.
Von gerdmitpferd am Sa, 11. Dezember 2010 um 10:10 #
Bei opensuse kannst Du:
1. Bei der live-CD beim bootloader ein init 3 eingeben. Dann landest du auf der konsole und kannst das live-image per yast instalieren.
2. Bei der NET-CD und der Installations-DVD kannst Du im bootloader den TEXT-Modus auswählen (Kann sein das das bei der Live auch geht)
Ist zwar nicht so bunt aber es geht wunderbar.
Die live-CD hat den Vorteil, wenn Dein X läuft, das Du wlan in Betrieb nehmen kannst über den Networkmanager. Kannst also, bei entsprechender Rechnerperfomance nebenher "arbeiten"
Ich selber benutze auf unterschiedlichen Rechnern, ArchLinux Gentoo opensuse Kubuntu Fedora und habe auch Debian schon ausprobiert.
Normalerweise schreibt man einmal ein Skript, und dann kann man das regelmässig automatisch bauen, bis es dann mal nicht mehr baut. Dann gibt es ein Problem mit dem Skript oder dem Code. Nightly Builds.
...mir grauts jetzt schon.
Ich bin zwar absoluter KDE Fan aber die letzten Jahre waren doch eine harte Geduldsprope. In 4.6 wird wohl KDEPIM endlich auf Akonadi umsteigen. Darauf warte ich im Prinzip schon sehr lange aber es wird wohl wieder auf kryptische Akonadi-Fehlermeldungen hinauslaufen. Besonders wenn man etwas exotischere Konfigurationen verwendet wie z.B. Disconnected IMAP und IMAP-Storage um Termine und Kontakte ebenfalls auf dem IMAP-Server zu speichern.
KDE sollte wirklich ihre Beta- und RC-Versionen als einfach zu installierende Pakete für die gängigsten Distributionen anbieten. Dann würden die Bugs vielleicht auch mal vor der Release gefunden werden.
Akonadi ist echt KDE zum abkotzen!
Akonadi ist ein Synonym für crashes und Datenverlust.
niemand
..mit Soße
Also ich habe die beta1 vor einer Woche mal getestet. Vor allem KMail mit Akonadi über meinen IMAP-Account meiner Firma. Zusätzlich auch den Kalender mit ical, wo ich neben meinem persönlichen Kalender auch die Belegungen der Meeting-Räume in weiteren Kalendern eingebunden habe. In der Firma benutzen wir für die Mails und Termine "Zimbra".
Ich war überrascht dass es doch ganz ordentlich lief. Mein erster Test über Akonadi vor einigen Monaten endete da oft in einigen Fehlermeldungen und 100% ausgelastetem Akonadi. Aktuell hingegen ist es zwar nicht das schnellste, aber dafür doch recht stabil. Fehlermeldungen hatte ich noch keine.
Was ich aber schon mal als einen Vorteil der Akonadi-Anbindung sehe, ist dass sich KMail nun endlich auch dann Benutzen lässt, auch wenn im Hintergrund die Konten abgerufen werden. Bisher musste ich da vor allem daheim immer warten bis KMail alles abgerufen hatte.
Kann das vom Vorposter nur bestätigen! Nutze ebenfalls schon die 1. und nun auch die 2.Beta und bin Positiv überrascht wie Akonadi mit Kmail samt Gefolge trotz des Beta Status zusammen arbeitet. Funktioniert soweit recht ordentlich das ganze!
"KDE sollte wirklich ihre Beta- und RC-Versionen als einfach zu installierende Pakete für die gängigsten Distributionen anbieten."
Das Bereitstellen von Paketen ist die ureigenste Aufgabe der Distributionen, und manche, wie OpenSuse oder Arch, kriegen es ja auch problemlos hin.
Zum Thema: Ich habe Beta1 ein bisschen getestet, läuft für eine Beta ziemlich rund, zudem setzt sie bei mir auf einer Distributions-Alpha (OpenSuse 11.4 Milestone 4) auf. Auf Akonadi in Beta2 bin ich gespannt, bisher hatte ich da ein Problem mit der Aktualisierung meines IMAP-Kontos.
Nee danke, bevor ich die Distri wechsele, wechsele ich lieber das DE.
Außerdem - wenn das Zeug auf Deiner Hardware läuft, heißt das noch lange nicht, daß es auch auf anderer Leute Rechner einwandfrei läuft.
Das ist mir als "Kunde" völlig egal wessen Aufgabe das ist. Da es viele Distributionen nunmal nicht machen sollte es im Interesse von KDE sein, selbst Pakete bereitzustellen. Schliesslich ist es deren Ruf, der unter den ganzen Bugs leidet.
Ich bin ja gerne mal bereit eine Beta zu testen und Bugs zu melden. Allerdings werde ich dafür nicht den Compiler anwerfen. Sollte sich 4.6 als Katastrophe herausstellen, wechsle ich einfach wieder zurück zu 4.5. Für mich als User macht das weniger einen Unterschied. KDE hingegen darf dann mit der schlechten Presse leben und das alles nur, weil nicht genug Leute die neue Release testen konnten.
Es gibt kaum eine Distribution, die entsprechende Pakete nicht anbietet und die sind genau da wo sie hingehören: im Entwicklungszweig der jeweiligen Distribution.
Willst du also KDE 4.6 Beta testen, empfiehlt es sich so oder so, dafür eine eigenes System zu nutzen anstatt mit dem Produktivsystem zu arbeiten und dann kannst du auch dort gleich den gesamten Entwicklungszweig nutzen.
Ich gehe im Übrigen davon aus, dass das Bereitstellen von Paketen für die gängigsten Distributionen für eine stabile Version dieser Distribution keinen Nennenswerten Vorteil bringen würde.
Die meisten die KDE testen, Bugs finden und melden wollen, tun das im Zuge der Entwicklung ihrer bevorzugten Distribution. Diejenigen, die KDE Beta auf einer stabilen Distribution nutzen würden, würden es kurz testen/nutzen aber kaum Feedback geben. Ausnahmen mag es geben aber das dürfte ein vernachlässigbarer Teil sein.
Und dann übersteigt der Aufwand den Nutzen um Weiten.
Gruß
Dann gucke doch mal in die Praxis, Clementine (Amarok 1.4+) rockt
http://code.google.com/p/clementine-player/
weil man ständig baut.
Amarok 2.x läuft auch nur, wenn man viel baut, was mittlerweile auch passiert.
Dank Buildservern und Builtbots geht heute viel mehr als früher. Wenn man viel baut, werden die ganzen Fehler schon in der betaphase gefunden, weil die Leute mehr testen und mehr Fehler finden.
Das Typische ist doch die Live-CD bei der man innerhalb von 2 Minuten Fehler im Programm findet. Leider ist die Live-CD erst für den release candidate da.
"Kunde" gibts nicht - mach es selbst statt zu motzen..
dies Haltung ist Doof ³ : nix Begriffen - zu Faul zum helfen - aber schnell beim Motzen
"Das Bereitstellen von Paketen ist die ureigenste Aufgabe der Distributionen, und manche, wie OpenSuse oder Arch, kriegen es ja auch problemlos hin."
Quatsch mit Soße. Ein Projekt ohne Referenzkompilate ist Unsinn. Heute gibt es Build-Server. Code ist ja nur immer nur die Quelle des Kompilats.
Die Distributoren kümmern sich darum, dass alles zusammenspielt.
Das ist so ähnlich wie bei Xorg. Auch dort gibt es keine Binaries mehr wie noch zu XFree-Zeiten.
Folge: Fast alle Nutzer testen keine Xorg-Originalsoftware mehr.
KDE hat noch nie Binaries zum Testen bereitgestellt. Aber wenn's Dir so wichtig ist: openSUSE wurde als Referenzplattform auserkoren und OBS erstellt auch ständig neue Live-ISOs.
Schau mal in die Archive der KDEPIM-Mailingliste. So sicher, dass KMail2 mit SC 4.6 ausgeliefert wird, ist's nämlich gar nicht mal.
Das Projekt krankt im Moment stark. Die Entwickler arbeiten alle für eine einzige Firma und dieser Firma ist Kontact für MeeGo-Smartphones wichtiger.
Würde mich nicht wundern, wenn die Distributoren weiter Kontact 4.4 ausliefern -- wird ja nichtumsonst weiter mit Bugfixes versorgt.
Ich hab mich seit kurzem dem KDE trinity Projekt angeschlossen und stelle unter anderem einen Mirror zur verfügung. Ich selbst benutze es und entwickel mit. Nachdem wir die offenen Bugs behoben haben, steht für die nächste große Version steht ein update auf Qt4 an. Außerdem wurden schon diverse Komponenten auf cMake umgestellt.
http://trinity.pearsoncomputing.net/
Nett.
Gnome lebt auch: www.gnome.org
Und XFCE: www.xfce.org
Enlightenment nicht zu vergessen: www.enlightenment.org
Und und und...
Und was hat das jetzt mit KDE SC 4.6b2 zu tun? Eben.
KDE 3.5 hat mit KDE 4.6b2 mehr zu tun als Gnome, XFCE oder E17 mit KDE 4.6b2 zu tun haben, du Nase. Und nein, das hat Nichts mit Nokia zu tun - falls du es noch nicht bemerkt haben solltest: es geht hier um das Aufrechterhalten des KDE 3 Entwicklungszweiges für alle diejenigen, die nicht zum 4er Zweig wechseln wollen. Ein Wechsel zu den von dir genannten Applikationen kommt meistens sowieso nicht in Frage.
Sicher hat KDE 3 mehr mit SC 4 zu tun als mit Gnome, aber wie nett ist es, in einer irgendwann kommenden Nachricht zur aktuellen Version von Trinity einen eigenen Diskussionsfaden zur neuesten Entwicklungsversion von SC 4 aufzumachen?
+1
Ein Update auf Qt4 ist zwar prinzipiell löblich, weil es damit leichter möglich ist, zu paketieren und man zudem von Patches für Qt4 profitiert.
Allerdings sehe ich da doch einige Probleme auf Euch zukommen, da der Sprung von Qt3 auf Qt4 nach meinem Gefühl der größte war in der bisherigen Qt-Historie. Da werden viele viele K-Komponenten extrem umgeschrieben werden... viel Erfolg dabei dennoch.
Dennoch freue ich mich auf die nächste KDE SC
KDE3 war toll, ich vermisse es aber nicht mehr, sondern liebe die 4er Serie mittlerweile seit längerer Zeit (ab 4.2).
Vielleicht entwickelt sich ja Trinity auch zu einer leichtgewichtigen Qt DE, für all jene, denen KDE4 zu überladen ist.
Sprich KDE3 auf Qt4 portieren und eventuell um einige Funktionen bereinigt, die vielleicht wenig Nutzen bringen aber sehr aufwändig sind.
Ich könnte mir vorstellen, dass es dafür schon eine nicht all zu kleine Nutzerschicht gibt.
Gruß
Die Frage ist eher, ob es da eine (ausreichend) starke Entwicklerschaft gibt
Lies Dir mal Interviews vom Projektgründer Timothy Pearson durch.
Der hat Trinity gegründet, weil SC4 seiner Meinung nach zu wenige Features hat.
Ich hatte mir das vor ein paar Monaten angeschaut, aber dann doch die Finger davon gelassen, weil das nach einer 1- Mann- Veranstaltung aussah, die auch nicht wirklich Zukunft hat, da Qt3 nicht mehr gepflegt wird.
Wenn der Wechsel auf Qt4 erfolgreich verläuft, wäre das ne super Sache!
Toll. Jetzt ist Trinity eine 3-Mann-Veranstaltung.
Drei Leute für eine komplette Desktop-Umgebung mit unzähligen Anwendungen. Das kann ja nur gelingen.....
Schön zu hören.
Wenn Ende 2011 Debian Lenny mit KDE3 aus dem Support läuft, dann stünde ich wirklich vor einem kleinen Problem.
Ich bin Deinem Link gefolgt und habe erfreut festgestellt, dass es einen Trinity-KDE3-Port für Debian Squeeze gibt bzw. geben wird.
Ein Glück!
Dieser KDE3-Forward-Port müsste jetzt nur noch in die offiziellen Squeeze-Backports wandern.
Klar wird die konservative Debian-Distro ein Projekt offiziell aufnehmen, an dem läppische drei Leute Jahre lang Support für ein Riesenprojekt übernehmen sollen.... klar...
Schau doch mal ins SVN-Repo: http://websvn.kde.org/branches/trinity/
Rasante Entwicklung sieht anders aus...
Dann doch lieber die Arbeitszeit darin stecken, KMail2 auf Vordermann zu kriegen und die handvoll (aus KDE3-Sicht) "fehlenden" Plasma-Features nachzurüsten.
Aber wenn man sich Interviews von Pearson durchliest, merkt man direkt, dass er die KDE Plasma Workspaces höchstens von Screenshots her kennt. Da stehen so viele Falschaussagen drin, dass man den Typen einfach nicht ernst nehmen kann (angeblich könnte man ja z.B. bei Plasma keine Icons auf dem Desktop ablegen... was'n Schwachsinn...)
Das Unwissen um Plasma ist nicht so schlimm. Wenn man als begeisterter KDE3-Nutzer KDE4 neu erfinden wollte, wäre Plasma das erste, was weggelassen und neu bzw. völlig anders geschrieben werden müsste.
Ob das allerdings jemals passieren wird? Das steht doch zu bezweifeln.
Ein Update auf Qt4 ist aber auch nicht wirklich notwendig.
KDE3 Trinity verträgt sich nämlich problemlos mit einem bereits installierten KDE4-Desktop und natürlich auch mit QT4.
Der Benutzung von KDE3 Trinity zusammen mit aktuellen KDE4-Anwendungen steht so nichts im Wege.
Es ist übrigens auch so, dass OpenSuse (abseits vom Trinityprojekt) selbst noch für die aktuelle 11.3-Distro einen kompletten KDE3 über den Buildservice bereit stellt, der ebenfalls mit einem bereits installierten KDE4-Desktop ohne Probleme zusammenarbeitet.
So kann man auch sehr gut ermessen, was mittlerweile besser und was schlechter geworden ist. Nach meinem Dafürhalten sind KDE3-Konsole und sämtliche KDE3-Editoren klar besser als ihre KDE4-Pendants. Demgegenüber hat KDE4-Konqueror als Webbrowser große Fortschritte gegenüber seinem KDE3-Kollegen gemacht. KDE4-K3b ist ein sehr guter Ersatz für KDE3-K3b (es gibt hier keinerlei Verlust an Funktionalität durch die Qt4-Portierung), während ich immer noch Amarok 1.4.10 gegenüber Amarok 2.x bevorzuge.
Diese Vergleichsmöglichkeiten werde ich dank Trinity nun auch noch in Debian Squeeze haben. Vielen Dank dafür.
>> Das Unwissen um Plasma ist nicht so schlimm. Wenn man als begeisterter KDE3-Nutzer KDE4 neu erfinden wollte, wäre Plasma das erste, was weggelassen und neu bzw. völlig anders geschrieben werden müsste.
Ob das allerdings jemals passieren wird? Das steht doch zu bezweifeln. < <
Dann erzähl doch mal was du als begeisteter KDE3-Nutzer an Plasma ändern bzw. was du daran "anders schreiben" würdest?
Was stimmt denn aus rein technischer Sicht mit Plama nicht?
Dem Plasma-Framework fehlt genau ein Feature, das Kicker noch hatte: Die Ausblend-Buttons.
Will Stephenson von SUSE hat das Feature entwickelt, hatte dann aber AFAIK nicht genügend Zeit gehabt, um das schon für KPW 4.6 fertigzustellen, da andere Dinge grad Vorrang.
Das wäre aber genau so ein Feature, das die drei Trinity-Leute weiterentwickeln könnten, statt das Rad neu zu erfinden: http://reviewboard.kde.org/r/3121/
Ich könnte hier jetzt wieder endlos herummeckern und KDE3 mit KDE4 vergleichen.
Es ist aber alles schon gesagt, das macht keinen Sinn. Abseits von aller Kritik ist KDE4 allerdings gut benutzbar, jedoch nicht auf älterer Hardware.
Letztendlich fehlt meiner persönlichen Meinung nach ein Plasma-Ersatz. Man kann Plasma zur Zeit leider nicht so austauschen wie z.B. KWin gegen OpenBox. Dass Trinity so etwas entwickeln wird, halte ich aber für eher unwahrscheinlich.
Du kannst die Frage nach den angeblichen technischen Defiziten von Plasma nicht beantworten. Sag' es doch gleich, dass Du dazu nicht in der Lage bist, an einer kleinen 3MB-Bibliothek fundiert Kritik zu üben und Du einfach nur aus stumpfer Antipathie Plasma nicht magst.
Das hat mit angeblich "technisch sinnvoll" nichts zu tun.
Plasma ist mir von Anbeginn ein Graus gewesen (seit KDE 4.0), rein aus Benutzungsgründen. Wofür ich in KDE3 einen Mausklick/eine Aktion brauchte, benötig(t)e ich in KDE4 oft wenigstens zwei oder mehr.
Von den regelmäßigen Plasma-Abstürzen (bis einschließlich KDE 4.2) ganz zu schweigen.
Ich habe hierzu schon oft genug kommentiert.
Die ständigen Wiederholungen bringen nichts.
Du kannst Dir ja die Prolinuxarchive durchlesen, hier tauchen sämtliche Argumente auf.
Wenn man also KDE3 auf Qt4 erneut portieren wollte, dann müßte man das IMO unter völliger Verwerfung des Plasmakonzeptes tun, das ich ganz persönlich für einen Designfehler halte. Eine Mitarbeit am eigentlichen KDE4-Projekt wäre in diesem Fall also gar nicht möglich.
Ob man überhaupt die Fähigkeiten, die Zeit und die Manpower zu solch einer Anstrengung besäße, das steht natürlich auf einem ganz anderen Blatt.
Du hast also kein einziges technisches Argument. Du beschränkst Dich auf "Benutzungsgründe", die kein Argument gegen Plasma sind. Das ist ein Argument dafür, dass die Trinity-Leute Veränderungen an der Plasma-Oberfläche vornehmen sollten, statt den ganzen alten Rotz zu forken.
Mein Eindruck ist eher, dass viele User das Konzept hinter Plasma bis heute nicht verstanden haben und es auch nicht verstehen wollen. Sie denken immer noch in den traditionellen Bahnen (die die aktuelle Beispielkonfiguration von Plasma am KDE4-Desktop auch bedient). Plasma ist extrem modular und fast beliebig konfigurier- und anpassbar. Allein deshalb gibt es schon Oberflächen für Netbooks und Smartphones ohne alles neu programmieren zu müssen. Das ist ein wesentlicher Vorteil. Das konnte der alte Desktop mit kicker und kdesktop nicht leisten. Nicht flexibel genug. Ich gebe dem Trinity-Projekt keine langen Überlebenschancen. Dennoch viel Erfolg dafür!
"Mein Eindruck ist eher, dass viele User das Konzept hinter Plasma bis heute nicht verstanden haben und es auch nicht verstehen wollen."
Mir ist schleierhaft, wie Ihr als KDE4-Begeisterte annehmen könnt, dass sich der Großteil der Nutzer länger als zehn Sekunden mit dem Plasma- bzw. KDE4-Desktop beschäftigt. Entweder er "funktioniert" so wie er ist oder aber man lehnt ihn ab.
"Sie denken immer noch in den traditionellen Bahnen (die die aktuelle Beispielkonfiguration von Plasma am KDE4-Desktop auch bedient)"
Die meisten Nutzer ändern diese Standardkonfiguration gar nicht. Von daher empfinde ich die Kritik, "dass viele User das Konzept hinter Plasma bis heute nicht verstanden haben und es auch nicht verstehen wollen", unberechtigt. Ihr habt "das Neue", das mit Plasma kommt, doch gerade aus Angst vor einer möglicherweise zu negativen Nutzerreaktion in einer Art "Traditioneller Desktop-Schafspelz" versteckt.
Nur zu, stellt die Plasmafähigkeiten mehr in den Mittelpunkt.
>Mir ist schleierhaft, wie Ihr als KDE4-Begeisterte annehmen könnt, dass sich der Großteil der Nutzer länger als zehn Sekunden mit dem Plasma- bzw. KDE4-Desktop beschäftigt. Entweder er "funktioniert" so wie er ist oder aber man lehnt ihn ab.
Richtig, muss man nicht. Der Desktop funktioniert auch ohne zu wissen, wie Plasma das erledigt. Mein Kommentar bezieht sich auf die User, die Plasma als "Dreck" bezeichnen. Da dies eine Wertung ist, gehe ich davon aus, dass man sich minimal mit Plasma auseinandergesetzt hat. Insofern ist meine Kritik allemal berechtigt, wenn sich dann herausstellt, dass man zwar etwas bewertet hat, aber sich die Mühe zum Verständnis erspart hat. Dabei sei jedem eine Wertung erlaubt. Ob er nun sich die Mühe zum Verständnis gemacht hat, oder nicht. Wenn nicht, ist es halt nur labern oder sogar trollen.
Der Ansatz mit Clementine, dem Port von Amarok 1.4 ist auch nicht schlecht.
http://www.clementine-player.org/
Bitte wechselt doch auf GIT. Dann macht es auch Spass!
Update auf Qt 4, Wechsel auf CMake.... klingt nach KDE SC 4 mit Kicker, statt Plasma.
Ist alles sicher auch weniger Arbeit, als einfach die paar fehlenden Plasma-Features dort nachzurüsten....
Gibts mittlerweile auch eine Live-CD mit KDE 4.6 Beta1/2?
KDE FOUR LIVE bietet keine an
Die Entwicklerversion von openSUSE 11.4 hat KDE4.6 (Beta 1) dabei und die gibt es unter
http://software.opensuse.org/developer/de
als live version.
Jepp, und MS4 läuft bei mir auch ganz rund (bekomme sogar 3D für Intels GMA-Grafikchips, was ich bei den aktuellen stabilen Distros nicht hingekriegt habe). Ich denke, spätestens morgen sind auch die Pakete für Beta2 im Repository.
Die SUSE - LIVE CD funktionier bei mir nie, weder auf Virtualbox noch nativ gebootet. Ich kriege nie ein X.
"Die SUSE - LIVE CD funktionier bei mir nie, weder auf Virtualbox noch nativ gebootet. Ich kriege nie ein X."
Vielleicht irgendein NVidia-Chip, den Nouveau noch nicht ansprechen kann? Oder ein Monitorerkennungsproblem?
Virtualbox hat manchmal temporäre Probleme mit neuesten Linuxversionen.
Es ist mittlerweile der Hauptnachteil von OpenSuse, dass es keine richtigen Installations-CDs mehr gibt, die z.B. wie die Ubuntu-Alternate- bzw. Debian-Installations-CDs funktionieren und gegebenenfalls nur noch die Sprachpakete aus dem Internet nachladen müssen.
LIve-CDs sind einfach zu störanfällig und benötigen viel zu viel Ressourcen. So macht eine OpenSuse-LXDE-Live-CD kaum Sinn, die etwa 1GB RAM zum reibungslosen Funktionieren braucht.
Die OpenSuse-Netzwerkinstallations-CD umfasst nur knapp über 100MB, man müßte also bei jeder Installation fast alles komplett aus dem Internet herunterladen.
Andererseits: Warum sollte man eine 4,4GB-DVD herunterladen, nur um OpenSuse auszuprobieren?
Es fehlt hier der goldene Mittelweg, eine 700MB-Installations-Nicht-Live-CD.
Folge: Bevor man sich damit herumschlägt, installiert man lieber gleich Debian oder Ubuntu.
Für OpenSuse ist das besonders schade, weil OpenSuse nach der Installation immer einen sog. Failsafe-Modus anbietet, mit dem man fast jeden Rechner zumindest hochfahren kann.
Bei opensuse kannst Du:
1. Bei der live-CD beim bootloader ein init 3 eingeben.
Dann landest du auf der konsole und kannst das live-image per yast instalieren.
2. Bei der NET-CD und der Installations-DVD kannst Du im bootloader den TEXT-Modus auswählen (Kann sein das das bei der Live auch geht)
Ist zwar nicht so bunt aber es geht wunderbar.
Die live-CD hat den Vorteil, wenn Dein X läuft, das Du wlan in Betrieb nehmen kannst über den Networkmanager. Kannst also, bei entsprechender Rechnerperfomance nebenher "arbeiten"
Ich selber benutze auf unterschiedlichen Rechnern,
ArchLinux Gentoo opensuse Kubuntu Fedora und habe auch Debian schon ausprobiert.
Alles hat seine Vor und Nachteile
Normalerweise schreibt man einmal ein Skript, und dann kann man das regelmässig automatisch bauen, bis es dann mal nicht mehr baut. Dann gibt es ein Problem mit dem Skript oder dem Code. Nightly Builds.