Jakie jest źródło mentalności „skompiluj to sam” w systemie Linux [zamknięte]

Użyłem Linuksa trochę na studiach i znam te warunki. Regularnie rozwijam się w językach .NET, więc nie jestem analfabetą komputerową.

To powiedziawszy, nie mogę powiedzieć, że naprawdę rozumiem mentalność „skompiluj to sam” [CIY], która istnieje w kręgach * nix. Wiem, że to odchodzi, ale od czasu do czasu to słyszę. Jako programista wiem, że konfigurowanie kompilatorów i niezbędnych zależności jest uciążliwe, więc uważam, że przepływy pracy CIY pomogły uczynić * nix znacznie mniej dostępnym.

Jakie czynniki społeczne lub techniczne doprowadziły do ​​wzrostu mentalności CIY?

Po prostu, przez większą część historii * nix nie było innego wyboru. Programy były dystrybuowane jako pliki źródłowe, a jedynym sposobem na ich użycie było skompilowanie ze źródła. Nie jest to więc mentalność, lecz zło konieczne.

To powiedziawszy, istnieją bardzo dobre powody do samodzielnego kompilowania rzeczy, ponieważ zostaną one skompilowane specjalnie dla twojego sprzętu, możesz wybrać opcje, które chcesz włączyć lub nie, a zatem możesz uzyskać precyzyjnie dostrojony plik wykonywalny, tak jak lubisz . Jest to oczywiście tylko coś, co ma sens dla ekspertów, a nie dla osób, które chcą tylko, aby działająca maszyna mogła czytać ich e-maile.

Teraz w świecie Linuksa wszystkie główne dystrybucje odeszły od tego wiele lat temu. W dzisiejszych czasach bardzo, bardzo rzadko musisz samodzielnie kompilować, chyba że korzystasz z dystrybucji specjalnie zaprojektowanej dla osób, które lubią to robić jak Gentoo. Jednak w zdecydowanej większości dystrybucji przeciętny użytkownik nigdy nie będzie musiał niczego kompilować, ponieważ prawie wszystko, czego kiedykolwiek będą potrzebować, jest obecne i kompilowane w repozytoriach ich dystrybucji.

Więc ta mentalność CIY, jak ją nazywacie, zasadniczo zniknęła. Być może nadal żyje i działa w świecie UNIX, nie mam tam doświadczenia, ale w Linuksie, jeśli używasz popularnej dystrybucji z porządnym repozytorium, prawie nigdy nie będziesz musiał niczego kompilować.

Istnieje kilka przyczyn tej mentalności, od użytkowników końcowych, opiekunów dystrybucji i dostawców kodu / programistów / grup projektowych, a każdy z nich jest całkowicie poprawny.

Aspekt Open Source

Są tacy, którzy lubią wiedzieć, że używają Wolnego oprogramowania i potwierdzają to, wybierając kompilację ze źródła. To tutaj pojawiają się takie rzeczy jak projekt Linux From Scratch / howto / guide / book.

Aspekt optymalizacji i opcji

Chcesz skompilować elementy z konkretnymi optymalizacjami dla konkretnej architektury procesora? Być może istnieje opcja czasu kompilacji (lub łatka, aby ją utworzyć), aby włączyć lub wyłączyć określoną funkcję, której potrzebujesz. Przykładem może być łatanie postfiksu, aby mieć możliwość zarządzania kwotami, lub korzystanie z dystrybucji takiej jak Gentoo, w której możesz zrezygnować z systemd, lub w szczególności wspierać ogg / theora / vorbis / cokolwiek i NIE mp3 z powodu problemów licencyjnych lub cokolwiek.

Aspekt architektury CPU

Czy twoje miejsce pracy korzysta z wysokiej klasy maszyn innych niż x86 / amd64? Pakiet, którego potrzebujesz / nie chcesz, może nie być wstępnie skompilowany dla architektury procesora, a tym bardziej bez względu na to, jakiej dystrybucji używasz. To prawda, że ​​większość miejsc, w których działa tego rodzaju sprzęt, jest również wspierana przez IBM itp. I nie instaluje się / kompiluje rzeczy nie chcąc. Ale co, jeśli kupisz jeden z nadwyżki, wykopiesz stary iMac z procesorem PPC itp.?

Aspekt dystrybucji

