Macht kompilieren noch Sinn wenn DEB's erhätlich sind

[stefanT42]

Hallo zusammen,

ich diskutiere schon länger mit Freunden darüber, was eigentlich mehr Vorteile hat :

apt-get install *.deb oder make sprich selbst kompilieren?

Da geht es die meiste Zeit um die Punkte wie

1. Performance
2. Sicherheit
3. Overhead

Vielleicht können hier einige Fachleute mal Ihre Meinungen Erfarhungen offenbaren.

Vielen Dank schonmal,

Stefan

[rendegast]

Zu 1. und 3.
Kannst Du das messen, bzw bemerkst Du da einen Unterschied?
Nach einem linux-Magazin-Artikel zur Kompiler-Optimierung liegt das im Prozentbereich.

zu 2.
Das ist ein Punkt, Bsp clamav: dessen Versionsupdates SIND Sicherheitsupdates.
Aus anderer Sicht: Der Anlaß einer solchen Aktion ist meist eine fehlende Funktion der Software. Würdest Du dann selbst immer schön auf die Aktualisierung Deiner Komponenten achten?

[GoKi]

Zu 1. und 3.
Kannst Du das messen, bzw bemerkst Du da einen Unterschied?
Nach einem linux-Magazin-Artikel zur Kompiler-Optimierung liegt das im Prozentbereich.

Zum Glück sind wir nicht in nem Gentoo Forum

Ich persönlich kompiliere nichts, was es auch als Paket gibt. Mit ein Grund für mich Debian zu benutzen. ist die große Anzahl an zur Verfügung stehenden Pakten, die auf einfache Art installiert werden können. Also ich habe mich dafür entschieden so wenig wie möglich zu kompilieren. Und mich daher auch für eine Binär-Distro entschieden, also eben nicht für eine Source Distro wie Gentoo, SourceMage, usw.

[Leonidas]

Ich persönlich kompiliere nichts, was es auch als Paket gibt. Mit ein Grund für mich Debian zu benutzen. ist die große Anzahl an zur Verfügung stehenden Pakten, die auf einfache Art installiert werden können. Also ich habe mich dafür entschieden so wenig wie möglich zu kompilieren. Und mich daher auch für eine Binär-Distro entschieden, also eben nicht für eine Source Distro wie Gentoo, SourceMage, usw.

Ich denke nicht dass das Killerfeature bei Gentoo das selbstkompilieren ist. Schließlich müsste es auch möglich sein, mit ein paar kleinen Änderungen an den ``rules``-Dateien die CFLAGS zu setzen und das Paket mit optimierungen zu kompilieren. Das geht in Debian auch, mit apt-build. Man könnte damit auch das ganze System übersetzen und dann selbst entscheiden, ob es was gebracht hat. Die Stärke von Gentoo sind die USE-Flags, mit denen ich etwa sagen kann ob ich ein Paket mit X11 kompilieren will oder ohne. Die Equivalente dazu sind in Debian spezielle, alternative Pakete etwa emacs-nox, mplayer-nogui, vim-full, vim-tiny etc, aber die sind natürlich nicht ganz so umfassend konfigurierbar. Andererseits hat man auch nicht das Problem, dass man Pakete neu kompilieren muss, weil man USE-Flag XY nicht gesetzt hat und das dann doch nötig war.

[catdog2]

Die USE flags können eine schöne Sache sein. Auf einem System, an dem man an der Softwareaustattung selten etwas ändert und genau weiss was man braucht, kann man da sicher gut was optimieren und Sicherheitslücken minimieren.
Auf einem normalen Desktop System, dass möglichst alles können sollte und auf dem man auch einiges ausprobiert ist sowas nicht wirklich vorteilhaft. "Recompile <irgendwasgroßes> with USE=irgendwas". Dann darfst du Stunden warten obwohl du eigentlich nur ein kleines Programm installieren wolltest.

