Interesse an FreeBSD rückläufig? Schwächen und Stärken von FreeBSD.

Also ich sehe hier grad eine Stärke von FreeBSD gegenüber Ubuntu bzw kann man auch sagen klassische Pakete gegenüber Snap.

Denn ich befasse mich gerade ein wenig damit auf einem alten Laptop und bin da etwas verwirrt. Snap soll doch Abhängigkeitsprobleme lösen. Aber wenn ich dies oder jenes installiere, kommen teilweise eine oder mehrere zusätzliche Snaps dazu!! Also ist ein Snap manchmal wieder von einem anderen Snap abhängig.
Was für ein Blödsinn! Entweder ganz oder gar nicht. Ausserdem gibt es einen Cache Ordner für die heruntergeladenen snaps (so wie bei den pkgs) und noch einen anderen Ordner der die Installationspakete in richtigem Namen enthält. (aber sonst identisch). Also gibts den Cache wohl zwei mal. Verstehe die Logik dahinter nicht. Aber snap Pakete sind ja eh schon gross und dann gleich 2 mal vorhanden...?
Und ein Paket funktioniert überhaupt nicht.
Ich fand snap interessant und sah das positiv. Aber jetzt bin ich da echt skeptisch.
 
Lance schrieb:
Also ich sehe hier grad eine Stärke von FreeBSD gegenüber Ubuntu bzw kann man auch sagen klassische Pakete gegenüber Snap.
Zum Vergrößern anklicken....
Snap soll Pakete nicht ersetzen, sondern ergänzen.
Es ist eher sowas wie AppImage oder auch Flatpak. Wenn Du willst, kannst Du es auch mit Docker vergleichen. :-)
Es geht darum, das Du Software installieren kannst ohne das Du in Konflikte damit kommst, was Du an Paketen oder Programm/Bibliotheksversionen auf Deinem Rechner installiert hast. Und das auch distributionsübergreifend.
Du brauchst dann kein Package mehr für 100.000 Distributionen anzubieten, sondern bietest es einmal als Snap an.
 
Da finde ich die Apple Lösung weit besser. Und bei Flatpak gibt es gar keine offline zu installierende Pakete.

Naja ich verstehe zwar den Sinn aber finde es halt nicht optimal umgesetzt.
 
Lance schrieb:
Da finde ich die Apple Lösung weit besser. Und bei Flatpak gibt es gar keine offline zu installierende Pakete.
Zum Vergrößern anklicken....

Flatpak hat Single File Bundles und create-usb, d.h. die Offline-Paketinstallation geht problemlos. Statt wie bei Apple eine dmg-Datei kopiert man halt eine flatpak-Datei auf den Rechner und installiert sie, auch ohne Internetverbindung.

Lance schrieb:
Naja ich verstehe zwar den Sinn aber finde es halt nicht optimal umgesetzt.
Zum Vergrößern anklicken....

Was vermisst du denn bei Flatpak? Von einer zentralen Bibliothek bis hin zum isolierten Offline-Betrieb ist alles abgedeckt. Konkurrierende Anwendungen und Abhängigkeiten lassen sich mit einem einzigen Paket problemlos parallel betreiben und das auf jeder Distribution (Debian, Ubuntu, Fedora, RHEL, SUSE, Arch Linux etc.) und das versionsübergreifend.

Um wieder on-topic zu werden: hat die BSD-Welt eine vergleichbare Lösung? Ports und Packages greifen hier wie alle konventionellen Paketmanager ja offensichtlich kürzer.
 
@Azazyel
danke, das wusste ich nicht. Werde das mal ausprobieren.
Mir ist das schon wichtig. Z.B. kann ich mit älteren Scribus Versionen erstellte Dateien neuerer Versionen nicht öffnen. Da ist es mir schon wichtig jederzeit eine bestimmte Version zu nutzen.
 
Andy_m4 schrieb:
Evtl. Bastille:
https://bastillebsd.org/
Zum Vergrößern anklicken....

Sieht nach einer Automatisierungslösung für die Erstellung von Jails aus den FreeBSD-Ports aus. Ich sehe keine Lösung für die Anwendungsfälle von Flatpak (falls ich mich täusche, korrigiert mich):

