Co więcej, każdy z nich może wykonywać wiele różnych procesów obliczeniowych, które będą wykorzystywać zasoby tego konkretnego komputera.

Drugą kolosalną zaletą Unixa jest jego wieloplatformowość. Rdzeń systemu został zaprojektowany w taki sposób, aby można go było łatwo dostosować do niemal każdego mikroprocesora.

Unix ma inne charakterystyczne cechy:

• używanie prostych plików tekstowych do konfiguracji i zarządzania systemem;
• powszechne korzystanie z narzędzi uruchamianych z wiersza poleceń;
• interakcja z użytkownikiem poprzez urządzenie wirtualne - terminal;
• reprezentacja urządzeń fizycznych i wirtualnych oraz niektórych środków komunikacji międzyprocesowej w postaci plików;
• użycie potoków z kilku programów, z których każdy wykonuje jedno zadanie.

Aplikacja

Obecnie systemy uniksowe dystrybuowane są głównie wśród serwerów, a także systemów wbudowanych dla różnego sprzętu, w tym smartfonów. Systemy uniksowe również dominują nad superkomputerami, w szczególności Linux jest zainstalowany na 100% superkomputerów TOP500.

Pierwsze wersje Unixa zostały napisane w języku asemblerowym i nie miały wbudowanego kompilatora języka wysokiego poziomu. Około 1969 roku Ken Thompson z pomocą Dennisa Ritchie opracował i zaimplementował język B (B), który był uproszczoną (do implementacji na minikomputerach) wersją języka BCPL opracowanego w tym języku. Bi, podobnie jak BCPL, był językiem interpretowanym. Wydany w 1972 Druga edycja Unix przepisany w B. W latach 1969-1973 na podstawie Bi opracowano skompilowany język o nazwie C (C).

Rozdzielać

Ważnym powodem podziału w systemie Unix było wdrożenie w 1980 stosu protokołów TCP/IP. Wcześniej komunikacja maszyna-maszyna w Unixie była w powijakach - najważniejszą metodą komunikacji był UUCP (środek kopiowania plików z jednego systemu Unix do drugiego, pierwotnie działający w sieciach telefonicznych za pomocą modemów).

Zaproponowano dwa sieciowe interfejsy programowania aplikacji: gniazda Berkley oraz interfejs warstwy transportowej TLI (Interfejs warstwy transportowej).

Interfejs gniazd Berkley został opracowany na Uniwersytecie Berkeley i wykorzystywał opracowany tam stos protokołów TCP/IP. TLI zostało stworzone przez AT&T zgodnie z definicją warstwy transportowej modelu OSI i po raz pierwszy pojawiło się w wersji System V 3. Chociaż ta wersja zawierała TLI i strumienie, pierwotnie nie implementowała protokołu TCP/IP ani innych protokołów sieciowych, ale takie implementacje zostały dostarczone przez osoby trzecie.

Implementacja TCP/IP została oficjalnie i definitywnie włączona do podstawowej dystrybucji Systemu V w wersji 4. To, wraz z innymi względami (głównie marketingowymi), spowodowało ostateczne rozgraniczenie między dwiema gałęziami Unixa - BSD (University of Berkeley) i System V (wersja komercyjna firmy AT&T). Następnie wiele firm, posiadających licencję System V od AT&T, opracowało własne komercyjne wersje Unixa, takie jak AIX, CLIX, HP-UX, IRIX, Solaris.

Nowoczesne implementacje Unixa generalnie nie są czystymi systemami V lub BSD. Wdrażają funkcje zarówno z Systemu V, jak i BSD.

Darmowe systemy operacyjne typu Unix

W tej chwili GNU/Linux i członkowie rodziny BSD szybko przejmują rynek od komercyjnych systemów uniksowych i jednocześnie infiltrują zarówno desktopy użytkowników końcowych, jak i systemy mobilne i wbudowane.

Systemy zastrzeżone

Od czasu podziału AT&T znak towarowy Unix i prawa do oryginalnego kodu źródłowego kilkakrotnie zmieniały właścicieli, w szczególności przez długi czas należały do ​​firmy Novell.

Wpływ Unixa na ewolucję systemów operacyjnych

Systemy uniksowe mają ogromne znaczenie historyczne, ponieważ propagowały niektóre popularne obecnie koncepcje i podejścia dotyczące systemów operacyjnych i oprogramowania. Również podczas rozwoju systemów Unix powstał język C.

Szeroko stosowany w programowaniu systemowym język C, pierwotnie stworzony do rozwoju systemu Unix, pod względem popularności przewyższył Uniksa. Język C był pierwszym "tolerancyjnym" językiem, który nie próbował narzucać programiście stylu programowania. C był pierwszym językiem wysokiego poziomu, który dawał dostęp do wszystkich funkcji procesora, takich jak referencje, tabele, przesunięcia bitowe, przyrosty itp. Z drugiej strony swoboda języka C prowadziła do błędów przepełnienia bufora w takich standardowe funkcje biblioteki C, takie jak gets i scanf. Powstało wiele niesławnych luk w zabezpieczeniach, takich jak ta wykorzystana w słynnym robaku Morris.

Pierwsi programiści Uniksa przyczynili się do wprowadzenia zasad programowania modułowego i ponownego wykorzystania do praktyki inżynierskiej.

Unix umożliwił korzystanie z protokołów TCP/IP na stosunkowo niedrogich komputerach, co doprowadziło do szybkiego rozwoju Internetu. To z kolei przyczyniło się do szybkiego odkrycia kilku głównych luk w zabezpieczeniach, architekturze i narzędziach systemowych Uniksa.

Z biegiem czasu wiodący programiści Unix opracowali kulturowe normy tworzenia oprogramowania, które stały się równie ważne jak sam Unix. ( )

Niektóre z najbardziej znanych przykładów systemów uniksopodobnych to macOS, Solaris, BSD i NeXTSTEP.

Rola społeczna w środowisku specjalistów IT i rola historyczna

Oryginalny Unix działał na dużych komputerach z wieloma użytkownikami, które oferowały również zastrzeżone systemy operacyjne producenta sprzętu, takie jak RSX-11 i jego następca VMS. Pomimo tego, że według wielu opinii [ którego?] ówczesny Unix miał wady w porównaniu z tymi systemami operacyjnymi (np. brak poważnych silników bazodanowych), był: a) tańszy, a czasem darmowy dla instytucji akademickich; b) został przeniesiony ze sprzętu na sprzęt i opracowany w przenośnym języku C, który „oddzielił” tworzenie oprogramowania od określonego sprzętu. Ponadto wrażenia użytkownika okazały się „niezwiązane” ze sprzętem i producentem - osoba, która pracowała z Unixem na VAX, z łatwością pracowała z nim na 68xxx i tak dalej.

Producenci sprzętu w tamtych czasach często podchodzili do Uniksa chłodno, uważając go za zabawkę i oferując swój autorski system operacyjny do poważnej pracy - przede wszystkim DBMS i oparte na nich aplikacje biznesowe w komercyjnych strukturach. Znane są komentarze na ten temat z DEC dotyczące jego VMS. Korporacje tego słuchały, ale nie środowisko akademickie, które w Uniksie miało wszystko dla siebie, często nie wymagało oficjalnego wsparcia producenta, radziło sobie samodzielnie i doceniało taniość i przenośność Uniksa. Tak więc Unix był prawdopodobnie pierwszym systemem operacyjnym, który można przenieść na inny sprzęt.

Drugim ważnym wzrostem Unixa było wprowadzenie procesorów RISC około 1989 roku. Jeszcze wcześniej istniały tzw. Stacje robocze to komputery osobiste o dużej mocy przeznaczone dla jednego użytkownika, z wystarczającą ilością pamięci, twardym dyskiem i wystarczająco zaawansowanym systemem operacyjnym (wielozadaniowość, ochrona pamięci) do pracy z poważnymi aplikacjami, takimi jak CAD. Wśród producentów takich maszyn wyróżniał się Sun Microsystems, który wyrobił sobie na nich markę.

Przed pojawieniem się procesorów RISC stacje te zwykle korzystały z procesora Motorola 680x0, takiego samego jak w komputerach Apple (choć pod bardziej zaawansowanym systemem operacyjnym niż Apple). Około 1989 roku na rynku pojawiły się komercyjne implementacje procesorów o architekturze RISC. Logiczną decyzją wielu firm (Sun i innych) było przeniesienie Unixa na te architektury, co natychmiast doprowadziło do przeniesienia całego ekosystemu oprogramowania uniksowego.

Zastrzeżone poważne systemy operacyjne, takie jak VMS, od tego momentu zaczęły swój upadek (nawet jeśli można było przenieść sam system operacyjny na RISC, wszystko było znacznie bardziej skomplikowane z aplikacjami dla niego, które w tych ekosystemach często były rozwijane w asemblerze lub w zastrzeżonych językach, takich jak BLISS), a Unix stał się systemem operacyjnym dla najpotężniejszych komputerów na świecie.

Jednak mniej więcej w tym czasie ekosystem zaczął zmierzać w kierunku GUI w postaci Windows 3.0. Ogromne zalety GUI, a także np. zunifikowane wsparcie dla wszystkich typów drukarek, zostały docenione zarówno przez deweloperów, jak i użytkowników. To mocno podważyło pozycję Unixa na rynku PC - implementacje takie jak SCO i Interactive UNIX nie radziły sobie z obsługą aplikacji Windows. Jeśli chodzi o GUI dla Uniksa, o nazwie X11 (były inne implementacje, znacznie mniej popularne), nie mógł on w pełni działać na komputerze zwykłego użytkownika ze względu na wymagania dotyczące pamięci - X11 wymagał 16 MB do normalnego działania, podczas gdy Windows 3.1 z wystarczającą wydajnością uruchamiaj jednocześnie Worda i Excela w 8 MB (wtedy był to standardowy rozmiar pamięci komputera). Przy wysokich cenach pamięci był to czynnik ograniczający.

Sukces Windows dał impuls wewnętrznemu projektowi Microsoft o nazwie Windows NT, który był kompatybilny z Windows przez API, ale jednocześnie miał te same cechy architektoniczne poważnego systemu operacyjnego, co Unix - wielozadaniowość, pełna ochrona pamięci, obsługa wieloprocesorów maszyny, uprawnienia do plików i katalogi, dziennik systemowy. Windows NT wprowadził również system plików z księgowaniem NTFS, który w tym czasie przewyższał pod względem możliwości wszystkie systemy plików standardowo dostarczane z Uniksem - analogi Uniksa były tylko oddzielnymi produktami komercyjnymi od Veritas i innych.

Chociaż Windows NT nie był początkowo popularny, ze względu na wysokie wymagania pamięciowe (te same 16 MB), pozwolił Microsoftowi wejść na rynek rozwiązań serwerowych, takich jak DBMS. Wielu w tamtym czasie nie wierzyło w zdolność Microsoftu, tradycyjnie specjalizującego się w oprogramowaniu desktopowym, do bycia graczem na rynku oprogramowania dla przedsiębiorstw, który miał już wielkie nazwiska, takie jak Oracle i Sun. Do tej wątpliwości doszedł fakt, że DBMS Microsoftu - SQL Server - zaczynał jako uproszczona wersja Sybase SQL Server, licencjonowana przez Sybase i kompatybilna w 99% we wszystkich aspektach pracy z nim.

W drugiej połowie lat 90. Microsoft zaczął wprowadzać Unixa również na rynek serwerów korporacyjnych.

Połączenie powyższych czynników, a także spadek cen kontrolerów wideo 3D, które stały się domem z profesjonalnego sprzętu, w zasadzie zabiły samą koncepcję stacji roboczej na początku XXI wieku.

Ponadto systemy firmy Microsoft są łatwiejsze w zarządzaniu, zwłaszcza w typowych przypadkach użycia.

Ale w tej chwili rozpoczął się trzeci gwałtowny wzrost Unixa.

Ponadto Stallman i jego towarzysze doskonale zdawali sobie sprawę, że zastrzeżone narzędzia programistyczne nie są odpowiednie dla sukcesu oprogramowania niekorporacyjnego. Dlatego opracowali zestaw kompilatorów dla różnych języków programowania (gcc), które wraz z opracowanymi wcześniej narzędziami GNU (zastępującymi standardowe narzędzia uniksowe) stanowiły niezbędny i dość potężny pakiet oprogramowania dla programisty.

FreeBSD było wówczas poważnym konkurentem dla Linuksa, jednak „katedralny” styl zarządzania rozwojem w przeciwieństwie do „bazarowego” stylu Linuksa, a także znacznie bardziej techniczny archaizm w takich kwestiach jak obsługa maszyn wieloprocesorowych i plików wykonywalnych formaty, znacznie spowolniły rozwój FreeBSD w porównaniu do Linuksa, czyniąc ten ostatni okręt flagowym świata wolnego oprogramowania.

W przyszłości Linux osiągał coraz większe wyżyny:

• przenoszenie poważnych, zastrzeżonych produktów, takich jak Oracle;
• poważne zainteresowanie IBM tym ekosystemem jako podstawą rozwiązań wertykalnych;
• pojawienie się analogów prawie wszystkich znanych programów ze świata Windows;
• odmowa niektórych producentów sprzętu od obowiązkowej wstępnej instalacji systemu Windows;
• wydanie netbooków tylko z Linuksem;
• używać jako jądra w Androidzie.

W tej chwili Linux jest zasłużenie popularnym systemem operacyjnym dla serwerów, choć znacznie mniej popularnym na komputerach stacjonarnych.

Niektóre cechy architektoniczne systemu operacyjnego Unix

Poniżej wymieniono cechy Uniksa, które odróżniają tę rodzinę od innych systemów operacyjnych.

• System plików jest podobny do drzewa, rozróżnia wielkość liter w nazwach, bardzo słabe ograniczenia długości nazw i ścieżek.
• Nie ma obsługi plików strukturalnych przez jądro systemu operacyjnego, na poziomie wywołań systemowych plik jest strumieniem bajtów.
• Wiersz poleceń znajduje się w przestrzeni adresowej uruchamianego procesu i nie jest pobierany przez wywołanie systemowe z procesu interpretera poleceń (jak to ma miejsce na przykład w RSX-11).
• Pojęcie „zmiennych środowiskowych”.
• Uruchamianie procesów przez wywołanie fork(), czyli możliwość sklonowania bieżącego procesu z całym stanem.
• Koncepcje stdin/stdout/stderr.
• We/Wy tylko przez deskryptory plików.
• Tradycyjnie bardzo słaba obsługa asynchronicznych operacji we/wy w porównaniu z VMS i Windows NT.
• Interpreter poleceń to zwykła aplikacja, która komunikuje się z jądrem za pomocą zwykłych wywołań systemowych (w RSX-11 i VMS interpreter poleceń był wykonywany jako specjalna aplikacja, umieszczana w pamięci w specjalny sposób, za pomocą specjalnych wywołań systemowych, wywołania systemowe były obsługiwane również, umożliwiając aplikacji dostęp do poleceń interpretera nadrzędnego).
• Polecenie wiersza poleceń to nic innego jak nazwa pliku programu, nie jest wymagana żadna specjalna rejestracja i specjalny rozwój programów jako poleceń (co było powszechną praktyką w RSX-11, RT-11).
• Podejście z programem, który zadaje użytkownikowi pytania dotyczące jego trybów działania, nie jest akceptowane, zamiast tego używane są parametry wiersza poleceń (w VMS, RSX-11, RT-11 programy również działały z wierszem poleceń, ale w przypadku jego braku zostały poproszone o wprowadzenie parametrów).
• Przestrzeń nazw urządzenia na dysku w katalogu /dev, którą może zarządzać administrator, w przeciwieństwie do podejścia Windows, gdzie ta przestrzeń nazw znajduje się w pamięci jądra, a administrowanie tą przestrzenią nazw (na przykład ustawianie uprawnień) jest niezwykle trudne ze względu na brak stałego miejsca na dyskach (budowany przy każdym uruchomieniu).
• Szerokie wykorzystanie plików tekstowych do przechowywania ustawień, w przeciwieństwie do binarnej bazy danych ustawień, takiej jak w systemie Windows.
• Szerokie wykorzystanie narzędzi do przetwarzania tekstu do wykonywania codziennych zadań opartych na skryptach.
• „Promocja” systemu operacyjnego po załadowaniu jądra poprzez wykonanie skryptów za pomocą standardowego interpretera poleceń.
• Szerokie zastosowanie

