Notiz - FreeBSD 13.0: Das unixoide Betriebssystem erhält ein großes Update (2024)

ghecko schrieb:

Oh man, jetzt hab ich wieder einen Grabenkampf losgetreten.

Zum Vergrößern anklicken....

Ha, das geht viel schneller als einem lieb ist

Auf Koexistenz können wir uns sicher einigen. Linuxbasierte OE haben sich dank der viralen gpl schnell verbreitet und bsd hat die Kommerzialisierung vorangetrieben, beide zusammen haben passende Entwickler bei ihre Enstellung abgeholt (Freiheit Code vs Freiheit Entwickler).

Dennoch ist BSD die Betriebsumgebung und Linux das Kernel. Bsd braucht keine coreutils, nutzt auch keine coreutils; Linuxbasierte OE sind drauf angewiesen oder müssen dropins verwenden.

Ja, bsd versucht gpl code aus dem Quellcode loszuwerden. Bei Linux war das nie zugelassen, deren Problem ist genau andersherum gelagert.

Warum auch nicht? Mehrere inkompatible Lizenzmodelle sorgen immer für Extraaufwand bei größeren Änderungen, und sei es nur, weil Komponente A nicht mit dem neu einzuführenden B zusammen arbeiten darf. Da müßte man jedes Mal den gesamten Code wälzen, was wo mit geht: unnötiger Extraaufwand.

Und ja, Linux wird von Unternehmen immer noch mißbraucht; jedes Mal wenn es als OS verwendet und dazu verändert wird. Da wäre bsd die richtige Wahl, aber lieber setzt man sich wohl Klagen aus.

andy_m4 schrieb:

Wobei man für DNS-based blocking kein PiHole braucht. Das geht mit jedem DNS-Server. PiHole ist ja letztlich nix anderes als ein dnsmasq (garniert mit vorgefertigen Listen und WebGUI). Und das kriegste auch auf FreeBSD zum laufen. :-)

Zum Vergrößern anklicken....

Es ist schon etwas mehr. Zusammen mit pihole-updatelist habe ich kuratierte Listen mit Listen sozusagen. Wenn es etwas vergleichbares gäbe, dann würde ich den Pihole absägen und zB direkt unbound nehmen.

Salamimander schrieb:

Zusammen mit pihole-updatelist habe ich kuratierte Listen mit Listen sozusagen. Wenn es etwas vergleichbares gäbe, dann würde ich den Pihole absägen und zB direkt unbound nehmen.

Zum Vergrößern anklicken....

Ich verstehe gerade Dein Problem nicht bzw. warum das z.B. mit unbound nicht gehen sollte.

Okay, ich mache es mal etwas präziser:

Folge Punkte sind aktuell ohne PiHole in der Art nicht möglich:

1.) https://v.firebog.net/hosts/lists.php?type=nocross --> Ticket Lists. Ja das kann man sich selber bauen, bringt aber viel impact mit (Duplikate entfernen usw, mehr Aufwand als man denkt, habe sowas schon fürs pihole seinerzeit gebastelt)
2.) Client basierte Blacklists bzw Whitelists. Ich kann beim pihole für meine Frau ihren Facebookmist (Für Instragram schauen) freigeben und bei mir blockiert lassen. Bietet der Rest nicht
3.) WebUI. Auch bietet mir zB der Unbound (Meine präferierte Lösung, da ich ihn eh schon als Recursive Resolver hinter dem pihole einsetzte) keine möglichkeit, bei Problemen mit Websiten schnell nach zu schauen was gerade beim Client XY geblockt wurde. Wie oft PayPal nicht geht weil man irgendeinen Tracker blockiert... Ein Hass..

Gerade Punkt 3 ist etwas, wo ich nicht Kompromissbereit bin. Mit 1 und 2 könnte ich leben

@andy_m4, ich glaube Du hast mich nicht verstanden:
Es geht nicht darum, ob es einfach oder zu schwierig zu implementieren wäre. Längst nicht jeder würde es selbst schreiben wollen, auch falls er könnte.
Auch geht's nicht darum, ob alle oder einige benötigte Komponenten bereits verfügbar sind.
Die Frage ist, ob jemand diese Lösung bereits für BSD zusammengebracht und verfügbar gemacht hat - und die Antwort ist scheinbar Nein.

Das ist der Unterschied zwischen "geht nicht" und "gibt's nicht", oder noch nicht jedenfalls.

foo_1337 schrieb:

Dafür ist macOS, was deutlich verbreiteter als GNU/Linux auf dem Desktop ist, dank seiner Vorfahren Next- und OpenStep BSDish

Zum Vergrößern anklicken....

Nicht nur das, es ist sogar ein zertifiziertes UNIX. Nicht nur unixoid.

Muffknutscher schrieb:

