Genaue Erklärung des binary / src (cvsup, buildworld) update Verfahrens

[I.MC]

Hallo!

Ich verstehe den genauen Vorgang bzw. die Unterschiede zwischen den beiden System update Möglichkeiten leider immer noch nicht. Darauf wird meiner Meinung nach nicht richtig eingegangen im Handbuch.

Fangen wir mal an:

Basis System updaten:

a) WAS ist das Basissystem, was beinhaltet es?
Bei binary upgrade via Sysinstall kann ich "minimal"
einstellen, was unter der custom Funktion dann "bin"
und "crypto" entspricht. Nun auf welche Version updatet aber
überhaupt sysinstall? Unter der Anleitung steht, dass auf die
Version geupdatet wird, von der Sysinstall ist. D.h. für mich
ich muss mir vorher irgendwoher die Version von sysinstall
besorgen, auf die ich mein System updaten möchte. Das wäre
ja ein wenig umständlich. Zudem steht irgendwo auch, dass
sysinstall gleich geblieben wäre seit FreeBSD 2.x. Wieso also
erst neue Version ziehen? Wird bei dieser Art des upgrades
auch automatisch der Standard Kernel des neues Version
installlliert? Ist es überhaupt möglich ein binary upgrade
automatisch durchführen zu lassen bei cron oder so?
Wenn ich "sysinstall installUpgrade" ausführe auch wenn
ich direkt mit angebe, was geupdatet werden soll, kommt
leider immer das sysinstall Menü (bin aber noch nicht alle
Optionen durchgegangen)

b) Update ich das "Basis" System via cvsup und kompiliere alles
selber, was für src muss ich dan überhaupt ziehen? Wenn ich
beispielsweise alle scr ziehe, installiert der dann auch einfach
alle? Angenommen ich möchte aber nur das "Basis" System
updaten, dürfte ich dann nur auch dieses ziehen bzw. im src
Ordner liegen haben?
Wo ist der Bezug zum binary uograde via sysinstall?
Entspricht die "minimal" Installation, also "bin" und "crypto"
"scr-base" bzw. "src-bin" und "src-crypto"???
Dann wird empfohlen die man pages auch upzudaten, die
könnten sich ja geändert haben. Ok, die finde ich im binary
upgrade und "man" (oder war es manpages?) aber wo sind die
bei cvsup? src-man oder so habe ich nicht gesehen.
Und zu guter letzt: Kann ich immer nur auf die nächste Version
Upgraden oder kann ich auch z.B. von 4.6 auf 4.8 gehen oder
sogar 5.0?

So, jetzt hoffe ich, dass mir bald alles ganz klar wird :-)

Gruss, Jochen

 

[asg]

Moin.

Ich verstehe den genauen Vorgang bzw. die Unterschiede zwischen den beiden System update Möglichkeiten leider immer noch nicht. Darauf wird meiner Meinung nach nicht richtig eingegangen im Handbuch.

Ich selbst nutze FreeBSD seit Version 3.0, und bin bisher nicht in die Versuchung gekommen ein binary upgrade mit sysinstall zu machen. Und ich frage mich auch, warum man dies machen will? Es gibt für mich eigentlich nur einen Grund, das es sich um einen PC handelt, bei dem es nicht die Möglichkeit gibt auf das Internet oder einen anderen Rechner im LAN zuzugreifen.
Auch mit einem Modem ist es ohne weiteres möglich einen cvsup Lauf zu starten, der am Anfang, je nachdem auf was man upgradet und welches System installiert ist, etwas "länger" dauern kann. Regelmässige cvsup Läufe sind dann innerhalb weniger Minuten durch.
Der sog. "make world" Lauf kann im Hintergrund stattfinden, das beeinträchtigt den User ja nicht, oder irgendwann in der Nacht. Einzig "mergemaster" braucht den input des Users.
Warum, frage ich mich da, warum sollte man sich daher Gedanken über sysinstall und das binary upgrade machen?

a) WAS ist das Basissystem, was beinhaltet es?

All das was Du bei Deiner FreeBSD Installation installiert hast, ohne ports und packages. Das Basissystem kann auch variieren. Es gibt ein minimales Basissystem, und ein etwas grösseres, incl. aller sourcen, mit docs und vorformatierten man pages,... .
Unter FreeBSD 4.x gehörte beispielsweise auch noch Perl zum Basissystem, das ist seit FreeBSD 5.x nicht mehr so. Hier wird Perl am Ende der Instalation als Paket installiert, ist so also getrennt vom Basisystem ohne Probleme zu deinstallieren, upzudaten,... .

Wenn Du "portversion" oder "pkg_version" mal aufrufst, wirst Du die Pakete/Ports sehen, die NICHT zum Basissystem gehören, und somit auch nicht bei einem update von diesem erneurert, gepatched oder sonstwas werden.
Diese kann man extra updaten, deinstallieren,... ohne das das Basissystem sich einen Kopp drüber macht.

Du kannst aber auch das Basissystem beeinflussen was wo wie instralliert werden soll, siehe dazu "man make.conf".

einstellen, was unter der custom Funktion dann "bin"
und "crypto" entspricht. Nun auf welche Version updatet aber
überhaupt sysinstall?

Kann man nicht unter "Options" bei Sysinstall nicht die Version angeben?

ja ein wenig umständlich. Zudem steht irgendwo auch, dass
sysinstall gleich geblieben wäre seit FreeBSD 2.x. Wieso also
erst neue Version ziehen?

sysinstall hat sich vom Code her nicht verändert, es hat sich nicht weiterentwickelt, das ist damit gemeint. sysinstall verändert sich ständig ein wenig, ein Blick ins CVS hätte Dir dies beantwortet.
Beispielsweise ist eine der letzten Änderungen, das bei FreeBSD 5.1 nun UFS2 als Standardfilesystem genommen wird wenn man die Platte labeld, und nicht mehr UFS1.
Schau Dir das CVS an.

Wird bei dieser Art des upgrades
auch automatisch der Standard Kernel des neues Version
installlliert?

Du scheinst aus der Linuxwelt zu kommen, oder anderweitig "verschmutzt" worden sein *fg*.
Ne, im ernst, unter Linux, falsch, Linux ist der Kernel. Nicht mehr nicht weniger. Das kann man dort als "Basissystem" sehen. Du kannst den Kernel rausnehmen, und durch einen anderen ersetzen.
Unter FreeBSD ist der Kernel mit dem umliegenden "verzahnt". Es gibt nicht DEN KERNEL, man kann diesen nicht einfach rausnehmen. FreeBSD ist ein komplettes lauffähiges System, hingegen Linux nur der Kernel ist und erst die Ditributionen daraus ein lauffähiges system zimmer mit dem man arbeiten kann.

Bei einem upgrade des systems nimmst Du einfach Deine alte Kernelconf, bzw. schaust Dir die neue GENERIC Kernelconf an, was sich verändert hat. Liest /usrsrc/UPDATING. Schaust bei www.freebsd.org vorbei was sich im Kernel, bzw. der kernel conf geändert haben könnte. Meist kann Du einfach deine alte kernelconfig nehmen. Wenn es grosser Versionssprünge gibt, insbesondere nun bei 4.x auf 5.x, muss man seine Kernelconfig anpassen, da sich grundlegendes geändert hat. Dies kommt aber mehr als nur äusserst selten vor.

b) Update ich das "Basis" System via cvsup und kompiliere alles
selber, was für src muss ich dan überhaupt ziehen? Wenn ich
beispielsweise alle scr ziehe, installiert der dann auch einfach
alle?

Ja, ziehe alle. Das ist wohl das beste. Und wenn cvsup diese zieht, wird erstmal gar nichts am System gemacht, nur /usr/src wird eben etwas ausgetauscht, aber das beeinträchtigt ja das System nicht. Dazu muss erst ein make world rennen.

Und, man muss nicht immer ein make world rennen lassen. Beispielsweise verändert sich nur etwas bei sysinstall, dann gehst Du nach /usr/src/usr.sbin/sysinstall und gibst dort "make install clean" ein. Gut ist. Dazu musste Du ja nicht alle sourcen neu übersetzen. Entsprechend kannst Du das bei anderen Programmen machen.

