Racjonalizacja (od łac. ratio, rozum) - jeden z tak zwanych mechanizmów obronnych polegający na pozornie racjonalnym uzasadnianiu swoich decyzji i postaw po fakcie, podczas gdy prawdziwe motywy pozostają ukryte, często także przed własną świadomością. Przykład za Wikipedią: “Chciałeś kupić auto sportowe, a małżonka vana. Kupiłeś vana więc udowadniasz sobie, że van jest lepszy.”

Mój przykład: “Nie umiesz posługiwać się wierszem polecenia w Windows, więc udowadniasz sobie, że i tak nie daje on żadnych możliwości.”

Uwagi wstępne

Nie jest moim celem, Drogi Czytelniku, udowadnianie nikomu, że wiersz polecenia Windows daje możliwości identyczne do Linuksowej konsoli. Tak na prawdę, tekst niniejszy nie ma na celu przedstawienia możliwości Windowsowego “czarnego okienka”. To nie cel, to środek. Celem jest kilka uwag o tym, co Agata Christie określała krótko jako “natura ludzka”.

W tekście znajdują się przykłady. Jeśli nie określono inaczej - kiedy mowa o systemie Linux polecenia wykonywane będą w środowisku dystrybucji Debian, przy użyciu interpretera bash. Przez Windows rozumiem: MS Windows XP Professional SP 2 działający w sieci zarządzanej przez MS Windows 2003 Server R2.

Część pierwsza: wiersz polecenia

Panuje opinia, niepowszechna wprawdzie, lecz wśród braci linuksiarskiej niezwykle wprost częsta, że Windowsowy wiersz polecenia w żaden sposób nie może się równać z Linuksową konsolą. Według szerokiej rzeszy użytkowników systemu spod znaku Pingwina, “czarne okienko” Windows nadaje się wyłącznie do wykonywania podstawowych, jakby rachitycznych operacji, nie nadaje się do automatyzacji pracy, a już na pewno nie da się za jego pomocą administrować systemem zdalnym. Proszę przejrzeć komentarze, ba - artykuły na dowolnym wortalu poświęconym Wolnemu Oprogramowaniu: Linux potrafi pod tym względem wszystko, Windows zaś nic. Kłopot w tym, że administratorzy serwerowych systemów z rodziny Windows o tym nie wiedzą i piszą rozbudowane skrypty służące do przeprowadzania prac administracyjnych w zarządzanych przez nich sieciach lokalnych. Jak to jest z owym “czarnym okienkiem” i ludzką mentalnością?

Przede wszystkim duża część użytkowników komputerów daje się złapać na swego rodzaju przesąd, jakoby Windows XP pochodził od prostego i ubogiego systemu DOS. Jest to taka sama prawda jak to, że człowiek pochodzi w prostej linii od szympansa. Linia NT niewiele ma wspólnego z tym topornym 16-bitowym tworem, jakim był Disk Operating System wraz z nakładkami z serii Windows [1.x, 2.x, 3.x, 95 x, 98 x, Me]. Rówieśnicy, jakimi są NT 3.5 i Windows 95, pochodzą z dwóch różnych światów, jedyne co mają podobne to interfejsy. Prawdziwy linuksiarz nie powinien wszelako być powierzchowny, czyż nie?
Drugi z przesądów, o jakim należy wspomnieć to przeświadczenie, iż przeciętny administrator Linuksa używa w normalnej pracy setek zawiłych poleceń, wykorzystując tysiące opcji. Myślę, że wśród doświadczonych administratorów nie znajdę wielu oponentów w stwierdzeniu, iż ponad osiemdziesiąt procent czynności administracyjnych da się przeprowadzić przy pomocy mniej niż dwudziestu procent dostępnych poleceń. Na potrzeby tego tekstu spróbowałem oszacować ilość znanych mi komend w systemach Linux i Windows. Jeśli chodzi o Linux, potrafię wymienić około 250 poleceń, w środowisku Windows - około 200. (Resztę mam “zapamiętaną” w dokumentacji.) W obu przypadkach do codziennej pracy wystarczało mi mniej niż 50.