Vielleicht übersehe ich es nur, aber vermisse auf den ersten Blick die Behandlung von 3rd-Party-Dependencies (d.h. es gibt keinen standardisierten Weg, auf ein wiederverwendbares Artefakt außerhalb der FreeBSD-Ports zu verweisen).

Ebenso vermisse ich die Möglichkeit, meine fertige Anwendung mit allen Abhängigkeiten außerhalb der Ports als Artefakt zu exportieren bzw. ein fertiges Artefakt in meinem System zu installieren. Ich sehe auch kein Repository-Konzept für die Verteilung der Software.

Die Versionskompatibilität vermisse ich ebenfalls, oder kann mit Bastille eine mit FreeBSD 12 erstellte Anwendung mit Abhängigkeiten zu FreeBSD 12 unter FreeBSD 11 laufen lassen, so wie das analog mit Flatpak geht?
 
Azazyel schrieb:
Sieht nach einer Automatisierungslösung für die Erstellung von Jails aus den FreeBSD-Ports aus.
Zum Vergrößern anklicken....
Sagen wir mal so. BastilleBSD ist eher die Antwort auf Docker als auf Flatpak. :-)
Dementsprechend hast Du mit Deinen Punkten auch nicht ganz Unrecht.
Anbei bemerkt habe ich BastilleBSD auch noch nicht selbst ausprobiert aber man liest in letzter Zeit häufig darüber.

Letztlich geht es darum, was man erreichen möchte und dann kommt man vielleicht auch mit herkömmlichen Lösungen schon recht weit.
Ein Entwickler der seine Anwendung verteilen möchte hat da sicher andere Bedürfnisse als ein Anwender.

Und wenn ich jetzt mal als reiner Anwender gucke was ich brauche, dann sind das nicht unbedingt Flatpaks oder Snaps. Denn eigentlich kriege ich alles was ich brauche an Programmen auch für FreeBSD. Worüber ich da stolpere sind zwei Dinge.

  1. Ich habe Konflikte in den Abhängigkeiten. Sowas wie: ein Programm braucht ImageMagick 6.9 und ein anderes aber ImageMagick 7. Beide Versionen von ImageMagick lassen sich aber nicht parallel installieren
  2. Ich möchte irgendeine Art von Sandbox haben weil ich z.B. Sicherstellen möchte, das Programm XYZ nicht ins Internet kommt oder meine Dateien sieht (zumindest nicht alle davon).
Beides lässt sich mit Jails lösen. Mein Setup dafür sieht so aus, das ich das als Thin-Jail mache. Das Basissystem was ich habe mounte ich einfach innerhalb der Jail, so das nur /etc/, /var/ und /usr/local/ Jail-spezifisch ist. In der Jail installiere ich mir dann mein Programm mit den Abhängigkeiten. Fertig.

Für sowas wie das angesprochene "brauche alte Scribus-Version" funktioniert das natürlich gut.

Theoretisch kann ich das Verzeichnis/Setup auch auf andere Rechner kopieren und hätte in dem Fall sogar etwas App-Container-Feeling. :-)
 
Die Probleme die da gelöst werden sind ja in der Linuxwelt relativ real:

Die große vielzahl an Linuxdistributionen bringen eine vielzahl an unterschiedlichen Paketen mit unterschiedlichsten Versionsnummern mit, oft auch noch mit verschiedenenen Sub-Optionen gebaut.

Und von dien vielen verschiedenen Distributionsspezifischen Updatezyclen e.t.c. will ich da noch garnicht sprechen. Und zu guter letzt die Software dann, sofern sie überhaupt den zig individuellen Lizenzansprüchen des distris gerecht wird, dann dort auch noch veröffentlich zu bekommen ... und was aktuelle versionen angeht immer auf den Maintainer zu hoffen ist gelinde gesagt - schwierig.

(Wer mal durch die Abhängigkeitshölle gegangen ist um eine ältere exotische Software zum fliegen zu bekommen weiß evtl. eher um was es geht)

Das ist eine schwierige Situation alles imho, ob die ganzen Lösungen ala Dokker aber wirklich der bessere weg sind ... denke das Thema ist auch kaum sinnvoll mit ja/nein zu beantworten :)