Ich persönlich kompiliere nichts, was es auch als Paket gibt. Mit ein Grund für mich Debian zu benutzen. ist die große Anzahl an zur Verfügung stehenden Pakten, die auf einfache Art installiert werden können. Also ich habe mich dafür entschieden so wenig wie möglich zu kompilieren. Und mich daher auch für eine Binär-Distro entschieden, also eben nicht für eine Source Distro wie Gentoo, SourceMage, usw.

Sehe ich ähnlich. Vor allem ist es für mich auch die einfache Art das ganze up-to-date zu halten. Wenn ich irgendwas per Hand installiere reicht eben kein dist-upgrade. Deswegen mach ich das nur bei wenigen ausgewählten Sachen (wine, firefox, kernel ... und das teilweise auch nur, weil ich mir das irgendwann mal angefangen habe und so weitermache).
Eine weitere wichtige Sache ist die Zeit, die das kompilieren braucht. Man kann bei distris wie gentoo eben oft nicht ganz schnell was nachinstallieren, weil es seine Zeit braucht, bis es gebaut ist. Und wenn ich mir vorstelle ich müsste in testing das tägliche dist-upgrade durch den Compiler jagen... meine CPU brauch ich für andere Dinge.
Das kompilieren Überlass ich dann doch dem Rechner, der dafür da ist... dem Buildserver. Was anderes kann man ja schon aus Umweltaspekten nicht mehr verantworten. Was das Strom braucht, wenn jeder den gleichen Arbeitsschritt selber ausführt, anstatt einmal zentral.
War jetzt als Witz gedacht, aber wenn mal mal genauer drüber nachdenkt... Bei einer Binärdistri schaltet man den Rechner ab wenn man für länger weggeht, bei gentoo wirft man den den Updatemechanismus an und lässt die Kiste auf Volllast rödeln.

[gms]

Die USE flags können eine schöne Sache sein. Auf einem System, an dem man an der Softwareaustattung selten etwas ändert und genau weiss was man braucht, kann man da sicher gut was optimieren und Sicherheitslücken minimieren.
Auf einem normalen Desktop System, dass möglichst alles können sollte und auf dem man auch einiges ausprobiert ist sowas nicht wirklich vorteilhaft.

welches normale Desktop System muß schon alles können ? Wer braucht schon Gnome/GTK UND KDE/Qt Support ? Und selbst wenn, dann gibts noch über 100 andere USE-Flags mit denen man das System an seine eigenen Bedürfnisse anpassen kann.

"Recompile <irgendwasgroßes> with USE=irgendwas". Dann darfst du Stunden warten obwohl du eigentlich nur ein kleines Programm installieren wolltest.

Ist ja nicht so, daß ich beim Kompilieren zugucken muß und Gut Ding braucht eben Weile
Wenn ich nur schnell ein Programm ausprobieren möchte, dann kann ich das auch auf meinem Debian-Server, oder im Debian-Chroot auf meinem Laptop

Und wenn ich mir vorstelle ich müsste in testing das tägliche dist-upgrade durch den Compiler jagen... meine CPU brauch ich für andere Dinge.
...
Bei einer Binärdistri schaltet man den Rechner ab wenn man für länger weggeht, bei gentoo wirft man den den Updatemechanismus an und lässt die Kiste auf Volllast rödeln.

Das wäre eine Möglichkeit, bei mir läuft das Upgrade aber im Hintergrund und ist nur durch durch einen leichte Erhöhung der Load Anzeige zu bemerken, bzw durch die Rückmeldung ob alles glatt gelaufen ist, oder eben nicht. Wenn ich länger weggehe klappe ich den Laptop-Deckel zu und wenn ich wieder komme macht das System Dank "Suspend to Disk" dort weiter, wo es aufgehört hat

