Dlaczego programy nie są dystrybuowane w formacie skompilowanym?

Ale dają instrukcje jak

cd downloaded_program
./configure
make install

Spowoduje to utworzenie potrzebnego pliku ELF i prawdopodobnie niektórych plików .so.

Dlaczego nie umieścić tych w pliku zip do pobrania, na przykład w aplikacjach Windows? Czy jest jakiś powód, dla którego użytkownik musi je skompilować?

Przeanalizujmy czynniki ...

Analiza :

ZALEŻNOŚCI WEDŁUG PLATFORMY : Istnieją pewne problemy, które pojawiają się w środowisku, w którym programiści tworzą i utrzymują kilka specyficznych dla architektury wariantów aplikacji:

• Dla różnych wariantów wymagany jest inny kod źródłowy - Różne systemy operacyjne oparte na UNIX mogą używać różnych funkcji do realizacji tego samego zadania (na przykład strchr (3) vs. index (3)). Podobnie może być konieczne dołączenie różnych plików nagłówkowych dla różnych wariantów (na przykład string.h vs. strings.h).

• Dla różnych wariantów wymagane są różne procedury kompilacji - procedury kompilacji dla różnych platform są różne. Różnice mogą obejmować takie szczegóły, jak lokalizacje kompilatora, opcje kompilatora i biblioteki.

• Kompilacje dla różnych wariantów muszą być oddzielone - ponieważ istnieje jedno drzewo źródłowe, należy zadbać o to, aby moduły obiektowe i pliki wykonywalne dla jednej architektury nie zostały pomylone z modułami dla innych architektur. Na przykład edytor linków nie może próbować utworzyć pliku wykonywalnego IRIX – 5 przy użyciu modułu obiektowego zbudowanego dla SunOS – 4.

• Każdy system operacyjny ma swój własny schemat zarządzania łączeniami i musi przygotować plik ELF (format wykonywalny i format łącza) zgodnie z potrzebami.

• Kompilator wygeneruje kompilację będącą sekwencją instrukcji , a różne architektury oznaczają różne zestawy instrukcji ( porównanie architektur zestawów instrukcji ). Zatem dane wyjściowe kompilatora są różne dla każdej architektury (np .: x86, x86-64, ARM, ARM64, IBM Power ISA, PowerPC, Motorola 6800, MOS T 6502 i tak wiele innych )

BEZPIECZEŃSTWO :

• Jeśli pobierzesz plik binarny, nie możesz być pewien, czy robi to, co mówi, ale robi, ale możesz spróbować skontrolować kod źródłowy i użyć samodzielnie skompilowanego pliku binarnego w systemie. Mimo to użytkownik Techmag dobrze skomentował swój komentarz, kontrola kodu wymaga wiedzy i kompetencji koderów do oceny kodu i nie stanowi gwarancji bezpieczeństwa.

RYNEK : W tej sekcji jest wiele czynników, ale spróbuję to wznowić:

• Nie każda firma chce dotrzeć do wszystkich platform, zależy to od rynku i popularności platform oraz tego, co chcą sprzedać.

• Wolne oprogramowanie ma ducha udostępniania oprogramowania tak szeroko, jak to możliwe, ale nie oznacza to, że jest ono zaprojektowane na każdą platformę, zależy to od społeczności, która je obsługuje.

Wniosek :

Nie każde oprogramowanie jest przeznaczone dla każdej platformy. Zapewnienie plików binarnych dla wszystkich architektur i platform wymaga skompilowania, przetestowania i utrzymania dla wszystkich platform. To więcej pracy, która czasami jest po prostu zbyt droga i można jej uniknąć, jeśli użytkownik skompiluje ją na własnej platformie. Ponadto użytkownik będzie wiedział, co wykonuje.

