Zitat

so kann es unter umständen passieren dass ich mit make install ein paar dateien überschriebe, und danach mit emerge diese wieder lösche, da ja emerge nicht weiß dass es die abhängikeiten gibt.

theoretisch schon, praktisch ist es mir eigentlich noch nie passiert, weil sich ein manuelles "make install" nach /usr/local installiert, aber ein ebuild nach /usr. Natürlich, könnten v.a. in /etc sachen überschrieben werden, aber da fallen mir grad 2 geile sachen von portage ein:

1.) konfigurationsdatein in /etc werden nicht einfach überschrieben wenn ich z.b. ein paket upgrade. Sondern es fragt dich, ob du lieber die neue oder alte version verwenden willst, oder du kannst die 2 dateien sogar interaktiv mergen.

2.) globale USE flags:
daher braucht man (meist) ein ./configure gar nicht, weil ich sag 1 mal global, ich will z.b. java und gnome support in programmen deaktivieren, dafür will ich, dass optionale kde oder alsa features von den programmen mitinstalliert werden. Sowas geht soweit ich weiß mit apt-get nicht, weilst du da ja nicht den source zu verfügung hast.

Zitat von Alex_K

wie schon martin richtig stellte gibt es apt auch schon seit langen auch für rpm distributionen. und für die großen rpm basierten distributionen (redhat/fedora, suse,... mandrake hat soweit ich weiß ein eigenes update system) gibt es auch ausreichend server.

nur wo stehen diese server? bei redhat/fedora, bei suse, bei mandrake...
das problem ist nunmal dass es nicht immer vom distributor gewünscht wird updates bereitzustellen.
bei suse bekommt man vom server sehr wohl aktualisierte programmversionen, aber das sind versionen in denen bugs oder security-probleme beseitigt worden sind.
einen neuen gnome oder mozilla wirst auf diesen servern kaum finden. klar, du kannst dir alternative server eintragen, nur ein update einen gnome oder kde oder mozilla wird zur geduldsprobe.
für jeden der seine distribution verkaufen will hat die zu einfache updatefunktion den nachteil dass nach der ersten box jeder kaufanreiz weg ist (warum kaufen wenn ich eh gemütlich updaten kann), bei gentoo oder debian ist der verkauf der distribution eher nebensächlich.

Zitat von Alex_K

der redhat nachfolger fedora liefert auch von haus aus yum (kann das gleiche wie apt) mit. und es schönes applet für gnome das anzeigt ob es updates gibt.

das schöne ist dass sich die systeme nicht auschließen, du kannst apt, yum, oder rpm verwenden und es macht keine problem.

ein weiter großer vorteil ist checkinstall dass unter anderem auch für rpm gibt.
wenn ich unter gentoo ein paket installieren will das nicht als ebuild vorhanden ist, muss ich mir entweder selbst eines bauen, oder ich installiere es per make install. das problem bei einem make install ist aber dass das paketsystem nichts von diesem paket weiß. so kann es unter umständen passieren dass ich mit make install ein paar dateien überschriebe, und danach mit emerge diese wieder lösche, da ja emerge nicht weiß dass es die abhängikeiten gibt.

Alles anzeigen

du kannst auch bei einer rpm basierenden distribution am paketmanagement vorbeiinstallieren. wenn man etwas kaputtmachen will bekommt mans auch kaputt.

Zitat von Alex_K

mit checkinstall kann ich einfach mit einem befehl aus den sourcen ein rpm bauen, dass ich dann ich mit den abhängigkeiten in das system einbauen kann.

ebuilds bauen ist auch nicht sonderlich schwer. und mir fällt überdies nur ein programm auf meinem system ein das nicht von vornherein im portage war, nämlich ein gnome-applet... 'phone-manager'... ist aber nicht zu empfehlen. (meiner meinung)...
wo wir wieder bei den von-vornherein-unterstützten-programmen wären... also bei einem suse (out of the box, mit vielen cds und dvds) fallen mir mehrere programme ein die 'Abgehn'
NetBeans
Eclipse
Gnome 2.4 (bei suse9, ich beschwer mich ja nicht über eine release irgendeines programmes die 3 tage vorm verkauf rauskam, aber ein desktop manager der schon lang da ist hätt wirklich sein können)
GnomeICU
SIM
KMESS

dazu noch die programme die auf vielen rechnern sind aber wohl nicht mitgeliefert werden (dürfen):
Xine mit DVD und DeCSS support (damit man seine dvds schauen kann)
DVDRIP (damit man seine dvds sichern kann)
nVIDIA-Treiber.

