Ganz einfach, für einen Großteil der Geschichte von *nix gab es keine andere Wahl. Programme wurden als Quell-Tarballs verteilt, und die einzige Möglichkeit, sie zu verwenden, bestand darin, aus dem Quellcode zu kompilieren. Es ist also weniger eine Mentalität als vielmehr ein notwendiges Übel.
Allerdings gibt es sehr gute Gründe, Dinge selbst zu kompilieren, da sie dann speziell für Ihre Hardware kompiliert werden, Sie auswählen können, welche Optionen aktiviert werden sollen oder nicht, und Sie daher eine fein abgestimmte ausführbare Datei erhalten können, genau so, wie Sie es mögen . Das ist aber natürlich nur etwas, das für erfahrene Benutzer sinnvoll ist und nicht für Leute, die nur eine funktionierende Maschine zum Lesen ihrer E-Mails wollen.
Nun, in der Linux-Welt haben sich die wichtigsten Distributionen vor vielen Jahren alle davon entfernt. Heutzutage müssen Sie sehr, sehr selten etwas selbst kompilieren, es sei denn, Sie verwenden eine Distribution, die speziell für Leute entwickelt wurde, die dies gerne tun, wie Gentoo. Bei der überwiegenden Mehrheit der Distributionen muss Ihr durchschnittlicher Benutzer jedoch nie etwas kompilieren, da so ziemlich alles, was er jemals benötigt, in den Repositories seiner Distribution vorhanden und kompiliert ist.
Diese CIY-Mentalität, wie Sie sie nennen, ist also im Wesentlichen verschwunden. Es mag in der UNIX-Welt immer noch am Leben sein, ich habe dort keine Erfahrung, aber unter Linux müssen Sie fast nie etwas selbst kompilieren, wenn Sie eine beliebte Distribution mit einem anständigen Repository verwenden.
Es gibt ein paar Gründe für diese Mentalität, von Endbenutzern, Distributionsbetreuern und Codelieferanten/Entwicklern/Projektgruppen, und jeder einzelne davon ist vollkommen gültig.
Der Open-Source-Aspekt
Es gibt einige, die es genießen zu wissen, dass sie Freie Software verwenden, und dies bestätigen, indem sie sich dafür entscheiden, aus dem Quellcode zu kompilieren. Hier kommen Dinge wie das Linux From Scratch Projekt/Howto/Guide/Buch ins Spiel.
Der Optimierungs- und Optionsaspekt
Möchten Sie Sachen mit spezifischen Optimierungen für Ihre spezielle CPU-Architektur kompilieren? Vielleicht gibt es eine Kompilierzeitoption (oder einen Patch, um eine zu erstellen), um eine bestimmte Funktion, die Sie benötigen, zu aktivieren oder zu deaktivieren. Beispiele hierfür könnten das Patchen von Postfix sein, um die Möglichkeit zu haben, Kontingente zu verwalten, oder die Verwendung einer Distribution wie Gentoo, bei der Sie sich entscheiden können, systemd nicht zu verwenden, oder Sie entscheiden sich aufgrund von Lizenzproblemen speziell dafür, ogg/theora/vorbis/whatever und NICHT mp3 zu unterstützen oder was auch immer.
Der Aspekt der CPU-Architektur
Verwendet Ihr Arbeitsplatz High-End-Computer ohne x86/amd64? Das Paket, das Sie benötigen / wollen, ist möglicherweise nicht vorkompiliert für Ihre CPU-Architektur verfügbar, geschweige denn, welche Distribution Sie ausführen. Zugegeben, die meisten Orte, an denen diese Art von Hardware ausgeführt wird, werden auch von IBM usw. unterstützt und installieren/kompilieren nicht einfach so Sachen. Aber was ist, wenn Sie einen aus einem Restverkauf aufheben, einen alten iMac mit PPC-Prozessor ausgraben usw.?
Der Vertriebsaspekt
Distributions-"Familien" - dh Debian mit Ubuntu, Mint usw. und RedHat mit CentOS, Whitebox, Fedora usw. - verwenden alle unterschiedliche Paketformate. Und jede Version wird mit unterschiedlichen Bibliotheksversionen usw. ausgeliefert. Selbst für ein einfaches Shell-Skript mit einer einzigen Datei braucht das Einrichten einer richtigen Debian-.deb-Datei Zeit und Mühe. Wenn Sie eine Software geschrieben haben, um etwas Juckreiz zu beseitigen, und sie kostenlos machen und auf Gitlab, Ihrem eigenen Webserver, was auch immer, veröffentlichen wollten, würden Sie lieber einfach eine generische .tar.gz-Quelldatei mit Anweisungen zum Erstellen posten, oder doch lieber Packen Sie Versionen für 2 Versionen von Debian (stable und testing, vielleicht oldstable), mehrere Versionen von Redhat und Fedora als RPMs, ein TGZ für Slackware, ein Ebuild-Profil für Gentoo usw. usw. usw. ein.
Wie @terdon sagt, ist heutzutage die Notwendigkeit, Dinge zu kompilieren, ziemlich gering, insbesondere für Heimanwender.
In der Vergangenheit war ich in der Unix-Welt stark auf das Kompilieren von Sourcen angewiesen, da ich beispielsweise Solaris-, AIX-, Ultrix-, Digital-Ultrix- und HP/UX-Systeme verwaltete, die teilweise nicht mehr vom Hersteller gepflegt wurden, oder deren Implementierungen allgemeiner Dienste weit hinter dem zurück, was üblicherweise von anderen Unixen, einschließlich Linux, verwendet wird.
Es gibt immer noch echten Bedarf, Dinge in der Gegenwart zu kompilieren, entweder um ein obskureres oder veralteteres Stück Software zu bekommen, das nicht in den Repositories ist, oder um eine neuere Version eines Pakets zu verwenden, für das Sie keine kompatiblen Binärdateien haben, oder wann Sie möchten zusätzliche Funktionalität hinzufügen oder selten, wenn Sie in der Lage sind, einen Patch oder ein Modul dafür zu schreiben.
Ich musste auch Software von Hand kompilieren, wenn ich Systeme umgestaltete, um sie auf Debian und/oder neue Versionen von Debian zu portieren, die ein Framework hatten, das vom Betriebssystem nicht mehr unterstützt wurde.
In der Vergangenheit musste ich zum Beispiel DHCP-Daemons von Hand kompilieren, um die Unterstützung für (bis dahin aktuelle) Windows-Änderungen am Protokoll zu erhalten, oder um bestimmte Patches für die Bereitstellung in der Telekommunikationswelt zu unterstützen.
Ich bewahre immer noch in meinem lokalen Repository debs für FreeRadius-Versionen auf, die ich selbst aus dem dev git repo kompiliert habe, da es eine Reihe von stabilen Versionen gab, die (schwerwiegende) Fehler in Debian aufwiesen, und normalerweise waren die entsprechenden .debs für Debian/Ubuntu nicht vorhanden ausreichend für unsere Bedürfnisse.
Und es versteht sich von selbst, dass wir manchmal auch von uns selbst geschriebene Sachen ausführen/kompilieren müssen.
Die Installation der Abhängigkeiten ist heutzutage nicht mehr so schwierig wie in der Vergangenheit, und einige Software hat sogar angepasste Regeldateien für einige gängige Linux-Distributionen, die die zu kompilierenden Abhängigkeiten benennen und die schwere Arbeit der Erstellung der Paketdatei mit der Liste der eingebauten Abhängigkeiten erledigen. Die Installation eines solchen Pakets aus einem lokalen Repository unterscheidet sich nicht wesentlich von der Installation desselben Pakets aus den offiziellen Repositorys.