Istnieje tak wiele platform i środowisk programowych, zarówno * nix, jak i innych , w których oprogramowanie może być uruchomione, więc umożliwienie zbudowania aplikacji (lub biblioteki do użycia z aplikacjami) jest jedynym realistycznym sposobem wsparcia, ponieważ robi to wiele kombinacji tych składników jako „dobrego” oprogramowania. Oczywiście licencje takie jak GPL wymagają dostępności kodu źródłowego - więc nawet jeśli oprogramowanie nie działa poprawnie, zwykle jest to możliwe (choć może być trudne do zrozumienia, co jest nie tak i jak to naprawić) dla użytkownika lub jakaś strona trzecia, aby nurkować i poprawiać to, nawet jeśli twórca nie istnieje / nie może / nie istnieje, aby to zrobić.

Dystrybucja oprogramowania jako kodu źródłowego pozwala również na niezależną weryfikację , czy oprogramowanie robi to, co twierdzi, i nie robi czegoś paskudnego zamiast lub też - co - pomimo zmniejszenia poziomu zaufania do twórcy, faktycznie go zwiększa!

Po pierwsze, twoje pytanie opiera się na błędnej przesłance. Programy są dystrybuowane w skompilowanym formacie!

Normalnym sposobem instalowania oprogramowania na Ubuntu, podobnie jak w większości innych dystrybucji Linuksa, a bardziej ogólnie w większości wariantów Uniksa, jest instalacja pakietu. W systemie Ubuntu otwierasz centrum oprogramowania lub inny menedżer pakietów i przeglądasz dostępne oprogramowanie. Po wybraniu pakietu do instalacji pliki binarne (jeśli pakiet zawiera program) są pobierane i instalowane na komputerze.

Domyślnie menedżer pakietów oferuje pakiety tworzone przez opiekunów dystrybucji. Możesz także znaleźć zewnętrzne źródła pakietów; Ubuntu oferuje PPA jako ustandaryzowany sposób oferowania pakietów stronom trzecim.

Pobieranie oprogramowania od autora w skompilowanej formie jest ostatecznością. Musisz to zrobić tylko wtedy, gdy oprogramowanie nie jest wystarczająco popularne, aby je spakować lub jeśli absolutnie potrzebujesz najnowszej wersji, która nie została spakowana. Większość ludzi nigdy nie musi tego robić.

Gdy oprogramowanie nie jest pakowane do dystrybucji, często jest dystrybuowane w formie źródłowej, a nie binarnej. Są dwa główne powody, dla których zdarza się to często w świecie Linuksa, ale rzadko w świecie Windows. Jednym z powodów jest to, że odsetek programów typu open source w systemie Linux jest znacznie wyższy. Oczywiście, jeśli kod źródłowy programu nie jest dostępny, jedyną formą dystrybucji jest plik binarny. Innym powodem jest to, że świat Linuksa jest znacznie bardziej zróżnicowany. Dla każdego zestawu niekompatybilnych wersji bibliotek potrzebne są różne pliki binarne, co często oznacza różne pliki binarne dla każdej wersji każdej dystrybucji. Windows „rozwiązuje” to, każąc autorowi każdego pakietu rozpowszechniać biblioteki, których używają wraz z programem (konsekwencja: twój komputer przechowuje wiele kopii każdej biblioteki, po jednej na program, który z niej korzysta; jeśli błąd zostanie naprawiony w bibliotece, każdy program, który z niego korzysta, musi dostarczyć aktualizację), a nowa wersja systemu operacyjnego będzie wydawana co około trzy lata. Unix ma znacznie większą różnorodność i znacznie bardziej aktualne nawyki naprawiania błędów oraz rozwiązuje problemy z dystrybucją bibliotek, budując różne pliki binarne dla różnych dystrybucji.

Linux działa na więcej niż jednej konkretnej platformie CPU. Jeśli rozpowszechnisz pliki ELF (lub dowolny inny surowy plik wykonywalny), istnieje szansa, że ​​niektóre wersje Linuksa nie będą mogły uruchomić oprogramowania. W duchu jak największej dostępności oprogramowania preferowane jest użycie kodu źródłowego. Na przykład Linux działa na procesorach Sparc, Intel, AMD, ARM i innych typach.