„Rodziny” dystrybucji - tj. Debian w / Ubuntu, Mint i in. Oraz RedHat z CentOS, Whitebox, Fedora i in. - wszystkie używają różnych formatów pakietów. Każda wersja jest dostarczana z inną wersją biblioteki itp. Nawet w przypadku prostego skryptu powłoki pojedynczego pliku ustawienie odpowiedniego pliku .deb Debiana wymaga czasu i wysiłku. Jeśli napisałeś jakieś oprogramowanie, aby zarysować swędzenie, i chciałbyś go uwolnić i opublikować na gitlab, swoim własnym serwerze internetowym, cokolwiek, wolałbyś po prostu zamieścić ogólny plik .tar.gz źródła z instrukcjami budowania, czy wolałbyś pakowanie wersji dla 2 wersji Debiana (stabilna i testowa, być może stara), wielu wersji Redhat i Fedory jako RPM, TGZ dla Slackware, profil ebuild dla Gentoo itp. itd. itp.

Jak mówi @terdon, obecnie potrzeba kompilacji jest bardzo niewielka, szczególnie dla użytkowników domowych.

W przeszłości w świecie Uniksa byłem bardzo zależny od kompilacji źródeł, na przykład, ponieważ zarządzałem systemami Solaris, AIX, Ultrix, Digital Ultrix i HP / UX, które czasami nie były już obsługiwane przez dostawcę lub które implementacje wspólnych usług były daleko w tyle za tym, co były powszechnie używane przez inne Uniksy, w tym Linux.

Nadal istnieją rzeczywiste potrzeby kompilacji rzeczy, aby uzyskać bardziej niejasne lub przestarzałe oprogramowanie, którego nie ma w repozytoriach, lub użyć nowszej wersji pakietu, dla którego nie masz kompatybilnych plików binarnych, lub gdy chcesz dodać dodatkową funkcjonalność lub rzadko, jeśli jesteś w stanie napisać dla niej łatkę lub moduł.

Musiałem też ręcznie skompilować oprogramowanie podczas reengineeringu systemów do portowania na Debianie i / lub nowych wersjach Debiana, które miały strukturę, która nie była już obsługiwana przez system operacyjny.

Na przykład w przeszłości musiałem ręcznie kompilować demony DHCP, aby uzyskać wsparcie dla (do tej pory) zmian systemu Windows w protokole lub aby obsługiwać określone łaty do obsługi administracyjnej w świecie telekomunikacji.

Nadal trzymam w moich lokalnych repozytoriach debaty dla wersji FreeRadius skompilowanych przeze mnie z repozytorium dev git, ponieważ istniał ciąg stabilnych wersji z (poważnymi) błędami w Debianie, i zwykle nie były to odpowiednie .deb dla Debiana / Ubuntu odpowiednie dla naszych potrzeb.

Jest rzeczą oczywistą, że często za jakiś czas musimy także uruchamiać / kompilować rzeczy napisane przez nas samych.

Instalowanie zależności w dzisiejszych czasach nie jest tak trudne jak w przeszłości, a niektóre programy mają nawet niestandardowe pliki reguł dla niektórych popularnych dystrybucji Linuksa, które określają zależności do skompilowania i wykonują ciężką pracę, tworząc plik pakietu z wbudowaną listą zależności. Instalacja takiego pakietu z lokalnego repozytorium nie różni się niczym od zainstalowania tego samego pakietu z oficjalnych repozytoriów.

Jakie czynniki społeczne lub techniczne doprowadziły do ​​wzrostu mentalności CIY?

Przyczyną jest oczywiście przyczyna techniczna: Przenośność binarna jest trudniejsza niż przenośność źródła . Poza pakietami dystrybucyjnymi większość Wolnego oprogramowania jest nadal dostępna tylko w formie źródłowej, ponieważ jest to znacznie wygodniejsze dla autora (autorów) / opiekunów.

Dopóki dystrybucje Linuksa nie zaczęły pakować większości rzeczy, z których przeciętni ludzie chcieliby korzystać, jedyną opcją było zdobycie źródła i skompilowanie go dla własnego systemu. Dostawcy komercyjnych systemów uniksowych zwykle nie zawierali rzeczy, które prawie wszyscy chcieli (np. Ładnej powłoki, takiej jak GNU bashlub podobna), tylko ich własną implementację shi / lub csh, więc trzeba było zbudować coś samodzielnie, jeśli (jako administrator systemu) chciałeś aby zapewnić użytkownikom przyjemne środowisko uniksowe do interaktywnego użytku.

