„Wszystko jest plikiem” to trochę glib. „Wszystko pojawia się gdzieś w systemie plików ” jest bliżej znaku, a nawet wtedy jest bardziej ideałem niż prawem projektowania systemu.
Na przykład gniazda domeny systemu Unix nie są plikami, ale pojawiają się w systemie plików. Możesz użyć ls -lgniazda domeny, aby wyświetlać jego atrybuty, catdane do / z jednego, modyfikować kontrolę dostępu za pośrednictwem chmoditp.
Ale mimo że zwykłe gniazda sieciowe TCP / IP są tworzone i manipulowane przy użyciu tych samych wywołań systemowych gniazd BSD , co gniazda domenowe w systemie Unix, gniazda TCP / IP nie pojawiają się w systemie plików, ¹ nawet jeśli nie ma szczególnie dobrego powodu, aby Mów prawdę.
Innym przykładem obiektów niebędących plikami pojawiających się w systemie plików jest Linuksa /procplików . Ta funkcja ujawnia dużą ilość szczegółów dotyczących działania jądra w przestrzeni użytkownika , głównie jako wirtualne pliki tekstowe. Wiele /procwpisów jest tylko do odczytu, ale wiele z nich /procjest również zapisywalnych, więc możesz zmienić sposób działania systemu za pomocą dowolnego programu, który może modyfikować plik. Niestety, tutaj znowu mamy nonideality: Unixy typu BSD generalnie działają bez/proc , a Unixy System V ujawniają o wiele mniej za pośrednictwem /procLinuksa.
Nie mogę kontrastować tego z MS Windows
Po pierwsze, wiele sentymentów, które można znaleźć w Internecie, a także w książkach o uniksowym podejściu do operacji we / wy plików i „pękaniu” systemu Windows pod tym względem, jest przestarzałe. Windows NT naprawił wiele z tego.
Nowoczesne wersje systemu Windows mają zunifikowany system we / wy, podobnie jak Unix, więc możesz czytać dane sieciowe z gniazda TCP / IP za pośrednictwem ReadFile()interfejsu API specyficznego dla Windows Sockets WSARecv(), jeśli chcesz. Dokładnie przypomina to Uniksowy Sposób , w którym można czytać z gniazda sieciowego za pomocą ogólnego read(2)wywołania systemowego Unix lub wywołania specyficznego dla gniazd recv(2).²
Niemniej jednak system Windows nadal nie przenosi tej koncepcji na ten sam poziom co Unix, nawet tutaj w 2018 roku. Istnieje wiele obszarów architektury Windows, do których nie można uzyskać dostępu za pośrednictwem systemu plików lub których nie można traktować jako plików. Kilka przykładów:
Kierowcy
Podsystem sterowników Windows jest tak bogaty i potężny jak Unix, ale aby pisać programy do manipulowania sterownikami, zazwyczaj musisz używać zestawu sterowników Windows , co oznacza pisanie kodu C lub .NET.
W systemach operacyjnych typu Unix można wiele zrobić ze sterownikami z wiersza poleceń. Prawie na pewno już to zrobiłeś, choćby przekierowując niechciane wyjście do /dev/null.³
Komunikacja między programami.
Programy Windows nie komunikują się ze sobą łatwo.
Programy wiersza poleceń systemu Unix komunikują się łatwo za pośrednictwem strumieni tekstowych i potoków. Programy GUI są często budowane na programach wiersza poleceń lub eksportują interfejs poleceń tekstowych, dzięki czemu te same proste mechanizmy komunikacji tekstowej działają również z programami GUI.
Rejestr
Unix nie ma bezpośredniego odpowiednika rejestru Windows. Te same informacje są rozproszone w systemie plików, większość w /etc, /proci /sys.
Jeśli nie widzisz, że sterowniki, potoki i odpowiedź Unixa na rejestr systemu Windows mają coś wspólnego z „wszystko jest plikiem”, czytaj dalej.
Jak zmienia się tutaj filozofia „Wszystko jest plikiem”?
Wyjaśnię to szczegółowo, omawiając moje trzy punkty powyżej.
Długa odpowiedź, część 1: Napędy a pliki urządzeń
Załóżmy, że Twój czytnik kart CF jest wyświetlany E:w systemie Windows i /dev/sdcLinux. Co to za praktyczna różnica?
Nie jest to tylko niewielka różnica w składni.
W systemie Linux mogę powiedzieć, dd if=/dev/zero of=/dev/sdcaby zastąpić zawartość /dev/sdczerami.
Zastanów się, co to znaczy przez chwilę. Tutaj mam normalny program w przestrzeni użytkownika ( dd(1)), do którego prosiłem o odczyt danych z urządzenia wirtualnego ( /dev/zero) i zapisanie tego, co odczytano na prawdziwym urządzeniu fizycznym ( /dev/sdc) poprzez zunifikowany system plików Unix. ddnie wie, że czyta i pisze na specjalnych urządzeniach. Działa równie dobrze na zwykłych plikach lub na mieszance urządzeń i plików, jak zobaczymy poniżej.
Nie ma łatwego sposobu na wyzerowanie E:dysku w systemie Windows, ponieważ system Windows rozróżnia pliki i dyski, więc nie można używać tych samych poleceń do manipulowania nimi. Najbliżej można zrobić format dysku bez opcji Szybkie formatowanie, która zeruje większość zawartości dysku, ale następnie zapisuje na nim nowy system plików. Co jeśli nie chcę nowego systemu plików? Co jeśli naprawdę chcę, aby dysk był zapełniony tylko zerami?
Bądźmy szczodrzy i powiedzmy, że naprawdę chcemy nowego systemu plików E:. Aby to zrobić w programie w systemie Windows, muszę wywołać specjalny interfejs API formatowania. ⁴ W systemie Linux nie trzeba pisać programu, aby uzyskać dostęp do funkcji „formatowania dysku” systemu operacyjnego. Wystarczy uruchomić odpowiedni program przestrzeni użytkownika dla danego typu systemu plików, który chcesz utworzyć: mkfs.ext4, mkfs.xfslub co ty. Programy te zapisują system plików na dowolnym /devprzekazywanym pliku lub węźle.
Ponieważ mkfsprogramy typu w systemach Unixy działają na plikach bez sztucznego rozróżniania urządzeń i normalnych plików, oznacza to, że mogę utworzyć system plików ext4 w normalnym pliku na moim Linux-ie:
$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs
To dosłownie tworzy obraz dysku 1 MiB w bieżącym katalogu o nazwie myfs. Następnie mogę zamontować go tak, jak gdyby był to inny zewnętrzny system plików:
$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint
Teraz mam obraz dysku ext4 z wywołanym plikiem my-passwd-entry, który zawiera wpis mojego użytkownika /etc/passwd.
Jeśli chcę, mogę wysadzić ten obraz na mojej karcie CF:
$ sudo dd if=myfs of=/dev/sdc1
Lub mogę spakować ten obraz dysku, wysłać go pocztą i pozwolić Ci napisać go na wybranym przez Ciebie nośniku , takim jak pamięć USB:
$ gzip myfs
$ echo "Here's the disk image I promised to send you." |
mutt -a myfs.gz -s "Password file disk image" you@example.com
Wszystko to jest możliwe w Linuksie, ponieważ nie ma sztucznego rozróżnienia między plikami, systemami plików i urządzeniami. Wiele rzeczy w systemach Unix albo są pliki, lub są dostępne za pośrednictwem systemu plików tak, że wyglądają jak pliki, lub w jakiś inny sposób spojrzenia na tyle plikopodobnym że mogą one być traktowane jako takie.
Koncepcja systemu plików dla systemu Windows to wielka zaleta; rozróżnia katalogi, dyski i zasoby sieciowe. Istnieją trzy różne składnie, wszystkie połączone w systemie Windows: uniksopodobny ..\FOO\BARsystem ścieżek, litery dysków podobne C:i ścieżki UNC jak \\SERVER\PATH\FILE.TXT. Jest tak, ponieważ jest to przyrost pomysłów z Uniksa, CP / M , MS-DOS i LAN Managera , a nie z jednego spójnego projektu. Dlatego w nazwach plików Windows jest tak wiele niedozwolonych znaków .
Unix ma zunifikowany system plików, do którego dostęp można uzyskać za pomocą jednego wspólnego schematu. Aby program uruchomiony na Linuksie, nie ma różnicy między funkcjonalne /etc/passwd, /media/CF_CARD/etc/passwdi /mnt/server/etc/passwd. Pliki lokalne, media zewnętrzne i udziały sieciowe są traktowane w ten sam sposób
Windows może osiągnąć podobne cele jak mój przykład obrazu dysku powyżej, ale musisz użyć specjalnych programów napisanych przez niezwykle utalentowanych programistów. Dlatego w systemie Windows jest tak wiele programów typu „wirtualny dysk DVD” . Brak podstawowej funkcji systemu operacyjnego stworzył sztuczny rynek dla programów, aby wypełnić lukę, co oznacza, że masz grupę ludzi konkurujących o stworzenie najlepszego programu typu wirtualnego DVD. Nie potrzebujemy takich programów w systemach * ix, ponieważ możemy po prostu zamontować obraz dysku ISO za pomocą urządzenia pętlowego .
To samo dotyczy innych narzędzi, takich jak programy do czyszczenia dysków , których nie potrzebujemy również w systemach Unix. Chcesz, aby zawartość Twojej karty CF była nieodwracalnie mieszana, a nie zerowana? Okej, użyj /dev/randomjako źródła danych zamiast /dev/zero:
$ sudo dd if=/dev/random of=/dev/sdc
W Linuksie nie wymyślamy na nowo takich kół, ponieważ podstawowe funkcje systemu operacyjnego działają nie tylko wystarczająco dobrze, ale działają tak dobrze, że są powszechnie stosowane. Typowy schemat uruchamiania systemu Linux obejmuje obraz dysku wirtualnego, na przykład, utworzony przy użyciu technik takich jak pokazałem powyżej.
Wydaje mi się słuszne, aby wskazać, że gdyby Unix zintegrował we / wy TCP / IP z systemem plików od samego początku, nie mielibyśmy bałaganunetcat vs socatvs Ncatvs , którego przyczyną była ta sama słabość projektowa proliferacja narzędzi do obrazowania i czyszczenia dysków w systemie Windows: brak akceptowalnej funkcji systemu operacyjnego.nc
Długa odpowiedź, część 2: Rury jako pliki wirtualne
Pomimo swoich korzeni w DOS, Windows nigdy nie miał bogatej tradycji wiersza poleceń.
Nie oznacza to, że system Windows nie ma wiersza polecenia lub brakuje wielu programów wiersza polecenia. Windows ma nawet bardzo potężną powłokę poleceń, odpowiednio zwaną PowerShell .
Istnieją jednak domniemane skutki tego braku tradycji wiersza poleceń. Dostajesz narzędzia, DISKPARTktóre są prawie nieznane w świecie Windows, ponieważ większość ludzi wykonuje partycjonowanie dysku i takie za pomocą przystawki programu Computer Management MMC. Następnie, kiedy trzeba wykonać skrypt tworzenia partycji, okazuje się, że DISKPARTnie był tak naprawdę stworzony do obsługi innego programu. Tak, możesz napisać serię poleceń do pliku skryptu i uruchomić go DISKPART /S scriptfile, ale to wszystko albo nic. Czego naprawdę chcą w takiej sytuacji jest czymś więcej jak GNUparted , który zaakceptuje pojedyncze polecenia jak parted /dev/sdb mklabel gpt. Dzięki temu skrypt może obsługiwać błędy krok po kroku.
Co to wszystko ma wspólnego z „wszystko jest plikiem”? Łatwość: potoki zamieniają we / wy program wiersza poleceń w „pliki”. Rury są strumieniami jednokierunkowymi , nie mają dostępu losowego jak zwykły plik na dysku, ale w wielu przypadkach różnica nie ma znaczenia. Ważne jest to, że możesz dołączyć dwa niezależnie opracowane programy i sprawić, by komunikowały się za pomocą prostego tekstu. W tym sensie mogą komunikować się dowolne dwa programy zaprojektowane z myślą o Uniksie .
W przypadkach, w których naprawdę potrzebujesz pliku, łatwo jest przekształcić dane wyjściowe programu w plik:
$ some-program --some --args > myfile
$ vi myfile
Ale po co zapisywać dane wyjściowe w pliku tymczasowym, skoro filozofia „wszystko jest plikiem” daje lepszy sposób? Jeśli wszystko, co chcesz zrobić, to wczytać dane wyjściowe tej komendy do vibufora edytora, vimożesz to zrobić bezpośrednio. W trybie vi„normalnym” powiedz:
:r !some-program --some --args
To wstawia dane wyjściowe tego programu do aktywnego bufora edytora w bieżącej pozycji kursora. Pod maską viużywa potoków, aby połączyć wyjście programu z bitem kodu, który używa tych samych wywołań systemu operacyjnego, których użyłby do odczytu z pliku. Nie zdziwiłbym się, gdyby dwa przypadki :r- to znaczy z i bez !- oba korzystały z tej samej ogólnej pętli odczytu danych we wszystkich typowych implementacjach vi. Nie mogę wymyślić dobrego powodu, aby tego nie robić.
To też nie jest ostatnia cecha vi; wraca do starożytnego ed(1)edytora tekstu
Ten potężny pomysł pojawia się wielokrotnie w Uniksie.
Jako drugi przykład tego przywołaj moje muttpolecenie e-mail powyżej. Jedynym powodem, dla którego musiałem napisać to jako dwie osobne komendy, jest to, że chciałem nazwać plik tymczasowy *.gz, aby załącznik e-mail był poprawnie nazwany. Gdybym nie dbał o nazwę pliku, mógłbym użyć podstawienia procesu, aby uniknąć utworzenia pliku tymczasowego:
$ echo "Here's the disk image I promised to send you." |
mutt -a <(gzip -c myfs) -s "Password file disk image" you@example.com
Pozwala to uniknąć tymczasowości, przekształcając dane wyjściowe gzip -cw plik FIFO (podobny do pliku) lub /dev/fdobiekt (podobny do pliku). (Bash wybiera metodę w oparciu o możliwości systemu, ponieważ /dev/fdnie jest dostępna wszędzie).
Po raz trzeci ten potężny pomysł pojawia się w Uniksie, rozważmy gdbw systemach Linux. Jest to debugger używany w każdym oprogramowaniu napisanym w C i C ++. Programiści przybywający do Unixa z innych systemów patrzą na to gdbi prawie niezmiennie się nią zajmują: „Fuj, to takie prymitywne!” Następnie szukają debugera GUI, znajdują jeden z kilku istniejących i z radością kontynuują pracę ... często nie zdając sobie sprawy, że GUI po prostu działa gdbpod spodem, zapewniając ładną powłokę. W większości systemów uniksowych nie ma konkurencyjnych debuggerów niskiego poziomu, ponieważ programy nie muszą konkurować na tym poziomie. Potrzebujemy tylko jednego dobrego narzędzia niskiego poziomu, na którym wszyscy możemy oprzeć nasze narzędzia wysokiego poziomu, jeśli to narzędzie niskiego poziomu łatwo komunikuje się za pośrednictwem rur.
Oznacza to, że mamy teraz udokumentowany interfejs debuggera, który umożliwiłby zastąpienie drop-in gdb, ale niestety główny konkurent gdb nie wybrał ścieżki o niskim współczynniku tarcia .
Nadal jednak możliwe jest, że niektóre przyszłe gdbzamiany wpadną w sposób przezroczysty po prostu poprzez klonowanie interfejsu wiersza poleceń. Aby wyciągnąć to samo z Windowsa, twórcy wymiennego narzędzia musieliby zdefiniować formalną wtyczkę lub API automatyzacji. Oznacza to, że tak się nie dzieje, z wyjątkiem najbardziej popularnych programów, ponieważ zbudowanie zarówno zwykłego interfejsu użytkownika wiersza poleceń, jak i pełnego interfejsu API programowania jest bardzo pracochłonne.
Ta magia dzieje się dzięki łasce wszechobecnego IPC opartego na tekście .
Chociaż jądro systemu Windows ma anonimowe potoki w stylu uniksowym , rzadko widuje się, że normalne programy użytkownika używają ich do IPC poza powłoką poleceń, ponieważ system Windows nie ma tradycji tworzenia wszystkich podstawowych usług w wersji wiersza poleceń, a następnie budowania GUI na na górze osobno. Prowadzi to do niemożności robienia pewnych rzeczy bez GUI, co jest jednym z powodów, dla których istnieje tak wiele systemów zdalnego pulpitu dla Windows, w porównaniu do Linuksa: Windows jest bardzo trudny w użyciu bez GUI.
Natomiast zdalne administrowanie urządzeniami Unix, BSD, OS X i Linux zdalnie odbywa się za pośrednictwem SSH. A jak to działa, pytasz? SSH łączy gniazdo sieciowe (podobne do pliku) z pseudo tty w /dev/pty*(podobnym do pliku). Teraz twój zdalny system jest podłączony do twojego lokalnego poprzez połączenie, które tak płynnie pasuje do Uniksowego sposobu, że możesz przesyłać dane przez połączenie SSH , jeśli to konieczne.
Czy zastanawiasz się, jak potężna jest teraz ta koncepcja?
Strumieniowy strumień tekstowy jest nie do odróżnienia z pliku z perspektywy programu, z wyjątkiem tego, że jest jednokierunkowy. Program czyta z potoku w taki sam sposób, jak czyta z pliku: poprzez deskryptor pliku . FD są absolutnie kluczowe dla Uniksa; fakt, że pliki i potoki używają tej samej abstrakcji dla I / O na obu, powinien ci coś powiedzieć
Świat Windows, pozbawiony tradycji prostej komunikacji tekstowej, radzi sobie z ciężkimi interfejsami OOP za pośrednictwem COM lub .NET . Jeśli chcesz zautomatyzować taki program, musisz także napisać program COM lub .NET. Jest to o wiele trudniejsze niż ustawienie potoku na pudełku uniksowym.
Programy systemu Windows pozbawione tych skomplikowanych interfejsów API programowania mogą komunikować się tylko przez zubożałe interfejsy, takie jak schowek lub File / Save, a następnie File / Open.
Długa odpowiedź, część 3: Rejestr a pliki konfiguracyjne
Praktyczna różnica między rejestrem systemu Windows a uniksowym sposobem konfiguracji systemu ilustruje również zalety filozofii „wszystko jest plikiem”.
W systemach typu Unix mogę przeglądać informacje o konfiguracji systemu z wiersza poleceń, po prostu sprawdzając pliki. Mogę zmienić zachowanie systemu, modyfikując te same pliki. W większości te pliki konfiguracyjne są zwykłymi plikami tekstowymi, co oznacza, że mogę używać dowolnego narzędzia w systemie Unix do manipulowania nimi, które mogą pracować z plikami zwykłego tekstu.
Skrypty rejestru nie są prawie tak łatwe w systemie Windows.
Najłatwiejszą metodą jest wprowadzenie zmian za pomocą interfejsu GUI Edytora rejestru na jednym komputerze, a następnie na ślepo zastosowanie tych zmian do innych komputerów za regeditpomocą *.regplików . To nie jest tak naprawdę „skryptowanie”, ponieważ nie pozwala ci robić niczego warunkowo: to wszystko albo nic.
Jeśli zmiany w rejestrze wymagają jakiejkolwiek logiki, następną najłatwiejszą opcją jest nauka programu PowerShell , co w zasadzie oznacza naukę programowania systemu .NET. To tak, jakby Unix posiadał tylko Perla i musiałeś za jego pośrednictwem wykonywać całą administrację systemu ad hoc . Teraz jestem fanem Perla, ale nie wszyscy są. Unix pozwala używać dowolnego narzędzia, które ci się podoba, pod warunkiem, że może ono manipulować zwykłymi plikami tekstowymi.
Przypisy:
Plan 9 stałe tej konstrukcji fałszywy krok, odsłaniając sieci / wy za pośrednictwem na /netwirtualnym plików .
Bash ma funkcję o nazwie,/dev/tcp która umożliwia sieciowe operacje we / wy za pośrednictwem zwykłych funkcji systemu plików. Ponieważ jest to funkcja Bash, a raczej jądro, nie jest widoczna poza Bash ani w systemach, które w ogóle nie używają Bash . Pokazuje to na przykładzie, dlaczego tak dobrym pomysłem jest, aby wszystkie zasoby danych były widoczne przez system plików.
Przez „nowoczesny system Windows” rozumiem system Windows NT i wszystkich jego bezpośrednich potomków, w tym Windows 2000, wszystkie wersje systemu Windows Server i wszystkie wersje systemu Windows dla komputerów stacjonarnych od XP. Używam tego terminu, aby wykluczyć wersje systemu Windows oparte na DOS, będące Windows 95 i jego bezpośrednimi potomkami, Windows 98 i Windows ME, a także ich 16-bitowymi poprzednikami.
Rozróżnienie można zobaczyć przez brak jednolitego systemu I / O w tych ostatnich systemach operacyjnych. Nie można przekazać gniazda TCP / IP do ReadFile()systemu Windows 95; możesz przesyłać tylko gniazda do interfejsów API Windows Sockets. Zobacz przełomowy artykuł Andrew Schulmana, Windows 95: Czego nie jest, aby głębiej zagłębić się w ten temat.
Nie popełnij błędu, /dev/nullto prawdziwe urządzenie jądra w systemach typu Unix, a nie tylko nazwa pliku w specjalnej obudowie, podobnie jak NULw Windowsie.
Chociaż system Windows próbuje uniemożliwić utworzenie NULpliku, można ominąć tę ochronę za pomocą zwykłych sztuczek , oszukując logikę analizy nazw plików systemu Windows. Jeśli spróbujesz uzyskać dostęp do tego pliku za pomocą cmd.exelub Eksploratora, system Windows odmówi otwarcia go, ale możesz napisać do niego za pomocą Cygwin, ponieważ otwiera pliki przy użyciu metod podobnych do programu przykładowego i możesz go usunąć za pomocą podobnych sztuczek .
Z drugiej strony, Unix z przyjemnością pozwoli ci rm /dev/null, o ile masz dostęp do zapisu /dev, i pozwoli ci odtworzyć nowy plik na swoim miejscu, wszystko to bez żadnych problemów, ponieważ ten węzeł deweloperski jest po prostu innym plikiem. Chociaż brakuje tego węzła deweloperskiego, zerowe urządzenie jądra nadal istnieje; jest po prostu niedostępny, dopóki nie odtworzysz węzła deweloperskiego za pośrednictwem mknod.
Możesz nawet utworzyć dodatkowe węzły deweloperskie urządzenia zerowego w innym miejscu: nie ma znaczenia, czy je nazwiesz /home/grandma/Recycle Bin, dopóki jest to węzeł deweloperski dla urządzenia zerowego, będzie działał dokładnie tak samo jak /dev/null.
W systemie Windows istnieją dwa interfejsy API „formatu dysku” wysokiego poziomu: SHFormatDrive()i Win32_Volume.Format().
Są dwa z bardzo ... cóż ... Windowsowego powodu. Pierwszy z nich prosi Eksploratora Windows o wyświetlenie jego normalnego okna dialogowego „Formatuj dysk”, co oznacza, że działa on na dowolnej nowoczesnej wersji systemu Windows, ale tylko wtedy, gdy użytkownik jest zalogowany interaktywnie. Drugi można wywołać w tle bez udziału użytkownika, ale nie został dodany do systemu Windows aż do Windows Server 2003. To prawda, podstawowe zachowanie systemu operacyjnego było ukryte za GUI do 2003 roku, w świecie, w którym Unix był dostarczany mkfs od pierwszego dnia .
Moja kopia systemu Unix V5 z 1974 r. Zawiera /etc/mkfs4136 bajtowy statycznie powiązany plik wykonywalny PDP-11 . (Unix nie otrzymał dynamicznego połączenia aż do późnych lat 80. , więc nie jest tak, że gdzieś indziej duża biblioteka wykonuje całą prawdziwą robotę.) Jej kod źródłowy - zawarty w obrazie systemu V5 jako /usr/source/s2/mkfs.c- jest całkowicie samodzielnym 457- program linii C. Nie ma nawet żadnych #includeoświadczeń!
Oznacza to, że możesz nie tylko badać, co mkfsrobi na wysokim poziomie, ale możesz eksperymentować z nim przy użyciu tego samego zestawu narzędzi, z którym utworzono Unix, podobnie jak ty Ken Thompson , cztery dekady temu. Wypróbuj to w systemie Windows. Najbliżej dzisiaj możesz pobrać kod źródłowy DOS , po raz pierwszy wydany w 2014 r. , Który stanowi zaledwie stos źródeł asemblera . Będzie budować tylko przy użyciu przestarzałych narzędzi, których prawdopodobnie nie będziesz mieć pod ręką, a na końcu otrzymasz własną kopię DOS 2.0, systemu operacyjnego znacznie mniej wydajnego niż Unix V5 z 1974 r. , Mimo że został wydany prawie dekadę później.
(Po co mówić o Unixie V5? Ponieważ jest to najwcześniejszy kompletny dostępny system uniksowy. Wcześniejsze wersje najwyraźniej straciły czas . Był projekt, który poskładał system uniksowy z czasów V1 / V2, ale wydaje się mkfs, że go brakuje , pomimo istnienia strony podręcznika V1, do której odsyłam powyżej, udowadniając, że gdzieś musi istnieć. Albo osoby składające ten projekt nie mogą znaleźć istniejącej kopii mkfsdo włączenia, albo mam ochotę znaleźć pliki, bez find(1)których nie ma również tego systemu . :))
Teraz możesz myśleć: „Czy nie mogę tak po prostu zadzwonić format.com? Czy to nie to samo w systemie Windows, co w systemie mkfsUnix?” Niestety, nie, to nie to samo, z wielu powodów:
Po pierwsze, format.comnie został zaprojektowany do skryptowania. Wyświetla monit o „naciśnięcie klawisza ENTER, gdy jest gotowy”, co oznacza, że musisz wysłać klawisz Enter do wejścia lub po prostu się zawiesi.
Następnie, jeśli chcesz czegoś więcej niż kod statusu powodzenia / niepowodzenia, musisz otworzyć jego standardowe wyjście do odczytu, co jest o wiele bardziej skomplikowane w systemie Windows niż powinno być . (W systemie Unix wszystko w tym linkowanym artykule można wykonać za pomocą prostego popen(3)wywołania.)
Po przejściu całej tej komplikacji, wynik format.comjest trudniejszy do przeanalizowania dla programów komputerowych niż wyjście mkfs, przeznaczone głównie do spożycia przez ludzi.
Jeśli prześledzić to, co format.comrobi, można zauważyć, że to robi kilka skomplikowanych połączeń do DeviceIoControl(), ufat.dlli takie. To nie jest po prostu otwarcie pliku urządzenia i zapisanie nowego systemu plików na tym urządzeniu. Tego rodzaju projekt otrzymujesz od firmy, która zatrudnia 126 000 osób i musi je nadal zatrudniać.
Mówiąc o urządzeniach pętlowych, mówię tylko o Linuksie, a nie o Uniksie, ponieważ urządzenia pętlowe nie są przenośne między systemami typu Unix. Istnieją podobne mechanizmy w OS X, BSD itp., Ale składnia jest nieco inna .
W czasach, gdy dyski były wielkości pralek i kosztowały więcej niż luksusowy samochód szefa działu, duże laboratoria komputerowe dzieliłyby większą część swojej łącznej przestrzeni dyskowej w porównaniu do nowoczesnych środowisk komputerowych. Możliwość przezroczystego zaszczepienia dysku zdalnego w lokalnym systemie plików znacznie ułatwiła korzystanie z takich systemów rozproszonych. /usr/shareNa przykład do tego dochodzimy .
W przeciwieństwie do systemu Windows, w którym dysk zdalny jest zwykle albo mapowany na literę dysku, albo musi być dostępny poprzez ścieżkę UNC, a nie zintegrowany z lokalnym systemem plików. Litery napędowe oferują niewiele możliwości wyrażenia symbolicznego; nie P:odnoszą się do „przestrzeni publicznej” na BigServer, albo „pakiety” katalogu na serwerze lustrzanym oprogramowanie? Ścieżki UNC oznaczają, że musisz pamiętać, na którym serwerze znajdują się Twoje zdalne pliki, co staje się trudne w dużej organizacji z setkami lub tysiącami serwerów plików.
Windows nie pojawił się dowiązań symbolicznych, dopóki system Windows Vista, wydany w 2007 roku, który wprowadził dowiązania symboliczne NTFS . Dowiązania symboliczne systemu Windows są nieco bardziej wydajne niż dowiązania symboliczne systemu Unix - cecha systemu Unix od 1977 r. - ponieważ mogą wskazywać również na zdalny udział plików, a nie tylko na ścieżkę lokalną. Unix zrobił to inaczej, poprzez NFS w 1984 r. , Który opiera się na istniejącej wcześniej uniksowej opcji montowania , którą miał od samego początku.
Tak więc, w zależności od tego, jak na to patrzysz, Windows podążał za Unixem przez około 2-3 dekady.
Nawet wtedy dowiązania symboliczne nie są normalną częścią doświadczenia użytkownika systemu Windows z kilku powodów.
Po pierwsze, można je tworzyć tylko za pomocą programu wiersza polecenia wsteczMKLINK . Nie można tworzyć je z Eksploratora Windows, natomiast odpowiedniki Unix Windows Explorer zazwyczaj nie pozwalają tworzyć dowiązania.
Po drugie, domyślna konfiguracja systemu Windows uniemożliwia zwykłym użytkownikom tworzenie dowiązań symbolicznych, wymagając, abyś albo uruchomił powłokę poleceń jako Administrator, albo zezwolił użytkownikowi na ich utworzenie za pomocą niejasnej ścieżki w narzędziu, którego przeciętny użytkownik nawet nie widział, a tym bardziej nie wie jak używać. (W przeciwieństwie do większości problemów z uprawnieniami administratora w systemie Windows, Kontrola konta użytkownika nie jest w tym przypadku pomocna.)
Linux-y nie zawsze używają obrazu dysku wirtualnego w sekwencji rozruchowej. Istnieje wiele różnych sposobów, aby to zrobić .
man ed
Nawiasem mówiąc, deskryptory gniazd sieciowych to także FD.