so... ich muss dann mal...
mfg, roland

Zitat von BigBlue

nur wo stehen diese server? bei redhat/fedora, bei suse, bei mandrake...

also zu fedora:
http://freshrpms.net/
http://dag.wieers.com/home-made/apt/
http://fedora.us
...
..
.

suse und mandrake verwende ich nicht darum kenne ich dazu auch keine server.

Zitat von BigBlue

nur ein update einen gnome oder kde oder mozilla wird zur geduldsprobe.

nein, überhaupt nicht, geht aufgrund der binärer pakete weit aus schneller als bei gentoo.
und ich hab auch selber die erfahrung gemacht dass updates bei gentoo (das ich immerhin über ein jahr verwendet habe) nicht immer problemlos ablaufen.

Zitat von BigBlue

für jeden der seine distribution verkaufen will ...

na zum glück ist gentoo nicht die einzige distribution die nicht nur verkauft werden will. fedora gibt es gar nicht zum kaufen. das bekommst du nur durch einen download, oder über heft-cds.

Zitat von BigBlue

du kannst auch bei einer rpm basierenden distribution am paketmanagement vorbeiinstallieren. wenn man etwas kaputtmachen will bekommt mans auch kaputt...

klar kann man dass, aber du musst zugeben dass es weit aus einfacher checkinstall einzugeben, als ein ebuild zu bauen. somit hat man eine einachere möglichkeit das zu umgehen.

Zitat von Alex_K

also zu fedora:
http://freshrpms.net/
http://dag.wieers.com/home-made/apt/
http://fedora.us
...
..
.

suse und mandrake verwende ich nicht darum kenne ich dazu auch keine server.

nein, überhaupt nicht, geht aufgrund der binärer pakete weit aus schneller als bei gentoo.

Alles anzeigen

das mit der geduldsprobe ist auch nicht auf die (kompilier)zeit bezogen, sondern auf dirverse abhängigkeiten quer durch dir pakete durch. ich kann mich nur an eine suse erinnern deren mozilla ich updaten wollte... der gnome (oder zumindest ein teil davon) hat auf die mozilla1.4 bestanden, obwohl der 1.5er dieselbe bibilothek zur verfügung stellen würde...
was die kompilierzeit angeht, ist mir das meistens reichlich egal. es hat nichts gegeben was nicht in einer nacht fertig gewesen wäre, oder eben an einem tag uni. ich geh schlafen, sag ihm meinen 'wunsch' und wenn ich aufwache ist er da.
obs jetzt ximian-openoffice, die kde3.2-beta2, oder gnome ist ist dabei egal.

Zitat von Alex_K

und ich hab auch selber die erfahrung gemacht dass updates bei gentoo (das ich immerhin über ein jahr verwendet habe) nicht immer problemlos ablaufen.

schiefgehen kann überall was.

Zitat von Alex_K

na zum glück ist gentoo nicht die einzige distribution die nicht nur verkauft werden will. fedora gibt es gar nicht zum kaufen. das bekommst du nur durch einen download, oder über heft-cds.

fedora wird es genauso zum kaufen geben wie debian auch... nur ist mir fedora noch viel zu redhat-lastig. (aber ich werds irgendwann mal ausprobieren)

Zitat von Alex_K

klar kann man dass, aber du musst zugeben dass es weit aus einfacher checkinstall einzugeben, als ein ebuild zu bauen. somit hat man eine einachere möglichkeit das zu umgehen.

natürlich ist es einfacher... aber die frage ist ob man überhaupt _WERT_ drauf legt ein sauberes system zu haben. viele leute 'otto normalo' wissen nicht mal warum man einen paketmanager braucht. und da ist ein großes paketsystem wo nahezu jedes verfügbare paket drin ist doch besser als eines wo man halt einfach pakete bauen kann wenns noch keine gibt.

und nochmal zurück zur installationszeit: die ist im vergleich zu der zeit während du mit dem system arbeitest verschwindend gering...
und bei einigen großen paketen macht sich die geschwindigkeit zwischen selberkompiliert mit 'march=AthlonXP' oder aus einer binärdistro mit 'mcpu=586', damits ja binärkompatibel bleibt, stark bemerkbar (openoffice, gnome, kde, ...)
und da die sachen ja direkt an die usability grenzen sind sich auch spürbar beim arbeiten...

mfg, roland

Zitat von BigBlue