Und zu guter letzt: Kann ich immer nur auf die nächste Version
Upgraden oder kann ich auch z.B. von 4.6 auf 4.8 gehen oder
sogar 5.0?

Du kannst auch von 4.5 auf 4.8 upgraden.
Oder sonstwas machen. Es werden die sourcen einfach neu übersetzt. Bei Versionssprüngen liest man aber, naja eigentlich liest man dies immer zuerst, /usr/src/UPDATING durch. Dort stehen Hinweise was man beachten muss, was sich verändert hat und wo man in evtl. Probleme rennen könnte.
Ansonsten ist das kejn Problem.

Anders bei einem upgrade auf 5.x von 4.x. Da sich 5.x doch stark in den Innereien von 4.x unterscheidet, wird empfohlen eine Neuinstallation zu starten. Man kann auch ein upgrade machen, muss aber einiges vieles beachten. Und das sauberste ist es in diesem Falle sicher nicht. Bzw. ist eine Neuinstallation evtl. schneller durchlaufen.

 

[I.MC]

Re: Re: Genaue Erklärung des binary / src (cvsup, buildworld) update Verfahrens

Ich selbst nutze FreeBSD seit Version 3.0, und bin bisher nicht in die Versuchung gekommen ein binary upgrade mit sysinstall zu machen. Und ich frage mich auch, warum man dies machen will?
Der sog. "make world" Lauf kann im Hintergrund stattfinden, das
Warum, frage ich mich da, warum sollte man sich daher Gedanken über sysinstall und das binary upgrade machen?

Habe es zwar noch nie mit cvsup gemacht, aber ich bezweifle doch, dass man keine Performance Verluste verspürt. Wenn der immerhin stundelang kompilieren muss. Ausserdem geht binary einfach schneller :-)

All das was Du bei Deiner FreeBSD Installation installiert hast, ohne ports und packages. Das Basissystem kann auch variieren. Es gibt ein minimales Basissystem, und ein etwas grösseres, incl. aller sourcen, mit docs und vorformatierten man pages,... .

Sind nun die Dinge "bin" und "crypto" gleich bei sysinstall und cvsup? Je nachdem welche Methode ich verwende will ich nicht mit der einen die Arbeit der anderen kaputt machen.
Sprich, ich installiere am Anfang erstmalig mit sysinstall und binary.
So, jetzt will ich das Basissystem nicht mehr verändern, evtl. aber mal upgraden. Gut, nehme ich wieder sysinstall, trage die gewünschte Version unter Options ein, wähle die selben Basis Pakete wie beim ersten Mal und los. Das wird gut klappen.
Jetzt habe ich aber mal Lust das mit cvsup zu machen, ich will aber wirklich nur mein bestehendes Basissystem updaten. Da muss ich ja schon wissen, welche scr Zweige denen der Erstinstallation mittels sysinstall entsprechen. Meine Frage, was alles bei einem buildworld neu kompiliert ist leider unbeantwortet.
Wenn ich alle scr ziehe, werden dann auch alle kompiliert / installiert? Das will ich ja überhaupt nicht, es sollen ja nur die bestehende Bereiche geupdatet werden.

Kann man nicht unter "Options" bei Sysinstall nicht die Version angeben?

Ja, hast recht :-)

Ne, im ernst, unter Linux, falsch, Linux ist der Kernel. Nicht mehr nicht weniger. Das kann man dort als "Basissystem" sehen. Du kannst den Kernel rausnehmen, und durch einen anderen ersetzen.
Unter FreeBSD ist der Kernel mit dem umliegenden "verzahnt". Es gibt nicht DEN KERNEL, man kann diesen nicht einfach rausnehmen. FreeBSD ist ein komplettes lauffähiges System,

Mmh, wenn ich ein upgrade des Basissystems fahre müsste dann aber der "Standard" Kernel installiert werden. Es ist ja angeblich aus einem Guß. Also wird auch der passende Kernel benötigt. Mein alter wäre dann nicht mehr passend. Sicher gibt es doch den Standard Kernel, das ist für mich der, der standarmässig installiert wird. Da gibt es für mich nichts dran zu rütteln.
Und ich kann doch den Kernel rausnehmen und dort einen selbst kompilierten ersetzen, also austausche. Der basiert ja auch den selben Sourcen :-) Na das kann man halt so und so definieren.
Ist nicht das gleiche wie bei Linux, das stimmt natürlich :-)
Noch einmal: Aber da muss doch dann der "Standard" Kernel mit installiert werden bei binary update!!?? Sonst ist doch keine Kompatibilität gewährleistet...

Und, man muss nicht immer ein make world rennen lassen. Beispielsweise verändert sich nur etwas bei sysinstall, dann gehst Du nach /usr/src/usr.sbin/sysinstall und gibst dort "make install clean" ein. Gut ist. Dazu musste Du ja nicht alle sourcen neu übersetzen. Entsprechend kannst Du das bei anderen Programmen machen.

Mmh, hast du nicht gesagt, dass Basissystem ist aus einem Guß?
Wenn ich dann anfange nur einzelne Pakete upzudaten, kann das nicht in die Hose gehen? Oder ist das ok, solange ich in der selber Version update. Also habe 4.7 RC6 und update dann nur sysinstall auf 4.7 RC7. Wenn ich das von 4.7 nach 4.8 mache.... na ja. Geht das auch mit binary, einzelne Pakete upzudaten?
Das will ich jetzt echt wissen :-) Ich mein einfach, warum muss man Sachen selber kompilieren, wenn das fertig vorhanden ist.
Das ist doch ein unschlagbares Argument, und es sind wohl die wenigsten, die im Source Code rumfummeln.

Gruss, Jochen

 

[asg]

Re: Re: Re: Genaue Erklärung des binary / src (cvsup, buildworld) update Verfahrens

Habe es zwar noch nie mit cvsup gemacht, aber ich bezweifle doch, dass man keine Performance Verluste verspürt. Wenn der immerhin stundelang kompilieren muss. Ausserdem geht binary einfach schneller :-)

Bei einem cvsup wird nichts kompiliert.
Bei einem make world, was täglich hunderte machen, und wahrscheinlich 98% aller FreeBSD nutzen, sehe ich das Problem nicht welches Du denkst was sein könnte.
Mach es doch einfach anstatt von vornherein zu sagen, das arbeitet zu wild.
Ich kann auf meinem AMD Duron 900 ein Release bauen, ein make world über mein System rennen lassen, CDs brennen, Im Internet surfen, IRC nutzen, xmms mp3 hören, oder von mir aus auch divx Filme sehe, ohne nenneswerte Probleme. Wo also ist das Problem?

Sprich, ich installiere am Anfang erstmalig mit sysinstall und binary.
So, jetzt will ich das Basissystem nicht mehr verändern, evtl. aber mal upgraden. Gut, nehme ich wieder sysinstall, trage die gewünschte Version unter Options ein, wähle die selben Basis Pakete wie beim ersten Mal und los. Das wird gut klappen.
Jetzt habe ich aber mal Lust das mit cvsup zu machen, ich will aber wirklich nur mein bestehendes Basissystem updaten.

Warum denn? Was zum Henker spricht denn dagegen? Und, warum willst Du einmal mit sysinstall upgraden, einmal mittels cvsup und make world? Wo ist da der Sinn versteckt?

Meine Frage, was alles bei einem buildworld neu kompiliert ist leider unbeantwortet.

Alles wird neu kompiliert, auch das was alt ist wird neu gebaut. Alles was unter /usr/src liegt. Alles.
Du sprichst wahrscheinlich über die reine Theorie, oder?
Installiere Dir bitte mal cvsup-without-gui und dann gehe nach /usr/share/examples/cvsup. Dort ist eine Datei Namens "stable-supfile" und was siehst Du dort?
Genau, src-all als tag, oder, wenn Du nicht alles willst, dann eben spezifizieren:
src-base
src-bin
src-contrib
src-etc
src-games
src-gnu
src-include
src-kerberos5
src-kerberosIV
src-lib
src-libexec
[...]

Wenn Du Dich schon mit etwas beschäftigen willst, dann schau Dir das genauer an, Deine Frage hätte sich dann nämlich, wie man sieht, erübrigt.

Wenn ich alle scr ziehe, werden dann auch alle kompiliert / installiert? Das will ich ja überhaupt nicht, es sollen ja nur die bestehende Bereiche geupdatet werden.

