FreeBSD auf dem Desktop von einem Einsteiger, für Einsteiger/-innen

[pit234a]

Der Start von x mißlingt und bricht wegen falscher Konfiguration ab. da bleibe ich dann doch bei der /etc/xorg.conf, das hat ja funktioniert

Das ist mir auch immer so ergangen. Wir Alten taugen wohl nicht für alle neue Technik.
Die xorg.conf ist nach wie vor gültig und es ist keine technische Frage, sondern hängt mit der Meinung von einem sauberen System zusammen, wo und wie X konfiguriert sein soll. Man möchte möglichst gut die FSH umsetzen und X gehört nunmal nicht zum System und deshalb sollte es nicht unter /etc konfiguriert werden. Auch die Position der xorg.conf wurde in dem Zusammenhang schon häufiger diskutiert, sie muss ja nicht unter /etc/X11 liegen, sondern das ist nur ein Ort, wo nach ihr gesucht wird.

/etc/login.conf ändern

Ebenfalls aus meinen Aufzeichnungen, wobai ISO... natürlich durch UTF oder die passende Einstellung ersetzt werden kann:
Beispiel /etc/login.conf modifizieren

german|German Users Accounts:\
        :charset=ISO-8859-15:\
        :lang=de_DE.ISO8859-15:\
        :tc=default:

/etc/login.conf.db anlegen:
Code:

cap_mkdb /etc/login.conf

german in /etc/master.passwd
/etc/master.passwd mit vipw*

....
pit:$1$ZQy8cjlU$otNcIcr1NfPN5i7bnn.sY.:1001:0:german:0:0:user name:/home/pit:/bin/tcsh
....

*vipw ist Pflicht. Aber, weil ich das nie bedienen kann, ändere ich meist zuvor mit ee und rufe dann nur mit vipw auf und speichere das neu ab. Das legt dann ebenfalls die entsprechende Binary an.

 

[ralli]

Danke @pit234a für Deine Unterstützung. Werde das demnächst umsetzen. Auch werde ich mal abwarten, was Holger noch herausgefunden hat. Zwischendurch muß ich auch noch ein bißchen produktiv arbeiten.

 

[holgerw]

Hallo,

das Tastaturlayout stellt man, wie im Wiki von Arch beschrieben, in der /usr/local/share/config/kdm/Xsetup um, der Eintrag lautet:

setxkbmap de

Ein Restart von KDM reicht, ein Reboot ist nicht erforderlich.

Eine Aktualisierung von KDE4 überschreibt vermutlich diese Datei wieder, es wäre ja lustig, wenn man den Arch Tipp mit der Modifikation der /etc/pacman.conf in die FreeBSD.conf übernehmen könnte. Das werde ich auch noch testen.

Viele Grüße,
Holger

 

[ralli]

Hallo Holger,

hurra es funktioniert, das (hoffentlicht) letzte Geheimnis ist gelöst. Das der Behl sexkbmap de dafür erforderlich ist, war mir bewußt, deswegen hatte ich ihn ja auch bei der manuellen Konfiguration in der .xinitrc berücksichtigt. Nur für KDM wo unterbringen, das wußte ich nicht. Sehr gut, allerdings ist dann auch jedes FreeBSD Wiki, was die KDE Installation behandelt und auch im FreeBSD Handbuch nicht vollständig, weil ich natürlich dort auch gesucht und es nirgendwo gefunden habe. Danke für Deine Beharrlichkeit, wir profitieren ja alle davon.

Viele Grüße

Ralph

 

[holgerw]

Hallo,

Update: Korrektes Setzen des Tastaturlayouts für KDM, GDM und Konsorten

Die Arch-Lösung, die /usr/local/share/kdm/Xsetup zu modifizieren, ist ein wenig unelegant, weil bei einem KDE4 Update diese Datei überschrieben wird. Besser ist folgendes, und das greift dann auch noch, wenn man den Loginmanager wechselt:
Anlegen einer /usr/local/etc/X11/xorg.conf.d/input.conf mit folgendem Inhalt

