Dlaczego Internet zdobył przestrzeń zdalnych aplikacji, a X nie?

19

System X Window ma 25 lat, wczoraj miał urodziny (15-go).

Jak zapewne wiesz, jedną z jego najważniejszych cech jest oddzielenie strony serwera od strony klienta w sposób, którego nie posiadają systemy okienkowe Microsoft, Apple i Wayland.

W dawnych czasach (przepraszam za niejednoznaczne frazowanie) wielu wierzyło, że X dominuje nad innymi sposobami tworzenia okien z powodu tego oddzielenia serwera i klienta, umożliwiając uruchomienie aplikacji na serwerze gdzieś indziej, podczas gdy użytkownik klika i pisze na niej własny komputer w domu.

Takie użycie oczywiście nadal istnieje, ale w najlepszym wypadku jest marginalizowane. Kiedy piszemy i używamy programów działających na serwerze, prawie zawsze korzystamy z Internetu z jego kodem HTML / CSS / JS.

Dlaczego sieć wygrała, a X nie? Technologie używane w Internecie (wspomniany html / css / js) to bałagan. W połączeniu ze wszystkimi frameworkami back-endowymi (Railsy, ​​Django i inne) nawigacja jest naprawdę dżunglą. Wciąż sieć rozwija się dzięki kreatywności i postępowi, podczas gdy zdalne aplikacje X nie.

Martin Josefsson
źródło
6
Oba nie są nawet zdalnie porównywalne. Połączenia X-server pozwalają mi uruchamiać zdalną aplikację i wyświetlać lokalnie GUI, co jest zupełnie innym przypadkiem użycia niż pozwalanie na ładowanie zdalnych zasobów do lokalnego klienta.
Martijn Pieters
3
Nie zgadzam się, że istnieje różnica. Kiedy podłączam mojego klienta (przeglądarkę) do serwera (lokalnie lub zdalnie), mogę wyświetlić GUI mojej aplikacji (internetowej). Tak jak mogę wyświetlić GUI mojej aplikacji za pomocą sesji X.
Martin Josefsson,
4
Spróbuj napisać program X11 i porównaj go ze stroną HTML - również porównaj wymaganą przepustowość. Dodatkowo WWW nie zastąpiło X11, tylko Gopher.
2
Pieters: Jasne, strona jest renderowana na kliencie, a JS działa na kliencie, ale to tylko szczegóły techniczne. Najczęściej kod działa po stronie serwera (php, java, .net, python, ruby, cokolwiek). W praktyce oba są interfejsami do uruchamiania aplikacji na serwerze i wyświetlania na kliencie. X i sieć robią to na różne sposoby, ale to jest sedno.
Martin Josefsson,
14
Ponieważ technologia nie przeszła walidacji przez przemysł rozrywkowy dla dorosłych, jest to niezbędny krok w głównym nurcie wdrażania technologii (jest to fantazyjny sposób stwierdzenia, że ​​zdjęcia nagich kobiet nie stały się dostępne wystarczająco szybko w systemach X).
dasblinkenlight,

Odpowiedzi:

22

Wydaje się to teraz całkowicie oczywiste i fundamentalne, ale zabójczą innowacją w Internecie był hiperłącze. Nawet jeśli X nie był całkowicie bezużyteczny przez łącze modemowe, jego niezdolność do uruchomienia zupełnie nowego procesu na zupełnie nowym serwerze za pomocą jednego kliknięcia utrudniłaby jego przyjęcie do tego rodzaju zastosowania.

Karl Bielefeldt
źródło
1
To może być poprawna odpowiedź. Również klienci WWW działali na Apple i Microsoft OS.
Martin Josefsson,
Hiperłącze nie było innowacją w sieci WWW. Został zaimplementowany wiele razy wcześniej, na przykład w Apple Hypercard, popularnym programie z lat 80. i 90. o wielu niesamowitych podobieństwach do przeglądarki internetowej. Koncepcja hipertekstu i hiperłączy sięga lat 60. wraz z projektem Xanadu i została wdrożona wiele razy w wielu formatach, zanim Tim Berners-Lee w końcu stworzył własną implementację hipertekstu w sieci CERN na początku lat 90.
Charles Salvia,
3
@CharlesSalvia: Przełom hiperłączy HTML wynikał z adresu URL. W szczególności jego aspekt uniwersalny: globalny, z wystarczającą liczbą centralnych uprawnień do działania, niepowiązany z jednym określonym rodzajem mediów lub technologią. Twoje poprzednie technologie były znacznie, znacznie mniej uniwersalne.
MSalters
17

