FreeBSD 12 - Installations ‘Hoppalas‘, Installationstagebuch eines FreeBSD Neulings

Wieviel % von der Gesamtinstallation?
Ich habe einen Vorteil - ich kann die VM stoppen und sichern und zu anderer Zeit weitermachen. Der eine zugewiesene CPU Core pendelt so zw. 90 und 100% - RAM 2GB.
Mit dem 2. Core kann ich am Mac noch halbwegs arbeiten. Eine 6 Core CPU mit 16/32 GB RAM und einer sauschnellen 1TB SSD = Mac Mini wäre da von Vorteil.
 
ich will auch ein Beispiel aus meiner Praxis geben. Ich habe zwei FreeBSD12 Systeme und auf einem arbeite ich nur mit Paketen und aus Quarterly, bei dem anderen stehe ich auf Latest und habe grundsätzlich nur einen Port installiert, nämlich ffmpeg, wegen der Abhängigkeit zu lame, die im Paket wegen Lizenz-Gründen nicht drin ist.
In Wirklichkeit kommen hier und da mal Dinge vor, weshalb ich dann schon mal mehrere Ports baue und benutze, vielleicht dann wieder verwerfe. Ech bin also froh, dass ich die Ports zusätzlich nutzen kann, verzichte aber auf einem System komplett darauf.
Es gibt bei mir bisher keinerlei Probleme, die wenigen Ports über pkg-lock zu halten.
Sehr viel bringt das aber in der tat nicht, weil sehr oft gleichzeitig zu anderen Änderungen auch diese Ports neue Versionen bekommen und dann neu gebaut werden müssen. Man könnte sich vielleicht auch ein Lock sparen und einfach immer nach einem pkg update die wenigen Dinge neu bauen. Das ist kein großes Ding und ich benutze dazu nicht mal irgendwelche Tools. Bei den wenigen Dingen kann ich ein "make install clean" gut verschmerzen.

Dass FreeBSD etwas mit OS-X zu tun hat, ist vermutlich eher historisches Gerede. Es ist wenigstens so viel GNU in einem OS-X, wenn nicht sogar deutlich mehr. Ich weiß auch nicht, wieso da eine Notwendigkeit erkannt wird, die angebliche Ähnlichkeit immer zu betonen. Einfach nicht darüber nachdenken und weglassen.
 
@pit234a
Ich bin vorerst mal am „Erforschen“ von FreeBSD.
Was Alltagstauglichkeit betrifft - so gibt es leider noch keine auf FreeBSD basierende Distribution, die so funktioniert wie eine der Linux Distributionen und der Benutzer sich nicht um Updates kümmern müsste, die sollten so wie bei anderen OS (nach Benachrichtigung) eingespielt werden. Wäre auch egal, wenn dadurch die Hardwareauswahl etwas eingeschränkt wäre.
Z.B. eines der Dell oder Lenovo Business Notebooks wäre eine solche Hardware.

PS: Was die Abstammung des macOS Kernels betrifft ist in dessen Stammbaum in der Wiki nachzulesen.
Was den Rest rundherum betrifft, greift Apple sehr wohl kräftigst in den Topf der OpenSource Software, das sowohl in macOS als auch iOS.
Ich hoffe nur, dass Apple der OpenSource Gemeinde viel von seinem Gewinn abgibt! :belehren::confused:
https://de.wikipedia.org/wiki/MacOS
https://de.wikipedia.org/wiki/XNU
https://de.wikipedia.org/wiki/Mach_(Kernel)
https://de.wikipedia.org/wiki/GNU

Wurde GNU Mach / GNU Hurd „auf freier Wildbahn“ (praktischen Einsatz) jemals gesichtet?
https://de.wikipedia.org/wiki/GNU_Hurd
 