Section "InputClass"
    Identifier      "Keyboard defaults"
    Driver          "keyboard"
    MatchIsKeyboard "on"
    Option          "XkbLayout" "de"
    Option          "XkbVariant" "nodeadkeys"
EndSection

Vgl. dazu http://www.bsdforen.de/threads/conf...dem-Überschreiben-schützen.32830/#post-283744
Danke an @lme für den Hinweis.

Viele Grüße,
Holger

 

[Elwood]

*vipw ist Pflicht. Aber, weil ich das nie bedienen kann, ändere ich meist zuvor mit ee und rufe dann nur mit vipw auf und speichere das neu ab. Das legt dann ebenfalls die entsprechende Binary an.

Setz doch EDITOR=ee, dann hast du einen bedienbaren Editor in vipw

 

[Vril]

@Holger

toll, dass Du so viel Energie und Arbeit in die Doku steckst.
Gerade für uns Anfänger ist so ein Leitfaden eine tolle Übersicht.

Allerdings ist mir der Punkt mit dem Editor "Nano" aufgefallen.
Ich denke, im unixoiden Umfeld ist einfach "wi ei", also vi und dessen Nachfolger (vim) Pflicht.
Natürlich ist das Teil anfangs mehr als kryptisch und wirkt anfangs so verstörend wie
Bilder von Hieronymus Bosch auf den ersten Blick;-)

Aber ich finde, dass gerade Anfäger diesen Dornenweg gehen sollten...
denn später werden sie selbst im Windows-Umfeld lächeln ( da gibt es nämlich gvim),
wenn der Kollege mit notepad++ oder dergleichen in einem
Textfile mit Zeilenanzahl im hohen 6-stelligen Bereich "suchen und ersetzen" probiert...
und letztendlich doch nicht so wirklich zum Ziel kommt, was aber auch nicht schlimm ist,
weil die App dann eh im Windows-Nirwana landet. -
während man mit Basics in vi und regex längst fertig ist

Gruss walter

 

[pit234a]

Setz doch EDITOR=ee, dann hast du einen bedienbaren Editor in vipw

Danke für den Rat, aber das habe ich schon so:

env | grep -i editor
EDITOR=/usr/bin/ee

Scheinbar ist mir gar nicht aufgefallen, dass ich damit ee in vipw habe. Naja, das braucht man ja auch selten.

Anlegen einer /usr/local/etc/X11/xorg.conf.d/input.conf

ich möchte das nur kurz nochmal aufgreifen, denn das ist nun eine FreeBSD-Lösung. Die gleichen oder ganz ähnliche Probleme hatte ich aber bei meinem Streifzug mit Ubuntu ebenfalls und auch dort war es mir klar, dass die Tastatur in der xorg.conf gesetzt werden muss und das schaffte auch Abhilfe.
Deshalb, weil ich altmodisch bin, aber auch, weil es für beinahe alle Systeme gilt, in denen ich bisher etwas gearbeitet habe: es spricht nichts gegen eine /etc/X11/xorg.conf, die dann auch mal einfach von einem System zum nächsten migriert werden kann. Gerade derartige Einstellungen sind es, die Zeit kosten. Das System ist Ratz-Fatz installiert, aber dann daran erinnern, was überall gesetzt werden muss, um es auch auf den Punkt zu bringen, das war mir eine Hürde beim Umstieg von FreeBSD8.4 zu 10.x, die mir lange Zeit zu mächtig erschien.
Wenn ich aufpasse, kann ich heute einen ziemlich fliegenden Wechsel zwischen einem FreeBSD und einem GNU/Linux vornehmen, weil ich die meisten der Konfigurationen einfach übernehmen kann. Mein Desktop verhält sich unter FreeBSD genau gleich zu einem Ubuntu.
Das ist sicher keine allgemeingültige Anforderung. Es sollte aber vielleicht nochmal erwähnt werden. In keinem System habe ich bisher wirklich auf eine xorg.conf verzichtet, verzichten können.

 

[holgerw]

toll, dass Du so viel Energie und Arbeit in die Doku steckst.
Gerade für uns Anfänger ist so ein Leitfaden eine tolle Übersicht.

Allerdings ist mir der Punkt mit dem Editor "Nano" aufgefallen.