Tutaj rodzi się jednak pewien problem. Teoria systemów operacyjnych jest o wiele starsza niż komputery osobiste i w momencie tworzenia tak Windows, jak i Linuksa znana była ich twórcom. Projektanci obu systemów nie “odkrywali Ameryki” - z góry wiedzieli, jakie funkcjonalności mają one zapewnić. Teoria nie wskazuje jednak, jak owe funkcjonalności mają być zrealizowane. Chodzi o to, że nie sposób zestawiać ze sobą poszczególnych poleceń obu systemów “jeden do jednego”. Popatrzmy:

No, to jeszcze od biedy daje się w ten sposób przedstawić. Od biedy, bo czyż findstr jest tym samym co grep, albo czy Windowsowe echo jest funkcjonalnym odpowiednikiem echo Linuksowego? No chyba nie, ale idźmy kawałek dalej:

No właśnie, tutaj zaczynają się przysłowiowe schody. Pierwsze polecenie pozwala na utworzenie dowiązania do pliku. Zwracam uwagę na fakt, że w Windows jak najbardziej da się takie dowiązanie utworzyć. W omawianym przeze mnie XP nie istnieje jednak dowiązanie miękkie, które w systemach z rodziny UNIX uzyskujemy poleceniem ‘ln -s‘ Możliwości takiej nie daje po prostu system plików NTFS w wersji używanej w XP. Wyższe wersje NTFS (Vista, Server > 2003) dają i taką możliwość. Jak widać, w Windows brak osobnego polecenia będącego odpowiednikiem ln. Dowiązania tworzymy podpoleceniem wchodzącym w skład większego programu.

Z rzekomym odpowiednikiem uptime jest o wiele większy problem i doskonale obrazuje on to, o czym chcę napisać. Windowsowe systeminfo to polecenie zwracające informacje o stanie systemu. Stanie systemu w ogóle. Zwraca więc jego czas pracy, nazwę, domenę w której działa, wersję systemu wraz z informacjami o poprawkach, model maszyny, informację o pamięci operacyjnej, lokalizacji pliku wymiany i jeszcze parę innych ciekawych linijek. Nie można jednak napisać, że systeminfo jest w takim razie odpowiednikiem Linuksowych: hostname, domainname, uname, free, czy wspomnianego już uptime. Niemal każde z wymienionych “odpowiedników” daje bowiem nieco szersze informacje, niż samo systeminfo. Nie znaczy to jednak z kolei, że Windows nie daje możliwości uzyskania szerszych informacji…
Tak na marginesie: “domena Windows” to nie to samo co “domena internetowa”, być może nie dla wszystkich jest to oczywiste. Domeny Windows to jeden ze sposobów realizacji zarządzania sieciami lokalnymi - traktowania zespołu połączonych siecią stacji roboczych jako swego rodzaju jednego organizmu.

Pytanie: co to za system?

Wróćmy jeszcze do fsutil hardlink create. Polecenie to doskonale obrazuje Windowsową koncepcję blokowania prostych komend w większe grupy. O ile systemy typu UNIX budowane są według zasady: jeden problem - jedno polecenie, o tyle w Windows przeciwnie - jedno rozbudowane polecenie zapewnić ma rozwiązanie kompleksowe. Samo fsutil składa się z 11 składowych, każde z nich z kolei posiada kilka opcji. I tak na przykład:

A propos. Ciekawe, że większość użytkowników Linuksa w ogóle nie zdaje sobie sprawy z tego, że NTFS daje możliwość przyłączania partycji, analogiczną do Linuksowego mount. Partycja NTFS wcale nie musi mieć przyporządkowanej literki, zresztą proszę zwrócić uwagę, w jaki sposób systeminfo wyświetla aktywne urządzenie rozruchowe: ‘\Device\HarddiskVolume1‘ na przykład. Podobnie system widzi wszystkie pozostałe partycje, które w oknie Eksploratora zazwyczaj faktycznie wyświetlane są jako “C:”, “D:”, “E:” i tak dalej. Nic nie stoi jednak na przeszkodzie, aby partycja została przyłączona do głównego systemu plików i w Eksploratorze widziana jako część partycji systemowej. Do przyłączania woluminów NTFS służy polecenie: diskpart assign mount=ścieżka Ogólnie, polecenie diskpart jest jeszcze bardziej rozbudowane niż przytoczone wcześniej fsutil, dość skomplikowane, a nieobeznanej osobie łatwo za jego pomocą zepsuć system, nie będziemy się więc nad nim dłużej zatrzymywać.

Windows zawiera więcej podobnych “kombajnów”. Jednym z najbardziej znanych jest polecenie net. O ile fsutil składało się z 11 podpoleceń, o tyle net zawiera ich aż 22. Polecenie ochrzczono tak chyba dla zmylenia przeciwnika, bowiem można z niego korzystać nawet wtedy, kiedy do naszej maszyny nie podłączono kabla sieciowego. Z jego pomocą można zarządzać usługami (net start, net stop, czy net pause), administrować kontami użytkowników (net accounts, net user), synchronizować zegar komputera (net time), a przede wszystkim zarządzać zdalnym dostępem do poszczególnych maszyn (do czego oczywiście niezbędny jest kabel sieciowy (czy jakieś inne medium)). Przykładowo, wykonalne, choć nieco niebezpieczne polecenie:

C:>net use B /user:administrator@B

spowoduje, że uzyskamy praktycznie pełny dostęp do zdalnej maszyny o nazwie “B” - przyda się w części trzeciej artykułu.

Filozofia Windowsa jest na tyle inna, że niekiedy, choć da się w nim uzyskać określoną informację, w ogóle nie mamy do czynienia z żadnym poleceniem. Przykład? W Linuksie mamy grupę komend: basename, dirname, pathchk. dirname jest to polecenie, które po podaniu pełnej ścieżki do pliku zwraca nazwę podkatalogu. Dobra rzecz, kiedy pisze się skrypty. W Windows też da się wyodrębnić sam katalog, tylko inaczej. Załóżmy, że mamy skrypt skrypt.cmd, który pobiera pełną ścieżkę do pliku:

@echo off
echo %1
echo %~p1

Wynikiem wywołania:

C:>skrypt.cmd "C:\Documents and Settings\Skryba\Pulpit\plik.txt"

będzie:

"c:\Documents and Settings\Skryba\Pulpit\plik.txt"
\Documents and Settings\Skryba\Pulpit\

Proszę zwrócić uwagę na zapis: %~p1. Zmienne w skryptach oznaczane są odpowiednio: %1, %2, %3 i tak dalej. Owo ~p to modyfikator, który umożliwia wyodrębnienie katalogu zawierającego plik. Czyli: da się żyć bez polecenia dirname?

Myślę, że na razie tyle wystarczy. Nie jest moim celem przepisywanie treści pomocy systemu Windows. Tak, proszę Państwa. Standardowa ogólnodostępna pomoc zawiera opis paruset poleceń i podpoleceń, które naprawdę pozwalają na zarządzanie systemem plików, zadaniami systemu, użytkownikami, zabezpieczeniami i wszystkim tym, co krócej określane jest po prostu jako administracja. Trzeba tylko czytać. (Tylko lub aż.) Jasne, że nie są to takie same polecenia, jakie znamy z systemu Linux - to raz. Nie twierdzę także, że praca jest tak samo efektywna jak w choćby Debianie, ale na ogół możliwa - to dwa. A propos Debiana…

Część druga: ulinuksowianie Windows

Gdyby głównym tematem niniejszego artykułu była Windowsowa konsola (a przypominam, że nie jest), tej części w ogóle by nie było. Jako że tekst jest jednak de facto o użytkownikach i ich podejściu do oprogramowania, zanim przejdziemy do omawiania metody, w jaki Windows we właściwy sobie sposób realizuje pracę w sieci, pozwolę sobie zauważyć parę spraw.

Tym co zazwyczaj spędza sen z powiek początkujących administratorów, jest praca na odległość. Ogólnie wiadomo, że w Linuksie można posłużyć się protokołem ssh i logując na zdalnej maszynie wykonać wszystkie potrzebne czynności administracyjne. Windows bywa zazwyczaj kojarzony z protokołem RDP. Przy pomocy programu Podłączenie Pulpitu Zdalnego wykorzystującego Remote Desktop Protocol, faktycznie można zalogować się na serwerze, czy komputerze klienckim i zająć administracją. Ten, kto próbował tej sztuki, wie jednak, że w praktyce od razu napotykamy na dwa problemy. Po pierwsze, RDP nie zawsze działa płynnie, często po prostu nie sposób w nim pracować, po drugie zaś: jak przy jego pomocy zresetować 100 komputerów klienckich naraz? (Problem nie jest wydumany - podobne rzeczy po prostu robi się, na przykład ze względów bezpieczeństwa.)

Przede wszystkim jednak: jak to jest z Linuksem. Linux to kernel systemu. Sam z siebie nie pozwala na interaktywną pracę użytkownika, o zdalnej nie wspominając. Aby dało się “wklupywać” polecenia, potrzebna jest powłoka, taka jak na przykład bash, tcsh czy zsh, czyli po prostu odpowiedni program. Tak na marginesie: cmd.exe, które omawiam w artykule, nie jest jedynym interpreterem poleceń systemu Windows. O wiele potężniejszym narzędziem jest na przykład MS PowerShell. Wspominam o tym dlatego, aby podkreślić, że wybór jest nie tylko w Linuksie. Dla potrzeb niniejszego tekstu wystarczą jednak programy standardowe.

Wracając do myśli przewodniej - mamy system operacyjny Linux wraz z odpowiednią powłoką. Czy to wystarczy? Oczywiście - nie. Niezbędnym jest jeszcze co najmniej komplet podstawowych programów, czy to pakiet coreutils, czy na przykład program BusyBox. Taki zestaw oprogramowania pozwoli nam na jaką taką pracę. Jednakże cudów nie ma. W takiej konfiguracji sieć jeszcze nie istnieje, czyli ze zdalnej pracy nici, jak to mówią. Aby administrować Linuksem zdalnie, potrzeba dodatkowo oprogramowania, które w ogóle udostępni nam sieć i programu, który pozwoli na zestawianie z naszą maszyną połączeń korzystających z protokołu ssh. (Oczywiście, może być telnet - to wolny kraj.) Reasumując - na zdalną pracę pozwala nam odpowiedni program, który trzeba zainstalować i skonfigurować. Ciekawym jest to, że przeciętny użytkownik Linuksa potrafi tę wiedzę przedstawić o wiele dokładniej, na wyrywki, od początku do końca i od końca do początku, kiedy jednak chodzi o Windows… Koniec - nie da się, bo WINDOWS nie daje takiej możliwości. Przepraszam, czy użytkownicy Slackware mają pretensje do Patricka Volkerdinga o to, że ta legendarna dystrybucja domyślnie nie zawiera środowiska GNOME? Ależ nie. Oni wiedzą, że trzeba go po prostu doinstalować, czyż nie tak? Czy ci sami użytkownicy mają pretensje do Microsoftu o to, że ich system nie zawiera demona sshd? Ależ tak. Ciekawe zjawisko. Wystarczy bowiem doinstalować odpowiedni program, aby zdalna praca w Windows przypominała tę znaną z Linuksa. Istnieje nawet rozwiązanie otwarte: OpenSSH, ale kto by się tym przejmował…

cmd.exe z Windows XP w terminalu Debian GNU/Linux

Wracając do meritum: nie inaczej sprawy się mają z całą chmarą poleceń, które z jasnych przyczyn trzeba pobrać, skonfigurować, ba - skompilować dla Linuksa, bo przecież to Wolne Oprogramowanie i nikt za nas tego nie zrobi. Kiedy jednak chodzi o Windows, to już gorzej, bo Bill nie umieścił na płycie instalacyjnej swojego systemu edytora vim, klienta putty, programu wyliczającego sumy md5, czy klienta poczty pine. Straszne. Oczywiście te i wiele innych poleceń jest dostępne dla systemu Windows, ale trzeba by je samodzielnie pobrać, a mam wrażenie, że dla wielu pobranie infantylnego w swojej prostocie programu instalacyjnego dla Windows to nie taki sam wysiłek, co na przykład pobranie kodów źródłowych dla Linuksa, skonfigurowanie ich, kompilacja, instalacja i znów konfiguracja. Oczywiście, że nie.

Repozytoria

Na koniec tej części uwaga na temat repozytoriów. Tak, dla Windows nie ma repozytoriów. Zastanawiam się dlaczego. W przypadku Debiana, Fedory, openSUSE, czy Gentoo nie było żadnego cudu, po prostu ktoś to zorganizował. Pewnie dlatego, że było potrzebne. W przypadku Windows mamy do czynienia z ciekawą sytuacją: dla tego systemu stworzono kilka tysięcy programów Open Source, a repozytorium nie ma. Tylko bez argumentów, że się nie da, proszę. Albo, że potrzeba na to jakichś środków. Dało się stworzyć całe to oprogramowanie? Aplikacja do obsługi repozytorium to po prostu jeszcze jeden program, pozostałe są napisane i spokojnie czekają na serwerach, a ponieważ życie nie znosi próżni, taki program na pewno by powstał, więc skoro go nie ma, to znaczy, że pewnie nie jest potrzebny.

Ja wiem, że na takie stwierdzenie każdy się obrusza, ale proszę spojrzeć na to tak: aby zainstalować program, wszystko jedno, czy klikając na ikonkę instalatora program.msi, czy używając polecenia ‘apt-get install program‘, trzeba najpierw wiedzieć, co zainstalować. Kiedy wiemy “co”, to “jak” nie stanowi większego problemu. Zauważyłem, że większości nowych użytkowników Linuksa nie na wiele przydaje się fakt, że biblioteki gstreamera znajdują się w repozytorium. Problem w tym, że trzeba wiedzieć, iż gstreamer jest w ogóle potrzebny. Oczywista - dobrze byłoby mieć taką wyszukiwarkę programów, jakimi przypadkiem są synaptic czy yum (co oczywiście nie jest ich główną funkcją). W takim Ubuntu bowiem, uruchamiamy synaptic, wpisujemy ‘przeglądarka internetowa‘, znajdujemy Firefox, zaznaczamy, klikamy instaluj i gotowe. W Windows? Z braku repozytorium, po sztubacku posłużymy się Wikipedią. Otwieramy, wpisujemy ‘przeglądarka internetowa‘, znajdujemy Firefox, klikamy na hiperłącze strony domowej, pobieramy, instalujemy i gotowe. Czy to się tak bardzo różni? Pewnie powiecie, że tak…

Wydaje mi się, że repozytoria w Linuksie nie powstały dlatego, że ułatwiają życie. Według mnie są raczej dość naturalną konsekwencją rozdrobnienia dystrybucji. Cóż to bowiem znaczy na przykład kompilator gcc dla systemu Linux? W rzeczywistości mamy gcc optymalizowane dla dystrybucji Arch, Debian, Fedora, openSUSE, Ubuntu czy Zenwak. Gdyby to chcieć umieścić na stronie FSF musiałoby: po pierwsze - powstać bardzo dużo linków do paczek dla poszczególnych dystrybucji, po wtóre - administracja stroną byłaby bardzo kłopotliwa. Proszę sobie wyobrazić, że kilkuset opiekunów poszczególnych dystrybucji śle maile do administratora strony FSF z prośbą o cokolwiek (zmianę paczki, odświeżenie mirrora, itp.). Z drugiej strony każdy z opiekunów miałby na głowie kilka setek, czy tysięcy stron poszczególnych projektów, gdzie trzeba by zamieszczać wersje oprogramowania dla danej dystrybucji. Sytuacja, w której każdy martwi się o siebie, jest po prostu prostsza, a że przy okazji Linuksowy manager pakietów dba o zależności? Tak po prawdzie w Windows wielkich problemów z tym nie ma. (Choć nie znaczy to: “nie ma w ogóle”.)

I jeszcze jedno: owszem, globalna aktualizacja systemu, typu Debianowego apt-get update jest wygodna, ale też w chwili obecnej większość aplikacji (nie tylko w Windows) sprawdza dostępność nowych wersji dla siebie - to z jednej strony, istnieją dystrybucje, w których brak managera zarządzania - to z drugiej strony, jeżeli w Linuksie zainstalujemy aplikację, której brak w repozytorium, to i tak manager jej nie zaktualizuje - to z trzeciej strony, Windows A.D. 2008 aktualizuje i siebie i MS Aplikacje jednym kliknięciem - to z czwartej strony. (To się nazywa: 5-wymiarowa czasoprzestrzeń.)
Wracając do poleceń systemu Windows.

Część trzecia: Windows na odległość

Opisany wcześniej sposób nie jest tym, co zaprojektowali inżynierowie z firmy Microsoft. Powtórzmy: w systemie Linux, pracując na maszynie “A”, logujemy się przez ssh (czy telnet - to wolny kraj) na maszynie “B” i wydajemy polecenie, na przykład: ps. W Windows jest zupełnie inaczej. Przede wszystkim dla systemów Microsoftu charakterystyczne jest pojęcie domeny Windows. Pokrótce pisząc: domena tworzona jest przez grupę komputerów zarządzaną przez jedną wyróżnioną maszynę zwaną kontrolerem domeny. Na owym kontrolerze tworzymy konta użytkowników, kontroler zapewnia nam uprawnienia do plików i tak dalej. Nie jest to ani lepsze, ani gorsze od tego co znamy z systemów Linuksowych. Jest to inne. Oczywiście przynależność komputerów do domeny nie jest konieczna, ale osobiście nie wyobrażam sobie zaawansowanej administracji grupą kilkuset komputerów bez tego wynalazku. To znaczy - wyobrażam sobie, ale nie w Windows. W Windows tak to zaprojektowano.

Siedzę więc przed wspomnianym wcześniej komputerem “A” z załadowanym Windowsem. Aby wyświetlić listę zadań na komputerze “B” z załadowanym Windowsem, na komputerze “A” wykonujemy polecenie:

C:> tasklist /s B /u administrator

Nazwa obrazu            PID Nazwa sesji      Nr sesji  Użycie pam.
==================== ====== ================ ======== ============
System Idle Process       0                         0        16 KB
System                    4                         0       208 KB
smss.exe                456                         0        56 KB
csrss.exe               504                         0     3 912 KB
winlogon.exe            528                         0     4 492 KB
services.exe            572                         0     2 120 KB
lsass.exe               584                         0     3 488 KB
svchost.exe             784                         0     2 428 KB
svchost.exe             852                         0     6 308 KB
svchost.exe             916                         0    21 260 KB

Zwracam uwagę na dwa fakty. Po pierwsze, jak już pisałem, Windows traktuje sieć nieco inaczej niż Linux, więc co za tym idzie i zasada pracy jest inna - z jednego stanowiska mamy potencjalną możliwość pracy na wszystkich innych. Sprawa druga: tak jak w każdym innym systemie, w Windows ważne są odpowiednie uprawnienia. Nie wykonamy opisywanego polecenia, jeżeli nie dysponujemy odpowiednimi uprawnieniami na komputerze “B” i częstokroć - na kontrolerze domeny.

W podobny sposób skonstruowana jest duża ilość poleceń, analogicznie zadziałają więc chociażby: taskkill, shutdown, systeminfo, czy choćby zwykłe dir. Jak widać, bez RDP naprawdę da się żyć i oczywiście wszystko to opisano w standardowej ogólnodostępnej pomocy Windows.

Podsumowanie

Kończąc artykuł, chciałbym podkreślić, że osobiście uważam, iż w konkurencji GNU/Linux kontra Windows, zdecydowanie wygrywa GNU/Linux. Nie dlatego jednak, że wprowadza jakąś nową funkcjonalność. Nie. Decyduje o tym wiele “drobiazgów“. Kilka z nich opisałem w ubiegłym roku w artykułach Windows vs Linux: porównanie architektury. Do tego, co tam napisałem dodać by można licencję GPL, mniejsze koszty całkowite, czy choćby to, że zdarzyło mi się pracować z Debianem, który po wpisaniu w konsoli polecenia uptime wyświetlał: 375 days, 10:55, a ostatnim z systemów Windows, który mógł poszczycić się podobną stabilnością był NT 4.0 Server, później było coraz gorzej. Teraz 28 dni wyświetlane przez systeminfo to maksimum. Przykładów wyższości Linuksa nad Windowsem da się wymyślić więcej, ale o ile prawdziwe jest stwierdzenie, że: “Wygodniej pracuje się w konsoli systemu Linux.“, o tyle: “Nie da się pracować w konsoli Windows.“, to według mnie typowy przypadek racjonalizacji.

W gruncie rzeczy problem nie leży ani w systemie Windows, ani w systemie Linux, tylko w użytkownikach. Przeciętny linuksiarz nie przykłada takiej samej miary do Windows i Swojego-Ukochanego-Systemu i ciągle przyjmuje postawę obronną. Dlaczego? Jakimś wytłumaczeniem jest to, że użytkownik jakiegokolwiek oprogramowania, przyzwyczajony do określonych działań, oczekuje od innych aplikacji, że będą robiły to samo - tak samo. Idąc tym torem myślenia oczekujemy, że zdalna praca na Windowsie będzie wyglądała tak samo jak w systemach Linuksowych, a przecież to nie tak. Nie tłumaczy to jednak racjonalizacji…

Korekta: Marta Siostrzonek-Bania