Hallo! Ich hab mal probiert, ein paar Pakete der SuSE-Distribution aus den Source-Paketen zu kompilieren (zq1). Sollte ja eine einfache Möglichkeit sein, optimalere Leistung (seien es auch nur ein paar Prozentchen) aus dem System zu holen, ohne auf den RPM-Komfort zu verzichten. Soweit ich weiß, sind ja die SuSE-Pakete auf i486 optimiert, aber auch unter einem 386'er ablauffähig, also kleinster gemeinsamer Nenner. Ich habe nun aber das Gefühl, daß bei einem "rpm -ba" meine tatsächliche Rechnerkonfiguration (K6-2) gar nicht erst berücksichtigt wird, sondern, wenn man den Compileraufrufen trauen darf, weiterhin für 486 optimiert wird. Auffällig ist es bei Paketen wie glxg200 (oder so), welche sogar eine Optimierung für MMX und 3DNow bieten würden, was jedoch bei einer Installation aus den SuSE-SRPMs explizit nicht verwendet wird. Bei einem manuellen Aufruf mit configure und make wird dies hingegen automatisch erkannt, aber der RPM-Komfort ist halt weg. Läßt sich dieses Verhalten einfach abstellen, oder muß ich da par Hand die SPEC-Files ändern, und, zweite Frage, hat jemand Erfahrungen, bei welchen Paketen sich das überhaupt lohnt? Alexx --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Tue Oct 19 1999, Alexx Riedel wrote:
Ich habe nun aber das Gefühl, daß bei einem "rpm -ba" meine tatsächliche Rechnerkonfiguration (K6-2) gar nicht erst berücksichtigt wird, sondern, wenn man den Compileraufrufen trauen darf, weiterhin für 486 optimiert wird. [....]
Installier' Dir glibc-2.1.2 mit gcc-2.95.1 und backe Deine Programme mit sowas wie -march=k6 -O3 -fstrict-aliasing -funroll-loops -fschedule-insns2 Einen 2.2.1x Kernel kannst Du problemlos mit CFLAGS := $(CFLAGS) -march=k6 -funroll-loops -mpreferred-stack-boundary=2 -DCPU586 optimieren. Bei Programmen, die nicht an systemrelevanten Dingen rumschrauben bringt auch ein "-ffast-math" haeufig noch einen guten Zuwachs an Geschwindigkeit. ~ hd --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi! Trying to kill the keyboard, riedel@forst.uni-muenchen.de produced:
Ich hab mal probiert, ein paar Pakete der SuSE-Distribution aus den Source-Paketen zu kompilieren (zq1). Sollte ja eine einfache Möglichkeit sein, optimalere Leistung (seien es auch nur ein paar Prozentchen) aus dem System zu holen, ohne auf den RPM-Komfort zu verzichten. Soweit ich
Ist dein System so langsam, dass du das brauchst? Mehr als 5% bekommst du da nicht raus, IMHO. Es sei denn, du hast spezielle Pakete (siehe dein Beispiel).
Ich habe nun aber das Gefühl, daß bei einem "rpm -ba" meine tatsächliche Rechnerkonfiguration (K6-2) gar nicht erst berücksichtigt wird, sondern, wenn man den Compileraufrufen trauen darf, weiterhin für 486 optimiert wird. Auffällig ist es bei Paketen wie glxg200 (oder so), welche sogar eine Optimierung für MMX und 3DNow bieten würden, was jedoch bei einer Installation aus den SuSE-SRPMs explizit nicht verwendet wird. Bei einem manuellen Aufruf mit configure und make wird dies hingegen automatisch erkannt, aber der RPM-Komfort ist halt weg.
Nun, du muesstest das .spec-File des RPM aendern, welches diese Einstellungen uebersteuert, und wahrscheinlich auch das SuSE-Makefile, ... nicht sehr schwer, wenn man es einmal gemacht hat. Teste einfach mal, wieviel schneller deine handkompilierten Dinger sind und dann entscheide dich. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 25-Oct-99 Wolfgang Weisselberg wrote:
Nun, du muesstest das .spec-File des RPM aendern, welches diese Einstellungen uebersteuert, und wahrscheinlich auch das SuSE-Makefile, ... nicht sehr schwer, wenn man es einmal gemacht hat.
Wenn man das macht, dürfte aber die Installation eines simplen source-tgz mit configure/make/make install weniger Aufwand bedeuten. Und wenn man bei configure ein --prefix=/usr/local/<prg> mit angibt kann man das komplette Programm bei Bedarf mittels eines simplen rm -Rf wieder entfernen. Natürlich muß man dann allerdings einige Pfade anpassen - dafür hab ich mir eine bash-Funktion in /etc/profile.local eingebaut, so daß ich auch dort nur noch eine Zeile ("addprg /usr/local/<prg>") einfügen muß. Und die ist bei der Deinstallation ebenfalls sehr leicht zu löschen :-). Das Skript kann man bei Bedarf von mir bekommen - just mail me :-). --- Erhard Schwenk <eschwenk@fto.de> - http://www.fto.de **** Jetzt neu: http://www.akkordeonjugend.de **** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Erhard Schwenk schrieb:
On 25-Oct-99 Wolfgang Weisselberg wrote:
Nun, du muesstest das .spec-File des RPM aendern, welches diese Einstellungen uebersteuert, und wahrscheinlich auch das SuSE-Makefile, ... nicht sehr schwer, wenn man es einmal gemacht hat. Wenn man das macht, dürfte aber die Installation eines simplen source-tgz mit configure/make/make install weniger Aufwand bedeuten. Und wenn man bei configure ein --prefix=/usr/local/<prg> mit angibt kann man das komplette Programm bei Bedarf mittels eines simplen rm -Rf wieder entfernen.
Genau. Mir ging es darum, die Pakete, mit denen ich mich nicht groß befassen will und wo ich eigentlich froh bin, daß YaST/RPM alles für mich erledigt, vielleicht durch Kompilation der Source-RPMs über Nacht problemlos leistungsmäßig etwas aufzumöbeln, ohne viel am System umzuschmeissen. Die Pakete, wo ich am aktuellsten Stand interessiert bin, tu ich eh schon selbergebacken nach /usr/local. Wo ja leider auch noch ein paar SuSE-RPMs ihre Dateien hintun, was aber ein ganz anderes Thema ist...
Natürlich muß man dann allerdings einige Pfade anpassen - dafür hab ich mir eine bash-Funktion in /etc/profile.local eingebaut, so daß ich auch dort nur noch eine Zeile ("addprg /usr/local/<prg>") einfügen muß. Und die ist bei der Deinstallation ebenfalls sehr leicht zu löschen :-). Das Skript kann man bei Bedarf von mir bekommen - just mail me :-).
Hmmm, würde mich interessieren! Alexx --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi! Zeilenlaenge <75 zeichen, bitte? Trying to kill the keyboard, eschwenk@fto.de produced:
On 25-Oct-99 Wolfgang Weisselberg wrote:
Nun, du muesstest das .spec-File des RPM aendern, welches diese Einstellungen uebersteuert, und wahrscheinlich auch das SuSE-Makefile, ... nicht sehr schwer, wenn man es einmal gemacht hat.
Wenn man das macht, dürfte aber die Installation eines simplen source-tgz mit configure/make/make install weniger Aufwand bedeuten.
Man verliert nur das bequeme RPM, die Abhaengigkeiten, die Trigger, ...
Und wenn man bei configure ein --prefix=/usr/local/<prg> mit angibt kann man das komplette Programm bei Bedarf mittels eines simplen rm -Rf wieder entfernen.
Ja, aber diese Idee ist alt. Abgesehen davon, dass du dann kein /etc mehr hast, keine konzentrierten Configfiles, kein /sbin/init.d/whatever ... hast du schnell einen Pfad, der laenger ist als es schoen ist oder eben doch eine Linkfarm. Nicht gut. Dazu braeuchten wir eine andere Art von Dateisystem als heute. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 25-Oct-99 Wolfgang Weisselberg wrote:
Nun, du muesstest das .spec-File des RPM aendern, welches diese Einstellungen uebersteuert, und wahrscheinlich auch das SuSE-Makefile, ... nicht sehr schwer, wenn man es einmal gemacht hat.
Wenn man das macht, dürfte aber die Installation eines simplen source-tgz mit configure/make/make install weniger Aufwand bedeuten.
Man verliert nur das bequeme RPM, die Abhaengigkeiten, die Trigger, ...
Wenn ich das spec-File ändern muß, ist RPM ja gerade nicht mehr als "bequem" zu bezeichnen. Abhängigkeiten werden von configure mindestens genauso zuverlässig angezeigt, im Gegenteil, wie oft schlägt RPM wegen nicht richtig erkannter alter Pakete Fehlalarm beim Installieren? Und Trigger pfuschen ohnehin nur unkontrollierbar im System rum, womit Linux wieder ein Stück näher an die Windows-Instabilitäten gerückt wird.
Und wenn man bei configure ein --prefix=/usr/local/<prg> mit angibt kann man das komplette Programm bei Bedarf mittels eines simplen rm -Rf wieder entfernen.
Ja, aber diese Idee ist alt. Abgesehen davon, dass du dann kein /etc mehr hast, keine konzentrierten Configfiles, kein /sbin/init.d/whatever ... hast du schnell einen Pfad, der laenger ist als es schoen ist oder eben doch eine Linkfarm.
Wieso kein /etc mehr? Ich habe dann für jedes Programm ein .../etc, in dem die zu dem Programm gehörige Config liegt. Die liegt da, wo jeder halbwegs logisch denkende Mensch sie sucht - beim Programm - und verschwindet bei der Deinstallation so, wie es sich gehört, auch gleich mit. Es sei denn, ich will sie z.B. bei nem Update übernehmen, dann muß ich sie halt vorher wegkopieren oder umbenennen. Konzentrierte Configfiles mögen schön sein, aber sie sorgen im Endeffekt auch bloß dafür, daß aller mögliche Müll im System rumliegt und kein Mensch mehr weiß, was wohin gehört. Liegen die Configfiles bei den Programmen, ist immer klar wo sie dazugehören. Und Müll wird auch viel weniger erzeugt. Ein /sbin/init.d/whatever hat man in 3 Minuten angelegt - wenn es denn wirklich notwendig ist. An der Ecke sollte eh nur jemand rumspielen, der auch weiß was er tut. Und aus einem skeleton-File ein neues Skript zu erzeugen ist nun wirklich einfach (zumal man auch das so weit parametrisieren kann, daß sich die Änderungen im Normalfall auf 2-3 Programmzeilen beschränken). Und wenn es schon komplizierter sein soll, kann der Programmautor auch jederzeit ein passendes File zum reinkopieren beiliegen. Und welchen Normalanwender bitteschön stört ein langer Pfad? Eine der positiven Eigenschaften von Linux ist, daß der Pfad länger als 256 Zeichen lang sein _kann_. Und die minimale Zeitverzögerung beim Aufbau einer Login-Shell oder beim Start eines Binaries nimmt der _normale_ User ohnehin nicht wahr. Wenn man dann zeitkritische Prozesse hat, kann man die immer noch entsprechend optimieren.
Nicht gut. Dazu braeuchten wir eine andere Art von Dateisystem als heute.
Funktioniert wunderbar und hat dafür gesorgt, daß mein ursprünglich auf SuSE 5.1 (!) basierendes System bis heute ohne Neuinstallation überlebt hat. Nichts gegen RPM, aber wer sowas verwendet muß sich einfach klar sein, daß er damit auch ein gutes Stück Kontrolle aufgibt. Im Endeffekt hat das Teil die gleichen Probleme wie die Windows-Installer. Da werden Abhängigkeiten nicht richtig erkannt, Deinstallationen hinterlassen Müll im System und kein Mensch weiß mehr genau, was bei der Installation eigentlich passiert ist. Ergebnis: immer unhandlichere, "zerinstalliertere" und weniger beherrschbare Systeme, die irgendwann so viele "Alterserscheinungen" angesetzt haben, daß eine Neuinstallation fällig ist. --- Erhard Schwenk <eschwenk@fto.de> - http://www.fto.de **** Jetzt neu: http://www.akkordeonjugend.de **** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi! Trying to kill the keyboard, eschwenk@fto.de produced:
On 25-Oct-99 Wolfgang Weisselberg wrote:
Nun, du muesstest das .spec-File des RPM aendern, welches diese Einstellungen uebersteuert, und wahrscheinlich auch das SuSE-Makefile, ... nicht sehr schwer, wenn man es einmal gemacht hat.
Wenn man das macht, dürfte aber die Installation eines simplen source-tgz mit configure/make/make install weniger Aufwand bedeuten.
Man verliert nur das bequeme RPM, die Abhaengigkeiten, die Trigger, ...
Wenn ich das spec-File ändern muß, ist RPM ja gerade nicht mehr als "bequem" zu bezeichnen.
Hmmm ... du musst sogar specs erstellen, wenn du eigene Pakete RPM'st. *shudder* Der Vorteil ist der, dass man sauberer upgraden kann, ohne z.B. config-files zu verlieren. Config-file wurde nicht geaendert? Dann den Default draufhauen. Geaendert? Dann je nach dem das Config-file als .rpmold speichern oder das neue als .rpmnew. Neues RPM ersetzt 2 alte RPMs.
Abhängigkeiten werden von configure mindestens genauso zuverlässig angezeigt, im Gegenteil, wie oft schlägt RPM wegen nicht richtig erkannter alter Pakete Fehlalarm beim Installieren?
Bei mir, nie. Wenn RPM Alarm schlaegt, habe ich entweder das entsprechende Paket nicht als RPM installiert (extrem selten bei mir) --- und das *kann* RPM nicht sauber abfangen. Oder das Spec-File ist ungenau. Fehler vom Author. YaST-ich-will-KDE-und-dies-und-das-und-so-weiter ist was ganz anderes!
Und Trigger pfuschen ohnehin nur unkontrollierbar im System rum, womit Linux wieder ein Stück näher an die Windows-Instabilitäten gerückt wird.
Nein. Trigger (im Sinne von RPM V3) werden nur ausgefuehrt, wenn bestimmte Pakete installiert/entfernt werden (und sich so bestimmte Kombinationen ergeben). So kann ein Trigger z.B. sendmail als Link von qmail setzen, wenn selbiges installiert wird und kein sendmail installiert ist und ... (der Link waere Teil des eazy-Paketes, welches schon lange drauf ist). Das qmail-Paket kann das nicht ohne Trigger-aehnliche Abfragen: qmail braucht eazy nicht, und darf nicht einfach in anderer Paket's Files rumaendern. Trigger sind sehr maechtig, und potentiell gefaehrlich. Das gleiche gilt fuer C.
Wieso kein /etc mehr? Ich habe dann für jedes Programm ein .../etc, in dem die zu dem Programm gehörige Config liegt. Die liegt da, wo jeder halbwegs logisch denkende Mensch sie sucht - beim Programm - und verschwindet bei der Deinstallation so, wie es sich gehört, auch gleich mit. Es sei denn, ich will sie z.B. bei nem Update übernehmen, dann muß ich sie halt vorher wegkopieren oder umbenennen.
Eben, das umbenennen ist ein RPM-Dienst. Ach so, wo gehoert z.B. /etc/resolv.conf hin ... welches Paket? Oder /etc/motd? /etc/services? Von /etc/passwd nicht zu sprechen --- gehoert es zu /etc/shadow, welches jetzt /usr/local/bin/PAM/etc/shadow ist? Oder gehoert /etc/shadow nach /usr/local/bin/shadow/etc/shadow? Und woher weiss login & co, ob es ein PAM-System ist? Oder doch Links aus /etc, die dann stale werden (weil kein z.B. RPM sie erfasst)? Es ist einfach nicht trivial!
Konzentrierte Configfiles mögen schön sein, aber sie sorgen im Endeffekt auch bloß dafür, daß aller mögliche Müll im System rumliegt und kein Mensch mehr weiß, was wohin gehört.
Dazu ist RPM & co da. (Ja, man kann auch Files angeben, die nicht installiert werden, wie optionale config-Files).
Liegen die Configfiles bei den Programmen, ist immer klar wo sie dazugehören. Und Müll wird auch viel weniger erzeugt.
Im Prinzip -- vielleicht.
Ein /sbin/init.d/whatever hat man in 3 Minuten angelegt - wenn es denn wirklich notwendig ist.
Und wird Muell, wenn nicht mehr gebraucht. Gefaehrlicher Sondermuell in manchen Faellen.
Und welchen Normalanwender bitteschön stört ein langer Pfad? Eine der positiven Eigenschaften von Linux ist, daß der Pfad länger als 256 Zeichen lang sein _kann_.
Hmmm. $ cd /usr/bin/ $ ls | wc -l 998 $ echo /usr/local/bin/xxx: | wc -c 20 $ bc -q 20 * 998 19960 Du bist dir sicher, dass du Pfade > 19 Kb gut findest? Ich nicht. Und ich habe noch nicht einmal besonders viele executables ... und die unter X sind auch noch nicht gezaehlt. Mal ganz abgesehen davon, dass du dann nicht mehr fuer UNIX, sondern nur noch fuer Linux deinen Kram machst. Stell dir vor, Emacs nur fuer Linux. *furrfu*
Funktioniert wunderbar und hat dafür gesorgt, daß mein ursprünglich auf SuSE 5.1 (!) basierendes System bis heute ohne Neuinstallation überlebt hat. Nichts gegen RPM, aber wer sowas verwendet muß sich einfach klar sein, daß er damit auch ein gutes Stück Kontrolle aufgibt.
Nur wenn er damit nicht umgehen kann. Wie gesagt, ich backe meine Zusatzinstallationen alle auf RPM-Basis.
Im Endeffekt hat das Teil die gleichen Probleme wie die Windows-Installer.
z.B.?
Da werden Abhängigkeiten nicht richtig erkannt,
Nein, das 'Erkennen' ist rein manuell steuerbar. Und in 98% der Faelle ist die atomatische Erkennung beim Bauen sehr gut. Nur wenn Installer so klever sind und versuchen, welche Libs sie nicht brauchen, wird der getaeuscht --- und wie gesagt, vom Packager kann es manuell angegeben werden. Im Zweifelsfall liegt dort der Fehler. Und man kann die Erkennung beim Installieren/Entfernen abschalten: --nodeps.
Deinstallationen hinterlassen Müll im System
Nein, wenn der Packager halbwegs gut gearbeitet hat, nicht. Und herrenlose Files lassen sich auch schnell herausfinden. rpm -qf FILE
und kein Mensch weiß mehr genau, was bei der Installation eigentlich passiert ist.
rpm -vv
Ergebnis: immer unhandlichere, "zerinstalliertere" und weniger beherrschbare Systeme, die irgendwann so viele "Alterserscheinungen" angesetzt haben, daß eine Neuinstallation fällig ist.
Nicht meine Erfahrung. Im Gegenteil, das Upgraden auf eine neuere Version (selbst wenn kein Specfile mitgeliefert wird) geht sauberer (wenn auch nicht unbedingt schneller) und ein backout des Upgrades ist sehr schnell, vor allem, wenn man die alten .rpm's nicht direkt loescht. Mein System basiert auf einer SuSE 4.2 ... und ist jetzt up-to-date mit einer 6.2. Aber, whatever works for you. -Wolfgang PS: Cc's an mich sind nicht noetig, ich lese die Liste. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (4)
-
eschwenk＠fto.de -
hd＠elfie.rhein-neckar.de -
riedel＠forst.uni-muenchen.de -
weissel＠ph-cip.uni-koeln.de