Hallo @Vril,
da sage ich doch zunächst mal "Vielen Dank für die Blumen"

Das Beispiel mit nano werde ich tatsächlich streichen, da kannte ich nämlich den ee noch nicht. Nach dem Kapitel zur Basisinstallation wird es ein Kapitel geben über Werkzeuge, die das System schon mitbringt, um Konfigurationen zu bearbeiten, da werden dann die drei Ansätze echo, ee und vi kurz abgehandelt, aus Bequemlichkeit ziehe ich den ee dem vi vor, auch wenn ich letztern in Grundzügen bedienen kann. Von der echo Variante halte ich nicht viel, das werde ich aber auch noch weiter erläutern.

Viele Grüße,
Holger

 

[Rakor]

Die Variante über xorg.conf.d ist nicht FreeBSD-spezifisch sondern funktioniert auch unter Linux. Siehe z.B. hier
https://wiki.ubuntuusers.de/xorg.conf.d/

Und die Variante über echo biete sich für Scripte an oder wenn man als Einzeiler schnell mal hin schreiben will was in einer Datei zu ergänzen ist. Für größere Änderungen von Hand ist ein Editor natürlich einfacher

 

[holgerw]

Und die Variante über echo biete sich für Scripte an oder wenn man als Einzeiler schnell mal hin schreiben will was in einer Datei zu ergänzen ist. Für größere Änderungen von Hand ist ein Editor natürlich einfacher

Hallo @Rakor,

klar, mit echo habe ich auch schon gearbeitet, ich mag echo allerdings aus zwei Gründen nicht:
1. Ich sehe ganz gerne beim Bearbeiten in die entsprechende Datei.
2. Ein Vertipper bei echo, und die Konfigdatei ist futsch, etwa

echo 'dbus_enable="YES"' > /etc/rc.conf

(beim nächsten Reboot gibt es eine böse Überraschung)

Aber das ist Geschmacksache.

Viele Grüße,
Holger

 

[Rakor]

Huhu,

Hallo @Rakor,

klar, mit echo habe ich auch schon gearbeitet, ich mag echo allerdings aus zwei Gründen nicht:
1. Ich sehe ganz gerne beim Bearbeiten in die entsprechende Datei.
2. Ein Vertipper bei echo, und die Konfigdatei ist futsch, etwa

echo 'dbus_enable="YES"' > /etc/rc.conf

(beim nächsten Reboot gibt es eine böse Überraschung)

Aber das ist Geschmacksache.

Klar, ich bearbeite Konfigurationsdateien auch immer mit dem Editor und nicht mit echo (bei mir meist vim ). Zum Einen will man ja sehen was man da verbricht (was man natürlich im echo-Befehl auch meist sieht) und zum Anderen will ich meine Anpassungen ja im Allgemeinen nicht immer ganz am Ende der Datei stehen haben. Dann findet man ja irgendwann nix mehr.
Wie gesagt, echo ist halt halt toll für Scripte oder für Anleitungen. Es ist einfacher zu schreiben

# echo "Find ich Toll" >> /narf/zort

als

Und dann schreiben Sie in die Datei /narf/zort die Zeile "Find ich Toll". Die Anführungszeichen bitte nicht in die Datei schreiben.

Wie gesagt ich bin da ganz bei dir, aber echo hat seine Berechtigung... Wobei es hier eher um dem Redirect (>>) und weniger um echo geht... echo ist hier nur Mittel zum Zweck. Könntest auch printf nehmen oder anderweitig deinen Text in den Redirect schubsen.

 

[pit234a]

Die Variante über xorg.conf.d ist nicht FreeBSD-spezifisch sondern funktioniert auch unter Linux.

logisch. Das ist ja X und nicht FreeBSD. Da war ich irgendwie geistig umnebelt oder wollte etwas anderes sagen.
Mir ist jedenfalls die xorg.conf nach wie vor lieber, weil ich da alles in einer Datei habe und nicht durch viele Mini-Dateien durch gehen muss.
Vielleicht werde ich meine Ansicht darüber auch ändern. Denn tatsächlich braucht man meist ja nur sehr wenige Einträge in der xorg.conf, weil so vieles schon automatisch richtig läuft. Das bedeutet im Umkehrschluss, dass man auch nur wenige Mini-Dateien braucht. Mal sehen.

 

