GhostBSD vs Debian

Schade aber, dass GhostBSD - wohl im Gegensatz zu FreeBSD - keinen SecureBoot signierten Bootloader hat.
Ich habe bei Debian auch kein SecureBoot aktiviert, ich halte die Einschätzung der Bedeutung von SecureBoot für übertrieben. Ein richtig gutes OS kommt ohne aus.
das hat mit dem Thread-Verlauf bisher doch gar nichts zu tun? Oder?

hat es also doch irgendwie und ich hatte das übersehen.
Anstatt meinen diesbezüglichen Beitrag zu löschen, entschuldige ich mich und wir machen halt weiter, wie gehabt.
 
Ich bin ein grosser Fan von minimalen und aufgeraeumten Systemen. Mit Debian komme ich daher nicht gut zurecht. Ich installiere ein Paket, welches sagen wir 20 abhaengige Pakete mit installiert. Wenn ich das Paket nun deinstalliere (remove, purge, autoremove), dann werden nur sagen wir 6 abhaengige Pakete deinstalliert. Die anderen lassen sich auch nicht mehr deinstallieren. Wenn man das nachtraeglich versucht, will Debian das halbe System deinstallieren. Ich habe auch noch nicht herausgefunden, wie man sowas sauber macht. Daher nutze ich andere Linux-Distributionen, wenn es nach Bedarf ein Linux sein soll.
 
Ich bin ein grosser Fan von minimalen und aufgeraeumten Systemen. Mit Debian komme ich daher nicht gut zurecht. Ich installiere ein Paket, welches sagen wir 20 abhaengige Pakete mit installiert. Wenn ich das Paket nun deinstalliere (remove, purge, autoremove), dann werden nur sagen wir 6 abhaengige Pakete deinstalliert. Die anderen lassen sich auch nicht mehr deinstallieren. Wenn man das nachtraeglich versucht, will Debian das halbe System deinstallieren. Ich habe auch noch nicht herausgefunden, wie man sowas sauber macht. Daher nutze ich andere Linux-Distributionen, wenn es nach Bedarf ein Linux sein soll.
Wenn Debian das halbe System deinstallieren will, weil du eine Abhängigkeit eines bereits gelöschten Paketes entfernen willst, dann haben diese Pakete ebenfalls diese Abhängigkeiten. ME ist dein System damit nach deiner Definition sauber und schlank. Ob diese Abhängigkeit zwingend erforderlich ist oder man die Pakete schlanker hätte bauen können, ist für mich ein anderes Thema. Kurzum: imho machst du das bereits sauber.
 
Wenn ich das Paket nun deinstalliere (remove, purge, autoremove),
mach das doch mal in einer FreeBSD-Installation.

Es wird recht ähnlich aussehen (die Befehle sind natürlich ein klein wenig anders).

Die Abhängigkeiten aller Pakete (Third-Party-SW) sind nicht besonders affin zu dem verwendeten OS. Entsprechend räumen die einhergehenden Befehle auch in jedem OS auf und entfernen unbenutzte Pakete und Abhängigkeiten.

FreeBSD bietet hier keinen zusätzlichen Schutzmechanismus und ich sage mal: Gott sei Dank!
Denn der über-vorsichtige Schutz vorhandener SW wäre in aller Regel ein Verstoß, gegen die ständig einfließende Fehlerbereinigung.
 
Ich bin ein grosser Fan von minimalen und aufgeraeumten Systemen. Mit Debian komme ich daher nicht gut zurecht. Ich installiere ein Paket, welches sagen wir 20 abhaengige Pakete mit installiert. Wenn ich das Paket nun deinstalliere (remove, purge, autoremove), dann werden nur sagen wir 6 abhaengige Pakete deinstalliert. Die anderen lassen sich auch nicht mehr deinstallieren. Wenn man das nachtraeglich versucht, will Debian das halbe System deinstallieren. Ich habe auch noch nicht herausgefunden, wie man sowas sauber macht. Daher nutze ich andere Linux-Distributionen, wenn es nach Bedarf ein Linux sein soll.


Todesmutig auf Fedora eben getestet - wieso ich mit Debian meine Probleme habe, würde einen eigenen Thread füllen - dnf in libreoffice installiert mir 95 Pakete, dnf rm libreoffice deinstalliert mir 95 Pakete. Generell wäre mir auch kein gegenteiliges Verhalten aufgefallen.
 
mach das doch mal in einer FreeBSD-Installation.

Es wird recht ähnlich aussehen (die Befehle sind natürlich ein klein wenig anders).
Ist da aber nicht der Unterschied, dass FreeBSD das System (was ja via freebsd-fetch und freebsd-update aktualisiert wird) von den Paketen (pkg) trennt? Bei Debian wird ja ALLES per apt installiert und aktualisiert.

Da gefällt mir die FreeBSD Trennung deutlich besser!
 