Jeśli na przykład plik ELF był ukierunkowany konkretnie na procesory Intela, oprogramowanie innego typu nie mogło uruchomić. ELF jest niezależny od platformy, ale hostowany przez niego kod musi być zgodny z kodem maszynowym platformy. Zauważysz, ile dystrybucji ma podobne pakiety (np. Pakiety _386 i _586, gdy obsługuje różne procesory) - musisz zainstalować poprawny plik ELF, aby uzyskać poprawną operację.

Podobnie, jeśli zdecyduję się zbudować niestandardową wersję Linuksa, która używa różnych przerwań, linkerów itp., To nadal potrzebuję kodu źródłowego do skompilowania kodu. Nawet jeśli kod źródłowy nie ma instrukcji budowania specyficznych dla platformy, każda platforma jest inna i może nie uruchamiać ELF z innego systemu.

Pierwotnym powodem dystrybucji jako źródła była z pewnością różnorodność platform; społeczność Linuksa kontynuowała tę metodologię zarówno z tego powodu, jak i z nowych, częściowo politycznych powodów.

W przeciwieństwie do np. Systemu Windows, Linux nigdy nie zadawał sobie trudu utrzymania stabilności ABI (binarnego interfejsu aplikacji) przez długi czas - utrzymanie możliwości wprowadzania innowacji w takich aspektach, jak formaty wykonywalne, interfejsy API bibliotek i obsługa nowych platform sprzętowych była / jest uważana za bardziej ważny.

Komercyjne systemy operacyjne osiągają długoterminową kompatybilność aplikacji, ponieważ są bardzo zdyscyplinowane w zakresie innowacji; nowa funkcja / interfejs oprogramowania zawsze musi zostać DODATKOWO dodana do starej - wymagając dwóch rzeczy, a cenę zmiany czegokolwiek po wydaniu należy uznać za bardzo wysoką. Alternatywnie, możesz uwzględnić fakt planowanego starzenia się aplikacji wraz z każdym, kto pisze oprogramowanie dla twojego systemu operacyjnego (nie jest to wskazówka dla MS, ale inny dostawca systemu operacyjnego).

Osiągnięcie długoterminowej stabilnej platformy dla oprogramowania dystrybuowanego wyłącznie w formie binarnej (poza daną dystrybucją Linuksa) byłoby nawet uważane za niepożądane przez niektóre elementy społeczności Linuksa. Jako niezaprzeczalny użytkownik obu platform, nie twierdzę, że jest to dobre lub złe; tak to jest.

W wielu przypadkach (przynajmniej w świecie * nix) kod źródłowy jest najbardziej przenośną wersją oprogramowania. Posiadanie źródła gwarantuje, że udostępnione oprogramowanie będzie działać na każdej platformie, która może go obsługiwać (co w wielu przypadkach oznacza po prostu zgodność z POSIX). Wydanie plików binarnych gwarantuje zgodność tylko z platformami (zarówno programowymi, jak i sprzętowymi), dla których te pliki binarne są wydawane.

Weź pod uwagę, że w systemie Windows pliki binarne są najwygodniejszą i najbardziej przenośną formą udostępniania oprogramowania. Ponieważ kompilowanie źródła nie jest częścią zwykłego modelu dystrybucji oprogramowania dla systemu Windows, Microsoft dołożył wszelkich starań, aby pliki binarne działały w wielu wersjach ich systemów operacyjnych: http://www.joelonsoftware.com/articles/APIWar.html

Większość oprogramowania dla systemu Linux jest wolnym oprogramowaniem. Rozpowszechniając kod źródłowy za pomocą instrukcji kompilacji zamiast plików binarnych, masz możliwość przejrzenia lub nawet edycji kodu źródłowego przed jego skompilowaniem. W ten sposób możesz być bardzo pewien, co faktycznie robi program i że nie jest on szkodliwy.