[Vril]

...aber echo hat seine Berechtigung... Wobei es hier eher um dem Redirect (>>) und weniger um echo geht... echo ist hier nur Mittel zum Zweck. Könntest auch printf nehmen oder anderweitig deinen Text in den Redirect schubsen.

Gerade Einsteiger sollten sich mit solchen Dingen wie z.B. >> befassen -
denn sie werden sie immer wieder brauchen.

Ein Zimmermann-Lehrling lernt ja auch zunächst nen Nagel mit den Hammer reinzuschlagen - bevor er
Druckluft-Nagler benutzen darf... auch wenn er sich dabei öfterns mal auf den Daumen haut.

Ich bin ganz sicher, dass echo "blabla" > rc.conf jedem nur einmal passiert ;-)

Und wer nicht einfach nur ans Ende eines Files anhängen will ... sondern z.B. hald_enable... hinter der Zeile mit dbus_enable hängen will,
der schreibt einfach:

sed -e '/dbus_/a\\hald_enable="YES"' rc.conf > t && mv t rc.conf
( wobei bei der Eingabe der Zeile (zumindest in BSD) nach den 2 backslashes <RETURN> gedrückt werden muss)

Gruss walter

 

[i18n]

Nööö, Latex ist keine gute Idee, man will ja sowas u.U. unter Win lesen. PDF wäre wohl die richtige Wahl...

Er nu wieder.
Es ging um die Erstellung, LaTeX gibt natürlich PDF aus oder was immer sonst Du willst: PS, RTF, ODF ...

 

[i18n]

Hallo,

zur Zeit dokumentiere ich sehr ausführlich meine FreeBSD-Installationen. ...
Viele Grüße,
Holger

Lieber Holger,

finde ich eine sehr gute Idee und bewundere Deine Fleiß. Sowas ist mal wieder dran, leider sind die meisten Anleitungen veraltet und/oder zu kompliziert. Vielleicht ist es eine gute Idee, diese Anleitung (wenn sie denn fertig ist) hier ins Wiki zu stellen. Einige Leute haben da in der Vergangenheit sehr gute Arbeit geleistet, aber wie das so ist, oft fehlt die Zeit, die Einträge aktuell zu halten, Leute wechseln das Metier oder verlieren das Interesse.

Ich würde mich über einen Artikel zum automatischen Einbinden von Dateisystemen freuen (USB-Stick, DVD ...), der etwas weinigen kompliziert mit der Materie umgeht. FUSE ist da ein Beispiel, das eigentlich das Leben leichter machen sollte. Allerdings bin ich da kein Experte.