siehe oben.

Mmh, wenn ich ein upgrade des Basissystems fahre müsste dann aber der "Standard" Kernel installiert werden. Es ist ja angeblich aus einem Guß. Also wird auch der passende Kernel benötigt. Mein alter wäre dann nicht mehr passend. Sicher gibt es doch den Standard Kernel, das ist für mich der, der standarmässig installiert wird. Da gibt es für mich nichts dran zu rütteln.

Es gibt eine GENERIC Config file, mit der man einen Kernel erstellen kann, oder der bei der erstinstallation in Funktion ist. In dieser GENERIC Config file ist ein Haufen Zeuch drin was Du für Dein System nicht brauchst, also raus damit und neuen Kernel für DEIN system backen. Fertig.
Das ist DEIn kernel für DEIN system. Und diesen kernel kannst Du auch nach einem upgrade weiter nutzen, bzw. bei einem make world wird einfach auch wieder Deine Kernel Conf genommen, und Dein kernel neu übersetzt. Das ist alles. Es wäre ein Schwchsinn jedesmal zuerst einen GENERIC Kernel backen zu müssen, um dann wieder einen eigenen zu erstellen. Findest Du nicht auch?
Dein Alter Kernel ist passend, er wird nur in das system mit neu reinübersetzt, da Userland und Kernelland in sync sein müssen. Wie ich schon schrieb, dies ist miteinander verzahnt, und nicht wie bei Linux-Distros.

Und ich kann doch den Kernel rausnehmen und dort einen selbst kompilierten ersetzen, also austausche. Der basiert ja auch den selben Sourcen :-) Na das kann man halt so und so definieren.

Das ist schlicht falsch und man kann es NICHT so oder so definieren.
Du nimmst den Kernel nicht wirklich raus, Du übersetzt diesen nur neu.
Bitte schau Dir dazu das Debian Projekt an, die probieren den NetBSD Kernel aus NetBSD zu rupfen und den FreeBSD Kernel ebenso. Aber FreeBSD ist nicht nur der Kernel, es ist das gesammte System, das ist dr Unterschied zu Linux.

Noch einmal: Aber da muss doch dann der "Standard" Kernel mit installiert werden bei binary update!!?? Sonst ist doch keine Kompatibilität gewährleistet...

Du musst den kernel nur neu übersetzen, nochmals, kernelland und userland in sync. Das ist alles. Sonst kann es zu einem seltsamen verhalten des systems kommen, an dem man dann spätestens die Verzahnung erkennt. Aber Du musst keinen GENERIC Kernel neu bauen, sondern einfach DEinen Kernel, den Du aus DEINER Kernelconf erstellt hast, neu bauen.

Zum anderen musst Du nicht wegen jedem Kram das System neu bauen, es reicht, wie ich schon geschrieben hatte, in das entsprechende verzeichnis zu gehen und dort ein make install aufzurufen. Nicht immer, aber oft reicht das.

Bitte lese in diesem Fall im handbook nach (kernel)

Mmh, hast du nicht gesagt, dass Basissystem ist aus einem Guß?
Wenn ich dann anfange nur einzelne Pakete upzudaten, kann das nicht in die Hose gehen?

Es kann, und so steht es auch im handbook, und im FAQ. Bitte lese es dort nach, aber mehr wird dort auch nicht stehen, als es "kann".

Geht das auch mit binary, einzelne Pakete upzudaten?
Das will ich jetzt echt wissen :-) Ich mein einfach, warum muss man Sachen selber kompilieren, wenn das fertig vorhanden ist.

Weil das nunmal der sauberere Weg ist. Weil es dann auf Deine Maschine passt. Weil das kompilieren von einzelnen Teilen wirklich schnell geht.
Ob man nun bei einem binary upgrade einzlne Teile austauschen kann, keine Ahnung, da ich es nicht nutze, und bis auf das eine Szenario auch nicht einsehe warum man es nutzen sollte.
Aber ich denke es wird schon gehen. Probier es eben aus.

Das ist doch ein unschlagbares Argument, und es sind wohl die wenigsten, die im Source Code rumfummeln.

Sorry, aber Du hast hingehend dessen keine Ahnung.
Hast Du jemals in der Praxis auch nur einen Teil dessen gemacht was Du hier fragst? Ich denke nein. Also mach endlich. Du wirst schon sehen was passiert.
Meine Herren.
Ansonsten, wo "fummelt" man denn im source code rum? Nirgends. man setzt nur ein "make" ab, das ist alles. Oder eben ein "make world". Dann baut sich alles neu, wo also ist das das gefummle?

 

[Ripley8]

Also ich würde schon immer auch einen GENERIC neu übersetzen.
Kostet ja nix und wenn es mit den Einstellungen im angepassten
Kernel ein Problem geben sollte, dann hat man auf jeden Fall den
generischen Kernel, mit dem das System erstmal laufen sollte.


Zu meinen Urzeiten hatte ich mich auch noch nicht an ein
häufiges Update rangetraut, da hatte ich aber das System
erst gar nicht zwischendurch erneuert, sondern irgendwann
nach einem Hardware-Wechsel neu aufgesetzt

Mit 2.2.x habe ich dann angefangen, cvsup-Updates
mitzuziehen. Über ISDN gar kein Thema und dass der
Rechner dann für den Compile-Lauf 3-4 Stunden braucht
interessiert auch niemanden, insbesondere wenn man das
vor dem Schlafengehen startet (make buildworld, also nur das
Übersetzen, nicht gleich installieren) und dann am nächsten
Morgen - sofern alles geklappt hat - installiert.

Mein derzeit schnellster Rechner braucht für eine 4.x'er
Welt so knapp 30-40 Minuten. Bei allem ab 500MHz ist
schon fast eher die Platte die Bremse...

 

[I.MC]

Re: Re: Re: Re: Genaue Erklärung des binary / src (cvsup, buildworld) update Verfahrens

Zuerst einmal möchte ich klar stellen, dass ich hier keinen angreifen will :-) Mir scheint das hier ein wenig emotional zu werden :-) Ich möchte es einfach nur genau wissen.

Bei einem make world, was täglich hunderte machen, und wahrscheinlich 98% aller FreeBSD nutzen, sehe ich das Problem nicht welches Du denkst was sein könnte.
Mach es doch einfach anstatt von vornherein zu sagen, das arbeitet zu wild.