Historia UNIX® zaczyna się w 1969 roku. Większość nowoczesnych systemów UNIX to komercyjne wersje oryginalnych dystrybucji UNIX. Solaris firmy Sun, HP-UX firmy Hewlett-Packard, AIX® firmy IBM to najlepsi przedstawiciele systemu UNIX, który również ma swoje unikalne elementy i własne podstawowe rozwiązania. Na przykład Sun Solaris to UNIX, ale zawiera również wiele narzędzi i rozszerzeń zaprojektowanych specjalnie dla stacji roboczych i serwerów Sun.

Linux® został opracowany w celu zapewnienia bezpłatnej alternatywy dla komercyjnych środowisk UNIX. Jego historia sięga roku 1991, a nawet 1983, kiedy powstał Projekt GNU, którego pierwotnym celem było dostarczenie darmowej alternatywy dla UNIX-a. Linux działa na wielu innych platformach, takich jak Intel®/AMD x86. Większość systemów operacyjnych UNIX może działać tylko na jednej platformie.

Linux i UNIX mają wspólne korzenie historyczne, ale są też znaczące różnice. Wiele narzędzi, narzędzi i bezpłatnych aplikacji, które są standardowo dostarczane z Linuksem, pierwotnie pomyślano jako bezpłatne alternatywy dla programów UNIX. Linux często zapewnia wsparcie dla wielu opcji i aplikacji, zapożyczając najlepsze lub najbardziej popularne funkcjonalności z UNIXa.

Jako administrator lub programista, który jest przyzwyczajony do pracy z Linuksem, system UNIX może nie wydawać się zbyt przyjazny dla użytkownika. Z drugiej strony podstawy systemu operacyjnego podobnego do UNIX (narzędzia, system plików, API) są dość ustandaryzowane. Jednak niektóre szczegóły systemów mogą mieć znaczące różnice. Różnice te zostaną omówione w dalszej części artykułu.

Różnice techniczne

Twórcy komercyjnych dystrybucji UNIX polegają na określonym zestawie klientów i platform serwerowych dla swojego systemu operacyjnego. Wiedzą, jakiego rodzaju wsparcie i optymalizację jakie aplikacje należy wdrożyć. Producenci UNIX dokładają wszelkich starań, aby zapewnić kompatybilność między różnymi wersjami. Ponadto opublikowali standardy swojego systemu operacyjnego.

Z drugiej strony, rozwój GNU/Linuksa nie jest skoncentrowany na platformie ani kliencie, a programiści GNU/Linuksa mają różne doświadczenia i perspektywy. W społeczności Linuksa nie ma ściśle standardowego zestawu narzędzi ani środowisk. Aby rozwiązać ten problem, uruchomiono projekt Linux Standards Base (LSB), ale nie okazał się on tak skuteczny, jak byśmy chcieli.

Ten brak standaryzacji prowadzi do znacznych niespójności w systemie Linux. Dla niektórych programistów możliwość korzystania z najlepszych innych systemów operacyjnych jest plusem, ale kopiowanie elementów UNIX do Linuksa nie zawsze jest wygodne, na przykład, gdy nazwy urządzeń w Linuksie można pobrać z AIX, podczas gdy narzędzia systemu plików to HP- Zorientowany na UX. Tego rodzaju niezgodności występują również między różnymi dystrybucjami Linuksa. Na przykład Gentoo i RedHat implementują różne metody aktualizacji.

Dla porównania, każda nowa wersja systemu UNIX zawiera dobrze udokumentowany opis nowych funkcji i zmian w systemie UNIX. Polecenia, narzędzia i inne elementy rzadko się zmieniają, a często te same argumenty wiersza polecenia dla aplikacji pozostają takie same w wielu wersjach tego oprogramowania. Gdy w tych elementach zachodzą znaczące zmiany, dostawcy komercyjnych systemów UNIX często dostarczają opakowanie potrzebne do zapewnienia zgodności z wcześniejszymi wersjami narzędzia.

Ta kompatybilność oznacza, że ​​narzędzia i aplikacje mogą być używane w nowych wersjach systemów operacyjnych bez sprawdzania lub zmiany ich kodu źródłowego. Dlatego migracja do nowej wersji systemu UNIX, która zwykle nie różni się zasadniczo od starej wersji, jest znacznie mniej pracochłonna dla użytkowników lub administratorów niż migracja z jednej dystrybucji Linuksa do innej.

Architektura sprzętowa

Większość komercyjnych wersji systemu UNIX jest budowana dla jednej lub niewielkiej liczby architektur sprzętowych. HP-UX działa tylko na platformach PA-RISC i Itanium, Solaris na SPARC i x86, a AIX jest przeznaczony tylko dla procesorów POWER.

Ze względu na te ograniczenia dostawcy systemu UNIX mogą stosunkowo swobodnie modyfikować swój kod dla tych architektur i korzystać z wszelkich zalet ich architektury. Ponieważ tak dobrze znają obsługiwane urządzenia, ich sterowniki działają lepiej i nie muszą radzić sobie z ograniczeniami systemu BIOS, które są specyficzne dla komputerów PC.

Z drugiej strony Linux był historycznie projektowany z myślą o maksymalnej kompatybilności. Linux jest dostępny w różnych architekturach, a liczba urządzeń I/O i innych urządzeń peryferyjnych, które mogą być używane z systemem operacyjnym, jest prawie nieograniczona. Deweloperzy nie mogą z góry wiedzieć, jaki konkretny sprzęt zostanie zainstalowany w komputerze i często nie mogą zapewnić jego efektywnego wykorzystania. Jednym z przykładów jest zarządzanie pamięcią w systemie Linux. Wcześniej Linux używał segmentowego modelu pamięci, pierwotnie zaprojektowanego dla x86. Jest teraz przystosowany do używania pamięci stronicowanej, ale nadal zachowuje pewne wymagania dotyczące pamięci segmentowej, co powoduje problemy, jeśli architektura nie obsługuje pamięci segmentowanej. Nie stanowi to problemu dla dostawców systemu UNIX. Wiedzą dokładnie, na jakim sprzęcie będzie działał ich UNIX.

Jądro

Jądro jest sercem systemu operacyjnego. Kod źródłowy jądra komercyjnych dystrybucji UNIX jest własnością ich twórców i nie jest rozpowszechniany poza firmą. Zupełnie odwrotna sytuacja z Linuksem. Procedury kompilowania i łatania jąder i sterowników są zupełnie inne. W przypadku Linuksa i innych systemów operacyjnych typu open source poprawka może zostać wydana jako kod źródłowy, a użytkownik końcowy może ją instalować, testować, a nawet modyfikować. Te poprawki zwykle nie są tak dokładnie testowane, jak poprawki od komercyjnych dostawców systemu UNIX OS. Ponieważ nie istnieje pełna lista aplikacji i środowisk, które należy przetestować, aby działały poprawnie w systemie Linux, programiści Linuksa polegają na użytkownikach końcowych i innych programistach, aby wyłapywać błędy.

Komercyjni dostawcy dystrybucji UNIX publikują jądra tylko jako kod wykonywalny. Niektóre wydania są monolityczne, podczas gdy inne umożliwiają aktualizację tylko określonego modułu jądra. W każdym razie to wydanie jest dostarczane tylko w postaci kodu wykonywalnego. Jeśli potrzebna jest aktualizacja, administrator musi poczekać, aż producent wyda poprawkę w postaci binarnej, ale może być pocieszony faktem, że producent dokładnie sprawdzi swoją poprawkę pod kątem wstecznej kompatybilności.

Wszystkie komercyjne wersje systemu UNIX ewoluowały do ​​pewnego stopnia w jądro modułowe. Sterowniki i określone funkcje systemu operacyjnego są dostępne jako oddzielne składniki i można je w razie potrzeby ładować lub usuwać z jądra. Ale otwarta modularna architektura Linuksa jest znacznie bardziej elastyczna. Jednak elastyczność i zdolność adaptacji Linuksa oznacza ciągłą zmianę. Kod źródłowy Linuksa ciągle się zmienia, a API może się zmienić pod wpływem kaprysu programisty. Kiedy moduł lub sterownik jest napisany dla komercyjnej wersji UNIX, będzie działać znacznie dłużej niż ten sam sterownik dla Linuksa.

Obsługa systemu plików

Jednym z powodów, dla których Linux stał się tak potężnym systemem operacyjnym, jest jego szeroka kompatybilność z innymi systemami operacyjnymi. Jedną z najbardziej oczywistych funkcji jest obfitość dostępnych systemów plików. Większość komercyjnych wersji systemu UNIX obsługuje dwa lub trzy typy systemów plików. Linux obsługuje jednak większość nowoczesnych systemów plików. pokazuje, które systemy plików są obsługiwane przez UNIX. Każdy z tych systemów plików można zamontować w systemie Linux, chociaż nie wszystkie z nich w pełni obsługują odczytywanie i zapisywanie danych.

Tabela 1. Systemy plików, które są standardowe dla UNIX

Większość komercyjnych wersji systemu UNIX obsługuje systemy plików z kronikowaniem. Na przykład HP-UX używa hfs jako swojego standardowego systemu plików, ale obsługuje również kronikowany system plików vxfs. Solaris obsługuje ufs i zfs. System plików z kronikowaniem jest podstawowym składnikiem każdego środowiska serwerowego przedsiębiorstwa. Wsparcie dla systemów plików z dziennikiem zostało wprowadzone pod koniec Linuksa, ale teraz jest kilka opcji, od klonów komercyjnych systemów plików (xfs, jfs) do systemów plików specyficznych dla Linuksa (ext3, reiserfs).

Inne funkcje systemu plików obejmują obsługę limitów, listy kontroli dostępu do plików, tworzenie kopii lustrzanych, migawki systemu i zmianę rozmiaru. Są one obsługiwane w takiej czy innej formie przez systemy plików Linuksa. Większość z tych funkcji nie jest standardowa w systemie Linux. Niektóre funkcje mogą działać w jednym systemie plików, podczas gdy inne będą wymagać innego systemu plików. Niektóre z tych funkcji są po prostu niedostępne w niektórych systemach plików Linux, podczas gdy inne wymagają dodatkowej instalacji narzędzi, takich jak określona wersja LVM lub obsługa macierzy dyskowych (pakiet raid oprogramowania). W przeszłości zgodność między interfejsami programistycznymi a standardowymi narzędziami była trudna do osiągnięcia w systemie Linux, dlatego wiele systemów plików implementuje te funkcje na różne sposoby.

Ponieważ komercyjne systemy UNIX obsługują ograniczoną liczbę systemów plików, ich narzędzia i techniki pracy z nimi są bardziej ustandaryzowane. Na przykład, ponieważ Irix obsługiwany był tylko jeden główny system plików, istniał tylko jeden sposób ustawiania list kontroli dostępu. Jest to znacznie wygodniejsze dla użytkownika końcowego i dalszego wsparcia tego systemu operacyjnego.

Dostępność aplikacji

Większość podstawowych aplikacji jest taka sama w systemach UNIX i Linux. Na przykład polecenia cp , ls , vi i cc są dostępne w systemach UNIX i Linux i są bardzo podobne, jeśli nie całkowicie identyczne. Wersje tych narzędzi dla systemu Linux są oparte na wersjach GNU tych narzędzi, podczas gdy wersje tych narzędzi dla systemu UNIX są oparte na tradycyjnych narzędziach UNIX. Te narzędzia UNIX mają długą historię i rzadko się zmieniają.

Ale to nie znaczy, że komercyjne wersje UNIXa nie mogą być używane z narzędziami GNU. W rzeczywistości wielu komercyjnych dostawców UNIX OS zawiera wiele narzędzi GNU w swoich dystrybucjach lub oferuje je jako bezpłatne dodatki. Narzędzia GNU to nie tylko standardowe narzędzia. Niektóre z tych darmowych narzędzi nie mają komercyjnych odpowiedników (emacs lub Perl). Większość producentów wstępnie instaluje te programy i są one albo automatycznie instalowane z systemem, albo dostępne jako funkcja opcjonalna.

Darmowe i otwarte aplikacje są prawie zawsze wbudowane we wszystkie dystrybucje Linuksa. Istnieje duża ilość wolnego oprogramowania dostępnego dla systemu Linux, a wiele z tych aplikacji zostało przeniesionych do komercyjnych wersji systemu operacyjnego UNIX.

Aplikacje komercyjne i/lub zamknięte (CAD, programy finansowe, edytor graficzny) może nie mieć odpowiedników dla systemu Linux. Chociaż niektórzy dostawcy wypuszczają wersje swoich aplikacji dla Linuksa, większość dostawców nie spieszy się z tym, dopóki popularność Linuksa wśród użytkowników nie wzrośnie.

Z drugiej strony komercyjne wersje systemu UNIX od dawna wspierały dużą liczbę aplikacji na poziomie korporacyjnym, takich jak Oracle czy SAP. Linux mocno traci z powodu trudności związanych z certyfikacją dużych aplikacji, podczas gdy komercyjne wersje UNIXa nie zmieniają się zbytnio od wydania do wydania. Linux może wiele zmienić, nie tylko z każdą nową dystrybucją, ale czasami między wydaniami tej samej dystrybucji. Dlatego producentowi oprogramowania bardzo trudno jest dokładnie zrozumieć, w jakim środowisku będzie używana jego aplikacja.

Administracja systemu

Chociaż niektóre dystrybucje Linuksa zawierają standardowy zestaw narzędzi administracyjnych systemu, takich jak YaST firmy SUSE, nie ma wspólnego standardu dla narzędzi administracyjnych systemu Linux.Pliki tekstowe i narzędzia wiersza poleceń są dostępne, ale czasami ich użycie może być niewygodne.Każda wersja komercyjna UNIX ma własny interfejs zarządzania systemem. Za pomocą tego interfejsu można zarządzać elementami systemu i modyfikować je. Poniżej przedstawiono przykład Menedżera administracji systemu dla HP-UX.

Ten SAM zawiera następujące moduły:

• Użytkownicy lub grupy do zarządzania.
• Opcje jądra, które można zmienić.
• Konfiguracja sieci.
• Konfigurowanie i inicjowanie dysków.
• Konfiguracja serwera X.

Jakość tego pakietu narzędziowego jest doskonała, a pakiet narzędziowy dobrze współpracuje z plikami tekstowymi. Nie ma odpowiednika tego narzędzia dla Linuksa. Nawet YaST w SUSE nie ma tej samej funkcjonalności.

Innym aspektem w systemach UNIX i Linux, który wydaje się zmieniać w prawie każdej wersji systemu operacyjnego, jest lokalizacja skryptów inicjujących system. Na szczęście /sbin/init i /etc/inittab są standardowymi katalogami. Ale skrypty startowe systemu znajdują się w różnych katalogach. pokazuje lokalizacje, w których przechowywane są skrypty inicjalizacji systemu dla różnych dystrybucji UNIX i Linux.

Tabela 2. Lokalizacja skryptów inicjujących system dla różnych wersji UNIX

