Hallo Lug,
nach einer kleinen Pause bin ich jetzt wieder in Sachen Linux aktiv geworden und habe mich mal an der Gentoo Distri versucht.
Zuerst hatte ich die Version 2004 mit dem Minimalinstaller installiert (stage3) und bin auch soweit gut weitergekommen und hatte auch schon einen 2.6 er Kernel kompiliert, nur dann gab es ständig probleme beim emerge von verschiedenen Paketen (mc, w3m, qt-libs) da sie beim compilieren gescheitert sind. Als nächstes habe ich versucht die 2004.1 darüberzuziehen, nur leider hatte das den erfolg, dass ich dann nicht mal mehr den Kernel compilieren konnte.
Kann man den 2.6 er Kernel schon benutzen? Gibt es etwas zu beachten, was nicht im Handbuch steht? Kann mir jemand einen Vernünftigen Server für die Binary Packete sagen, oder sollte man dazu die CD's benutzen ?
viele Grüße Joe
Johannes Richter joe_2000@web.de at 2004-05-08 1645 +0200:
Hallo Lug,
Hallo Johannes,
nach einer kleinen Pause bin ich jetzt wieder in Sachen Linux aktiv geworden und habe mich mal an der Gentoo Distri versucht.
Zuerst hatte ich die Version 2004 mit dem Minimalinstaller installiert (stage3) und bin auch soweit gut weitergekommen und hatte auch schon einen 2.6 er Kernel kompiliert, nur dann gab es ständig probleme beim emerge von verschiedenen Paketen (mc, w3m, qt-libs) da sie beim compilieren gescheitert sind.
Genaue Fehlermeldungen? (Die letzten 10-20 Zeilen)
Als nächstes habe ich versucht die 2004.1 darüberzuziehen
Eher keine gute Idee, IMHO.
nur leider hatte das den erfolg, dass ich dann nicht mal mehr den Kernel compilieren konnte.
Fehlermeldung?
Kann man den 2.6 er Kernel schon benutzen?
Natürlich, ich tue das seit einem halben Jahr (vor 2003-12-19 natürlich 2.5) und bin sehr zufrieden.
Gibt es etwas zu beachten, was nicht im Handbuch steht?
Die Gentoo-Dokumentation ist sehr gut, das kann ich mir eigentlich nicht vorstellen.
Kann mir jemand einen Vernünftigen Server für die Binary Packete sagen, oder sollte man dazu die CD's benutzen ?
Nein, kann ich nicht, ich kompiliere alles selber. Fehlermeldungen sollten dich nicht abschrecken, das auch zu tun. Mit Binaries verpasst du ja den halben Spaß.
MfG, Jonas Witt
On Sat, May 08, 2004 at 05:07:21PM +0200, Jonas Witt wrote:
Nein, kann ich nicht, ich kompiliere alles selber. Fehlermeldungen sollten dich nicht abschrecken, das auch zu tun. Mit Binaries verpasst du ja den halben Spaß.
Stimmt, anstatt in Minuten funktionell ausgefeilte Debian-Pakete (z.B.) zu installieren, kann man viele CPU-Stunden mit dem Kompilieren von halbgebackenen Gentoo-Ebuilds verbrauchen, nur damit man auch ja die letzte Compileroptimierungsstufe drin hat. Macht besonders viel Spass beim Up-to-date-halten von Produktionsservern. Nicht zu vergessen die Alle-Patches+Bugs-Die-Es-Gibt Gentoo Kernel Sources.
SCNR ;)
p.s.: Jaja, ich weiss das Debian nicht mehr das ist was es mal war.
Thomas Jacob jacob@internet24.de at 2004-05-08 1922 +0200:
On Sat, May 08, 2004 at 05:07:21PM +0200, Jonas Witt wrote:
Nein, kann ich nicht, ich kompiliere alles selber. Fehlermeldungen sollten dich nicht abschrecken, das auch zu tun. Mit Binaries verpasst du ja den halben Spaß.
Stimmt, anstatt in Minuten funktionell ausgefeilte Debian-Pakete (z.B.) zu installieren, kann man viele CPU-Stunden mit dem Kompilieren von halbgebackenen Gentoo-Ebuilds verbrauchen, nur damit man auch ja die letzte Compileroptimierungsstufe drin hat. Macht besonders viel Spass beim Up-to-date-halten von Produktionsservern. Nicht zu vergessen die Alle-Patches+Bugs-Die-Es-Gibt Gentoo Kernel Sources.
[ ] Du hast schonmal Gentoo benutzt (richtig) [ ] Ich hab schonmal Debian benutzt (richtig)
Deshalb sag ich auch nichts gegen Debian, nur weil ich von Gentoo überzeugt bin. Es wäre eh bloß ein platter Flame mit haarsträubenden Argumenten, so wie deiner. Natürlich wäre er auch nicht ernst gemeint, so wie deiner. (oder?) :)
-jonas
On Sat, May 08, 2004 at 07:44:45PM +0200, Jonas Witt wrote:
[X] Du hast schonmal Gentoo benutzt (richtig)
Und benutze es immer noch.
Es wäre eh bloß ein platter Flame mit haarsträubenden Argumenten, so wie deiner.
Du kannst ja mal versuchen, diese zu widerlegen, ich sammel sie noch mal zusammen.
1) Gentoo-Installationen und Upgrades dauern um Größenordnugen länger als bei Bin-Paket-Orientierten Distros. 2) Gentoo Ebuilds sind oft weniger ausgereift/robust als ./debian/*. Beispiel, bei iptables fehlen die meisten Interface-Bibliotheken/Headers. 3) Die Möglichkeit, alles mit -O3 --mcpu=MeineCPU --march=MeineCPU zu builden wird von vielen Gentoo-Adepten als erster Vorteil verbreitet. 4) Die Gentoo-Kernel-Sources sind vollgepackt mit allerlei Patches und deren Bugs (jüngstes Beispiel: ext3-Kernel-Memory-Leaks). Aber gut, wenn man einfach Standard-Kernels backt, läuft auch ein Gentoo-Server unter Last stabil ;)
Natürlich wäre er auch nicht ernst gemeint, so wie deiner. (oder?) :)
Doch. ;)
Gruesse, Thomas
Thomas Jacob jacob@internet24.de at 2004-05-09 1408 +0200:
Du kannst ja mal versuchen, diese zu widerlegen, ich sammel sie noch mal zusammen.
- Gentoo-Installationen und Upgrades dauern um Größenordnugen länger
als bei Bin-Paket-Orientierten Distros.
Ne Windows-Installation ist auch schneller als ne Gentoo-Installation. Dass Kompilieren länger dauert als kopieren, ist ja klar. Die Frage ist: warum hast du ein Problem damit, 12 Stunden zu installieren oder mal ne halbe Stunde auf nen Apache zu warten?
- Gentoo Ebuilds sind oft weniger ausgereift/robust als
./debian/*. Beispiel, bei iptables fehlen die meisten Interface-Bibliotheken/Headers.
Hm, bei meinen iptables ist alles dran, was zum Funktionieren benötigt wird.
- Die Möglichkeit, alles mit -O3 --mcpu=MeineCPU --march=MeineCPU zu
builden wird von vielen Gentoo-Adepten als erster Vorteil verbreitet.
Von mir nicht. Viel schlimmer sind die, die behaupten, dass mit 10 Zeilen CFLAGS alles noch viel schneller geht.
Viel interessanter sind eigentlich die USE-Flags. Oder hat Debian für jede Feature-Kombination ein Binary? Wie bekommst du mplayer mit MMX-, SSE- und SSE2-Unterstützung?
- Die Gentoo-Kernel-Sources sind vollgepackt mit allerlei Patches
und deren Bugs (jüngstes Beispiel: ext3-Kernel-Memory-Leaks). Aber
Gentoo bietet mir 42 Kernel-Compilations zu Auswahl an. Du musst nicht die nehmen, die dir nicht gefällt.
gut, wenn man einfach Standard-Kernels backt, läuft auch ein Gentoo-Server unter Last stabil ;)
Eben.
Ansonsten full ACK@Eric.
MfG, Jonas Witt
On Sun, May 09, 2004 at 03:59:42PM +0200, Jonas Witt wrote:
Ne Windows-Installation ist auch schneller als ne Gentoo-Installation. Dass Kompilieren länger dauert als kopieren, ist ja klar. Die Frage ist: warum hast du ein Problem damit, 12 Stunden zu installieren oder mal ne halbe Stunde auf nen Apache zu warten?
Hehe.. Meinst du die Frage ernst? Gut für mein Spielsystem zuhause macht das nichts, aber wenn ich schnell mal nen Server brauche, ist das ne lange Zeit.
- Gentoo Ebuilds sind oft weniger ausgereift/robust als
./debian/*. Beispiel, bei iptables fehlen die meisten Interface-Bibliotheken/Headers.
Hm, bei meinen iptables ist alles dran, was zum Funktionieren benötigt wird.
Die Kommandozeilentools schon, aber z.B. nicht libiptc, was man maschinelle Manipulieren braucht, zumindest für spezielle Sachen. Kann man natürlich durch ein Ebuild-Patch ändern, ok ;)
Von mir nicht. Viel schlimmer sind die, die behaupten, dass mit 10 Zeilen CFLAGS alles noch viel schneller geht.
;)
Viel interessanter sind eigentlich die USE-Flags. Oder hat Debian für jede Feature-Kombination ein Binary? Wie bekommst du mplayer mit MMX-, SSE- und SSE2-Unterstützung?
Ich kompiliere selbst. Dieses eine Programm. Aber sicher, in so einem Fall hat Gentoo Vorteile.
- Die Gentoo-Kernel-Sources sind vollgepackt mit allerlei Patches
und deren Bugs (jüngstes Beispiel: ext3-Kernel-Memory-Leaks). Aber
Gentoo bietet mir 42 Kernel-Compilations zu Auswahl an. Du musst nicht die nehmen, die dir nicht gefällt.
Wenn ich ext3 brauche, kann ich es nicht ausschalten.
On Sun, May 09, 2004 at 05:47:36PM +0200, Torsten Werner wrote:
mplayer-i386 ist ein Paket, dass zur Laufzeit die zum Prozessor passende Optimierung wählt. Ergo: neu übersetzen ist völlig unnötig.
runtime-cpudetection ist lame. Zumindest wenn du auf performance wert legst.
Stefan Seyfried wrote:
On Sun, May 09, 2004 at 05:47:36PM +0200, Torsten Werner wrote:
mplayer-i386 ist ein Paket, dass zur Laufzeit die zum Prozessor passende Optimierung wählt. Ergo: neu übersetzen ist völlig unnötig.
runtime-cpudetection ist lame. Zumindest wenn du auf performance wert legst.
Die CPU wird am Anfang einmal erkannt, die entsprechenden Routinen werden einmal geladen, anschließend x >> 1 mal ausgeführt. Die verschwendete Rechenzeit durch eine CPU-Detection ist doch nicht groß, insbesondere bei lange rechnenden Anwendungen sollte sie prozentual verschwindend gering sein.
mfg, Fabian
On Sun, May 09, 2004 at 08:24:52PM +0200, Fabian Hänsel wrote:
Stefan Seyfried wrote:
On Sun, May 09, 2004 at 05:47:36PM +0200, Torsten Werner wrote:
mplayer-i386 ist ein Paket, dass zur Laufzeit die zum Prozessor passende Optimierung wählt. Ergo: neu übersetzen ist völlig unnötig.
runtime-cpudetection ist lame. Zumindest wenn du auf performance wert legst.
Die CPU wird am Anfang einmal erkannt, die entsprechenden Routinen werden einmal geladen, anschließend x >> 1 mal ausgeführt. Die
Du schreibst aber jetzt nicht über MPlayer? Ich habe schon lange nicht mehr in den Code geschaut, aber es war wohl so, daß je nach erkannter CPU ein Sprungvektor anders initialisiert wurde, so daß anderer Assemblercode ausgeführt wurde. Dieser dynamische Sprungbefehl ist aber wohl wesentlich unperformanter, als wenn der handoptimierte MMX- oder SSE- oder wasauchimmer-Assemblercode direkt an dieser Stelle stehen würde.
verschwendete Rechenzeit durch eine CPU-Detection ist doch nicht groß,
nein, aber wenn du eine MPEG-Dekodierroutine hast, die teilweise CPU-Unabhängigen C-Code und teilweise handoptimierte Assembleranweisungen wie in libavcodec hast, dann macht das durchaus was aus.
insbesondere bei lange rechnenden Anwendungen sollte sie prozentual verschwindend gering sein.
Tja, im Zeitalter der Gigahertzen interessieren diese 2-3% die es beim MPlayer wohl sein sollen natürlich keinen mehr... :-)
Stefan Seyfried schrieb:
runtime-cpudetection ist lame. Zumindest wenn du auf performance wert legst.
Sorry, aber ohne exakte Benchmarks halte ich diese Aussage für völligen Quatsch. Aber sie passt meiner Erfahrung nach sehr gut zum typischen Argumentationsverhalten von gentoo-Fans.
Torsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo,
Sorry, aber ohne exakte Benchmarks halte ich diese Aussage für völligen Quatsch. Aber sie passt meiner Erfahrung nach sehr gut zum typischen Argumentationsverhalten von gentoo-Fans.
Echt? Ich kompiliere alle Pakete sehr konservativ mit -O2 -pipe. Laut Poll macht das der grösste Anteil der Gentoo-Foren-Nutzer ...
Was ich genial finde, ist nun mal, dass meine Packete auf G3 bzw. Athlon-XP angepasst sind.
Ausserdem finde ich die Leichtigkeit der Wahl der neuesten Software und die sehr nette Community sehr schön bei dieser Distribution.
Aber daran wird immer Linux scheitern. Wir sind zu zerstritten und manchmal zu sehr von unserer Distri eingenommen, um irgendwann die Leute von furchtbaren monopolistischen Betriebssystemen abzubringen ...
So wird das nie was. Immer diese Teufelskreise.
Grüsse
Marek
Marek Werstak schrieb:
Sorry, aber ohne exakte Benchmarks halte ich diese Aussage für völligen Quatsch. Aber sie passt meiner Erfahrung nach sehr gut zum typischen Argumentationsverhalten von gentoo-Fans.
Aber daran wird immer Linux scheitern. Wir sind zu zerstritten und manchmal zu sehr von unserer Distri eingenommen, um irgendwann die Leute von furchtbaren monopolistischen Betriebssystemen abzubringen ...
So wird das nie was. Immer diese Teufelskreise.
Hallo Marek,
ich gebe zu, der Satz mit 'typisch' ist etwas zu sehr verallgemeinert. Im Gegensatz zu manchen Distributionsverfechtern sehe ich aber auch bei Debian ganz klare Probleme, nur sind es nicht die, die typischerweise von 'Debiangegnern' genannt werden (abgesehen von den langen Releasezyklen vielleicht).
Tschüss, Torsten
Am So, den 09.05.2004 schrieb Torsten Werner um 23:39:
ich gebe zu, der Satz mit 'typisch' ist etwas zu sehr verallgemeinert. Im Gegensatz zu manchen Distributionsverfechtern sehe ich aber auch bei Debian ganz klare Probleme, nur sind es nicht die, die typischerweise von 'Debiangegnern' genannt werden (abgesehen von den langen Releasezyklen vielleicht).
Puuhhh, und ich dachte Du hättest Torsten entführt oder schlimme Experimente mit ihm angestellt... ;-)
So Zeit fürs Bettchen, Eric
Am So, den 09.05.2004 schrieb Marek Werstak um 23:28:
Sorry, aber ohne exakte Benchmarks halte ich diese Aussage für völligen Quatsch. Aber sie passt meiner Erfahrung nach sehr gut zum typischen Argumentationsverhalten von gentoo-Fans.
[...]
Aber daran wird immer Linux scheitern. Wir sind zu zerstritten und manchmal zu sehr von unserer Distri eingenommen, um irgendwann die Leute von furchtbaren monopolistischen Betriebssystemen abzubringen ...
So wird das nie was. Immer diese Teufelskreise.
Da kannst Du recht haben. Besonders schön ist dieses "passt ... zum typischen Argumentationsverhalten von gentoo-Fans". Sehr kontruktiv. Torsten, das kannst Du definitiv besser. Das wird langsam echt albern...
Eric
On Sun, May 09, 2004 at 10:52:12PM +0200, Torsten Werner wrote:
Stefan Seyfried schrieb:
runtime-cpudetection ist lame. Zumindest wenn du auf performance wert legst.
Sorry, aber ohne exakte Benchmarks halte ich diese Aussage für völligen Quatsch. Aber sie passt meiner Erfahrung nach sehr gut zum typischen Argumentationsverhalten von gentoo-Fans.
Sage das Michael Niedermayer, der den Assemblercode für die libavcodec dekoder handoptimiert hat. Und ja, die Entwickler haben das benchmarked, sonst hätten sie sich die Arbeit nicht gemacht.
Und nein, ich bin kein gentoo-Fan, ich finde das zwar geeky, aber ansonsten: gesehen, gelacht, gelöscht :-)
On Sun, 9 May 2004 19:51:16 +0200 Stefan Seyfried seife@gmane0305.slipkontur.de wrote:
On Sun, May 09, 2004 at 05:47:36PM +0200, Torsten Werner wrote:
mplayer-i386 ist ein Paket, dass zur Laufzeit die zum Prozessor passende Optimierung wählt. Ergo: neu übersetzen ist völlig unnötig.
runtime-cpudetection ist lame. Zumindest wenn du auf performance wert legst.
Kannst du das bitte auch mal begründen?
Gruß Matthias
On Sun, May 09, 2004 at 11:34:19PM +0200, Matthias Petermann wrote:
On Sun, 9 May 2004 19:51:16 +0200 Stefan Seyfried seife@gmane0305.slipkontur.de wrote:
runtime-cpudetection ist lame. Zumindest wenn du auf performance wert legst.
Kannst du das bitte auch mal begründen?
Ohne Runtime-CPUdetection kann ich DVDs auf einem K6 mit 300 MHz abspielen. Mit " nicht.
Thomas Jacob jacob@internet24.de at 2004-05-09 1732 +0200:
On Sun, May 09, 2004 at 03:59:42PM +0200, Jonas Witt wrote:
Ne Windows-Installation ist auch schneller als ne Gentoo-Installation. Dass Kompilieren länger dauert als kopieren, ist ja klar. Die Frage ist: warum hast du ein Problem damit, 12 Stunden zu installieren oder mal ne halbe Stunde auf nen Apache zu warten?
Hehe.. Meinst du die Frage ernst? Gut für mein Spielsystem zuhause macht das nichts, aber wenn ich schnell mal nen Server brauche, ist das ne lange Zeit.
Wenn ein Server länger laufen soll, weiß man das doch in der Regel 24h vorher, oder? Für den Rest kann man auch ne Live-CD nehmen. Auch eine, die auf Debian basiert. :)
- Gentoo Ebuilds sind oft weniger ausgereift/robust als
./debian/*. Beispiel, bei iptables fehlen die meisten Interface-Bibliotheken/Headers.
Hm, bei meinen iptables ist alles dran, was zum Funktionieren benötigt wird.
Die Kommandozeilentools schon, aber z.B. nicht libiptc, was man maschinelle Manipulieren braucht, zumindest für spezielle Sachen. Kann man natürlich durch ein Ebuild-Patch ändern, ok ;)
Eben, sollte man sogar ändern. Auch Debian wurde nicht stabil und mit ner großen Nutzergemeinde geboren, oder?
Viel interessanter sind eigentlich die USE-Flags. Oder hat Debian für jede Feature-Kombination ein Binary? Wie bekommst du mplayer mit MMX-, SSE- und SSE2-Unterstützung?
Ich kompiliere selbst. Dieses eine Programm. Aber sicher, in so einem Fall hat Gentoo Vorteile.
Dieses eine Programm? Was machst du, wenn du dein Sylpheed mit XFace-Unterstützung willst (xface), aber ohne LDAP (-ldap)? Oder vielleicht mit AV-Unterstützung (clamav)? Wenn du für jede Software die Doku willst(doc)? Wenn du nmap ohne X-Frontend möchtest (-X)? Oder vielleicht gcc ohne gcj (-gcj)? Oder Mozilla ohne Mailcient (moznomail)? Wie bestimmst du, welche Widgets dein Emacs nutzt?
Kompilierst du das alles selber? Dauert das nicht viel zu lange? ;) SCNR
- Die Gentoo-Kernel-Sources sind vollgepackt mit allerlei Patches
und deren Bugs (jüngstes Beispiel: ext3-Kernel-Memory-Leaks).
Gentoo bietet mir 42 Kernel-Compilations zu Auswahl an. Du musst nicht die nehmen, die dir nicht gefällt.
Wenn ich ext3 brauche, kann ich es nicht ausschalten.
Das ist erstmal richtig, aber was hat das mit dem (sowieso OT-)Thema zu tun?
peace, Jonas
On Sun, May 09, 2004 at 06:01:09PM +0200, Jonas Witt wrote:
Wenn ein Server länger laufen soll, weiß man das doch in der Regel 24h vorher, oder?
In der Regel. Leider nicht immer.
Eben, sollte man sogar ändern. Auch Debian wurde nicht stabil und mit ner großen Nutzergemeinde geboren, oder?
Sicher. Gentoo ist relativ neu, und daher gibt es noch viel zum Feilen. Ich zeige einfach mal ein paar Stellen auf. Völlig subjektiv, natürlich ;)
Dieses eine Programm? Was machst du, wenn du dein Sylpheed mit XFace-Unterstützung willst (xface), aber ohne LDAP (-ldap)? Oder vielleicht mit AV-Unterstützung (clamav)? Wenn du für jede Software die Doku willst(doc)? Wenn du nmap ohne X-Frontend möchtest (-X)? Oder vielleicht gcc ohne gcj (-gcj)? Oder Mozilla ohne Mailcient (moznomail)? Wie bestimmst du, welche Widgets dein Emacs nutzt?
50% der Fälle: habe ich überhaupt das Problem nicht, da es um Compile-Zeiteinsparung geht, die man nun mal bei binär-Pakete installieren gar nicht sparen kann.
40% der Fälle: installiere ich mir die entsprechende Subvariante.
10% der Fälle: muss ich selber was compilieren. Also Download packet, ./configure --meine-spezi-optionen, make, make install vs. emerge packet.
Kompilierst du das alles selber? Dauert das nicht viel zu lange? ;) SCNR
Ist das nicht genau der Punkt?
Wenn ich ext3 brauche, kann ich es nicht ausschalten.
Das ist erstmal richtig, aber was hat das mit dem (sowieso OT-)Thema zu tun?
Dieses: Gentoo's default Kern ist selbst bei Standardoptionen nicht stable. Und ich kann mich NICHT zwischen Standard-Kernel ext3 und Gentoo-Patch ext3 entscheiden, ich kann nur 1) selber Patchen 2) der normalen Linux-Kern nehmen ;)
peace,
Na aber klar doch ;)
Jonas Witt schrieb:
Dieses eine Programm? Was machst du, wenn du dein Sylpheed mit XFace-Unterstützung willst (xface), aber ohne LDAP (-ldap)? Oder vielleicht mit AV-Unterstützung (clamav)?
Ich installiere sylpheed-claws-clamav.
Wenn du für jede Software die Doku willst(doc)?
Ich installiere die jeweiligen *-doc Pakete.
Wenn du nmap ohne X-Frontend möchtest (-X)?
nmap hat kein X-Frontend, für das X-Frontend installiere ich nmapfe.
Oder vielleicht gcc ohne gcj (-gcj)?
Das sind alles Einzelpakete die ich einzeln installieren oder weglassen kann.
Oder Mozilla ohne Mailcient (moznomail)?
Dasselbe hier.
Wie bestimmst du, welche Widgets dein Emacs nutzt?
s. o.
Wenn du genauer hinguckst, ist ein fein abgestimmtes Debian wesentlich weniger bloated als ein gentoo, schon deshalb, weil man kein unnötiges toolchain installiert (Header-Files, Compiler, statische Bibliotheken, Entwickler-Dokumentation etc.)
Torsten
Am So, den 09.05.2004 schrieb Torsten Werner um 19:01:
Wenn du genauer hinguckst, ist ein fein abgestimmtes Debian wesentlich weniger bloated als ein gentoo, schon deshalb, weil man kein unnötiges toolchain installiert (Header-Files, Compiler, statische Bibliotheken, Entwickler-Dokumentation etc.)
Jein. U.u. kannst Du mit USE die Features viel feingranularer abstimmen als mit Paketx-FeatureY. Wirklich ein Nachteil ist, daß es dadurch natürlich auch wesentlich mehr Varianten von einzelnen Paketen gibt und eine Supportanfrage dann nicht mehr lautet "ich habe Probleme mit PaketX", sondern "ich habe Probleme mit PaketX (USE="y -z a b -c"). Diese spezielle USE-Situation ist dann u.U. nicht so einfach nachzuvollziehen, wie bei "PaketX-FeatureY". Aber Gentoo ist auch nicht für Memmen ;-) Ja, das habe ich früher über Debian gesagt. ;-))
Eric
Am So, den 09.05.2004 schrieb Thomas Jacob um 17:32:
Dass Kompilieren länger dauert als kopieren, ist ja klar. Die Frage ist: warum hast du ein Problem damit, 12 Stunden zu installieren oder mal ne halbe Stunde auf nen Apache zu warten?
Hehe.. Meinst du die Frage ernst? Gut für mein Spielsystem zuhause macht das nichts, aber wenn ich schnell mal nen Server brauche, ist das ne lange Zeit.
Jetzt interessiert mich das ja doch mal: Was machst Du, daß Du schnell mal nen Server brauchst? Ich kann es mir beim besten Willen nicht vorstellen. In welcher Situation kann das so dringend sein, daß man das nicht über Nacht durchkompilieren lassen kann. Will man einen Server hinstellen, der nicht erst noch ein ganze Weile getestet wurde? Dauert das nicht viel länger? Normalerweise dauert die Dokumentation eines Servers länger als das bisschen Quellen durch den Kompilierer zu jagen.
Viel interessanter sind eigentlich die USE-Flags. Oder hat Debian für jede Feature-Kombination ein Binary? Wie bekommst du mplayer mit MMX-, SSE- und SSE2-Unterstützung?
Ich kompiliere selbst. Dieses eine Programm. Aber sicher, in so einem Fall hat Gentoo Vorteile.
Das Nette ist ja gerade, daß ich das global festlegen kann. D.h. ich kann von vornherein festlegen daß ich z.B. Support für ein bestimmtes Feature unbedingt will oder eben gerade nicht (bei allen Paketen). z.B.: "cups java -qt -svga". Ich finde das genial.
Eric
On Sun, May 09, 2004 at 07:36:32PM +0200, Eric Schaefer wrote:
Am So, den 09.05.2004 schrieb Thomas Jacob um 17:32:
Dass Kompilieren länger dauert als kopieren, ist ja klar. Die Frage ist: warum hast du ein Problem damit, 12 Stunden zu installieren oder mal ne halbe Stunde auf nen Apache zu warten?
Hehe.. Meinst du die Frage ernst? Gut für mein Spielsystem zuhause macht das nichts, aber wenn ich schnell mal nen Server brauche, ist das ne lange Zeit.
Jetzt interessiert mich das ja doch mal: Was machst Du, daß Du schnell mal nen Server brauchst? Ich kann es mir beim besten Willen nicht vorstellen. In welcher Situation kann das so dringend sein, daß man das nicht über Nacht durchkompilieren lassen kann. Will man einen Server hinstellen, der nicht erst noch ein ganze Weile getestet wurde? Dauert das nicht viel länger? Normalerweise dauert die Dokumentation eines Servers länger als das bisschen Quellen durch den Kompilierer zu jagen.
Kommt darauf halt auf die Industrie, gel ;) Wenn du 3 Server hast, die einen großen Wert darstellen, ist das wohl seltener ein Problem als bei mehren 100 Servern, mit geringem "Wert" pro Server, in einem hart umkämpften Markt.
Das Nette ist ja gerade, daß ich das global festlegen kann. D.h. ich kann von vornherein festlegen daß ich z.B. Support für ein bestimmtes Feature unbedingt will oder eben gerade nicht (bei allen Paketen). z.B.: "cups java -qt -svga". Ich finde das genial.
Das sind die zwei Features, die ich momentan als "cool" bei Gentoo ausmachen kann. USE flags und parallele Versionen des gleichen Pakets. Kein Widerspruch.
Am So, den 09.05.2004 schrieb Thomas Jacob um 20:29:
Hehe.. Meinst du die Frage ernst? Gut für mein Spielsystem zuhause macht das nichts, aber wenn ich schnell mal nen Server brauche, ist das ne lange Zeit.
Jetzt interessiert mich das ja doch mal: Was machst Du, daß Du schnell mal nen Server brauchst? Ich kann es mir beim besten Willen nicht vorstellen. In welcher Situation kann das so dringend sein, daß man das nicht über Nacht durchkompilieren lassen kann. Will man einen Server hinstellen, der nicht erst noch ein ganze Weile getestet wurde? Dauert das nicht viel länger? Normalerweise dauert die Dokumentation eines Servers länger als das bisschen Quellen durch den Kompilierer zu jagen.
Kommt darauf halt auf die Industrie, gel ;) Wenn du 3 Server hast, die einen großen Wert darstellen, ist das wohl seltener ein Problem als bei mehren 100 Servern, mit geringem "Wert" pro Server, in einem hart umkämpften Markt.
Nun ja, daraus und aus dem $From schließe ich, es geht um ein "Rechenzentrum". Besagte Server von geringem Wert sind doch eigentlich immer gleich, oder nicht. Da bau ich mir doch einmal ein Grundsystem, welches ich dann immer nur noch an die Kundenbedürfnisse anpassen muß. Und wenn nicht, will man wirklich Clients auf ad hoc installierte Server, ohne ausreichende Tests und Dokumentation loslassen?
Abgesehen davon sollte in Umgebungen die mehrere 100 Server zu verwalten haben genügend Infrastruktur da sein um mittels distcc die Turnaroundzeiten deutlich zu drücken.
Langsam wird es jetzt aber OffTopic, denn das hat weder mit Gentoo, noch mit Debian was zu tun.
Eric
On 09.05.04 Jonas Witt (wittj@gmx.net) wrote:
Thomas Jacob jacob@internet24.de at 2004-05-09 1408 +0200:
Moin,
Du kannst ja mal versuchen, diese zu widerlegen, ich sammel sie noch mal zusammen.
- Gentoo-Installationen und Upgrades dauern um Größenordnugen länger
als bei Bin-Paket-Orientierten Distros.
Ne Windows-Installation ist auch schneller als ne Gentoo-Installation. Dass Kompilieren länger dauert als kopieren, ist ja klar. Die Frage ist: warum hast du ein Problem damit, 12 Stunden zu installieren oder mal ne halbe Stunde auf nen Apache zu warten?
Wenn ich nur einen Rechner habe, den neu aufsetzen will und davon abhängig bin, daß der tut, würde es mich schon stören wenn das 12h dauert. Ja, ich weiß -- Gentoo hat wohl mehrere Ausbaustufen und ich muß nicht alles selber backen wenn ich nicht will.
Viel interessanter sind eigentlich die USE-Flags. Oder hat Debian für jede Feature-Kombination ein Binary? Wie bekommst du mplayer mit MMX-, SSE- und SSE2-Unterstützung?
Debian hat gar keinen MPlayer. Und ja, so ein zwei Stücken Software selber backen (Backports) ist ja kein Problem, aber doch nicht die ganze Dist.
- Die Gentoo-Kernel-Sources sind vollgepackt mit allerlei
Patches und deren Bugs (jüngstes Beispiel: ext3-Kernel-Memory-Leaks). Aber
Gentoo bietet mir 42 Kernel-Compilations zu Auswahl an. Du musst nicht die nehmen, die dir nicht gefällt.
... sondern alle 42 ausprobieren? Nicht Dein Ernst, oder?
H.
Am So, den 09.05.2004 schrieb Hilmar Preusse um 17:55:
Ne Windows-Installation ist auch schneller als ne Gentoo-Installation. Dass Kompilieren länger dauert als kopieren, ist ja klar. Die Frage ist: warum hast du ein Problem damit, 12 Stunden zu installieren oder mal ne halbe Stunde auf nen Apache zu warten?
Wenn ich nur einen Rechner habe, den neu aufsetzen will und davon abhängig bin, daß der tut, würde es mich schon stören wenn das 12h dauert. Ja, ich weiß -- Gentoo hat wohl mehrere Ausbaustufen und ich muß nicht alles selber backen wenn ich nicht will.
Genau, wenn es schnell gehen muß, holst Du Dir eben die Binärpakete und kannst dann aber trotzdem alles später "nachkompilieren", wenn Du willst.
Viel interessanter sind eigentlich die USE-Flags. Oder hat Debian für jede Feature-Kombination ein Binary? Wie bekommst du mplayer mit MMX-, SSE- und SSE2-Unterstützung?
Debian hat gar keinen MPlayer. Und ja, so ein zwei Stücken Software selber backen (Backports) ist ja kein Problem, aber doch nicht die ganze Dist.
Siehe oben. Ich brauchte schnell ein funktionierendes System und habe deshalb (als absoluter Gentoo-Neuling) das Basissystem (stage3) aus den Quellen installiert (hat nicht allzu lang gedauert) und den Rest (X, Gnome, Mozilla, Evolution, etc) habe ich mir erst mal als Binärpakete besorgt. Inzwischen habe ich alles nachkompiliert.
Gentoo bietet mir 42 Kernel-Compilations zu Auswahl an. Du musst nicht die nehmen, die dir nicht gefällt.
... sondern alle 42 ausprobieren? Nicht Dein Ernst, oder?
Wieso? Wähle Version und [vanilla|gentoo|dunno], merge, konfiguriere, kompiliere, installiere, hole neues Bierchen.
Eric
On 09.05.04 Eric Schaefer (eric@gixgax.de) wrote:
Am So, den 09.05.2004 schrieb Hilmar Preusse um 17:55:
Moin,
Gentoo bietet mir 42 Kernel-Compilations zu Auswahl an. Du musst nicht die nehmen, die dir nicht gefällt.
... sondern alle 42 ausprobieren? Nicht Dein Ernst, oder?
Wieso? Wähle Version und [vanilla|gentoo|dunno], merge, konfiguriere, kompiliere, installiere, hole neues Bierchen.
Ich hole nochmal eine Quotingebene zurück:
4) Die Gentoo-Kernel-Sources sind vollgepackt mit allerlei Patches und deren Bugs (jüngstes Beispiel: ext3-Kernel-Memory-Leaks). Aber gut, wenn man einfach Standard-Kernels backt, läuft auch ein Gentoo-Server unter Last stabil ;)
Will ich erst alles 42 Kernels ausprobieren, bis ich den finde der funktioniert?
H.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Guten Morgen,
Will ich erst alles 42 Kernels ausprobieren, bis ich den finde der funktioniert?
Nein, Du liest die Beschreibung der Kernel-Version. Z.B. Was leistet denn der Hardened gegenüber dem Gaming-Source? Dann schaust Du Dir Deine maschine an und legst fest, was sie denn machen soll.
Von mir aus: Das wird mein Desktop-Rechner für die Uni mit Openoffice, Tex, KDE und ein XML oder HTML Editor. Hmmmm .. Soll also ein bisschen performant sein und relativ stable. Hier wäre meine Entscheidung gentoo-sources. Fertig.
Liebe Grüsse
Marek
On 10.05.04 Marek Werstak (marexmail@web.de) wrote:
Guten Morgen,
Will ich erst alles 42 Kernels ausprobieren, bis ich den finde der funktioniert?
Nein, Du liest die Beschreibung der Kernel-Version. Z.B. Was leistet denn der Hardened gegenüber dem Gaming-Source? Dann schaust Du Dir Deine maschine an und legst fest, was sie denn machen soll.
Ich wollte eher darauf hinaus, daß wohl Kernels dabei sind, die kaputtgepatcht wurden. Was passiert, wenn mir der Einsatzzweck, genau so einen vorschreibt?
H.
Am Mo, den 10.05.2004 schrieb Hilmar Preusse um 14:59:
Nein, Du liest die Beschreibung der Kernel-Version. Z.B. Was leistet denn der Hardened gegenüber dem Gaming-Source? Dann schaust Du Dir Deine maschine an und legst fest, was sie denn machen soll.
Ich wollte eher darauf hinaus, daß wohl Kernels dabei sind, die kaputtgepatcht wurden. Was passiert, wenn mir der Einsatzzweck, genau so einen vorschreibt?
Du machst es Dir zu kompliziert. emerge vanilla-sources und fertig. Dann hast Du das, was Du unter Debian auch hast. Wenn Du unbedingt irgendwelche hardend- oder gaming-sourcen willst, dann solltest Du sowieso erstmal lesen oder eben experimentieren. Mit vanilla bist Du aber immer auf der sicheren Seite.
Eric
On 10.05.04 Eric Schaefer (eric@gixgax.de) wrote:
Am Mo, den 10.05.2004 schrieb Hilmar Preusse um 14:59:
Moin,
Ich wollte eher darauf hinaus, daß wohl Kernels dabei sind, die kaputtgepatcht wurden. Was passiert, wenn mir der Einsatzzweck, genau so einen vorschreibt?
Du machst es Dir zu kompliziert. emerge vanilla-sources und fertig.
Wenn das geht, erkläre ich diesen Teilthread ab sofort für geschlossen.
H.
Hilmar Preusse wrote:
Will ich erst alles 42 Kernels ausprobieren, bis ich den finde der funktioniert?
fab@adeon /usr/portage/sys-kernel $ ls aa-sources hppa-headers ppc-development-sources alpha-sources hppa-sources ppc-sources ck-sources ia64-sources ppc-sources-benh compaq-sources ksymoops ppc-sources-dev config-kernel linux-headers selinux-sources development-sources mips-headers sparc-sources gaming-sources mips-prepatch-sources uclinux-sources genkernel mips-sources usermode-sources gentoo-dev-sources mm-sources vanilla-sources gentoo-sources openmosix-sources vserver-sources grsec-sources pac-sources win4lin-sources gs-sources pegasos-sources wolk-sources hardened-dev-sources planet-ccrma-sources xfs-sources hardened-sources ppc64-headers hppa-dev-sources ppc64-sources
(43 Kernel-Pakete)
Für einen Rechner kommen nur ein paar von denen in Frage, es gibt verschiedene Pakete für verschiedene Architekturen, weil auch der Patch-Stand unterschiedlich ist.
Wenn du z.B. keinen ck-kernel willst wirst du das wissen und ihn gar nicht erst ausprobieren, sondern beim vanilla bleiben, den du auch unter Debian per Standart haben dürftest.
mfg, Fabian
Hilmar Preusse hille42@web.de at 2004-05-09 1755 +0200:
Wenn ich nur einen Rechner habe, den neu aufsetzen will und davon abhängig bin, daß der tut, würde es mich schon stören wenn das 12h dauert.
Du kannst ja auch dein neues Gentoo in nem chroot backen.
Gentoo bietet mir 42 Kernel-Compilations zu Auswahl an. Du musst nicht die nehmen, die dir nicht gefällt.
... sondern alle 42 ausprobieren? Nicht Dein Ernst, oder?
Nein, natürlich nicht. Ich meinte nur, dass man ja schließlich nicht auf die gentoo-(dev-)sources festgelegt ist.
MfG, Jonas
On 09.05.04 Jonas Witt (wittj@gmx.net) wrote:
Hilmar Preusse hille42@web.de at 2004-05-09 1755 +0200:
Moin,
Wenn ich nur einen Rechner habe, den neu aufsetzen will und davon abhängig bin, daß der tut, würde es mich schon stören wenn das 12h dauert.
Du kannst ja auch dein neues Gentoo in nem chroot backen.
Wenn ich mal wieder zuviel Zeit habe probier ich es mal aus. Ich fürchte aber, das passiert in diesem Leben nicht mehr.
Gentoo bietet mir 42 Kernel-Compilations zu Auswahl an. Du musst nicht die nehmen, die dir nicht gefällt.
... sondern alle 42 ausprobieren? Nicht Dein Ernst, oder?
Nein, natürlich nicht. Ich meinte nur, dass man ja schließlich nicht auf die gentoo-(dev-)sources festgelegt ist.
Dann kann ich auch bei Debian stable bleiben und mir die Vanillas von kernel.org saugen.
H.
Hilmar Preusse hille42@web.de at 2004-05-10 0840 +0200:
On 09.05.04 Jonas Witt (wittj@gmx.net) wrote:
Du kannst ja auch dein neues Gentoo in nem chroot backen.
Wenn ich mal wieder zuviel Zeit habe probier ich es mal aus. Ich fürchte aber, das passiert in diesem Leben nicht mehr.
Was ist daran zeitintensiver als ne normale Gentoo-Installation? Oder meintest du im Vergleich zu ner binären?
MfG, Jonas
On 10.05.04 Jonas Witt (wittj@gmx.net) wrote:
Hilmar Preusse hille42@web.de at 2004-05-10 0840 +0200:
On 09.05.04 Jonas Witt (wittj@gmx.net) wrote:
Du kannst ja auch dein neues Gentoo in nem chroot backen.
Wenn ich mal wieder zuviel Zeit habe probier ich es mal aus. Ich fürchte aber, das passiert in diesem Leben nicht mehr.
Was ist daran zeitintensiver als ne normale Gentoo-Installation? Oder meintest du im Vergleich zu ner binären?
Letzteres.
H.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo,
warum gibt es immer Krieg? Jede Distribution hat seine Vor- und Nachteile. Es sollte nach Sinn entschieden werden.
Das ist doch das Schöne an freier Software. Die freie Wahl. Sonst kann ich gleich zu einem grossen Hersteller wechseln und alles über mich ergehen lassen.
Meines Erachtens sollte mehr an einer gemeinsamen Vereinfachung für User gearbeitet werden. Dem User ist es egal, was drunter ist. Hauptsache ... die Aufgaben können schnell und zuverlässig erledigt werden!
Mit diesen Kleinkriegen wird das nie was.
Übrigens, ich benutze Gentoo, Debian, Suse, Fedora --> je nach Einsatzzweck. Monopolismus ist sinnlos, es verschränkt die Sicht und stoppt eigene kreative Entfaltungen. Mit Niedermachen kommen wir in keinem Feld weiter.
Open Source = Open Mind!
Grüsse
Marek
Am So, den 09.05.2004 schrieb Marek Werstak um 21:28:
warum gibt es immer Krieg? Jede Distribution hat seine Vor- und Nachteile. Es sollte nach Sinn entschieden werden.
Ich wäre z.B. unter meinem Stein geblieben, wären nicht hanebüchene Argumente gefallen, die ich so nicht stehen lassen wollte (es könnten ja Kinder mitlesen). Wären richtige contra-Argumente gegen Gentoo gefallen, hätte ich meine Klappe gehalten.
Übrigens, ich benutze Gentoo, Debian, Suse, Fedora --> je nach Einsatzzweck. Monopolismus ist sinnlos, es verschränkt die Sicht und stoppt eigene kreative Entfaltungen. Mit Niedermachen kommen wir in keinem Feld weiter.
Ich hatte auch schon so einiges auf meinen Hartscheiben: NetBSD, FreeBSD, Solaris, Suse (so um 95), eine sehr frühe Linux-Distribution (ca. 1994), deren Namen ich vergessen habe (drei Buchstaben), RedHat, Corel, Debian, Gentoo und last but not least BeOS. Übrig sind Debian (Heimserver, Testrechner auf Arbeit, Sun #1), Gentoo ("Workstation") und Solaris (Sun #2, bald auch wieder Debian). Dazu kommen diverse Server auf Suse 7.2 Basis (war nicht meine Entscheidung ;-).
Letztlich sind diese Kriege wirklich sinnfrei. Ich würde zwar selbst keine Suse benutzen, einem Neuling aber meistens selbige empfehlen.
Eric
On Sun, May 09, 2004 at 03:59:42PM +0200, Jonas Witt wrote:
Ne Windows-Installation ist auch schneller als ne Gentoo-Installation. Dass Kompilieren länger dauert als kopieren, ist ja klar. Die Frage ist: warum hast du ein Problem damit, 12 Stunden zu installieren oder mal ne halbe Stunde auf nen Apache zu warten?
Weil mir das keiner bezahlen wird?
Viel interessanter sind eigentlich die USE-Flags. Oder hat Debian für jede Feature-Kombination ein Binary? Wie bekommst du mplayer mit MMX-, SSE- und SSE2-Unterstützung?
also noch bei _jeder_ mir bekannten Distribution baut man MPlayer ganz einfach:
cvs update -dP; ./configure; make; make install
und das mindestens 2 mal täglich ;-)
Am So, den 09.05.2004 schrieb Stefan Seyfried um 19:49:
Ne Windows-Installation ist auch schneller als ne Gentoo-Installation. Dass Kompilieren länger dauert als kopieren, ist ja klar. Die Frage ist: warum hast du ein Problem damit, 12 Stunden zu installieren oder mal ne halbe Stunde auf nen Apache zu warten?
Weil mir das keiner bezahlen wird?
Sitzt Du die 12 Stunden da und schaust dem Compiler zu? Das würde ich Dir auch nicht bezahlen.
Eric
On Sun, May 09, 2004 at 08:10:02PM +0200, Eric Schaefer wrote:
Sitzt Du die 12 Stunden da und schaust dem Compiler zu? Das würde ich Dir auch nicht bezahlen.
Nein, aber früher bin ich durchaus zu Kunden gefahren / geflogen und habe dort Server installiert. Und da hätte ich 12 Stunden warten müssen.
Am So, den 09.05.2004 schrieb Stefan Seyfried um 20:14:
Sitzt Du die 12 Stunden da und schaust dem Compiler zu? Das würde ich Dir auch nicht bezahlen.
Nein, aber früher bin ich durchaus zu Kunden gefahren / geflogen und habe dort Server installiert. Und da hätte ich 12 Stunden warten müssen.
Oder Du hättest fertige Binärpakete mitgebracht, die Du die Nacht vorher speziell für den Zielhost erzeugt hättest. Ansonsten: spezielle Baustelle, spezielle Werkzeuge.
Eric
Thomas Jacob wrote:
- Gentoo-Installationen und Upgrades dauern um Größenordnugen länger
als bei Bin-Paket-Orientierten Distros.
Also der Vorgang des Updatens dauert sicher länger, aber die Zeit, die zwischen dem Herauskommen einer neuen Version eines Programmes und der Verfügbarkeit jener auf einem Gentoo-System vergeht, ist definitiv kürzer als bei Debian. Man muss nicht an penetranter Versionitis (neueste Version = Selbstzweck) leiden, um aktuelle Software zu schätzen.
- Gentoo Ebuilds sind oft weniger ausgereift/robust als
./debian/*. Beispiel, bei iptables fehlen die meisten Interface-Bibliotheken/Headers.
Bei mir gerade nicht, aber sowas kommt vor. Dann ist eben ein bisschen Suchen oder Handarbeit angesagt. Anschließend meldest du den Bug und er wird behoben.
- Die Möglichkeit, alles mit -O3 --mcpu=MeineCPU --march=MeineCPU zu
builden wird von vielen Gentoo-Adepten als erster Vorteil verbreitet.
Wo ist denn da die Gentoo-Kritik? Ebenso toll finde ich die Anpassbarkeit in puncto Funktionalität mittels USE-Flags. Durch Prelink kriegt man sogar schnell(er) startende KDE-Apps.
- Die Gentoo-Kernel-Sources sind vollgepackt mit allerlei Patches
und deren Bugs (jüngstes Beispiel: ext3-Kernel-Memory-Leaks). Aber gut, wenn man einfach Standard-Kernels backt, läuft auch ein Gentoo-Server unter Last stabil ;)
Jetzt kommst du zu einem der größten Vorteile von Gentoo. Wenn ich getestete, stabile Software will, dann lass ich emerge nur die installieren. Will ich aber mal was ausprobieren, dann lass ich ihn eben explizit experimentelle Pakete installieren, und das Gesamtsystem funktioniert trotzdem noch. Ohne irgendwelche komplizierten Mix-Probleme wie bei der Distri mit dem "D".
Am Ende hat jeder die Wahl, welche Distri er nimmt. Jede hat ihr Vor- und Nachteile, und es wird nie die Distri mit 99% Marktanteil geben, die für so ziemlich jeden Anwender in jeder Situation für jede Hardware das Optimimum ist. Und dass ist gut so, werte ... Hier herrscht gesunder Wettbewerb.
mfg, Fabian
On Sun, May 09, 2004 at 05:18:28PM +0200, Fabian Hänsel wrote:
Thomas Jacob wrote:
- Gentoo-Installationen und Upgrades dauern um Größenordnugen länger
als bei Bin-Paket-Orientierten Distros.
Also der Vorgang des Updatens dauert sicher länger, aber die Zeit, die zwischen dem Herauskommen einer neuen Version eines Programmes und der Verfügbarkeit jener auf einem Gentoo-System vergeht, ist definitiv kürzer als bei Debian.
OK, aber beim Vergleich Debian unstable/Gentoo geht es hier um wenige Tage/Wochen. Debian stable hat steinalte Software, keine Frage.
- Gentoo Ebuilds sind oft weniger ausgereift/robust als
./debian/*. Beispiel, bei iptables fehlen die meisten Interface-Bibliotheken/Headers.
Bei mir gerade nicht, aber sowas kommt vor. Dann ist eben ein bisschen Suchen oder Handarbeit angesagt. Anschließend meldest du den Bug und er wird behoben.
Ja klar, reagiert im Falle von iptables zwar keiner, aber ich werde es weiter versuchen ;)
- Die Möglichkeit, alles mit -O3 --mcpu=MeineCPU --march=MeineCPU zu
builden wird von vielen Gentoo-Adepten als erster Vorteil verbreitet.
Wo ist denn da die Gentoo-Kritik? Ebenso toll finde ich die Anpassbarkeit in puncto Funktionalität mittels USE-Flags. Durch Prelink kriegt man sogar schnell(er) startende KDE-Apps.
USE-Flags sind nett, das stimmt.
- Die Gentoo-Kernel-Sources sind vollgepackt mit allerlei Patches
und deren Bugs (jüngstes Beispiel: ext3-Kernel-Memory-Leaks). Aber gut, wenn man einfach Standard-Kernels backt, läuft auch ein Gentoo-Server unter Last stabil ;)
Jetzt kommst du zu einem der größten Vorteile von Gentoo. Wenn ich getestete, stabile Software will, dann lass ich emerge nur die installieren.
Ich sprach vom Standard-Kernel, ich glaube der gilt wohl als stable,
Will ich aber mal was ausprobieren, dann lass ich ihn eben explizit experimentelle Pakete installieren, und das Gesamtsystem funktioniert trotzdem noch. Ohne irgendwelche komplizierten Mix-Probleme wie bei der Distri mit dem "D".
Weiterer Vorteil von Gentoo.
Am Ende hat jeder die Wahl, welche Distri er nimmt. Jede hat ihr Vor- und Nachteile, und es wird nie die Distri mit 99% Marktanteil geben, die für so ziemlich jeden Anwender in jeder Situation für jede Hardware das Optimimum ist. Und dass ist gut so, werte ... Hier herrscht gesunder Wettbewerb.
Hab ich auch kein Problem mit. Nur sollte der Vergleich irgendwie mit rationalen Argumenten geführt werden. Und das Fazit wäre doch nach deinen und anderen Aussagen: Gentoo ist ein tolles Privat-/Entwicklungs und Bastelsystem. Und da kann ich nur sagen: stimmt ;)
On 09.05.04 Fabian Hänsel (fabtagon@gmx.de) wrote:
Moin,
Man muss nicht an penetranter Versionitis (neueste Version = Selbstzweck) leiden, um aktuelle Software zu schätzen.
Schätzen ja. Nur wie hoch? Ich könnte mir auch einmal im Monat eine Debian testing auf CD kommen lassen, die einwerfen, apt-get... eintippen und hoffen, daß das einigermaßen stable war. Noch reicht mir stable.
Bei mir gerade nicht, aber sowas kommt vor. Dann ist eben ein bisschen Suchen oder Handarbeit angesagt. Anschließend meldest du den Bug und er wird behoben.
Die Gentoo-Entwickler haben wohl noch genug Enthusiasmus, als das daß funktioniert. Hat die Dist inzwischen die Größe/Komplexität von Debian erreicht oder liegt das wirklich nur an D's Bürokratie?
H.
Hilmar Preusse wrote:
On 09.05.04 Fabian Hänsel (fabtagon@gmx.de) wrote:
Moin,
Man muss nicht an penetranter Versionitis (neueste Version = Selbstzweck) leiden, um aktuelle Software zu schätzen.
Schätzen ja. Nur wie hoch? Ich könnte mir auch einmal im Monat eine Debian testing auf CD kommen lassen, die einwerfen, apt-get... eintippen und hoffen, daß das einigermaßen stable war. Noch reicht mir stable.
Wenn du bis zum Ende des Monats warten willst: ja ;-) ist auch ökonomischer. Anderer Punkt: Kann man bei Debian so problemlos stable (deine "Grundausstattung" ist stable, oder?) und unstable mixen? Wie stabil ist das Gesamtsystem dann?
Bei mir gerade nicht, aber sowas kommt vor. Dann ist eben ein bisschen Suchen oder Handarbeit angesagt. Anschließend meldest du den Bug und er wird behoben.
Die Gentoo-Entwickler haben wohl noch genug Enthusiasmus, als das daß funktioniert. Hat die Dist inzwischen die Größe/Komplexität von Debian erreicht oder liegt das wirklich nur an D's Bürokratie?
Ich verstehe den gesamten Absatz leider (grammatisch) nicht so richtig, aber Gentoo hat rund 7000 Pakete.
mfg, Fabian
On 10.05.04 Fabian Hänsel (fabtagon@gmx.de) wrote:
Hilmar Preusse wrote:
Moin,
Anderer Punkt: Kann man bei Debian so problemlos stable (deine "Grundausstattung" ist stable, oder?) und unstable mixen? Wie stabil ist das Gesamtsystem dann?
Kommt drauf an, wie weit sie schon auseinander gedriftet sind. Also jetzt, so 1,75 Jahre nach dem letzten Release ist das (bis auf simple Software) nicht mehr so einfach. Es sei denn, ich bin bereit, auch ein paar grundlegende Pakete (debconf u.ä. mit hochzuziehen). Ob letzteres die Stabiltät beeinflußt weiß ich nicht, da ich das nicht getan habe.
Die Gentoo-Entwickler haben wohl noch genug Enthusiasmus, als das daß funktioniert. Hat die Dist inzwischen die Größe/Komplexität von Debian erreicht oder liegt das wirklich nur an D's Bürokratie?
Ich verstehe den gesamten Absatz leider (grammatisch) nicht so richtig, aber Gentoo hat rund 7000 Pakete.
Ich wollte die Frage stellen, warum Debian so ewig Releasezyklen hat. Vielleicht sollte ich besser groups.google.com fragen. Und nein, die Anzahl der Pakete sagt nichts über die Menge der miteglieferten Software.
H.
Am Sa, den 08.05.2004 schrieb Thomas Jacob um 19:22:
Stimmt, anstatt in Minuten funktionell ausgefeilte Debian-Pakete (z.B.) zu installieren, kann man viele CPU-Stunden mit dem Kompilieren von halbgebackenen Gentoo-Ebuilds verbrauchen, nur damit man auch ja die letzte Compileroptimierungsstufe drin hat. Macht besonders viel Spass beim Up-to-date-halten von Produktionsservern. Nicht zu vergessen die Alle-Patches+Bugs-Die-Es-Gibt Gentoo Kernel Sources.
*Prust* "Produktionsserver" und "Up-to-date-halten" in einem Satz... 1. Produktionsserver bekommen nur Security-Updates und die kompiliert man sich sowieso selbst, wenn man sicher gehen will. 2. Auf halbwegs aktueller Hardware brauchen die meisten Pakete länger für den Download, als fürs komplilieren [1] und gnome/kde/etc kompiliert man nicht gerade jeden Tag. 2a: Wer Gentoo auf einem 386 benutzt, hat es nicht verstanden. 3. Distributionsspezifische Kernel sind IMMER Scheiße. 4. Niemand will "die letzte Compileroptimierungsstufe", aber gerade bei rechenintensiver SW will man eigentlich nicht, daß diese für eine CPU optimiert ist, die es nur noch im Museum zu besichtigen gibt. Solche SW würde man also sowieso selbst kompilieren.
Eric
[1] Meine Holde meinte neulich: Wieso "kompiliert" dein "Kompeiler". Entweder "kompiliert" dein "Kompilierer" oder es "kompeilert" dein "Kompeiler". Irgendwie hat sie ja Recht... ;-)
On Sun, May 09, 2004 at 03:53:10PM +0200, Eric Schaefer wrote:
Am Sa, den 08.05.2004 schrieb Thomas Jacob um 19:22:
Stimmt, anstatt in Minuten funktionell ausgefeilte Debian-Pakete (z.B.) zu installieren, kann man viele CPU-Stunden mit dem Kompilieren von halbgebackenen Gentoo-Ebuilds verbrauchen, nur damit man auch ja die letzte Compileroptimierungsstufe drin hat. Macht besonders viel Spass beim Up-to-date-halten von Produktionsservern. Nicht zu vergessen die Alle-Patches+Bugs-Die-Es-Gibt Gentoo Kernel Sources.
*Prust* "Produktionsserver" und "Up-to-date-halten" in einem Satz...
- Produktionsserver bekommen nur Security-Updatesi
Richtig. Geht nur bei Gentoo nicht so einfach...
und die kompiliert man sich sowieso selbst, wenn man sicher gehen will.
Muss man bei Gentoo selber patchen/kompilieren, weil es gar nicht anders geht. Oder gibt es da eine Alternative? An Infos wäre ich sehr interessiert ;)
- Auf halbwegs aktueller Hardware brauchen die meisten Pakete länger
für den Download, als fürs komplilieren [1] und gnome/kde/etc kompiliert man nicht gerade jeden Tag. 2a: Wer Gentoo auf einem 386 benutzt, hat es nicht verstanden.
Auch auf nem PIV 3GHZ dauert Samba kompilieren noch ne Weile. Und wer benutzt schon für alles die allerletzte Hardware, das ist nicht wirklich ökonomisch.
- Distributionsspezifische Kernel sind IMMER Scheiße.
OK ;)
- Niemand will "die letzte Compileroptimierungsstufe", aber gerade bei
rechenintensiver SW will man eigentlich nicht, daß diese für eine CPU optimiert ist, die es nur noch im Museum zu besichtigen gibt. Solche SW würde man also sowieso selbst kompilieren.
Wenn mans braucht, na logisch. Braucht man aber meistens nicht.
Thomas Jacob wrote:
On Sun, May 09, 2004 at 03:53:10PM +0200, Eric Schaefer wrote:
Am Sa, den 08.05.2004 schrieb Thomas Jacob um 19:22:
Stimmt, anstatt in Minuten funktionell ausgefeilte Debian-Pakete (z.B.) zu installieren, kann man viele CPU-Stunden mit dem Kompilieren von halbgebackenen Gentoo-Ebuilds verbrauchen, nur damit man auch ja die letzte Compileroptimierungsstufe drin hat. Macht besonders viel Spass beim Up-to-date-halten von Produktionsservern. Nicht zu vergessen die Alle-Patches+Bugs-Die-Es-Gibt Gentoo Kernel Sources.
*Prust* "Produktionsserver" und "Up-to-date-halten" in einem Satz...
- Produktionsserver bekommen nur Security-Updatesi
Richtig. Geht nur bei Gentoo nicht so einfach...
Nimm mal glsa-check, das zeigt dir an, welche deiner installierten und nicht-installierten Pakete (natürlich getrennt) von Sicherheitproblemen betroffen sind. Anschließend "emerge <betroffenes Paket>"; glsa-check wird momentan direkt in emerge integriert, so dass es bald möglich sein wird, mit "emerge -nur_security_updates world" alles automatisiert zu fixen.
und die kompiliert man sich sowieso selbst, wenn man sicher gehen will.
Muss man bei Gentoo selber patchen/kompilieren, weil es gar nicht anders geht. Oder gibt es da eine Alternative? An Infos wäre ich sehr interessiert ;)
Es gibt auch Binary-Pakete für alles auf CD (vielleicht auch irgendwo im Netz).
- Distributionsspezifische Kernel sind IMMER Scheiße.
OK ;)
Ich kann kaum auf Unterstützung bei Problemen damit hoffen, und wenn ich die Probleme nicht selbst gelöst kriege, muss ich eben wieder auf vanilla gehen. Ich hab damit kein Problem.
- Niemand will "die letzte Compileroptimierungsstufe", aber gerade
bei rechenintensiver SW will man eigentlich nicht, daß diese für eine CPU optimiert ist, die es nur noch im Museum zu besichtigen gibt. Solche SW würde man also sowieso selbst kompilieren.
Wenn mans braucht, na logisch. Braucht man aber meistens nicht.
Schadet aber auch nicht. Bestenfalls durch die Installationsdauer, aber das sind mir die Gentoo-Features wert.
mfg, Fabian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo,
- Produktionsserver bekommen nur Security-Updatesi
Richtig. Geht nur bei Gentoo nicht so einfach...
Ruhig Blut. emerge security ist in Arbeit. Im Moment kannst Du Dir mit glsa-check behelfen.
Grüsse
Marek
On 09.05.04 Eric Schaefer (eric@gixgax.de) wrote:
Moin,
- Produktionsserver bekommen nur Security-Updates und die
kompiliert man sich sowieso selbst, wenn man sicher gehen will.
Wieso? Du hast Angst, daß Dir jemand gefakte Binaries unterschiebt?
- Distributionsspezifische Kernel sind IMMER Scheiße.
Weil sie zu groß sind? Weil sie patches drin haben?
H.
Am So, den 09.05.2004 schrieb Hilmar Preusse um 17:25:
- Produktionsserver bekommen nur Security-Updates und die
kompiliert man sich sowieso selbst, wenn man sicher gehen will.
Wieso? Du hast Angst, daß Dir jemand gefakte Binaries unterschiebt?
Nein. Wenn jetzt (in drei Minuten) jemand eine sshd-Lücke mit patch und exploit veröffentlicht, kann ich den Patch gleich reviewen (so ich das wissen dazu habe), patchen, kompilieren, fertig. Bis ein Paket dafür da ist, vergehen meist ein paar Stunden und das kann bei verschiedenen Servern schon zu spät sein. Auf meiner privaten Spielmaschine ist das allerdings relativ wurscht, aber jemand anderes fing mit "Produktionsservern" an.
- Distributionsspezifische Kernel sind IMMER Scheiße.
Weil sie zu groß sind? Weil sie patches drin haben?
Weil ich damit bisher nur Probleme hatte und noch nie einen mit dem ultimativen Killerfeature hatte, welches nicht auch in vanilla V++ enthalten gewesen wäre.
Eric
Eric Schaefer wrote:
Am So, den 09.05.2004 schrieb Hilmar Preusse um 17:25:
- Produktionsserver bekommen nur Security-Updates und die
kompiliert man sich sowieso selbst, wenn man sicher gehen will.
Wieso? Du hast Angst, daß Dir jemand gefakte Binaries unterschiebt?
Nein. Wenn jetzt (in drei Minuten) jemand eine sshd-Lücke mit patch und exploit veröffentlicht, kann ich den Patch gleich reviewen (so ich das wissen dazu habe), patchen, kompilieren, fertig. Bis ein Paket dafür da ist, vergehen meist ein paar Stunden und das kann bei verschiedenen Servern schon zu spät sein.
Bist du auch Nachts immer wach, falls jemand um 24h eine Lücke veröffentlicht? Oder zwei Lücken gleichzeitig? ;-) Also ich würde mich da gerade auf ein automatisiertes stündliches (oder auch dreiminütiges) Update aus externer (fähiger) Quelle verlassen (Updates/Patches digital signiert, versteht sich). (Nicht nur, dass ich gerne mal schlafe, ich mache gerne am Tag auch noch andere Dinge != Serveradministration. ;-)
Source-Review ist ja schön und gut, aber ich z.B. als Normalsterblicher kann die $vielen GB Source-Code, aus denen mein System besteht, nie vollständig durchsehen (bzw. Warum willst du gerade/nur die Patches durchsehen?).
Ich halte die Chance, dass ich einen Fehler im Patch übersehe für wesentlich größer, als dass das einem der Autoren der SW/dem Maintainer des Paketes passiert.
mfg, Fabian
Am So, den 09.05.2004 schrieb Fabian Hänsel um 20:15:
Wenn jetzt (in drei Minuten) jemand eine sshd-Lücke mit patch und exploit veröffentlicht, kann ich den Patch gleich reviewen (so ich das wissen dazu habe), patchen, kompilieren, fertig. Bis ein Paket dafür da ist, vergehen meist ein paar Stunden und das kann bei verschiedenen Servern schon zu spät sein.
Bist du auch Nachts immer wach, falls jemand um 24h eine Lücke veröffentlicht? Oder zwei Lücken gleichzeitig? ;-) Also ich würde mich da gerade auf ein automatisiertes stündliches (oder auch dreiminütiges) Update aus externer (fähiger) Quelle verlassen (Updates/Patches digital signiert, versteht sich).
Das "in drei Minuten" sollte eigentlich deutlich machen, das es eine Überspitzung ist.
(Nicht nur, dass ich gerne mal schlafe, ich mache gerne am Tag auch noch andere Dinge != Serveradministration. ;-)
Echt jetzt? Ganz ohne Scheiß? Du veralberst mich doch... ;-P
Source-Review ist ja schön und gut, aber ich z.B. als Normalsterblicher kann die $vielen GB Source-Code, aus denen mein System besteht, nie vollständig durchsehen (bzw. Warum willst du gerade/nur die Patches durchsehen?).
Ich habe dafür Experten auf der ganzen Welt... ;-)
Ich halte die Chance, dass ich einen Fehler im Patch übersehe für wesentlich größer, als dass das einem der Autoren der SW/dem Maintainer des Paketes passiert.
1. "so ich das Wissen dazu habe". Habe ich meistens nicht. Das "ich" war auch nicht unbedingt auf meine Person bezogen (Stichwort "Überspitzung") 2. Den Patch der SW-Autoren habe ich wahrscheinlich eher als das Paket vom Distri-Maintainer.
Eric
On Sun, May 09, 2004 at 11:43:12PM +0200, Eric Schaefer wrote:
- Den Patch der SW-Autoren habe ich wahrscheinlich eher als das Paket
vom Distri-Maintainer.
Da würde ich nicht drauf wetten. Oft bekommen die SW-Autoren den Patch von den Security-Teams der Distributoren. Und ja, hier weiss ich ausnahmsweise mal wirklich wovon ich schreibe :-)
On Mon, May 10, 2004 at 06:45:48PM +0200, Eric Schaefer wrote:
Am Mo, den 10.05.2004 schrieb Stefan Seyfried um 4:00:
Da würde ich nicht drauf wetten. Oft bekommen die SW-Autoren den Patch von den Security-Teams der Distributoren.
Das gilt dann für Distri A. Was ist mit Distri B?
du hast schonmal von vendor-sec gehört? EOD.
Am Mo, den 10.05.2004 schrieb Stefan Seyfried um 21:47:
On Mon, May 10, 2004 at 06:45:48PM +0200, Eric Schaefer wrote:
Am Mo, den 10.05.2004 schrieb Stefan Seyfried um 4:00:
Da würde ich nicht drauf wetten. Oft bekommen die SW-Autoren den Patch von den Security-Teams der Distributoren.
Das gilt dann für Distri A. Was ist mit Distri B?
du hast schonmal von vendor-sec gehört?
Nein.
EOD.
Aha.
Eric
On Tue, May 11, 2004 at 07:08:27PM +0200, Eric Schaefer wrote:
Am Mo, den 10.05.2004 schrieb Stefan Seyfried um 21:47:
du hast schonmal von vendor-sec gehört?
Nein.
EOD.
Aha.
na gut, dann halt nicht :-). Auf vendor-sec koordinieren die Betriebssystemhersteller die Security-Announcements und Fixes. Meistens entsteht ein Fix (so er nicht wirklich trivial ist) aus einer Zusammenarbeit der Verschiedenen Distributionen.
Am Di, den 11.05.2004 schrieb Stefan Seyfried um 21:30: [vedor-sec]
na gut, dann halt nicht :-). Auf vendor-sec koordinieren die Betriebssystemhersteller die Security-Announcements und Fixes. Meistens entsteht ein Fix (so er nicht wirklich trivial ist) aus einer Zusammenarbeit der Verschiedenen Distributionen.
Was es nicht alles gibt. Hab mal ein bissl gegoogelt (sp?). Klingt interessant. Allerdings soooo geheim... Wenn da mal nicht eine Sekte oder die Rosenkreutzer dahinter stehen...
heute albern, Eric
On Sun, May 09, 2004 at 07:36:30PM +0200, Eric Schaefer wrote:
Nein. Wenn jetzt (in drei Minuten) jemand eine sshd-Lücke mit patch und exploit veröffentlicht, kann ich den Patch gleich reviewen (so ich das wissen dazu habe), patchen, kompilieren, fertig.
Naja, das ist schon etwas theoretisch, meinst du nicht? Wieviele Leute sind in der Lage, gerade bei ssh, das wirklich einzuschätzen.
Bis ein Paket dafür da ist, vergehen meist ein paar Stunden und das kann bei verschiedenen Servern schon zu spät sein.
Das stimmt. Dafür hat aber der entsprechende Maintainer in 90% der Fälle mehr Ahnung von den Projektdetails als du, zumindest würde ich das von mir selbst sagen. Außerdem geht es hier ganz einfach um Ökonomie, der Zeitaufwand für sowas steht i.A. in keinem Verhältnis zum nutzen. Hängt natürlich vom Einsatzgebeit ab.
On Sun, May 09, 2004 at 07:36:30PM +0200, Eric Schaefer wrote:
Am So, den 09.05.2004 schrieb Hilmar Preusse um 17:25:
- Produktionsserver bekommen nur Security-Updates und die
kompiliert man sich sowieso selbst, wenn man sicher gehen will.
Wieso? Du hast Angst, daß Dir jemand gefakte Binaries unterschiebt?
Nein. Wenn jetzt (in drei Minuten) jemand eine sshd-Lücke mit patch und exploit veröffentlicht, kann ich den Patch gleich reviewen (so ich das wissen dazu habe), patchen, kompilieren, fertig. Bis ein Paket dafür da
^^^^^^^^^^^^^^^^^^^ hast du das Wissen?
ist, vergehen meist ein paar Stunden und das kann bei verschiedenen Servern schon zu spät sein.
Eben, deswegen würden bei mir die Firewalls umkonfiguriert und das Logging aufgeblasen, ausserdem wären die Maschinen unter Beobachtung. Ein Patch, der keine QA gesehen hat, macht dir unter umständen mehr kaputt als ganz. Und ja, gerade die "trivialen" Einzeiler haben es oft dick hinter den Ohren.
Auf meiner privaten Spielmaschine ist das allerdings relativ wurscht, aber jemand anderes fing mit "Produktionsservern" an.
Eben. Auf deiner Privatmaschine kannst du machen was du willst, auf einem Produktionsserver ist das nicht mehr so einfach. Zumindest wenn es schief- geht.
- Distributionsspezifische Kernel sind IMMER Scheiße.
Weil ich damit bisher nur Probleme hatte und noch nie einen mit dem ultimativen Killerfeature hatte, welches nicht auch in vanilla V++ enthalten gewesen wäre.
Für manche Kunden ist "Software X ist zertifiziert für Kernel Y von Distributor Z" durchaus ein Killerfeature. Und das kann man scheisse finden wie man will, aber wenn der Support für Software X halt davon abhängt, bleibt dir keine andere Wahl.
Am So, den 09.05.2004 schrieb Stefan Seyfried um 20:11:
On Sun, May 09, 2004 at 07:36:30PM +0200, Eric Schaefer wrote:
Am So, den 09.05.2004 schrieb Hilmar Preusse um 17:25:
- Produktionsserver bekommen nur Security-Updates und die
kompiliert man sich sowieso selbst, wenn man sicher gehen will.
Wieso? Du hast Angst, daß Dir jemand gefakte Binaries unterschiebt?
Nein. Wenn jetzt (in drei Minuten) jemand eine sshd-Lücke mit patch und exploit veröffentlicht, kann ich den Patch gleich reviewen (so ich das wissen dazu habe), patchen, kompilieren, fertig. Bis ein Paket dafür da
^^^^^^^^^^^^^^^^^^^ hast du das Wissen?
Nein. ;-) In erster Linie ging es mir darum, daß es je nach Distribution recht lange dauern kann, bis ein gefixes Paket da ist. Wenn ich mir statt dessen gefixte sshd-Quellen hole und die selbst kompiliere, habe ich mein System schneller dicht.
ist, vergehen meist ein paar Stunden und das kann bei verschiedenen Servern schon zu spät sein.
Eben, deswegen würden bei mir die Firewalls umkonfiguriert und das Logging aufgeblasen, ausserdem wären die Maschinen unter Beobachtung. Ein Patch, der keine QA gesehen hat, macht dir unter umständen mehr kaputt als ganz. Und ja, gerade die "trivialen" Einzeiler haben es oft dick hinter den Ohren.
Wer macht die QA?
[Distributionsspezifische Kernel]
Weil ich damit bisher nur Probleme hatte und noch nie einen mit dem ultimativen Killerfeature hatte, welches nicht auch in vanilla V++ enthalten gewesen wäre.
Für manche Kunden ist "Software X ist zertifiziert für Kernel Y von Distributor Z" durchaus ein Killerfeature. Und das kann man scheisse finden wie man will, aber wenn der Support für Software X halt davon abhängt, bleibt dir keine andere Wahl.
Es gibt Software, bei der der Hersteller z.B. auf einem Suse- oder Gentoo-Kernel besteht? Bisher ist mir höchstens welche untergekommen, die auf Suse Version X mit Kernel Version Y bestanden hat, aber nie Kernel Version Y_susepatch_Z.
Eric
On Sun, May 09, 2004 at 11:28:06PM +0200, Eric Schaefer wrote:
Wer macht die QA?
jetzt kommen wir auf des pudels Kern: Die Distributoren. Den Patch reingehackt haben die Buben von RedHat, SuSE & Co. auch in ein paar Minuten, aber erstens muss er reviewed werden, zweitens durchläuft das kompilierte Paket natürlich die QA Tests.
Es gibt Software, bei der der Hersteller z.B. auf einem Suse- oder Gentoo-Kernel besteht? Bisher ist mir höchstens welche untergekommen, die auf Suse Version X mit Kernel Version Y bestanden hat, aber nie Kernel Version Y_susepatch_Z.
SAP, Oracle (AFAIK). Wenn du deren Support nicht brauchst, dann kannst du dir kompilieren, was du willst.
Am Mo, den 10.05.2004 schrieb Stefan Seyfried um 3:58:
Wer macht die QA?
jetzt kommen wir auf des pudels Kern: Die Distributoren. Den Patch reingehackt haben die Buben von RedHat, SuSE & Co. auch in ein paar Minuten, aber erstens muss er reviewed werden, zweitens durchläuft das kompilierte Paket natürlich die QA Tests.
Die Distributoren von Blue Cat Linux [1] begreifen also die openssl-Quellen besser als die openssl Leute?
Es gibt Software, bei der der Hersteller z.B. auf einem Suse- oder Gentoo-Kernel besteht? Bisher ist mir höchstens welche untergekommen, die auf Suse Version X mit Kernel Version Y bestanden hat, aber nie Kernel Version Y_susepatch_Z.
SAP, Oracle (AFAIK). Wenn du deren Support nicht brauchst, dann kannst du dir kompilieren, was du willst.
Die bestehen wirklich auf Suse-gepatchte Kernel-Versionen? Ismirübel.
Eric
[1] The names have been changed to protect the innocent ;-)
On Mon, May 10, 2004 at 06:49:41PM +0200, Eric Schaefer wrote:
Am Mo, den 10.05.2004 schrieb Stefan Seyfried um 3:58:
Minuten, aber erstens muss er reviewed werden, zweitens durchläuft das kompilierte Paket natürlich die QA Tests.
Die Distributoren von Blue Cat Linux [1] begreifen also die openssl-Quellen besser als die openssl Leute?
nein, aber sie schauen aus einem anderen Blickwinkel drauf. Und sie schauen, ob das neugebackene openssl mit dem Rest des Systems noch ordentlich zusammenspielt. Oder sie portieren den Fix auf die (ältere) openssl-Version, die mit der Distribution ausgeliefert wurde, anstatt dir zu sagen, daß du alle deine Pakete, die openssl benutzen jetzt leider neu kompilieren musst, da sich die API geändert hat, aber der Fix halt nur in der neuesten openssl- Version drin ist. Und ja, bevor ich mich auf Theo de Raadt verlasse, verlasse ich mich lieber auf die Distributoren (ich bin mir nicht sicher, ob er was mit openssl zu tun hat, aber seine OpenSSH-"Bugfixes" sind ja legendär).
Die bestehen wirklich auf Suse-gepatchte Kernel-Versionen? Ismirübel.
Nein, die bestehen auf von ihnen Zertifizierte Kernel. Ein Vanilla-2.4.x taugt aber nunmal nicht für SAP und Oracle. Du kannst ihn dir von SAP zertifizieren lassen, dann kriegst du auch Support. Ja, die Welt ist böse.
On Wed, May 12, 2004 at 08:32:24PM +0200, Eric Schaefer wrote:
Am Mo, den 10.05.2004 schrieb Stefan Seyfried um 21:46:
Nein, die bestehen auf von ihnen Zertifizierte Kernel. Ein Vanilla-2.4.x taugt aber nunmal nicht für SAP und Oracle.
Warum? Weißt Du was die für besondere Anforderungen haben?
nicht genau, aber es sind wohl die VM-patches wenn ich das richtig verstanden habe.
Stefan Seyfried schrieb:
On Wed, May 12, 2004 at 08:32:24PM +0200, Eric Schaefer wrote:
Am Mo, den 10.05.2004 schrieb Stefan Seyfried um 21:46:
Nein, die bestehen auf von ihnen Zertifizierte Kernel. Ein Vanilla-2.4.x taugt aber nunmal nicht für SAP und Oracle.
Warum? Weißt Du was die für besondere Anforderungen haben?
nicht genau, aber es sind wohl die VM-patches wenn ich das richtig verstanden habe.
Ich würde eher vermuten, dass die aufgrund zu geringer Lizenzkosten kein Geld für den Support anderer Kernel haben. ;-)
Torsten
On Fri, May 14, 2004 at 07:50:08AM +0200, Torsten Werner wrote:
Ich würde eher vermuten, dass die aufgrund zu geringer Lizenzkosten kein Geld für den Support anderer Kernel haben. ;-)
naja, betreibe mal einen Datenbankserver mit >4G RAM mit einem Vanilla 2.4.x Viel Spaß.
Ähnlich verhält es sich mit 2.6.x ohne Andrea Arcangeli's VM. Die kommt nun aber wohl doch via -mm in mainline.
On Sat, May 15, 2004 at 07:11:48PM +0200, Torsten Werner wrote:
Stefan Seyfried schrieb:
naja, betreibe mal einen Datenbankserver mit >4G RAM mit einem Vanilla 2.4.x Viel Spaß.
Dafür gilt schon seit vielen Jahren: kauf dir ein 64-Bit-System, statt auf dirty hacks zu bauen.
jein, die VM wird davon nicht besser, wenn sie einfach nicht für diesen Einsatzfall ausgelegt war. Aber das ist nicht mehr meine "Kernkompetenz", insofern kann ich dazu nicht viel qualifiziertes sagen.
On Sun, May 09, 2004 at 03:53:10PM +0200, Eric Schaefer wrote:
*Prust* "Produktionsserver" und "Up-to-date-halten" in einem Satz...
- Produktionsserver bekommen nur Security-Updates und die kompiliert
man sich sowieso selbst, wenn man sicher gehen will.
[ ] ich will dein Kunde sein. [ ] ich will dich für dein Hobby bezahlen müssen.
Sorry, aber Administratoren, die meinen sie seien den security-Teams der Distributionen soweit überlegen, daß sie alles mit selbstkompilieren und selbstfixen im Griff hätten, kann ich einfach nicht mehr wirklich Ernst nehmen. Auf Maschinen, bei denen ein Stillstand richtig Geld kostet, ist das einfach nicht tragbar.
Am So, den 09.05.2004 schrieb Stefan Seyfried um 20:01:
"Produktionsserver" und "Up-to-date-halten" in einem Satz...
- Produktionsserver bekommen nur Security-Updates und die kompiliert
man sich sowieso selbst, wenn man sicher gehen will.
[ ] ich will dein Kunde sein. [ ] ich will dich für dein Hobby bezahlen müssen.
Sorry, aber Administratoren, die meinen sie seien den security-Teams der Distributionen soweit überlegen, daß sie alles mit selbstkompilieren und selbstfixen im Griff hätten, kann ich einfach nicht mehr wirklich Ernst nehmen. Auf Maschinen, bei denen ein Stillstand richtig Geld kostet, ist das einfach nicht tragbar.
Da hast Du irgendwas falsch verstanden. Ich bin nur der Meinung daß z.B. das Apache-Security-Team dem Distribution-X-Security-Team überlegen ist, vor allem zeitlich.
Mal abgesehen davon, daß es in meinem zitierten Text oben in erster Linie um das Thema Produktionsserver und "up-to-date-halten" geht. Und ich bin mir sicher, daß Du auf einem Produktionsserver nicht irgendwelche Software updatest, nur weil es eben eine neue Version gibt, es sein denn es handelt sich um ein Security-Update. Das mache ich nichtmal auf meinem Heimserver.
Eric
On 08.05.04 Thomas Jacob (jacob@internet24.de) wrote:
Moin,
p.s.: Jaja, ich weiss das Debian nicht mehr das ist was es mal war.
Wie war es denn mal?
H.
On Sun, May 09, 2004 at 02:18:58PM +0200, Hilmar Preusse wrote:
On 08.05.04 Thomas Jacob (jacob@internet24.de) wrote:
Moin,
p.s.: Jaja, ich weiss das Debian nicht mehr das ist was es mal war.
Wie war es denn mal?
Up to date. Debian stable hat steinalte Software. Debian unstable hat sicher nen stabileren Distro-Kernel als Gentoo, aber auch 10-100mal soviel updates pro Woche ;)
On 09.05.04 Thomas Jacob (jacob@internet24.de) wrote:
On Sun, May 09, 2004 at 02:18:58PM +0200, Hilmar Preusse wrote:
Moin,
[Debian nicht mehr das ist was es mal war.]
Wie war es denn mal?
Up to date. Debian stable hat steinalte Software.
Muß aber lange her sein. War wohl noch in den Zeiten, wo sie alle halbe Jahre released haben. In den letzten Tagen von potato habe ich ganz schöne Klimmzüge gemacht und war echt froh, als woody rauskam. Derzeit geht es mir ähnlich, aber bei weitem nicht so schlimm. Na ja, sarge ist ja auch noch nicht draußen. ;-|
H.
On Sun, May 09, 2004 at 06:28:25PM +0200, Hilmar Preusse wrote:
On 09.05.04 Thomas Jacob (jacob@internet24.de) wrote: Muß aber lange her sein. War wohl noch in den Zeiten, wo sie alle halbe Jahre released haben. In den letzten Tagen von potato habe ich ganz schöne Klimmzüge gemacht und war echt froh, als woody rauskam.
Nun ja. Relativ up to date. Ohne backports.org/apt-get.org würde woody inzwischen keinen Spass mehr machen.
Viele Provider bieten das aber immer noch als Standard-Distro an, weil man halt so schön schnell und einfach Sicherheitsupdates einspielen kann (*winkwink* ;).
Aber als Desktop/Devel-System ist es natürlich veraltet, dafür muss man dann schon Debian testing/unstable nehmen.
Grüssens.
On 09.05.04 Thomas Jacob (jacob@internet24.de) wrote:
On Sun, May 09, 2004 at 06:28:25PM +0200, Hilmar Preusse wrote:
Moin,
Muß aber lange her sein. War wohl noch in den Zeiten, wo sie alle halbe Jahre released haben. In den letzten Tagen von potato habe ich ganz schöne Klimmzüge gemacht und war echt froh, als woody rauskam.
Viele Provider bieten das aber immer noch als Standard-Distro an, weil man halt so schön schnell und einfach Sicherheitsupdates einspielen kann (*winkwink* ;).
ACK.
Aber als Desktop/Devel-System ist es natürlich veraltet, dafür muss man dann schon Debian testing/unstable nehmen.
Nun, hier läuft stable als Desktop System. Bei 56k-Modemanbindung will ich nicht testing fahren. Ich hab gehört, bei Gentoo könnte man sich neue Source-Pakete mittels rsync einspielen, backen muß man danach selber. Das hört sich gut an. Ich hab aber Angst vor ewigen Compilerorgien und vorm Umstieg....
H.
Hilmar Preusse hille42@web.de at 2004-05-10 0833 +0200:
Ich hab gehört, bei Gentoo könnte man sich neue Source-Pakete mittels rsync einspielen, backen muß man danach selber. Das hört sich gut an.
Der Portage-Tree wird per rsync geupdatet. Sourcen kommen ganz normal als tar.{gz|bz2}, oder habe ich was verpasst?
Ich hab aber Angst vor ewigen Compilerorgien und vorm Umstieg....
Wie andere weiter oben schon gesagt haben: Du kannst auch erstmal komplett binär installieren und später im Hintergrund geniced drüber kompilieren.
MfG, Jonas
Jonas Witt wrote:
Hilmar Preusse hille42@web.de at 2004-05-10 0833 +0200:
Ich hab aber Angst vor ewigen Compilerorgien und vorm Umstieg....
Wie andere weiter oben schon gesagt haben: Du kannst auch erstmal komplett binär installieren und später im Hintergrund geniced drüber kompilieren.
Oder auch die Binär-Pakete (per CD aus dem Versand) installieren und so lassen wie sie sind, wenn dir die Compiler- und USE-Flags, mit denen sie gebaut wurden, gefallen. Und dir dann nur die einzelnen Pakete mit eigenen Flags neu kompilieren, bei denen du gern was anders hättest. Effekt wäre ein 1) schnell binär installiertes, 2) stabiles*, 3) modernes, 4) anpassbares System.
mfg, Fabian
* mir ist zwar noch keine fehlfunktionierende SW unter Gentoo begegnet, aber Debian ist durch intensives Testen sicher stahlbeton-stabil
On 10.05.04 Jonas Witt (wittj@gmx.net) wrote:
Hilmar Preusse hille42@web.de at 2004-05-10 0833 +0200:
Moin,
Ich hab gehört, bei Gentoo könnte man sich neue Source-Pakete mittels rsync einspielen, backen muß man danach selber. Das hört sich gut an.
Der Portage-Tree wird per rsync geupdatet. Sourcen kommen ganz normal als tar.{gz|bz2}, oder habe ich was verpasst?
Ja, so klingt das auch sinnvoll.
Ich hab aber Angst vor ewigen Compilerorgien und vorm Umstieg....
Wie andere weiter oben schon gesagt haben: Du kannst auch erstmal komplett binär installieren und später im Hintergrund geniced drüber kompilieren.
Ja, dann kann ich mir aber auch Debian (unstable) kommen lassen und die Source-Pakete nach und nach durch den Compiler drücken. Bloß ein "make world" wird nicht ganz so gut unterstützt. ;-)
H.
Am Samstag, 08. Mai 2004 17:07 schrieb Jonas Witt:
Johannes Richter joe_2000@web.de at 2004-05-08 1645 +0200:
Hallo Lug,
Hallo Johannes,
nach einer kleinen Pause bin ich jetzt wieder in Sachen Linux aktiv geworden und habe mich mal an der Gentoo Distri versucht.
Zuerst hatte ich die Version 2004 mit dem Minimalinstaller installiert (stage3) und bin auch soweit gut weitergekommen und hatte auch schon einen 2.6 er Kernel kompiliert, nur dann gab es ständig probleme beim emerge von verschiedenen Paketen (mc, w3m, qt-libs) da sie beim compilieren gescheitert sind.
Genaue Fehlermeldungen? (Die letzten 10-20 Zeilen)
guter tip, habe dann auch mal genauer hingesehen (nachdem ich alles nochmal neu installiert hatte) das Script hat eine libstd++.la gesucht und zwar in /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.2/ und als ich mir das mal näher angesehen hatte stellte ich fest, das es nur ein .../i686... bei mir gab. Hab einfach einen Symlink erstellt und: Jetzt tut es ...
viele Grüße Joe
Hallo Johannes,
Johannes Richter wrote:
einen 2.6 er Kernel kompiliert, nur dann gab es ständig probleme beim emerge von verschiedenen Paketen (mc, w3m, qt-libs) da sie beim compilieren gescheitert sind.
Willkommen bei der Meta-Distributionen ;-) Was meldet er denn so an Problemen?
Kann man den 2.6 er Kernel schon benutzen? Gibt es etwas zu beachten,
Gentoo 1.4, Kernel 2.6.3. Hab einfach den 2.6 emerged, kompiliert und alles lief weiter wie bisher. Hast du die modutils upgedatet (bei mir 2.4.25)?
mfg, Fabian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Am Samstag, 8. Mai 2004 16:45 schrieb Johannes Richter:
Kann man den 2.6 er Kernel schon benutzen? Gibt es etwas zu beachten, was
Ja, bei mir läuft er wunderbar.
nicht im Handbuch steht? Kann mir jemand einen Vernünftigen Server für die
Zu beachten ist eigentlich nur, das nicht im Handbuch steht, das der 2.6er Kernel nicht auf der Installations-CD (2004.0) ist. Außerdem fehlte bei mir der iwconfig-Befehl, so dass eine Installation über WLAN nicht möglich war.
Binary Packete sagen, oder sollte man dazu die CD's benutzen ?
So einen Server wüsste ich auch gerne, da hilft erstmal nur die CDs zu benutzen. Sonst mal im Gentoo-Forum nachfragen.
Ciao, Martin
- -- | Martin Eisfeld martin.eisfeld@gmx.net | GnuPG-KeyID: 0x70AC13D5 | Homepage: http://www.martin-eisfeld.de/ | LinuxInfoTag Dresden * 30.10.2004 * http://www.linuxinfotag.de/
Martin Eisfeld martin.eisfeld@gmx.net wrote:
Am Samstag, 8. Mai 2004 16:45 schrieb Johannes Richter:
Kann man den 2.6 er Kernel schon benutzen? Gibt es etwas zu beachten, was
Ja, bei mir läuft er wunderbar.
Bei mir nicht. Ich nehm den 2.4.26er da das Modul für meine Netzwerkkarte regelmäßig den Abgang macht. (bcm4400).
Mfg, Martin
lug-dd@mailman.schlittermann.de
-
Eric Schaefer -
Fabian Hänsel -
Hilmar Preusse -
Johannes Richter -
Johannes Richter -
Jonas Witt -
Marek Werstak -
Martin Eisfeld -
Martin Weissbach -
Matthias Petermann -
Stefan Seyfried -
Thomas Jacob -
Torsten Werner