Co Linus Torvalds miał na myśli, mówiąc o przenośności? [Zamknięte]

41

W debacie z Andrew Tanenbaumem na temat architektury mikrojądra vs. monolitycznej architektury systemu operacyjnego Linus Torvalds powiedział:

Przenośność jest przeznaczona dla osób, które nie mogą pisać nowych programów.

Co miał przez to na myśli?

ykombinator
źródło
8
Uważaj, o czym czytasz, wyciągając te „debaty” (flamewars) ze „starych” dni. Pomyśl, że ponieważ Linux był bardzo bliski sercu Linusa, prawdopodobnie podczas tych dyskusji narastało wiele emocji. Dlatego najprawdopodobniej natkniesz się na wiele stwierdzeń po to, aby być bezczelnym lub wkurzyć kogoś.
Wayne Koorts
Tego rodzaju pytania są obecnie omawiane na naszej stronie z meta-dyskusją .
1
zalecana lektura: Porozmawiaj o tym {blog}
gnat

Odpowiedzi:

82

Jak pisze Linus w debacie, jest to język z policzkiem (tzn. Nie należy go traktować zbyt poważnie).

Następnie wyjaśnia, że ​​chociaż przenośność jest dobrą rzeczą, jest to również kompromis; nieportowalny kod może być znacznie prostszy. Oznacza to, że zamiast uczynić kod idealnie przenośnym, wystarczy uczynić go prostym i wystarczająco przenośnym („przestrzegaj przenośnego interfejsu API”), a następnie, jeśli trzeba go przenieść, przepisz go w razie potrzeby. Stworzenie doskonale przenośnego kodu może być również postrzegane jako forma przedwczesnej optymalizacji - często więcej szkody niż pożytku.

Oczywiście nie jest to możliwe, jeśli nie możesz pisać nowych programów i musisz trzymać się oryginalnego :)

Joonas Pulakka
źródło
20
Uzgodniono przedwczesną optymalizację.
Mark Gibaud,
4
+1 Linus jest znany ze swojego humoru w policzku, ale niektórzy traktują to, co mówi, zbyt poważnie.
Spoike 30.01.11
12

Myślę, że oznacza to, że każdy program powinien być napisany specjalnie dla sprzętu i systemu operacyjnego, na którym działa.

Myślę, że kieruje nim, ponieważ ten kod ogólnego przeznaczenia, który może działać na kilku platformach, jest mniej wydajny lub bardziej podatny na błędy niż kod napisany specjalnie dla jednej platformy. Oznacza to jednak, że kiedy rozwijasz się w ten sposób, musisz utrzymywać kilka różnych linii kodu.

ChrisF
źródło
myślę, że właśnie to miał na myśli
Chani,
9

Kiedy po raz pierwszy napisano Linuksa, korzystał on z funkcji dostępnych tylko na procesorze i386, który był wówczas dość nowy i drogi.

To właśnie robi linux: używa po prostu większego podzbioru funkcji 386 niż wydaje się, że robią to inne jądra. Oczywiście powoduje to, że jądro nie nadaje się do przenoszenia, ale także sprawia, że ​​projekt / dużo / jest prostszy. Możliwy do zaakceptowania kompromis, a przede wszystkim taki, który umożliwił Linuksa.

Gdy wkroczyliśmy w XXI wiek, funkcje, które uczyniły i386 wyjątkowymi, stały się całkowicie popularne, pozwalając Linuxowi stać się bardzo przenośny.

Andomar
źródło
2
„… stał się całkowicie głównym nurtem, pozwalając Linuxowi stać się bardzo przenośnym” i udowodnił, że przenośność Linuksa w tym momencie byłaby przedwczesną optymalizacją.
2
@Roger: Naprawdę nie mogę się zgodzić. Funkcje te stały się głównym nurtem - ale z biegiem czasu procesory dodały więcej funkcji, z których wiele Linux albo całkowicie ignoruje, używa tylko minimalnie, albo musiało zostać masowo (i boleśnie) przepisane, aby używać nawet całkiem dobrze. Jednocześnie Linus ma przynajmniej jakiś punkt: coś, co teraz działa całkiem dobrze (nawet nieprzenośnie), wyprzedza coś, o czym mówi się przez lata, ale nigdy się nie kończy (np. GNU HURD).
Jerry Coffin
@Jerry - brzmi jak projekty badawcze w miejscu, w którym kiedyś pracowałem: „Powinieneś się teraz poddać. To, nad czym pracuję, sprawi, że wszystko, co robisz, stanie się przestarzałe”. To było 20 lat temu. Nadal nie widziałem, aby nowe rzeczy z hukiem opuściły laboratorium badawcze.
szybko_now
@Roger, przenośność nie jest optymalizacją.
7