Głównym powodem, dla którego osobiście nie lubię tylko wykonywania pliku wykonywalnego programu, jest to, że lubię najpierw sprawdzić, co faktycznie robi kod źródłowy (głównie dlatego, że lubię patrzeć na kod innych), ale znam kilka innych którzy również sprawdzają kod źródłowy pod kątem złośliwego kodu.

Wiele odpowiedzi mówiło, że w większości przypadków oprogramowanie jest dystrybuowane w skompilowanym formacie. Zgadzam się z tym założeniem. Niemniej jednak widzę przypadek, w którym dystrybucja oprogramowania według jego źródła jest lepsza niż dystrybucja w formacie skompilowanym.

Nie jestem pewien, czy to prawda, ale wyobrażam sobie na początku Internetu, ponieważ pasma sieciowe były złe, czasem dystrybucja oprogramowania według źródła może być szybsza niż w formacie skompilowanym. Ponieważ źródła kodu są tylko zwykłym tekstem, często są mniejsze niż oprogramowanie w skompilowanym formacie. Tak więc rozpowszechnianie oprogramowania ze źródłem kodu wydaje się lepszym sposobem udostępniania go, pod warunkiem, że użytkownicy będą mogli go skompilować.

Oprócz faktu, że istnieje wiele systemów uniksowych, które działają na wielu różnych platformach, po prostu weź pod uwagę problemy, jakie napotyka oprogramowanie Windows z tego modalu dystrybucji, nawet jeśli naprawdę muszą się martwić tylko o jedną wersję systemu Windows i jedną platformę (komputer ).

Nawet przy martwym komputerze, istnieją jeszcze dwie architektury: 32-bitowa i 64-bitowa. Jeśli zauważysz, ogromna większość oprogramowania Windows po prostu ignoruje 64-bitowe i tylko oprogramowanie 32-bitowe, pozostawiając ci nieoptymalne oprogramowanie, jeśli masz system 64-bitowy. Są też biblioteki. Jeden sprzedawca oprogramowania nie chce, abyś popełnił dziwne błędy przy próbie uruchomienia programu, jeśli nie masz już zainstalowanej odpowiedniej biblioteki, więc po prostu dołączają bibliotekę do swojego programu (zwiększając pobieranie, nawet jeśli masz już tę bibliotekę) ). Drugi program robi to samo, ale z inną wersją biblioteki. W najlepszym przypadku program B zawiera nowszą wersję biblioteki, która jest kompatybilna wstecz, więc jeśli program B zostanie zainstalowany późniejprogram A, rzeczy działają, ale instalacja ich w odwrotnej kolejności pozostawia starszą wersję biblioteki, więc program B ulega awarii. Często jednak dostawca biblioteki dokonuje zmian, które nie są kompatybilne wstecz i nie zawracają sobie głowy zmianą nazwy biblioteki, więc bez względu na to, w jakiej kolejności instalujesz dwa programy, pierwszy się zepsuje. Nazywa się to „dll hell”.

Niestety, aby tego uniknąć, większość programów systemu Windows ucieka się z wysyłaniem wszystkich swoich bibliotek we własnym katalogu programów zamiast katalogu współdzielonego, więc każdy program ma wszystkie swoje prywatne biblioteki i nigdy nie będzie się ze sobą dzielić, co pokona całość punkt bibliotek DLL, a w końcu zużywasz o wiele więcej pamięci RAM i miejsca na dysku, a czas pobierasz wszystkie zduplikowane biblioteki.

To dlatego oprogramowanie open source jest publikowane w formie źródłowej, a dostawcy systemów operacyjnych opracowali menedżery pakietów, które rozwiązują problemy z zależnościami i pobierają tylko te wstępnie skompilowane pliki binarne, których faktycznie potrzebujesz, bez kopiowania bibliotek w dowolnym miejscu. Dotyczy to również faktu, że istnieje wiele różnych systemów uniksowych, które działają na wielu różnych platformach.