Was Alltagstauglichkeit betrifft - so gibt es leider noch keine auf FreeBSD basierende Distribution, die so funktioniert wie eine der Linux Distributionen und der Benutzer sich nicht um Updates kümmern müsste, die sollten so wie bei anderen OS (nach Benachrichtigung) eingespielt werden.
Ich glaube Du hast die Philosophie von FreeBSD (noch) nicht verstanden. Du bist verantwortlich und übernimmst die Verantwortung durch Tun oder Unterlassen und das ist meineserachtens auch gut und richtig so. Denn das ist ein Freiheitsgrad, den Du durch die Automagie, die Dir Linux anbietet, nicht findest. Siehst Du, genau deshalb lieben wir FreeBSD, weil wir nicht bevormundet und gegängelt werden.
 
@ralli
OK - das hat aber nichts mit einem gewissen „Automatisierungsgrad“ zu tun, den man für das alltägliche Arbeiten „freiwillig“ einbauen kann.
Updates (BSD, ports/pkg, etc.) kann man sicherlich mittels cron / anacron automatisieren. Und auch sonstige „Helferleins“ die das alltägliche Arbeiten erleichtern. Detto automatisiertes Sichern des Rechners, bzw. der Benutzer Daten. Usw.
Befasst sich hier Jemand damit und stellt Hinweise, Anleitungen bzw. Scripts online?
 
Befasst sich hier Jemand damit und stellt Hinweise, Anleitungen
Also bezüglich Anleitung kann ich nur auf das FreeBSD-Handbuch verweisen:
https://www.freebsd.org/doc/de/books/handbook/backup-basics.html

Ansonsten ist ja Backup nix anderes als Dateien kopieren. Wobei in erster Linie die Dateien im Homeverzeichnis sowie /etc und /var interessant ist. Evtl. dann noch ne Liste der installierten Pakete (die man bei einer Reinstallation ja pkg auch wieder übergeben kann damit er die automatisch abarbeitet).

Nu kann man halt gucken, ob man das zeitgesteuert macht (a-ka CRON) oder z.B. wenn eine bestimmte externe Festplatte angeschlossen wird.
 
Du kannst dir zum Automatisieren natürlich allerlei Cron-Scripte schreiben. Musst du dir überlegen wieviel du davon ungesehen auomatisch machen willst.

Zum Thema Backup gibt es hier auch schon viele Threads und sicherlich auch im restlichen Internet noch einiges. Da ist auch die Frage wie komfortabel möchte man es haben und was verwendet man. Hast du ZFS kannst du snapshots machen und per send/recieve übertragen. Ich nutze seit einiger Zeit restic auf allen Maschinen und bin damit recht zufrieden. Aber die Frage was für dich das Richtige ist musst du selbst herausfinden.
 
OK - das hat aber nichts mit einem gewissen „Automatisierungsgrad“ zu tun, den man für das alltägliche Arbeiten „freiwillig“ einbauen kann.
Natürlich. Nur: wir haben es halt nicht.
Über die Gründe kann man spekulieren. Im Laufe der zeit hatte ich FreeSBIE oder so ähnlich, GhostBSD, PC-BSD angesehen. Dies sind Fertig-Distributionen gewesen. Was die alles konnten, kann ich nicht mehr erinnern, aber ich weiß noch, dass ich das ein oder Andere damals aus GhostBSD schließlich in meinem FreeBSD-Desktop benutzt hatte. Nun, das sagt es ja schon: ich kam schließlich immer wieder zu FreeBSD zurück und das ist sicher eine Frage des persönlichen Geschmacks, aber auch der Ideologie. Ich fühle mich tatsächlich Freier, wenn ich nicht von Automatismen gegängelt werde.
Deshalb könnte es diese natürlich trotzdem geben, aber es entwickelt sie offenbar niemand.
Man muss das auch ein wenig hinterfragen, denn FreeBSD ist nun mal nicht ein fertiges Desktop-System. Ohne Desktop ist alles, was man zu einem Update braucht und machen kann, zwei Befehle einzugeben. Mit meinen Aliasen verkürzt sich das auf ein fu und pu in der Shell, immer dann, wenn es mir gerade passt. Wer sollte hier eine Automatik brauchen?
Der Bedarf für Automatik und GUI entsteht ja erst auf dem Desktop und dafür ist FreeBSD nicht mehr zuständig. Die Entwickler der Desktop-SW denken meist gar nicht an FreeBSD und es gibt eben keine Distribution, die genug Leute hätte, um großartig etwas zu stemmen. Wir sind nicht im Linux-Land. DesktopBSD oder nomad-bsd sind One-Man-Shows. Schon die relativ einfache Aufgabe, ein DesktopEnvironment für FreeBSD zu schaffen (Lumina), kann beinahe nicht gestemmt werden.
Häufiger kommt es vor, dass sich Gruppen mit guten Ideen finden. Betrachte PC-BSD und True-OS, wobei ich dahingestellt sein lasse, ob diese Ideen gut waren. Mit viel Eifer und großem Enthusiasmus starten die, zerfransen irgendwann an der Fülle der selbst gestellten Aufgaben und enden nicht selten in Vergessenheit.