Kann ich nicht, habe im Moment wirklich nicht ein MB Traffic über um was zu ziehen :-(

Ich kann auf meinem AMD Duron 900 ein Release bauen, ein make world über mein System rennen lassen, CDs brennen, Im Internet surfen, IRC nutzen, xmms mp3 hören, oder von mir aus auch divx Filme sehe, ohne nenneswerte Probleme. Wo also ist das Problem?

Ich dachte zumindest, dass das zu lange dauert, nachdem aber im nächsten Posting erwähnt wurde, dass das doch so schnell geht, bin ich gerne bereits das zu nutzen. Allerdings ist das für langsame alte Rechner doch schon blöde. Gut, aber diese nutze ich eh nur als Router, und die können von mir aus 3 Tage am stück kompilieren, das stört ja echt keinen.

Warum denn? Was zum Henker spricht denn dagegen? Und, warum willst Du einmal mit sysinstall upgraden, einmal mittels cvsup und make world? Wo ist da der Sinn versteckt?

Angenommen ich habe gerade keine Zeit das mittels kompilieren zu machen und will daher das binary upgrade nutzen.
Was dagegen spricht? Wenn ich src-all ziehe, ich alles kompiliere und installiere was im src Verzeichnis ist, dann habe ich doch nachher jede Menge Dinge installiert, die ich evtl. überhaupt nicht brauche.
Oder sehe ich das falsch?

Du sprichst wahrscheinlich über die reine Theorie, oder?

Nein, ich nutze cvsup um die Ports aktuell zu halten, nicht jedoch für das Basis System.

Installiere Dir bitte mal cvsup-without-gui und dann gehe nach /usr/share/examples/cvsup. Dort ist eine Datei Namens "stable-supfile" und was siehst Du dort?
Genau, src-all als tag, oder, wenn Du nicht alles willst, dann eben spezifizieren:

S.o. Ich weiss immer noch nicht, ob das "bin" und "crypto" in sysinstall und cvsup gleich sind. Ich vermute jetzt einfach ja.
Ich sehe allerdings nicht wieso sich meine Frage da von alleine geklärt hätte. Ich weiss, dass ich die Bereiche, die ich haben möchte im supfile wählen kann. Aber ich wusst nicht das wenn ich das ganze System neu bau, dass dann alles was an src da ist auch kompiliert und installiert wird.

Es gibt eine GENERIC Config file, mit der man einen Kernel erstellen kann, oder der bei der erstinstallation in Funktion ist. In dieser GENERIC Config file ist ein Haufen Zeuch drin was Du für Dein System nicht brauchst, also raus damit und neuen Kernel für DEIN system backen. Fertig.
Das ist DEIn kernel für DEIN system. Und diesen kernel kannst Du auch nach einem upgrade weiter nutzen, bzw. bei einem make world wird einfach auch wieder Deine Kernel Conf genommen, und Dein kernel neu übersetzt. Das ist alles. Es wäre ein Schwchsinn jedesmal zuerst einen GENERIC Kernel backen zu müssen, um dann wieder einen eigenen zu erstellen. Findest Du nicht auch?
Dein Alter Kernel ist passend, er wird nur in das system mit neu reinübersetzt, da Userland und Kernelland in sync sein müssen. [

Ich weiss, habe durchaus mehrere Kernel kompiliert. Aber das war leider gar nicht meine Frage, habe beim ersten Teil der Frage das Wörtchen "binary" vergessen. Das das so läuft beim selber kompilieren ist mir absolut klar. Meine Frage war, was passiert mit meinem alten Kernel, wenn ich ein binary upgrade mache?

Hast Du jemals in der Praxis auch nur einen Teil dessen gemacht was Du hier fragst? Ich denke nein.

Alles, bis auf Basissystem mittels cvsup auf neuen Stand zu bringen. Und da ich das hier wegen harten Taffic Limit nicht testen kann, frage ich halt!

Gruss, Jochen

 

[asg]

usr/ports/security/freebsd-update
This is the client half of the FreeBSD Update system; it fetches and
applies binary security updates.

WWW: http://www.daemonology.net/freebsd-update/

Evtl. ist das ja was. Ich habe es noch nicht ausprobiert...

 

[I.MC]

Original geschrieben von grunix
usr/ports/security/freebsd-update
This is the client half of the FreeBSD Update system; it fetches and
applies binary security updates.

WWW: http://www.daemonology.net/freebsd-update/

Evtl. ist das ja was. Ich habe es noch nicht ausprobiert...

Werde ich machen, wenn ich wieder frei von diesem blöden Traffic Limt hier bin, das nervt! Hier in Südafrika kostet das MB in der Uni momentan 16,6 Euro Cent. Unglaublich, aber wahr. Surfe schon ohne Grafiken, grummel.
Aber jetzt haste mich soch recht überzeugt, dass ich das fast gar nicht mehr will mit dem binary Kram :-)
Aber der einzige Vorteil von dem selber kompilieren ist doch jetzt dann eigentlich nur, dass das perfekt auf meine Maschine angepasst kompiliert wurde. Was bedeutet das genau?
Kompilieren nicht die meisten Programme z.B. unter jedem i386er System gleich? Bin nicht so der erfahrene Programmierer um da DEN Unterschied festzustellen... aber sehr neugierig :-)
Habe da immer noch die Frage, ob "bin" und "crypto" in cvsup und sysinstall gleich sind. Ich bin halt extrem geizig mit Festplattenplatz und will nicht unnötig Zeug installieren, was ich nicht brauche... auch wenn aufgrund der Namen ja wohl anzunehmen ist, dass die gleich sind.

Gruss, Jochen

 

[I.MC]

Re: Re: Re: Re: Genaue Erklärung des binary / src (cvsup, buildworld) update Verfahrens

Weil das nunmal der sauberere Weg ist. Weil es dann auf Deine Maschine passt.

Aber dann wäre es ja bei einer Erstinstallation mittels sysinstall nur vernünftig direkt danach die Sourcen zu ziehen und das System neu zu bauen, damit es genau auf mein System passt! Sonst hätte ich ja "nur" die vor kompilierten Binaries genutzt, oder nicht? Und sobald ich hardware austausche müsste ich dann um ganz sicher zu gehen wieder alles neu bauen... zumindest bei ganz relavanter Hardware wie Prozessor, Motherboard... aber was ist relavante Hardware, wo man das besser machen sollte und welche nicht? Das ist alles gar nicht schnell vom Tisch finde ich und das würde gerne wissen :-)

Gruss, Jochen

 

[asg]

Re: Re: Re: Re: Re: Genaue Erklärung des binary / src (cvsup, buildworld) update Verf

Aber dann wäre es ja bei einer Erstinstallation mittels sysinstall nur vernünftig direkt danach die Sourcen zu ziehen und das System neu zu bauen, damit es genau auf mein System passt!

Ja. Nein.
Etwas was durchkompiliert wurde, wie beispielsweise bei einem upgrade über die sourcen, ist sauberer, als wenn nur ein Teil der binaries instaliert werden.
Ich hatte, so glaube ich, schon auf die make.conf verwiesen. Schau Dir das an, hier kannst Du einige Paramter mitgeben, um den Code an Deine Maschine anzupassen.

Und sobald ich hardware austausche müsste ich dann um ganz sicher zu gehen wieder alles neu bauen... zumindest bei ganz relavanter Hardware wie Prozessor, Motherboard... aber was ist relavante Hardware, wo man das besser machen sollte und welche nicht? Das ist alles gar nicht schnell vom Tisch finde ich und das würde gerne wissen :-)

Na, wenn Du es wissen willst, dann denk doch einfach mal selbst, anstatt alles zu bezweifeln.
Dein obiges Szenario beispielsweise, da brauchst Du nicht das System neu zu bauen, sondern den Kernel evtl.. Je nachdem was für hardware eingebaut wird musst Du Deinem evtl. angepassten kernel diese noch mitteilen, sonst bootet das System nicht mehr, oder sie wird, was das geringste Übel ist, einfach nicht eingebunden. Aus diesem Grund ist es von Vorteil immer einen GENERIC Kernel auf dem system zu haben, neben dem angepassten Kernel an das eben agierende System. Falls wirklich mal die Hardware abraucht, Du andere einbaust, und diese nicht im Kernel drin ist, was dann? Dann kannst Du wenigstens erstmal den GENERIC Kernel booten und dann wieder einen eigenen erstellen.

Nochmals, ein cvsup und make world ist einfach die sauberere Lösung im Vergleich zu einem binary upgrade wie ich meine, da das System neu gebaut wird, und nicht nur Teile einfach ersetzt.

 

[I.MC]

Re: Re: Re: Re: Re: Re: Genaue Erklärung des binary / src (cvsup, buildworld) update Verf

Dein obiges Szenario beispielsweise, da brauchst Du nicht das System neu zu bauen, sondern den Kernel evtl..

Dann fällt für mir mich jetzt das Argument, dann ist das genau an deine Maschine angepasst, jetzt wieder flach. Wenn du sagst, ok, selbst wenn du den Prozessor ausstauscht evtl. gegen einen mit einer anderen Architektur (486er auf Pentium 4), dann brauchst du nur einen neuen Kernel zu backen. Sicher muss ich das, ist mir vollkommen klar. Aber wenn ich den Rest nicht mit neu baue, ist es doch in diesem Bsp. noch immer für den alten Prozze optimiert, nicht für den neuen. Mal abgesehen vom Kernel, der stimmt dann natürlich. Ich habe mir die make.conf leider noch nicht angesehen, aber da werde sicherlich interessante Optionen drin sein und evtl. klärt das ja einiges. Nur ich suche nach der Antwort ob es evtl. schon beim kompilieren an sich Unterschiede gibt unabhängig von der make.conf. Oder geht es wirklich "nur" um die Optionen in der make.conf??? Sprich wo da der Vorteil liegt, wenn ich das selber mache oder jemand anderes bei selber make.conf. Z.B. weil der Compiler des anderen etwas anders macht als mein eigener. Das scheint bis jetzt aber keine beantworten zu können. Evtl. auch falsche Ecke. Ich habe das mal in einer Programmier NG gepostet. Mal gucken...