Ich nutze sowohl Debian als auch FreeBSD seit diversen Jahren. Auf dem Desktop, hat Debian bei mir inzwischen FreeBSD verdrängt. Auf dem Server betreibe ich FreeBSD weiterhin gerne. Aber auch dort, hat Debian - FreeBSD bei mir den Rang abgelaufen.

Es kommt wie immer auf deinen Anwendungsfall an, wann für dich welches OS die bessere Wahl ist. Debian hat für mich die breitere Hardware-Unterstützung und läuft out-of-the-box einfach für meinen Bedarf "besser" und bietet mir die Möglichkeit auch properitäre Software zu nutzen. Viele Hersteller bieten leider keine Unterstützung für FreeBSD, da stößt man schnell an Grenzen, wenn man darauf angewiesen ist.

Secure Boot, Measured Boot und Trusted Boot sind eine ganz andere Geschichte (wie CommanderZed schon erwähnte) und aus Security-Perspektive leider alternativlos.
 
Ich wollte ein Spiel unter Debian spielen, dass unter Ubuntu immer reibungslos lief. Unter Debian musste ich zusätzlich einen kompatiblen Audioserver installieren.
Beim ersten Start ging der Sound, danach nie wieder. Unter Ubuntu: keine Problem.

Wenn ich also Proprietäre Software (inkl. Spiele) benutzen möchte, komme ich um Ubuntu nicht herum. Es wird einfach besser unterstützt.

Hätte Ghost- oder FreeBSD eine angenehme Möglichkeit, Bluetooth Geräte einzubinden und zu trennen, würde ich es - kompatible Hardware vorausgesetzt - Ubuntu und erst recht Debian vorziehen. ZFS soll unter FreeBSD stabiler und unproblematischer funktionieren.
Spielen tu ich eh kaum noch, und dann eher ältere Games, die mit Wine laufen.

Edit: ach ja, Rquickshare bräuchte ich auch noch.

Ich hoffe dieser Post von mir wird der Überschrift gerecht.
 
Ist da aber nicht der Unterschied, dass FreeBSD das System (was ja via freebsd-fetch und freebsd-update aktualisiert wird) von den Paketen (pkg) trennt? Bei Debian wird ja ALLES per apt installiert und aktualisiert.
natürlich gibt es einen Unterschied!
Wenigstens einen!
FreeBSD ist in sich selbst geschlossen und besteht immer aus FreeBSD. GNU/Linux gibt es in der Form einfach gar nicht (also mit Ausrufezeichen versehen: das GNU/Linux!). Es gibt einfache update-Mechanismen für FreeBSD, es gibt aber keine einfachen Update-Mechanismen für GNU und Linux, weil es eben gar kein verbindliches GNU/Linux überhaupt gibt.
Hier muss man also selbst ein System einrichten und die jeweiligen Komponenten von Hand aktualisieren, was ich gerne mal probiert hätte, woran ich aber immer wieder gescheitert bin.
Oder, man vertraut irgendeiner der super zahlreichen Distributionen und dem, was die aus Linux und GNU und weiterer SW zusammen gestellt haben. Ich sage das mal ein wenig platt: jede Distribution im GNU/Linux-Land nutzt einen angepassten Kernel, also ein Linux mit eigenen Patches und eine GNU-Version, die gerade passend war und dann spickt sie dieses alles auf und setzt ein Paket-System mit Third-Party-Erweiterungen darauf und sorgt meist dafür, dass dies alles von einem unbedarften User auch mit Updates versorgt werden kann.

Man versteht den Unterschied?
FreeBSD kann aufteilen und sagen, hier ist mein FreeBSD, das Kernel und Unix enthält und das wird von uns veröffentlicht und ihr dürft auch Tools nutzen, um zusätzliche SW zu installieren.
GNU/Linux Distributionen könnten auch unterscheiden und separate Updates für Linux und Gnu fahren und dann auch ein getrenntes Paket-System anbieten und manche machen so etwas in der Art sogar. Die meisten verzichten aber darauf und sagen, wir liefern ein Komplett-Paket und Updates schließen halt auch das Komplett-Paket ein, was aber bedeutet, dass der Kernel der Distribution und das GNU der Distribution und die Pakete aus dem Repositrie der Distribution upgedatet werden. Die Updates sind hier also immer Distributions- Spezifisch. Deshalb macht es aber auch großen Sinn, dass jede Distribution mehr oder weniger an eigenen Mechanismen zum Update fest hält.

Jedoch, abseits von FreeBSD und GNU/Linux sind die Abhängigkeiten der zusätzlich installierten Pakete relativ identisch und es macht gar keinen Unterschied, ob die in /usr/local/bin oder gleich in /bin installieren, die Abhängigkeiten werden ja je Paket geführt.
Die Trennung, die man bei FreeBSD für einen großen Vorteil hält, haben viele Entwickler für andere Systeme so nicht gesehen und weil sie auch eh von der untersten Stufe aus nicht die saubere Trennung haben, die es bei FreeBSD inhärent gibt, verzichten sie halt oft ganz darauf.

Das Problem daraus ist gar keines!
Technisch gesehen funktionieren beide Varianten ausgezeichnet und Probleme entstehen nicht an dieser Stelle.