Ein anderes Thema ist UTF-8, Mehrsprachigkeit (nomen est omen) usw., da kann ich Dir gerne helfen. Ich bin seit 12 Jahren hier in China (bin aber Deutscher und schnell mitten im FreeBSD-Klub gelandet, nette Leute, einige sind sehr kompetent. Ich nutze als Oberfläche Windowmaker, Enlightenment und ROX auf Openbox -- auch mal Alternativen.

Bleib dran, gebe Dir gerne Feedback zu den Themen, von denen ich ein bißchen weiß.

Beste Grüße aus der alten Kaiserstadt Xi'an, i18n

 

[pit234a]

Ich nutze als Oberfläche Windowmaker, Enlightenment und ROX auf Openbox -- auch mal Alternativen.

Das spricht mir aus dem Herzen.
Seit einiger Zeit nutze ich OpenBox ohne Desktop und bin damit sehr zufrieden. Was den Umgang und die Einrichtung der verschiedenen Teile angeht, konnte ich mir zwar bei Ubuntu ein wenig abgucken, aber sehr viel trug ich erst im Laufe der Zeit zusammen und meist durch zufällig gefundene Hinweise. Da gibt es sicher ein riesiges Potenzial, die Sache besser zu machen. Und eine Vorstellung der Abläufe in einer Doku könnten dann vielleicht eher auch mal andere veranlassen, über einen "eigenen Desktop" nachzudenken, anstatt immer den großen DEs anzuhängen.

Ein weiterer Punkt, bei dem ich unüblich viel lesen musste und davon nur recht wenig gebrauchen konnte, das war Claws-Mail mit PGP zu realisieren. Es muss nicht Claws sein, aber es ist doch schon erstaunlich, wie wenig generell verschlüsselt wird und Hauptargument ist doch, dass das zu kompliziert ist für einfache Nutzer. Es ist vielleicht kompliziert zu verstehen, aber bei weitem nicht so kompliziert umzusetzen! Eine klare Doku dazu habe ich nicht gefunden.

Sicher kann so eine Wunschliste sehr lange werden.
Optimalerweise stelle ich mir vor, dass in öffentlichen Diskussionen die einzelnen Schritte und Möglichkeiten dargestellt werden. Das halte ich persönlich besser, als jede Dokumentation, wenigstens begleitend zu einer solchen. Es gibt ja oft nicht nur den Königsweg.
Bislang sind alle derartigen Vorhaben aber gescheitert und haben sich irgendwo verlaufen.

 

[holgerw]

Hallo,

damit nicht bei manchen der Eindruck entsteht, ich würde nur von einer Neufassung der Doku schwätzen, aber nicht machen, lade ich nun einen Schnappschuss meiner neuen Dokumentation hoch.

Dieser Schnappschuss ist unvollständig, auch das Gerüst ist noch nicht fertig, aber ihr könnt ungefähr sehen, in welche Richtung das gehen soll.

Vorerst bin ich bei LibreOffice geblieben, das heißt nicht, dass ich LaTeX und LyX meiden möchte, aber mich da auch noch einzuarbeiten wird mir momentan etwas zu viel, mir ist wichtig, dass die Doku zustande kommt.

Ich schreibe nach und nach zu einzelnen Teilen, mal in Kapitel 1, mal in Kapitel 3 u.s.f.

Dieser Schnappschuss soll in erster Linie einen Eindruck vermitteln, bedenkt bitte, dass vieles noch gar nicht ausgearbeitet ist, aber falls ihr darin grobe Schnitzer bemerkt, freue ich mich natürlich über Hinweise.

Viele Grüße,
Holger

 

[Vril]

Hallo Holger,

ich hab da 'mal ne Frage zum Punkt 4.3.1.

Warum soll ich als Einsteiger Poudriere installieren und nutzen?

Laut Manual ist Poudriere ein Tool um Pakete zu bauen - und wird z.B. für Cross-Compiling Anforderungen gebraucht, also um Pakete für andere -als die eigene- Umgebung herzustellen.

Um aber ein BSD System aufzusetzen reicht es doch die Pakete mit 'make install clean' herzustellen oder portmaster zu nutzen oder eben Binärpakete mit pkg zu laden. ...

Warum soll ich also ein eher kryptisches Entwicklerwerkzeug wie Poudriere benutzen, von dem das Handbuch folgendes sagt:

"Poudriere ist ein ... Werkzeug zum Erstellen und Testen von FreeBSD-Paketen. Dieses Programm nutzt FreeBSD Jails, um die Pakete in einer isolierten Umgebung zu bauen. Diese Jails können verwendet werden, um Pakete für andere Versionen von FreeBSD zu bauen, oder um auf einem amd64-System Pakete für i386 zu bauen. Sobald die Pakete gebaut sind, haben sie das gleiche Format wie auf den offiziellen Spiegeln. ..."

Lieber Gruß
Walter

 

[holgerw]

Hallo Walter,

ich werde poudriere demnächst intensiv einsetzen, und warum das dann nicht auch dokumentieren? Das poudriere-Kapitel ist im vierten Teil "Fortgeschrittene Themen" zu finden, das soll ein Sammel-Kapitel für Sachen sein, die ich persönlich mit FreeBSD mache, aber die eher nicht mehr in die "Anfänger-Richtung" gehen.

Warum soll ich also ein eher kryptisches Entwicklerwerkzeug wie Poudriere benutzen,

Ich finde poudriere nicht kryptisch, aber man kann diese Frage "Warum soll ich, wenn es doch auch ..." bezogen auf das Buch doch öfters stellen:
Warum manuelles Partitionieren -> der Installer macht das doch
Warum manuelles Root-on-ZFS -> der Installer macht das doch

Du kannst poudriere nutzen, ich schreibe nicht davon, dass Leserinnen und Leser es nutzen sollen, wer das Buch liest, soll gar nicht, es ist ein Angebot, ich möchte neugierig machen auf den Bereich "FreeBSD auf dem Desktop" und dass Komplexizität bei FreeBSD nicht bedeuten muss, dass es kompliziert ist, und dass auch ein Verzicht auf Automatismen zu Gunsten von manuellem Einrichten und Nutzen verschiedener Werkzeuge kein Hexenwerk ist. Und die es lesen, können davon Gebrauch machen. Dass das Buch auf meine eigenen Interessen zugeschnitten ist, das mache ich mehrmals explizit deutlich, und diese Interessen werden sich nicht komplett mit denen anderer Leute decken. Wer möchte, kann Kapitel 4 und alles mit manuellen Einrichtungsvorschlägen und alles, was nicht mit Info Werkzeuge beginnt, ignorieren, übrig bleibt dann ein FreeBSD im Crash-Kurs auf dem Desktop für Bequeme, auch das ist doch in Ordnung. Es wird Leute geben, die sich einzelnes heraus greifen, es wird vielleicht auch Leute geben, die die Doku "von Deckel zu Deckel" lesen, manche werden neu zu FreeBSD stoßen und das Buch ignorieren. Einigen wird der Stil gefallen, andere werden ihn kritisieren, manche werden vielleicht das Buch mehr oder weniger verreißen, wobei ich letztere dann schon bitten würde, mal zu zeigen, wie sie es besser machen würden.

Viele Grüße,
Holger

 

[Vril]

Du hast meine Frage nicht verstanden.
Meine Frage war: " warum soll ich es nutzen?"

Damit wollte ich nicht hinterfragen ob ich 'muss' oder 'kann' - oder ob 'manuelles Einrichten' den 'Automatismen' vorzuziehen sind.

Nein, ich wollte wissen - welche Vorteile ich bekomme, wenn ich Poudriere nutze - sofern ich nicht gerade die im FreeBSD Manual dokumentierten Anforderungen wie das 'Paket-Erstellen für andere Umgebungen' als Hintergrund habe.

Oder um das ganze etwas abzukürzen:
Warum und wofür wirst Du Poudriere benutzen?

Gruß Walter

 

[holgerw]

Du hast meine Frage nicht verstanden.
Meine Frage war: " warum soll ich es nutzen?"

Damit wollte ich nicht hinterfragen ob ich 'muss' oder 'kann' - oder ob 'manuelles Einrichten' den 'Automatismen' vorzuziehen sind.

Nein, ich wollte wissen - welche Vorteile ich bekomme, wenn ich Poudriere nutze - sofern ich nicht gerade die im FreeBSD Manual dokumentierten Anforderungen wie das 'Paket-Erstellen für andere Umgebungen' als Hintergrund habe.

Oder um das ganze etwas abzukürzen:
Warum und wofür wirst Du Poudriere benutzen?

Gruß Walter

Hallo Walter,

ah, ein Missverständnis, Du möchtest um die Vorteile von poudriere im Hinblick auf gewisse Anforderungen wissen. Das wird selbstverständlich in der Dokumentation ausführlich begründet - wie schon geschrieben ist das neue PDF meiner Rohfassung ein Torso, sowohl inhaltlich wie auch vom Gerüst her. Ich glaube, in meiner Erstfassung verweise ich da schon auf eine Diskussion zu poudriere versus portmaster hier im Forum, das fehlt beim neuen Entwurf noch.

Ich habe in meinem Heimnetzwerk mehrere Rechner, die ich mit Paketen versorgen und deren Standardoptionen ich zum Teil modifizieren möchte. Dazu kommt, dass ich als KDE-Freund auch mir einen Eindruck von Plasma5 verschaffen möchte, es also auch bauen werde. Und spätestens von da an bekommst Du Schwierigkeiten beim Bau über make install clean oder Portmaster.

Ich zitiere zur Begründung, poudriere beim Paketbau größeren Umfanges den Vorzug zu geben, mal @-Nuke-:

Statt die Ports direkt zu nutzen würde ich poudriere ( https://github.com/freebsd/poudriere/wiki ) vorschlagen. Du müllst dir sonst dein System mit Build-Abhängigkeiten zu. Das kann auf lange Sicht nervend werden, da es hier und da mal zu Problemen beim Upgrade dieser kommt. Mittels poudriere werden die Pakete immer in einer sauberen Umgebung gebaut. Auch vermeidet man Seiteneffekte bereits installierter Pakete. Manchmal ändern die Tools ihre Konfiguration wenn bestimmte Sachen installiert sind und dann baut es bei dir nicht, bei anderen aber schon.

Viele Grüße,
Holger

 

[Vril]

Ah o.k. - so entsteht langsam ein Sinn für mich

D.h also, dass Poudriere nicht nur dafür eingesetzt wird um Pakete für fremde Systeme mit anderem Hardwarehintergrund oder anderem Release - Level zu bauen - sondern auch um Programme für das eigene System in einem vom OS abgegrenzten Bereich (Jail) zu kompilieren und zu linken.

Das würde aber bedeuten, dass man dann auf Poudriere verzichten kann - wenn man hauptsächlich fertige -also Binärpakete mit PKG- lädt, sofern man mit den im Sourcecode gesetzten Default-Optionen klar kommt.

Wenn ich also mal FreeBSD auf einem STM32 Contoller - Board laufen hab - und mit nen C Programm ein paar LEDs ansteuern wollte - müsste ich die Tool-Chain in der Poudriere - Umgebung zusammen basteln ?

Viele Grüße
Walter

 

[pit234a]

Poudriere braucht man überhaupt nicht. Man kann es nutzen und wenn man häufig und viele Pakete zu bauen hat, erleichtert es die Aufgabe.
Für mich selbst habe ich vor Jahren entschieden, dass der Aufwand nicht lohnt und ich lieber darauf verzichten möchte. Damals baute ich aus den Ports und nutzte portupgrade dazu. Zusammen mit einigen weiteren Tools kann man damit sein System durchaus sauber und aktuell halten, Aber auch das ist nun für mich Vergangenheit. Mit den Paketen von heute brauche ich nun nur noch ffmpeg aus den Ports und das auch nur wegen mp3 und dafür lohnt sich ganz gewiss kein poudriere und nicht mal portsmaster. Einzelne Anwendungen kann man leicht von Hand aus den Ports installieren, benötigte Abhängigkeiten werden dabei mitgezogen. Nur der Port, in dem man eigene Optionen wählte, sollte dann mit pkg lock geschützt werden, der Rest wird dann auch als Paket gepflegt.
Bei wenigen Ports lohnt sich daher in meinen Augen keiner der vorhandenen Automatismen und mit Paketen kommt man heute sehr sehr weit und ganz gut ans Ziel.
holgerw nannte ein Projekt, mit diesem Plasma5 und KDE, wo das nicht gilt. Dafür gibt es keine Pakete und wenn man so etwas testen möchte, hat man viele Ports, die man dann manuell installieren und warten müsste. Das geht auch ohne poudriere sehr gut, aber mit geht es in dem Fall offenbar einfacher oder mit mehr Automagie. Und vor allem, wenn man dann solche Pakete auch auf anderen PCs nutzen will, ist poudriere schon extrem praktisch, aber auch da kein MUSS.

 

[pit234a]

@holgerw:

35 Anm.: In der Regel werden sha512 Summen angegeben, und ihr braucht zum Überprüfen das – auch
abhängig von eurem Betriebssystem - entsprechende Werkzeug, unter GNU/Linux zum Beispiel
sha512sum .

würde ich noch in der Art ergänzen: unter FreeBSD etwa md5(1), sha1, sha256, sha384, sha512, sha512t256, rmd160.
Denn, ich erinnere noch einige Vorkommnisse, wo GNU/Linux-Umsteiger verzweifelt ihr xyzsum suchen und auf FreeBSD nicht fündig werden.