HP-UX	/sbin/init.d
AIX	/etc/rc.d/init.d
Irix	/etc/init.d
Solaris	/etc/init.d
czerwony kapelusz	/etc/rc.d/init.d
SUSE	/etc/rc.d/init.d
Debiana	/etc/init.d
Slackware	/etc/rc.d

Ze względu na dużą liczbę dystrybucji Linuksa i prawie nieskończoną liczbę dostępnych aplikacji (biorąc pod uwagę, że istnieje również wiele wersji tej aplikacji) dla tego systemu operacyjnego, zarządzanie programami w Linuksie staje się trudnym zadaniem. Wybór odpowiedniego narzędzia zależy od dystrybucji, z którą pracujesz. Dalsze niedogodności wynikają z faktu, że niektóre dystrybucje używają formatu pliku Redhat Package Manager (RPM), podczas gdy ich programy są niekompatybilne. Ten podział prowadzi do ogromnej liczby opcji pracy z pakietami i nie zawsze jest jasne, który system jest używany w konkretnym środowisku.

Z drugiej strony komercyjne dystrybucje systemu UNIX zawierają standardowe menedżery pakietów. Mimo że istnieją różne wersje aplikacji i określone formaty dla różnych wersji systemu UNIX, środowisko zarządzania aplikacjami jest takie samo. Na przykład Solaris używa tych samych narzędzi do zarządzania pakietami aplikacji od samego początku. I najprawdopodobniej sposoby identyfikacji, dodawania lub usuwania pakietów oprogramowania w Solarisie pozostaną niezmienione.

Sprzedawcy komercyjnych dystrybucji UNIX dostarczają również sprzęt, na którym ich system operacyjny został zaprojektowany, dzięki czemu mogą wprowadzać nowe urządzenia do swojego systemu operacyjnego, co jest znacznie trudniejsze w przypadku Linuksa. Na przykład w najnowsze wersje Linux próbował zaimplementować obsługę komponentów z możliwością wymiany podczas pracy (z różnym powodzeniem). Komercyjne wersje systemu UNIX mają tę możliwość od wielu lat. Ponadto w komercyjnych wersjach systemu UNIX monitorowanie sprzętu jest lepsze niż w systemie Linux. Producenci mogą pisać sterowniki i umieszczać je w swoich systemach operacyjnych, które będą monitorować stan systemu, na przykład liczbę błędów pamięci ECC, ustawienia zasilania lub dowolny inny komponent sprzętowy. Tego rodzaju wsparcie dla Linuksa jest oczekiwane dopiero w odległej przyszłości.

Sprzęt dla komercyjnych systemów UNIX ma również bardziej zaawansowane opcje rozruchu. Przed uruchomieniem systemu operacyjnego istnieje wiele opcji dostosowywania sposobu uruchamiania, sprawdzania kondycji systemu lub dostosowywania ustawień sprzętu. BIOS standardowego komputera ma niewiele, jeśli w ogóle, z tych opcji.

Wspierać się

Jedną z najważniejszych różnic między Linuksem a UNIXem jest koszt. Sprzedawcy komercyjnych systemów UNIX zapłacili wysoką cenę za swój UNIX, mimo że można go używać tylko z ich platformami sprzętowymi. Z drugiej strony dystrybucje Linuksa są stosunkowo niedrogie, jeśli w ogóle nie są darmowe.

Kupując komercyjną wersję systemu UNIX, dostawcy zazwyczaj zapewniają pomoc techniczną. Większość użytkowników systemu Linux nie jest obsługiwana przez producenta systemu operacyjnego. Mogą uzyskać wsparcie tylko za pośrednictwem poczty e-mail, forów i różnych społeczności użytkowników Linuksa. Jednak te grupy nie są przeznaczone tylko dla użytkowników Linuksa. Wielu administratorów komercyjnych systemów operacyjnych z rodziny UNIX uczestniczy w tych otwartych grupach wsparcia, aby móc zarówno świadczyć pomoc, jak i w razie potrzeby z niej korzystać. Dla wielu osób takie grupy samopomocy są nawet bardziej przydatne niż system wsparcia oferowany przez producenta systemu operacyjnego.

Wniosek

Podstawy systemów UNIX i Linux są bardzo podobne. Dla użytkownika lub administratora systemu przejście z Linuksa na UNIX spowoduje pewne niedogodności w pracy, ale generalnie przejście będzie bezbolesne. Nawet jeśli systemy plików i jądra są różne i przyzwyczajenie się do nich zajmuje trochę czasu, narzędzia i interfejsy API pozostają takie same. W większości różnice te nie są bardziej znaczące niż różnice między głównymi wersjami systemu UNIX. Wszystkie gałęzie UNIX i Linux stopniowo ewoluują i będą się nieznacznie różnić od siebie, ale ze względu na dojrzałość koncepcji UNIX, podstawy systemu operacyjnego nie zmienią się zbytnio.

Wstęp

Co to jest Unix?

Skąd wziąć darmowy Unix?

Jakie są główne różnice między Unixem a innymi systemami operacyjnymi?

Dlaczego Unix?

Podstawowe koncepcje uniksowe

System plików

tłumacz poleceń

Podręczniki - człowiek

Wstęp

Pisanie o systemie operacyjnym Unix jest niezwykle trudne. Po pierwsze dlatego, że o tym systemie napisano wiele. Po drugie dlatego, że idee i decyzje Uniksa miały i mają ogromny wpływ na rozwój wszystkich nowoczesnych systemów operacyjnych, a wiele z tych pomysłów zostało już opisanych w tej książce. Po trzecie dlatego, że Unix to nie jeden system operacyjny, ale cała rodzina systemów i nie zawsze można „śledzić” ich wzajemne relacje, a opisanie wszystkich systemów operacyjnych wchodzących w skład tej rodziny jest po prostu niemożliwe . Jednakże, nie twierdząc, że jest to w jakikolwiek sposób wyczerpujące, postaramy się przedstawić pobieżny przegląd „świata Uniksa” w tych jego obszarach, które wydają się nam interesujące dla celów naszego samouczka.

Narodziny systemu operacyjnego Unix sięgają końca lat 60-tych, a ta historia nabrała już „legend”, które czasami na różne sposoby opowiadają o szczegółach tego wydarzenia. System operacyjny Unix narodził się w centrum badawczym Bell Telephone Laboratories (Bell Labs), które jest częścią korporacji AT&T. Początkowo ten inicjatywny projekt dla komputera PDP-7 (później - dla PDP-11) był albo systemem plików, albo grą komputerową, albo systemem przygotowania tekstu, albo jednym i drugim. Ważne jest jednak, że od samego początku projekt, który ostatecznie przekształcił się w system operacyjny, był pomyślany jako środowisko oprogramowania do wspólnego użytku. Autorem pierwszej wersji Uniksa jest Ken Thompson, jednak w dyskusji nad projektem, a następnie w jego realizacji brał udział spory zespół pracowników (D. Ritchie, B. Kernigan, R. Pike i inni). . Naszym zdaniem kilka szczęśliwych okoliczności narodzin Unixa zadecydowało o powodzeniu tego systemu na wiele lat.

Dla większości osób w zespole, w którym narodził się Unix, ten system operacyjny był „trzecim systemem”. Istnieje opinia (patrz na przykład), że programista systemowy osiąga wysokie kwalifikacje dopiero po ukończeniu trzeciego projektu: pierwszy projekt jest nadal „studentem”, drugi programista stara się uwzględnić wszystko, co nie wyszło w pierwszym, oraz w rezultacie okazuje się to zbyt uciążliwe, a dopiero w trzecim osiąga się niezbędną równowagę pragnień i możliwości. Wiadomo, że przed narodzinami Unixa zespół Bell Labs uczestniczył (wraz z kilkoma innymi firmami) w rozwoju systemu MULTICS OS. Finalny produkt MULTICS (Bell Labs nie brał udziału w ostatnich etapach rozwoju) nosi wszystkie cechy „drugiego systemu” i nie jest powszechnie stosowany. Należy jednak zauważyć, że w tym projekcie narodziło się wiele fundamentalnie ważnych pomysłów i decyzji, a niektóre koncepcje, które wielu uważa za narodzone w systemie Unix, w rzeczywistości pochodzą z projektu MULTICS.

System operacyjny Unix był systemem stworzonym „dla mnie i dla moich przyjaciół”. Unix nie był nastawiony na zdobywanie rynku i konkurowanie z jakimkolwiek produktem. Twórcy systemu operacyjnego Unix sami byli jego użytkownikami i sami oceniali przydatność systemu do swoich potrzeb. Bez presji warunków rynkowych taka ocena mogłaby być niezwykle obiektywna.

Unix był systemem stworzonym przez programistów dla programistów. Decydowało to o elegancji i harmonii pojęciowej systemu - z jednej strony, az drugiej - potrzeba zrozumienia systemu dla użytkownika Uniksa i poczucie odpowiedzialności zawodowej programisty tworzącego oprogramowanie dla Uniksa. I żadne kolejne próby stworzenia "Unix for Dummies" nie były w stanie pozbyć się tej cechy z Unix OS.

W latach 1972-73. Ken Thompson i Dennis Ritchie napisali nową wersję Uniksa. Specjalnie w tym celu D. Ritchie stworzył język programowania C, który nie jest już potrzebny. Ponad 90% kodu Uniksa jest napisane w tym języku, a język stał się integralną częścią systemu operacyjnego. Fakt, że główna część systemu operacyjnego jest napisana w języku wysokiego poziomu, umożliwia ponowną kompilację do kodów dowolnej platformy sprzętowej i jest okolicznością, która zadecydowała o powszechnym użyciu Unixa.

Na początku istnienia Unixa amerykańskie przepisy antymonopolowe uniemożliwiały AT&T wejście na rynek oprogramowania. Dlatego system operacyjny Unix był niekomercyjny i swobodnie rozpowszechniany, głównie na uniwersytetach. Tam jego rozwój był kontynuowany, a najaktywniej był prowadzony na Uniwersytecie Kalifornijskim w Berkeley. Na tej uczelni powstała grupa Berkeley Software Distribution, która zajmowała się rozwojem osobnej gałęzi systemu operacyjnego - BSD Unix. W kolejnych latach główny nurt Unix i BSD Unix ewoluowały równolegle, wielokrotnie się wzajemnie wzbogacając.

W miarę rozpowszechniania się systemu operacyjnego Unix coraz bardziej interesowały się nim firmy komercyjne, które zaczęły wydawać własne komercyjne wersje tego systemu operacyjnego. Z czasem „główny” oddział Unixa od AT&T stał się komercyjny, a do jego promocji utworzono filię Unix System Laboratory. Gałąź BSD Unix rozwidlała się z kolei na komercyjne BSD i wolne BSD. Różne komercyjne i darmowe systemy uniksopodobne zostały zbudowane na jądrze AT&T Unix, ale zawierają funkcje zapożyczone z BSD Unix, a także funkcje oryginalne. Pomimo wspólnego źródła, różnice między członkami rodziny uniksowej nagromadziły się i ostatecznie sprawiły, że przenoszenie aplikacji z jednego uniksopodobnego systemu operacyjnego na inny stało się niezwykle trudne. Z inicjatywy użytkowników Unixa nastąpił ruch w kierunku standaryzacji Unix API. Ruch ten był wspierany przez Międzynarodową Organizację Normalizacyjną ISO i doprowadził do powstania standardu POSIX (Portable Operation System Interface eXecution), który wciąż jest rozwijany i jest najbardziej autorytatywnym standardem dla systemu operacyjnego. Jednak uczynienie specyfikacji POSIX oficjalnym standardem jest procesem powolnym i nie spełnia potrzeb dostawców oprogramowania, co doprowadziło do pojawienia się alternatywnych standardów branżowych.

Wraz z przejściem AT&T Unix do Nowell, nazwa tego systemu operacyjnego została zmieniona na Unixware, a prawa do znaku towarowego Unix zostały przeniesione na konsorcjum X/Open. To konsorcjum (obecnie Open Group) opracowało własną (szerszą niż POSIX) specyfikację systemu, znaną jako Single Unix Specification. Niedawno ukazała się druga edycja tego standardu, znacznie lepiej dostosowana do POSIX.

W końcu, kilka firm produkujących własne wersje Uniksa utworzyło konsorcjum Open Software Foundation (OSF), które wydało własną wersję Unixa, OSF/1, opartą na mikrojądrze Mach. OSF opublikowała również specyfikacje systemu OSF/1, które posłużyły jako podstawa dla firm członkowskich OSF do wydania własnych systemów Unix. Systemy te obejmują SunOS firmy Sun Microsystems, AIX firmy IBM, HP/UX firmy Hewlett-Packard, DIGITAL UNIX firmy Compaq i inne.

Początkowo systemy uniksowe tych firm opierały się głównie na BSD Unix, ale obecnie większość nowoczesnych przemysłowych systemów Unix jest budowana przy użyciu (na licencji) jądra AT&T Unix System V Release 4 (S5R4), chociaż dziedziczą one również pewne właściwości BSD Unix . Nie bierzemy odpowiedzialności za porównywanie komercyjnych systemów uniksowych, ponieważ tego rodzaju porównania, które pojawiają się okresowo w druku często dają zupełnie odwrotne wyniki.

Nowell sprzedał Unix firmie Santa Crouse Operations, która wyprodukowała swój własny produkt uniksowy, SCO Open Server. SCO Open Server był oparty na wcześniejszej wersji jądra (System V Release 3), ale był znakomicie debugowany i bardzo stabilny. Firma Santa Crouse Operations zintegrowała swój produkt z AT&T Unix i wydała Open Unix 8, ale potem sprzedała Unix firmie Caldera, dzisiejszemu właścicielowi „klasycznego” Unixa (koniec 2001 roku).

Sun Microsystems rozpoczął wprowadzanie do świata Uniksa od SunOS, opartego na jądrze BSD. Jednak później zastąpił go systemem Solaris opartym na S5R4. Obecnie dystrybuowana jest wersja 8 tego systemu operacyjnego (istnieje również wersja v.9-beta). Solaris działa na platformie SPARC (procesory RISC produkowane zgodnie ze specyfikacją Sun) oraz Intel-Pentium.

Hewlett-Packard oferuje system operacyjny HP-UX. v.11 na platformie PA-RISC. HP-UX jest oparty na S5R4, ale zawiera wiele funkcji, które zdradzają jego początki z BSD Unix. Oczywiście HP-UX będzie również dostępny na platformie Intel-Itanium.

IBM wychodzi z systemem operacyjnym AIX, najnowsza wersja do tej pory to 5L (będzie to omówione później). IBM nie ogłosił "rodowód" AIX, jest to głównie oryginalny rozwój, ale pierwsze wersje nosiły ślady pochodzenia z FreeBSD Unix. Teraz jednak AIX bardziej przypomina S5R4. AIX był pierwotnie dostępny na platformie Intel-Pentium, ale później (zgodnie z ogólną polityką IBM) nie był już obsługiwany na tej platformie. AIX działa obecnie na serwerach IBM RS/6000 i innych platformach obliczeniowych opartych na PowerPC (w tym na superkomputerach IBM).

DIGITAL UNIX firmy DEC był jedyną komercyjną implementacją OSF/1. DIGITAL UNIX OS działał na serwerach Alpha RISC firmy DEC. Kiedy firma DEC została przejęta przez Compaq w 1998 roku, Compaq nabył zarówno serwery Alpha, jak i DIGITAL UNIX. Compaq zamierza przywrócić swoją obecność na rynku serwerów Alpha i w związku z tym intensywnie rozwija dla nich system operacyjny. Obecna nazwa tego systemu operacyjnego to Tru64 Unix (aktualna wersja to 5.1A), nadal opiera się na jądrze OSF/1 i ma wiele funkcji BSD Unix.