Und zu dem upgrade nacht dem erstmaligen install mittels sysinstall. Also wenn man dann alles angepasst haben willst an sein System, muss man ja dann meiner Meinung nach direkt nen neues System bauen mit angepasster make.conf, genau, wie man sich halt seinen eigenen Kernel bauen muss (oder besser sollte)

Gruss, Jochen

 

[netbie]

Hallo,

ob die Binaerpakete, die du ueber sysinstall upgrade kannst deckungsgleich sind mit den verschiedenen Verzeichnissen in den Sourcen weiss ich leider nicht. Ich bin auch einer von denen, die FreeBSD seit Jahren nutzen, aber noch niemals ein binary upgrade gemacht haben Ich weiss das so etwas existiert, aber ehrlich gesagt kenne ich niemanden der es nutzt.
cvsup/make world ist eben der Koenigsweg um sein FreeBSD-System aktuell zu halten. Das hat auch den Vorteil, dass du dein System beliebig oft upgraden kannst und eben nicht nur im Abstand von mindestens einem Release. Wenn ich zum Beispiel auf der -stable Mailingliste lese, dass FreeBSD-stable einen bestimmten neuen Treiber bekommen hat der fuer mich interessant ist, dann kann ich ueber die Sourcen mein System sofort upgraden und muss nicht erst warten bis ein neues Release herausgekommen ist.
Ich habe schon sehr oft per cvsup/make world das System aktualisiert. Das geht einfacher (und schneller) als man vielleicht denkt. Was du upgradest kannst du ueber die Optionen in /etc/make.conf (man make.conf) steuern. Da kannst du zum Beispiel angeben, dass Sendmail nicht mitgebaut werden soll oder lpr (falls du cups verwendest) usw. Ein make buildworld dauert auf meinem Duron 800MHz (das ist fuer heutige Verhaeltnisse eine lahme Kruecke ) etwa eine Stunde fuer FreeBSD 4.x. FreeBSD 5.x dauert etwas laenger. Also das ist elles sehr unproblematisch.

Thomas

 

[Ripley8]

Re: Re: Re: Re: Re: Genaue Erklärung des binary / src (cvsup, buildworld) update Verf

Original geschrieben von incmc
Aber dann wäre es ja bei einer Erstinstallation mittels sysinstall nur vernünftig direkt danach die Sourcen zu ziehen und das System neu zu bauen, damit es genau auf mein System passt!

Das ist soweit ich es verstanden habe der Ansatz von Linux-Gentoo.
Da bootet man ein minimales System und fängt an, alles - und ich
meine dabei alles - aus den Quellcodes zu bauen.


In den meisten Fällen ist das, was den Usermode-Kram angeht,
ja nur eine Optimierungsfrage, d.h. aus der Maschine wird durch
optimale Anpassung an die CPU und Chipsatz noch ein Mikro mehr
an Performance rausgekitzelt. Wenn man das aufs Maximum hochdreht,
dann geht das irgendwann auf Kosten der Allgemeingültigkeit,
d.h. man kommt zu einem System, das auf einem anderen Rechner
nicht läuft.
Einfachstes Beispiel dazu sind Systeme, die mit Pentium-Opcodes
übersetzt sind, die dann auf einem 586er nicht laufen, weil der
halt die neuen Maschinencodes nicht kennt. Oder die früher
mal sehr relevante Frage nach der FPU.

Ich übersetze bei mir den Code nicht unbedingt so sehr wegen
maximaler Performance (maximale Stabilität ist mir da schon eher wichtig ),
sondern weil bestimmte Kompatibilitäts-Probleme dadurch vermieden
werden können, dass z.B. immer dieselben Compiler-Optionen oder
Compiler-Versionen genommen werden.
Oder die Frage, ob etwas mit X11-Support gebaut wird, oder nicht.
Oder Bibliotheks-Abhängigkeiten, die da lauten Bla-Lib Version
3.x und auf die genaue Version hinter dem Komma kommt es
nicht an, aber wenn ein fertiges Binär-Paket mit 3.1 und ein anderes
mit 3.2 übersetzt wurde, dann knirscht es.

 

[I.MC]

cvsup/make world ist eben der Koenigsweg um sein FreeBSD-System aktuell zu halten. Das hat auch den Vorteil, dass du dein System beliebig oft upgraden kannst und eben nicht nur im Abstand von mindestens einem Release. Wenn ich zum Beispiel auf der -stable Mailingliste lese, dass FreeBSD-stable einen bestimmten neuen Treiber bekommen hat der fuer mich interessant ist, dann kann ich ueber die Sourcen mein System sofort upgraden und muss nicht erst warten bis ein neues Release herausgekommen ist.

Mmh, ok. Das ist ein Argument. Jedoch wenn ich unter sysinstall eintrage, V. 4.8, dann wird der ja auch das aktuellste hohlen, also auch z.B. die neuesten Treiber.

Was du upgradest kannst du ueber die Optionen in /etc/make.conf (man make.conf) steuern. Da kannst du zum Beispiel angeben, dass Sendmail nicht mitgebaut werden soll oder lpr (falls du cups verwendest) usw.

Das ist gut, habe mal die make.conf ganz flink überflogen.

Ein make buildworld dauert auf meinem Duron 800MHz (das ist fuer heutige Verhaeltnisse eine lahme Kruecke ) etwa eine Stunde fuer FreeBSD 4.x. FreeBSD 5.x dauert etwas laenger. Also das ist elles sehr unproblematisch.

Ja, das stimmt. Nur für alte Rechner, also P1 Ära schon doof, auch wenn man die meist nur als Router noch sieht und die eh ewig rennen und daher ja auch ewig Zeit haben zum kompilieren :-)

Es wurde hier halt nur immer gesagt, dass das selber kompilieren Vorteile hätte, weil es dann besser auf mein System abgestimmt ist. Wird damit jetzt "nur" die make.conf Einstellerei gemeint, also dass ich präziser sagen kann was ich in meinem System haben möchte oder gibt es da noch ein stärkeres Argument wie, selber kompiliert ist nachher effizienter, weil genau auf meinen Prozessor etc. agestimmt?!?!?!?!?! DAS wäre ein zweites gutes Argument!

Versteht mich nicht falsch, aber ich sehe bis jetzt dann als einziges Argument nur, dass ich durch die make.conf dann präziser steuern kann, was ich auf meinen System haben möchte und was nicht. Das war´s im Vgl. zu binary update ...
Als Gegenargument steht dann dort, dass ältere Maschinen ewig kompilieren müssen.

Also, was gibt es noch an Vorteilen? Gut, ich kann einzelne Teile zischendurch einzeln updaten, wenn ich weiss, dass nur dieser Bereich betroffen war, wie z.B. die letzten sendmail bugs. Mit der Konsequenz, dass das ich Verzahnung riskiere, weil dann ja nicht mehr "aus einem Guß", also besser gleich das ganze System neu bauen oder nen patch nutzen. Denn laut Handbuch "kann" das ja sonst in die Hose gehen... sprich das ist schon wieder kein Vorteil in meinen Augen, weil ich das wiederrum auch per binary machen kann (also alles updaten)

Gruss, Jochen

 

[I.MC]

Re: Re: Re: Re: Re: Re: Genaue Erklärung des binary / src (cvsup, buildworld) update Verf

Das ist soweit ich es verstanden habe der Ansatz von Linux-Gentoo.Da bootet man ein minimales System und fängt an, alles - und ich meine dabei alles - aus den Quellcodes zu bauen.

OK, aber es wäre dann die einzige logsiche Konsequenz für mich, mein System nachdem ich es mittels sysinstall zum ersten mal aufgezogen habe, direkt noch einmal selber neu zubauen, um halt auch sicher zu gehen, dass auch alles mit selben compiler (was du unten sagtest) etc. kompiliert wurde, eben mit meinem momentanen. Wenn ich dann nur das binary Zeug nutze, wäre es ja nicht 100% tig sicher. Auch wenn man wohl meistens davon ausgehen können sollte, dass die Leute es mit den Versionen der Distri kompiliert haben, auf der es rauskommt. Aber da haste recht mit, DAS ist ein Argument.