das mit der geduldsprobe ist auch nicht auf die (kompilier)zeit bezogen, sondern auf dirverse abhängigkeiten quer durch dir pakete durch.

die abhängigkeiten sind ja überall gleich (ist ja überall die gleiche software).
und da es ja auch bei binär distributionen massenweise an möglichkeiten gibt diese abhängigkeiten automatisch aufzulösen (apt, yum, uirpm) gibt es dieses probleme nicht mehr.

Zitat von BigBlue

fedora wird es genauso zum kaufen geben wie debian auch... nur ist mir fedora noch viel zu redhat-lastig.

1. verstehe ich nicht wirklich warum das schlecht sein soll
2. gibt es keine anzeichen dass ferdora in zufunkt verkauft werden soll.

Zitat von BigBlue

natürlich ist es einfacher... aber die frage ist ob man überhaupt _WERT_ drauf legt ein sauberes system zu haben.

spätestens wenn es dir mal passiert dass emerge aus irgendwelchen grüden keine neuen pakete mehr installieren kann (ist mir selbst passiert) wird es dir das wert sein

Zitat von BigBlue

und bei einigen großen paketen macht sich die geschwindigkeit zwischen selberkompiliert mit 'march=AthlonXP' oder aus einer binärdistro mit 'mcpu=586', damits ja binärkompatibel bleibt, stark bemerkbar (openoffice, gnome, kde, ...)

leider hat es noch keiner geschafft diese vorteile wirklich zu zeigen.
die benchmarks die ich kenne wo anwendungen (gleicher version) auf einem optimierten gentoo und auf einer binär-distribuion vergleichen werden haben praktisch keinen unterschied gezeigt.
das was dir scheller vorkommt wenn du mit gentoo arbeitest kommt daher weil du mit gentoo ein minimales system aufbaust. und so weniger dienste usw. startest.
ob es einem nun lieber ist ob man z.b. beim booten eine hardwareerkennung mitstartet oder selber alles konfiguriert ist einfach geschmakssache.

Zitat von BigBlue

und bei einigen großen paketen macht sich die geschwindigkeit zwischen selberkompiliert mit 'march=AthlonXP' oder aus einer binärdistro mit 'mcpu=586', damits ja binärkompatibel bleibt, stark bemerkbar (openoffice, gnome, kde, ...)
und da die sachen ja direkt an die usability grenzen sind sich auch spürbar beim arbeiten...

Stimmt. Die Fedora Packages sind -mcpu=i686, allerdings gibts auch isos mit den source packages bzw. source-rpms sowohl in den offiziellen repositories als auch bei dritten (freshrpms,...)

Wo wir bei optimierungen sind: von allen die ich kenn die gentoo verwenden und wirklich alles selber kompilieren, hab ich noch *niemanden* gesehen der (bevor ich mit ihm geredet hab) -msse[2]* -mfpmath=sse[,387]** in seiner make.conf drin stehen hatte. nur für -march=blah würd ich mir das nicht antun... ein paar gut gewählte optimierungen - bleiben wir beim vorigen beispiel mit gleitpunktarithmetik und sagen wir gtk/qt (muss ja nicht mal das gesamte gnome/kde sein), a/v codecs, gimp,... - können sich deutlich besser aufs system auswirken als halbherzige, die dafür konsequent
(bitte das nicht persönlich nehmen, deine make.conf kenn ich ja nicht mal, ist einfach nur eine generelle feststellung)

* bzw. -m3dnow, die gcc docs sagen nicht 100% eindeutig ob das jetzt mit -march=pentium3 oder höher defaultmäßg aktiviert wird
** sse,387 ist noch experimentell

flyingtable07:
hmm, ist bei einem "-march=pentium4" nicht automatisch -msse[2] includiert? wenn nicht, ist das gut zu wissen, und werd mal probieren -msse2 manuell hinzuzufügen bzw. mich genauer mit gcc flags zu beschäftigen.

SPEED: hat zwar nicht direkt was mit ausführungs-geschwindigkeit zu tun, aber da fällt mir gerade ein, welche angenehmen dinge selberkompilieren mit sich bringt. Wie kann ich bei apt,yum, etc. die Qt-libraries OHNE OpenGL unterstützung installieren? Da die (NVIDIA)-OpenGL libraries nicht PIC-fähiger code sind, könnte ich mit einer standardinstallation mein gesamtes KDE nicht prelinken.

