Dlaczego programy nie są dystrybuowane w formacie skompilowanym?

32

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ć?

koteczek
źródło
18
tak dystrybuowany jest kod źródłowy . oznaczyłeś to tagiem ubuntu - próbowałeś już tego apt?
mikeserv
11
Ubuntu: 40.000 najczęstsze programy: $ sudo apt-get install [name]. Rzadsze oprogramowanie: niektóre muszą być zbudowane ze źródła za pomocą {cmake .. && make, ./configure && make, waf, scons itp. ~ 10 opcji budowania}.
Knud Larsen
6
Masz trzy wersje Windows © i ~ 100 wersji „Linux OS”. Niemożliwe jest utrzymanie i przechowywanie więcej niż (40 000) najpopularniejszych programów.
Knud Larsen
35
to pytanie jest po prostu błędne. Większość oprogramowania jest rozprowadzany w postaci binarnej, zazwyczaj w .rpmlub .deblub .tgzopakowaniach. Źródło jest również dystrybuowane dla tych, którzy chcą go samodzielnie skompilować, zbadać, zmodyfikować lub spakować pod kątem jednego lub więcej dystrybucji. Nikt nie używa .zipdo dystrybucji plików binarnych w systemie Linux, ponieważ pliki .zip nie obsługują istotnych informacji, takich jak użytkownik, grupa i uprawnienia do plików, które zawierają.
cas
2
Muszę jeszcze skompilować dowolny program Linux, który chciałbym uruchomić. Pliki wykonywalne zawsze były dostępne ... jak dotąd.
user2338816

Odpowiedzi:

34

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.

Facundo Victor
źródło
1
Sądzę, że odpowiedź ta zostałaby poprawiona poprzez bardziej precyzyjne określenie różnic między modelami procesorów - a także w jaki sposób ~ 10 lat temu każdy wariant Unixa miał swój własny. Linux nie był wszechobecnym wpływem, jaki ma dzisiaj.
Sobrique
@Sobrique: Albo nawet wspominam o różnicach modeli procesorów per se - 10 lat temu było więcej niż 2 typy, które mamy dzisiaj, a Linux działał na prawie wszystkich z nich (ja sam korzystałem z Linuksa na PowerPC). Jest nadal częściowo aktualne w przypadku x86, AMD64 (znanego również jako x86-64) i ARM. MIPS jest nadal dość popularne wśród ludzi, którzy mogą produkować własne układy scalone, ponieważ jest teraz całkowicie wolne od patentów.
slebetman
Przepraszam za opóźnienie! Dziękuję wam obu! Dodałem kilka odniesień do architektur procesorów, a także dodałem link do listy porównawczej. Nie chcę, żeby odpowiedź była tak duża. Ale tak, to bardzo istotne!
Facundo Victor,
1
Komentarz bezpieczeństwa sugeruje, że czytnik / instalator wie, jak odczytać i zrozumieć kod. Biorąc pod uwagę, że podatność na atak szokowy przetrwała dziesięciolecia bez zauważenia, z szacunkiem sugeruję, że jest to nieco fałszywe przekonanie. Pozwala znającym się na rzeczy i kompetentnym programistom oceniać kod tak, ale nie jest to tak naprawdę odstraszający środek bezpieczeństwa, jak reklamowany. Może faktycznie mieć odwrotny skutek. Hakerzy finansowani przez państwo i przestępczość zorganizowaną prawdopodobnie wnoszą obecnie wkład do całego dworu bibliotek / projektów typu open source w nadziei na posadzenie kolejnego otwarcia skorupy ...
Techmag
Masz rację! Zmodyfikowałem odpowiedź, aby to odzwierciedlić. Starałem się nie tracić koncentracji na głównym celu odpowiedzi. Dziękuję Techmag!
Facundo Victor,
10

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!

SlySven
źródło
8

Po pierwsze, twoje pytanie opiera się na błędnej przesłance. Programy 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.

Gilles „SO- przestań być zły”
źródło
5

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.

phyrfox
źródło
Właśnie dlatego prawdopodobnie używasz 32-bitowego firefoxa, podobnie jak wiele innych programów w „64-bitowym” systemie operacyjnym Windows, podczas gdy 64-bitowy Linux zwykle uruchamia 64-bitową aplikację.
mchid
5

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.

rackandboneman
źródło
4

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

zje
źródło
5
System Windows zależy również od podstawowej architektury. Aplikacje Windows z obsługą ARM nie działają na zwykłych laptopach / komputerach stacjonarnych i tak dalej. To główny powód, dla którego Linux ma znacznie lepszą obsługę sprzętu - ponieważ kod jest napisany do kompilacji na dowolnej platformie, która ma rozsądną implementację Linuksa, podczas gdy Windows zależy od obecności znanych typów sprzętu.
phyrfox
Jeśli budujesz Windows / x86, to pokrywasz 95% binarnej kompatybilności. To całkiem nieźle. Podczas gdy Linux / x86 staje się coraz bardziej popularny, wywodzimy się ze świata, w którym masz różne wielkie nazwiska z ich własną specjalną architekturą procesora i wariantem Uniksa - który nie był kompatybilny binarnie.
Sobrique
@Sobrique Skąd masz tę 95% liczbę? Ostatnim razem, gdy szukałem, były 4 procesory ARM na każde 1 x86. Było to kilka lat temu, zanim wszyscy zaczęli używać smartfonów z procesorami ARM. Jeśli więc założymy, że nie ma innych procesorów, to jest to 20%.
ctrl-alt-delor
3

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.

Rapti
źródło
0

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.

xempes
źródło
0

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ć.

Nairolf21
źródło
0

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.

psusi
źródło