Außerdem sehe ich keinen Zusammenhang zwischen der Fragestellung und einer Diskussion über Gentoo! Es steht ja nicht die Frage im Raum "apt-get vs emerge", sondern "apt-get vs make",
also ob es sinnvoll ist Pakete selber zu bauen, wenn diese auch über den Paketmanager installierbar sind. Wie Leonidas schon angemerkt hat, ist bei Debian mit "apt-build" beides möglich.
Somit hat man ( wenn man daran glaubt ) eine Performancesteigerung, keinen Nachteil bei der Sicherheit und je nachdem wieviele Pakete man selber bauen möchte, entweder einen kleinen, oder einen größeren Overhead.

Gruß
gms

[Leonidas]

Die USE flags können eine schöne Sache sein. Auf einem System, an dem man an der Softwareaustattung selten etwas ändert und genau weiss was man braucht, kann man da sicher gut was optimieren und Sicherheitslücken minimieren.
Auf einem normalen Desktop System, dass möglichst alles können sollte und auf dem man auch einiges ausprobiert ist sowas nicht wirklich vorteilhaft. "Recompile <irgendwasgroßes> with USE=irgendwas". Dann darfst du Stunden warten obwohl du eigentlich nur ein kleines Programm installieren wolltest.

Ja, gut xmonad installieren ist lästig, weil es GHC braucht und GHC eine halbe Ewigkeit kompiliert. Ansonsten dauert es in der Regel gar icht so lange, auf Gentoo stable gibt es oft tagelang keine Updates. Ein anderer Vorteil ist, dass die Gentoo-``-r<num>``-Releases nicht immer das neue Source-File runterladen müssen, wie die Debian-``-<num>``-Releases. Dafür hast du eben einen Gigabyte an Tarballs rumliegen

Bei einer Binärdistri schaltet man den Rechner ab wenn man für länger weggeht, bei gentoo wirft man den den Updatemechanismus an und lässt die Kiste auf Volllast rödeln.

Nein, das ist mir seit Monaten zwei Mal passiert: Installation + kompilation von GNOME, Update auf GNOME 2.22. Die restlichen Kompilationen laufen nebenher.

Ob es jetzt Portage oder APT ist: Paketmanagement ist auf jeden Fall besser als kein Paketmanagement. Erstens hat man dadurch die Sicherheit, dass sich die kompilierten Pakete gut ins System einfügen (wer kompiliert GNOME mittels GRNOME oder jhbuild? Warum sonst dauert das Upgrade auf neue Versionen so lange?) und zweitens Sicherheitsupdates, drittens kann das Paketmanagement das Paket ggf. als Dependency nutzen, falls es später ein anderes, via Paketmanager installiertes Programm zum funktionieren benötigt, etc.

[C167]

wie einige inzwischen wissen bin ich quasi ein junkie, immer gerne auf der neusten Version. Ich compiliere dafuer auch einige Anwendungen selbst, solange sie remove- oder uninstall-Targets haben. Nennt es Spass an der Freude
Bei einigen Sachen ist es aber so, dass ich neben der neust moeglichen Version auch gerne ein wenig optimiere, was momentan nur auf Games wie Nexuiz und XMoto zutrifft, aber auch xaos (fraktalgenerator) und andere Rechenintensive Dinge passe ich gerne auf mein System an. So bekomme ich bei Nexuiz trunk trotz des Schlechten fglrx-Treibers durch die Optimierung ca. 50-80 FPS mehr als ohne und renne je nach Karte auf bis zu 200FPS rum. Genug Puffer moechte man meinen

[Saxman]

So bekomme ich bei Nexuiz trunk trotz des Schlechten fglrx-Treibers durch die Optimierung ca. 50-80 FPS mehr als ohne und renne je nach Karte auf bis zu 200FPS rum. Genug Puffer moechte man meinen

Da bin Ich mal neugierig, was optimierst du denn?
Welche sourcen nutzt du denn dafür? die aus den repos oder von der website?

Könnte hier nicht nur mich interessieren. Gel RuckelSandra?

Schönen Gruß

[catdog2]

Sie hat doch eh bald einen neuen Rechner.

[Saxman]

Sie hat doch eh bald einen neuen Rechner.