Obecna sytuacja, w której większość ludzi jest jedynym administratorem i jedynym użytkownikiem maszyny siedzącej na pulpicie, różni się znacznie od tradycyjnego modelu Uniksa. Sysadmin utrzymywał oprogramowanie w systemie centralnym i na pulpicie wszystkich. (Często wystarczy, że stacje robocze są po prostu podłączane do systemu plików NFS /opti /usr/local/z serwera centralnego, i instalują tam rzeczy.)

Przed rzeczami takimi jak .NET i Java prawdziwa przenośność binarna w różnych architekturach procesorów była niemożliwa. Kultura uniksowa ewoluowała z domyślną przenośnością źródła z tego powodu, przy niewielkim wysiłku, nawet próbując włączyć przenośność binarną aż do ostatnich wysiłków Linuksa, takich jak LSB. Na przykład, POSIX ( głównym standardem Unix) próbuje jedynie w celu ujednolicenia przenoszenia źródłowego, nawet w najnowszych wersjach.

Powiązany czynnik kulturowy: wczesny komercyjny system AT&T Unix był dostarczany z kodem źródłowym (na taśmach). Nie musisz budować systemu ze źródła, było to na wypadek, gdybyś chciał zobaczyć, jak coś naprawdę działa, gdy dokumenty nie są wystarczające.

Wikipedia mówi :

„Polityka Uniksa dotycząca obszernej dokumentacji on-line i (przez wiele lat) łatwego dostępu do całego kodu źródłowego systemu podniosła oczekiwania programistów i przyczyniła się do uruchomienia w 1983 roku ruchu wolnego oprogramowania”.

Nie jestem pewien, co było przyczyną tej decyzji, ponieważ zapewnienie klientom dostępu do kodu źródłowego oprogramowania komercyjnego jest obecnie niespotykane. W tym kierunku wyraźnie widać pewne wczesne uprzedzenia kulturowe, ale być może wyrosły one z korzeni Unixa jako przenośnego systemu operacyjnego napisanego głównie w C (nie w asemblerze), który można skompilować dla innego sprzętu. Myślę, że wiele wcześniejszych systemów operacyjnych miało więcej kodu napisanego w asm dla konkretnego procesora, więc przenośność na poziomie źródła była jedną z mocnych stron wczesnego Uniksa. (Mogę się mylić; nie jestem ekspertem od wczesnego Uniksa, ale Unix i C są ze sobą powiązane).

Dystrybucja oprogramowania w formie źródłowej jest zdecydowanie najłatwiejszym sposobem, aby pozwolić ludziom na dostosowanie go do dowolnego systemu, na którym ma działać. (Użytkownicy końcowi lub osoby pakujące go dla dystrybucji Linuksa). Jeśli oprogramowanie zostało już spakowane przez / dla dystrybucji, użytkownicy końcowi mogą z niego korzystać.

Ale to zbyt wiele, by oczekiwać, że autorzy większości pakietów sami tworzą pliki binarne dla każdego możliwego systemu. Niektóre duże projekty zapewniają pliki binarne dla kilku typowych przypadków (szczególnie x86 / Windows, w których system operacyjny nie jest dostarczany ze środowiskiem kompilacji, a producent systemu operacyjnego położył duży nacisk na dystrybucję instalatorów zawierających tylko pliki binarne).

Uzyskanie oprogramowania do pracy w innym systemie niż ten, którego użył autor, może nawet wymagać niewielkich zmian, które są łatwe w przypadku źródła . Mały jednorazowy program, który ktoś napisał, aby podrapać swój własny świąd, prawdopodobnie nigdy nie był testowany na większości mało znanych systemów. Posiadanie źródła umożliwia dokonanie takich zmian. Oryginalny autor mógł coś przeoczyć lub celowo napisać mniej przenośny kod, ponieważ zaoszczędził wiele czasu. Nawet duże pakiety, takie jak Info-ZIP, nie miały od razu testerów na każdej platformie i wymagały od ludzi przesyłania poprawek przenośności w miarę wykrycia problemów.