Chociaż większość komercyjnych systemów Unix opiera się na jednym jądrze i jest zgodna z wymaganiami POSIX, każdy ma swój własny dialekt API, a różnice między dialektami kumulują się. Prowadzi to do tego, że przenoszenie aplikacji przemysłowych z jednego systemu uniksowego do drugiego jest trudne i wymaga przynajmniej rekompilacji, a często także korekty kodu źródłowego. Próba przezwyciężenia „zamieszania” i stworzenia jednego systemu operacyjnego Unix dla wszystkich została podjęta w 1998 roku przez sojusz SCO, IBM i Sequent. Firmy te połączyły się w projekcie Monterey, aby stworzyć jeden system operacyjny oparty na Unixware, należącym wówczas do SCO, IBM AIX i DYNIX OS firmy Sequent. (Sequent jest liderem w produkcji komputerów NUMA - asymetryczny wieloprocesor - a DYNIX to Unix dla takich komputerów). System operacyjny Monterey miał działać na 32-bitowej platformie Intel-Pentium, 64-bitowej platformie PowerPC oraz nowej 64-bitowej platformie Intel-Itanium. Poparcie dla projektu zadeklarowali niemal wszyscy liderzy branży hardware i middleware. Nawet firmy, które mają własne klony Uniksa (z wyjątkiem Sun Microsystems) ogłosiły, że będą obsługiwać Monterey tylko na platformach Intela. Praca nad projektem przebiegała pomyślnie. Monterey OS był jednym z pierwszych, który udowodnił swoją wydajność na Intel-Itanium (wraz z Windows NT i Linux) i jedynym, który nie emulował 32-bitowej architektury Intel-Pentium. Jednak w końcowej fazie projektu wydarzyło się fatalne wydarzenie: SCO sprzedało swój oddział Unix. Jeszcze wcześniej firma Sequent stała się częścią IBM. „Następcą” wszystkich funkcji Monterey OS jest IBM AIX v.5L OS. Jednak nie do końca. Platforma Intel-Pentium nie jest strategicznym celem dla IBM, a AIX nie jest dostępny na tej platformie. A ponieważ inni liderzy w branży komputerowej nie podzielają (lub nie do końca podzielają) stanowiska IBM, idea wspólnego systemu operacyjnego Unix nigdy nie doszła do skutku.

Jeśli niedawno zacząłeś uczyć się Linuksa i czuć się komfortowo w tym ogromnym wszechświecie, prawdopodobnie często spotykałeś się z terminem Unix. Brzmi bardzo podobnie do Linuksa, ale co to znaczy? Prawdopodobnie zastanawiasz się, jaka jest różnica między Unixem a Linuksem. Odpowiedź na to pytanie zależy od tego, co rozumiesz przez te słowa. W końcu każdy z nich można interpretować na różne sposoby. W tym artykule przyjrzymy się uproszczonej historii Linuksa i Uniksa, aby pomóc Ci zrozumieć, czym one są i jak są ze sobą powiązane. Jak zawsze możesz zadawać pytania lub dodawać więcej informacji w komentarzach.

Unix rozpoczął swoją historię na przełomie lat 60. i 70. w AT&T Bell Labs w Stanach Zjednoczonych. Wraz z MIT i General Electric Bell Labs rozpoczął opracowywanie nowego systemu operacyjnego. Niektórzy badacze byli niezadowoleni z rozwoju tego systemu operacyjnego. Odeszli od pracy nad głównym projektem i zaczęli rozwijać własny system operacyjny. W 1970 roku system ten nazywał się Unix, a dwa lata później został całkowicie przepisany w języku programowania C.

Umożliwiło to dystrybucję i przeniesienie Uniksa do różne urządzenia i platformy komputerowe.

Wraz z dalszym rozwojem Unixa AT&T zaczęło udzielać licencji na jego użytkowanie uniwersyteckie, a także do celów komercyjnych. Oznaczało to, że nie każdy mógł, tak jak teraz, swobodnie zmieniać i rozpowszechniać kod systemu operacyjnego Unix. Wkrótce zaczęło pojawiać się wiele wydań i wariantów systemu operacyjnego Unix, przeznaczonych do rozwiązywania różnych problemów. Najbardziej znanym z nich było BSD.

Linux jest podobny do Unixa pod względem funkcjonalności i funkcji, ale nie bazuje na kodzie. Ten system operacyjny został złożony z dwóch projektów. Pierwszym z nich jest projekt GNU opracowany przez Richarda Stallmana w 1983 roku, drugim jest jądro Linuksa napisane przez Linusa Torvaldsa w 1991 roku.

Celem Projektu GNU było stworzenie systemu podobnego do Uniksa, ale niezależnego od niego. Innymi słowy, system operacyjny nie zawierający kodu uniksowego, który można swobodnie rozpowszechniać i modyfikować bez ograniczeń, jak wolne oprogramowanie. Ponieważ wolne jądro Linuksa nie mogło działać samodzielnie, projekt GNU połączył się z jądrem Linuksa i narodził się system operacyjny Linux.

Linux został zaprojektowany pod wpływem systemu Minix, potomka Unixa, ale cały kod został napisany od zera. W przeciwieństwie do Uniksa, który był używany na serwerach i dużych komputerach mainframe różnych przedsiębiorstw, Linux został zaprojektowany do użytku na komputer domowy z prostszym sprzętem.

Obecnie Linux działa na większej liczbie platform niż jakikolwiek inny system operacyjny, w tym na serwerach, systemach wbudowanych, mikrokomputerach, modemach, a nawet telefonach komórkowych. Teraz bardziej szczegółowo rozważymy różnicę między linuxem a unixem.

Co to jest Unix

Termin Unix może odnosić się do takich pojęć:

• Oryginalny system operacyjny opracowany przez AT&T Bell Labs, na podstawie którego powstają inne systemy operacyjne.
• Znak towarowy, pisany wielkimi literami. UNIX jest własnością The Open Group, która opracowała specyfikację Single UNIX, zestaw standardów dla systemów operacyjnych. Tylko te systemy, które są zgodne ze standardami, mogą zgodnie z prawem nazywać się UNIX. Certyfikacja nie jest bezpłatna i wymaga od deweloperów zapłaty za używanie tego znaku towarowego.
• Wszystkie systemy operacyjne są zarejestrowane pod nazwą Unix. Ponieważ spełniają powyższe normy. Są to AIX, A/UX, HP-UX, Inspur K-UX, Reliant UNIX, Solaris, IRIX, Tru64, UnixWare, z/OS i OS X - tak, nawet te działające na komputerach Apple.

Czym jest Linux

Termin Linux odnosi się tylko do jądra. System operacyjny nie byłby kompletny bez środowiska graficznego i aplikacji. Ponieważ większość aplikacji została opracowana i jest obecnie rozwijana w ramach projektu GNU, pełna nazwa systemu operacyjnego to GNU/Linux.

Wiele osób używa teraz terminu Linux w odniesieniu do wszystkich dystrybucji opartych na jądrze Linuksa. W tej chwili najnowsza wersja jądra Linux to 4.4, wersja 4.5 jest w fazie rozwoju. Zmiana numeracji wydań jądra z 3.x na 4.x miała miejsce nie tak dawno temu.

Linux to system operacyjny podobny do Uniksa, który zachowuje się jak Unix, ale nie zawiera swojego kodu. Systemy operacyjne typu Unix są często określane jako Un*x, *NIX i *N?X, a nawet Unixoids. Linux nie ma certyfikatu Unix, a GNU oznacza GNU, a nie Unix, więc Mac OS X jest pod tym względem bardziej Uniksem niż Linuxem. Niemniej jednak jądro Linuksa i system operacyjny GNU Linux są bardzo podobne pod względem funkcjonalności do Uniksa, implementując większość zasad filozofii Uniksa. Jest to kod czytelny dla człowieka, przechowujący konfigurację systemu w oddzielnych plikach tekstowych i używający małych narzędzi wiersza poleceń, powłoki graficznej i menedżera sesji.

Należy zauważyć, że nie wszystkie systemy uniksopodobne otrzymały certyfikat UNIX. W pewnym kontekście wszystkie systemy operacyjne oparte na UNIX lub jego ideach nazywane są UNIX-like, niezależnie od tego, czy mają certyfikat UNIX, czy nie. Ponadto mogą być komercyjne i bezpłatne.

Mam nadzieję, że teraz stało się bardziej jasne, czym Unix różni się od Linuksa. Ale pójdźmy jeszcze dalej i podsumujmy.

Główne różnice

• Linux jest darmowym i otwartym systemem operacyjnym, ale oryginalny Unix nie jest, z wyjątkiem niektórych jego pochodnych.
• Linux jest klonem oryginalnego Uniksa, ale nie zawiera jego kodu.
• Główna różnica między Uniksem a Linuksem polega na tym, że Linux jest tylko jądrem, podczas gdy Unix był i jest pełnoprawnym systemem operacyjnym.
• Linux został zaprojektowany dla komputerów osobistych. A Unix skupia się przede wszystkim na dużych stacjach roboczych i serwerach.
• Dziś Linux obsługuje więcej platform niż Unix.
• Linux obsługuje więcej typów systemów plików niż Unix.

Jak widać, zamieszanie zwykle wynika z tego, że linux vs unix może oznaczać zupełnie inne rzeczy. Bez względu na znaczenie, faktem jest, że najpierw pojawił się Unix, a później Linux. Linux narodził się z pragnienia wolności oprogramowania i przenośności, zainspirowanego podejściem Uniksa. Można śmiało powiedzieć, że wszyscy jesteśmy dłużnikami ruchu wolnego oprogramowania, ponieważ bez niego świat byłby o wiele gorszym miejscem.

MINISTERSTWO EDUKACJI I NAUKI ROSYJSKIEJ

FEDERACJA

FEDERALNA AGENCJA EDUKACJI

PAŃSTWOWA INSTYTUCJA EDUKACYJNA

WYŻSZE WYKSZTAŁCENIE ZAWODOWE

Państwowy Uniwersytet Radiotechniczny Taganrog

Dyscyplina „Informatyka”

"System operacyjny UNIX"

Wypełnił: Orda-Zhigulina D.V., gr. E-25

Sprawdzone: Vishnevetsky V.Yu.

Taganrog 2006

Wstęp

Co to jest Unix 3?

Skąd wziąć darmowy Unix 7

Główną częścią. (Opis Uniksa)

1. Podstawowe pojęcia Unixa 8

2. System plików 9

2.1 Typy plików 9

3. Tłumacz poleceń 11

4. Jądro UNIX 12

4.1 Ogólna organizacja tradycyjnego jądra UNIX 13

4.2 Główne funkcje jądra 14

4.3 Zasady interakcji z rdzeniem 15

4.4 Zasady obsługi przerwań 17

5. Sterowanie we/wy 18

5.1 Zasady buforowania wejść/wyjść systemu 19

5. 2 wywołania systemowe dla sterowania we/wy 21

6. Interfejsy i punkty wejściowe sterowników 23

6.1 Zablokuj sterowniki 23

6.2 Sterowniki znaków 24

6. 3 sterowniki strumieniowe 25

7. Polecenia i narzędzia 25

7. 1 Organizacja zespołu w systemie UNIX OS 26

7.2 Przekierowanie we/wy i orurowanie 26

7. 3 Wbudowane, biblioteka i polecenia użytkownika 26

7.4 Programowanie w języku poleceń 27

8. Narzędzia GUI 27

8.1 Identyfikatory użytkowników i grupy użytkowników 30

8.2 Ochrona plików 32

8.3 Obiecujące systemy operacyjne obsługujące środowisko UNIX OS 33

Wniosek

Główne różnice między Unixem a innymi OS 36

Zastosowania Uniksa 37

Wstęp

Co to jest Unix

Termin Unix i nie do końca równoważny UNIX są używane w różnych znaczeniach. Zacznijmy od drugiego z terminów, jako prostszego. Krótko mówiąc, UNIX (w tej formie) jest zastrzeżonym znakiem towarowym pierwotnie należącym do AT&T Corporation, który przez lata zmieniał właściciela i jest obecnie własnością organizacji o nazwie Open Group. Prawo do używania nazwy UNIX uzyskuje się poprzez swego rodzaju „sprawdzenie pod kątem wszy” – przejście testów zgodności ze specyfikacjami jakiegoś referencyjnego systemu operacyjnego (Single Unix Standard – co w tym przypadku można przetłumaczyć jako Single Standard on Unix). Procedura ta jest nie tylko skomplikowana, ale też bardzo kosztowna, dlatego też poddało się jej tylko kilka systemów operacyjnych z obecnych, a wszystkie są własnościowe, czyli są własnością określonych korporacji.

Wśród korporacji, które zasłużyły na prawo do nazwy UNIX, potem deweloperzy/testerzy i krew (a dokładniej dolara) właścicieli, możemy wymienić:

Sun z systemem SunOS (lepiej znanym światu jako Solaris);

IBM, który opracował system AIX;

Hewlett-Packard jest właścicielem systemu HP-UX;

IRIX to system operacyjny firmy SGI.

Ponadto właściwa nazwa UNIX dotyczy systemów:

True64 Unix, opracowany przez firmę DEC, którego likwidacja przeszła na Compaqa, a teraz wraz z tym ostatnim stał się własnością tego samego Hewlett-Packarda;

UnixWare jest własnością SCO (produkt fuzji Caldera i Santa Cruz Operation).

Jako prawnie zastrzeżone, wszystkie te systemy są sprzedawane za duże pieniądze (nawet jak na amerykańskie standardy). Nie jest to jednak główna przeszkoda w rozprzestrzenianiu się samego UNIXa, gdyż ich wspólną cechą jest powiązanie z określonymi platformami sprzętowymi: AIX działa na serwerach IBM i stacjach roboczych z procesorami Power, HP-UX na własnym HP-PA (Precision Architecture) maszyny , IRIX - na stacjach graficznych firmy SGI, niosące procesory MIPS, True64 Unix - przeznaczony dla procesorów Alpha (niestety w Bose nieżyjących) Tylko UnixWare nastawiony jest na "demokratyczną" platformę PC, a Solaris istnieje w wersjach na dwie architektury - swój własny, Sparc i wciąż ten sam komputer, który jednak nie przyczynił się zbytnio do ich rozpowszechnienia - ze względu na stosunkowo słabe wsparcie dla nowych peryferiów PC.

Dlatego UNIX jest przede wszystkim koncepcją prawną. Ale termin Unix ma interpretację technologiczną. Jest to potoczna nazwa używana przez branżę IT dla całej rodziny systemów operacyjnych, albo wywodzących się od „oryginalnej” UNIXowej firmy AT&T, albo odtwarzających jej funkcje „od zera”, w tym darmowych systemów operacyjnych, takich jak Linux, FreeBSD i innych BSD, żadna weryfikacja zgodności ze standardem Single Unix nigdy nie została ujawniona. Dlatego często nazywa się je uniksopodobnymi.

Termin „systemy zgodne z POSIX”, który ma bliskie znaczenie, jest również szeroko stosowany, który łączy rodzinę systemów operacyjnych, które odpowiadają zestawowi standardów o tej samej nazwie. Same standardy POSIX (Portable Operation System Interface based on uniX) zostały opracowane na podstawie praktyk przyjętych w systemach uniksowych, a zatem wszystkie te ostatnie są z definicji zgodne z POSIX. Jednak nie są to do końca synonimy: zgodność ze standardami POSIX jest zapewniana przez systemy operacyjne, które są tylko pośrednio związane z Uniksem (QNX, Syllable) lub w ogóle nie są związane (do Windows NT/2000/XP).

Aby wyjaśnić kwestię relacji między UNIX, Unix i POSIX, musimy trochę zagłębić się w historię. Właściwie historia tego zagadnienia jest szczegółowo omówiona w odpowiednim rozdziale książki „Free Unix: Linux, FreeBSD and Others” (wkrótce nakładem BHV-Petersburg) oraz w artykułach dotyczących historii systemów Linux i BSD.