Sowas macht für OpenBSD aber z.B. imho wenig sinn, es gibt rel. fest Releasyzyklen und innerhalb dieser rel. feste Paketversionen von Patches für größere Sicherheitslücken mal abgesehen. (Mit FreeBSD kenn ich mich zu wenig aus).
Ich glaube auch kaum das irgend ein Entwickler von Software, OpenSource oder nicht, der flatpack oder dokker oder so verwendet extra für OpenBSD nen "OpenBSD Snap" extra erstellen würde, und ich glaube kaum das dies bei FreeBSD anders aussieht.
Ich meine damit, selbst wenn es sowas geben würde, heißt das ja nicht das automatisch irgendjemand ausserhalb der *BSD Welt son Ding "befeuert" - und das ist ja der eigentliche nutzen. Denke also das würde letztendlich wenig sinn machen und viele ressourcen verschlingen die man anderweitig besser verwenden kann.
 
hi

ich selber nutze zz .ubuntu auf meinen notebooks , openbsd fur firewall und freebsd fuer NAS und als Virtualisierungs Host.

Freebsd nutze ich seit ca. Version 3 ( oder seit der SusSE Version 4.4 , der beweggrund zu Wechseln )zu FreeBSD )

BSD ist für mich das bessere Linux , weil

* Evolution statt Revolution
* Kontinuität
* Struktur ( Aufbau und u.a.Trennung OS zu Userland )
* Es Funktioniert
* Transparenz.
* Dokumentation


Leider Funktioniert *Bsd Nicht sauber auf meinen Samsung 5 ( Probleme mit der Netzwerkkarte )
Und Als Desktop ist mittlerweile Ubuntu Bequemer als BSD.

Alleine da Thema Systemd ist zum .... ( ärger mich gerade mit einen seltsamen verhalten des sytemd-dhcp-client rum )

wenn Es ein Desktop Version von FreeBSD gibt welches mein Convertable Notebook Sauber und umfänglich Funktioniert,
würde Linux runterfliegen.

Holger

p.s. ich bin keine Linux hater , jedoch geht die entwicklung ,in meinen augen, in die falsche richtung
 
mark05 schrieb:
BSD ist für mich das bessere Linux , weil
Zum Vergrößern anklicken....
Oh nein, wenn dann "Unix" bitte. ;)

mark05 schrieb:
* Evolution statt Revolution
* Kontinuität
* Struktur ( Aufbau und u.a.Trennung OS zu Userland )
* Es Funktioniert
* Transparenz.
* Dokumentation
Zum Vergrößern anklicken....
Jo sehe ich genauso
mark05 schrieb:
Und Als Desktop ist mittlerweile Ubuntu Bequemer als BSD.
Zum Vergrößern anklicken....
Ubuntu war schon immer bequemer, aber immer wieder funktionieren Snaps nicht (z.B. momentan u.a. WoeUSB)
GhostBSD aber ist fast genauso bequem. Mit Hilfe meiner Notizen skalliere ich es mir in einer Minute.

mark05 schrieb:
Alleine da Thema Systemd ist zum ....
Zum Vergrößern anklicken....
Damit komme ich nie wirklich in Berührung, sprich ich merke bei Linux nicht wirklich was drunter ist, weil ich da kaum an irgendwelchen Schrauben drehen muss. Es funzt einfach out of the box.

mark05 schrieb:
wenn Es ein Desktop Version von FreeBSD gibt welches mein Convertable Notebook Sauber und umfänglich Funktioniert,
würde Linux runterfliegen.
Zum Vergrößern anklicken....
GhostBSD probiert? ich liebe es.

mark05 schrieb:
ich bin keine Linux hater , jedoch geht die entwicklung ,in meinen augen, in die falsche richtung
Zum Vergrößern anklicken....
Ich auch nicht, ich mag Ubuntu und ich mochte es auch schon immer (ausser das 14.04, damit hatte ich leider immer wieder Pech), weil es in meinen Augen das beste/einfachste Linux war/ist und viel bewegt hat. Dieses Gehate um die Amazon Suchapp hab ich z.B. nie verstanden. Dann macht man es halt weg und es kommt auch nicht mal eben wieder nach nem Update. Aber da sieht man halt dass manche einfach nur mies drauf sind und haten wollen.
 
@Andy_m4 : bzgl bhyve und Windows... Wenn du ein Tutorial hast oder kennst und die Sache für unerfahrene nicht zu komplex ist, gerne her damit. Momentan teste ich grad VBox.
 