Wenn sie es denn schaft sich mal für ein Mainboard zu entscheiden...

Neugierig bin ich aber trotzdem immer noch...

[catdog2]

Würd mich auch interessieren, wie man da so viel rausholen kann.

[cirrussc]

Welche sourcen nutzt du denn dafür? die aus den repos oder von der website?

Wäre mal interessant.

Könnte hier nicht nur mich interessieren. Gel RuckelSandra?

Oh ja Ruckelsandra wird es brauchen, obwohl sie so schon nicht schlecht ist.

Wenn sie es denn schaft sich mal für ein Mainboard zu entscheiden...

Diese Woche ist es wohl soweit
C167 Antworte uns

Ich konfiguriere und kompiliere höchstens den Kernel und ein paar Anwendung neuerer Version als im Repo. sind selber.
Schliesslich klappt das nicht auf jedem System innerhalb einer gewissen Zeit, die Rechenleistung ist bestimmend.
Zudem hat das Energieverbrauch Argument auch Hand und Fuss.

[C167]

leutz, ich schreib morgen IT-Abitur, also habt Gedult
darkplaces: svn://svn.icculus.org/twilight/trunk/darkplaces
nexuiz: svn://svn.icculus.org/nexuiz/trunk

die Datei makefile.inc im Ordner darkplaces editieren:

Code: Alles auswählen

CPUOPTIMIZATIONS=-pipe -march=prescott -fomit-frame-pointer -mfpmath=sse -msse -msse2 -msse3

dann ein kleines diff:

Code: Alles auswählen

-#OPTIM_RELEASE=-O2 -fno-strict-aliasing -ffast-math -funroll-loops $(CPUOPTIMIZATIONS)
+OPTIM_RELEASE=-O3 -fno-strict-aliasing -ffast-math -funroll-loops $(CPUOPTIMIZATIONS)

evtl noch verbieten dass er die sdl-version baut. dann einfach "make cl-nexuiz" und der Kern baut. ich hab nen symlink von nexuiz-glx (also der engine) nach /usr/local/bin/nexuiz und brauch nur nexuiz eingeben.

im Nexuiz-Ordner wirds schwerer, da muessen die qc-sourcen compiliert werden. dazu braucht man ne aktuelle Version von fteqcc, woher evtl spaeter, muss ich suchen
man muss den Befehl fteqcc in den Ordnern
nexuiz/data/qcsrc/menu client und server ausfuehren wenn ich mich recht erinnere. dann geht man in den nexuiz-ordner zurueck und gibt nexuiz ein (was den symlink ausfuehrt)

[Saxman]

Vielen Dank für deine Anleitung.

Ich hab das mal nachvollzogen mit etch amd64, allerdings mit den sourcen aus den repos.

Die letzte funktionierende Konfiguration ist bei mir

Code: Alles auswählen

CPUOPTIMIZATIONS=-pipe -march=athlon64 -m64 -fomit-frame-pointer -mfpmath=sse -mmmx -msse -msse2 -m3dnow

und

Code: Alles auswählen

OPTIM_RELEASE=-O3 -fno-strict-aliasing -funroll-loops $(CPUOPTIMIZATIONS)

Alles andere produziert Fehler.
Einen großen Geschwindigkeitszuwachs konnte Ich allerdings nicht verbuchen.
Lohnt sich nicht wirklich, zumindest nicht für meine Architektur.

Die Jungs vom debian amd64 team machen ihre Sache anscheinend ganz ordentlich.

Danke trotzdem.

Schönen Gruß

[Leonidas]

Die Jungs vom debian amd64 team machen ihre Sache anscheinend ganz ordentlich.

Naja, da gibt es ja auch nicht viel zu optimieren, da x86_64 recht neu ist. Da sind viele CPU-Erweiterungen von Haus aus drin, so sind alle CPUs mit SSE, SSE2 usw. Da gibt es einfach keine alten CPUs die wesentlich weniger Erweiterungen haben, zu denen man trotzdem noch kompatibel bleibt.