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

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?

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 :)

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.

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.

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.

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.

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.

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.

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.

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.

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.