Wir haben es einfach nicht und müssen das nehmen, was uns das FreeBSD-Team gibt.
Die arbeiten alle viel und leisten auch gute Arbeit. Einen Automatisierer für Updates haben sie einfach nicht auf der Liste.
 
@all
Ich habe schon mitbekommen, dass xxxxBSD (Büro, Home-Office) Komplettpakete (wie im Linux Land üblich) nicht von Dauer waren oder sind. Gilt auch für Open-Solaris oder Ähnliches.

Zum Thema zurück - meine ein CPU Core + 2GB RAM VM nuckelt noch immer beim Kompilieren vor sich hin. Kann das noch Tage dauern?
Ist bei
Code:
/usr/ports/devel/llvm60/work/llvm-6.0.1.src
Was passiert, wenn man den Kompiliervorgang 'abschießt' und vor allem wie?
Wie bekommt man allfälligen „Schrott“ und schon fertige Softwareteile weg?
Gibt es möglicherweise Konfig-Files die man löschen sollte?
Oder würden diese bei einer erneuten Installation - diesmal mit pkg - sowieso überschrieben?

PS: Meine VM ist vermutlich nur marginal schneller als der Einplatinen PC ODROID-XU4. Ist der auch FreeBSD tauglich? :rolleyes::)
 
Die ganzen FreeBSD-Derivate (TrueOS, GhostBSD usw.) hatte ich mir auch mal angeschaut. Letztlich bin ich aber doch bei FreeBSD gelandet. Dort findet man das meiste Zeug zu. Dort ist man direkt am Upstream. Und letztlich kriegt man auch ein FreeBSD so hinkonfiguriert, das es wie ein GhostBSD aussieht.
Mir persönlich fehlt da so der richtige Grund um sowas wie GhostBSD einzusetzen. Die Installation mag schneller gehen. Aber wie oft installiert man schon. Ansonsten hat man nur Nachteile, finde ich.

Die arbeiten alle viel und leisten auch gute Arbeit. Einen Automatisierer für Updates haben sie einfach nicht auf der Liste.
Ich wüsste auch gar nicht, wofür das gut sein sollte.
Je nachdem wie man das System benutzt sieht ja auch die Updateprozedur unterschiedlich aus.

Was passiert, wenn man den Kompiliervorgang 'abschießt' und vor allem wie?
Wie? Mit Strg+C oder Du schießt mit kill den Prozess ab.

Wie bekommt man allfälligen „Schrott“ und schon fertige Softwareteile weg?
make clean

Oder würden diese bei einer erneuten Installation - diesmal mit pkg - sowieso überschrieben?
Wenn er noch beim kompilieren war, hat er nix ins System geschrieben. Deshalb gibts auch nix zum überschreiben und damit sowieso keine Probleme.
 
Welche Upgrades sind davon dann und wann notwendig:
Code:
# System
freebsd-update fetch
freebsd-update install

#pkg
pkg upgrade