Andy_m4 schrieb:
Ich habe Konflikte in den Abhängigkeiten. Sowas wie: ein Programm braucht ImageMagick 6.9 und ein anderes aber ImageMagick 7. Beide Versionen von ImageMagick lassen sich aber nicht parallel installieren
Zum Vergrößern anklicken....

Kommt sowas wirklich häufig vor? In UPDATING sollte eigentlich immer eine Lösung für derartige Konflikte beschrieben sein.
 
Bitte nicht noch so eine "was ist Unix und was nicht" Diskussion :o
Ist es Unix, wenn es eine direkte "Abstammungslinie" gibt? Dann ist FreeBSD ein Unix.
Ist es Unix, wenn es "aussieht" wie Unix und bestimmte Spezifikationen erfüllt sind? Dann ist FreeBSD ein Unix, ebenso wie GNU/Linux und so manch anderes.
Ist es Unix, wenn es das UNIX® trademark trägt/tragen darf (was übrigens neben der Anforderung, gewisse Spezifikationen zu erfüllen, vor allem regelmäßig Geld kostet)? Dann nicht.

Spielt das alles letztendlich eine Rolle? Also ich habe meine Meinung dazu...
 
Ein Greybeard sagte mir vor Jahrzehnten mal:

UNIX (R) - das sind die von HP, SUN, IBM (ob Irix von SGI dazugehörte, weiss ich jetzt nicht mehr)
Unix - das sind die, welche von UNIX abstammen, die BSDs usw
Unix-like/-artig - das sind die, welche wie ein Unix aussehen, z.B. Linux

In Literatur kann man manchmal die eine oder andere Schreibweise erkennen (bzw glauben, sie zu erkennen), ich denke aber nicht, dass es eine offizielle Regel dafür gibt.
Sollte auch keinen von irgendwas ab- bzw aufhalten.

Ich nutze heutzutage gerne den Mix (BSD und Linux) - und "echte" UNIX Betriebssysteme mittlerweile gar nicht mehr - und mir wäre es vermutlich mittlerweile auch egal, ob UNIX, Unix oder unix dahinter steckt.
Früher, wo gefühlt alles um mich rum Win war, war ich schon irgendwie stolz, auf UNIX zu arbeiten...
 
Lance schrieb:
bzgl bhyve und Windows... Wenn du ein Tutorial hast oder kennst und die Sache für unerfahrene nicht zu komplex ist, gerne her damit.
Zum Vergrößern anklicken....
So schwer ist es eigentlich nicht. :-)

Du brauchst ne UEFI-Firmware für bhyve.
Die kriegst Du sogar als Paket: uefi-edk2-bhyve

Dann brauchst Du noch eine virtuelle Festplatte, wo Du Windows drauf installierst. Das kann ein ZFS-Volume sein. Das kann aber auch einfach ne Datei sein, die Du Dir mit truncate erzeugst:

Code: 
truncate -s 16G my-win10.img
Wenn Du dann ein Win10-ISO-Image bei der Hand hast, kann es dann auch schon losgehen:

Code: 
bhyve -c 1 -m 4G -H -w \ 
-s 3,ahci-cd,/path/to/win10.iso 
-s 4,ahci-hd,my-win10.img \
-s 29,fbuf,tcp=127.0.0.1:5900,w=1024,h=768,wait \
-s 30,xhci,tablet \
-s 31,lpc \
-l com1,stdio \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
Win10
Zu den Parametern sehe auch die Manpage von bhyve
Die Bildschirmausgabe, Keyboard/Maus geht über VNC.

Code: 
vncviewer 127.0.0.1:5900
Es klappt allerdings nicht jeder VNC-Viewer. Mit TigerVNC hats bisher aber immer funktioniert.

Ich würde übrigens VNC nur zum installieren nehmen und danach auf RDP umsteigen. Funktioniert besser (Keyboard-Mapping, dynamische Fenstergröße). Denk daran: RDP gibts erst ab Windows Professional. Sonst musste die ein RDP-Server manuell installieren.

Wenn die Installation durch ist, würde ich noch zusehen als Gasterweiterungen die VirtIO-Treiber zu installieren.
VirtIO-Treiber für Windows kriegt man hier:

  1. https://github.com/virtio-win/kvm-guest-drivers-windows
  2. https://docs.fedoraproject.org/en-U...tual-machines-using-virtio-drivers/index.html
  3. https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso
Den Rest wie z.B. Netzwerk kannste so konfigurieren, wie im Handbuch beschrieben:
https://www.freebsd.org/doc/de_DE.ISO88591/books/handbook/virtualization-host-bhyve.html

Code: 
ifconfig tap0 create
sysctl net.link.tap.up_on_open=1
ifconfig bridge0 create
ifconfig bridge0 addm igb0 addm tap0
ifconfig bridge0 up
Also igb0 natürlich durch die Bezeichnung deines Netzwerkadapters ersetzen.
Dann kannste dann auch beim bhyve-Aufruf noch ein:

Code: 
-s 5,virtio-net,tap0 \
hinzufügen.

Ich hab bestimmt noch was vergessen. Aber zum starten bzw. Abschätzen des Aufwandes sollte es zunächst reichen. :-)
 
Zuletzt bearbeitet:
Andy_m4 schrieb:
So schwer ist es eigentlich nicht. :-)
Zum Vergrößern anklicken....
Wenn ich das lese, was danach folgt, dann scheint es schon schwer zu sein: wie mache ich das denn im laufenden System, also innerhalb meines Desktops, den ich ja nutze und brauche?
Vielleicht habe ich das nicht richtig verstanden, aber das sieht mir eher nach einer Lösung aus, die voll darauf abfährt, in der Ferne ein FreeBSD zu installieren, ihm die nötigen Moudule und Konfigs zu servieren und dann darauf das virtuelle System zu installieren und fortan zu betreiben.

Deshalb nachgefragt, ob ich das richtig verstehe:
kann ich meinen Desktop, also mein FreeBSD voll nutzen, wie ich das bei VirtualBox(VB) kann?
Also, ich arbeite ganz gewöhnlich auf meinem FreeBSD Desktop und nun kommt mir plötzlich ein Problem unter, wozu ich kurz mal ein Ubuntu brauche und danach möchte ich einmal im Jahr mit Win10 arbeiten und dann wieder einmal im Jahr mit XP und dann hat es sich aber wieder und ich brauche diese fremden OS nicht mehr.
Mit dem installierten VB kann ich das ganz normal als Programm aus meinem Desktop heraus starten.
Dann wähle ich ein virtuelles OS und vielleicht ein zweites oder drittes und arbeite meine Dinge damit ab. Danach schließe ich diese virtuellen OS und anschließend sogar VB und arbeite dann ganz normal auf meinem Desktop weiter und wenn ich mal wieder was in einem Windows/Ubuntu/sonstwas machen muss, dann starte ich ich eben wieder VB und einen entsprechenden Guest und beende den wieder, nachdem ich fertig bin und arbeite dann auf meinem Desktop weiter.

Für mich sieht es nicht so aus, als wenn das ein bhyve-typisches Szenario ist.
Mein Eindruck ist eher, dass man ein FreeBSD nutzt, mit bhyve eine VM erstellt, WIN10 oder andere rein legt und diese dann für alle Zeiten sorglos betreibt. Also FreeBSD als Unterbau, bhyve als Virtualisierung und darauf diverse Systeme,
aber nicht
FreeBSD als Desktop-System und bhyve als zusätzliches Programm, das innerhalb des Desktops beliebig gestartet und benutzt werden kann, virtuelle Systeme gestartet und beendet werden können und bei Bedarf wieder gestartet und dann auch die VM beendet und wieder gestartet werden kann, ohne jemals den Desktop mit FreeBSD als Host zu verlassen oder eine Arbeit unterbrechen zu müssen?

Wie schon mal gesagt, fehlt mir der Antrieb, mich näher damit zu befassen, weil es eine FreeBSD-only Lösung ist und ich auch andere Systeme nutzen möchte und da jeweils die gleiche Virtualisierung haben möchte.
Nur zu meinem Verständnis.
Könnte ich ein GUI zu bhyve auf meinem Desktop starten und dann irgendein System in meiner laufenden Desktop-Sitzung benutzen, Daten austauschen und dann wieder beenden und mit meinem FreeBSD-Desktop weiter arbeiten, bis ich mal wieder was in einem virtuellen OS machen möchte?
So, wie ich GIMP immer mal wieder starte und beende, um gerade mal was an einem Bild zu verändern.
Denn so nutze ich auch VB.

Geht das mit bhyve überhaupt?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben