eRIZ's weblog

PHP, webdesign, Linux, Windows i inne, bo nie samym chlebem człowiek żyje

10 powodów, dla których Windows jest lepszy od…

Tak, tak, dobrze wpisałem tytuł. Wbijam przysłowiowy kij w mrowisko! Wszędzie można spotkać się z opiniami, jaki to Linusk (w nawiązaniu do arcy733+a ;]) jest the best i w ogóle spychając pozostałe systemy (a zwłaszcza Windows) do rangi błota zalegającego na dnie kałuży.

Disclaimer: Micro$oft nie zapłacił mi za napisanie tej notki, są to moje spostrzeżenia po obcowaniu z systemami należącymi do obu grup.

Prolog

Niejednokrotnie spotykałem się z opiniami fanatyków (tak, fanatyków, a nie fanów; tym ostatnim jestem, ale pod warunkiem, że oprogramowanie działa sprawnie i tak, jak tego oczekuję), którzy mieszają zamknięty soft z błotem tylko dlatego, że nie pozwala na grzebanie w kodzie. Tak na dobrą sprawę, może tylko 0.00000(…)1% dokonuje jakichkolwiek poprawek. Dzisiaj skupię się na postawie użytkownika, a nie paczkera/developera/betatestera, etc.

Do napisania tej notki zbierałem się jakiś czas zastanawiając się nad argumentami i ich sensownością. W mojej opinii utwierdziły mnie wpisy Sołtysa i kFYatka.

1. sterowniki i architektura sprzęt-oprogramowanie

Pomimo, że systemy OS przebyły już długą drogę rozwoju, to w dalszym ciągu nie ma ujednoliconego schematu instalowania urządzeń; część jest dość typowa i system radzi sobie sam z obsługą, ale jest też grupa tych, które wymagają kompilowania niewiadomo, czego. Najdziwniejsza była dla mnie instalacja tabletu (nie był to Wacom), która wymagała ściągania źródeł kernela i rekompilowania go. Ludzie, czy za każdym updatem jajka mam tracić czas tylko po to, aby dokompilować sobie obsługę jednego urządzenia…? Fakt, producent nie udostępnia sterowników do systemu, ale skoro powstał jakiś nieoficjalny sterownik, to dlaczego nie da się go po ludzku zainstalować? Na tym polu Linux w dalszym ciągu ustępuje systemom spod znaku okien. A wszystko przez naprawdę proste narzędzie, jakim jest Menedżer Urządzeń. Czy aktualizacja sterownika/doinstalowanie niewykrytego urządzenia stanowiła jakiś większy problem? Nie, wszystko jest zebrane w jednym miejscu, programiści mają SDK, jak pisać sterowniki, aby działały i zostały uwzględnione przez system operacyjny. A Linusk? Hmm, pomyślmy… No właśnie, co urządzenie, to mechanizm; sterowniki do karty graficznej instalowane osobno i obsługiwane przez X-y, dźwięk przez ALSA/PulseAudio/etc… Wszystko jest porozrzucane po całym systemie. Ile razy się nasłuchałem, że nie działa dźwięk we Flashu przy tym albo przy tamtym serwerze dźwięku? Po co tyle pośredników? Serwer, klient… Przyznam szczerze, że wychodzi jednak fanatyzm programistów, którzy porzucają prostotę działania na rzecz wciskanych na siłę modeli i wzorców projektowych. Przecież w środowisku Windows sterowniki WDM działają bez zarzutu i nigdy nie spotkałem się z jakimikolwiek problemami kompatybilności z poszczególnymi aplikacjami. Wszystko po prostu DZIAŁA. Jest jeden quasi-serwer dźwięku i wszystkie aplikacje z niego korzystają…

2. problemy QT/GTK i zależności