Einfachstes Beispiel dazu sind Systeme, die mit Pentium-Opcodes
übersetzt sind, die dann auf einem 586er nicht laufen, weil der
halt die neuen Maschinencodes nicht kennt. Oder die früher
mal sehr relevante Frage nach der FPU.

So weit kann das gehen wenn man mittels make.conf Einstellungen? Also ähnlich der CPU Opt. in der Kernel Config?

Gruss, Jochen

 

[asg]

Versteht mich nicht falsch, aber ich sehe bis jetzt dann als einziges Argument nur, dass ich durch die make.conf dann präziser steuern kann, was ich auf meinen System haben möchte und was nicht. Das war´s im Vgl. zu binary update ...
Als Gegenargument steht dann dort, dass ältere Maschinen ewig kompilieren müssen.

Da ich keine sonderliche Lust verspüre mich im Kreise zu drehen, und das ist bei dieser "Diskussion" nun erreicht, es dreht sich im Kreise.
Warum nimmst Du denn nicht einfach das binary upgrade? Wenn Du für DICH darin nur Vorteile siehst, dann nimm es, es möchte Dir ja keiner Ausreden. Wie schon erwähnt wurde, ist der sog. Königsweg eben "make world" aus den Sourcen (auch ist die Aktualität dort eher gegeben als bei binary upgrades).
"Argument" - "Gegenargument"? Es gibt zwei Wege, der eine ist der richtige, der andere ist der "richtigere". Wähle einen aus, denn DU meinst nehmen zu wollen/müssen/dürfen.

Also, was gibt es noch an Vorteilen? Gut, ich kann einzelne Teile zischendurch einzeln updaten, wenn ich weiss, dass nur dieser Bereich betroffen war, wie z.B. die letzten sendmail bugs. Mit der Konsequenz, dass das ich Verzahnung riskiere, weil dann ja nicht mehr "aus einem Guß", also besser gleich das ganze System neu bauen oder nen patch nutzen. Denn laut Handbuch "kann" das ja sonst in die Hose gehen... sprich das ist schon wieder kein Vorteil in meinen Augen, weil ich das wiederrum auch per binary machen kann (also alles updaten)

Wer liefert Dir denn die binaries sofort?
Ich weiss nun wirklich nicht wie aktuell diese sind, bzw. wer aus den sourcen gleich die binaries bereitstellt.
Ich frage mich wirklich was Dein Problem mit "make world" ist. Oder eine patch aus den sourcen einzuspielen? WO ist da das Problem? Das ist eine Frage die noch nicht geklärt wurde, um Deine Sprachwahl zu nutzen.
Wie ich schon sagte, das läuft so nebenher. Wenn ich nun einen cvsuplauf mache, dann ist der in < 1 Minute durch, und die übetragenen Daten sind veschwindend gering. Und es ist ja nicht so, dass ich nach jedem cvsup lauf ein "make world" mache, machen muss.

Und noch was. Die installierten Programme (packages/ports) dürften öfters von Sicherheitslücken oder einfach nur updates betroffen sein als das System an sich. Naja, je nachdem was man installiert hat. Wie willst Du es da machen?
Jedesmal das neuste binary ziehen (was aber etwas dauern kann bis es bereit steht), oder doch lieber die sourcen nutzen und einen neuen build von postfix oder whatever anwerfen? Oder einfach den patch in die vorhandenen sourcen und diese neu durchkompilieren. Das wird dann Dein nächstes Problem, nicht wahr?
In meinem Portstree kann ich täglich mehr updaten als auf dem system, daher verstehe ich wirklich nicht Dein Problem mit dem make world. Du musst es ja nicht jede Woche/Monat machen.

 

[I.MC]

Da ich keine sonderliche Lust verspüre mich im Kreise zu drehen, und das ist bei dieser "Diskussion" nun erreicht, es dreht sich im Kreise.
Warum nimmst Du denn nicht einfach das binary upgrade? Wenn Du für DICH darin nur Vorteile siehst, dann nimm es, es möchte Dir ja keiner Ausreden. Wie schon erwähnt wurde, ist der sog. Königsweg eben "make world" aus den Sourcen (auch ist die Aktualität dort eher gegeben als bei binary upgrades).
"Argument" - "Gegenargument"? Es gibt zwei Wege, der eine ist der richtige, der andere ist der "richtigere". Wähle einen aus, denn DU meinst nehmen zu wollen/müssen/dürfen.

....

Wer liefert Dir denn die binaries sofort?
Ich weiss nun wirklich nicht wie aktuell diese sind, bzw. wer aus den sourcen gleich die binaries bereitstellt.
Ich frage mich wirklich was Dein Problem mit "make world" ist. Oder eine patch aus den sourcen einzuspielen? WO ist da das Problem?

Jaaa, endlich wieder ein echtes Argument, danke.

Fände es Klasse, wenn du einfach nur die Fragen beantworten würdest, was du ja anscheinend durchaus kannst. Immer dieses an einander vorbei lesen. Ich habe kein Problem mit cvsup etc. ws ich auch schon gesagt habe, oder auch nicht in die Welt gesetzt habe. Ich möchte schlicht und ergreifend NUR versthehen, wo der genau Unterschied, bzw. die Vorteile des Systems seihen sollen! Und sorry, wenn da dann Antworten kommen, das is so, weil es dann halt alles aus einem Guss ist, also isses besser das zu kompilieren und das machen 98% so, dann ist das für mich einfach kein Argument. Und wie man sieht kommen ja langsam endlich mal die Antworten auf die ich warte, nämlich WO ist der Vorteil und das mal mit präziserer Erklärung, wie von Ripley8. Mehr wollte und will ich nicht. Ich weiss nicht "WO ist das Problem" um es mal mit deinen Worten zu sagen???
Und da brauche ich keine 5 km Romane mit ja so geht das mit Kernel backen wie man cvsup benutzt, dass ich mal selber denken soll und du dann mir was erzählst, was dir selber permanent widerspricht. Erst heisst es. z.B. ja, da kompilieren macht man, weil es dann genau auf dein System angepasst ist (ohne weitere Präzisierung), dann isses aber ok, mal die Prozze Architektur zu wechseln und nur den Kernel anzupassen ohne nen Neubau. Soviel zu aus einem Guss dachte ich mir da, weil ich es vorher halt selbst von dir vorgebetet bekommen habe, meine Güte. Wenn ich ne Frage stelle, dann nicht ohne Grund. Tut mir ja leid, wenn ich es noch nicht besser weiss, aber du machst es einem nicht gerade immer leicht.
Ich finde es dreht sich wirklich nicht wegen mir im Kreis da ja z.B. Ripley und du gerade auch endlich mal gute Argumente bringen. Ich wusste nicht, dass die scr Dinger aktueller sind, sorry und war auch leider nicht bei der Entwicklung von FreeBSD dabei um zu wissen, wieso man sich für den kompilierweg entschieden hat. Und ich frage so lange weiter bis ich zufrieden bin, sprich weiss wo genau Vor- und Nachteile sind und wenn mir dann halt Antworten nur zu Teilfragen gegeben werden, ok, frage ich nochmal. Dafür ist ein Forum wohl da.
Sorry dass ich jetzt auch mal emotional werde. Wahrscheinlich ist das jetzt wieder alles Quatsch was ich hier erzählt habe und ich werde gleich wieder als der halbe Vollidiot hingestellt von dir.
Also ich würde mich weiterhin über jedes genau Argument freuen wieso selber bauen des Basissystems besser ist als der andere Weg und ich auch bin nicht an ports Fragen interessiert in diesem Thread :-(

Danke und Gruss, Jochen

 

[asg]

Original geschrieben von incmc
Fände es Klasse, wenn du einfach nur die Fragen beantworten würdest, was du ja anscheinend durchaus kannst.

Sender-Empfänger Problem. Stelle Deine Fragen präzise und spreche nicht immer von "Argumenten".

Immer dieses an einander vorbei lesen. Ich habe kein Problem mit cvsup etc. ws ich auch schon gesagt habe, oder auch nicht in die Welt gesetzt habe.

Nunja, in Deinen posts kommt es mir aber doch so vor das Du ein Problem mit cvsup und make world hast.
Deine herangehensweise an eine Frage ist nicht unbedingt der Stil den man erwartet von einem Fragestellt. Seis drum.

Und sorry, wenn da dann Antworten kommen, das is so, weil es dann halt alles aus einem Guss ist, also isses besser das zu kompilieren und das machen 98% so, dann ist das für mich einfach kein Argument. Und wie man sieht kommen ja langsam endlich mal die Antworten auf die ich warte, nämlich WO ist der Vorteil und das mal mit präziserer Erklärung, wie von Ripley8.

Dann solltest Du Dich einmal darüber informieren. Dazu gibt es Lektüre noch und nöcher. Alles unter www.google.com zu finden ;-).