#ports
portupgrade -a
 
Ports nur wenn Du Ports installiert hast.
Bei pkg upgrade würde ich immer ein -y anfügen, sonst wirds schwierig mit CRON-Job.
pkg upgrade -y

Bei freebsd-update kannst Du auch
freebsd-update cron
benutzen.
Du kriegst dann ne Mail, wenn ne neue Version da ist und kannst sie dann mit
freebsd-update install
einspielen.

Eintragen würde ich die Änderungen aber nicht in der /etc/crontab direkt, sondern mir eine eigene Datei unter /etc/cron.d/ anlegen z.B. mit folgendem Inhalt:
Code:
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

0       2       *       *       *       root    freebsd-update cron
30      2       *       *       *       root    pkg upgrade -y
freebsd-update wird hier nachts um 2:00 Uhr ausgeführt. pkg ne halbe Stunde später.

Wenn etwas geupdated wurde empfiehlt sich den Rechner neuzustarten. Nur dann ist sichergestellt, das die aktuellsten Versionen der Programme und Libraries geladen sind.
Theoretisch braucht man das nicht immer, aber man macht damit nix falsch.
 
freebsd-update wird hier nachts um 2:00 Uhr ausgeführt. pkg ne halbe Stunde später.
Wenn der Rechner nicht durchläuft?
Ich habe zu Anfang cron durch anacron ersetzt (stand in einer Anleitung, man soll das wenn Rechner nicht durchläuft) - kann man das auch auf z.B. xx Minuten nach Rechnerstart verlegen - eigentlich wie kann man das?
 
Welche Upgrades sind davon dann und wann notwendig:
das hängt auch ein wenig von den eigenen Vorlieben ab.
Ich habe mir angewöhnt, immer wieder Sonntags und nur, wenn ich dran denke, freebsd-update und pkg upgrade zu fahren.
freebsd-update ist meist leer.
Außerdem mache ich einen portsnap fetch update und wenn nötig, cd zu/meinem/port && make deinstall && make install clean
portupgrade oder sowas nutze ich nicht mehr, weil ich quasi keine Ports mehr nutze.
 
Ich habe zu Anfang cron durch anacron ersetzt
Ähm. anacron ist kein Ersatz für cron, sondern eine Ergänzung.

stand in einer Anleitung, man soll das wenn Rechner nicht durchläuft
Du und Deine ominösen Anleitungen.

- kann man das auch auf z.B. xx Minuten nach Rechnerstart verlegen - eigentlich wie kann man das?
Es gibt auch den Zeiteintrag @boot, der sorgt dafür das der angegebene Job genau dann ausgeführt wird, wenn der Rechner startet (genauer gesagt beim Start von cron):
Code:
@boot    root    freebsd-update cron

Die crontab-Optionen stehen aber auch alle in der Man-Page:
https://www.freebsd.org/cgi/man.cgi?query=crontab&sektion=5
 
Zuletzt bearbeitet:
das hängt auch ein wenig von den eigenen Vorlieben ab.
Ich habe mir angewöhnt, immer wieder Sonntags und nur, wenn ich dran denke, freebsd-update und pkg upgrade zu fahren.
Stimmt. Hängt davon ab.
Ich update täglich. inkl. Kernel und Userland welche dann anschließend auch gleich durchkompiliert wird. :-)
Bei Releases sind Änderungen seltener. Da reicht vermutlich einmal pro Woche wirklich. Bei Packages kommt fast täglich frischer Kram rein. Also zumindest wenn man das latest-Repository nutzt.
Dito bei Ports, falls man sie intensiv nutzt. Zumindest sammelt portsnap täglich was ein.
 
das hängt auch ein wenig von den eigenen Vorlieben ab.
Ich habe mir angewöhnt, immer wieder Sonntags und nur, wenn ich dran denke, freebsd-update und pkg upgrade zu fahren.
freebsd-update ist meist leer.
Außerdem mache ich einen portsnap fetch update und wenn nötig, cd zu/meinem/port && make deinstall && make install clean
portupgrade oder sowas nutze ich nicht mehr, weil ich quasi keine Ports mehr nutze.