Jako osoba, która zrobiła dużo Java i od lat doświadcza fenomenu „pisz raz, debuguj wszędzie” co tydzień, mogę w pełni się do tego odnieść.

A Java jest prawdopodobnie łagodnym przykładem. Nie mogę nawet wyobrazić sobie, przez co przechodzą ludzie, którzy próbują, będąc przenośną bazą kodu w języku / zestawie narzędzi, który nawet nie został zaprojektowany jako przenośny.

W tej chwili pracujemy nad pomysłem napisania wersji Lite jednego z naszych produktów na urządzenia mobilne. Przeprowadziłem badania dotyczące tego, jak zrobić jego przenośną wersję zarówno dla J2ME, jak i Androida - która próbuje udostępnić jak najwięcej bazy kodu (oczywiście nie może być w pełni „przenośna” per se, ale jest to podobna filozofia ). To koszmar.

Tak więc, czasami naprawdę dobrze jest myśleć (i robić) w zakresie korzystania z danych narzędzi dla danego zadania. tzn. swobodnie rozwijający się przeciwko jednej, pojedynczej, monolitycznej platformie / środowisku. I po prostu piszę osobne, czyste wersje dla każdego.

Stoły Bobby'ego
źródło
5

Chociaż niektórzy ludzie postrzegają / traktują przenośność, przestrzeganie standardów itp. Jako moralnie lepsze lub coś w tym porządku, to tak naprawdę sprowadza się do ekonomii.

Pisanie przenośnego kodu wiąże się z kosztami związanymi z jego przystosowaniem i (często) rezygnacją z niektórych funkcji, które nie są dostępne we wszystkich obiektach docelowych.

Kod nieprzenośny wiąże się z kosztami związanymi z przenoszeniem kodu, gdy zależy Ci na nowej architekturze i (często) rezygnuje z niektórych funkcji, które nie są (lub nie były) dostępne w pierwotnym celu.

Dużym kwalifikatorem jest „kiedy / jeśli zależy ci na nowej architekturze”. Pisanie przenośnego kodu wymaga wysiłku z góry w nadziei na ostateczną korzyść z możliwości użycia tego kodu na nowych / różnych architekturach przy niewielkim lub żadnym wysiłku. Kod nieprzenośny pozwala opóźnić tę inwestycję w przenoszenie do momentu, gdy będziesz (przynajmniej rozsądnie) pewien, że naprawdę musisz przenieść do określonego celu.

Jeśli masz pewność, że zamierzasz przenieść do wielu celów, zwykle warto zainwestować z góry w minimalizację długoterminowych kosztów przenoszenia. Jeśli nie masz pewności, ile (lub nawet jeśli) będziesz musiał przenieść kod, pisanie nieprzenośnego kodu pozwala zminimalizować koszty początkowe, opóźnić lub nawet całkowicie uniknąć kosztu uczynienia kodu przenośnym.

Myślę, że warto również zauważyć, że mówiłem o „przenośnym” i „nieprzenośnym”, jak gdyby istniał wyraźny podział między nimi. W rzeczywistości nie jest to prawdą - przenośność jest kontinuum, od całkowicie nieprzenośnego (np. Kod asemblera) do niezwykle przenośnego (np. Info-zip) i wszędzie pomiędzy.

Jerry Coffin
źródło
4