Und da brauche ich keine 5 km Romane mit ja so geht das mit Kernel backen wie man cvsup benutzt, dass ich mal selber denken soll und du dann mir was erzählst, was dir selber permanent widerspricht.

Du machst den Eindruck das Du nichts weisst. Daher die Ausführungen.

Erst heisst es. z.B. ja, da kompilieren macht man, weil es dann genau auf dein System angepasst ist (ohne weitere Präzisierung), dann isses aber ok, mal die Prozze Architektur zu wechseln und nur den Kernel anzupassen ohne nen Neubau. Soviel zu aus einem Guss dachte ich mir da, weil ich es vorher halt selbst von dir vorgebetet bekommen habe, meine Güte. Wenn ich ne Frage stelle, dann nicht ohne Grund.

Ohne Grund nicht aber...

Ich wusste nicht, dass die scr Dinger aktueller sind, sorry und war auch leider nicht bei der Entwicklung von FreeBSD dabei um zu wissen, wieso man sich für den kompilierweg entschieden hat.

...aber ohne Wissen wie mir scheint (was nicht böse gemeint ist).
Mensch, das ist doch sowas von ersichtlich. Natürlich sind die sourcen aktueller, ohne source kein binary, das sagt doch schon die Logik. Das erwarte ich wenigstens wenn ich sage "denk selber".
Auch solltest Du wissen das wenn Du cvsup nutzen kannst, es einen CVS Server gibt auf dem immer das neuste drauf ist, das es versch. branches gibt. Allein dieses Wissen sagt Dir "source sind aktueller als binary code". Nimm die ports. Meistens sind die ports schon da, aber noch keine packages. Warum? Weil die ports die sourcen ziehen, die packages aber vorkompilierte binaries sind.
Auch da hätte es "klick" machen müssen. Das muss man doch nicht wirklich immer alles erzählen.
Oder?
Wo also soll ich dann ansetzen? Wieviel weiss derjenige schon, wieviel nicht,...

Und ich frage so lange weiter bis ich zufrieden bin, sprich weiss wo genau Vor- und Nachteile sind und wenn mir dann halt Antworten nur zu Teilfragen gegeben werden, ok, frage ich nochmal. Dafür ist ein Forum wohl da.

Es ist doch aber nicht dazu da alles bis ins kleinste vorzukauen, oder? ;-)

Sorry dass ich jetzt auch mal emotional
werde. Wahrscheinlich ist das jetzt wieder alles Quatsch was ich hier erzählt habe und ich werde gleich wieder als der halbe Vollidiot hingestellt von dir.

Hehe, ich lese Dein post und antworte darauf. Also könntest Du bei obigen Zeilen denken, das ich meine Du seist ein "Vollxxxx". Du kannst das denken, ist aber nicht meine Meinung.

Also ich würde mich weiterhin über jedes genau Argument freuen wieso selber bauen des Basissystems besser ist als der andere Weg und ich auch bin nicht an ports Fragen interessiert in diesem Thread :-(

Was denn noch? sourcen sind aktueller. binary nicht so. Reicht das nicht? Was die Erwähnungen der ports angehen, so ist das ein GLeichnis, nicht mehr, nicht weniger.

 

[I.MC]

Sender-Empfänger Problem. Stelle Deine Fragen präzise und spreche nicht immer von "Argumenten".

Also, das wird mir jetzt zu blöde. Du stehst anscheind tierisch drauf das letzte Wort haben zu müssen, sei´s drum.
Wenn dir das Wort nicht gefällt, mir sehr gut. Du schreibst dafür jedes zweite Wort upper case, hehe.

Deine herangehensweise an eine Frage ist nicht unbedingt der Stil den man erwartet von einem Fragestellt. Seis drum.

Guck dir mal deine Antworten an, die sind teilweise so an den Fragen vorbei, ach näää....

Dann solltest Du Dich einmal darüber informieren. Dazu gibt es Lektüre noch und nöcher. Alles unter www.google.com zu finden ;-).

Sag ich doch, musst das letzte Wort haben. Ich muss leider noch irgenwann arbeiten und nicht immer die Zeit alles nachzulesen.
Nach DEM Argument brächte man die meisten NGs nicht mehr, weil man theoretisch durch lesen und denken am die meisten Dinge alleine kommen würde. Man man...

Du machst den Eindruck das Du nichts weisst. Daher die Ausführungen.

Und du den Eindruck nicht richtig Fragen zu lesen bzw. gerne selber was anderes herein zu interpretieren :-)

sourcen aktueller, ohne source kein binary, das sagt doch schon die Logik. Das erwarte ich wenigstens wenn ich sage "denk selber".

Und? Es hätte ja genauso sein, dass die Jungs immer sofort mit kompilieren und das binary auffen Server legen und nicht nur erst die src!?!?

Wo also soll ich dann ansetzen? Wieviel weiss derjenige schon, wieviel nicht,...

Ja ja schon ok, aber manchmal sitzt man hier und fragt sich wieso du nicht einfach nur meine dummen Fragen beantwortest anstatt abzuschweifen.

Es ist doch aber nicht dazu da alles bis ins kleinste vorzukauen, oder? ;-)

Sicher nicht, aber die Fragen beantworten :-)

Was denn noch? sourcen sind aktueller. binary nicht so. Reicht das nicht? Was die Erwähnungen der ports angehen, so ist das ein GLeichnis, nicht mehr, nicht weniger. [/B]

[/QUOTE]
Das weiss ich ja eben nicht, vielleicht ist da ja noch was???
Z.B. würde ich jetzt immer noch sobald ich ne bedeutende Komponente austaschen alles neu bauen und nicht nur den Kernel, weil des Gusses halber. Würde mich sehr interssieren :-)

Peace :-)

Feierabend...

 

[asg]

[QUOTE[Also, das wird mir jetzt zu blöde. Du stehst anscheind tierisch drauf das letzte Wort haben zu müssen, sei´s drum.
Wenn dir das Wort nicht gefällt, mir sehr gut. Du schreibst dafür jedes zweite Wort upper case, hehe.
[/QUOTE]

Wir das nun ein bashing?

Guck dir mal deine Antworten an, die sind teilweise so an den Fragen vorbei, ach näää....

Ich sagte doch, Sender-Empfänger Problem...

Sag ich doch, musst das letzte Wort haben. Ich muss leider noch irgenwann arbeiten und nicht immer die Zeit alles nachzulesen.
Nach DEM Argument brächte man die meisten NGs nicht mehr, weil man theoretisch durch lesen und denken am die meisten Dinge alleine kommen würde. Man man...

Andere müssen auch irgendwann arbeiten und können nicht immer alles bis ins kleinste erklären, so rum wird auch ein Schuh draus. Und da Du etwas wissen willst, musst Du im Notfall nach suchen, oder?
Nach diesem, Deinen, Argument, wäre das hier ein Support, und kein Forum ;-).
Aber wurscht.
Belassen wir es dabei und konzentrieren uns wieder aufs wesentliche.

Und? Es hätte ja genauso sein, dass die Jungs immer sofort mit kompilieren und das binary auffen Server legen und nicht nur erst die src!?!?

Wäre das aber nicht reichlich unlogisch? Zumindest für mein Verständnis.
Wenn ich schon ein RELEASE am laufen habe, dadurch das ich die sourcen ziehe und compiliere, wartet man immer noch auf die ISOs. So ist es dann auch mit patches und binary upgrades, nach meinem Verständnis.
Zumal wirklich die meisten die sourcen ziehen, und die wenigsten binary code.

Das weiss ich ja eben nicht, vielleicht ist da ja noch was???
Z.B. würde ich jetzt immer noch sobald ich ne bedeutende Komponente austaschen alles neu bauen und nicht nur den Kernel, weil des Gusses halber. Würde mich sehr interssieren :-)