Ponieważ X wymaga posiadania dyplomu CS do napisania aplikacji. Podczas gdy Internet wymaga, abyś mógł pisać (nawet to).

Zwłaszcza we wczesnych dniach, kiedy internet był tylko HTMLem. Możesz otworzyć terminal i zbudować działający wyświetlacz w 10 minut, a następnie interaktywnie go ulepszyć dzięki natychmiastowej informacji zwrotnej. Ten niski pasek wejścia spowodował masową absorpcję użytkowników. Z drugiej strony budowanie aplikacji X-Server jest łatwym zadaniem nawet dla doświadczonych programistów.

10 lat zajęło, aby Internet był bezpośrednim konkurentem aplikacji X pod względem funkcjonalności i zapewniał takie same możliwości GUI. Ta funkcja została z czasem dodana do stosu językowego, umożliwiając programistom opanowanie jednego zestawu funkcji przed dodaniem następnego; więc ten stopniowy rozwój złożoności technologicznej utrzymał niski poziom (dla ludzi, którzy są już w terenie i jest ich dużo). Wskakiwanie na pole jest teraz o wiele trudniejsze niż 10 lat temu, ale nadal jest możliwe, a natychmiastowa informacja zwrotna z sieci sprawia, że ​​nauka jest bardziej satysfakcjonująca (ludzie potrzebują szybkiej satysfakcji, aby wzmocnić swoje popędy).

Koszt to kolejny kierowca. Rzeczywisty koszt nauki umiejętności programowania wystarczających do opracowania X-Servera jest znaczny. Następnie dodatkowo dostępność serwerów, na których można uruchomić aplikację, spowodowała wzrost kosztów. Nauka pisania HTML była praktycznie niczym, aby strona „Hello World” została uruchomiona, a dostawcy usług internetowych udostępnili bezpłatny hosting, który zainspiruje Cię do nawiązania połączenia internetowego. Możesz ćwiczyć za darmo. Kiedy w końcu potrzebowałeś hostingu biznesowego, dostępność firm hostingowych wzrosła, a koszt zawsze był stosunkowo tani.

Martin York
źródło
1
Zakładasz, że aby napisać aplikację używaną w X, musisz zrozumieć X api. Ale tak jak nie musisz rozumieć HTTP, aby napisać aplikację internetową, nie musisz rozumieć X, aby napisać aplikację działającą pod X. Możesz napisać ją w jednym języku, który preferujesz, i wystarczy mieć bibliotekę GTK na górze. O wiele łatwiej niż nauczyć się HTML, CSS i JS oraz języka serwera. Istota tego: tak jak nie trzeba pisać serwera HTTP, aby opublikować stronę internetową, nie trzeba pisać serwera X, aby obsługiwać aplikację X.
Martin Josefsson,
Nie zgadzam się z twoją analizą tam. Chociaż masz rację, że pisanie nowoczesnej aplikacji internetowej jest teraz prawie tak złożone, jak pisanie aplikacji X 10 lat temu. Pisanie X-aplikacji wciąż nie jest trywialnym procesem. To tak jak pisanie aplikacji Windows. Daleko poza możliwościami kogoś, kto nie zrobił znaczącego doświadczenia programistycznego. Z drugiej strony utworzenie strony HTML jest banalne i może być wykonane w 10 minut (nawet przez początkującego). Prowadzi to zatem do szybkiego ponownego egzekwowania i możliwości szybkiego eksperymentowania. To sprawia, że ​​znacznie niższy pasek do wejścia.
Martin York,
GTK było dostępne dopiero po ustanowieniu sieci.
user16764,
@ user16764: To nieprawda. Korzystałem z GTK w 1997 roku (nie jestem pewien, kiedy to się zaczęło, ale wcześniej). Sieć (jak w HTML / HTTP) mogła być wtedy rozwinięta, ale nie tak dobrze ugruntowana. Mam na myśli, że przeglądarka internetowa dopiero co została wprowadzona do głównego strumienia w 92 roku (pierwszy raz ją zobaczyłem). X ma jednak kilka innych menedżerów okien, które były wcześniej użyteczne. Pamiętam, że używałem twm (menedżer okien Tomka) i jednego nieco wyższego poziomu (którego zapominam), ale w 90 było wiele do wyboru (zbyt wiele) (i wcześniej były dostępne (tak myślę)).
Martin York,
@LokiAstari: Mylisz menedżerów okien i biblioteki GUI. Chociaż istnieje wyraźne nakładanie się (GNOME / Gtk, KDE / Qt), z pewnością nie są one identyczne. Nawet z menedżerami okien nadal odczuwasz światy bólu.
MSalters
11