KDE vs. GNOME. Niektóre aplikacje napisane pod KDE, drugie pod GNOME. I żeby wygodnie pracować, trzeba w rzeczywistości posiadać zainstalowane biblioteki obu środowisk. I tak, dla małego programiku trzeba ściągać w chorobę pakietów, z których może kilka funkcji jest używanych. A reszta sobie leży tylko dlatego, żeby zaspokoić zależności wpisane na sztywno. Jak to kFYattek napisał o analizowaniu bibliotek w zależności od potrzeb (odnośników do innych libów), można wprowadzić jakieś rozwiązanie, które instalowałoby tylko naprawdę potrzebne paczki, a nie wszystkie te, które są napisane w zależnościach. Tzw. piekło zależności istnieje w dalszym ciągu, ale pod inną postacią. Znowu mamy przewagę formy nad treścią – co z tego, że mamy porządek i całe paczki w magazynie, jak większość z nich stoi jako rupiecie i zawalają miejsce? Przecież to taki porządeczek, wszystko cacy i ładnie wygląda… Jeśli jednak nic z tego nie korzysta, to na chorobę? :P Pod Windows jest podobny problem, ale tylko w przypadku aplikacji portowanych z Uniksa (np. każda z osobna ma swoją kopię QT/GTK). Ale o problemach libów/paczek będzie nieco później. Wracając, wszystkie kontrolki są renderowane przez funkcje systemu (WinAPI) i też działa. Fakt, programista-leniuszek musi się bardziej namęczyć i będzie ględzić, bo nie będzie miał super-wygodnego-zgodnego frameworka, jakim jest GTK/QT, ale… Aplikacja nie potrzebuje do szczęścia niczego więcej, co ma każdy system w standardzie i tego, co ma wkompilowane w execu zajmującym mniej, jak 100 KiB. Fakt, zdarzają się ostatnio aplikacje napisane w różnych wersjach .net framework, ale osobiście, olewam takie aplikacje. Powód? Niekompatybilność wersji. Nie rozumiem, dlaczego nie można było zachować kompatybilności wstecznej, jaką oferuje np. DirectX – .net nie. Tak samo z aplikacjami pisanymi w Javie. Choć o ile w przypadku .net programy chodzą nawet żwawo (co mnie zaskakuje), to w przypadku Javy zachowam minutę ciszy… Heh, poględziłem, poględziłem, a Linuksiarze dalej się męczą w GNOME ze stertą bibliotek QT, z których nie korzystają i vice versa. :P Choć przyznam, że problemy z natywnością mają również aplikacje bazujące na XUL-u, które IMHO wynajdują koło na nowo. Jak zwykle, wszystko na rzecz ułatwiania życia programiście… Nie wyważaj otwartych drzwi.

3. aplikacje profesjonalne

Cóż, może i kwestia sporna, w końcu przez wiele lat system (przede wszystkim Wine) bardzo się rozwinął. Coraz więcej aplikacji działa bez problemów (a nawet lepiej) pod kontrolą Linuksa albo skompilowane via WineLib. O ile słyszałem o wielu pomyślnych próbach wystartowania aplikacji typu Photoshop, to z innymi może nie być tak do końca różowo. Najwięcej wątpliwości budzą we mnie aplikacje bardziej specjalistyczne, księgowe, np. wymagające kluczy sprzętowych, czy innych zabezpieczeń. Ale fakt faktem, jest coraz lepiej. ;]

4. kompilacja, kompilacja…

Jedną z rzeczy, która mnie osobiście naprawdę denerwuje, jest konieczność kompilowania wielu aplikacji/bibliotek. A już naprawdę irytujący jest fakt kompilowania całych bibliotek tylko dla jednej, czy paru funkcji… Marnowanie zasobów, miejsca na dysku i czasu. Fakt, niektórzy może przytoczą argument, że samodzielnie skompilowane binarki działają szybciej. Trudno się z nimi nie zgodzić… Ale czy poświęcony czas jest wart (na ogół) kilkuprocentowego wzrostu wydajności…? Mniejsza o czas, ale po co komu kilkanaście (kilkadziesiąt) bibliotek tylko po to, aby kompilator działał poprawnie…? Pamięta ktoś czasy Windows 95? Do szczęścia wystarczało 60 MiB miejsca na dysku. Dzisiaj same wspomniane przeze mnie biblioteki mogą tyle zajmować… Pewnie ktoś mi zarzuci, że Windows XP też dużo miejsca zajmuje (co to jest Vista? :O), ale da się go tak przerobić, że łącznie ze środowiskiem graficznym zeżre mniej niż pół giga. I w dalszym ciągu będzie można radośnie żyć bez kompilatora. :P Programy skompilowane mają jeszcze jeden – dla mnie wielki – mankament, który wiąże się z następnym punktem.

5. zarządzanie zainstalowanymi aplikacjami

Temat-zaczepka, szczerze mówiąc – bywa to dość często denerwujące, a to za sprawą różnych systemów pakietów dla dystrybucji. Pół biedy, gdy jest to tylko podział na „rodziny” DEB i RPM, ale coraz więcej dystrybucji implementuje swoje własne systemy paczkowania, wzajemnie ze sobą niekompatybilne. I znalazł sobie szary użytkownik jakiś ciekawy – jego zdaniem – programik. Szuka w repozytorium, ups, nie ma. Jest za to paczka dla innej dystrybucji, ale sobie nie zainstaluje. Pozostaje wyłącznie kompilacja… I zaczynają się wspomniane przeze mnie wcześniej problemy. Ok, Kowalskiemu program się najzwyczajniej w świecie znudził. Jeśli nie skasował źródeł, to wszystko w porządku, zdeinstaluje. A jak skasował? Ups… Trzeba znowu ściągać. Nie wiem, czy wystarczyłby sam Makefile, ale przecież co aplikacja, to inny diabeł może tam w środku siedzieć. :P Najbardziej zbliżone do ideału rozwiązanie ma IMHO system portów FreeBSD. Cóż, Unix, to nie tylko *BSD.

Pozostaje jeszcze kwestia zarządzania takimi aplikacjami. O ile pod Windows jest proste, ale jednak użyteczne narzędzie, jakim jest Dodaj/Usuń programy, to pod Linuksem już jest troszkę gorzej, ponieważ każda dystrybucja rozwiązuje inaczej kwestię zarządzania zainstalowanym oprogramowaniem. Czasem lepiej, czasem gorzej ;P.

6. multikomunikatory i menedżery plików

Jedną dosyć ważną kwestią, która skutecznie zatrzymuje mnie przy Windows, jest multikomunikator i menedżer plików. Pewnie część osób wie, że nieprzerwanie od paru lat używam Mirandy jako komunikatora. Jest odpowiednik pod Linuksem, który będzie dorastał jej do pięt? No właśnie… Najbardziej liczą się Pidgin i ostatnio może troszkę Galaxium, ale żaden z nich nie oferuje na pewno tego, co Miranda. W Linuksie zjadłyby mnie zależności i o przenoszeniu komunikatora na pendrive mogę praktycznie zapomnieć, a Miranda? Kopiuj i działaj. :P

Bardzo podobnie jest z Total Commanderem. Zjadacze kodu starej daty pewnie pamiętają jeszcze legendarnego Norton Commandera. Pod Linuksem ciężko o równie funkcjonalny odpowiednik, który by choć dogonił TC. W miarę użyteczny jest Midnight Commander, ale to raczej NC, a nie TC. :P Nie uwzględniam tutaj, oczywiście, sytuacji, w której uruchamiamy program przez Wine, ale mam na myśli natywne aplikacje.

7. przenośność aplikacji

Jak już wcześniej wspomniałem, tzw. piekło zależności w rzeczywistości nie znikło z systemów uniksowych. Fakt, menedżery pakietów dbają o to, aby wszystkie biblioteki były obecne w systemie, ale… Co w sytuacji, gdy chcemy skopiować program na pendrive’a? Owszem, można „wyczuć”, których bibliotek program używa poprzez odpowiednie narzędzia, jednakże jeśli rozpatrzymy przypadek, w którym biblioteka/program składa się z wielu składników, które zależą od siebie łańcuchowo, to może się okazać, że program potrzebuje biblioteki dla – hipotetycznie – tylko jednej funkcji. Ale ta biblioteka ma wpisane na sztywno jakieś zależności i…? Żeby zaspokoić wszystkie potrzeby może się okazać, że na pendrive’a skopiowanych zostanie wiele plików, z których w rzeczywistości, wystarczyłoby kilka. Oczywiście, pomijam tu sytuacje, w których aplikacja korzysta z bibliotek już obecnych w systemie. Szczerze mówiąc, nie widziałem aplikacji przenośnych, nie wymagających instalacji, przeznaczonych na system Linuksowy. To, że może nie są potrzebne, to swoją drogą, ale jeśli zdarzy się taki przypadek, że potrzebujemy jakiejś aplikacji, której nie ma w systemie, na którym będziemy pracować? Wiem, zaraz się odezwą, że jest internet, ale ludzie – przecież pod Windows ściągnę sobie aplikację przygotowaną specjalnie na pendrive’a, która zadziała bez instalacji jakiegokolwiek oprogramowania w systemie. Np. wspomniana przeze mnie wcześniej Miranda i Total Commander. Dodam również, że powstał jakiś czas temu standard przenośnych aplikacji, jakim jest U3… W systemach opartych na Open Source z podobnym rozwiązaniem się, niestety, nie spotkałem.

8. obejścia licencyjne

Jak to każdemu geekowi się zdarza, czasem (albo i trochę częściej ;]) poeksperymentuje. Jakiś czas temu instalowałem ejabberd pod FreeBSD. Instaluję ejabberd z portów, podczas kompilacji ujrzałem komunikat, o którym wcześniej nigdy nawet nie słyszałem. Zajrzałem pod wskazany w komunikacie link… Jakież było moje zdziwienie, gdy okazało się, że ten komunikat oraz stronę zeń prowadzącą utworzono tylko po to, aby przeczytać licencję i ściągnąć osobno paczkę uruchomieniową. A że była ona znacznych rozmiarów, postanowiłem nieco przeszukać sieć w celu odnalezienia odpowiedzi na pytanie, czy przypadkiem nie zabłądziłem gdzieś po drodze. Wystarczyło zainstalować wcześniej biblioteki uruchomieniowe erlanga, a nie cały framework, który posłużył do jego zbudowania… Litości, czy ja instalowałem wtedy erlanga po to, aby go rozwijać, czy specjalnie dla ejabberd? erlang-lite zainstalował się bez żadnych problemów i więcej nie zobaczyłem żadnego durnego komunikatu. Ok, a teraz wracając do tematu – wiem, niektóre licencje są chore:

You may install this Software only if you are currently a licensee
of FreeBSD (including substantially similar versions of FreeBSD) for
your own internal use only with your copy(ies) of FreeBSD (including
substantially similar versions of FreeBSD).

Ludzie, litości, przecież ja chciałem UŻYWAĆ, a nie rozprowadzać oprogramowanie. Już kompromisem byłoby zapytanie, w jakim celu chcę używać softu… Fakt, niektórzy mogą spełniać drugi warunek licencji (paczka: jdk-diablo), ale jaki to będzie odsetek użytkowników? Jedno proste pytanie, a oszczędziłoby nerwy i czas… Podejrzewam, że takich obejść „na łatwiznę” jest więcej, ale cóż…

9. oprogramowanie na komórki

Przedostatnią kwestią, jaką poruszę – może trochę taką marginalną, ale z mojego punktu widzenia trochę ważną, jest komunikacja z telefonami komórkowymi. Owszem, coraz częściej komunikują się one z komputerem (i nie tylko) poprzez port USB i działają jak pendrive’y, ale jeśli chodzi o oprogramowanie serwisowe, to sytuacja nie jest już taka prosta. Różne protokoły komunikacji bywają też i bolączką szklarzy, ale jeśli chodzi o programy serwisowe, to bywają problemy… Fakt, producenci mogliby wypuszczać sterowniki… Ale czy szary użytkownik poruszy niebo i ziemię, żeby producent, który patrzy bardziej na opłacalność przedsięwzięcia, napisał sterowniki dla pingwina? Mało prawdopodobne w kapitalistycznym świecie… Programy serwisowe dość często są pisane przez entuzjastów danych „słuchawek” i to przede wszystkim pod Windows – czasem po prostu mają swoje powody, aby nie ujawniać kodu źródłowego swoich tworów i nie portować aplikacji pod Uniksa… Patrzę z perspektywy użytkownika, a nie dewelopera…

10. użytkownik, to deweloper