portupgrade -a war auch keine gute Idee .... da läuft wieder eine „Endlos Orgie“ und wieder CMakeFiles aus llvm-6.0.1.src - ich habe die Abfrage-Fenster die zwischendurch kamen immer nur mit OK abgenickt.

Was ich mit dieser VM mache, ist eine Art trial & error - ein Lernprozess.

Schon gefunden
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html
portupgrade habe ich von 4.5.3.3. Upgrading Ports Using Portupgrade

PS: Ich hoffe ich lageweile oder gar verärgere euch dabei nicht!? :rolleyes::D
 
portupgrade -a war auch keine gute Idee .... da läuft wieder eine „Endlos Orgie“ und wieder CMakeFiles aus llvm-6.0.1.src - ich habe die Abfrage-Fenster die zwischendurch kamen immer nur mit OK abgenickt.
Ich kann mich nur noch mal wiederholen:
Nutze Ports nur wenn unbedingt nötig. Sonst Packages.
Zumindest in der Anfängerzeit.

Was ich mit dieser VM mache, ist eine Art trial & error - ein Lernprozess.
Wenns ziellos ist, bringt das einen nur begrenzt weiter. Was nützt es, wenn man irgendwie irgendwas zum laufen bringt aber hinterher weiß man nicht warum.
Ich mein, kann man machen. Ist aber ineffizient.

PS: Ich hoffe ich lageweile oder gar verärgere euch dabei nicht!?
Naja. Bei solchen Sachen wie den Ports die hier schon zigmal zur Sprache kamen, da wirds dann schon leicht nervig. Ist dann halt blöd, wenn Du Dich an die Empfehlungen nicht hältst und trotzdem irgendwas machst und dann plötzlich Hilfe erwartest. Fortgeschrittenen-Themen sind sinnvoll nur zu beantworten, wenn derjenige schon fortgeschritten ist.
Was nützt es Dir, wenn man Dir irgendwas sagt aber Du das noch nicht verstehst (verstehen kannst).

Ist alles nicht böse gemeint, sondern eher im Sinne eines Ratschlages, um Dir Zeit und ggf. unnötigen Frust zu ersparen.
 
Wie bekommt man ports nun los ohne das Sytem neu aufzusetzen?
In dem du Packages verwendest......

Es wird IMMER ein Paket installiert. Wenn du aus den Ports installierst, wird der Quellcode runter geladen, kompiliert, in ein Paket geschnürt, und das wird dann installiert.
Wenn du direkt Pakete installierst wird das fertige Paket runtergeladen und installiert. Dein System kennt nur Pakete.
 
Ich habe nun schon über die Anleitung herausgefunden wie man mit portsnap updated und mit portsclean Überbleibsel abräumt.
Ich installiere eben xorg per pkg - beim Herunterladen von llvm-6.0.1 war mir nun klar warum das Kompstart xilieren so lange auf eines schwachen Maschine dauert.
 
ok. Ich glaube, dass es da Verwirrung gibt.
Alle "Portstools" arbeiten auf Ports, um es mal so ein wenig plakativ auszudrücken.
portsclean cleaned die Ports von Ballast.
Bereits installierte Ports, die ja zuvor Pakete wurden, sind damit nicht gemeint.

@holgerw hat eben dies gesagt:
https://www.bsdforen.de/threads/was...en-unixosen-gegenüber-linux.34052/post-310520

Derzeit habe ich so den Eindruck, dass du noch nicht richtig mitbekommst, was den Unterschied ausmacht oder besser gesagt, wie du damit umgehen sollst.

Es wurde schon mehrfach gesagt: nutz keine Ports! wenn du das nicht unbedingt haben willst.
Du hast das offenbar verstanden und möchtest nun, quasi mitten in der Installation, umschwenken.