Odpowiedź brzmi: „wiele technologii stosuje się z arbitralnych powodów historycznych lub społeczno-politycznych, a nie technicznych”. Najlepsze rozwiązanie danego problemu nie zawsze staje się dominującą technologią. (W rzeczywistości rzadko.)

W 2012 r., Gdy serwery HTTP są używane do tworzenia aplikacji interaktywnych na równi z aplikacjami komputerowymi, porównanie HTTP i X jest interesujące. Z perspektywy czasu X jest prawdopodobnie lepszą technologią do tworzenia bogatych, interaktywnych aplikacji sieciowych. Interaktywne aplikacje typu Desktop nie są dobrze odwzorowane na bezstanową, zorientowaną na dokumenty technologię, taką jak HTTP, a to niedopasowanie w przeszłości skutkowało różnego rodzaju obejściami (włamaniami) do tworzenia stanu, takimi jak pliki cookie, sesje itp.

Ale pierwotnym celem HTTP nie było tworzenie stanowych aplikacji typu Desktop. Miało to na celu pobieranie dokumentów i wyświetlanie informacji - informacji, które mogą prowadzić do innych dokumentów, które mogą być również natychmiast wyświetlane. Idea połączonego zbioru dokumentów sięga lat 60. XX wieku wraz zProjektem XanaduTheodora Nelsona . Sieć miała być implementacją hipertekstowej koncepcji Nelsona , która była próbą skomputeryzowania drukowanej strony - takiej jak encyklopedia lub gazeta - umożliwiając użytkownikowi natychmiastowe „przechodzenie” z jednego artykułu do drugiego za pomocą jednego kliknięcia.

Wiele iteracji tego pomysłu pojawiło się i zniknęło, na przykład Hypercard firmy Apple , który wdrożył koncepcję hipertekstu / hiperłączy, ale nigdy nie został wdrożony w sieci. World Wide Web był opartą na sieci implementacją hipertekstu przez CERN i prawdopodobnie wystartował, ponieważ Tim Berners-Lee opublikował swoją bibliotekę kodów przeglądarki za darmo, umożliwiając innym eksperymentowanie z nią. Doprowadziło to ostatecznie do przeglądarki Mosaic Marca Andreesena, poprzednika Netscape. A reszta to historia.


Ale ... podobnie jak w przypadku tak wielu technologii, zaczęły się pojawiać nowe możliwości, że oryginalni projektanci HTTP lub hipertekstu tak naprawdę nie zastanawiali się zbyt wiele. Internet został skomercjalizowany, a ludzie zaczęli tworzyć witryny o stanowej interaktywności, takie jak koszyki i loginy. Coraz bardziej oczywiste stało się, że bezstanowy i zorientowany na dokumenty charakter HTTP nie był zbyt dobrze dostosowany do aplikacji typu Desktop. Ale w tym momencie było już za późno. Wszyscy już używali HTTP. Tak więc, oto jesteśmy dzisiaj z różnymi hackerskimi aplikacjami AJAX starającymi się udawać, że są aplikacjami komputerowymi.

Charles Salvia
źródło
3

Technologie mogą teraz próbować rozwiązać podobne problemy, ale na pewno nie były w przeszłości.

Obecny stos HTML ewoluował z czasem od bardzo prostego przesyłania dokumentów tekstowych, poprzez „wizualne” dokumenty z niewielką ilością skryptów, do w pełni funkcjonalnej platformy aplikacji.