Zauważyłem, że systemy o otwartym kodzie praktycznie zawsze zakładają, że Kowalski, który używa komputera do czytania poczty i oglądania filmów, słuchania piosenek albo zgrywania zdjęć z cyfrówki, to programista, któremu potrzebne są źródła wszystkiego, ponieważ często lubi sobie poprawiać aplikacje, z których korzysta. Skoro instalatory systemów, tak przyjazne użytkownikowi, pytają, jakie grupy pakietów instalować – programista/administracja serwera/stacja robocza – to dlaczego nie potrafią tej, wbrew pozorom, cennej informacji dostarczyć menedżerowi pakietów…? Chociażby wspomniany przeze mnie erlang, czy nie można by było zadać użytkownikowi pytania, w jakim celu instaluje oprogramowanie? Czy będzie chciał coś w nim zmienić (potrzebuje kompletnego frameworka), czy tylko zechce go użyć (tu erlang-lite). Można i oszczędzić miejsce na dysku, i łącze, i czas, a najważniejsze – nerwy śmiertelnika śledzącego komunikaty instalatora (ewentualnie, podtrzymującego cegłę uciskającą na enter ;P). Jedno proste pytanie, a ile może zdziałać… Ba, zapisanie informacji w systemie, która została dostarczona już na etapie instalacji… W Windows obrano zupełnie inną drogę – wszystkie biblioteki są instalowane w wersji runtime – w przeważającej większości przypadków będzie to trafny wybór, ponieważ programista i tak będzie wiedział, jak zaopatrzyć się w odpowiednie biblioteki/IDE/kompilatory. Owszem – nie można też z pytaniami „przegiąć”, jak to miało w przypadku kasowania skrótów w tzw. Viście… Ale każda skrajność jest niebezpieczna – system nie może być też zbyt user-friendly, bo użytkownik straci nad nim kontrolę. Wówczas ten najbardziej poszkodowany zaczyna czuć się zagubiony…

epilog

Chyba wbiłem kij w mrowisko, właściwie – w takim celu napisałem ten artykuł. Tak, jak napisałem w zajawce – wszędzie powinna być zachowana równowaga – każdy system ma swoje zalety, ale również i wady. O ile Linux jest IMHO naprawdę niezłym system, to jednak to samo mogę powiedzieć o Okienkach – każdy z nich posiada jednak swoje niedociągnięcia. Mimo to, na obu da się pracować, niektóre rozwiązania są naprawdę dobre. Pewnie wielu z Was (w tym także – do niedawna – również i mnie) nie wyobraża sobie uruchamianie serwera pod systemem Windows. Jednak np. w Wielkiej Brytanii dość popularne są hostingi bazujące na edycjach serwerowych systemów Windows i SQL Server, co nie znaczy, że z systemów linuksowych się nie korzysta. Panuje równowaga – jak w przyrodzie.

Niektórzy pewnie zarzucą, że są to systemy dziurawe, bardzo podatne na wirusy. A jednak już blisko 10 lat pracuję na oknach i wcale nie miałem z nimi większych problemów. Kwestia konfiguracji systemu, po prostu. ;] Bardzo łatwo jest zmieszać coś z błotem tylko dla tego, iż nie wie się, jak tego używać, dostrajać, konfigurować, czy zabezpieczać. Moim zdaniem, każdy geek (nawet i nie-geek) powinien posiadać przynajmniej podstawowe umiejętności w obsłudze systemu innego, niż ten, którego używa na codzień – Linuksiarz – Windows, Szklarz – Linux.

A przecież wielu z nas korzysta z symbiozy obu systemów – chociażby w routerkach, sieciach osiedlowych, czy w pewnych systemach firmowych – wszystko jest w stanie ze sobą WSPÓŁPRACOWAĆ. Ważne, żeby podejść z dystansem do wszystkiego. ;]

A jakie jest Wasze zdanie, Czytelnicy? Czego Wam brakuje w systemach Open Source, co jest standardem w Oknach? A może któryś argument jest przeze mnie nie trafiony? Każdy z nas się uczy od drugiego, więc jestem otwarty na wszelkie komentarze i konstruktywną krytykę popartą rzeczowymi argumentami, a nie flamem w stylu windows, to zuo, bo tak ma być.

28 komentarzy

dopisz swój :: trackback :: RSS z komentarzami

RSS z komentarzami :: trackback

Skomentuj

Możesz używać znaczników XHTML. Dozwolone są następujące tagi: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">

Wszystkie komentarze przechodzą przez moderację oraz filtry antyspamowe. Nie zostanie opublikowany komentarz, jeśli:

  • Jego treść obraża kogokolwiek.
  • W treści znajdują się wulgaryzmy i słownictwo ogólnie uznane za nieprzyzwoite.
  • Mam wątpliwości co do autora wpisu (Wszelkie anonimy są kasowane - niezależnie od zawartości - wpisz prawdziwy e-mail. Jeśli usunąłem, Twoim zdaniem, komentarz niesłusznie - daj znać). Zdarza się, iż sprawdzam kim jest komentujący.
  • Zawiera jakąkolwiek formę reklamy.

Warning: Undefined variable $user_ID in /usr/home/er1zpl/domains/eriz.pcinside.pl/public_html/weblog/wp-content/themes/inBlueDiary/comments.php on line 112

Szufladka