Stell dir das so vor:
Es gibt die Ports.
Sie werden benutzt, um Pakete zu erstellen, die dir zur Verfügung stehen. Diese Pakete haben vorbestimmte Optionen, die du akzeptieren musst. Allermeist sind diese Optionen gut gewählt und verträglich, also brauchst du zunächst keine Ports, sondern nur Pakete.

Die Pakete, die aus den Ports gebaut werden und dann zur Verfügung stehen, gibt es in zwei Versionen. Quarterly und Latest.
Du kannst das um-wählen, wenn du es in der /etc/pkg/FreeBSD.conf entsprechend änderst.

Am aktuellsten sind die Ports, dicht gefolgt von den Paketen aus latest und dann erst quarterly.

Alles, was du aus den Ports installierst, wird zu einem eigenen Paket, lass es mich ein "Lokales Paket" nennen.
Es gibt Tools, um sich seine eigenen Pakete tatsächlich als eigenes Repo zu erstellen. Diese Pakete können dann anstatt der zentralen Pakete in quarterly oder latest benutzt werden. Das macht Sinn, wenn jemand gar nicht mit Optionen in den allgemeinen Paketen leben kann und mehrere PCs mit eigenen Paketen versorgen möchte.
Es macht zunächst mal keinen Sinn für einen Anfänger und auch nicht für mich selbst (der ich natürlich immer noch Anfänger bin).

Wenn alles, was auf deinem System landet, letztlich als Paket installiert wird, dann kann man es auch mit pkg-tools verwalten, ergo, wieder löschen.
pkg delete löscht Pakete.
pkg delete -a (siehe die man page PKG-DELETE(8)) löscht sie alle. Auch alle, die du aus den Ports oder irgendwelchen lokalen Repositries installiert hast.
Gut.
Damit bist du dann alle Paket los.
Du bist alle Pakete los, die über die Ports installiert wurden und alle Pakete, die von sonst irgendwo her kamen.

Alle Konfigurationen von "Non-Base"-SW landet in FreeBSD irgendwo unter /usr/local.
Es gibt hier etwa ein /usr/local/etc
und es gibt natürlich ein /etc
ABER: /usr/local/etc kann man getrost löschen, wenn man sich nur auf das Basis-System konzentriert und dieses erhalten möchte. Die Trennung zwischen Base und zusätzlicher SW ist an der Stellen in FreeBSD wesentlich besser und rigider umgesetzt, als in anderen Syste3men, die ich mir angesehen habe.

Wenn aber nun alle Pakete deinstalliert und alle Konfigurationen gelöscht sind, dann bleibt immer noch der Müll in /usr/ports.
Der stört nicht weiter.
Man kann diesen Portstree ein Leben lang pflegen und nicht weiter beachten oder benutzen.
Er verbraucht halt ein wenig Plattenplatz.

Benutzt man ihn, dann kann man die zugehörigen Tools einsetzen. Etwa den portsclean, um ihn zu säubern.
Will man ihn loswerden, kann man ihn einfach löschen und schadet damit Nichts und Niemandem.
Es ist nur eine Option, die Ports in FreeBSD zu nutzen, kein Zwang.
Du kannst natürlich löschen und eine neuen, aktuellen Portstree ziehen und auch damit allen Ballast los werden.

Nur, die bereits über ports installierten Pakete bleiben davon unberührt.
Die werden mit den pkg-Tools verwaltet.
 
Eigentlich braucht man Ports nur in 2 Fällen:

  • Es gibt kein Paket, da die Lizenz das Paketieren nicht zulässt.
Dazu mal ne Frage: bei jedem Linux was ich ausprobiert hatte war die Installation von exfat-fuse kein Problem. Ubuntu hat es auch standardmässig in seinem Repo. Bei Androidx86 ist es ebenfalls enthalten.
Warum ist es bei FreeBSD per pkg nicht installierbar? Die anderen haben doch sicher auch keine Lizenzgebüren bezahlt, oder etwa doch??
 
Zurück
Oben