Es ist zwar schön, das hier die News aufgegriffen wird, aber leider fehlen so ziemlich alle Hintergrundinformationen.
Was nicht erwähnt wurde, ist das z.b. wireguard komplett entfernt worden ist, weil der Code so grottig war.
Wer sich dafür interessiert, sollte sich diesen Artikel durchlesen:
https://www.heise.de/news/FreeBSD-1...e-Tools-und-viel-WireGuard-Drama-6015871.html

Zum Vergrößern anklicken....

Aber wenn ich richtig bin ist der Code von Wireguard gut nur dss implementieren war unterirdisch seitens FREE BSD bzw auch pfsense als endplattform

@Obreien
Hier ein Auszug aus dem Artikel:

WireGuard-Entwickler Jason Donenfeld unterzog den in FreeBSD eingefügten Code einem Audit und fand verheerende Fehler: Sleep-Befehle, um Timing-Probleme im Protokoll zu beheben, Validierungsfunktionen, die einfach nur "true" zurückgaben, löchrige Kryptofunktionen, Teile des Protokolls, die nicht implementiert waren, Tricks, um Sicherheitsfunktionen zu umgehen, Überläufe von Variablen bis hin zu leicht über ein einzigen IP-Paket mit zu großer MTU-Size reproduzierbaren Kernel Panics. Die WireGuard-Implementation für FreeBSD war schlicht unbrauchbar – der gesamte Code flog aus dem Kernel und das RELEASE musste verschoben werden

Salamimander schrieb:

Okay, ich mache es mal etwas präziser:

Zum Vergrößern anklicken....

Vielen Dank für Deine Ausführungen. Jetzt ist klarer geworden, was Du meinst.

Salamimander schrieb:

(Duplikate entfernen usw, mehr Aufwand als man denkt, habe sowas schon fürs pihole seinerzeit gebastelt)

Zum Vergrößern anklicken....

Jein. Nicht wirklich. Jede halbwegs brauchbare Programmiersprache bringt dafür bereits die passenden Bibliotheksfunktionen mit.

Salamimander schrieb:

Client basierte Blacklists bzw Whitelists

Zum Vergrößern anklicken....

Geht z.B: mit unbound auch.

Salamimander schrieb:

keine möglichkeit, bei Problemen mit Websiten schnell nach zu schauen was gerade beim Client XY geblockt wurde.

Zum Vergrößern anklicken....

Gut. Aber das siehst Du ja auch im Browser (der dafür eh die bessere/komfortablere) Infoquelle ist.
Ansonsten lässt Du Dir halt das unbound-Log anzeigen.

Ich möchte ja gar nicht in Abrede stellen das Pi-Hole eine nette Lösung ist und auch einen gewissen Komfort bietet (und damit DNS-based Blocking auch einem größeren Anwenderkreis zugänglich macht).
Aber es ist jetzt nicht so, das man es dringend bräuchte und absolut alternativlos ist.

Shagrath schrieb:

Längst nicht jeder würde es selbst schreiben wollen, auch falls er könnte.

Zum Vergrößern anklicken....

Wie schreibst Du eigentlich Deine Texte? Wenn Du dem Gesagten keine fertigen Textblöcke da sind, geht es halt nicht? :-)

Shagrath schrieb:

Die Frage ist, ob jemand diese Lösung bereits für BSD zusammengebracht und verfügbar gemacht hat -

Zum Vergrößern anklicken....

Das kann ich nicht beantworten.
Aber Pi-Hole ist kein Selbstzweck. Man möchte damit etwas erreichen. Und das was man damit machen will, geht sehr wohl.

foo_1337 schrieb:

Das Problem bei pihole ist FTL: Es gab schon Portierungsefforts, aber der Maintainer will kein #ifdef blabla in seinem code haben und so bleibt es linux only

Zum Vergrößern anklicken....

Wobei man gucken könnte, ob es mit dem Linux-Compatibility-Layer funktioniert. Der wurde ja schon im Zuge von FreeBSD 12 deutlich verbessert, so das es inzwischen recht easy ist z.B: ne Linux-Jail zu machen.

Bemerkenswert an solchen Geschichten finde ich ja immer:
Früher haben sich die Linuxer aufgeregt, das viele Programme Windows-only waren statt einfach das plattformunabhängig zu programmieren.
Inzwischen haben wir die Situation das im Linux-Umfeld selbst viel schwer-portabler Code produziert wird. Und damit mein ich jetzt nicht nur so Sachen wie systemd (im Gegenteil; das können die sehr gern bei sich behalten ).