Tanenbaum podkreśla, że ​​duża część Linuksa jest napisana w sposób niemodularny, aby wykorzystać procesor 386, najnowocześniejszy w tym czasie, zamiast uczynić interakcję procesora komponentem, a zatem bardzo łatwo wymienić. Tanenbaum zasadniczo uważa, że ​​fakt, że jądro jest tak monolityczne i powiązane z procesorem 386, bardzo utrudnia,

  • Przenieś sam Linux na inną platformę CPU (oczywiście niepoprawne, AMD64, PowerPC itp.)
  • Programy portów napisane dla systemu Linux x86 na inną architekturę procesora (również niepoprawną)

Obóz linux zawiera kilka punktów, między innymi:

  • Linux oferuje wielowątkowy system plików jako część projektu
  • Mikrojądro, choć interesujące i intuicyjne, nie jest zbyt wydajne
  • Zgodność z przenośnym interfejsem API sprawia, że ​​problem z przenośnością jest większy lub mniej kłopotliwy niż blokowanie.
Anatolij G.
źródło
1
Teraz trzymaj się ... w czasie tej debaty przenośność była znacznie większym problemem. AMD64 i PPC pojawiły się wiele lat.
Matt Olenik,
1
Masz całkowitą rację - jednak inni, w tym Linus, zauważyli, że nie było to tak duże zmartwienie, jak wydawało się Tanenbaum
Anatolij G
Mikrojądra nie działają dobrze? Byłoby to szokiem dla tych z nas, którzy z nich skorzystali.
WŁAŚNIE MOJA poprawna OPINIA
Nie sądzę, że mikrojądra nie działają dobrze - używam Macha (OsX) i działa świetnie. Linus jednak o tym wspomniał.
Anatolij G.
3

Jeśli chcesz napisać kod przenośny, musisz napisać kod przenośny.

Co mam przez to na myśli?

Projekt musi odzwierciedlać cel. Jeśli na przykład językiem jest C, zaprojektuj go tak, aby minimalna liczba wierszy kodu musiała się zmienić, aby działał. Oznaczałoby to często oddzielenie wyświetlacza od obliczeń, co zresztą jest dobrą filozofią projektowania (MVC). Większość kodu C można skompilować w dowolnym miejscu, pod warunkiem, że masz dostęp do dobrego kompilatora. Wykorzystaj to i napisz jak najwięcej, aby być ogólnym.

BTW, ta odpowiedź będzie dotyczyć tylko aplikacji. OS i wbudowane są zupełnie innym zwierzęciem.

Michael K.
źródło
2

Interpretuj to stwierdzenie „dosłownie” takim, jakim jest.

W innym cytatów Linus on powiedział: „C ++ próbuje rozwiązać wszystkie problemy źle Rzeczy C ++. Rozwiązuje są trywialne rzeczy, niemal czysto składniowych rozszerzeń C zamiast ustalania jakiś prawdziwy głęboki problemu”.

Również w swojej biografii linus „Just For Fun”, cytując o mikrojądrach, powiedział, że w przypadku problemu ze złożonością „n”, jeśli podzielisz problem na „1 / n” unikalne części… wtedy całkowita złożoność opracowania takiego systemu byłaby bądź „n!” samo to jest wystarczającym czynnikiem, aby nie próbować czegoś takiego, a uzyskanie wydajności z tak złożonego systemu byłoby bardzo trudne.

pankajdoharey
źródło
2

Musisz wziąć pod uwagę fakt, że podczas tych debat Linux był bardzo nowy i był w dużej mierze systemem operacyjnym 386. Myślę, że gdybyś dziś zapytał Linusa, miałby inne zdanie. Może nie tak ekstremalny jak Tannenbaums, ale prawdopodobnie pokiwał hime głową i powiedział, że miał rację co do niektórych rzeczy.

Linus i inni programiści jądra bardzo się starali, aby Linux był przenośny, ale z drugiej strony Linux mógł nigdy nie istnieć, gdyby Linus musiał na początku uczynić go przenośnym.

Erik Funkenbusch
źródło
2

Oznacza to, że ludzie, którzy potrafią pisać dobre programy, nie potrzebują urządzeń przenośnych, ponieważ mogą pracować od zera.

To mniej uzdolnieni programiści, którzy chcą „importować” inne programy (przenośność) do bieżącego.

Tom Au
źródło