Performance-Verbesserung durch Selbstkompilieren?
Hallo, ich habe immer wieder in Foren, etc.. gehört, dass alles viel besser und performanter laufen soll, wenn man z.B. den Kernel oder KDE selber kompiliert. Also meine kurze Frage: Würde es bezüglich der Performance etwas bringen, wenn ich den Kernel (so wie in Thomas' Howto: http://thomashertweck.de/kernel.html) selber kompiliere, oder ist das nur ein subjektiver Eindruck, den viele Leute haben, wenn sie einen Kernel gebaut haben? Meiner Meinung nach, müsste man dann Flags setzen, wenn man es für die eigene CPU optimieren will, aber das wird (soweit, wie ich das beurteilen kann, man möge mich verbessern, wenn ich da falsch liege) in dem Howto ausgelassen. Kann sein, dass dieses Thema schon mehrfach hier durchgekaut wurde, ich habe jedoch nichts gefunden, was mir eine eindeutige Antwort geben konnte. Gruß Sören
Hallo, Am Mon, 16 Aug 2004, Sören Wengerowsky schrieb:
ich habe immer wieder in Foren, etc.. gehört, dass alles viel besser und performanter laufen soll, wenn man z.B. den Kernel oder KDE selber kompiliert.
Also meine kurze Frage: Würde es bezüglich der Performance etwas bringen, wenn ich den Kernel (so wie in Thomas' Howto: http://thomashertweck.de/kernel.html) selber kompiliere, oder ist das nur ein subjektiver Eindruck, den viele Leute haben, wenn sie einen Kernel gebaut haben?
Seit SUSE optimierte Kernel (k_athlon z.B.) bringt das performancemaessig eigentlich nix mehr. Interessant ist am ehesten noch, den Kernel abzuspecken. KDE selbstzukompilieren bringt tendenziell auch nicht wirklich was. -dnh -- "Bismark [...] Sehen sie, so alt sind ihre Ideen, Frau Schmidt..." -- Georg Schramm im Scheibenwischer, mit Ulla Schmidt im Publikum(!)
Am Montag, 16. August 2004 20:13 schrieb David Haller:
Seit SUSE optimierte Kernel (k_athlon z.B.) bringt das performancemaessig eigentlich nix mehr. Ich dachte jetzt eigentlich, diese Athlon-Kernel gibts seit dem 2.6er nicht mehr bei SuSE.. Muss mich wohl geirrt haben.
Interessant ist am ehesten noch, den Kernel abzuspecken. Was meinst du damit? Weniger Module fest einkopilieren?
KDE selbstzukompilieren bringt tendenziell auch nicht wirklich was.
Danke für die Bestätigung, das dachte ich mir bereits. Ich habe nur in manchen Foren schon viele Leute getroffen, die darauf schwören, alles selber zu kompilieren. (nicht nur die Gentoo-User..) Aber dann muss ich denen wohl nicht mehr so viel Glauben schenken, wenn mir mal jemand beteuert, ich müsste Sachen wie OpenOffice und Kde selber bauen... Gruß Sören
Sören Wengerowsky schrieb am 08/16/2004 10:59 PM:
Am Montag, 16. August 2004 20:13 schrieb David Haller:
Interessant ist am ehesten noch, den Kernel abzuspecken.
Was meinst du damit? Weniger Module fest einkopilieren?
Das kann durchaus sinnvoll sein, gerade auf Servern macht es aus Sicherheitsgründen Sinn, selbst einen Kernel zu kompilieren, in dem alles, das man braucht, drin ist (und nichts anderes), und in dem die Unterstützung für nachladbare Kernelmodule deaktiviert ist. Otto Normaluser wird allerdings auf seinem Desktop-Rechner kaum einen Unterschied spüren, da reicht ein Standardkernel von SuSE vollkommen aus. Wenn man nicht weiß, was man tut, hat man nämlich schnell mal einen Kernel kompiliert, in dem man das eine oder andere vergessen hat, und steht dann erstmal mit großen Augen vor der Kiste, die sich weigert zu booten... ;) Michael.
Am Montag, 16. August 2004 21:33 schrieb Michael Schachtebeck:
Otto Normaluser wird allerdings auf seinem Desktop-Rechner kaum einen Unterschied spüren, da reicht ein Standardkernel von SuSE vollkommen aus. Wenn man nicht weiß, was man tut, hat man nämlich schnell mal einen Kernel kompiliert, in dem man das eine oder andere vergessen hat, und steht dann erstmal mit großen Augen vor der Kiste, die sich weigert zu booten... ;) Genau davor habe ich auch Angst.. deswegen hab ich es bis jetzt vermieden...
Gruß Sören
Hallo, Am Mon, 16 Aug 2004, Sören Wengerowsky schrieb:
Am Montag, 16. August 2004 20:13 schrieb David Haller:
Seit SUSE optimierte Kernel (k_athlon z.B.) bringt das performancemaessig eigentlich nix mehr. Ich dachte jetzt eigentlich, diese Athlon-Kernel gibts seit dem 2.6er nicht mehr bei SuSE.. Muss mich wohl geirrt haben.
Nein, hast schon recht. Der (32bit) 9.1er Kernel ist wohl mit CONFIG_M586=y kompiliert (schau in /boot/config-`uname -r`), wenn du ne P4 oder Athlon hat, dann lohnt sich's evtl. schon, weil einige Routinen (v.a. haeufige) sind teilweise mit MMX oder gar SSE Assemblerbefehlen geschrieben. Ein 'CONFIG_MPENTIUM4' oder 'CONFIG_MK8' oder so duerfte sich schon bei manchen kernellastingen Dingen sogar bemerkbar machen. Wenn's dich interessiert und C lesen kannst, dann kannst du ja mal in asm-i386 kruschteln.
Interessant ist am ehesten noch, den Kernel abzuspecken. Was meinst du damit? Weniger Module fest einkopilieren?
Ja. Bzw. generell mehr wegzulassen. Dazu muss man dann aber seine Hardware und anderes recht gut kennen. Mein Kernel ist sicherlich kleiner als ein aehnlicher SuSE-Kernel: $ du -hs /boot/*-`uname -r` /lib/modules/`uname -r` 588k /boot/System.map-2.4.25-1l 1.1M /boot/bzImage-2.4.25-1l 3.4M /lib/modules/2.4.25-1l Und dabei hab ich noch einiges unwichtige drin, das ich noch weglassen koennte.
KDE selbstzukompilieren bringt tendenziell auch nicht wirklich was. Danke für die Bestätigung, das dachte ich mir bereits. Ich habe nur in manchen Foren schon viele Leute getroffen, die darauf schwören, alles selber zu kompilieren. (nicht nur die Gentoo-User..) Aber dann muss ich denen wohl nicht mehr so viel Glauben schenken, wenn mir mal jemand beteuert, ich müsste Sachen wie OpenOffice und Kde selber bauen...
Unwahrscheinlich. Zumal im Vergleich zum noetigen Aufwand. -dnh -- Viele unserer Importe stammen aus dem Ausland -- G. W. Bush
Hallo,
Am Mon, 16 Aug 2004, Sören Wengerowsky schrieb:
Am Montag, 16. August 2004 20:13 schrieb David Haller:
Seit SUSE optimierte Kernel (k_athlon z.B.) bringt das performancemaessig eigentlich nix mehr.
Ich dachte jetzt eigentlich, diese Athlon-Kernel gibts seit dem 2.6er nicht mehr bei SuSE.. Muss mich wohl geirrt haben.
Nein, hast schon recht. Der (32bit) 9.1er Kernel ist wohl mit CONFIG_M586=y kompiliert (schau in /boot/config-`uname -r`) Ja
Am Montag, 16. August 2004 21:55 schrieb David Haller: linux:~ # cat /boot/config-`uname -r` |grep CONFIG_M586 CONFIG_M586=y # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set linux:~ # Schade eigentlich, dass es die Athlon-Kernel nicht mehr gibt! War anscheinend zuviel Aufwand für die "RPM-Packer" bei Suse, immer 2 Kernel bereit und aktuell zu halten.
, wenn du ne P4 oder Athlon hast , dann lohnt sich's evtl. schon, weil einige Routinen (v.a. haeufige) sind teilweise mit MMX oder gar SSE Assemblerbefehlen geschrieben. Ein 'CONFIG_MPENTIUM4' oder 'CONFIG_MK8' oder so duerfte sich schon bei manchen kernellastingen Dingen sogar bemerkbar machen. AMD Athlon XP 1700+ mit 1460Mhz, um genau zu sein.. oder merkt man das erst bei den großen Athlons?
Wenn's dich interessiert und C lesen kannst, dann kannst du ja mal in asm-i386 kruschteln. Leider kann ich kein C. Was würde ich dort zu sehen bekommen?
Ja. Bzw. generell mehr wegzulassen. Dazu muss man dann aber seine Hardware und anderes recht gut kennen. Mein Kernel ist sicherlich kleiner als ein aehnlicher SuSE-Kernel:
$ du -hs /boot/*-`uname -r` /lib/modules/`uname -r` 588k /boot/System.map-2.4.25-1l 1.1M /boot/bzImage-2.4.25-1l 3.4M /lib/modules/2.4.25-1l Bei /lib/modules sind bei mir 51MB.. der Rest ist nicht so auffallend größer. Aber in /lib/modules sind doch alle Module, auch die, die nicht geladen sind, oder? Warum stören auch ungeladene Module, außer, dass sie Festplattenplatz fressen? :-)
56K /boot/config-2.6.5-7.104-default 1,2M /boot/initrd-2.6.5-7.104-default <--warum existiert dieser Eintrag bei dir gar nicht? Liegt das an dem 2.4-2.6-Unterschied? 116K /boot/Kerntypes-2.6.5-7.104-default 729K /boot/System.map-2.6.5-7.104-default 1,5M /boot/vmlinuz-2.6.5-7.104-default 51M /lib/modules/2.6.5-7.104-default [..] Gruß Sören
Hallo, Am Tue, 17 Aug 2004, Sören Wengerowsky schrieb:
Am Mon, 16 Aug 2004, Sören Wengerowsky schrieb:
Am Montag, 16. August 2004 20:13 schrieb David Haller:
Seit SUSE optimierte Kernel (k_athlon z.B.) bringt das performancemaessig eigentlich nix mehr.
Ich dachte jetzt eigentlich, diese Athlon-Kernel gibts seit dem 2.6er nicht mehr bei SuSE.. Muss mich wohl geirrt haben.
Nein, hast schon recht. Der (32bit) 9.1er Kernel ist wohl mit CONFIG_M586=y kompiliert (schau in /boot/config-`uname -r`) Ja
Am Montag, 16. August 2004 21:55 schrieb David Haller: linux:~ # cat /boot/config-`uname -r` |grep CONFIG_M586 CONFIG_M586=y # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set linux:~ #
Schade eigentlich, dass es die Athlon-Kernel nicht mehr gibt! War anscheinend zuviel Aufwand für die "RPM-Packer" bei Suse, immer 2 Kernel bereit und aktuell zu halten.
Vermutlich.
, wenn du ne P4 oder Athlon hast , dann lohnt sich's evtl. schon, weil einige Routinen (v.a. haeufige) sind teilweise mit MMX oder gar SSE Assemblerbefehlen geschrieben. Ein 'CONFIG_MPENTIUM4' oder 'CONFIG_MK8' oder so duerfte sich schon bei manchen kernellastingen Dingen sogar bemerkbar machen. AMD Athlon XP 1700+ mit 1460Mhz, um genau zu sein.. oder merkt man das erst bei den großen Athlons?
Meinst du mit "grossen" die Opterons/Athlon64? Die brauchen ja eh nen anderen Kernel. Ansonsten: Ich glaube, selbst fuer meinen cpu family : 6 model : 1 model name : AMD-K7(tm) Processor stepping : 2 cpu MHz : 499.040 lohnt es sich, mit aktiviertem MMX zu kompilieren. Und mit nem neueren gcc (>= 3.0) und deinem Athlon XP wohl noch mehr (s.u.). Aber wohl gemerkt: das, was man dadurch "rausholen" kann ist wohl mess- aber nicht fuehlbar im Bereich von <= 10% oder so. Erwarte dir also nicht zuviel.
Wenn's dich interessiert und C lesen kannst, dann kannst du ja mal in asm-i386 kruschteln. Leider kann ich kein C. Was würde ich dort zu sehen bekommen?
Da koenntest du sehen, wann welche Assembler-Teile mit MMX / SSE kompiliert werden. Es gibt ein paar Basis-Routinen z.B. memcpy oder strstr, die durchaus haeufig im Kernel aufgerufen werden und die auch als MMX etc. vorhanden sind und mit nur CONFIG_M586 AFAIK nicht verwendet werden, z.B. _mmx_memcpy aus arch/i386/lib/mmx.c. Wieviel das in der Praxis ausmacht weiss ich aber auch nicht.
Ja. Bzw. generell mehr wegzulassen. Dazu muss man dann aber seine Hardware und anderes recht gut kennen. Mein Kernel ist sicherlich kleiner als ein aehnlicher SuSE-Kernel:
$ du -hs /boot/*-`uname -r` /lib/modules/`uname -r` 588k /boot/System.map-2.4.25-1l 1.1M /boot/bzImage-2.4.25-1l 3.4M /lib/modules/2.4.25-1l Bei /lib/modules sind bei mir 51MB.. der Rest ist nicht so auffallend größer. Aber in /lib/modules sind doch alle Module, auch die, die nicht geladen sind, oder?
Ja.
Warum stören auch ungeladene Module, außer, dass sie Festplattenplatz fressen? :-)
Nicht weiter, aber wenn man wie ich ueber 20 Kernels rumfahren hat, dann wird das schon interessant ;) # ls -A /lib/modules | wc -l 24 # du -hs /lib/modules 70M /lib/modules Haette jeder Kernel dort >= 30 MB statt ca. 3 MB... Ich hab allerdings auch vieles rausgeworfen was ich nicht brauche, was aber auf moderneren Kisten notwendig ist, so komme ich z.B. komplett ohne USB aus, und IIRC sind die USB-Module ziemliche Platz- und Speicherfresser (das sind z.B. beim 2.6.4-37-default schon 2.3 MB).
56K /boot/config-2.6.5-7.104-default 1,2M /boot/initrd-2.6.5-7.104-default <--warum existiert dieser Eintrag bei dir gar nicht? Liegt das an dem 2.4-2.6-Unterschied?
Nein. Das liegt daran, dass ich alles zum Booten noetige fest im Kernel habe. Ich brauche also keine initrd, und es waere auch Unfug, wenn ich eine verwenden wuerde. Vgl. mein Multikernel-HOWTO (das ich aber immer noch nicht an Kernel 2.6 angepasst habe, da ich auf meinem Linux noch keinen 2.6.xer installiert habe. Ich sollte mir wohl mal die Zeit nehmen, das auf einer der Testinstallationen durchzutesten) und Thomas' Kernel-HOWTO.
116K /boot/Kerntypes-2.6.5-7.104-default 729K /boot/System.map-2.6.5-7.104-default 1,5M /boot/vmlinuz-2.6.5-7.104-default 51M /lib/modules/2.6.5-7.104-default ^^^ Oy!
Allerdings ist das auch ein 2.6.xer Kernel, ist also nicht direkt vergleichbar. -dnh -- If the bit is set to 1, the packet has evil intent. Secure systems SHOULD try to defend themselves against such packets. Insecure systems MAY chose to crash, be penetrated, etc. -- RfC 3514
Am Dienstag, 17. August 2004 00:11 schrieb David Haller: [..]
Meinst du mit "grossen" die Opterons/Athlon64? Die brauchen ja eh nen anderen Kernel. Ansonsten: Ich glaube, selbst fuer meinen Eigentlich meinte ich diese AMD mit 3000Mhz oder so, tut jetzt aber nichts zur Sache.
cpu family : 6 model : 1 model name : AMD-K7(tm) Processor stepping : 2 cpu MHz : 499.040
lohnt es sich, mit aktiviertem MMX zu kompilieren. Und mit nem neueren gcc (>= 3.0) und deinem Athlon XP wohl noch mehr (s.u.). Aber wohl gemerkt: das, was man dadurch "rausholen" kann ist wohl mess- aber nicht fuehlbar im Bereich von <= 10% oder so. Erwarte dir also nicht zuviel. Ok, ich werde es mal demnächst probieren.
Nicht weiter, aber wenn man wie ich ueber 20 Kernels rumfahren hat, dann wird das schon interessant ;) Heißa..
# ls -A /lib/modules | wc -l 24 # du -hs /lib/modules 70M /lib/modules
Haette jeder Kernel dort >= 30 MB statt ca. 3 MB... Das verstehe ich natürlich...
[..]
56K /boot/config-2.6.5-7.104-default 1,2M /boot/initrd-2.6.5-7.104-default <--warum existiert dieser Eintrag bei dir gar nicht? Liegt das an dem 2.4-2.6-Unterschied?
Nein. Das liegt daran, dass ich alles zum Booten noetige fest im Kernel habe. Ich brauche also keine initrd, und es waere auch Unfug, wenn ich eine verwenden wuerde. Vgl. mein Multikernel-HOWTO (das ich aber immer noch nicht an Kernel 2.6 angepasst habe, da ich auf meinem Linux noch keinen 2.6.xer installiert habe. Ich sollte mir wohl mal die Zeit nehmen, das auf einer der Testinstallationen durchzutesten) und Thomas' Kernel-HOWTO.
Das Howto von Thomas habe ich bereits gesehen. Deine Howtos werde ich mir morgen/heute mal zu Gemüte führen.
116K /boot/Kerntypes-2.6.5-7.104-default 729K /boot/System.map-2.6.5-7.104-default 1,5M /boot/vmlinuz-2.6.5-7.104-default 51M /lib/modules/2.6.5-7.104-default
^^^ Oy!
Allerdings ist das auch ein 2.6.xer Kernel, ist also nicht direkt vergleichbar.
Achso. Vielen Dank für die Erklärungen! Gruß Sören
Am Montag, 16. August 2004 20:13 schrieb David Haller:
Am Mon, 16 Aug 2004, Sören Wengerowsky schrieb:
ich habe immer wieder in Foren, etc.. gehört, dass alles viel besser und performanter laufen soll, wenn man z.B. den Kernel oder KDE selber kompiliert. Also meine kurze Frage: Würde es bezüglich der Performance etwas bringen, wenn ich den Kernel selber kompiliere Seit SUSE optimierte Kernel (k_athlon z.B.) bringt das performancemaessig eigentlich nix mehr. Interessant ist am ehesten noch, den Kernel abzuspecken. KDE selbstzukompilieren bringt tendenziell auch nicht wirklich was.
Grmpf. Basiert diese Aussage auch auf deinen Erfahrungen mit KDE 1 und 2? Mal abgesehen davon, dass Pauschalaussagen generell flasch sind, gab und gibt es einige gute Gründe dafür, KDE selbst zu kompilieren. Zwischenzeitlich war auch Geschwindigkeit dabei. Ich erinnere mal an Object prelinking: http://objprelink.sourceforge.net/ Mittlerweile ist dieser Punkt obsolet, und Geschwindigkeit würde ich als Vorteil wirklich nicht anführen. KDE3.3 einmal durchkompilieren dauert hier knapp 8 Stunden (Athlon XP 2100+) Aber man kommt mit selbst bauen auch eher in den Genuss der neuen Features. Tabbed Browsing und Mausgesten im Konqueror, Rechtschreibprüfung und html-editing (jaja, ich weiß braucht man nicht. Pauschalaussagen und so.) in KMail. Das sind so ein paar Dinge, die ich nicht missen möchte. Aber das nur am Rande. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Am Montag, 16. August 2004 20:13 schrieb Sören Wengerowsky:
ich habe immer wieder in Foren, etc.. gehört, dass alles viel besser und performanter laufen soll, wenn man z.B. den Kernel oder KDE selber kompiliert.
Wenn Du einfach nur neu compilierst, sollte 100% das selbe rauskommen, das SuSE als Binary-RPM liefert. Wenn Du mit, für Deine CPU optimierten Parametern compilierst kriegst Du vielleicht das eine oder andere Prozent zusätzlich, normalerweise aber nur messbar, nicht spürbar. Die Zeit, die Du zum compilieren brauchst, holst Du auf jeden Fall nicht wieder rein. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Sören Wengerowsky wrote: [Monday 16 August 2004 20:13]
ich habe immer wieder in Foren, etc.. gehört, dass alles viel besser und performanter laufen soll, wenn man z.B. den Kernel oder KDE selber kompiliert.
Unter "selber kompilieren" verstehe ich, daß man den Source-Code aufmerksam liest, gründlich darüber nachdenkt und dann ein hoch-optimiertes Maschinensprache-Programm mittels eines Binär-Editors eintippt. Gottähnliches Wissen über die jeweilige Architektur vorausgesetzt, kann man auf diese Weise innerhalb von ein wenigen Jahren kleinere Applikationen zwischen 5% bis 55% beschleunigen. Manche Leute glauben andererseits, daß mit "selbst kompilieren" gemeint ist, daß man sich ein paar Stunden am Vorbeirauschen von kryptischen Log-Informationen erfreut, anstatt dieses Vergnügen einem anonymen Server in der Compile-Farm eines Distributors zu überlassen. SCNR.
Meiner Meinung nach, müsste man dann Flags setzen, wenn man es für die eigene CPU optimieren will, aber das wird (soweit, wie ich das beurteilen kann, man möge mich verbessern, wenn ich da falsch liege) in dem Howto ausgelassen.
Welche CPU du hast, stellst du in der Kernel Konfiguration ein. Von Optimierungs-Flags würde ich persönlich beim Kompilieren vom Kernel eher die Finger lassen. Die werden wahrscheinlich mehr schaden als nützen. Thomas.
Thomas Hofer wrote:
eintippt. Gottähnliches Wissen über die jeweilige Architektur vorausgesetzt, kann man auf diese Weise innerhalb von ein wenigen Jahren kleinere Applikationen zwischen 5% bis 55% beschleunigen. Manche Leute glauben andererseits, daß mit "selbst kompilieren" gemeint ist, daß man sich ein paar Stunden am Vorbeirauschen von kryptischen Log-Informationen erfreut, anstatt dieses Vergnügen einem anonymen Server in der Compile-Farm eines Distributors zu überlassen. SCNR.
Cool! Selbstcompilierte Kernel scheinen bei manchen so eine Art Erkennungszeichen für die wirklichen Hardcore User zu sein, die sich damit von uns normalen Dummusern meinen arrogant abgrenzen zu müssen.
Von Optimierungs-Flags würde ich persönlich beim Kompilieren vom Kernel eher die Finger lassen. Die werden wahrscheinlich mehr schaden als nützen.
na dann macht ja das Selbstbauen zwecks Optimierung überhaupt keinen Sinn mehr. Es ist auch nicht das Argument der Leute mit dem "gottähnlichen Wissen", sondern sie sind scharf drauf den Kernel möglichst klein zu halten, was sie machen indem sie wirklich nur Unterstützung für die momentane Hardware ihrer momentanen Machine erlauben. Da kommen dann so Argumente wie, "Hey mein Kernel ist nur 200kb gross". Echt Cool! Wird dann eine andere Peripherie angeschlossen, ist der Rebuild natürlich angesagt. Ich meine, wer sich in so einer Art Computersteinzeit wohlfühlt, der sollte es tun, allerdings sich nicht einbilden, er wäre etwas besseres als derjenige, der dieses Vergnügen einem anonymen Server in der Compile-Farm eines Distributors überlässt. -Carsten
Hallo, Am Mon, 16 Aug 2004, Carsten Weinberg schrieb:
Selbstcompilierte Kernel scheinen bei manchen so eine Art Erkennungszeichen für die wirklichen Hardcore User zu sein, die sich damit von uns normalen Dummusern meinen arrogant abgrenzen zu müssen.
Zeig mir ein Kernel-2.4.2x oder gar einen 2.6.x von SuSE fuer SuSE 6.2 und wir sprechen nochmal. Die Gruende fuer einen eigenen Kernel sind vielfaeltig. Einer ist Stabilitaet, denn SuSE experimentiert doch relativ viel und die ganzen Patches brauche und will ich gar nicht. Ich fahre hier seit Mitte 2000 eine nur minimal veraenderte config von 2.4.0-test{1,4}, 2.4.16, 2.4.24 und 2.4.25, letztere jew. wg. den Sicherheits-Bugs. Ausserdem hab ich so einen Kernel in ca. 30min am laufen. -dnh -- What is c through a C-thru ruler? -- Jake Kesinger
David Haller wrote:
Die Gruende fuer einen eigenen Kernel sind vielfaeltig. Einer ist Stabilitaet, denn SuSE experimentiert doch relativ viel und die ganzen Patches brauche und will ich gar nicht.
dafür brauchts keinen selbstgebauten Kernel. Standardkernel als Binaries kann man anderswo downloaden. Viele tun es auch! Das Selbstbauen ist nun wahrlich kein Garant für Stabilität. Es ist eine nervige Angelegenheit, die Stunden und vor allem Insiderwissen braucht, was die vielen Parameter angeht. Natürlich handeln sich die meisten damit erst einmal einen instabilen Kernel ein, sie sind dann froh, wenns irgendwann einmal klappen sollte, und fortan bilden sie sich ein zur Expertengruppe zu gehören. Also ich denke sie sind dann eher auf dem Narrenschiff gelandet. Heutzutage sollte man es nicht nötig haben einen Kernel selbstbauen zu müssen, zumal solche -wie gesagt- als Binaries downloadbar sind. Linux als OS mit selbstgebautem Kernel - also so wird man sich gegen Windows niemals behaupten können, zumal das Einsparen von ein paar KB angesichts 512mb oder gar 1 GB PC's mit an die 4 GHz CPU einfach lächerlich geworden ist. Sicherlich war das früher anders, aber heute schreiben wir '2004.
Am Montag, 16. August 2004 22:31 schrieb Carsten Weinberg:
David Haller wrote:
Die Gruende fuer einen eigenen Kernel sind vielfaeltig. Einer ist Stabilitaet, denn SuSE experimentiert doch relativ viel und die ganzen Patches brauche und will ich gar nicht.
[...] Heutzutage sollte man es nicht nötig haben einen Kernel selbstbauen zu müssen, zumal solche -wie gesagt- als Binaries downloadbar sind. Linux als OS mit selbstgebautem Kernel - also so wird man sich gegen Windows niemals behaupten können, [...]
bla,bla,bla. Der selbe Mist wie immer...hm? Harald
Am Montag, 16. August 2004 22:31 schrieb Carsten Weinberg:
David Haller wrote:
Die Gruende fuer einen eigenen Kernel sind vielfaeltig. Einer ist Stabilitaet, denn SuSE experimentiert doch relativ viel und die ganzen Patches brauche und will ich gar nicht.
dafür brauchts keinen selbstgebauten Kernel. Standardkernel als Binaries kann man anderswo downloaden. Viele tun es auch!
Du hast scheinbar die Mail, welche Du zitiert hast nicht richtig gelesen. - Oder nenne so auf die schnelle _eine_ Quelle eines 2.6.xx Kernels welcher für SuSE 6.2 zum Download bereitsteht. ;-)
Das Selbstbauen ist nun wahrlich kein Garant für Stabilität. Es ist eine nervige Angelegenheit, die Stunden und vor allem Insiderwissen braucht, was die vielen Parameter angeht.
Wer sagt Dir das? Schon mal das Kernel-HOWTO von Manfred Tremmel gelesen?
Natürlich handeln sich die meisten damit erst einmal einen instabilen Kernel ein, sie sind dann froh, wenns irgendwann einmal klappen sollte, und fortan bilden sie sich ein zur Expertengruppe zu gehören.
Also ich denke sie sind dann eher auf dem Narrenschiff gelandet.
Dir geschehe nach Deinem Glauben. :)
Heutzutage sollte man es nicht nötig haben einen Kernel selbstbauen zu müssen, zumal solche -wie gesagt- als Binaries downloadbar sind.
Siehe oben. Nenn uns eine Quelle!
Linux als OS mit selbstgebautem Kernel - also so wird man sich gegen Windows niemals behaupten können, zumal das Einsparen von ein paar KB angesichts 512mb oder gar 1 GB PC's mit an die 4 GHz CPU einfach lächerlich geworden ist.
Na sowieso! Wenn alle Entwickler von Systemsoftware bzw. Anwendersofware so denken würden (viel zu viele tun das auch!) bräuchten wir bald 10 GHz CPU's und 50 GB RAM.
Sicherlich war das früher anders, aber heute schreiben wir '2004.
Tatsächlich!!! Und für Dich bedeutet Fortschritt dann also bedingungslose Verschwendung von Resourcen??? Gute Nacht! Andreas.
Am Montag, 16. August 2004 23:09 schrieb Andreas Scherer:
Am Montag, 16. August 2004 22:31 schrieb Carsten Weinberg:
David Haller wrote:
Die Gruende fuer einen eigenen Kernel sind vielfaeltig. Einer ist Stabilitaet, denn SuSE experimentiert doch relativ viel und die ganzen Patches brauche und will ich gar nicht.
dafür brauchts keinen selbstgebauten Kernel. Standardkernel als Binaries kann man anderswo downloaden. Viele tun es auch!
Du hast scheinbar die Mail, welche Du zitiert hast nicht richtig gelesen. - Oder nenne so auf die schnelle _eine_ Quelle eines 2.6.xx Kernels welcher für SuSE 6.2 zum Download bereitsteht. ;-)
zeig mir leute die einen 2.6er auf einer suse 6.2 laufen haben. die dürfte man an einer hand abzählen können. ich finde die ganze diskussion lächerlich. natürlich gibt es unzählige gründe sich einen kernel zu bauen. aber für den otto normaluser eben nicht. es sind nur spezielle sachen wo ich das dem default-kernel vorziehen würde. -- mit freundlichen Grüßen Best regards Marko Härtel Tel. +49 174-9238053 E-Mail: Marko.Haertel@web.de
Hallo, On 16-Aug-2004 Marko Härtel wrote:
[...] an einer hand abzählen können. ich finde die ganze diskussion lächerlich.
Und warum fuehrst du sie dann? Wenn du die Diskussion laecherlich findest, sie aber trotzdem so engagiert fuehrst, machst hoechstens du dich laecherlich.
natürlich gibt es unzählige gründe sich einen kernel zu bauen. aber
Z.B. auch den, dass es einfach Spass macht. Mir reicht schon, dass man sonst ueberall auf Effizienz etc. getrimmt wird und eigentlich nur noch tun soll, was sich rechnet. Bloss dazu habe ich null Bock. Und was spricht gegen selbst kompilierte Kernel? Nichts. Schlimmstenfalls muss man ueber das Rettungssystem booten. Wenn ich ein paar Promille Performancegewinn raushole, ist das schoen, aber unerheblich. Wichtig ist mir, dass ich beim Konfigurieren jedes Mal etwas neues entdecke und den Kernel weiter zu verkleinern schaffe. Man muss doch nicht alles immer so verkniffen sehen. Beste Gruesse, Heinz. -- http://www.pahlke-online.de/reisenews/ http://www.Pahlke-KunstWebDesign.de/
Hallo, Am Mon, 16 Aug 2004, Heinz W. Pahlke schrieb:
On 16-Aug-2004 Marko Härtel wrote:
[...] an einer hand abzählen können. ich finde die ganze diskussion lächerlich.
Und warum fuehrst du sie dann? Wenn du die Diskussion laecherlich findest, sie aber trotzdem so engagiert fuehrst, machst hoechstens du dich laecherlich.
ACK.
natürlich gibt es unzählige gründe sich einen kernel zu bauen. aber
Z.B. auch den, dass es einfach Spass macht. Mir reicht schon, dass man sonst ueberall auf Effizienz etc. getrimmt wird und eigentlich nur noch tun soll, was sich rechnet. Bloss dazu habe ich null Bock.
Und was spricht gegen selbst kompilierte Kernel? Nichts. Schlimmstenfalls muss man ueber das Rettungssystem booten.
ACK. Und dann ist da ja noch der "failsafe" Kernel samt Boot-Manager-Eintrag, den SUSE schon recht lange per default installiert. Und fuer 2.4.x gibt's ja mein nettes HOWTO, wie man bequem auch ein Dutzend 2.4.xer voellig unterschiedlich konfigurierte Kernels installieren und testen kann. Zu den Problemen mit der abgespeckten Syntax der modprobe.conf der 2.5.x, 2.6.x Kernels habe ich mich schon anderweitig ausgelassen. Fuer mich war praktisch seit dem ersten selbstkompilierten Kernel die Hauptmotivation die, dass ich gelernt habe, wie Linux (der Kernel) (im Groben) funktioniert. Das Kernelupdate 2.2.x auf 2.4.0-test1 hat einiges an Lesen (Documentation/*) und Lernen erfordert. Aber es hat sich sehr gelohnt. In letzter Zeit bin ich aber etwas faul gewesen und hab nur noch Sicherheitsupdates gemacht. -dnh --
Was haltet ihr von Lindows?? ABSTAND :-) [> Glenn Charpantier und Axel Lindlau in suse-linux]
Moin, Am Montag, den 16.08.2004, 23:49 +0200 schrieb Marko Härtel:
ich finde die ganze diskussion lächerlich. natürlich gibt es unzählige gründe sich einen kernel zu bauen. aber für den otto normaluser eben nicht. es sind nur spezielle sachen wo ich das dem default-kernel vorziehen würde.
Nein. Nein. Nein. Es ist gut, daß die Leute sich mit dem System beschäftigen. Es ist gut, daß sie neugierig sind. Es ist gut, daß sie ihre Erfahrungen (lies: Fehler) machen. Keine Handlung auf einem Linux-System kann so unsinnig sein, daß man nicht irgendwas dabei lernt. Linux existiert überhaupt nur, weil sein Erfinder sich mit funktionierendem Kram gelangweilt hat. Natürlich gibt es Grenzen - ein Webserver im Internet ist der falsche Platz, um das erste mal in seinem Leben zu gucken, was unter der GUI so stattfindet. Aber die meisten hier haben "private" Systeme. In der Regel spielt Uptime, Stabilität und dergleichen nicht die geringste Rolle. Lass die Leute lernen - einer von hundert "Bastlern" wird in fünf Jahren den Kernelpatch schreiben, der mein und dein System besser macht. Die 99 anderen haben mehr oder weniger Spaß gehabt, ohne anderen zu schaden. Wenn ich alles mit einer Sinnfrage hinterlegen würde, säße ich jetzt nicht vorm Rechner, sondern am Heimtrainer. Soviel dazu. :-) Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Am Montag, 16. August 2004 23:49 schrieb Marko Härtel:
Am Montag, 16. August 2004 23:09 schrieb Andreas Scherer:
Am Montag, 16. August 2004 22:31 schrieb Carsten Weinberg:
David Haller wrote:
Die Gruende fuer einen eigenen Kernel sind vielfaeltig. Einer ist Stabilitaet, denn SuSE experimentiert doch relativ viel und die ganzen Patches brauche und will ich gar nicht.
dafür brauchts keinen selbstgebauten Kernel. Standardkernel als Binaries kann man anderswo downloaden. Viele tun es auch!
Du hast scheinbar die Mail, welche Du zitiert hast nicht richtig gelesen. - Oder nenne so auf die schnelle _eine_ Quelle eines 2.6.xx Kernels welcher für SuSE 6.2 zum Download bereitsteht. ;-)
zeig mir leute die einen 2.6er auf einer suse 6.2 laufen haben. die dürfte man an einer hand abzählen können. ich finde die ganze diskussion lächerlich. natürlich gibt es unzählige gründe sich einen kernel zu bauen. aber für den otto normaluser eben nicht. es sind nur spezielle sachen wo ich das dem default-kernel vorziehen würde.
Wiso muß man denn unbedingt Gründe Anführen? man könnte doch einfach mal etwas über das Herz seines Systemes erfahren wollen. man könnte sachen abschalten wo man nicht braucht. man könnte die Weinflasche auch mit dem Vorschlaghammer öffnen... es kann einfach nur Experimentierfreude sein... Ich denke daß diese Diskussion schon lächerlich ist... stell Dir mal vor es würde sich überhaupt niemand mehr mit dem Kernel (oder sonst einem Stück der Freien Software) befassen, und nur das nehmen was in der Box daherkommt, dann bleibt die Entwicklung einfach stehen. Wer selber Backen will, kann das doch tun. Das erinnert mich hier unter anderem an das Thema : "Du bist kein Biker, Du hast keine Harley, ich bin ein Biker weil ich habe eine Harley..." Anmerkung aus Erfahrung: Harlefahrer fahren Ihre Kräder meist bis kurz vors Treffen laden das Teil vom Hänger ab, und machen sich selber glauben im Jahr 20Tausend Kilometer gefahren zu sein. Wen Interessierts? Wen Interessierts wer sich selber n Kernel baut? Wen Interessierts wer alles komplett aus der Distrikiste nimmt? Wen Interessierts wer welche Distri nimmt? Eingentlich niemand, Hauptsache das Läuft alles und schleudert kein Spam und keine Viren ins Netz... fertig, und wer einen Kernel Bauen kann (wo dann nachher auch funktioniert) der kann mehr als Ich (hab ich Respekt vor). Ich betrachte mch schon als Normal User (Ich und Normal ...fragt die netten Menschen von SuSE Talk) aber ich bin nicht Otto, ich sehe schon daß ich unter Umständen hier das eine oder andere für mich Verbessern könnte wenn ich hier selber was Backen würde, aber mir Fehlt die Zeit und der Nerv dazu, also lass ichs mal bleiben und fahre mit einem System wo nicht 100% ist, aber es geht... MfG TB (s Köchle) -- http://www.gasthof-linde.de http://www.chef-de-cuisine.de
Am Montag, 16. August 2004 23:09 schrieb Andreas Scherer:
Wer sagt Dir das? Schon mal das Kernel-HOWTO von Manfred Tremmel gelesen?
Ich hab ja schon das eine oder andere gemacht, aber ein Kernel-HOWTO wäre mir neu ;-) Meinst Du http://www.thomashertweck.de/kernel.html von Thomas Hertweck, oder http://www.dhaller.de/linux/multikernel.html von David Haller? -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ Manfred | http://packman.links2linux.de/
Carsten Weinberg schrieb am 08/16/2004 10:31 PM:
Heutzutage sollte man es nicht nötig haben einen Kernel selbstbauen zu müssen, zumal solche -wie gesagt- als Binaries downloadbar sind.
Und was machst Du auf einem Server, auf dem Sicherheit und Stabilität extrem wichtig ist? Einen vorkompilierten Kernel installieren, in dem alles mögliche unnütze Zeug drin ist und der Modulunterstützung einkompiliert hat? Michael.
On Monday 16 August 2004 23:17, Michael Schachtebeck wrote:
Carsten Weinberg schrieb am 08/16/2004 10:31 PM:
Heutzutage sollte man es nicht nötig haben einen Kernel selbstbauen zu müssen, zumal solche -wie gesagt- als Binaries downloadbar sind.
Und was machst Du auf einem Server, auf dem Sicherheit und Stabilität extrem wichtig ist? Einen vorkompilierten Kernel installieren, in dem alles mögliche unnütze Zeug drin ist und der Modulunterstützung einkompiliert hat?
Ist wohl nötig. Sonst wird Linux nie mit einem Windows Server 2003 mithalten können. Vielen Linuxservern fehlt ja sogar die graphische Oberfläche. Ferdinand
Ferdinand Ihringer schrieb am 08/16/2004 11:26 PM:
On Monday 16 August 2004 23:17, Michael Schachtebeck wrote:
Und was machst Du auf einem Server, auf dem Sicherheit und Stabilität extrem wichtig ist? Einen vorkompilierten Kernel installieren, in dem alles mögliche unnütze Zeug drin ist und der Modulunterstützung einkompiliert hat?
Ist wohl nötig. Sonst wird Linux nie mit einem Windows Server 2003 mithalten können.
Ich weiß nicht, ob das ernst gemeint ist. Falls ja, weiß ich nicht, ob ich jetzt lachen oder weinen soll.
Vielen Linuxservern fehlt ja sogar die graphische Oberfläche.
Hallo?!? Das ist doch gerade der Vorteil. Michael.
Am Montag, 16. August 2004 23:26 schrieb Ferdinand Ihringer:
On Monday 16 August 2004 23:17, Michael Schachtebeck wrote:
Carsten Weinberg schrieb am 08/16/2004 10:31 PM:
Heutzutage sollte man es nicht nötig haben einen Kernel selbstbauen zu müssen, zumal solche -wie gesagt- als Binaries downloadbar sind.
Und was machst Du auf einem Server, auf dem Sicherheit und Stabilität extrem wichtig ist? Einen vorkompilierten Kernel installieren, in dem alles mögliche unnütze Zeug drin ist und der Modulunterstützung einkompiliert hat?
Ist wohl nötig. Sonst wird Linux nie mit einem Windows Server 2003 mithalten können. Vielen Linuxservern fehlt ja sogar die graphische Oberfläche.
Eine graphische Benutzeroberfläche hat ja auch auf einem Server nix zu suchen! Der Server ist ja keine Workstation. Und um so weniger unnützes Zeug im Kernel ist um so sicherer ist der Server. Um auf die Frage Win 2k3 Server <> Linux Server einzugehen. Statisiken bei netcraft.com ansehen und dann reden. Linux hat AFAIK die größten Zuwächse im Serverbereich. Mit Win 2k3 kann es Linux allemal aufnehmen. Soweit ich mich erinnere haben HP und Linux gemeinsam einen Performance Rekord aufgestellt. Sicher nicht mit einem Standardkernel. Gruß, Andreas
Am Montag August 16 2004 23:26 schrieb Ferdinand Ihringer:
On Monday 16 August 2004 23:17, Michael Schachtebeck wrote:
Carsten Weinberg schrieb am 08/16/2004 10:31 PM:
Heutzutage sollte man es nicht nötig haben einen Kernel selbstbauen zu müssen, zumal solche -wie gesagt- als Binaries downloadbar sind.
Und was machst Du auf einem Server, auf dem Sicherheit und Stabilität extrem wichtig ist? Einen vorkompilierten Kernel installieren, in dem alles mögliche unnütze Zeug drin ist und der Modulunterstützung einkompiliert hat?
Ist wohl nötig. Sonst wird Linux nie mit einem Windows Server 2003 mithalten können. Vielen Linuxservern fehlt ja sogar die graphische Oberfläche.
Ferdinand
Für was um alles in der Welt braucht ein Server eine grafische Oberfläche? Zum Solitär spielen, für das Einfangen von Viren/Würmern etc. durch das Tor Internet Explorer? Schau dich mal bei Peripheriegeräten wie Netzwerkdruckern, Storage-Systemen etc. um, dort werden auch Serversysteme benutzt, höchstens der Client ist grafisch (-> siehe auch Embedded Systems). Gruß Udo -- Only a fool fights in a burning house. -- Kank the Klingon, "Day of the Dove", stardate unknown
On Monday 16 August 2004 23:26, Ferdinand Ihringer wrote:
On Monday 16 August 2004 23:17, Michael Schachtebeck wrote:
Carsten Weinberg schrieb am 08/16/2004 10:31 PM:
Heutzutage sollte man es nicht nötig haben einen Kernel selbstbauen zu müssen, zumal solche -wie gesagt- als Binaries downloadbar sind.
Und was machst Du auf einem Server, auf dem Sicherheit und Stabilität extrem wichtig ist? Einen vorkompilierten Kernel installieren, in dem alles mögliche unnütze Zeug drin ist und der Modulunterstützung einkompiliert hat?
Ist wohl nötig. Sonst wird Linux nie mit einem Windows Server 2003 mithalten können. Vielen Linuxservern fehlt ja sogar die graphische Oberfläche.
Hilfe! Muss man zu allem ein SCNR oder ;-) dazuschreiben? Das war natürlich nicht ernstgemeint. Ferdinand
Am Dienstag, 17. August 2004 00:14 schrieb Ferdinand Ihringer:
On Monday 16 August 2004 23:26, Ferdinand Ihringer wrote:
On Monday 16 August 2004 23:17, Michael Schachtebeck wrote:
Carsten Weinberg schrieb am 08/16/2004 10:31 PM:
Heutzutage sollte man es nicht nötig haben einen Kernel selbstbauen zu müssen, zumal solche -wie gesagt- als Binaries downloadbar sind.
Und was machst Du auf einem Server, auf dem Sicherheit und Stabilität extrem wichtig ist? Einen vorkompilierten Kernel installieren, in dem alles mögliche unnütze Zeug drin ist und der Modulunterstützung einkompiliert hat?
Ist wohl nötig. Sonst wird Linux nie mit einem Windows Server 2003 mithalten können. Vielen Linuxservern fehlt ja sogar die graphische Oberfläche.
Hilfe! Muss man zu allem ein SCNR oder ;-) dazuschreiben? Das war natürlich nicht ernstgemeint.
Natürlich... sonst wird doch der Humor eine Nuance zu Schwarz, und Monty Pyton ist hier AFAIK noch nicht Subcribet.... (würde sich dann allerdings MontX PXton nennen ;-)) MfG TB -- http://www.gasthof-linde.de http://www.chef-de-cuisine.de
Am Dienstag August 17 2004 00:21 schrieb Thilo Alfred Bätzig:
Natürlich... sonst wird doch der Humor eine Nuance zu Schwarz, und Monty Pyton ist hier AFAIK noch nicht Subcribet.... (würde sich dann allerdings MontX PXton nennen ;-))
Eher Monty Python *g* Gruß Udo -- Respect is a rational process -- McCoy, "The Galileo Seven", stardate 2822.3
Hallo, Am Mon, 16 Aug 2004, Carsten Weinberg schrieb:
David Haller wrote:
Die Gruende fuer einen eigenen Kernel sind vielfaeltig. Einer ist Stabilitaet, denn SuSE experimentiert doch relativ viel und die ganzen Patches brauche und will ich gar nicht.
dafür brauchts keinen selbstgebauten Kernel. Standardkernel als Binaries kann man anderswo downloaden. Viele tun es auch!
*shudder* Wo denn zum Beispiel?
Heutzutage sollte man es nicht nötig haben einen Kernel selbstbauen zu müssen, zumal solche -wie gesagt- als Binaries downloadbar sind. Linux als OS mit selbstgebautem Kernel - also so wird man sich gegen Windows niemals behaupten können, zumal das Einsparen von ein paar KB angesichts 512mb oder gar 1 GB PC's mit an die 4 GHz CPU einfach lächerlich geworden ist. Sicherlich war das früher anders, aber heute schreiben wir '2004.
[ ] du hast verstanden. Warum kaufst du dir eigentlich keinen Mac Dual G5 mit MacOS X? Oder verwendest deine P4-3.x GHz Kiste mit WinXP? ==== /proc/cpuinfo ==== cpu family : 6 model : 1 model name : AMD-K7(tm) Processor stepping : 2 cpu MHz : 499.040 ==== /proc/meminfo ==== total: used: free: shared: buffers: cached: Mem: 328908800 324112384 4796416 0 37494784 97398784 Swap: 674459648 32251904 642207744 ==== Und fuer meine Hardware ist das viel RAM. Und nein, ich brauche keine schnellere Hardware. Schau dir "buffers" und "cached" an. Und normal brauch ich gar keinen Swap. Wer Linux an Windows misst, misst Mist. -dnh --
In Yast2-System-Editor /etc/sysconfig-Dateien in System-Kernel-MODULES_LOADED_ON_BOOT ide-scsi eintragen. *JAUUUUUUUULLLLL* *ARRRGGHHHH* Man reiche mir eine Klinik-Jahrespackung von $SCHMERZMITTEL!!! [> Heinz Dittmar und David Haller in suse-linux]
Am Di, den 17.08.2004 schrieb David Haller um 0:26:
Wer Linux an Windows misst, misst Mist.
*gesiggt* :-) Bye Michael -- Eines Tages wird der Rechner laufen, und an dem Tag gehe ich in Rente ... -- Christian Kuhn in suse-linux _______________________________________________________________________ http://macbyte.info/ ICQ #151172379 http://dattuxi.de/
Carsten Weinberg wrote:
[...] Das Selbstbauen ist nun wahrlich kein Garant für Stabilität. Es ist eine nervige Angelegenheit, die Stunden und vor allem Insiderwissen braucht, was die vielen Parameter angeht. Natürlich handeln sich die meisten damit erst einmal einen instabilen Kernel ein, sie sind dann froh, wenns irgendwann einmal klappen sollte, und fortan bilden sie sich ein zur Expertengruppe zu gehören.
Also ich denke sie sind dann eher auf dem Narrenschiff gelandet.
Oh je, bei Deinen Ansichten stellen sich mir echt die Haare zu Berge... Du hast Scheuklappen auf! Man *muss* ja nicht einen Kernel selbst compilieren, aber man *kann* es, und Du solltest diese Leute nicht verurteilen. Es ist vielleicht am Anfang ein wenig schwierig, aber man kann *sehr viel* dabei lernen, und daher halte ich Leute, die sich damit beschaeftigen, nicht auf dem Weg zu einem Narrenschiff. Wenn Du es als nervige Angelegenheit ansiehst oder es nicht kannst, dann ist das eine Sache, und das ist ja auch nicht weiter tragisch - die Distributoren stellen Dir ja alles fuer Deinen taeglichen Bedarf zur Verfuegung. Aber dass Du hier andere, die vielleicht mal einen Blick tiefer ins System werfen wollen, so verurteilst, finde ich daneben!
Heutzutage sollte man es nicht nötig haben einen Kernel selbstbauen zu müssen, zumal solche -wie gesagt- als Binaries downloadbar sind. Linux als OS mit selbstgebautem Kernel - also so wird man sich gegen Windows niemals behaupten können, zumal das Einsparen von ein paar KB angesichts 512mb oder gar 1 GB PC's mit an die 4 GHz CPU einfach lächerlich geworden ist. Sicherlich war das früher anders, aber heute schreiben wir '2004.
[ ] Du kennst die Gruende, warum man einen eigenen Kernel baut. Th. *kopfschuettelnd*
Am Mittwoch, 18. August 2004 14:31 schrieb Thomas Hertweck:
Sorry fuer die nachtraegliche Antwort, ich war ein Weilchen abwesend... Trotzdem vielen Dank :-)
Also meine kurze Frage: Würde es bezüglich der Performance etwas bringen, wenn ich den Kernel (so wie in Thomas' Howto: http://thomashertweck.de/kernel.html) selber kompiliere, oder ist das nur ein subjektiver Eindruck, den viele Leute haben, wenn sie einen Kernel gebaut haben?
Solange es keine objektiven Messungen sind, die Du gesehen hast von diesen Leuten, wuerde ich es mal eher auf den subjektiven Eindruck der Leute schieben. Wirklich merken tut man naemlich einen Geschwindigkeitszuwachs in der Regel erst, wenn er doch recht deutlich (deutlich mehr als 10% oder so) ausfaellt... Und das ist nur in gewissen Faellen zu erzielen.
Ok, vielen Dank. So ähnlich hatte ich mir das anhand der Antworten, die ich bekommen habe schon gedacht.
Die Compiler-Flags solltest Du beim Kernel *nicht* veraendern. Dort ist Code, der wirklich optimiert werden muss, bereits von Hand optimiert worden. Im Prinzip wuerde es hier reichen, die richtige CPU bei der Kernel-Konfiguration auszuwaehlen.
Ok. Ich werde es demnächst mal anhand deines Howtos ausprobieren, da SuSE ja leider keine Athlon-Kernel mehr anbietet.
PS: Warum setzt Du das reply-to auf die Listenadresse? Das ist eigentlich nicht Sinn der Sache. Danke für den Hinweis. Ich habe mir das hier nochmal durchgelesen: http://www.eschkitai.de/linux/listreply.html
Also wenn ich jetzt bei deiner Mail hier zum Beispiel auf "Antworten" klicke, steht die Listen-Adresse dort schon. Bei "An-Liste-Antworten" auch. und bei "Antwort-an-Verfasser" geht die Mail als PM raus. Ich weiß nicht, wie ich das ändern kann, dass das Reply nicht an die Liste geht.. ich dachte bisher immer, das wäre so richtig. Und nach dem Text oben liegt das wohl an der Mailingliste, oder? Trotzdem werde ich versuchen, mich an das "List-Reply" zu gewöhnen. Gruß Sören
Hallo Sören, hallo Leute, Am Mittwoch, 18. August 2004 16:07 schrieb Sören Wengerowsky:
Am Mittwoch, 18. August 2004 14:31 schrieb Thomas Hertweck:
PS: Warum setzt Du das reply-to auf die Listenadresse? Das ist eigentlich nicht Sinn der Sache.
Danke für den Hinweis. Ich habe mir das hier nochmal durchgelesen: http://www.eschkitai.de/linux/listreply.html
Also wenn ich jetzt bei deiner Mail hier zum Beispiel auf "Antworten" klicke, steht die Listen-Adresse dort schon. Bei "An-Liste-Antworten" auch. und bei "Antwort-an-Verfasser" geht die Mail als PM raus.
Das ist eine Neuerung in KMail 1.6.x (sprich: KDE 3.2). Über Sinn und Unsinn will ich nicht diskutieren (ich denke aber, dass eher letzteres zutrifft ;-) - jedenfalls kannst Du das alte Verhalten wiederherstellen, wenn Du die Taste R an "Antwort an Verfasser" bindest bzw. im Menü oder der Symbolleiste eben diesen Eintrag wählst. Für Antworten an die Liste dann die Taste L bzw. "Antwort an Mailingliste" verwenden, wie von älteren KMail-Versionen gewohnt.
Ich weiß nicht, wie ich das ändern kann, dass das Reply nicht an die Liste geht.. ich dachte bisher immer, das wäre so richtig. Und nach dem Text oben liegt das wohl an der Mailingliste, oder?
Nö, in suse-linux wird glücklicherweise nicht das Reply-To verändert. Gruß Christian Boltz --
Die Systemuhr auf dem Rechner mit SuSE8.1 geht jeden Tag ca. 10 Minuten schneller. Stellt es eine Krankheit dar? Hattest Du den Rechner mal mit in Simbabwe? Buschfieber? [> Matthias Dort und Thilo Alfred Bätzig in suse-linux]
Am Sonntag, 22. August 2004 22:22 schrieb Christian Boltz:
Das ist eine Neuerung in KMail 1.6.x (sprich: KDE 3.2). Über Sinn und Unsinn will ich nicht diskutieren (ich denke aber, dass eher letzteres zutrifft ;-) - jedenfalls kannst Du das alte Verhalten wiederherstellen, wenn Du die Taste R an "Antwort an Verfasser" bindest bzw. im Menü oder der Symbolleiste eben diesen Eintrag wählst.
Für Antworten an die Liste dann die Taste L bzw. "Antwort an Mailingliste" verwenden, wie von älteren KMail-Versionen gewohnt. Vielen Dank für die Erklärung.
ich habe jetzt das R an "Antwort an Verfasser" gebunden. Gruß Sören
Carsten Weinberg
Thomas Hofer wrote:
eintippt. Gottähnliches Wissen über die jeweilige Architektur vorausgesetzt, kann man auf diese Weise innerhalb von ein wenigen Jahren kleinere Applikationen zwischen 5% bis 55% beschleunigen. Manche Leute glauben andererseits, daß mit "selbst kompilieren" gemeint ist, daß man sich ein paar Stunden am Vorbeirauschen von kryptischen Log-Informationen erfreut, anstatt dieses Vergnügen einem anonymen Server in der Compile-Farm eines Distributors zu überlassen. SCNR.
Cool!
Selbstcompilierte Kernel scheinen bei manchen so eine Art Erkennungszeichen für die wirklichen Hardcore User zu sein, die sich damit von uns normalen Dummusern meinen arrogant abgrenzen zu müssen.
Nein, das ist Unsinn. Vor vielen, vielen Jahren, etwa bis Version 5.3 hat SuSE nur 386er Kernel in die Distribution aufgenommen [1]. Wenn du dann aber schon einen Pentium hattest, machte es Sinn, einen optimierten Kernel zu kompilieren, Wenn du dann auch noch ISDN hattest, mußtest du sowieso ein neuer Kernel her. Zu dieser Zeit war es also, auch für Anfänger wie mich, zwingend notwendig Kernel zu kompilieren. Man gewöhnt sich aber daran. Es gibt weiterhin viele Anwender, die ältere Distributions-Versionen verwenden, aber für bestimmte Hardware trotzdem neuere Kernelversionen benötigen. So habe ich z.B. auf meiner SuSE-7.3 auch einen 4.2.25 Kernel, den gibt es aber für diese Version nicht mehr von der Stange. Es gibt also Gründe, wo man einen Kernel kompilieren muß, das hat aber wenig mit Arroganz zu tun. ... Ich habe mal das SuSE-Linux-5.3 Handbuch aus dem Regal genommen. Das Kapitel 13 Der Kernel, behandelt auf über 30 Seiten die Erstellung eines eigenen Kernels dazu noch 25 Seiten für die Kernelmodule. SuSE hat damals noch empfohlen, eigene Kernel zu erstellen. :-) -Dieter Footnotes: [1] Ich glaube 6.0 war die erste Version mit 586er Kernel. -- Dieter Klünter | Systemberatung Tel.: +49.40.64861967 Fax : +49.40.64891521 http://www.avci.de
Hallo, Am Mon, 16 Aug 2004, Dieter Kluenter schrieb:
[1] Ich glaube 6.0 war die erste Version mit 586er Kernel.
Nein. Eher die 7.0. /me schaut mal eben auf die CDs: SuSE 6.2 kam nur mit /cdrom/suse/images/config (0)$ grep '^[^#]*CONFIG_M.8' config.* \ | cut -d: -f2 | sort -u CONFIG_M386=y -dnh -- 13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.'' --- Antoine de Saint-Exupéry as cited in Eric S. Raymond, "The Cathedral and the Bazaar"
Gerald Goebel
Am Montag, 16. August 2004 23:45 schrieb Dieter Kluenter:
Kernelversionen benötigen. So habe ich z.B. auf meiner SuSE-7.3 auch einen 4.2.25 Kernel, den gibt es aber für diese Version nicht mehr ^^^^^^^^ Ich auch haben will ;-)
Da mußt du noch ein paar Jahre warten. :-) Leider hat sich ein Dreher eingeschlichen :( Man sollte so spät keine Mail schreiben. Es ist natürlich der 2.4.25 -Dieter -- Dieter Klünter | Systemberatung Tel.: +49.40.64861967 Fax : +49.40.64891521 http://www.avci.de
Am Montag, 16. August 2004 21:23 schrieb Carsten Weinberg: [..]
Es ist auch nicht das Argument der Leute mit dem "gottähnlichen Wissen", sondern sie sind scharf drauf den Kernel möglichst klein zu halten, was sie machen indem sie wirklich nur Unterstützung für die momentane Hardware ihrer momentanen Machine erlauben. Da kommen dann so Argumente wie, "Hey mein Kernel ist nur 200kb gross". Echt Cool! :-D
Wird dann eine andere Peripherie angeschlossen, ist der Rebuild natürlich angesagt. Nicht nur dann.. was mir am meisten Unbehagen macht, ist, dass man dann per You keine Security-bugfixes mehr erhält.. somit ist man also irgendwie darauf angewiesen, die neuste Version zu haben, oder die alte öfter zu patchen.
Ich meine, wer sich in so einer Art Computersteinzeit wohlfühlt, Ich weiß nicht, ob Steinzeit das richtige Wort ist. der sollte es tun, allerdings sich nicht einbilden, er wäre etwas besseres als derjenige, der dieses Vergnügen einem anonymen Server in der Compile-Farm eines Distributors überlässt. ACK Erhöht den Freak-faktor natürlich ungemein.. und wirkt professionell.. Vielleicht kann man sich dieses Kryptischen Meldungen irgendwie als bewegtes Hintergrundbild einrichten ;-)
gruß Sören
Moin, Am Montag, den 16.08.2004, 23:54 +0200 schrieb Sören Wengerowsky:
ACK Erhöht den Freak-faktor natürlich ungemein.. und wirkt professionell.. Vielleicht kann man sich dieses Kryptischen Meldungen irgendwie als bewegtes Hintergrundbild einrichten
Ich bin sicher, ihr alle arbeitet ernsthaft mit euren Rechnern, wenn ihr nicht gerade eure hochsicheren Server wartet... :-) Also, ich für meinen Teil mache sowas einfach deswegen, weil ich neugierig bin. Weil ich es als Herausforderung empfinde (für andere mag das trivial erscheinen) - oder weil ich mich total verbastelt habe und glaube (irre), der neue Kernel könne die neue Hardware zum laufen bringen ...oder einfach, weil es einfach nicht in Ordnung ist, eine neue Distri auszuprobieren, bevor man die alte kaputt gemacht hat! Also tut nicht so erwachsen. Das seid ihr ja garnicht! :-) Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Am Dienstag, 17. August 2004 00:04 schrieb Joerg Rossdeutscher:
Moin,
Am Montag, den 16.08.2004, 23:54 +0200 schrieb Sören Wengerowsky:
ACK Erhöht den Freak-faktor natürlich ungemein.. und wirkt professionell.. Vielleicht kann man sich dieses Kryptischen Meldungen irgendwie als bewegtes Hintergrundbild einrichten
Ich bin sicher, ihr alle arbeitet ernsthaft mit euren Rechnern, wenn ihr nicht gerade eure hochsicheren Server wartet... :-)
Also, ich für meinen Teil mache sowas einfach deswegen, weil ich neugierig bin. Weil ich es als Herausforderung empfinde (für andere mag das trivial erscheinen) - oder weil ich mich total verbastelt habe und glaube (irre), der neue Kernel könne die neue Hardware zum laufen bringen ...oder einfach, weil es einfach nicht in Ordnung ist, eine neue Distri auszuprobieren, bevor man die alte kaputt gemacht hat!
Also tut nicht so erwachsen. Das seid ihr ja garnicht! :-)
HE ich bin nicht Erwachsen... Ich bin Koch und Normal... MfG TB (s Köchle) -- http://www.gasthof-linde.de http://www.chef-de-cuisine.de
Am Dienstag, 17. August 2004 00:04 schrieb Joerg Rossdeutscher:
Moin,
Am Montag, den 16.08.2004, 23:54 +0200 schrieb Sören Wengerowsky:
ACK Erhöht den Freak-faktor natürlich ungemein.. und wirkt professionell.. Vielleicht kann man sich dieses Kryptischen Meldungen irgendwie als bewegtes Hintergrundbild einrichten
Ich bin sicher, ihr alle arbeitet ernsthaft mit euren Rechnern, wenn ihr nicht gerade eure hochsicheren Server wartet... :-)
Also, ich für meinen Teil mache sowas einfach deswegen, weil ich neugierig bin. Weil ich es als Herausforderung empfinde (für andere mag das trivial erscheinen) Klar, das Bedürfnis haben bestimmt alle Linuxer :-) - oder weil ich mich total verbastelt habe und glaube (irre), der neue Kernel könne die neue Hardware zum laufen bringen ...oder einfach, weil es einfach nicht in Ordnung ist, eine neue Distri auszuprobieren, bevor man die alte kaputt gemacht hat!
Also tut nicht so erwachsen. Das seid ihr ja garnicht! :-) Hast mich ertappt ;-)
Carsten Weinberg wrote:
Cool!
Selbstcompilierte Kernel scheinen bei manchen so eine Art Erkennungszeichen für die wirklichen Hardcore User zu sein, die sich damit von uns normalen Dummusern meinen arrogant abgrenzen zu müssen.
[ ] Du hast Ahnung.
Es ist auch nicht das Argument der Leute mit dem "gottähnlichen Wissen", sondern sie sind scharf drauf den Kernel möglichst klein zu halten, was sie machen indem sie wirklich nur Unterstützung für die momentane Hardware ihrer momentanen Machine erlauben. Da kommen dann so Argumente wie, "Hey mein Kernel ist nur 200kb gross". Echt Cool!
Wird dann eine andere Peripherie angeschlossen, ist der Rebuild natürlich angesagt. Ich meine, wer sich in so einer Art Computersteinzeit wohlfühlt, der sollte es tun, allerdings sich nicht einbilden, er wäre etwas besseres als derjenige, der dieses Vergnügen einem anonymen Server in der Compile-Farm eines Distributors überlässt.
Oh Mann, wie blind bist Du, dass Du alle ueber einen Kamm scherst? Natuerlich gibt es Leute, die einen eigenen Kernel nur deswegen compilieren, weil es cool ist. Genau so gibt es Leute, die meinen, staendig und immer die alleraktuelleste Version eines Programms haben zu muessen. Deswegen kann man aber nicht alle in einen Topf werfen. Es gibt sehr gute Gruende, einen Kernel selbst zu bauen, und das kann man auch so machen, dass ohne Probleme neue Peripherie Geraete angeschlossen werden koennen. Wenn Du hier das Gegenteil behauptest, dann hast Du wahrlich keine Ahnung und solltest besser schweigen. CU, Th.
Am Montag, 16. August 2004 20:35 schrieb Thomas Hofer:
Sören Wengerowsky wrote: [Monday 16 August 2004 20:13]
ich habe immer wieder in Foren, etc.. gehört, dass alles viel besser und performanter laufen soll, wenn man z.B. den Kernel oder KDE selber kompiliert. [...] Manche Leute glauben andererseits, daß mit "selbst kompilieren" gemeint ist, daß man sich ein paar Stunden am Vorbeirauschen von kryptischen Log-Informationen erfreut, anstatt dieses Vergnügen einem anonymen Server in der Compile-Farm eines Distributors zu überlassen. SCNR. Das meinte ich! Sorry, falls ich da irgendetwas "falsch definiert" habe. Wie würdest du das bezeichnen, wenn man ./configure && make && make install eintippt (bei kleineren Anwendungen jetzt.) ?
Welche CPU du hast, stellst du in der Kernel Konfiguration ein. Von Optimierungs-Flags würde ich persönlich beim Kompilieren vom Kernel eher die Finger lassen. Die werden wahrscheinlich mehr schaden als nützen. Also wird dann die Architektur, etc.. angepasst. Danke für die Info. dann wird es wohl auch etwas die Performance verbessern.
Wie ist das mit kde und anderen Anwendungen, die mit der oben genannten Prozedur installiert werden? ist dort irgendwie ein Geschwindigkeitszuwachs zu erwarten? AFAIR nein, aber das ist alles nur Halbwissen bei mir.. Gruß Sören
Sören Wengerowsky wrote: [Monday 16 August 2004 22:41]
Das meinte ich! Sorry, falls ich da irgendetwas "falsch definiert" habe. Wie würdest du das bezeichnen, wenn man ./configure && make && make install eintippt (bei kleineren Anwendungen jetzt.) ?
Du hast nichts falsches gesagt - das war doch nur ein dummer Scherz meinerseits. Inhaltlich habe ich ungefähr das gemeint, was Manfred Tremmel in diesem Thread geantwortet hat.
Wie ist das mit kde und anderen Anwendungen, die mit der oben genannten Prozedur installiert werden? ist dort irgendwie ein Geschwindigkeitszuwachs zu erwarten? AFAIR nein, aber das ist alles nur Halbwissen bei mir..
Bei KDE könnte es etwas bringen, Optimierungsflags zu setzen. Ich bezweifle allerdings, daß der Unterschied wirklich spürbar sein wird. Zur Entspannung: http://www.funroll-loops.org/ Thomas.
Am Montag, 16. August 2004 21:26 schrieb Thomas Hofer:
Sören Wengerowsky wrote: [Monday 16 August 2004 22:41]
Das meinte ich! Sorry, falls ich da irgendetwas "falsch definiert" habe. Wie würdest du das bezeichnen, wenn man ./configure && make && make install eintippt (bei kleineren Anwendungen jetzt.) ? <-- war nicht als Angriff gemeint o.Ä.
Du hast nichts falsches gesagt - das war doch nur ein dummer Scherz meinerseits. Inhaltlich habe ich ungefähr das gemeint, was Manfred Tremmel in diesem Thread geantwortet hat. War mir bewusst, dass es nicht ernst gemeint war ;-)
Wie ist das mit kde und anderen Anwendungen, die mit der oben genannten Prozedur installiert werden? ist dort irgendwie ein Geschwindigkeitszuwachs zu erwarten? AFAIR nein, aber das ist alles nur Halbwissen bei mir..
Bei KDE könnte es etwas bringen, Optimierungsflags zu setzen. Ich bezweifle allerdings, daß der Unterschied wirklich spürbar sein wird. Vielleicht probiere ich es mal, wenn ich zuviel Zeit haben sollte.. Aber ich schätze, bei meinem AMD mit 1460 Mhz dauert das den ganzen Tag, oder?
Zur Entspannung: http://www.funroll-loops.org/ Schick.
Gruß Sören
Am Montag, 16. August 2004 22:41 schrieb Sören Wengerowsky:
Das meinte ich! Sorry, falls ich da irgendetwas "falsch definiert" habe. Wie würdest du das bezeichnen, wenn man ./configure && make && make install eintippt (bei kleineren Anwendungen jetzt.) ?
Also ich würde das als Verbrechen gegen das Packaging System der Distribution bezeichnen. Zumindestens checkinstall sollte man bemühen, wenn man schon keine "richtigen" RPMs baut.
Also wird dann die Architektur, etc.. angepasst. Danke für die Info. dann wird es wohl auch etwas die Performance verbessern.
Je nachdem, gerade beim Kernel sind unter vielen Architekturen die selben Compiler-Parameter hinterlegt, da ändert das im einzelnen dann nichts.
Wie ist das mit kde und anderen Anwendungen, die mit der oben genannten Prozedur installiert werden? ist dort irgendwie ein Geschwindigkeitszuwachs zu erwarten? AFAIR nein, aber das ist alles nur Halbwissen bei mir..
Wenn Du wie oben beschrieben installierst, wird es normalerweise langsamer, wie das was SuSE anbietet. Die Binaries, die da rauskommen sind universal i386, während SuSE i586er optimiert und auch sonst einige gewinnbringenden configure Optionen einsetzt. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Montag, 16. August 2004 21:30 schrieb Manfred Tremmel:
Am Montag, 16. August 2004 22:41 schrieb Sören Wengerowsky:
Das meinte ich! Sorry, falls ich da irgendetwas "falsch definiert" habe. Wie würdest du das bezeichnen, wenn man ./configure && make && make install eintippt (bei kleineren Anwendungen jetzt.) ?
Also ich würde das als Verbrechen gegen das Packaging System der Distribution bezeichnen. Zumindestens checkinstall sollte man bemühen, wenn man schon keine "richtigen" RPMs baut. :-D Naja.. checkinstall funktioniert bei mir irgendwie nur jedes zweite mal.. Deswegen habe ich ca. 100MB Sourcen auf der Platte, die ich wegen dem make uninstall brauche.. Oder gibt es da noch eine bessere Möglichkeit?
Also wird dann die Architektur, etc.. angepasst. Danke für die Info. dann wird es wohl auch etwas die Performance verbessern.
Je nachdem, gerade beim Kernel sind unter vielen Architekturen die selben Compiler-Parameter hinterlegt, da ändert das im einzelnen dann nichts. Ah. gut. Danke.
Wenn Du wie oben beschrieben installierst, wird es normalerweise langsamer, wie das was SuSE anbietet. Die Binaries, die da rauskommen sind universal i386, während SuSE i586er optimiert und auch sonst einige gewinnbringenden configure Optionen einsetzt. Interessant.. Ich hatte immer das gefühl, dass dieses kdebase-suse mit diesem Suse-Skin für den Kicker und die anderen Sachen irgendwie bremst, denn als ich einmal das normale Kdebase-rpm für Suse probiert hatte, kam mir alles viel schneller vor... Kann das jemand bestätigen? Aber ist wohl eher nur meine Subjektive Einschätzung.
Gruß Sören
Sören Wengerowsky wrote: [Monday 16 August 2004 23:26]
Deswegen habe ich ca. 100MB Sourcen auf der Platte, die ich wegen dem make uninstall brauche.. Oder gibt es da noch eine bessere Möglichkeit?
Mein Ansatz ist, daß ich jedes von Source kompilierte Paket in ein separates Verzeichnis unter /opt installiere. In meiner .bashrc habe ich ein Skript, das die notwendigen Environment-Variablen dynamisch ermittelt (PATH, LD_LIBRARY_PATH, MANPATH, etc). Auf diese Weise kann ich die Pakete leicht deinstallieren (rm -r) oder kurzfristig deaktivieren (einfach wegschieben). Und mit rpm komme ich so auch nicht ins Gehege. Thomas.
Am Montag, 16. August 2004 22:00 schrieb Thomas Hofer:
Sören Wengerowsky wrote: [Monday 16 August 2004 23:26]
Deswegen habe ich ca. 100MB Sourcen auf der Platte, die ich wegen dem make uninstall brauche.. Oder gibt es da noch eine bessere Möglichkeit?
Mein Ansatz ist, daß ich jedes von Source kompilierte Paket in ein separates Verzeichnis unter /opt installiere. In meiner .bashrc habe ich ein Skript, das die notwendigen Environment-Variablen dynamisch ermittelt (PATH, LD_LIBRARY_PATH, MANPATH, etc). Hört sich Interessant an. Kannst du das mal genauer erklären? Wozu müssen die Variablen für jedes Programm geändert werden? Auf diese Weise kann ich die Pakete leicht deinstallieren (rm -r) rm -r /opt/programm ? oder kurzfristig deaktivieren (einfach wegschieben) . Und mit rpm komme ich so auch nicht ins Gehege. Warum nicht? Es ist doch eigentlich egal, wo ich die Pakete hin installiere, oder?
Gruß Sören
Sören Wengerowsky wrote: [Monday 16 August 2004 23:46]
Am Montag, 16. August 2004 22:00 schrieb Thomas Hofer:
Mein Ansatz ist, daß ich jedes von Source kompilierte Paket in ein separates Verzeichnis unter /opt installiere. In meiner .bashrc habe ich ein Skript, das die notwendigen Environment-Variablen dynamisch ermittelt (PATH, LD_LIBRARY_PATH, MANPATH, etc).
Wozu müssen die Variablen für jedes Programm geändert werden?
Im PATH stehen alle Verzeichnisse, unter denen ausführbare Programme gesucht werden. Wenn man nichts weiter unternimmt, landen selbst kompilierte Programme unter /usr/local/bin. Da dieses Verzeichnis im vorkonfigurierten Pfad enthalten ist, kann man das Programm danach gleich aufrufen. Installiert man aber in ein separates Verzeichnis, z.B. /opt/xzy, dann landet das ausführbare Programm unter /opt/xyz/bin, was nicht im normalen Pfad steht - daher kann man das Programm dann nicht aufrufen. Das selbe gilt für Libraries (LD_LIBRARY_PATH) und man pages. Damit ich nicht nach jeder Installation meine Environment-Variablen um die neuen Verzeichnisse erweitern muß, lasse ich ein Skript alle /opt/*/bin Verzeichnisse sammeln und zum PATH verketten. Für /opt/*/lib und /opt/*/man das selbe. Das funktioniert automatisch - ich muß mich nur neu einloggen.
Auf diese Weise kann ich die Pakete leicht deinstallieren (rm -r)
rm -r /opt/programm ?
Genau.
oder kurzfristig deaktivieren (einfach wegschieben) . Und mit rpm komme ich so auch nicht ins Gehege.
Warum nicht? Es ist doch eigentlich egal, wo ich die Pakete hin installiere, oder?
Ich habe nur gemeint, daß ich nicht versehentlich Files überschreiben kann, die von rpm Paketen stammen. Thomas.
Am Montag, 16. August 2004 22:47 schrieb Thomas Hofer:
Sören Wengerowsky wrote: [Monday 16 August 2004 23:46]
Erstmal vielen Dank für die ausführliche Erklärung! Achso.. ok. Jetzt verstehe ich das auch.
Wozu müssen die Variablen für jedes Programm geändert werden? Im PATH stehen alle Verzeichnisse, unter denen ausführbare Programme gesucht werden. Wenn man nichts weiter unternimmt, landen selbst kompilierte Programme unter /usr/local/bin. Da dieses Verzeichnis im vorkonfigurierten Pfad enthalten ist, kann man das Programm danach gleich aufrufen. Installiert man aber in ein separates Verzeichnis, z.B. /opt/xzy, dann landet das ausführbare Programm unter /opt/xyz/bin, was nicht im normalen Pfad steht - daher kann man das Programm dann nicht aufrufen. Das selbe gilt für Libraries (LD_LIBRARY_PATH) und man pages. Ich kannte bis jetzt nur den "PATH" (aus alten Dos-Zeiten ;) ) Mit dem Begriff "Environment-Variablen" konnte ich vorhin nicht so viel anfangen. Aber jetzt weiß ich, was du meinst. Danke.
Damit ich nicht nach jeder Installation meine Environment-Variablen um die neuen Verzeichnisse erweitern muß, lasse ich ein Skript alle /opt/*/bin Verzeichnisse sammeln und zum PATH verketten. Für /opt/*/lib und /opt/*/man das selbe. Das funktioniert automatisch - ich muß mich nur neu einloggen.
[..]
Ich habe nur gemeint, daß ich nicht versehentlich Files überschreiben kann, die von rpm Paketen stammen. Das leuchtet jetzt auch ein. Warum hast du ausgerechnet /opt gewählt? Ich habe gerade nachgesehen, was /opt eigentlich ist, und im Benutzerhandbuch von Suse 8.2 steht auf Seite 363: "/opt: optionale Software, größere Systeme (z.B. Kde, Gnome, Netscape) "
Kommt es sich dann nicht mit den Paketen in /opt ins Gehege, oder nutzt du das nur für "kleinere" Dinge? Wäre natürlich toll, wenn du das Script hier mal Posten würdest (oder auch per PM an mich..) ich glaube, das könnte mir auch einige Stunden Arbeit sparen. Gruß Sören
Sören Wengerowsky wrote: [Tuesday 17 August 2004 00:37]
Warum hast du ausgerechnet /opt gewählt? Ich habe gerade nachgesehen, was /opt eigentlich ist, und im Benutzerhandbuch von Suse 8.2 steht auf Seite 363: "/opt: optionale Software, größere Systeme (z.B. Kde, Gnome, Netscape) "
Ich bin nicht sicher, ob ich den FHS bis auf den i-Punkt einhalte, aber mir schien /opt der richtige Ort für so etwas zu sein. Schließlich handelt es sich um Einzelpakete, die nicht Teil der Distribution sind. Wer unsicher ist, sollte das hier mit seinem Rechtsanwalt durcharbeiten: http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACK...
Kommt es sich dann nicht mit den Paketen in /opt ins Gehege, oder nutzt du das nur für "kleinere" Dinge?
Zitat FHS: "Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator." Bevor man ein neues Paket installiert muß man sich halt vergewissern, daß das betreffende Verzeichnis noch nicht verwendet wird.
Wäre natürlich toll, wenn du das Script hier mal Posten würdest (oder auch per PM an mich..) ich glaube, das könnte mir auch einige Stunden Arbeit sparen.
Sinngemäß steht in meiner ~/.bashrc so etwas: export PATH LD_LIBRARY_PATH MANPATH PATH=`ls -d /opt/*/{s,}bin|tr "\n" :`$PATH LD_LIBRARY_PATH=`ls -d /opt/*/lib|tr "\n" :`$LD_LIBRARY_PATH MANPATH=`ls -d /opt/*/man|tr "\n" :`$MANPATH Zur Erklärung: 'ls -d /opt/*/{s,}bin' erzeugt eine Liste aller bin und sbin Unterverzeichnisse und 'tr "\n" :' wandelt die Umbrüche in Doppelpunkte um (das ist das Trennzeichen in den Pfaden). Unter KDE muß man sich aus- und einloggen, damit die neuen Pfade nach einer Installation wirksam werden. Wenn man so arbeiten will, muß man allerdings in gewissen Situationen Zusatzarbeit leisten: z.B. wenn beim compilieren von einem Paket Abhängigkeiten zu einem anderen Paket bestehen, muß man bei configure den jeweiligen Ort bekanntgeben, usw. Insgesamt hat man mehr Kontrolle aber teilweise auch mehr Schwierigkeiten auf diese Weise. Thomas.
Hallo, Am Mon, 16 Aug 2004, Thomas Hofer schrieb:
Sinngemäß steht in meiner ~/.bashrc so etwas:
export PATH LD_LIBRARY_PATH MANPATH PATH=`ls -d /opt/*/{s,}bin|tr "\n" :`$PATH LD_LIBRARY_PATH=`ls -d /opt/*/lib|tr "\n" :`$LD_LIBRARY_PATH MANPATH=`ls -d /opt/*/man|tr "\n" :`$MANPATH
Nette Idee, aber du faellst auf die Fresse, wenn da mal ein Verzeichnis mit nem Leerzeichen oder so auftaucht. Ausserdem bringt das export _vor_ dem Aendern genau gar nix. Besser also (Quoting beachten!) PATH="$PATH:`ls -d /opt/*/{s,}bin | tr '\n' ':'`" LD_LIBRARY_PATH="$LD_LIBRARY_PATH:`ls -d /opt/*/lib | tr '\n' ':'`" MANPATH="$MANPATH:`ls -d /opt/*/man | tr '\n' ':'`" export PATH LD_LIBRARY_PATH MANPATH Man beachte ebenfalls, dass erst die vordefinierten Pfade kommen. Das kann man im Einzelfall aber aendern. Generell halte ich es fuer sinnvoller, das in /etc/profile.local abzuhandeln, da man dort dann die richtige[tm] Reihenfolge festlegen kann. Das kann dort dann durchaus auch "automatisiert" erfolgen. ==== for DIR in \ /opt/WMaker/bin \ /usr/X11R6/bin \ [..] /usr/games/bin \ do test -d "$DIR" && PATH="$PATH:$DIR" done export PATH ==== Das mit dem 'ls' muesste dann aber (an der gewuenschten Stelle) so aussehen: ls -d /opt/*/{s,}bin | tr '\n' ' ' \ Analog fuer MANPATH, INFOPATH und LD_LIBRARY_PATH (falls noetig). -dnh, der sich im Zweifelsfall wrapperscripte nach ~/bin/ oder /usr/local/bin legt oder die noetigen Variablen auch per Hand setzt. Oder ein "generisches" wrapperscript fuer z.B. kde2 oder gnome2. -- Traditionalists will of course make sacrifices to all storage devices, though things like CompactFlash are too small for a whole goat; something around the size of a chipmunk appears called-for. At the other end of the scale, a SAN probably calls for the passing of a passing waterbuffalo. -- AdB
David Haller wrote: [Tuesday 17 August 2004 01:17]
Am Mon, 16 Aug 2004, Thomas Hofer schrieb:
Sinngemäß steht in meiner ~/.bashrc so etwas:
export PATH LD_LIBRARY_PATH MANPATH PATH=`ls -d /opt/*/{s,}bin|tr "\n" :`$PATH LD_LIBRARY_PATH=`ls -d /opt/*/lib|tr "\n" :`$LD_LIBRARY_PATH MANPATH=`ls -d /opt/*/man|tr "\n" :`$MANPATH
Nette Idee, aber du faellst auf die Fresse, wenn da mal ein Verzeichnis mit nem Leerzeichen oder so auftaucht.
Solche Verzeichnisse gibt es auf meinem System nicht, und es wird sie auch nie geben.
Ausserdem bringt das export _vor_ dem Aendern genau gar nix.
Ich schreibe das immer in dieser Reihenfolge, und zwar aus zwei Gründen: 1. Ich finde es übersichtlicher. 2. Es hat eine lehrreiche Wirkung auf Leute, die ich dazu bringen kann, sich darüber zu wundern, das das eben doch funktioniert. ;-)
Besser also (Quoting beachten!)
Quotes sind jedenfalls eine gute Idee. Thomas.
Am Dienstag, 17. August 2004 01:17 schrieb David Haller:
Hallo,
Am Mon, 16 Aug 2004, Thomas Hofer schrieb:
Sinngemäß steht in meiner ~/.bashrc so etwas:
export PATH LD_LIBRARY_PATH MANPATH PATH=`ls -d /opt/*/{s,}bin|tr "\n" :`$PATH LD_LIBRARY_PATH=`ls -d /opt/*/lib|tr "\n" :`$LD_LIBRARY_PATH MANPATH=`ls -d /opt/*/man|tr "\n" :`$MANPATH
Nette Idee, aber du faellst auf die Fresse, wenn da mal ein Verzeichnis mit nem Leerzeichen oder so auftaucht. Ausserdem bringt das export _vor_ dem Aendern genau gar nix. Besser also (Quoting beachten!) kann man bei soetwas nicht einfach ein: IFS=$'\n' An den Anfang der Zeile setzen?
PATH="$PATH:`ls -d /opt/*/{s,}bin | tr '\n' ':'`" LD_LIBRARY_PATH="$LD_LIBRARY_PATH:`ls -d /opt/*/lib | tr '\n' ':'`" MANPATH="$MANPATH:`ls -d /opt/*/man | tr '\n' ':'`" export PATH LD_LIBRARY_PATH MANPATH
Man beachte ebenfalls, dass erst die vordefinierten Pfade kommen. Das kann man im Einzelfall aber aendern.
Generell halte ich es fuer sinnvoller, das in /etc/profile.local abzuhandeln, da man dort dann die richtige[tm] Reihenfolge festlegen kann. Das kann dort dann durchaus auch "automatisiert" erfolgen.
Ok.. werde ich mal ausprobieren. Vielen Dank Sören
Hallo, Am Tue, 17 Aug 2004, Sören Wengerowsky schrieb:
Am Dienstag, 17. August 2004 01:17 schrieb David Haller:
Am Mon, 16 Aug 2004, Thomas Hofer schrieb:
export PATH LD_LIBRARY_PATH MANPATH PATH=`ls -d /opt/*/{s,}bin|tr "\n" :`$PATH LD_LIBRARY_PATH=`ls -d /opt/*/lib|tr "\n" :`$LD_LIBRARY_PATH MANPATH=`ls -d /opt/*/man|tr "\n" :`$MANPATH
Nette Idee, aber du faellst auf die Fresse, wenn da mal ein Verzeichnis mit nem Leerzeichen oder so auftaucht. Ausserdem bringt das export _vor_ dem Aendern genau gar nix. Besser also (Quoting beachten!) kann man bei soetwas nicht einfach ein: IFS=$'\n' An den Anfang der Zeile setzen?
Dann solltest du aber IFS anschliessend wieder zuruecksetzen. OIFS="$IFS"; IFS=$'\n' ... IFS="$OIFS" Allerdings sollte man generell einfach immer richtig quoten. -dnh -- Gib einem Hungrigen einen Fisch, und er ist fuer einen Tag satt. Zeig ihm, wie man angelt, und er poebelt Dich an, dass er besseres zu tun haette, als Schnuere ins Wasser haengen zu lassen. -- David Kastrup in de.comp.text.tex
Am Montag, 16. August 2004 23:51 schrieb Thomas Hofer: [..]
Schließlich handelt es sich um Einzelpakete, die nicht Teil der Distribution sind. Ok, das ist ein Argument.
[..]
Zitat FHS: "Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator." Das auch :-)
Bevor man ein neues Paket installiert muß man sich halt vergewissern, daß das betreffende Verzeichnis noch nicht verwendet wird. Gut, kde oder Openoffice werde ich auch nicht selber kompilieren, von daher ist es schon richtig, das Verzeichnis für die kleineren Sachen zu nehmen (also auch von dieser Sichtweise her)
Wäre natürlich toll, wenn du das Script hier mal Posten würdest (oder auch per PM an mich..) ich glaube, das könnte mir auch einige Stunden Arbeit sparen.
Sinngemäß steht in meiner ~/.bashrc so etwas: warum Sinngemäß? ich werde es hier so mal ausprobieren, da ich da eigentlich nichts sehe, was angepasst werden müsste.. naja, ich werde es mir morgen/Heute nochmal bei Tageslicht ansehen.
export PATH LD_LIBRARY_PATH MANPATH PATH=`ls -d /opt/*/{s,}bin|tr "\n" :`$PATH LD_LIBRARY_PATH=`ls -d /opt/*/lib|tr "\n" :`$LD_LIBRARY_PATH MANPATH=`ls -d /opt/*/man|tr "\n" :`$MANPATH
Zur Erklärung: 'ls -d /opt/*/{s,}bin' erzeugt eine Liste aller bin und sbin Unterverzeichnisse und 'tr "\n" :' wandelt die Umbrüche in Doppelpunkte um (das ist das Trennzeichen in den Pfaden).
Unter KDE muß man sich aus- und einloggen, damit die neuen Pfade nach einer Installation wirksam werden. Das ist schön einfach :-)
Wenn man so arbeiten will, muß man allerdings in gewissen Situationen Zusatzarbeit leisten: z.B. wenn beim compilieren von einem Paket Abhängigkeiten zu einem anderen Paket bestehen, muß man bei configure den jeweiligen Ort bekanntgeben, usw. Das stimmt.. aber die meisten davon kriegt man wohl mit Configure-Optionen in den Griff, oder?
Insgesamt hat man mehr Kontrolle aber teilweise auch mehr Schwierigkeiten auf diese Weise. Ich werde es auf jeden Fall mal ausprobieren! Vielen Dank!
Gruß Sören
Hallo, Am Tue, 17 Aug 2004, Sören Wengerowsky schrieb:
Am Montag, 16. August 2004 23:51 schrieb Thomas Hofer: [..]
Wenn man so arbeiten will, muß man allerdings in gewissen Situationen Zusatzarbeit leisten: z.B. wenn beim compilieren von einem Paket Abhängigkeiten zu einem anderen Paket bestehen, muß man bei configure den jeweiligen Ort bekanntgeben, usw. Das stimmt.. aber die meisten davon kriegt man wohl mit Configure-Optionen in den Griff, oder?
Teilweise. Erstmal: verstehe, dass sich --prefix, --libdir usw. auf den Installationsort des _zu installierenden_ Paketes beziehen. Wenn jetzt configure etwas nicht findet dann sind z.B. $PATH, $QTDIR oder $PKG_CONFIG_PATH nicht richtig gesetzt (so dass dann das '${foo}-config'-script von lib${foo} oder QT oder ${foo}-${ver}.pc von lib${foo}-${ver} von pkg-config nicht gefunden werden). Bei "sauberen" Paketen kann man sowas teilweise durch configure-Optionen wie --with-${foo}=${fooprefix} umgehen (wobei $fooprefix dann die prefix ist, in der $foo installiert wurde, z.B. --with-${foo}=/opt/${foo}, wenn $foo mit --prefix=/opt/$foo kompiliert wurde). Ansonsten muss man anders (z.B. durch PATH="$PATH:/opt/$foo/bin") dafuer sorgen, dass die entsprechenden config-scripte / libs / header gefunden werden. Die Details, was wie wo gesucht und u.U. nicht gefunden wird sind aber sehr vom configure script (sofern vorhanden) des "neuen" Paketes abhaengig. Als Faustregel gilt eigentlich nur: - Sorge dafuer dass ${foo}-config in $PATH gefunden wird, oder - Sorge dafuer dass ${foo}-${ver}.pc in $PKG_CONFIG_PATH gefunden wird. Alles andere sind Sonderfaelle. Und, BTW, manche configure-scripte sind durchaus schlecht und testen unzureichend oder schlicht falsch. Das macht sich dann teils durch Fehler beim Kompilieren und/oder linken bemerkbar. -dnh -- (Multiple bracketed paragraphs usually indicate a severe lack of focus.) -- Juliusz Chroboczek
Hallo, Am Tue, 17 Aug 2004, Sören Wengerowsky schrieb:
Warum hast du ausgerechnet /opt gewählt?
Ich verwende dafuer z.B. /usr/local/tarballs, fuer groessere Sachen die ich an RPM vorbei installiere (und von denen keine andere SW abhaengt, z.B. OpenOffice.org) verwende ich /opt. Im Zweifelsfall schaut man einfach mit 'rpm -qf' ob ein Verzeichnis unter /opt/<foo> zu einem RPM-Paket gehoert (dabei sollte man aber durchaus rekursiv zu "signifikanten" Dateien gehen, da die Verzeichnisse selbst nicht unbedingt als zum RPM gehoerend eingetragen sind. Also z.B. $ rpm -qf /opt/kde/bin/konsole kbase-1.1.2-156 $ rpm -qf /opt/OpenOffice/1.0.3/program/soffice.bin file /opt/OpenOffice/1.0.3/program/soffice.bin is not owned by any package -dnh -- Du meinst, es gibt Menschen die vom Katzen so trainiert sind, das die die Katzen so erziehen das die machen was sie sowieso wollen, die Leute aber glauben lassen das die genau gehorchen. -- Rik Steenwinkel
Am Montag, 16. August 2004 21:30 schrieb Manfred Tremmel:
Wenn Du wie oben beschrieben installierst, wird es normalerweise langsamer, wie das was SuSE anbietet. Die Binaries, die da rauskommen sind universal i386, während SuSE i586er optimiert und auch sonst einige gewinnbringenden configure Optionen einsetzt.
Noch eine Frage.. warum wird bei mir i386 angezeigt, obwohl SuSE doch eigentlich auf i586 optimiert..? soeren@linux:~> uname -i i386 soeren@linux:~> uname -a Linux linux 2.6.5-7.104-default #1 Wed Jul 28 16:42:13 UTC 2004 i686 athlon i386 GNU/Linux Gruß Sören
Sorry fuer die nachtraegliche Antwort, ich war ein Weilchen abwesend... Sören Wengerowsky wrote:
ich habe immer wieder in Foren, etc.. gehört, dass alles viel besser und performanter laufen soll, wenn man z.B. den Kernel oder KDE selber kompiliert.
Du hast ja schon genug Antworten dazu bekommen, deswegen will ich mich da nicht weiter einmischen, es ist eigentlich alles gesagt. Ich persoenlich denke, dass sich eine Optimierung nur im Einzelfalle lohnt und abgewaegt werden muss. Eine generelle Aussage ist IMHO nicht moeglich.
Also meine kurze Frage: Würde es bezüglich der Performance etwas bringen, wenn ich den Kernel (so wie in Thomas' Howto: http://thomashertweck.de/kernel.html) selber kompiliere, oder ist das nur ein subjektiver Eindruck, den viele Leute haben, wenn sie einen Kernel gebaut haben?
Solange es keine objektiven Messungen sind, die Du gesehen hast von diesen Leuten, wuerde ich es mal eher auf den subjektiven Eindruck der Leute schieben. Wirklich merken tut man naemlich einen Geschwindigkeitszuwachs in der Regel erst, wenn er doch recht deutlich (deutlich mehr als 10% oder so) ausfaellt... Und das ist nur in gewissen Faellen zu erzielen.
Meiner Meinung nach, müsste man dann Flags setzen, wenn man es für die eigene CPU optimieren will, aber das wird (soweit, wie ich das beurteilen kann, man möge mich verbessern, wenn ich da falsch liege) in dem Howto ausgelassen.
Die Compiler-Flags solltest Du beim Kernel *nicht* veraendern. Dort ist Code, der wirklich optimiert werden muss, bereits von Hand optimiert worden. Im Prinzip wuerde es hier reichen, die richtige CPU bei der Kernel-Konfiguration auszuwaehlen. CU, Th. PS: Warum setzt Du das reply-to auf die Listenadresse? Das ist eigentlich nicht Sinn der Sache.
participants (20)
-
Andreas Scherer -
Carsten Weinberg -
Christian Boltz -
David Haller -
Dieter Kluenter -
Ferdinand Ihringer -
Gerald Goebel -
Harald_mail＠t-online.de -
Heinz W. Pahlke -
Joerg Rossdeutscher -
Manfred Tremmel -
Marko Härtel -
Martin Borchert -
Michael Raab -
Michael Schachtebeck -
Sören Wengerowsky -
Thilo Alfred Bätzig -
Thomas Hertweck -
Thomas Hofer -
Udo Neist