LibertyBSD

Ist ja auch ein wahnsinniger Unterschied, ob ich die"unfreie" Firmware nun beim Attach auf das Device lade oder die beim Attach aus dem ROM ins Device geladen wird.
 
Nuja, wenn zum Beispiel das Netzwerkgerät von OpenBSD nicht erkannt wird, weil es unfreie Firmware braucht, ist das schon nicht mehr ganz so einfach.
 
Die Idee & Absicht dahinter find' ich nicht schlecht.
Darüber wie's umgesetzt wird, möchte ich mir kein Urteil anmassen.

Für Manche vlt. ganz nützlich.
 
Ich find's etwas schade, weil es mal eine Funktion gab um die Blobs nicht zu installieren und diese ja auch auf der Website des Projekts erwähnt wird sogar mit den genauem Commit. Ich glaube, dass man die eine Frage einfach wieder hinzufügen könnte und nicht gleich einen Fork macht. Oder man baut einfach gepatchte Installationsmedien.

Bin mir nicht sicher, wie das in der Community ankommen würde, aber im Hinblick "Kontrolle über das System" haben zu wollen finden das vielleicht auch die Core-Developer ganz okay, gerade weil die ja auch nicht gerade Freunde von Blobs sind. Andererseits eben Pragmatismus. Wer will ein nicht funktionierendes System?

Im Endeffekt wäre es wohl am Sinnvollsten das Problem mit Reverse Engineering, etc. zu bekämpfen, Dokumentation oder Source Code zu fordern. Zumindest erscheint es mir eher dem Ziel von BLOB-freier Software zu entsprechen, als ein System zu haben wo Dinge nicht funktionieren.

Das einzig Gute daran ist, dass es aufzeigt, dass es immer noch ein Problem gibt, wenn man ein System haben will, das durchgehend Open Source ist. Es gibt einfach echt viel Zeug, das einem in die Quere kommt (man denke auch an Dinge, wie Basebands). Selbst mit einem Raspberry Pi ist man drauf angewiesen, offene Basebands existieren quasi nicht und im Endeffekt geht es leider viel zu oft um blindes Vertrauen.
 
So gut mir die grundsätzlich Idee gefällt:
Was bringt einem das, wenn die darunter liegende Hardware nicht offen ist. Wer weiß bitteschön, was z.B. Netzwerkkarten in ihrer Hardware machen? Das einzige was (wenn überhaupt) offen ist, ist der Treiber, und der bedient nur die Schnittstellen.
Hmm....
 
Das ist es ja. Es ist häufig kaum was offen, weder Treiber noch Firmware. Hardware ist nochmal ein anderes Thema. Da ist es schwer rauszufinden, was die im Detail macht. Je nachdem was das für eine Hardware ist kann man das etwas eingrenzen. Es geht halt um Vertrauen. Dem Baseband auf einem Phone zu vertrauen ist eher was was man nicht tun will. Wenn ein Gerät mit dicker, Closed Source Firmware kommt, die ein Eigenleben führt dann macht mich das stutzig. Im Endeffekt kann man der Hardware aber auch mit offenen Treibern und offener Firmware nicht einfach so vertrauen. Aber es wäre halt cool für so kleine Geräte, die sehr weit verbreitet sind, die einigermaßen (naja, nicht wirklich) überschaubar sind und wo auch Forschungseinrichtungen viel mit arbeiten.

Der Raspberry Pi ist da finde ich ein echt tolles Beispiel. Die Userbase ist groß, alle wollen es unterstützen, hacken, etc., aber die Hardware ist alles andere als offen, nicht mal der Bootprozess ist offen. Das ist ziemlich schade, weil alle immer von Trusted Devices reden und es im Endeffekt darum geht blind zu vertrauen. Okay, TPM ist das nächste Thema, aber im Grunde geht es in eine ähnliche Richtung, die aufzeigt, dass man ja eigentlich Hardware will, der man vollkommen vertrauen kann.

Klar, man sollte sich keinesfalls einbilden, dass weil Doku existiert man absolut sicher sein kann, dass das System macht, was man will und nichts anderes, aber es geht darum dass man zumindest möglichst stark in die Richtung kommt und wenn man eben ein Gerät hat, das breite Verwendung hat wie der RPi und das von Hackern, der Industrie, Forschungseinrichtungen/Universitäten genutzt wird, dann ist die Hürde da was zu verstecken, obwohl Code und Doku da sind entsprechend groß. Man weiß ja nicht wo vielleicht jemand rumfummelt und die Chance ist nochmal größer mit Doku und Source.

Die nur zu löschen hilft da nicht. Deshalb mein Statement vom vorigen Beitrag. Was hilft ist Druck (oder Anreiz), Reverse Engineering bzw. alternativen Code schreiben oder eben entsprechendes Absichern, des Blobs oder der Hardware, was ja zum Beispiel mit Baseband Firewalls und "nicht nur blind auf Random von Intel CPUs hören, wie vorgeschlagen" auch passiert.
 
Da hat wohl einer den Unterschied zwischen Firmware und Kerneltreiber nicht verstanden, reißt einfach raus, was er nicht kennt und packt das Ganze gleich als komplett neues BSD zusammen, anstatt 10 Zeilen diff fürs Makefile bereitzustellen.

Genius.

Edit: FTP-Server ist auch down. Großartiges Projekt Marke trotziger Teenager. Aber Hauptsache Ads auf die Seite kleistern.
 
Ich seh nur "a-ads.com" im RequestPolicy. Ich denke mal, dass das Werbung ist. Gesehen hab ich natürlich auch keine.
 
Hm. Im praktischen Einsatz, wie ich denke, eher minder sinnvoll. An sich natürlich nicht schlecht, aber wäre nicht auch hier der Effort wo anders besser aufgehoben?
 
Zurück
Oben