System operacyjny Unix (a dokładniej jego pierwsza wersja) został opracowany przez pracowników Bell Labs (oddział AT&T) w latach 1969-1971. Jej pierwsi autorzy – Ken Thompson i Dennis Ritchie – zrobili to wyłącznie dla własnych celów, w szczególności po to, by móc bawić się swoją ulubioną grą StarTravel. A z wielu powodów prawnych sama firma nie mogła wykorzystać go jako produktu komercyjnego. Jednak praktyczne zastosowanie Unixa znaleziono dość szybko. Po pierwsze, był używany w Bell Labs do przygotowania różnego rodzaju dokumentacji technicznej (w tym patentowej). Po drugie, system komunikacji UUCP (Unix to Unix Copy Program) był oparty na Unixie.

Kolejny obszar, w którym Unix był używany w latach 70. i wczesnych 80. ubiegłego wieku, okazał się dość niezwykły. Mianowicie w tekstach źródłowych był on rozpowszechniany wśród instytucji naukowych prowadzących prace z zakresu Informatyki. Celem takiego rozpowszechniania (nie było ono w obecnym znaczeniu całkowicie darmowe, ale w rzeczywistości okazało się bardzo liberalne) było: edukacja i badania w powyższej dziedzinie wiedzy.

Najbardziej znanym jest system BSD Unix, stworzony na Uniwersytecie Berkeley w Kalifornii. Co, stopniowo uwalniając się od zastrzeżonego kodu oryginalnego Uniksa, w końcu, po dramatycznych wzlotach i upadkach (opisanych szczegółowo tutaj), dało początek nowoczesnym darmowym systemom BSD - FreeBSD, NetBSD i innym.

Jednym z najważniejszych rezultatów prac hakerów uniwersyteckich było (1983) wprowadzenie obsługi protokołu TCP/IP w systemie Unix, na którym opierał się ówczesny ARPANET (i który stał się fundamentem współczesnego Internetu). To był warunek dominacji Unixa we wszystkich obszarach związanych z World Wide Web. I okazało się, że jest to kolejne praktyczne zastosowanie tej rodziny systemów operacyjnych - do tego czasu nie było już potrzeby mówić o pojedynczym Unixie. Ponieważ, jak wspomniano wcześniej, rozdzielił swoje dwie gałęzie - wywodzący się z oryginalnego UNIX-a (z czasem otrzymał nazwę System V) oraz system wywodzący się z Berkeley. Z drugiej strony, System V stanowił podstawę tych różnych prawnie zastrzeżonych UNIX-ów, które w rzeczywistości miały prawo do żądania tej nazwy.

Ostatnia okoliczność - rozgałęzienie niegdyś pojedynczego systemu operacyjnego na kilka linii, które stopniowo tracą kompatybilność - weszła w konflikt z jednym z fundamentów ideologii Unix: przenośnością systemu między różnymi platformami i jego aplikacjami z jednego systemu Unix do inne. Co powołało do życia działania różnego rodzaju organizacji normalizacyjnych, które zakończyły się w końcu stworzeniem zestawu standardów POSIX, o którym była mowa wcześniej.

To właśnie na standardach POSIX oparł się Linus Torvalds, tworząc "od zera" (czyli bez użycia wcześniej istniejącego kodu) swój system operacyjny - Linux. A ona, szybko i skutecznie opanowawszy tradycyjne obszary zastosowań systemów uniksowych (tworzenie oprogramowania, komunikacja, Internet), w końcu otworzyła dla nich nowe - uniwersalne platformy użytkowników komputerów stacjonarnych. To właśnie sprawiło, że stał się popularny wśród ludzi - popularność przewyższająca wszystkie inne systemy Unix łącznie, zarówno zastrzeżone, jak i darmowe.

Dalej porozmawiamy o pracy na systemach uniksowych w najszerszym tego słowa znaczeniu, bez uwzględniania wszelkiego rodzaju znaków towarowych i innych problemów prawnych. Choć główne przykłady związane z metodami pracy będą zaczerpnięte z dziedziny darmowych ich implementacji - Linuxa, w mniejszym stopniu FreeBSD, a jeszcze mniej - z innych systemów BSD.

Skąd wziąć darmowy Unix?

Baza danych FreeBSD - www.freebsd.org;

Możesz wejść na www.sco.com

Główną częścią. (Opis Uniksa)

1. Podstawowe pojęcia Unix

Unix opiera się na dwóch podstawowych pojęciach: „proces” i „plik”. Procesy są dynamiczną stroną systemu, są podmiotami; oraz pliki - statyczne, są to obiekty procesów. Prawie cały interfejs między procesami oddziałującymi z jądrem i między sobą wygląda jak zapisywanie/odczytywanie plików. Chociaż musisz dodać takie rzeczy, jak sygnały, pamięć współdzielona i semafory.

Procesy można z grubsza podzielić na dwa typy - zadania i demony. Zadanie to proces, który wykonuje swoją pracę, starając się go jak najszybciej zakończyć i zakończyć. Demon czeka na zdarzenia, które musi przetworzyć, przetwarza zdarzenia, które wystąpiły, i czeka ponownie; zwykle kończy się na zlecenie innego procesu, najczęściej jest zabijany przez użytkownika, wydając polecenie „kill process_number”. W tym sensie okazuje się, że interaktywne zadanie przetwarzające dane wejściowe użytkownika przypomina bardziej demona niż zadanie.

2. System plików

W starych Uniksach do nazwy przypisano 14 liter, w nowych usunięto to ograniczenie. Oprócz nazwy pliku katalog zawiera jego identyfikator i-węzła - liczbę całkowitą określającą numer bloku, w którym znajduje się rejestrowane są atrybuty pliku, wśród nich: numer użytkownika - właściciel pliku, grupy numerów Liczba odwołań do pliku (patrz niżej) Data i czas utworzenia, ostatniej modyfikacji i ostatniego dostępu do pliku Atrybuty dostępu Atrybuty dostępu zawierają plik typ (patrz poniżej), atrybuty zmiany uprawnień podczas uruchamiania (patrz poniżej) oraz uprawnienia dostępu do niego dla właściciela, kolegi z klasy i innych osób do czytania, pisania i wykonywania. Prawo do usunięcia pliku jest określone przez prawo do zapisu do nadrzędnego informator.

Każdy plik (ale nie katalog) może być znany pod kilkoma nazwami, ale muszą znajdować się na tej samej partycji. Wszystkie linki do pliku są równe; plik jest usuwany po usunięciu ostatniego łącza do pliku. Jeśli plik jest otwarty (do odczytu i/lub zapisu), to liczba linków do niego zwiększa się o jeden; tyle programów, które otwierają plik tymczasowy, usuwa go natychmiast, aby w przypadku awarii, gdy system operacyjny zamknie pliki otwarte przez proces, ten plik tymczasowy zostanie usunięty przez system operacyjny.

Jest jeszcze inna interesująca cecha systemu plików: jeśli po utworzeniu pliku zapis do niego nie odbywał się z rzędu, ale w dużych odstępach czasu, to nie jest przydzielane miejsce na dysku dla tych odstępów czasu. W ten sposób całkowita objętość plików na partycji może być większa niż objętość partycji, a po usunięciu takiego pliku zwalnia się mniej miejsca niż jego rozmiar.

2.1 Typy plików

Pliki są następujących typów:

regularny plik z bezpośrednim dostępem;

katalog (plik zawierający nazwy i identyfikatory innych plików);

dowiązanie symboliczne (ciąg z nazwą innego pliku);

urządzenie blokowe (dysk lub taśma magnetyczna);

urządzenie szeregowe (terminale, porty szeregowe i równoległe; dyski i taśmy mają również interfejs urządzenia szeregowego)

nazwany kanał.

Specjalne pliki przeznaczone do pracy z urządzeniami zwykle znajdują się w katalogu "/dev". Oto niektóre z nich (w nominacji FreeBSD):

tty* - terminale, w tym: ttyv - konsola wirtualna;

ttyd - terminal DialIn (zwykle port szeregowy);

cuaa - Linia telefoniczna

ttyp - pseudoterminal sieciowy;

tty - terminal, z którym powiązane jest zadanie;

wd* - dyski twarde i ich podsekcje, w tym: wd - dysk twardy;

wds - partycja tego dysku (tu zwana „plasterkiem”);

wds - sekcja partycji;

fd - dyskietka;

rwd*, rfd* - to samo co wd* i fd*, ale z dostępem sekwencyjnym;

Czasami wymagane jest, aby program uruchomiony przez użytkownika nie posiadał praw użytkownika, który go uruchomił, ale jakieś inne. W tym przypadku atrybut prawa do zmiany jest ustawiony na prawa użytkownika - właściciela programu. (Jako przykład podam program, który odczytuje plik z pytaniami i odpowiedziami i na podstawie tego, co przeczytał, testuje ucznia, który uruchomił ten program. Program musi mieć prawo do odczytania pliku z odpowiedziami, ale uczeń kto go uruchomił, nie powinien.) Na przykład działa program passwd, za pomocą którego użytkownik może zmienić swoje hasło. Użytkownik może uruchomić program passwd, może dokonywać zmian w bazie danych systemu - ale użytkownik nie może.

W przeciwieństwie do DOS, gdzie pełna nazwa pliku to „dysk:ścieżka” i RISC-OS, czyli „-filesystem-dysk:$.ścieżka” (co generalnie ma swoje zalety), Unix używa przezroczystej notacji w postaci „/ścieżka/nazwa ”. Korzeń jest mierzony od partycji, z której załadowano jądro Unix. Jeśli potrzebna jest inna partycja (a partycja rozruchowa zwykle zawiera tylko to, co jest potrzebne do rozruchu), używane jest polecenie `mount /dev/partitionfile dir`. Jednocześnie pliki i podkatalogi, które wcześniej znajdowały się w tym katalogu, stają się niedostępne, dopóki partycja nie zostanie odmontowana (oczywiście wszyscy normalni ludzie używają pustych katalogów do montowania partycji). Tylko przełożony ma prawo do wsiadania i zdejmowania.

Podczas uruchamiania każdy proces może oczekiwać otwarcia trzech plików, które są znane jako standardowe wejście wejściowe pod deskryptorem 0; standardowe wyjście standardowe na deskryptorze 1; i standardowe wyjście stderr na deskryptorze 2. Po zalogowaniu, gdy użytkownik wprowadza nazwę użytkownika i hasło, a powłoka jest uruchamiana, wszystkie trzy są kierowane do /dev/tty; później każdy z nich może zostać przekierowany do dowolnego pliku.

3. Tłumacz poleceń

Unix prawie zawsze ma dwie powłoki, sh (powłoka) i csh (powłoka podobna do C). Oprócz nich istnieją również bash (Bourne), ksh (Korn) i inne. Nie wchodząc w szczegóły, oto ogólne zasady:

Wszystkie polecenia z wyjątkiem zmiany bieżącego katalogu, ustawiania zmiennych środowiskowych (środowiska) i instrukcji programowania strukturalnego są programami zewnętrznymi. Programy te zwykle znajdują się w katalogach /bin i /usr/bin. Programy do administrowania systemem - w katalogach /sbin i /usr/sbin.