Du kannst, und sonst würde es binary upgrade nicht geben, auch ein solches upgrade machen. Ja. Wo also ist die Frage?
Ich, und ein Haufen anderer lassen eben gerne ein make world rennen, da es für mich die sinnigere Methode ist, oder ich spiele einen patch aus den sourcen ein, und kopiliere das Programm neu.
Man _kann_ auch die binaries nehmen, sicher, wenn es dazu eine wirkliche veranlassung gibt. Und da sind wir wieder bei meinem ersten post, ich sehe nur einen Grund, keinen Netzanschluss zu haben. Wobei man für ein binary upgrade ohne CDs auch einen braucht...
Oder, Grund 2, wie von Dir erwähnt, wenn Dir das ziehen der sourcen zuviel jostet, wobei Du die binaries ja auch ziehen musst, also auch kein Grund, ausser Du machst das über CD.

 

[I.MC]

Ich gebe es auf, du liest einfach nicht.

Du kannst, und sonst würde es binary upgrade nicht geben, auch ein solches upgrade machen. Ja. Wo also ist die Frage?

Wo habe ich denn jetzt wieder was von binary upgraden gesagt, es ging um Austausch von Hardware und deine Aussage, da müsse man nur den Kernel evtl anpassen, was ein paar Postings vorher angesprochen wurde. Ich frage mich halt immer noch, ob wenn ich gravierende Hardware ändere wie Prozessor, ob dann nicht ein kompletter Neubau des Systems besser wäre um den Rest ausser dem kernel auch an diese Veränderung anzupassen. Oder ob man nun wirklich nur den Kernel evtl. updaten damit das System wieder läuft. Sprich, ob der Rest des Systems nicht geupdatet werden muss weil diese nichts mit der Hardware zu tun hat.

Fasse ich also zusammen:

Vorteile selber bauen:

1) Detaillierte Anpassung möglich durch make.conf
2) Vermeidung von Kompatibilitätsproblemen weil selbe Libaries, was aber auch bei den binaries so sein sollte, weil sonst ja Probleme mit den binary Installationen vordefiniert wären (Also wager Vorteil)
3) Einzelinstallationen von Paketen möglich, kann aber in die Hose gehen laut Handbuch (Also wager Vorteil)
4) Quellcodes minimal aktueller als binaries

Nachteile selber bauen:

1) Auf langsamen Rechnern dauert es ewig

Vorteile binary update

1) Auf langsamen Rechner deutlich schneller. Geht bei Erstinstallation nicht anders (oder?)

Gruss, incmc

 

[asg]

Original geschrieben von incmc
Ich gebe es auf, du liest einfach nicht.

Also doch bashing?
Zitat: "Belassen wir es dabei und konzentrieren uns wieder aufs wesentliche."
Was habe ich damit wohl gemeint? Ich wollte wieder auf Deine eigentlich Frage bezüglich binary ja oder nein, warum wieso weshalb eingehen. Anscheinend ist Dir dies aber nicht mehr so wichtig.
Da ich keine sonderliche Lust habe auf ein naives bashing, belasse ich es hiermit und konzentriere mich wiederum auf das wesentliche.

Austausch von Hardware und deine Aussage, da müsse man nur den Kernel evtl anpassen, was ein paar Postings vorher angesprochen wurde.

Das habe ich schon erklärt. Aber gerne nochmals und für Dich auch noch genauer.

Ich frage mich halt immer noch, ob wenn ich gravierende Hardware ändere wie Prozessor, ob dann nicht ein kompletter Neubau des Systems besser wäre um den Rest ausser dem kernel auch an diese Veränderung anzupassen. Oder ob man nun wirklich nur den Kernel evtl. updaten damit das System wieder läuft. Sprich, ob der Rest des Systems nicht geupdatet werden muss weil diese nichts mit der Hardware zu tun hat.

Wenn Du Teile der hardware rausreisst, kannst Du ein Problem bekommen, mit dem Kernel. Weniger mit dem System (alles ausser dem Kernel).
Beispiel: Mein SCSI Controll raucht ab. Jetzt habe ich nicht den gleichen zur Hand, sondern einen anderen von einer anderen Firma, der einen anderen Treiber braucht, eine andere Kenelunterstützung.
Ich habe meinen Kernel aber so angepasst, dass alles überflüssige, was ich für mein bestehendes System (hardware) nicht brauche, draussen ist. Was passiert wenn ich nun mit dem Kernel versuche zu booten? Wahlweise kannst Du andere Hardware Komponenten nehmen die das booten dann unmöglich machen würden, worst case, oder einfach nur die hardware dann nicht ansprechen.
In einem solchen fall ist es gut einen GENERIC Kernel irgendwo rumliegen zu haben, diesen kann ich dann booten, da in diesem die hardware aller Wahrscheinlichkeit drin sein sollte.
Danach kann ich meine alte kernelconf nehmen, und einfach den Eintrag für die neue hardware hinzufügen und den kernel neu bauen.
Danach habe ich wieder meinen alten/neuen schlanken kernel.

1) Detaillierte Anpassung möglich durch make.conf
2) Vermeidung von Kompatibilitätsproblemen weil selbe Libaries, was aber auch bei den binaries so sein sollte, weil sonst ja Probleme mit den binary Installationen vordefiniert wären (Also wager Vorteil)
3) Einzelinstallationen von Paketen möglich, kann aber in die Hose gehen laut Handbuch (Also wager Vorteil)
4) Quellcodes minimal aktueller als binaries

Sourcen sollten immer aktueller sein. Wohl wahr.
ok

1) Auf langsamen Rechnern dauert es ewig

Stimmt, was aber nicht weiter stören sollte da es ja im Hintergrund maschieren kann.

 

[I.MC]

Original geschrieben von grunix
Also doch bashing?
Da ich keine sonderliche Lust habe auf ein naives bashing, belasse ich es hiermit und konzentriere mich wiederum auf das wesentliche.

Gerne, nur habe ich damit nicht angefangen :-)


Aber mit der Frage meinte ich das anders, kam am Ende der Frage nicht richtig rüber. Ich meinte hauptsächlich den ersten Teil der Frage. Mir ist klar, dass und wie ich den Kernel kompilieren muss, was ich auch schon erwähnt hatte. Nur weil hier ja auch von performance Optimierung geredet wurde und davon dass alles dann besser auf mein System angepasst wurde, frage ich mich, würde der Rest des Systems nicht besser / Stabiler laufen, wenn er auch neu übersetzt würde? Zumindest bei solchen Kernelementen wie dem Prozessor? Oder ist so Hardware Kram nur mit Kernel anpassen erledigt / ist der Rest des Systems nicht für Hardware Angelegeneiten zuständig?

Gruss, Jochen

 

[asg]

Aber mit der Frage meinte ich das anders, kam am Ende der Frage nicht richtig rüber. Ich meinte hauptsächlich den ersten Teil der Frage. Mir ist klar, dass und wie ich den Kernel kompilieren muss, was ich auch schon erwähnt hatte. Nur weil hier ja auch von performance Optimierung geredet wurde und davon dass alles dann besser auf mein System angepasst wurde, frage ich mich, würde der Rest des Systems nicht besser / Stabiler laufen, wenn er auch neu übersetzt würde? Zumindest bei solchen Kernelementen wie dem Prozessor? Oder ist so Hardware Kram nur mit Kernel anpassen erledigt / ist der Rest des Systems nicht für Hardware Angelegeneiten zuständig?

Um Deine hardware anzusprechen ist der Kernel da (und Module) kann man im groben sagen, bzw. in diesem Fall ist es so. Ohne Kernelunterstützung für die und die hardware, keine hardware zur Verfügung.
Wenn Du in der make.conf die Programme oder das System mit Optimierung kompiliert hast, so sollte das alles trotzdem rennen, ausser eben diese optimierung. in wie weit man da noch eingreifen kann, das man es CPU spezifisch macht und es dann nur mit dieser CPU rennt, weiss ich nicht.

 

[I.MC]

Cool, danke!! Jetzt finde ich ist ziemlich alles klar!
Und danke auch für die Geduld :-)

Gruss, Jochen