Mir gefällt es besser, wie FreeBSD das macht.
Aber ich sehe gar keinen Nachteil darin, dass diverse GNU/Linux-Distributionen das anders machen und alles ihrem wohl erprobten Update-Tool überlassen.
FreeBSD sieht darin vermutlich auch keinen Nachteil, denn es entwickelt ja sein einiger Zeit ein ähnliches Tool, das binär FreeBSD und alle Pakete in einem Rutsch (mit dem gleichen Mechanismus) updaten kann.
 
FreeBSD sieht darin vermutlich auch keinen Nachteil, denn es entwickelt ja sein einiger Zeit ein ähnliches Tool, das binär FreeBSD und alle Pakete in einem Rutsch (mit dem gleichen Mechanismus) updaten kann.
Also doch. Ich dachte mir schon, war da nicht was? Aber das kann ich nicht ganz nachvollziehen, wo da der Vorteil sein soll. Das braucht man mir auch nicht erklären, weil ich es zu 90% nicht verstehen werde.
 
Aber das kann ich nicht ganz nachvollziehen, wo da der Vorteil sein soll. Das braucht man mir auch nicht erklären, weil ich es zu 90% nicht verstehen werde.
vielleicht doch:
bisher hast du zu einem "binären" Update zwei Befehle
freebsd-update für FreeBSD
pkg upgrade für die zusätzlich installierte SW.

pkg upgrade ist aus der Reihe der Befehle, die mit dem damals neuen pkgng, dem Pakete-Verwaltungssystem von FreeBSD kamen. Dies bezieht sich nur auf zusätzlich installierte SW, also Dinge, die sich in den Ports finden und für die es eben fertige Pakete auf den Servern gibt. pkgng ist ein FreeBSD - Tool, ich sage mal, ein FreeBSD Urgewächs, was aber ziemlich doof beschrieben ist.

Für den Binärupdate des eigentlichen Systems, also für FreeBSD, gibt oder gab es lange Zeit nichts außer einen Plan und deshalb hat sich Colin Percival daran gemacht und eine Art Notlösung in Form eines Scripts gebastelt, eben freebsd-update.
Wie gut oder schlecht es ist, will ich nicht erst diskutieren, aber ich traue mich mal zu der Äußerung, dass es im Vergleich zu pkgng ziemlich plump und unelegant ist, eben ein "einfaches" Script.

Ich weiß nicht, ob die Leute bei FreeBSD den Vorteil eines binären Systemupdates nicht zu würdigen wissen und eher glauben, dass es doch kein Ding ist, die Sourcen aus zu checken und mal ein make config und install darauf laufen zu lassen oder ob sie vielleicht mit der Lösung durch freebsd-update schon zufrieden sind oder ob sie einfach sowieso mit ihren Plänen eher überlastet sind und deshalb so einer Kleinigkeit keine Aufmerksamkeit schenken. Aber ganz gewiss steckt hier der Teufel auch im Detail und es geht nicht nur darum, einen fertig gebackenen Kernel mal via remote irgendwo hin zu kopieren.
 
Ok, scheint alles einleuchtend. Aber dieses „einfache, plumpe Script“ funktioniert doch tadellos, oder nicht? Sonst würde man es doch nicht Jahre oder über ein Jahrzehnt so belassen.
 
Ok, scheint alles einleuchtend. Aber dieses „einfache, plumpe Script“ funktioniert doch tadellos, oder nicht? Sonst würde man es doch nicht Jahre oder über ein Jahrzehnt so belassen.
für mich funktioniert es sei etwa FreeBSD-6.0 oder so, als es noch nicht zu den offiziellen Tools gehörte und ich bin dafür sehr dankbar.
Insofern hat die manchmal geäußerte Kritik eben hauptsächlich ideologischen Charakter, aber tatsächlich hätte ein entsprechendes Tool auch die Möglichkeit, besser, schneller und sicherer zu funktionieren.

Mein Vergleich trifft vielleicht nicht so gut, aber wenn du Ports benutzt, musst du den Ports-Tree aktuell halten. Dazu kannst du zB portsnap fetch und update benutzen, was sehr gut funktioniert, vor allem im Vergleich zu Vorgängern. Du kannst es aber auch über git mit einem einfachen git pull machen und der Unterschied ist etwa, wie zwischen Pferdekutsche und modernem Elektro-Auto.
 
Ok, scheint alles einleuchtend. Aber dieses „einfache, plumpe Script“ funktioniert doch tadellos, oder nicht? Sonst würde man es doch nicht Jahre oder über ein Jahrzehnt so belassen.

Gab erst vor wenigen Tagen einen Thread, wo eben eine Funktion dieses plumpen Scriptes nicht funktioniert hat.

Allgemein hab ich dann die ganzen Möglichkeiten von pkg, also ich kann ein Paket locken, ich kann ein Paket auf integrität checken, ich kann ein Paket neu installieren. Derzeit alles nicht möglich.
 
Zurück
Oben