andy_0 schrieb:
Richtig, nicht alle Software liegt als Quellcode vor. Das betrifft vor allem proprietäre Treiber (z.B. Intel GPU Treiber). Da man sowas aber trotzdem anbieten möchte, integriert man das vom Hersteller bereitgestellte Binary.
Ja. Bei Firmware und Treibern gibt es Distributionen und Linux-Anwender, die ein Auge zudrücken, weil sie hier die Funktionalität (dass die Hardware funktioniert) als wichtiger erachten, als dass jeder Treiber/Firmware unbedingt Open Source ist. Außerdem liegt mancher Treiber und Firmware NUR als Closed Source vor - weshalb man hier dann die Wahl hat: entweder man nutzt diese Hardware gar nicht unter Linux, oder eben mit Closed Source Treibern/Firmware. Und bei
dieser Wahl treffen viele die pragmatische Entscheidung: lieber mit Nachteilen als gar nicht.
Ich würde aber empfehlen, wenn man es vorher schon WEIẞ, dass eine Hardware nur mit Closed Source lauffähig ist, dass man diese dann am besten gar nicht erst käuft, also stattdessen auf eine zurückgreift, die mit Open Source Treibern ähnlich gut funktioniert. Als Beispiel sei hier für Gaming/Normaluser erwähnt, dass die AMD Grafikkarten unter Linux mit Open Source Treibern sehr gut funktionieren, die NVidia-Grafikkarten mit Open Source Treibern aber eher schlecht bis gar nicht. Daher ist hier AMD zu bevorzugen, vorausgesetzt man ist nicht abhängig von NVidia-only Features.
Open Source ist generell zu bevorzugen. Auch wenn es wie in dem Thread hier erwähnt vorkommen kann, dass ein Kompilat nicht dem Source entspricht, oder die Sourcen vorher manipulitert wurden bevor das Kompilat erstellt wurde. Bei Open Source Software ist das zumindest nur eine theoretisch mögliche Gefahrenquelle ("Reproducible Builds" oder selbstständiges Kompilieren von Source sind Gegenmaßnahmen dagegen, oder auch einfach Vertrauen in die Distros... dass bspw. Community-Distros wie Arch oder Debian aus manipulierten Sources ihre Pakete erstellen, ist sehr unwahrscheinlich - sie hätten ja keinen Gegenwert davon), während man bei Closed Source Software nie eine Wahl hat und zwangsweise das fressen muss, was als Kompilat vorliegt (und hier ist auch die Wahrscheinlichtkeit hoch, dass bereits im Source (den niemand außer dem Entwickler sehen kann) diverser Schmutz oder Anti-Features vorhanden sind, die der Entwickler den Usern von vornherein vorenthalten möchte. Gerade bei kommerzieller Software ist hier auch ein finanzieller Incentive gegeben, denn mit dem Abgreifen von allen erdenklichen System- und Nutzungs-Daten lässt sich zusätzliches Geld scheffeln). Backdoors für Geheimdienste sind auch wesentlich wahrscheinlicher. Bei Open Source hat man halt zumindest die Wahl: nehme ich aus Einfachheitsgründen nur das Kompilat, was vielleicht nicht dem Source 100% entspricht oder wo der Build-Prozess nicht 100% reproduzierbar ist (was aber nicht mal ein Problem sein muss... es bedeutet erst mal nur, dass man halt die exakten Gegebenheiten des Builds nicht nachstellen kann, weshalb sich das entstandene Kompilat dann halt minimal unterscheidet. Das muss überhaupt nichts Bösartiges sein), oder baue ich es mir vom Source selbst, um 100% sicher zu gehen dass mein Kompilat dem Source entspricht. Wer diese Kategorie von potenziellem Problem generell umschiffen möchte, kann auch generell zu Source-basierten Distros oder Source-Paketen greifen, oder einfach alles selbst bauen auch wenn die Distri Binärpaket-basiert ist, anstatt die Binär-Pakete zu verwenden. Das ist natürlich etwas umständlicher und energie-ineffizienter, aber wie das halt so ist in der IT: zusätzliche Sicherheit ist immer etwas unbequemer, als mit weniger Sicherheit zu leben.
.