Polecenie składa się z nazwy programu, który ma zostać uruchomiony oraz argumentów. Argumenty są oddzielone od nazwy polecenia i od siebie spacjami i tabulatorami. Niektóre znaki specjalne są interpretowane przez samą powłokę.Znaki specjalne to " " ` ! $ ^ * ? | & ; (co jeszcze?).

Możesz podać wiele poleceń w tym samym wierszu poleceń. Zespoły można dzielić; (sekwencyjne wykonywanie poleceń), & (asynchroniczne jednoczesne wykonywanie poleceń), | (wykonanie synchroniczne, standardowe wyjście pierwszego polecenia zostanie podane na standardowe wejście drugiego).

Możesz również pobrać standardowe wejście z pliku, dołączając "plik" (plik zostanie wyzerowany) lub ">>plik" (wpis zostanie zapisany na końcu pliku) jako jeden z argumentów.

Jeśli potrzebujesz informacji o jakimkolwiek poleceniu, wydaj polecenie "man nazwa_komendy". Zostanie to wyświetlone na ekranie przez program "more" - zobacz jak zarządzać tym na swoim Unixie za pomocą polecenia `man more`.

4. Jądro UNIX

Jak każdy inny system operacyjny dla wielu użytkowników, który chroni użytkowników przed sobą nawzajem i dane systemowe przed każdym nieuprzywilejowanym użytkownikiem, UNIX ma bezpieczne jądro, które zarządza zasobami komputera i zapewnia użytkownikom podstawowy zestaw usług.

Wygoda i wydajność nowoczesnych wersji systemu operacyjnego UNIX nie oznacza, że ​​cały system, w tym jądro, jest zaprojektowany i skonstruowany w najlepszy możliwy sposób. System operacyjny UNIX ewoluował na przestrzeni lat (jest to pierwszy system operacyjny w historii, który w tak dojrzałym wieku nadal zyskuje popularność – od ponad 25 lat). Oczywiście możliwości systemu rosły i, jak to często bywa w dużych systemach, jakościowa poprawa struktury UNIX OS nie nadążała za wzrostem jego możliwości.

W rezultacie rdzeń większości nowoczesnych komercyjnych wersji systemu operacyjnego UNIX to duży, niezbyt dobrze skonstruowany monolit. Z tego powodu programowanie na poziomie jądra UNIX nadal jest sztuką (z wyjątkiem dobrze znanej i zrozumiałej technologii tworzenia zewnętrznych sterowników urządzeń). Ten brak możliwości produkcyjnych w organizacji jądra UNIX nie zadowala wielu. Stąd chęć pełnego odtworzenia środowiska UNIX OS przy zupełnie innej organizacji systemu.

Ze względu na największe rozpowszechnienie często dyskutowane jest jądro UNIX System V (można je uznać za tradycyjne).

4.1 Ogólna organizacja tradycyjnego jądra UNIX

Jednym z głównych osiągnięć systemu operacyjnego UNIX jest to, że system ma właściwość dużej mobilności. Znaczenie tej jakości polega na tym, że cały system operacyjny, w tym jego jądro, można stosunkowo łatwo przenieść na różne platformy sprzętowe. Wszystkie części systemu, z wyjątkiem jądra, są całkowicie niezależne od komputera. Te komponenty są starannie napisane w C, a przeniesienie ich na nową platformę (przynajmniej na 32-bitową klasę komputerów) wymaga jedynie rekompilacji. kod źródłowy do kodów komputera docelowego.

Oczywiście największe problemy wiążą się z jądrem systemowym, które całkowicie ukrywa specyfikę używanego komputera, ale samo od tej specyfiki zależy. W wyniku przemyślanego oddzielenia komponentów jądra zależnych od maszyny i niezależnych od maszyny (podobno z punktu widzenia twórców systemów operacyjnych jest to najwyższe osiągnięcie twórców tradycyjnego jądra UNIX OS), udało się osiągnąć, że główna część jądra nie zależy od cech architektury platformy docelowej, jest napisana w całości w C i wymaga jedynie ponownej kompilacji w celu przeniesienia na nową platformę.

Jednak stosunkowo mała część jądra jest zależna od komputera i jest napisana w mieszance C i języka asemblera docelowego procesora. Przy przenoszeniu systemu na nową platformę, ta część jądra musi zostać przepisana przy użyciu języka asemblera i z uwzględnieniem specyfiki sprzętu docelowego. Zależne od maszyny części jądra są dobrze odizolowane od głównej części niezależnej od maszyny, a przy dobrym zrozumieniu celu każdego komponentu zależnego od maszyny przepisanie części specyficznej dla maszyny jest głównie zadaniem technicznym (chociaż wymaga wysokiego umiejętności programowania).

Specyficzna dla komputera część tradycyjnego jądra UNIX zawiera następujące składniki:

promocja i inicjalizacja systemu na niskim poziomie (na razie zależy to od możliwości sprzętu);

pierwotne przetwarzanie przerwań wewnętrznych i zewnętrznych;

zarządzanie pamięcią (w części dotyczącej funkcji obsługi sprzętu pamięci wirtualnej);

przełączanie kontekstu procesu między trybami użytkownika i jądra;

docelowe części sterowników urządzeń specyficzne dla platformy.

4.2 Główne funkcje jądra

Główne funkcje jądra UNIX OS obejmują:

(a) Inicjalizacja systemu – funkcja start-up i spin-up. Jądro udostępnia narzędzie ładowania początkowego, które ładuje pełne jądro do pamięci komputera i uruchamia jądro.

(b) Zarządzanie procesami i wątkami - funkcja tworzenia, zatrzymywania i śledzenia istniejących procesów i wątków ("procesów" działających na współdzielonej pamięci wirtualnej). Ponieważ UNIX jest wieloprocesowym systemem operacyjnym, jądro zapewnia współdzielenie czasu procesora (lub procesorów w systemach wieloprocesorowych) i innych zasobów komputera między uruchomionymi procesami, aby dać wrażenie, że procesy faktycznie działają równolegle.

(c) Zarządzanie pamięcią to funkcja mapowania praktycznie nieograniczonej pamięci wirtualnej procesów do fizycznej pamięci RAM komputera, której rozmiar jest ograniczony. Odpowiedni składnik jądra zapewnia współużytkowanie tych samych obszarów pamięci RAM przez kilka procesów korzystających z pamięci zewnętrznej.

(d) Zarządzanie plikami - funkcja realizująca abstrakcję systemu plików - hierarchie katalogów i plików. Systemy plików UNIX obsługują kilka typów plików. Niektóre pliki mogą zawierać dane ASCII, inne będą odpowiadać urządzeniom zewnętrznym. System plików przechowuje pliki obiektowe, pliki wykonywalne i tak dalej. Pliki są zwykle przechowywane na zewnętrznych urządzeniach pamięci masowej; dostęp do nich zapewnia jądro. W świecie UNIX istnieje kilka typów organizacji systemu plików. Nowoczesne warianty systemu operacyjnego UNIX obsługują jednocześnie większość typów systemów plików.

(e) Środki komunikacji - funkcja zapewniająca możliwość wymiany danych między procesami działającymi na tym samym komputerze (IPC - Inter-Process Communications), między procesami działającymi w różnych węzłach lokalnej lub rozległej sieci danych, a także między procesami oraz sterowniki urządzeń zewnętrznych .

(f) Interfejs programistyczny - funkcja zapewniająca dostęp do możliwości jądra od strony procesów użytkownika w oparciu o mechanizm wywołań systemowych, ułożonych w formie biblioteki funkcji.

4.3 Zasady interakcji z rdzeniem

W każdym systemie operacyjnym obsługiwany jest pewien mechanizm, który umożliwia programom użytkownika dostęp do usług jądra systemu operacyjnego. W systemach operacyjnych najsłynniejszego radzieckiego komputera BESM-6 odpowiednie środki komunikacji z jądrem nazywano ekstrakodami, w systemach operacyjnych IBM nazywano je makrami systemowymi i tak dalej. W systemie UNIX te udogodnienia są nazywane wywołaniami systemowymi.

Nazwa nie zmienia znaczenia, które polega na tym, że aby uzyskać dostęp do funkcji jądra systemu operacyjnego, używane są „specjalne instrukcje” procesora, podczas wykonywania następuje specjalny rodzaj przerwania wewnętrznego procesora, przenoszący go do trybu jądra (w większości nowoczesnych OS tego typu przerwanie nazywa się pułapka - pułapka). Podczas przetwarzania takich przerwań (odszyfrowywania) jądro systemu operacyjnego rozpoznaje, że przerwanie jest w rzeczywistości żądaniem do jądra z programu użytkownika wykonania określonych czynności, wybiera parametry wywołania i przetwarza je, a następnie wykonuje „powrót z przerwania ", wznawiając normalne wykonywanie programu użytkownika.

Jasne jest, że specyficzne mechanizmy podnoszenia przerwań wewnętrznych inicjowanych przez program użytkownika różnią się w różnych architekturach sprzętowych. Ponieważ system operacyjny UNIX dąży do zapewnienia środowiska, w którym programy użytkownika mogą być w pełni mobilne, wymagana była dodatkowa warstwa, aby ukryć specyfikę konkretnego mechanizmu podnoszenia przerwań wewnętrznych. Mechanizm ten zapewnia tzw. biblioteka wywołań systemowych.

Dla użytkownika biblioteka wywołań systemowych jest zwykłą biblioteką wstępnie zaimplementowanych funkcji systemu programowania C. Podczas programowania w C użycie dowolnej funkcji z biblioteki wywołań systemowych nie różni się od używania dowolnej natywnej lub bibliotecznej funkcji C. Jednak wewnątrz dowolnej funkcji konkretnej biblioteki wywołań systemowych znajduje się kod, który jest, ogólnie rzecz biorąc, specyficzny dla danej platformy sprzętowej.

4.4 Zasady obsługi przerwań

Oczywiście mechanizm obsługi przerwań wewnętrznych i zewnętrznych stosowany w systemach operacyjnych zależy głównie od tego, jakiego rodzaju sprzętową obsługę przerwań zapewnia dana platforma sprzętowa. Na szczęście do tej pory (i od dłuższego czasu) najwięksi producenci komputerów de facto uzgodnili podstawowe mechanizmy przerwań.

Mówiąc niezbyt precyzyjnie i konkretnie, istotą przyjętego dziś mechanizmu jest to, że każde możliwe przerwanie procesora (czy to wewnętrzne, czy zewnętrzne) odpowiada pewnemu stałemu adresowi fizycznej pamięci RAM. W momencie, gdy procesor może przerwać z powodu obecności wewnętrznego lub zewnętrznego żądania przerwania, następuje sprzętowe przekazanie kontroli do fizycznej komórki RAM z odpowiednim adresem - zwykle adres tej komórki nazywa się „przerwaniem wektor” (zwykle żądania przerwania wewnętrznego, tj. żądania przychodzące bezpośrednio z procesora są natychmiast spełniane).

Zadaniem systemu operacyjnego jest umieszczenie w odpowiednich komórkach pamięci RAM kodu programu, który zapewnia wstępne przetwarzanie przerwania i inicjuje pełne przetwarzanie.

Zasadniczo system operacyjny UNIX przyjmuje podejście ogólne. W wektorze przerwań odpowiadającym przerwaniu zewnętrznemu, tj. przerwanie z jakiegoś urządzenia zewnętrznego, zawiera instrukcje, które ustawiają poziom działania procesora (poziom działania określa, na które przerwania zewnętrzne procesor powinien natychmiast zareagować) i przeskakuje do pełnej obsługi przerwań w odpowiednim sterowniku urządzenia. W przypadku przerwania wewnętrznego (na przykład przerwania zainicjowanego przez program użytkownika, gdy w pamięci głównej brakuje wymaganej strony pamięci wirtualnej, gdy wystąpi wyjątek w programie użytkownika itp.) lub przerwania czasowego, wektor przerwań zawiera przejdź do odpowiedniego programu jądra UNIX.

5. Sterowanie we/wy

Tradycyjnie UNIX OS rozróżnia trzy typy organizacji I/O i odpowiednio trzy typy sterowników. Blokowe I/O przeznaczone jest głównie do pracy z katalogami i zwykłymi plikami systemu plików, które na poziomie podstawowym mają strukturę blokową. Na poziomie użytkownika możliwa jest teraz praca z plikami poprzez bezpośrednie mapowanie ich do segmentów pamięci wirtualnej. Ta funkcja jest uważana za najwyższy poziom blokowych wejść/wyjść. Na niższym poziomie blokowe wejścia/wyjścia są obsługiwane przez sterowniki blokowe. Blokowe we/wy jest również obsługiwane przez buforowanie systemu.

Wejście/wyjście znaków jest używane do bezpośredniej (bez buforowania) wymiany między przestrzenią adresową użytkownika a odpowiednim urządzeniem. Obsługa jądra wspólna dla wszystkich sterowników znaków polega na udostępnianiu funkcji przesyłania danych między przestrzeniami adresowymi użytkownika i jądra.

Wreszcie, strumień I/O jest podobny do I/O znakowego, ale ze względu na możliwość włączenia pośrednich modułów przetwarzania do strumienia, ma znacznie większą elastyczność.

5.1 Zasady buforowania wejść/wyjść systemu

Tradycyjnym sposobem zmniejszenia narzutu podczas wymiany z zewnętrznymi urządzeniami pamięci, które mają strukturę blokową, jest buforowanie we/wy bloków. Oznacza to, że dowolny blok pamięci zewnętrznej jest wczytywany najpierw do pewnego bufora obszaru pamięci głównej, zwanego w systemie UNIX buforem systemowym, a stamtąd jest w całości lub częściowo (w zależności od rodzaju wymiany) kopiowany do odpowiednią przestrzeń użytkownika.

Zasady organizacji tradycyjnego mechanizmu buforowania polegają po pierwsze na tym, że kopia zawartości bloku jest przechowywana w buforze systemowym do czasu, aż zaistnieje konieczność jej wymiany ze względu na brak buforów (wykorzystywana jest odmiana algorytmu LRU zorganizować politykę wymiany). Po drugie, podczas zapisywania dowolnego bloku pamięci zewnętrznej, w rzeczywistości wykonywana jest tylko aktualizacja (lub tworzenie i wypełnianie) bufora pamięci podręcznej. Rzeczywista wymiana z urządzeniem odbywa się albo przez otwarcie bufora z powodu zastąpienia jego zawartości, albo przez wydanie specjalnego wywołania systemowego sync (lub fsync), obsługiwanego specjalnie do wymuszania wypychania zaktualizowanych buforów pamięci podręcznej do pamięci zewnętrznej.

Ten tradycyjny schemat buforowania wchodził w konflikt z narzędziami do zarządzania pamięcią wirtualną rozwijanymi we współczesnych wersjach systemu operacyjnego UNIX, aw szczególności z mechanizmem mapowania plików do segmentów pamięci wirtualnej. Dlatego System V Release 4 wprowadził nowy schemat buforowania, który jest obecnie używany równolegle ze starym schematem.

Istotą nowego schematu jest to, że na poziomie jądra faktycznie odtwarzany jest mechanizm mapowania plików na segmenty pamięci wirtualnej. Po pierwsze, pamiętaj, że jądro UNIX rzeczywiście działa we własnej pamięci wirtualnej. Ta pamięć ma bardziej złożoną, ale zasadniczo taką samą strukturę jak pamięć wirtualna użytkownika. Innymi słowy, pamięć wirtualna jądra to segment-strona i wraz z pamięcią wirtualną procesów użytkownika jest obsługiwana przez wspólny podsystem zarządzania pamięcią wirtualną. Po drugie, wynika z tego, że prawie każda funkcja dostarczana przez jądro użytkownikom może być przekazywana przez niektóre komponenty jądra innym komponentom jądra. W szczególności dotyczy to również możliwości mapowania plików na segmenty pamięci wirtualnej.

Nowy schemat buforowania w jądrze UNIX opiera się głównie na fakcie, że nie można zrobić prawie nic specjalnego, aby zorganizować buforowanie. Gdy jeden z procesów użytkownika otwiera plik, który nie był do tej pory otwierany, jądro tworzy nowy segment i łączy otwierany plik z tym segmentem. Następnie (niezależnie od tego, czy proces użytkownika będzie pracował z plikiem w trybie tradycyjnym przy użyciu wywołań systemowych odczytu i zapisu, czy też połączy plik z jego segmentem pamięci wirtualnej), na poziomie jądra, praca będzie wykonywana z segmentem jądra do którego plik jest dołączony na poziomie kernels. Główną ideą nowego podejścia jest wyeliminowanie luki między zarządzaniem pamięcią wirtualną a buforowaniem ogólnosystemowym (powinno to być zrobione dawno temu, ponieważ oczywiste jest, że główne buforowanie w systemie operacyjnym powinno być wykonywane przez komponent zarządzania pamięcią wirtualną).

Dlaczego nie zrezygnować ze starego mechanizmu buforowania? Chodzi o to, że nowy schemat zakłada obecność pewnego ciągłego adresowania wewnątrz zewnętrznego obiektu pamięci (musi istnieć izomorfizm między mapowanymi i mapowanymi obiektami). Jednak podczas organizowania systemów plików system operacyjny UNIX jest dość trudny do przydzielenia pamięci zewnętrznej, co jest szczególnie ważne w przypadku i-węzłów. Dlatego niektóre bloki pamięci zewnętrznej należy uznać za izolowane i dla nich bardziej korzystne okazuje się użycie starego schematu buforowania (chociaż w przyszłych wersjach systemu UNIX może być możliwe całkowite przełączenie się na nowy, ujednolicony schemat).

5. 2 wywołania systemowe do sterowania we/wy

Aby uzyskać dostęp (to znaczy, aby móc wykonać kolejne operacje we/wy) dowolnego rodzaju pliku (w tym plików specjalnych), proces użytkownika musi najpierw połączyć się z plikiem za pomocą jednego z wywołań systemowych open, creat, dup lub potoku .

Sekwencja działań wywołania systemowego open (ścieżka, tryb) jest następująca:

analizowana jest spójność parametrów wejściowych (głównie związanych z flagami trybu dostępu do plików);

przestrzeń jest przydzielona lub zlokalizowana dla deskryptora pliku w obszarze danych procesowych systemu (obszar u);

w obszarze ogólnosystemowym istniejąca przestrzeń jest przydzielana lub lokalizowana w celu dostosowania deskryptora plików systemowych (struktury plików);

archiwum systemu plików jest przeszukiwane w poszukiwaniu obiektu o nazwie "pathname" i generowany jest lub znaleziony deskryptor pliku na poziomie systemu plików (vnode w terminach UNIX V System 4);

vnode jest powiązany z poprzednio utworzoną strukturą pliku.

Wywołania systemowe open i create są (prawie) funkcjonalnie równoważne. Każdy istniejący plik można otworzyć za pomocą wywołania systemowego create, a każdy nowy plik można utworzyć za pomocą wywołania systemowego open. Jednak w odniesieniu do wywołania systemowego creat należy podkreślić, że w swoim naturalnym użyciu (do utworzenia pliku) wywołanie to tworzy nowy wpis w odpowiednim katalogu (zgodnie z podaną ścieżką), a także tworzy i odpowiednio inicjuje nowy i-węzeł.

Na koniec wywołanie systemowe dup (duplikat - kopia) prowadzi do utworzenia nowego deskryptora dla już otwartego pliku. To wywołanie systemowe specyficzne dla systemu UNIX służy wyłącznie do przekierowywania we/wy). Jego wykonanie polega na utworzeniu nowego otwartego deskryptora pliku w obszarze u przestrzeni systemowej procesu użytkownika, zawierającego nowo utworzony deskryptor pliku (liczba całkowita), ale odwołującego się do już istniejącej ogólnosystemowej struktury plików i zawierającego te same znaki i flagi które odpowiadają otwartemu przykładowemu plikowi.

Inne ważne wywołania systemowe to wywołania systemowe odczytu i zapisu. Wywołanie systemowe read jest wykonywane w następujący sposób:

deskryptor określonego pliku znajduje się w ogólnosystemowej tablicy plików i określa się, czy dostęp danego procesu do danego pliku w określonym trybie jest legalny;

na pewien (krótki) czas na vnode tego pliku jest ustawiana blokada synchronizacji (zawartość deskryptora nie może ulec zmianie w krytycznych momentach operacji odczytu);

rzeczywisty odczyt odbywa się za pomocą starego lub nowego mechanizmu buforowania, po czym dane są kopiowane, aby były dostępne w przestrzeni adresowej użytkownika.

Operacja zapisu działa w ten sam sposób, ale zmienia zawartość bufora puli buforów.

Wywołanie systemowe zamknięcia powoduje, że sterownik przerywa skojarzony proces użytkownika i (w przypadku ostatniego zamknięcia urządzenia) ustawia ogólnosystemową flagę „sterownik wolny”.

Wreszcie, inne "specjalne" wywołanie systemowe ioctl jest obsługiwane dla plików specjalnych. Jest to jedyne wywołanie systemowe, które jest dostępne dla plików specjalnych i nie jest dostępne dla innych rodzajów plików. W rzeczywistości wywołanie systemowe ioctl pozwala na dowolne rozszerzenie interfejsu dowolnego sterownika. Parametry ioctl obejmują opcode i wskaźnik do pewnego obszaru pamięci procesu użytkownika. Cała interpretacja kodu operacji i związanych z nim określonych parametrów jest obsługiwana przez sterownik.

Oczywiście, ponieważ sterowniki są przeznaczone głównie do sterowania urządzeniami zewnętrznymi, kod sterownika musi zawierać odpowiednie środki do obsługi przerwań z urządzenia. Wywołanie indywidualnego programu obsługi przerwań w sterowniku pochodzi z jądra systemu operacyjnego. Podobnie, sterownik może zadeklarować wejście "timeout", do którego jądro uzyskuje dostęp, gdy upłynie czas wcześniej zamówiony przez sterownik (taka kontrola czasu jest konieczna przy zarządzaniu mniej inteligentnymi urządzeniami).

Ogólny schemat organizacji interfejsów maszynistów pokazano na rysunku 3.5. Jak pokazuje ten rysunek, pod względem interfejsów i zarządzania w całym systemie istnieją dwa typy sterowników - znakowe i blokowe. Z punktu widzenia organizacji wewnętrznej wyróżnia się inny rodzaj sterowników - sterowniki strumieniowe. Jednak pod względem interfejsu zewnętrznego sterowniki strumieni nie różnią się od sterowników znaków.

6. Interfejsy i punkty wejściowe sterowników

6.1 Zablokuj sterowniki

Sterowniki blokowe są przeznaczone do obsługi urządzeń zewnętrznych o strukturze blokowej (dyski magnetyczne, taśmy itp.) i różnią się od innych tym, że są opracowywane i wykonywane z wykorzystaniem buforowania systemowego. Innymi słowy, takie sterowniki zawsze działają poprzez systemową pulę buforów. Jak widać na rysunku 3.5, każdy dostęp odczytu lub zapisu do sterownika bloku zawsze przechodzi przez przetwarzanie wstępne, które polega na próbie znalezienia kopii żądanego bloku w puli buforów.

Jeśli kopia wymaganego bloku nie znajduje się w puli buforów lub jeśli z jakiegoś powodu konieczne jest zastąpienie zawartości jakiegoś zaktualizowanego bufora, jądro UNIX wywołuje procedurę strategii odpowiedniego sterownika bloku. Strategia zapewnia standardowy interfejs między jądrem a sterownikiem. Wykorzystując podprogramy biblioteczne przeznaczone do pisania sterowników, procedura strategii może organizować kolejki wymian z urządzeniem, np. w celu optymalizacji ruchu głowic magnetycznych na dysku. Wszystkie wymiany wykonywane przez sterownik bloku są wykonywane z pamięcią buforową. Przepisywanie niezbędnych informacji do pamięci odpowiedniego procesu użytkownika jest wykonywane przez programy jądra, które zarządzają buforami

6.2 Sterowniki znaków

Sterowniki znakowe są przeznaczone głównie do obsługi urządzeń, które przekazują ciągi znaków znak po znaku lub ciągi znaków o zmiennej długości. Typowym przykładem urządzenia znakowego jest prosta drukarka, która akceptuje jeden znak na wymianę.

Sterowniki znaków nie używają buforowania systemowego. Bezpośrednio kopiują dane z pamięci procesu użytkownika podczas wykonywania operacji zapisu lub do pamięci procesu użytkownika podczas wykonywania operacji odczytu, używając własnych buforów.

Należy zauważyć, że możliwe jest zapewnienie interfejsu znakowego dla urządzenia blokowego. W tym przypadku drajwer bloku wykorzystuje dodatkowe cechy procedury strategii, co pozwala na przeprowadzenie wymiany bez użycia buforowania systemowego. W przypadku sterownika, który ma zarówno interfejs blokowy, jak i znakowy, w systemie plików tworzone są dwa specjalne pliki: blokowy i znakowy. Przy każdym połączeniu kierowca otrzymuje informację o trybie, w jakim jest używany.

6. 3 sterowniki strumienia

Głównym celem mechanizmu strumieni jest zwiększenie poziomu modułowości i elastyczności sterowników ze złożoną logiką wewnętrzną (dotyczy to przede wszystkim sterowników implementujących zaawansowane protokoły sieciowe). Specyfiką takich sterowników jest to, że większość kodu programu nie zależy od funkcji urządzenia sprzętowego. Co więcej, często korzystne jest łączenie części kodu programu na różne sposoby.

Wszystko to doprowadziło do powstania architektury strumieniowej sterowników, które są dwukierunkowym rurociągiem modułów przetwarzających. Na początku potoku (najbliżej procesu użytkownika) znajduje się nagłówek strumienia, do którego użytkownik ma przede wszystkim dostęp. Na końcu potoku (najbliżej urządzenia) znajduje się normalny sterownik urządzenia. W szczelinie może znajdować się dowolna liczba modułów przetwarzających, z których każdy jest zaprojektowany zgodnie z wymaganym interfejsem przesyłania strumieniowego.

7. Polecenia i narzędzia

Pracując interaktywnie w środowisku UNIX OS, używają różnych narzędzi lub poleceń zewnętrznych języka powłoki. Wiele z tych narzędzi jest tak złożonych, jak sama powłoka (a przy okazji, sama powłoka jest jednym z narzędzi, które można wywołać z wiersza poleceń).

7. 1 Organizacja zespołu w systemie UNIX OS

Aby utworzyć nowe polecenie, wystarczy przestrzegać zasad programowania w C. Każdy dobrze uformowany program w C rozpoczyna swoje wykonanie od funkcji main. Ta „półsystemowa” funkcja ma standardowy interfejs, który jest podstawą do organizowania poleceń, które można wywoływać w środowisku powłoki. Polecenia zewnętrzne są wykonywane przez interpreter powłoki przy użyciu zestawu wywołań systemowych fork i jednej z opcji exec. Parametry wywołania systemowego exec obejmują zestaw ciągów tekstowych. Ten zestaw ciągów tekstowych jest przekazywany jako dane wejściowe do głównej funkcji uruchamianego programu.

Dokładniej, główna funkcja przyjmuje dwa parametry - argc (liczbę ciągów tekstowych do przekazania) i argv (wskaźnik do tablicy wskaźników do ciągów tekstowych). Program twierdzący, że użyje go jako polecenia powłoki, musi mieć dobrze zdefiniowany interfejs zewnętrzny(parametry są zwykle wprowadzane z terminala) i muszą kontrolować i poprawnie analizować parametry wejściowe.

Ponadto, aby dostosować się do stylu powłoki, taki program nie powinien sam nadpisywać plików odpowiadających standardowemu wejściu, standardowemu wyjściu i standardowym błędom. Polecenie może następnie zostać przekierowane we/wy w zwykły sposób i może być zawarte w potokach.

7.2 Przekierowanie we/wy i orurowanie

Jak widać z ostatniego zdania poprzedniego akapitu, nie musisz robić nic specjalnego, aby włączyć przekierowanie I/O i potokowanie podczas programowania instrukcji. Wystarczy po prostu pozostawić nietknięte trzy początkowe deskryptory plików i prawidłowo pracować z tymi plikami, a mianowicie wyprowadzić plik z stdout deskryptora, wprowadzić dane z pliku stdin i wydrukować komunikaty o błędach do pliku stderror.

7. 3 Wbudowane, biblioteka i polecenia użytkownika

Wbudowane polecenia są częścią kodu programu powłoki. Działają jako podprogramy interpretera i nie można ich zastąpić ani przedefiniować. Składnia i semantyka poleceń wbudowanych są zdefiniowane w odpowiednim języku poleceń.

Polecenia biblioteczne są częścią oprogramowania systemowego. Jest to zestaw programów wykonywalnych (narzędzi) dostarczanych wraz z systemem operacyjnym. Większość z tych programów (takich jak vi, emacs, grep, find, make itp.) jest niezwykle przydatna w praktyce, ale ich omówienie wykracza poza zakres tego kursu (są osobne grube książki).

Polecenie użytkownika to dowolny program wykonywalny zorganizowany zgodnie z wymaganiami określonymi w. W ten sposób każdy użytkownik systemu UNIX OS może w nieskończoność rozszerzać repertuar poleceń zewnętrznych swojego języka poleceń (na przykład można napisać własny interpreter poleceń).

7.4 Programowanie w języku poleceń

Każdy z wymienionych wariantów języka powłoki może w zasadzie być używany jako język programowania. Wśród użytkowników UNIXa jest wiele osób, które piszą całkiem poważne programy w powłoce. Do programowania lepiej używać języków programowania (C, C++, Pascal itp.) niż języków poleceń.

8. Narzędzia GUI

Chociaż obecnie wielu profesjonalnych programistów UNIX woli korzystać z tradycyjnych, liniowych sposobów interakcji z systemem, powszechne stosowanie stosunkowo niedrogich, kolorowych terminali graficznych o wysokiej rozdzielczości doprowadziło do tego, że wszystkie nowoczesne wersje systemu UNIX OS obsługują użytkownika graficznego interfejsy z systemem, a użytkownicy otrzymują narzędzia do tworzenia interfejsów graficznych z tworzonymi przez siebie programami. Z punktu widzenia użytkownika końcowego narzędzia interfejsu graficznego obsługiwane w różnych wersjach systemu operacyjnego UNIX i innych systemach (na przykład MS Windows lub Windows NT) są mniej więcej takie same.

Po pierwsze, we wszystkich przypadkach obsługiwany jest tryb wielookienkowy z ekranem terminala. W dowolnym momencie użytkownik może utworzyć nowe okno i powiązać je z żądanym programem, który współpracuje z tym oknem jak z osobnym terminalem. Okna można przesuwać, zmieniać rozmiar, tymczasowo zamykać itp.

Po drugie, we wszystkich nowoczesnych odmianach interfejsu graficznego obsługiwane jest sterowanie myszą. W przypadku UNIXa często okazuje się, że zwykła klawiatura terminala jest używana tylko przy przechodzeniu na tradycyjny interfejs liniowy (chociaż w większości przypadków przynajmniej jedno okno terminala uruchamia jedną z powłok z rodziny powłok).

Po trzecie, takie rozpowszechnienie „myszkowego” stylu pracy jest możliwe dzięki wykorzystaniu narzędzi interfejsu opartych na piktogramach (ikonach) i menu. W większości przypadków program działający w określonym oknie prosi użytkownika o wybranie dowolnej funkcji, którą ma wykonać, albo wyświetlając zestaw symbolicznych obrazów możliwych funkcji (ikon) w oknie, albo oferując wielopoziomowe menu . W każdym razie do dalszego wyboru wystarczy sterować kursorem odpowiedniego okna za pomocą myszy.

Wreszcie, nowoczesne interfejsy graficzne są „przyjazne dla użytkownika”, zapewniając możliwość natychmiastowego uzyskania interaktywnej pomocy na każdą okazję. (Być może trafniej byłoby powiedzieć, że dobry styl programowania GUI to taki, który faktycznie dostarcza takich wskazówek.)

Po wyliczeniu tych wszystkich ogólnych właściwości nowoczesnych narzędzi GUI, może pojawić się naturalne pytanie: Skoro istnieje taka jednolitość w dziedzinie interfejsów graficznych, to co jest szczególnego w interfejsach graficznych w środowisku UNIX? Odpowiedź jest dość prosta. Tak, użytkownik końcowy w rzeczywistości w każdym dzisiejszym systemie ma do czynienia z w przybliżeniu tym samym zestawem funkcji interfejsu, ale w różnych systemach te funkcje są osiągane na różne sposoby. Jak zwykle zaletą UNIX-a jest dostępność wystandaryzowanych technologii, które pozwalają na tworzenie aplikacji mobilnych z graficznymi interfejsami.

8. Zasady ochrony

Ponieważ system operacyjny UNIX od samego początku był pomyślany jako system operacyjny dla wielu użytkowników, problem autoryzacji dostępu różnych użytkowników do plików systemu plików zawsze był w nim istotny. Autoryzacja dostępu odnosi się do akcji systemowych, które zezwalają lub odmawiają danemu użytkownikowi dostępu do danego pliku, w zależności od praw dostępu użytkownika i ograniczeń dostępu ustawionych dla pliku. Schemat autoryzacji dostępu zastosowany w UNIX OS jest na tyle prosty i wygodny, a jednocześnie tak potężny, że stał się de facto standardem nowoczesnych systemów operacyjnych (które nie pretendują do miana systemów z wielopoziomową ochroną).

8.1 Identyfikatory użytkowników i grupy użytkowników

Każdy uruchomiony proces w systemie UNIX jest powiązany z rzeczywistym identyfikatorem użytkownika, efektywnym identyfikatorem użytkownika i zapisanym identyfikatorem użytkownika. Wszystkie te identyfikatory są ustawiane za pomocą wywołania systemowego setuid, które może być wykonane tylko w trybie administratora. Podobnie, każdy proces ma powiązane z nim trzy identyfikatory grup użytkowników — rzeczywisty identyfikator grupy, efektywny identyfikator grupy i zapisany identyfikator grupy. Te identyfikatory są ustawiane przez uprzywilejowane wywołanie systemowe setgid.

Gdy użytkownik loguje się do systemu, program login sprawdza, czy użytkownik jest zalogowany i zna prawidłowe hasło (jeśli jest ustawione), tworzy nowy proces i uruchamia w nim powłokę wymaganą dla tego użytkownika. Ale zanim to zrobisz, login ustawia identyfikatory użytkownika i grupy dla nowo utworzonego procesu, używając informacji przechowywanych w plikach /etc/passwd i /etc/group. Po skojarzeniu identyfikatorów użytkowników i grup z procesem, do tego procesu mają zastosowanie ograniczenia dostępu do plików. Proces może uzyskać dostęp do pliku lub go wykonać (jeśli plik zawiera program wykonywalny) tylko wtedy, gdy pozwalają na to ograniczenia dostępu do pliku. Identyfikatory skojarzone z procesem są przekazywane do procesów, które tworzy, podlegając tym samym ograniczeniom. Jednak w niektórych przypadkach proces może zmienić swoje uprawnienia za pomocą wywołań systemowych setuid i setgid, a czasami system może zmienić uprawnienia procesu automatycznie.

Rozważmy na przykład następującą sytuację. Do pliku /etc/passwd nie może zapisywać nikt poza superużytkownikiem (superużytkownik może zapisywać do dowolnego pliku). Ten plik zawiera między innymi hasła użytkowników, a każdy użytkownik może zmienić swoje hasło. Do dyspozycji program specjalny/bin/passwd, który zmienia hasła. Jednak użytkownik nie może tego zrobić nawet z tym programem, ponieważ plik /etc/passwd nie może być zapisywany. W systemie UNIX ten problem został rozwiązany w następujący sposób. Plik wykonywalny może określać, że po uruchomieniu należy ustawić identyfikatory użytkownika i/lub grupy. Jeśli użytkownik zażąda wykonania takiego programu (używając wywołania systemowego exec), wówczas identyfikator użytkownika odpowiedniego procesu jest ustawiany na identyfikator właściciela pliku wykonywalnego i/lub identyfikator grupy tego właściciela. W szczególności, gdy uruchomiony jest program /bin/passwd, proces będzie miał identyfikator root, a program będzie mógł zapisywać do pliku /etc/passwd.

Zarówno w przypadku identyfikatora użytkownika, jak i identyfikatora grupy, rzeczywistym identyfikatorem jest prawdziwy identyfikator, a efektywnym identyfikatorem bieżącego wykonania. Jeśli bieżący identyfikator użytkownika pasuje do superużytkownika, to ten identyfikator i identyfikator grupy można zresetować do dowolnej wartości za pomocą wywołań systemowych setuid i setgid. Jeśli bieżący identyfikator użytkownika jest inny niż identyfikator superużytkownika, wykonanie wywołań systemowych setuid i setgid powoduje zastąpienie bieżącego identyfikatora prawdziwym identyfikatorem (odpowiednio użytkownika lub grupy).

8.2 Ochrona plików

Jak zwykle w wieloużytkownikowym systemie operacyjnym, UNIX utrzymuje jednolity mechanizm kontroli dostępu do plików i katalogów systemu plików. Każdy proces może uzyskać dostęp do określonego pliku wtedy i tylko wtedy, gdy prawa dostępu opisane w pliku odpowiadają możliwościom tego procesu.

Ochrona plików przed nieautoryzowanym dostępem w systemie UNIX opiera się na trzech faktach. Po pierwsze, każdy proces tworzący plik (lub katalog) jest powiązany z jakimś unikalnym identyfikatorem użytkownika (UID – User Identifier) ​​w systemie, który można dalej traktować jako identyfikator właściciela nowo utworzonego pliku. Po drugie, każdy proces próbujący uzyskać dostęp do pliku ma powiązaną z nim parę identyfikatorów, identyfikatory bieżącego użytkownika i grupy. Po trzecie, każdy plik jednoznacznie odpowiada swojemu deskryptorowi - i-węzłowi.

Każdy i-węzeł używany w systemie plików zawsze jednoznacznie odpowiada jednemu i tylko jednemu plikowi. Węzeł I zawiera dość wiele różnych informacji (większość z nich jest dostępna dla użytkowników poprzez wywołania systemowe stat i fstat), a wśród tych informacji znajduje się część, która pozwala systemowi plików ocenić prawa dostępu danego procesu do danego pliku w wymaganym trybie.

Ogólne zasady ochrony są takie same dla wszystkich istniejących wariantów systemu: Informacje o i-węźle zawierają UID i GID obecnego właściciela pliku (zaraz po utworzeniu pliku identyfikatory jego obecnego właściciela są ustawiane na odpowiadający bieżący identyfikator procesu twórcy, ale może być później zmieniony przez wywołania systemowe chown i chgrp) . Ponadto i-węzeł pliku zawiera skalę, która wskazuje, co użytkownik - jego właściciel może zrobić z plikiem, co użytkownicy należący do tej samej grupy użytkowników co właściciel mogą zrobić z plikiem oraz co mogą zrobić inni użytkowników pliku. Drobne szczegóły implementacji w różnych wersjach systemu różnią się.

8.3 Przyszłe systemy operacyjne obsługujące środowisko UNIX OS

Mikrojądro to najmniejsza podstawowa część systemu operacyjnego, służąca jako podstawa rozszerzeń modułowych i przenośnych. Wygląda na to, że większość systemów operacyjnych nowej generacji będzie miała mikrojądra. Istnieje jednak wiele różnych opinii na temat tego, jak usługi systemu operacyjnego powinny być zorganizowane w odniesieniu do mikrojądra: jak zaprojektować sterowniki urządzeń tak, aby były jak najbardziej wydajne, ale jak najbardziej niezależne od sprzętu; czy operacje niezwiązane z jądrem powinny być wykonywane w przestrzeni jądra czy w przestrzeni użytkownika; czy warto zachować programy istniejących podsystemów (na przykład UNIX), czy lepiej wszystko wyrzucić i zacząć od zera.

Koncepcja mikrojądra została wprowadzona do szerokiego użytku przez firmę Next, której system operacyjny wykorzystywał mikrojądro Mach. Mały, uprzywilejowany rdzeń tego systemu operacyjnego, wokół którego działały podsystemy w trybie użytkownika, teoretycznie miał zapewniać niespotykaną elastyczność i modułowość systemu. Jednak w praktyce ta zaleta została nieco zdyskontowana przez obecność monolitycznego serwera, który implementuje system operacyjny UNIX BSD 4.3, który Next wybrał jako opakowanie mikrojądra Mach. Poleganie na Macha pozwoliło jednak na włączenie do systemu narzędzi do przesyłania wiadomości oraz szeregu obiektowych funkcji serwisowych, na podstawie których możliwe było stworzenie eleganckiego interfejsu użytkownika końcowego z graficznymi narzędziami do konfiguracji sieci, administrowania systemem i rozwój oprogramowania.

Kolejnym systemem operacyjnym z mikrojądrem był Microsoft Windows NT, w którym kluczową zaletą korzystania z mikrojądra miała być nie tylko modułowość, ale także przenośność. (Zauważ, że nie ma zgody co do tego, czy NT powinien być faktycznie uważany za system operacyjny z mikrojądrem). NT został zaprojektowany do użytku w systemach jedno- i wieloprocesorowych opartych na Procesory Intel, Mips i Alpha (i te, które przyjdą po nich). Ponieważ programy napisane dla systemów DOS, Windows, OS/2 i zgodnych z Posix musiały działać na NT, Microsoft wykorzystał nieodłączną modułowość podejścia mikrojądra do stworzenia ogólnej struktury NT, która nie naśladowała żadnego istniejącego systemu operacyjnego. Każdy system operacyjny jest emulowany jako oddzielny moduł lub podsystem.

Niedawno Novell/USL, Open Software Foundation (OSF), IBM, Apple i inne ogłosiły architekturę systemu operacyjnego z mikrojądrem. Jednym z głównych konkurentów NT w systemach operacyjnych z mikrojądrem jest Mach 3.0, system stworzony na Uniwersytecie Carnegie Mellon, który zarówno IBM, jak i OSF podjęły się komercjalizacji. (Next używa obecnie Mach 2.5 jako podstawy dla NextStep, ale także przygląda się uważnie Mach 3.0.) Innym konkurentem jest mikrojądro Chorus 3.0 Chorus Systems, wybrane przez USL jako podstawa dla nowych implementacji systemu operacyjnego UNIX. Niektóre mikrojądra będą używane w SpringOS firmy Sun, zorientowanym obiektowo następcy Solarisa (jeśli oczywiście Sun uzupełni SpringOS). Istnieje oczywisty trend w kierunku przejścia z systemów monolitycznych na systemy z mikrojądrem (ten proces nie jest prosty: IBM cofnął się o krok i zrezygnował z przejścia na technologię mikrojądra). Nawiasem mówiąc, nie jest to wcale nowość dla QNX Software Systems i Unisys, które od kilku lat wypuszczają udane systemy operacyjne z mikrojądrem. QNX OS jest poszukiwany na rynku czasu rzeczywistego, a system CTOS firmy Unisys jest popularny w bankowości. Oba systemy z powodzeniem wykorzystują modułowość właściwą dla systemów operacyjnych z mikrojądrem.

Wniosek

Główne różnice między Unixem a innymi systemami operacyjnymi

Unix składa się z jądra z dołączonymi sterownikami i narzędziami (programy zewnętrzne w stosunku do jądra). Jeśli potrzebujesz zmienić konfigurację (dodać urządzenie, zmienić port lub przerwanie), to jądro jest przebudowywane (ponownie łączone) z modułów obiektowych lub (na przykład we FreeBSD) ze źródeł. To nie do końca prawda. Niektóre parametry można poprawić bez przebudowy. Istnieją również ładowalne moduły jądra.

W przeciwieństwie do Uniksa, w Windows (jeśli nie jest określony który, to mamy na myśli 3.11, 95 i NT) i OS/2, podczas ładowania faktycznie łączą sterowniki w podróży. zmontowane jądro i ponowne użycie wspólnego kodu są o rząd wielkości mniejsze niż Ponadto, jeśli konfiguracja systemu pozostaje niezmieniona, jądro Unix może zostać zapisane w pamięci ROM i wykonane _nie_uruchomione_ do pamięci RAM bez przeróbek (wystarczy tylko zmienić początkową część BIOS) Zwartość kodu jest szczególnie ważna, ponieważ jądro i sterowniki nigdy nie opuszczają pamięci fizycznej nie są zamieniane na dysk.

Unix to najbardziej wieloplatformowy system operacyjny. WindowsNT próbuje go naśladować, ale jak dotąd nie udało się to - po porzuceniu MIPS i POWER-PC, W "NT pozostał na tylko dwóch platformach - tradycyjnej i*86 i DEC Alpha. Przenośność programów z jednej wersji Uniksa do innego jest ograniczone. Niestarannie napisany program, który nie bierze pod uwagę różnic w implementacjach uniksowych, przyjmuje nierozsądne założenia, takie jak „liczba całkowita musi mieć cztery bajty”, może wymagać poważnych przeróbek, ale nadal jest o wiele rzędów wielkości łatwiejszy niż przenoszenie z Na przykład od OS/2 do NT.

Zastosowania Uniksa

Unix jest używany zarówno jako serwer, jak i stacja robocza. W nominacji serwerów konkurują z nim systemy operacyjne MS WindowsNT, Novell Netware, IBM OS/2 Warp Connect, DEC VMS i mainframe. Każdy system ma swój obszar zastosowania, w którym jest lepszy od innych.

WindowsNT jest przeznaczony dla administratorów, którzy preferują przyjazny interfejs użytkownika od oszczędności zasobów i wysokiej wydajności.

Netware — dla sieci, w których potrzebne są wysokowydajne usługi plików i drukarek, a inne usługi nie są tak ważne. Główną wadą jest trudność uruchamiania aplikacji na serwerze Netware.

OS / 2 jest dobry tam, gdzie potrzebujesz „lekkiego” serwera aplikacji. Wymaga mniej zasobów niż NT, jest bardziej elastyczny w zarządzaniu (chociaż może być trudniejszy do skonfigurowania), a wielozadaniowość jest bardzo dobra. Autoryzacja i różnicowanie praw dostępu nie są realizowane na poziomie systemu operacyjnego, co z nawiązką opłaca się implementacją na poziomie serwerów aplikacji. (Jednak często inne systemy operacyjne robią to samo). Wiele stacji FIDOnet i BBS jest opartych na OS/2.

VMS jest potężnym, w niczym nie ustępującym Uniksowi (i pod wieloma względami lepszym od niego) serwerem aplikacji, ale tylko dla platform VAX i Alpha firmy DEC.

Mainframe - do obsługi bardzo dużej liczby użytkowników (rzędu kilku tysięcy). Ale praca tych użytkowników jest zwykle zorganizowana nie w formie interakcji klient-serwer, ale w formie host-terminal. Terminal w tej parze nie jest raczej klientem, lecz serwerem (Internet World, N3 za 1996 rok). Zaletami komputerów typu mainframe są większe bezpieczeństwo i odporność na awarie, a wadami odpowiadająca tym cechom cena.

Unix jest dobry dla wprawnego (lub chętnego do bycia) administratorem, ponieważ wymaga znajomości zasad funkcjonowania zachodzących w nim procesów. Prawdziwa wielozadaniowość i współdzielenie twardej pamięci zapewniają wysoką niezawodność systemu, chociaż wydajność usług plików i drukowania w systemie Unix jest gorsza niż w Netware.

Brak elastyczności w przyznawaniu użytkownikom praw dostępu do plików w porównaniu do WindowsNT utrudnia zorganizowanie grupowego dostępu do danych (a dokładniej do plików) na poziomie _na_systemie_plików_, co moim zdaniem jest niwelowane przez łatwość implementacji, czyli mniej sprzętu wymagania. Jednak aplikacje takie jak SQL Server same rozwiązują problem grupowego dostępu do danych, więc możliwość odmowy dostępu do _pliku_ konkretnemu użytkownikowi, której brakuje w Uniksie, jest moim zdaniem ewidentnie zbędna.

Prawie wszystkie protokoły, na których oparty jest Internet, zostały opracowane pod Uniksem, w szczególności stos protokołów TCP/IP został wynaleziony na Uniwersytecie Berkeley.

Bezpieczeństwo Uniksa, gdy jest właściwie administrowane (a kiedy nie jest?), w niczym nie ustępuje ani Novellowi, ani WindowsNT.

Ważną właściwością Unixa, która zbliża go do komputerów mainframe, jest jego wieloterminalowość, wielu użytkowników może jednocześnie uruchamiać programy na tej samej maszynie Unix. Jeśli nie musisz używać grafiki, możesz sobie poradzić z tanimi terminalami tekstowymi (specjalistycznymi lub opartymi na tanich komputerach PC) połączonymi wolnymi liniami. W tym konkuruje z nim tylko VMS. Graficzne terminale X mogą być również używane, gdy okna procesów uruchomionych na różnych komputerach znajdują się na tym samym ekranie.

W nominacji stacji roboczej Unix konkuruje z MS Windows*, IBM OS/2, Macintosh i Acorn RISC-OS.

Windows - dla tych, którzy cenią kompatybilność nad wydajność; dla tych, którzy są gotowi kupić dużą ilość pamięci, miejsca na dysku i megaherców; dla tych, którzy lubią nie zagłębiać się w esencję, kliknij przyciski w oknie. To prawda, prędzej czy później trzeba jeszcze przestudiować zasady systemu i protokoły, ale wtedy będzie za późno - wybór został dokonany. Ważną zaletą systemu Windows jest również możliwość kradzieży pakietów oprogramowania.

OS/2 - dla fanów OS/2. :-) Chociaż, według niektórych raportów, OS/2 lepiej niż inne współdziała z komputerami mainframe i sieciami IBM.

Macintosh - dla prac graficznych, wydawniczych i muzycznych, a także dla tych, którzy kochają przejrzysty, piękny interfejs i nie chcą (nie potrafią) zrozumieć szczegółów systemu.

RISC-OS, flashowany w pamięci ROM, pozwala nie tracić czasu na instalowanie systemu operacyjnego i przywracanie go po awariach. Ponadto prawie wszystkie programy w ramach tego programu wykorzystują zasoby bardzo ekonomicznie, dzięki czemu nie wymagają wymiany i działają bardzo szybko.

Unix działa zarówno na komputerach PC, jak i na potężnych stacjach roboczych z procesorami RISC, pod Uniksem napisane są naprawdę potężne systemy CAD i systemy informacji geograficznej. Według niektórych autorów skalowalność Unixa, ze względu na jego wieloplatformową naturę, jest o rząd wielkości przewyższająca jakikolwiek inny system operacyjny.

Bibliografia

1. Podręcznik Kuznetsova S.D. „System operacyjny UNIX” 2003;

2. Poliakow A.D. „UNIX 5th Edition na x86, albo nie zapomnij historii”;

3. Karpow D.Yu. "UNIX" 2005;

4. Fedorchuk A.V. Mistrzostwo Uniksa, 2006

5. Materiały na stronie http://www.citforum.ru/operating_systems/1-16;

MINISTERSTWO EDUKACJI I NAUKI FEDERACJI ROSYJSKIEJ FEDERALNA AGENCJA Oświaty PAŃSTWOWA INSTYTUCJA EDUKACYJNA WYŻSZEGO SZKOLNICTWA ZAWODOWEGO