@andy_m4 stimmt, compat_linux wäre auch eine Option. Aber schon blöd, dass der Maintainer das so sieht. Das fbsd PoC ist übrigens hier zu finden: https://github.com/freqlabs/FTL/tree/freebsd-wip
Das war wohl auch funktional, aber wie gesagt, der Porter (von iXsystems) hatte dann keinen Bock mehr, nachdem ihn der Maintainer abgewiesen hat. Verstehe ich auch, wenn man das dauerhaft forken muss, ist das ein vergleichsweise hoher Aufwand.
Und die Hauptänderungen sind sehr überschaubar: https://github.com/freqlabs/FTL/commit/1b9c3d773be171cbeffa15dd5a5f9a89b820451b

Aber pihole ist halt auch frickelsoftware... wie alles, was man via curl | sudo sh - installieren soll... Aber so tickt halt leider viel heute

Im Grunde ist Pi-Hole schon in Ordnung, weils halt auch Leuten mit nicht so tiefgehenden Kenntnissen ermöglicht DNS-based Blocking zu machen.
Ich sag mal: für den ambitionierten Laien. Der in Windows herum klickt und auch ein ubuntu unfallfrei installiert kriegt. Für den ist das eine feine Sache.

Das es Pi-Hole für FreeBSD nicht gibt sehe ich daher nicht so dramatisch. FreeBSD ist ein System von Profis für Profis. Wer FreeBSD einsetzt der weiß in der Regel was er tut. Der hat dann natürlich auch kein Problem damit sich mal an irgendwelchen Konfigurationsdateien oder Skripten die Hände schmutzig zu machen. Er wird das schon allein deshalb machen, damit er das Blocking in seine übrige Konfiguration einfügen kann. Pi-Hole kommt ja auch eher als komplette Appliance daher, die alleinstehend auch am besten funktioniert.

foo_1337 schrieb:

Und die Hauptänderungen sind sehr überschaubar:

Zum Vergrößern anklicken....

Wenn Du schon Condionals a-la #ifdef brauchst ist das meist kein gutes Zeichen was die Portierbarkeit der Software angeht. Das ist so wie Browser-Weiche (die hat selbst unter den Web-/Javascript-Fricklern inzwischen einen schlechten Ruf!). :-)
Gut manchmal kommt man nicht drum herum. Man sollte es aber nicht ausarten lassen.

bash voraussetzen ist so ein typischer Linuxismus. Gut. POSIX-Shell hat schon seine Beschränkungen. Aber bei so einem simplen Skript fragt man sich natürlich schon, was das soll.
Wobei solche Sachen ja meist keine böse Absicht sind oder so. Das passiert einem schnell wenn man halt nur unter einem System unterwegs ist und nicht über den Tellerrand schaut.

Wenigstens so hin und wieder sollte man mal seinen Kram auf einer anderen Plattform compilieren und laufen lassen damit einem solche Dinge auffallen. Für viele Sachen ist es nämlich eigentlich nicht schwer auf Plattformneutralität zu achten. Und wenn man das regelmäßig macht hat man erst gar nicht das Problem, das man in solche Sachen reinläuft und das ohne das man mehr Aufwand hat.

Wobei jetzt hier in dem konkreten Beispiel die Änderungen tatsächlich

überschaubar sind. Weiß gar nicht, warum sich da die Entwickler querstellen.

@andy_m4 naja, bei pthreads war das schon immer so ein Thema. Ich bin da mittlerweile raus, aber so um 2004-2006 rum, zu FreeBSD 5.x/6.x Zeiten, haben wir damals auch viel optimiert um MySQL performanter zu bekommen. Da hatte man dann die wahl zwischen linuxthreads, pthreads(3) und libthr. Da gabs dann natürlicch auch viel #ifdef, die dann durch configure flags jeweils griffen oder eben nicht.
Er hier scheint hier sowohl pthreads wie auch libthr zu nutzen. Hab's mir aber im Detail nicht angeschaut, da ich auch unbound mit views dafür nutze.

Aber geil bei pihole ist alleine, dass du dem lighttpd nicht ohne weiteres sagen kannst, dass er gefälligst auf einer spezifischen IP/IF lauschen soll. Bzw. es geht schon, aber die config wird halt gnadenlos beim pihole update überschrieben. Bei sämtlichen anderen Configs auch. Geht zwar via hacks irgendwie, aber man sieht halt, dass die Maintainer sich über Standards bzw. Packaging null gedanken machen. Einfach shellscript ausführen und drüber bügeln..

foo_1337 schrieb:

bei pthreads war das schon immer so ein Thema.

Zum Vergrößern anklicken....

Es kann immer valide Gründe geben. Aber oftmals hast Du halt auch so Sachen, wo es eben unglücklich ist.

foo_1337 schrieb:

Er hier scheint hier sowohl pthreads wie auch libthr zu nutzen.

Zum Vergrößern anklicken....

Eigentlich gibts heutzutage nur noch in Ausnahmefällen Gründe auf was anderes als pthreads zu setzen. Da gibts auch nicht direkt ein Problem. Eher so an dem drum herum.