W momencie, gdy zaczął się HTML, nikt nie mógł marzyć o podłączeniu się do komputera zdalnego i uruchomieniu aplikacji graficznych. Dopiero po uzyskaniu lepszych opóźnień i przepustowości Internetu stało się to możliwe. Jednak w tym czasie HTML był już zawsze obecny. Wszyscy wiedzieli, że w ten sposób klienci i użytkownicy mają dostęp do aplikacji graficznej działającej na zdalnym komputerze.

I jak w przypadku każdego „darmowego” systemu, niemożliwe stało się „zresetowanie” całości i rozpoczęcie od nowa, aby tym razem zrobić to lepiej. Dlatego musimy się zamknąć i używać HTML / CSS / JS i żałuję, że ludzie, którzy go obsługują, w końcu się przekonają i pogrzebią go wraz z jego wieloletnią spuścizną.

To odpowiada na pytanie „Dlaczego wygrała sieć?”. Nie było konkurencji, sieć wygrała, zanim wszystko się zaczęło.

Euforyk
źródło
1
W momencie, gdy zaczął się HTML, istniało już przetwarzanie po stronie serwera, z serwerem NSCA HTTP i jego SGI. Większość aplikacji dostarczyła tekst, ale pamiętam taką, która była w stanie renderować niestandardowe mapy czarno-białe, przodka map Google.
mouviciel
Mapy obrazów rzeczywiście pochodzą z wczesnych lat ostatniej dekady ubiegłego wieku.
MSalters
1

Zgadzam się, że w zasadzie oba są podobne. Jeśli zadajesz pytanie „w jaki sposób możemy uruchomić kod na serwerze, ale zapewnić wizualizację na zdalnym kliencie?”, Uzasadnione jest przypuszczenie, że niezależne zespoły mogłyby znaleźć jedno z tych rozwiązań.

Podejrzewam, że powodem, dla którego jedno jest bardziej popularne pod innym względem, jest to, że oba podchodzą do tego samego problemu z zupełnie innych perspektyw. X to techniczne rozwiązanie problemu technicznego, ale sieć ewoluowała jako potrzeba rozwiązania problemu społecznego - w jaki sposób mogę pobrać zasoby ze zdalnego serwera i wyświetlić je na moim komputerze lokalnym i zrobić to w łatwy sposób i wygodne?

Sieć „wygrała”, ponieważ rozwiązała problem doświadczany przez większą liczbę osób. Pomyśl o analogii samochodu: zarówno luksusowe sedany, jak i ciężarówki pozornie rozwiązują ten sam problem: jak transportować coś z jednego miejsca do drugiego.

Ciężarówka rozwiązała problem techniczny dosłownie, jak ciągnąć coś z punktu A do punktu B, i do tego działa całkiem dobrze. Samochód osobowy ewoluował jako potrzeba, aby ludzie czuli się komfortowo podczas podróży oraz aby przewozić więcej ludzi i mniej obornika. Stało się koniecznością wymagającą wygody. Tak więc z biegiem czasu liczba samochodów osobowych znacznie przewyższyła liczbę pickupów na drodze (domyślam się, na podstawie obserwacji ruchu w Chicago, może w Teksasie jest inaczej? :-)

Tak więc, podobnie jak analogia samochód / ciężarówka, zarówno sieć, jak i X11 prawdopodobnie rozwiązują ten sam problem techniczny, ale służą całkowicie innym celom.

Bryan Oakley
źródło
1

Porównujesz jabłka do gruszek. W X Window chodzi o rozdzielenie renderowania zawartości ekranu na lokalnego klienta, który może być podłączony cienkim drutem do źródła treści. To naprawdę rozszerzenie modelu obliczeniowego z epoki „szklanego tty” na dziedzinę wysokiej jakości grafiki. X powstał w erze, w której komputery były jeszcze dość słabe, a większość prawdziwych obliczeń została przeprowadzona na komputerach z systemami unix lub mainframe. Chodziło o wykorzystanie mocy stosunkowo tanich „terminali X” i stosunkowo wolnych sieci, aby te poważne zasoby obliczeniowe były dostępne graficznie.

Powodem, dla którego nie wygrało to na komputerach Mac i PC, jest to, że ich rozwój zawsze był napędzany chęcią wspierania wysokiej klasy grafiki w lokalnych aplikacjach, w tym w grach, edytorach i grafice biznesowej. Wspieranie aplikacji rezydentów sieciowych to niedawna refleksja.

ddyer
źródło