So sag ich einfach 'USE="-opengl" emerge qt', und ich kompiliere Qt ohne den OpenGL support, und kann alle KDE programme prelinken, was z.b. einen "Startvorteil" von "time kmail" von 0.8 auf 0.3 sekunden bringt (nachdem es einmal im Cache ist).

Ohne einer Source-basierten distro müsst ich erst recht wieder Qt manuell downloaden, entpacken, compilieren, installieren etc., und mir erst die richtigen --configure options raussuchen.

PS: @alle gentoo user: Probierts mal den Compiler-Cache "ccache" aus, bringt bei einigen Compilationen wirklich einiges an Zeitersparnis.

hmmm......hab jetzt den ccache getestet und muss eigentlich sagen, dass die Zeitersparnis nicht so hoch ausfällt wie ich es mir erhofft hatte.
Trotzdem einiges an Zeit erspart es. 3-4 Minuten sind auch schon was.

Erster Durchgang:

cache hit					         2
 cache miss						  1182
 called for link					  186
 compile failed						 4
 preprocessor error					 3
 not a C/C++ file					  11
 autoconf compile/link				 95
 unsupported compiler option			1
 no input file						 22
 files in cache					  2364
 cache size						  37.8 Mbytes
 max cache size					   2.0 Gbytes

Zweiter Durchgang:

cache hit						   1138
 cache miss						  1182
 called for link					  367
 compile failed						 7
 preprocessor error					 5
 not a C/C++ file					  21
 autoconf compile/link				138
 unsupported compiler option			2
 no input file						 34
 files in cache					  2364
 cache size						  37.8 Mbytes
 max cache size					   2.0 Gbytes

Zitat von MaxAuthority

flyingtable07:
hmm, ist bei einem "-march=pentium4" nicht automatisch -msse[2] includiert? wenn nicht, ist das gut zu wissen, und werd mal probieren -msse2 manuell hinzuzufügen bzw. mich genauer mit gcc flags zu beschäftigen.

-msse[2] weiß ich eben nicht (habs eh beim sterndl dazugeschrieben), was du halt definitiv extra einschalten musst ist das andere, -mfpmath=sse:

Zitat

Use scalar floating point instructions present in the SSE instruction set. This instruction set is supported by Pentium3 and newer chips, in the AMD line by Athlon-4, Athlon-xp and Athlon-mp chips. The earlier version of SSE instruction set supports only single precision arithmetics, thus the double and extended precision arithmetics is still done using 387. Later version, present only in Pentium4 and the future AMD x86-64 chips supports double precision arithmetics too. For i387 you need to use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For x86-64 compiler, these extensions are enabled by default.

The resulting code should be considerably faster in majority of cases and avoid the numerical instability problems of 387 code, but may break some existing code that expects temporaries to be 80bit.

This is the default choice for x86-64 compiler.

i.e. du musst erst mal -march=pentium3 oder besser haben damit der switch überhaupt was macht.

zugegeben das mit den USE flags ist ein geniales feature, bei source-rpm installationen müsstest du das .spec file aufmachen, die entsprechenede stelle in %build finden und auskommentieren, außerdem kann man USE flags ja permanent einstellen.

übrigens: danke, jetzt check ich wenigstens worüber sich mein prelink dauernd aufgeregt hat, klar ist libGL die nvidia library :shinner:

@birger:
nein, das ist AFAIK gentoo egal, d.h. du hast (wenn möglich) auch kommerzielle software im paket-managment. Dort musst du dann aber manchmal (z.b. realplayer glaub ich), die installationsdatei manuell downloaden - installieren kannst es dann aber auch wieder über "emerge".

Stefan: prelink ist echt der wahnsinn wenn man KDE verwendet. bei gnome merkst es nicht so, aber v.a. C++ sachen starten wirklich viel schneller find ich.

mit welchem benchmark kann man eigentlich am besten solche compiler-optimierungen testen? Weil "fühlen" tut man 5-10% mehr leistung nicht wirklich, aber ich will trotzdem kein einziges prozent leistung verschwenden wenns irgendwie messbar ist und mir keine nachteile bringt.

Xandros Linux (Früher Corel Linux) basiert auf Debian, hat eine einfache Installationsroutine und hat auf Anhieb auf meinem Laptop funktioniert (Sound, Netzwerk, ...)

Ab Heute (16.12.03) gibts angeblich Xandros V2. Werd ich mir in nächster Zeit mal anschaun.

Das blöde ist, dass keine ISO´s auf der Webseite verfügbar sind. Ich habe meine Version von E-Mule gesaugt.

mfg Stefan