Ich finde das richtig gut. Ich habe den eindruck schon oft gehabt das KDE einfach zu fett ist. Man bekommt 5 Texteditoren mit und anderen kram wo man vom prinzip nur eins braucht.
>...Diese Größe stellt gleichzeitig auch eigene Probleme dar - nicht jede Applikationen findet einen Einzug in die Core-Distribution von KDE.
und das ist gut so :P
> Viele interessante Programme sind trotz ihres bereits reifen Stadiums immer noch nicht in das Environment integriert worden und werden auch nie den Weg in die Distribution finden.
Und mit einem guten Installer der kde programme auch als soche erkennen würde, könnte man diese programme auch ohne probleme "nach"installieren und zwar NUR die die ich haben will (nicht gleich 2-3 von denne ich eh nur eins nutzen werde)
>Grund dafür ist unter anderem der, dass das KDE-Projekt das Environment nicht mit verschiedenen Anwendungen mit gleichen Funktionen aufblähen will.
Wie jetzt ? Was heist hier will , die machen das doch schon immer so :P
> Es macht auch wenig Sinn, die Distribution mit vier oder mehr Brenn-Front-Ends auszuliefern.
Naja, momentan ist es bei kde doch eher so : Alles oder garnichts . Und mit Selbst compilieren kanns für einen Desktop der damals zumindest auch neulinge ansprechen wollte ja nicht getan sein .
Und mit einem guten Installer der kde programme auch als soche erkennen würde, könnte man diese programme auch ohne probleme "nach"installieren und zwar NUR die die ich haben will
Das ist zwar richtig, aber daran kann KDE leider nichts aendern. KDE selbst stellt lediglich den Source Codes zur Verfuegung, und da ist es einfach sehr viel einfacher, sie in grossen "Haeppchen" zu entwickeln und veroeffentlichen als einzeln. Was die Distributionen dann daraus machen, ist letztenendes deren Sache. AFAIK wird bei Debian ja alles in einzelne Packages zerlegt. Aber solange die Packet-Systeme fuer Linux nicht besser und moeglichst auch zueinander kompatibler werden, ist da von KDE-Seite nicht so viel zu machen. Das liegt eher in der Verantwortung der Distributionen und der low-level Systeme fuer Linux (und andere freie Systeme).
Von Moritz Moeller-Herrmann am Mo, 26. August 2002 um 08:25 #
Was ist denn so toll am loki installer? Das man auf continue klicken muss? RPMS sind benutzerfreundlicher, denn sie kümmern sich im Gegensatz zum LOKI installer um die Abhängigkeiten eines Programmes.
Sinnvoller wäre es kpackage mit apt-get für RPMs aufzubohren (ala synaptic). Dann klickt man auf das RPM und der Installer läd alle benötigten Zusatzpakete automatisch herunter.
Wenn das Linux System LSB Zertifiziert ist, dann gibt es keine Abhängigkeiten !!!
Und in so einem Fall ist der Loki Installer ungemein praktisch und vor allem einfach, was Newbies sicher sehr zu schätzen wissen.
RPM ist zwar nicht schlecht, für Newbies oder Leute die wenig Ahnung von Computern haben oder haben wollen ist RPM zu abstrakt. Der Loki Installer ist intuitiver und gibt ein mehr plastisches und durchschaubares Gefühl für den Newbie der davor sitzt.
Und was soll das eigentlich, wiso klagst du hier herum, für mich klingt das so, als fürchtest du dich davor die vorgefertigen RPM Pakete bei KDE zu verlieren. 1. Wirst du immer deine RPM Pakete von deiner RPM-Distri bekommen. und 2. hast du jederzeit die Möglichkeit so ein Programm von den Sourcen zu isntallieren. Deswegen verstehe ich deine "Schwachfug" Reaktion nicht.
Und dann wären wir noch beim allerletzten Punkt, wer hat davon geredet das man die RPM Pakete bei KDE durch Loki Installer Pakete "ersetzen" soll?
mal ernsthaft, ein deb oder rpm sollte jeder installiert bekommen (gerade, wenn es keine abhaengigkeiten gibt oder sie automatisch aufgeloest werden). wer hat eigentlich mit dem anspruch angefangen, dass jeder etwas schlauere schimpanse linux bedienen keonnen soll?
etwas weniges darf man doch wohl vom user erwarten duerfen...
... nein, sehe ich nicht so. Ich bin der Meinung, desto mehr Schimpansen Linux bedienen kann, je mehr Software wird es dafür geben, u. so wenierg wird ein großer Konzern aus Redmond abkassieren können.
Ich predige es immer wieder: Ein Frontend geschrieben, das aussieht, wie Installshild oder meinetwegen auch wie der Loki-Installer. Das wird aufgerufen, wenn man auf eine RPM klickt, und nicht dieses dumme RPMInst.
Ich glaube nicht, das die GUI das Problem ist, die ist bei deb und RPM eigentlich optimal: du brauchst keine. Wenn du erstmal das RPM ausgewaehlt hast, installiert es sich vollautomatisch. Besser geht es wohl nicht. Das Problem liegt viel eher daran, dass die Pakete nicht vernueftig praesentiert werden (wem sagt schon ein kmail-1.3.1-10.rpm was?), das Dependency-Problem nur teilweise bis gar nicht geloest ist und man fuer jede Distribution (und teilweise sogar fuer jede Version) ein eigenes Packet benoetigt.
"Das ist zwar richtig, aber daran kann KDE leider nichts aendern. KDE selbst stellt lediglich den Source Codes zur Verfuegung, und da ist es einfach sehr viel einfacher, sie in grossen "Haeppchen" zu entwickeln"
Warum ist das so? Ich wuerde mir doch denken, dass es einfacher ist jedes Programmpaket einzeln zu pflegen. Fuer den Benutzer ist es heutzutage auch nicht mehr umstaendlicher, wie man bei GNOME sieht. Man kann sich etweder alles bequem per Script (wie garnome) installieren oder bequem per Paketmanager der moeglichst die Abhaengigkeiten automatisch aufloest. Und dazu kommt eben der enorme Vorteil, dass man sich auch nur das installieren muss, was man wirklich moechte und wenn ein Programm ein wichtiges Update erhalten hat, kann man dieses upgraden ohne gleich ein riesiges Paket neu installieren zu muessen. Ich finde es schon etwas extrem, wenn man sich fuer einen wichtigen Security-Fix den gesamten Desktop neu installieren muss (ausser natuerlich man weiss, wie man einzelne Programme aus den Paketen installiert oder man verwendet Debian).
Die meisten Entwickler haben immer eine komplette HEAD-Version zum entwickeln und zT auch arbeiten. Dadurch ist man einerseits auf dem neusten Stand, und kann andererseits Probleme relativ schnell entdecken. Packete einzelnd zu selektieren waere mir viel zu viel Aufwand... das ich viele Programme habe, die ich nie benutze, ist mir relativ egal: die Programme kosten mich Festplattenplatz im Wert von vielleicht 1-2 Euro... man kann uebrigens auch mit configure einzelne Packete deaktivieren, nur wozu die Arbeit machen? Auch das Installieren von Patches ist kein Problem, make compiliert schliesslich nur die Aenderungen...
"drei CD-Brenner-Frontends" wenn ich das schon wieder lese wird klar, dass man sich offensichtlich da mal wieder nicht auf _ein_ Programm einigen konnte, was dann wirklich auf Top-Qualität gebracht wird - stattdessen kommen 3 Mittelprächtige raus :/
>du hast die Welt der Sofware auch nicht verstanden, oder?
Vielleicht hast Du nur die Welt der _freien_ Software nicht verstanden?
Vielleicht gibt es ja Entwickler, die lieber weiter in Ruhe an ihren Projekten basteln, ohne in die grosse "offizielle" KDE-Tretmuehle zu geraten? Was sollten die KDE-Leute in so einem Fall machen? Sich ein vielversprechendes CD-Brennfrontend schnappen und forken, und dann unter Eigenregie weiterentwickeln? Welchen Sinn haette das?
Ich finde, es sollte das Veryeichnis /opt/kde/userapps/ und /home/user/.kde/userapps (o.ae.) geben, in das neue KDE-Programme einfach per Doppelklick ueber einen einfachen und komfortablen (de)installer reinkopiert und geloescht werden koennen und automatisch einen passenden Eintrag im K-Menue bekommen und mit passenden Dateitypen verknuepft werden, usw. Sprich: Voll integriert werden. Das muss doch irgendwie gehen...
Das Problem ist bekannt, aber leider nicht sooo einfach. Das faengt damit an, dass es derzeit 3 zueinander inkompatible gcc-Versionen gibt und hoert mit unterschiedlichen, inkompatiblen KDE-Versionen auf. Die Lage wird sich vielleicht in 2-3 Jahren stabilisiert haben, aber bis jetzt ist das Aufwand fuer sowas extrem hoch (=zu hoch fuer freie Entwickler, und selbst kommerzielle Firmen wie TheKompany haben es vorlaeufig aufgegeben).
3 zueinander inkompatible gcc-Versionen? Du meinst die geänderte ABI? Weil: Was sich mit dem GCC 3.2 kompilieren lässt, sollte sich doch mit dem GCC 2.95 und 3.0/3.1 kompilieren lassen.
Wäre doch ne Lösung, wenn man eine hübsche Oberfläche für ./configure && make && make install macht, welches das Programm am besten noch gleich in die RPM- bzw. DPKG-Datenbank einträgt. Vielleicht wage ich mich mal an sowas ran, nur mit GTK sind meine Erfahrungen noch recht mässig. ;)
Source-Kompatibilitaet bringt einem fuer benutzerfreundliche Installation relativ wenig. Gerade auf langsameren Computern kann das Compilieren von KDE problemlos einen Tag dauern, und auch groessere einzelne Programme benoetigen ein paar Minuten oder mehr. Mal ganz davon abgesehen, dass beim Compilieren auch SEHR viel schieflaufen kann, und man die daraus resultierenden Fehlermeldungen wohl kaum einem durchschnittlichen User zumuten kann.
Sag das Deinem Distributor und nicht KDE. Jede moderne Distribution macht im übrigen genau das, was Du willst - grafische Installation - was willst Du mehr? Ich verstehe die Kritik echt nicht.
Die Verbreitung der Programme ist auf diese Weise abhaengig davon, ob der Distributor es in die Distribution aufnimmt. Das darf IMO nicht sein. Ich will mir ein Programm direkt vom Entwickler beziehen und es mit einem einzigen Doppelklick und einer Passwortangabe gebrauchsfertig im System integriert haben.
Die RPM-Loesung ist IMO etwas ungluecklich gestaltet. Eine riesige Datenbank an Installierten Paketen, von denen vielleicht 5-10% fuer den User interessant sind ist sehr verwirrend und fuer Neulinge auch abschreckend, weil es verhaeltnismaessig lange dauert, bis das gesuchte Programm gefunden wurde... Programme und wichtige Bibliotheken sollten deshalb etwas besser voneinander getrennt sein. Und warum im selben Zug nicht alle Grafischen Programme gleich von den Konsolenprogrammen trennen? Ich denke dabei insbesondere an die Masse der Mac- und Win-Umsteiger.
Im grossen und ganzen halte ich es fuer wesentlich intuitiver, wenn Programme, die in einem Speziellen Ordner fuer Programme liegen, automatisch installiert sind, eben *weil* sie in diesem Ordner liegen.
Und für wieviele glibcs, Compiler, Plattformen und gerade installierten Bibliotheken sollen Pakete bereitliegen? Das ist nicht machbar, oder soll alles statisch gelinkt sein?
Nein, ich denke der DAU nimmt das, was die Distri mitbringt und jeder andere kann sich die Programme kompilieren.
Entschuldige bitte aber Leute wie Du gehen mir auf den Senkel.
Akzeptiere doch bitte, dass die meisten Open Source Autoren Programme schreiben, weil es Ihnen Spass macht und nicht um das für irgendwelche User beste Programm zu schreiben (außer genau dass macht Ihnen Spass).Ich kann mir tausend Gründe denken, warum es jemandem mehr Spass macht, ein neues, in den Augen der meisten anderen Menschen vielleicht sogar schlechteres, Programm zu schreiben als sich in ein bestehendes Projekt einzuklinken.
So wie ich das verstanden habe soll es jetzt weitere größere Pakete (mit "KEG" gekennzeichnet) geben die man zusätzlich zu den Core Paketen installieren kann.
Das Problem an diesen KEG Paketen ist aber wieder, das man diese wieder komplett installieren muß (wenn man es nicht gerade selber manuel einzeln nach dem compilieren installiert). D.h. man hat dabei nichts gewonnen.
Viel sinnvoller finde ich es, wenn man auf apps.kde.com die guten Programme einzeln heraussucht (was ja anhand den Wertungen leicht möglich ist) und dann einzeln installiert. Das ist für mich der Grund warum ich in diesen KEG Paketen keinen Sinn sehe. Eine Seite die die besten der besten KDE Apps von apps.kde.com auflistet, inklusive Reviews und Screenshots auf denen man auch etwas erkennen kann wäre IMHO sinnvoller.
Und was die Core Pakete betrifft, sollte man diese auch mal etwas entschlacken, oder wenigstens eine einfachere Möglichkeit bieten nur ganz bestimmte Programme zu compilieren und zu installieren. Das würde sich IMHO sehr einfach über das ./configure Script realisieren lassen, wo man einfach beim starten von ./configure mitangibt, welche Pakete compiliert und installiert werden sollen. (so eine ./configure Option wie beim ALSA-driver Paket die Treiber)
Ich weiß das es die Möglichkeit gibt, einzeln in jedes Unterverzeichnis bei den Sourcepacketen zu gehen und dann von dort aus ein "make && make install" auszuführen. Aber das habe ich einmal gemacht und das ist eine ziemliche umständliche Fummelei und sehr Zeitaufwendig.
Viel lieber wäre mir daher eine Möglichkeit via ./configure die zu installierenden Programme anzugeben. Das könnte z.b. so aussehen:
$ cd kde-games-3.0.x $ ./configure --with "Ktron KSnake KSokoban KMines" $ make $ checkinstall
Dabei werden dann nur diese 4 Programme compiliert und zu einem einzigen Paket zusammengeschnürt. Wenn man das System sowiso selber compiliert ist das zusammenschnüren kein großes Problem und ist so gesehen ein guter Kompromiss zwischen "einfach alles" oder jedes Programm umständlich aber dafür einzeln zu installieren.
Schreib Dir doch ein Skript, das im richtigen Verzeichnis make uninstall ausführt. Bei den heutigen Plattenpreisen nehme ich alle Programme und blende im Startmenü die unwichtigen aus. Der normale User überlässt seiner Distribution die Programmauswahl, von daher verstehe ich die Nörglerei _überhaupt_ nicht. Es ist ja nicht so, daß mehr installierte Programme KDE langsamer machen würden, oder?
Das Skript schreiben ist zwar ne gute Idee, aber soll das wirklich jeder machen?
IMHO sollte man das Problem an der Wurzel anpacken und gleich die KDE Pakete mit so einem Skript ausstatten. Und wenn man dann soweit ist, dann kann man gleich ./configure anpassen.
"Bei den heutigen Plattenpreisen nehme ich alle Programme und blende im Startmenü die unwichtigen aus." Diese Option habe ich leider nicht. Manchmal sitze ich vor einem alten P2 Rechner und der hat nur ne 3 GB Platte, da brauche ich jeden Platz.
Der normale User überlässt seiner Distribution die Programmauswahl, von daher verstehe ich die Nörglerei _überhaupt_ nicht. 1. Was ist ein normaler User? 2. Kann ich nicht bestätigen. Ich kenne Leute die sind absolute Anfänger was Computer und Linux betrifft. Und die finden schon die Standardinstallation von Suse 7.3 überladen. Was man natürlich auch verstehen kann, wozu benötigt man 6 verschiedene Text-Editoren. Außerdem gibt es Distributoren die die KDE Pakete nicht aufsplitten. D.h. da muß man dann die einzelnen Core Pakete komplett installieren oder gar nicht.
"Es ist ja nicht so, daß mehr installierte Programme KDE langsamer machen würden, oder? Nein, aber sie benötigen unnötig viel Platz. Und die unnötigen Programme aus dem Startmenü auszublenden ist zu Zeitaufwendig. Zuletzt klingt sowas ja auch noch wie die Windows Internet Explorer lösung: Wenn man den IE nicht mag, dann entfernt man ihn einfach aus seinem Startmenü, der Quicklaunch Leiste und dem Desktop.
>> Viel sinnvoller finde ich es, wenn man auf apps.kde.com die guten Programme einzeln heraussucht (was ja anhand den Wertungen leicht m?glich ist) und dann einzeln installiert. <<
So aehnlich ist es doch gedacht: die jeweils besten der verschiedenen vorhandenen "flavours" werden als ein (dann hoffentlich etwas kleineres) "kdebase-extended" (da musste ich jetzt auch lachen) rausgebracht. Gut - es nimmt Dir jemand die Entscheidung ab, welches Paket denn nun "das beste" ist :(
Aber >> Und was die Core Pakete betrifft, sollte man diese auch mal etwas entschlacken << genau das passiert doch dabei.
Um ehrlich zu sein, wusste ich aber bisher nicht, dass man die ganzen Teile nicht auch einzeln bekommen kann - bei debian muss ich (wie oben erwaehnt) jedenfalls nicht das ganze kdenetwork installieren.
Ich glaube nicht, dass man das ./configure script nochweiter verkomplizieren sollte. Wie waere es mit einem separatem Script, dem man die Namen der zu compilieren und installierenden Programme uebergibt und Abhaengigkeiten automatisch aufloest. Das Script muesste nur in die entsprechenen Verzeichnisse gehen und "make install" aufrufen.
Hmm, jetzt braucht man nur noch einen, der so ein Script schreibt und die Abhaengigkeiten wartet... Wie waere es mit dir?
Der deutsche/Pro-Linux.de Bericht ist irreführend. Diese CVS-Module sind nicht für Benutzer eingeführt worden (damit sie als ein großes Modul released werden), sondern sind an Entwickler gerichtet.
> So wie ich das verstanden habe soll es jetzt weitere größere Pakete (mit "KEG" gekennzeichnet) geben die man zusätzlich zu den Core Paketen installieren kann.
Ich kann Dich beruhigen, dass Du das falsch verstanden hast. Es werden niemals KEG - Pakete veröffentlicht werden. Diese Module existieren im CVS um den Entwicklern ein paar Vorteile zu geben und um die anderen an KDE beteiligten Gruppen (Übersetzer, Dokumentatoren,...) auf die Anwendungen aufmerksam zu machen.
Veröffentlicht werden die Anwendungen dann unabhängig voneinander.
Also, was mir am liebsten waere, ist ein sehr eingeschraenktes KDEbase-Paket, was man per Skript herunterlaedt,kompiliert und installiert, bzw. nur rpms fuer die qt und das Basispaket. Dann koennte man schonmal mit der konsole arbeiten. Und dann koennte man einen grafischen Installer integrieren, der so eine grafische Auswahl erlaubt, was man an Einzelprogrammen haben moechte. Die koennten dann in der jeweils passenden Version (zum Beispiel gcc 3.2.0 vorausgesetzt) so aehnlich wie im Gentoo-Ports-System installiert werden. Wenn es viele kleine Programme sind, dauert das Kompilieren auch nicht immer so lange bzw. kann dann ja im Hintergrund ablaufen. Auf jedem Fall waere man das Problem schlecht gepackter Pakete los, was sich bei SuSE zum Beispiel in letzter Zeit doch auffallend haeuft. Ausserdem waere es fuer die KDE-Maintainer sicher nicht mehr Arbeit als dauernd fuer die einzelnen Distributionen Pakete zu packen, oder?
ACK. Hinzuzufuegen waere noch: finde es nicht gut, dass kde mit druckertreibern oder aehnlichen Features aufgeblaeht wird. Sowas gehoehrt als Daemon realisiert. Die Features mussen dann von allen Oberflaechen (idealerweise auch von der konsole, wie bei deamons ueblich) benutzbar sein. KDE soll ja kein Betriebssystemersatz werden. Die "Marketingstrategie": KDE muss nahezu alle anwendungsbezogene Aufgaben erfuellen, die sonst das Betriebssystem macht, fuert in eine Sackgasse, da kann ich auch gleich Windoof nehmen. Bei Windoof sieht man ja schon heute zu welcher Unflexibilitaet das fuehrt.
wo sind in KDE Druckertreiber drin? du meinst eher plugins um Drucksysteme anzusteuern. z.B. Cups, LPD, .... Dort sind dann 1000de von Treibern. Aber Cups ist ja auch ein Daemon...
Dass ausgerechnet der KDE-Hasserdienst linuxandmain diese Nachricht liefert, sehe ich als eine besondere Bosheit an, man suggeriert KDe sei normalerweise ueberfrachtet, waehrend es doch gerade eine Staerke von kde war, einen einheitlichen stil zu kultivieren und die applikation wie aus einem guss zu liefern, manchmal mit einigen parallelprojekten und neandertalern, aber das hat der entwicklung nur genuetzt.
N8N8
Calle
Andere Leute nehmen Word für eine Textnotiz, kann man machen, aber wozu?
und das ist gut so :P
> Viele interessante Programme sind trotz ihres bereits reifen Stadiums immer noch nicht in das Environment integriert worden und werden auch nie den Weg in die Distribution finden.
Und mit einem guten Installer der kde programme auch als soche erkennen würde, könnte man diese programme auch ohne probleme "nach"installieren und zwar NUR die die ich haben will (nicht gleich 2-3 von denne ich eh nur eins nutzen werde)
>Grund dafür ist unter anderem der, dass das KDE-Projekt das Environment nicht mit verschiedenen Anwendungen mit gleichen Funktionen aufblähen will.
Wie jetzt ? Was heist hier will , die machen das doch schon immer so :P
> Es macht auch wenig Sinn, die Distribution mit vier oder mehr Brenn-Front-Ends auszuliefern.
Naja, momentan ist es bei kde doch eher so : Alles oder garnichts .
Und mit Selbst compilieren kanns für einen Desktop der damals zumindest auch neulinge ansprechen wollte ja nicht getan sein .
mfg
Das ist zwar richtig, aber daran kann KDE leider nichts aendern. KDE selbst stellt lediglich den Source Codes zur Verfuegung, und da ist es einfach sehr viel einfacher, sie in grossen "Haeppchen" zu entwickeln und veroeffentlichen als einzeln. Was die Distributionen dann daraus machen, ist letztenendes deren Sache. AFAIK wird bei Debian ja alles in einzelne Packages zerlegt. Aber solange die Packet-Systeme fuer Linux nicht besser und moeglichst auch zueinander kompatibler werden, ist da von KDE-Seite nicht so viel zu machen. Das liegt eher in der Verantwortung der Distributionen und der low-level Systeme fuer Linux (und andere freie Systeme).
Pakete zur Verfügung stellen.
Dann braucht man weder .deb noch .rpm Pakete und für
den Newbie ist es kein Problem mehr solche Programme zu installieren.
Sinnvoller wäre es kpackage mit apt-get für RPMs aufzubohren (ala synaptic). Dann klickt man auf das RPM und der Installer läd alle benötigten Zusatzpakete automatisch herunter.
dann gibt es keine Abhängigkeiten !!!
Und in so einem Fall ist der Loki Installer ungemein praktisch und
vor allem einfach, was Newbies sicher sehr zu schätzen wissen.
RPM ist zwar nicht schlecht, für Newbies oder Leute die wenig Ahnung
von Computern haben oder haben wollen ist RPM zu abstrakt.
Der Loki Installer ist intuitiver und gibt ein mehr plastisches und
durchschaubares Gefühl für den Newbie der davor sitzt.
Und was soll das eigentlich, wiso klagst du hier herum,
für mich klingt das so, als fürchtest du dich davor die
vorgefertigen RPM Pakete bei KDE zu verlieren.
1. Wirst du immer deine RPM Pakete von deiner RPM-Distri bekommen.
und
2. hast du jederzeit die Möglichkeit so ein Programm von den Sourcen zu isntallieren.
Deswegen verstehe ich deine "Schwachfug" Reaktion nicht.
Und dann wären wir noch beim allerletzten Punkt,
wer hat davon geredet das man die RPM Pakete bei KDE durch
Loki Installer Pakete "ersetzen" soll?
mal ernsthaft, ein deb oder rpm sollte jeder installiert bekommen (gerade, wenn es keine abhaengigkeiten gibt oder sie automatisch aufgeloest werden). wer hat eigentlich mit dem anspruch angefangen, dass jeder etwas schlauere schimpanse linux bedienen keonnen soll?
etwas weniges darf man doch wohl vom user erwarten duerfen...
Das Problem liegt viel eher daran, dass die Pakete nicht vernueftig praesentiert werden (wem sagt schon ein kmail-1.3.1-10.rpm was?), das Dependency-Problem nur teilweise bis gar nicht geloest ist und man fuer jede Distribution (und teilweise sogar fuer jede Version) ein eigenes Packet benoetigt.
Warum ist das so? Ich wuerde mir doch denken, dass es einfacher ist jedes Programmpaket einzeln zu pflegen. Fuer den Benutzer ist es heutzutage auch nicht mehr umstaendlicher, wie man bei GNOME sieht. Man kann sich etweder alles bequem per Script (wie garnome) installieren oder bequem per Paketmanager der moeglichst die Abhaengigkeiten automatisch aufloest. Und dazu kommt eben der enorme Vorteil, dass man sich auch nur das installieren muss, was man wirklich moechte und wenn ein Programm ein wichtiges Update erhalten hat, kann man dieses upgraden ohne gleich ein riesiges Paket neu installieren zu muessen. Ich finde es schon etwas extrem, wenn man sich fuer einen wichtigen Security-Fix den gesamten Desktop neu installieren muss (ausser natuerlich man weiss, wie man einzelne Programme aus den Paketen installiert oder man verwendet Debian).
Auch das Installieren von Patches ist kein Problem, make compiliert schliesslich nur die Aenderungen...
:-(
Einen brauchbaren FTP-Client haben sie ja auch noch immer nicht zusammengebastelt...
Vielleicht hast Du nur die Welt der _freien_ Software nicht verstanden?
Vielleicht gibt es ja Entwickler, die lieber weiter in Ruhe an ihren Projekten basteln, ohne in die grosse "offizielle" KDE-Tretmuehle zu geraten? Was sollten die KDE-Leute in so einem Fall machen? Sich ein vielversprechendes CD-Brennfrontend schnappen und forken, und dann unter Eigenregie weiterentwickeln? Welchen Sinn haette das?
Oder Krusader und gftp
Ich finde, es sollte das Veryeichnis /opt/kde/userapps/ und /home/user/.kde/userapps (o.ae.) geben, in das neue KDE-Programme einfach per Doppelklick ueber einen einfachen und komfortablen (de)installer reinkopiert und geloescht werden koennen und automatisch einen passenden Eintrag im K-Menue bekommen und mit passenden Dateitypen verknuepft werden, usw. Sprich: Voll integriert werden. Das muss doch irgendwie gehen...
3 zueinander inkompatible gcc-Versionen? Du meinst die geänderte ABI? Weil: Was sich mit dem GCC 3.2 kompilieren lässt, sollte sich doch mit dem GCC 2.95 und 3.0/3.1 kompilieren lassen.
Wäre doch ne Lösung, wenn man eine hübsche Oberfläche für ./configure && make && make install macht, welches das Programm am besten noch gleich in die RPM- bzw. DPKG-Datenbank einträgt. Vielleicht wage ich mich mal an sowas ran, nur mit GTK sind meine Erfahrungen noch recht mässig. ;)
iGEL
Jede moderne Distribution macht im übrigen genau das, was Du willst - grafische Installation - was willst Du mehr?
Ich verstehe die Kritik echt nicht.
Die Verbreitung der Programme ist auf diese Weise abhaengig davon, ob der Distributor es in die Distribution aufnimmt. Das darf IMO nicht sein. Ich will mir ein Programm direkt vom Entwickler beziehen und es mit einem einzigen Doppelklick und einer Passwortangabe gebrauchsfertig im System integriert haben.
Die RPM-Loesung ist IMO etwas ungluecklich gestaltet. Eine riesige Datenbank an Installierten Paketen, von denen vielleicht 5-10% fuer den User interessant sind ist sehr verwirrend und fuer Neulinge auch abschreckend, weil es verhaeltnismaessig lange dauert, bis das gesuchte Programm gefunden wurde... Programme und wichtige Bibliotheken sollten deshalb etwas besser voneinander getrennt sein. Und warum im selben Zug nicht alle Grafischen Programme gleich von den Konsolenprogrammen trennen? Ich denke dabei insbesondere an die Masse der Mac- und Win-Umsteiger.
Im grossen und ganzen halte ich es fuer wesentlich intuitiver, wenn Programme, die in einem Speziellen Ordner fuer Programme liegen, automatisch installiert sind, eben *weil* sie in diesem Ordner liegen.
mfg,
Benjamin
Das ist nicht machbar, oder soll alles statisch gelinkt sein?
Nein, ich denke der DAU nimmt das, was die Distri mitbringt und jeder andere kann sich die Programme kompilieren.
Und, klar, dieser Ordner heißt $PATH.
Akzeptiere doch bitte, dass die meisten Open Source Autoren Programme schreiben, weil es Ihnen Spass macht und nicht um das für irgendwelche User beste Programm zu schreiben (außer genau dass macht Ihnen Spass).Ich kann mir tausend Gründe denken, warum es jemandem mehr Spass macht, ein neues, in den Augen der meisten anderen Menschen vielleicht sogar schlechteres, Programm zu schreiben als sich in ein bestehendes Projekt einzuklinken.
So wie ich das verstanden habe soll es jetzt weitere größere Pakete
(mit "KEG" gekennzeichnet) geben die man zusätzlich zu den Core Paketen installieren kann.
Das Problem an diesen KEG Paketen ist aber wieder,
das man diese wieder komplett installieren muß (wenn man es nicht gerade
selber manuel einzeln nach dem compilieren installiert).
D.h. man hat dabei nichts gewonnen.
Viel sinnvoller finde ich es, wenn man auf apps.kde.com die guten Programme einzeln heraussucht (was ja anhand den Wertungen leicht möglich ist) und dann einzeln installiert.
Das ist für mich der Grund warum ich in diesen KEG Paketen keinen Sinn sehe.
Eine Seite die die besten der besten KDE Apps von apps.kde.com auflistet,
inklusive Reviews und Screenshots auf denen man auch etwas erkennen kann
wäre IMHO sinnvoller.
Und was die Core Pakete betrifft, sollte man diese auch mal etwas entschlacken,
oder wenigstens eine einfachere Möglichkeit bieten nur ganz bestimmte
Programme zu compilieren und zu installieren.
Das würde sich IMHO sehr einfach über das ./configure Script
realisieren lassen, wo man einfach beim starten von ./configure
mitangibt, welche Pakete compiliert und installiert werden sollen.
(so eine ./configure Option wie beim ALSA-driver Paket die Treiber)
Ich weiß das es die Möglichkeit gibt, einzeln in jedes Unterverzeichnis bei den Sourcepacketen zu gehen und dann von dort aus ein "make && make install" auszuführen.
Aber das habe ich einmal gemacht und das ist eine ziemliche umständliche Fummelei und sehr Zeitaufwendig.
Viel lieber wäre mir daher eine Möglichkeit via ./configure
die zu installierenden Programme anzugeben.
Das könnte z.b. so aussehen:
$ cd kde-games-3.0.x
$ ./configure --with "Ktron KSnake KSokoban KMines"
$ make
$ checkinstall
Dabei werden dann nur diese 4 Programme compiliert und zu einem einzigen
Paket zusammengeschnürt.
Wenn man das System sowiso selber compiliert ist das zusammenschnüren kein großes Problem und ist so gesehen ein guter Kompromiss
zwischen "einfach alles" oder jedes Programm umständlich aber dafür einzeln zu installieren.
Bei den heutigen Plattenpreisen nehme ich alle Programme und blende im Startmenü die unwichtigen aus.
Der normale User überlässt seiner Distribution die Programmauswahl, von daher verstehe ich die Nörglerei _überhaupt_ nicht.
Es ist ja nicht so, daß mehr installierte Programme KDE langsamer machen würden, oder?
aber soll das wirklich jeder machen?
IMHO sollte man das Problem an der Wurzel anpacken und gleich
die KDE Pakete mit so einem Skript ausstatten.
Und wenn man dann soweit ist, dann kann man gleich ./configure anpassen.
"Bei den heutigen Plattenpreisen nehme ich alle Programme und blende im Startmenü die unwichtigen aus."
Diese Option habe ich leider nicht.
Manchmal sitze ich vor einem alten P2 Rechner und der
hat nur ne 3 GB Platte, da brauche ich jeden Platz.
Der normale User überlässt seiner Distribution die Programmauswahl, von daher verstehe ich die Nörglerei _überhaupt_ nicht.
1. Was ist ein normaler User?
2. Kann ich nicht bestätigen. Ich kenne Leute
die sind absolute Anfänger was Computer und Linux betrifft.
Und die finden schon die Standardinstallation von Suse 7.3 überladen.
Was man natürlich auch verstehen kann, wozu benötigt man 6 verschiedene
Text-Editoren.
Außerdem gibt es Distributoren die die KDE Pakete nicht aufsplitten.
D.h. da muß man dann die einzelnen Core Pakete komplett installieren oder
gar nicht.
"Es ist ja nicht so, daß mehr installierte Programme KDE langsamer machen würden, oder?
Nein, aber sie benötigen unnötig viel Platz.
Und die unnötigen Programme aus dem Startmenü auszublenden
ist zu Zeitaufwendig.
Zuletzt klingt sowas ja auch noch wie die Windows Internet Explorer
lösung:
Wenn man den IE nicht mag, dann entfernt man ihn einfach aus seinem
Startmenü, der Quicklaunch Leiste und dem Desktop.
Kann man vielleicht in kde-devel anregen.
Die Distributoren lernen auch dazu und entschlacken größtenteils, was aber wieder andere zur Kritik anregt.
Nimmt man halt ne andere Distri.
Der IE läuft immer, ob man ihn nutzt oder nicht, das ist ein Unterschied.
Ich bleib dabei, wenn man keine Ahnung hat, muß man dem Distributor vertrauen, wer mehr Ahnung hat, weiß wie er einzelne Pakete loswird.
Geschrieben auf einem PII mit 3GB-Platte und gentoo...
>> Viel sinnvoller finde ich es, wenn man auf apps.kde.com die guten Programme einzeln heraussucht (was ja anhand den Wertungen leicht m?glich ist) und dann einzeln installiert. <<
So aehnlich ist es doch gedacht: die jeweils besten der verschiedenen vorhandenen "flavours" werden als ein (dann hoffentlich etwas kleineres) "kdebase-extended" (da musste ich jetzt auch lachen) rausgebracht.
Gut - es nimmt Dir jemand die Entscheidung ab, welches Paket denn nun "das beste" ist :(
Aber
>> Und was die Core Pakete betrifft, sollte man diese auch mal etwas entschlacken <<
genau das passiert doch dabei.
Um ehrlich zu sein, wusste ich aber bisher nicht, dass man die ganzen Teile nicht auch einzeln bekommen kann - bei debian muss ich (wie oben erwaehnt) jedenfalls nicht das ganze kdenetwork installieren.
ma gucken, was bei rauskommt
cu
kamome
Hmm, jetzt braucht man nur noch einen, der so ein Script schreibt und die Abhaengigkeiten wartet... Wie waere es mit dir?
Ich kann Dich beruhigen, dass Du das falsch verstanden hast. Es werden niemals KEG - Pakete veröffentlicht werden. Diese Module existieren im CVS um den Entwicklern ein paar Vorteile zu geben und um die anderen an KDE beteiligten Gruppen (Übersetzer, Dokumentatoren,...) auf die Anwendungen aufmerksam zu machen.
Veröffentlicht werden die Anwendungen dann unabhängig voneinander.
Auf jedem Fall waere man das Problem schlecht gepackter Pakete los, was sich bei SuSE zum Beispiel in letzter Zeit doch auffallend haeuft. Ausserdem waere es fuer die KDE-Maintainer sicher nicht mehr Arbeit als dauernd fuer die einzelnen Distributionen Pakete zu packen, oder?
Vielleicht findet sich ja dafuer eine Gruppe?
Hinzuzufuegen waere noch:
finde es nicht gut, dass kde mit druckertreibern oder aehnlichen Features aufgeblaeht wird. Sowas gehoehrt als Daemon realisiert. Die Features mussen dann von allen Oberflaechen (idealerweise auch von der konsole, wie bei deamons ueblich) benutzbar sein. KDE soll ja kein Betriebssystemersatz werden. Die "Marketingstrategie": KDE muss nahezu alle anwendungsbezogene Aufgaben erfuellen, die sonst das Betriebssystem macht, fuert in eine Sackgasse, da kann ich auch gleich Windoof nehmen. Bei Windoof sieht man ja schon heute zu welcher Unflexibilitaet das fuehrt.