(Istnieją inne rodzaje problemów przenośności źródło szczebla, które zdarzają się tylko z powodu różnic w kompilacji env i nie są bardzo istotne z punktu widzenia problem tutaj. Z Java stylu binarnej przenośności, automatyczne narzędzia ( autoconf/ auto-make) i podobne rzeczy jak cmakeWouldn „t być potrzebne. i nie mielibyśmy rzeczy jak niektóre systemy wymagają włączenia <netinet/in.h>zamiast<arpa/inet.h> ontohl(3) . (A może nie mielibyśmy ntohl()ani jakiekolwiek inne rzeczy bajt rzędu na pierwszym miejscu!)

Regularnie rozwijam się w językach .NET, więc nie jestem analfabetą komputerową.

Jednorazowa kompilacja, uruchomienie w dowolnym miejscu jest jednym z głównych celów platformy .NET i Java, więc można śmiało powiedzieć, że całe języki zostały wymyślone w celu rozwiązania tego problemu , a twoje doświadczenie deweloperskie dotyczy jednego z nich. Dzięki .NET Twój plik binarny działa w przenośnym środowisku wykonawczym (CLR) . Java nazywa to środowisko wykonawcze Java Virtual Machine . Musisz tylko dystrybuować jeden plik binarny, który będzie działał w dowolnym systemie (przynajmniej w każdym systemie, w którym ktoś już zaimplementował JVM lub CLR). Nadal można mieć problemy przenośności jak, /vs \separatorów ścieżki, albo jak wydrukować lub GUI układ szczegóły, oczywiście.

Wiele programów jest napisanych w językach w pełni skompilowanych w natywnym kodzie . Nie ma .netkodu bajtowego Java lub tylko natywny kod maszynowy dla procesora, na którym będzie on uruchomiony, przechowywany w nieprzenośnym formacie pliku wykonywalnego. C i C ++ są głównymi tego przykładami, szczególnie w świecie Uniksa. Oczywiście oznacza to, że plik binarny musi zostać skompilowany dla określonej architektury procesora.

Wersje bibliotek to kolejny problem . Biblioteki mogą i często utrzymują stabilność API na poziomie źródła podczas zmiany ABI na poziomie binarnym. (Zobacz Różnica między API i ABI .) Na przykład dodanie innego elementu do nieprzezroczystego structnadal zmienia jego rozmiar i wymaga ponownej kompilacji z nagłówkami dla nowej wersji biblioteki dla dowolnego kodu, który przydziela miejsce dla takiej struktury, czy to dynamicznej (malloc ), statyczny (globalny) lub automatyczny (lokalny na stosie).

Ważne są także systemy operacyjne . Inny smak Uniksa na tej samej architekturze procesora może mieć różne formaty plików binarnych, inny ABI do wykonywania połączeń systemowych i różnych wartości liczbowych dla stałych takich jak fopen(3)„s O_RDONLY, O_APPEND,O_TRUNC .

Zauważ, że nawet dynamicznie połączony plik binarny nadal ma jakiś kod startowy specyficzny dla systemu operacyjnego, który działał wcześniej main(). W systemie Windows tak jest crt0. Unix i Linux mają to samo, gdzie część kodu startowego C-Runtime jest statycznie połączona z każdym plikiem binarnym. Sądzę, że teoretycznie możesz zaprojektować system, w którym ten kod byłby również dynamicznie połączony, i był częścią libc lub samego dynamicznego linkera, ale nie wiem, jak to działa w praktyce w każdym systemie operacyjnym. To rozwiązałoby jedynie problem ABI wywołania systemowego, a nie problem wartości liczbowych dla stałych dla funkcji biblioteki standardowej. (Zwykle wywołania systemowe są wykonywane za pomocą funkcji opakowania libc: normalny plik binarny dla systemu Linux x86-64 dla źródła, który używa mmap(), nie będzie zawierał syscallinstrukcji, a tylkocall instrukcja do funkcji otoki libc o tej samej nazwie.

Jest to część tego, dlaczego nie można po prostu uruchamiać plików binarnych i386-FreeBSD w systemie i386-Linux. (Przez pewien czas jądro Linuksa miało warstwę kompatybilności z wywołaniami systemowymi. Myślę, że przynajmniej jeden z BSD może uruchamiać binaria Linuksa z podobną warstwą kompatybilności, ale oczywiście potrzebujesz bibliotek Linuksa.)

Jeśli chcesz dystrybuować pliki binarne, musisz utworzyć osobny dla każdej kombinacji CPU / OS-smak + wersja / wersja zainstalowanej biblioteki .

W latach 80. / 90. istniało wiele różnych rodzajów procesorów powszechnie używanych w systemach Unix (MIPS, SPARC, POWER, PA-RISC, m68k itp.) Oraz wiele różnych odmian Uniksa (IRIX, SunOS, Solaris, AIX, HP-UX, BSD itp.).
A to tylko systemy uniksowe . Wiele pakietów źródłowych również kompiluje się i działa na innych systemach, takich jak VAX / VMS, MacOS (m68k i PPC), Amiga, PC / MS-DOS, Atari ST itp.

Nadal istnieje wiele architektur procesorów i systemów operacyjnych, choć obecnie zdecydowana większość komputerów stacjonarnych to x86 z jednym z trzech głównych systemów operacyjnych.

Tak więc jest już więcej kombinacji procesora / systemu operacyjnego, niż można sobie wyobrazić, nawet zanim zaczniesz myśleć o zależnościach od bibliotek innych firm, które mogą być w różnych wersjach w różnych systemach. (Wszystko, co nie zostało spakowane przez dostawcę systemu operacyjnego, musiałoby zostać zainstalowane ręcznie).

Wszelkie ścieżki wkompilowane w plik binarny są również specyficzne dla systemu. (Oszczędza to pamięć RAM i czas w porównaniu do odczytu ich z pliku konfiguracyjnego przy uruchomieniu). Old-schoolowe systemy uniksowe zazwyczaj zawierały wiele ręcznie dostosowywanych rzeczy, więc nie ma sposobu, abyś mógł przyjąć jakiekolwiek uzasadnione założenia co do tego, gdzie jest.

Dystrybucja plików binarnych była całkowicie niemożliwa dla old-schoolowego Uniksa, z wyjątkiem dużych komercyjnych projektów, których stać na zbudowanie i przetestowanie wszystkich głównych kombinacji .

Nawet tworzenie binariów za słuszne i386-linux-gnui amd64-linux-gnujest trudne. Wiele czasu i wysiłku poświęcono na takie rzeczy jak Linux Standard Base, aby umożliwić przenośne pliki binarne . Nawet statycznie łączące pliki binarne nie rozwiązują wszystkiego. (np. jak program do edycji tekstu powinien drukować w systemie RedHat w porównaniu z systemem Debian? W jaki sposób instalator powinien dodać użytkownika lub grupę do demona i ustawić uruchamianie skryptu startowego po każdym ponownym uruchomieniu?) Nie są świetne przykłady, ponieważ ponowna kompilacja ze źródła ich nie rozwiązuje.

Poza tym wspomnienia w tamtych czasach były cenniejsze niż obecnie. Pozostawienie opcjonalnych funkcji w czasie kompilacji może stworzyć mniejsze pliki binarne (mniejszy rozmiar kodu), które również zużywają mniej pamięci dla swoich struktur danych. Jeśli funkcja wymagała dodatkowego elementu w każdym przypadku określonego elementu classlub structdo śledzenia czegoś, wyłączenie tej funkcji spowoduje zmniejszenie obiektu o 4 bajty (na przykład), co jest miłe, jeśli jest to obiekt, który program przydziela 100 tys.

Opcjonalne funkcje czasu kompilacji są obecnie najczęściej używane, aby dodatkowe biblioteki były opcjonalne. Na przykład można skompilować ffmpegz lub bez libx264, libx265, libvorbis, i wiele innych bibliotek dla konkretnego filmu / kodery audio, obsługę napisów, itp itd. Częściej, wiele rzeczy może być skompilowany z lub bez libreadline: jeśli jest ona dostępna po uruchomieniu ./configure, wynikowy plik binarny będzie zależeć od biblioteki i zapewni fantazyjną edycję linii podczas czytania z terminala. Jeśli tak nie jest, program użyje wsparcia rezerwowego, aby po prostu odczytać linie ze standardowego wejścia fgets()lub czegoś.)

Niektóre projekty nadal używają opcjonalnych funkcji, aby pominąć niepotrzebny kod ze względu na wydajność. np. samo jądro Linuksa można zbudować bez obsługi SMP (np. dla systemu osadzonego lub starożytnego pulpitu), w którym to przypadku wiele blokowania jest prostszych. Lub z wieloma innymi opcjonalnymi funkcjami, które wpływają na niektóre podstawowe kody, nie tylko pomijając sterowniki lub inne funkcje sprzętowe. (Chociaż opcje konfiguracji specyficzne dla architektury i sprzętu stanowią dużą część całego kodu źródłowego. Zobacz Dlaczego jądro Linuksa ma ponad 15 milionów linii kodu? )