Объяснение непрофессионала «Все есть файл» - что отличается от Windows?

Я знаю, что «Все является файлом» означает, что даже устройства имеют свое имя и путь в Unix и Unix-подобных системах, и это позволяет использовать общие инструменты на различных ресурсах независимо от их природы. Но я не могу сравнить это с Windows, единственной другой ОС, с которой я работал. Я прочитал несколько статей о концепции, но я думаю, что их непросто понять не-разработчикам. Объяснение непрофессионала - то, что нужно людям!

Например, когда я хочу скопировать файл на CF-карту, которая прикреплена к кард-ридеру, я буду использовать что-то вроде

zcat name_of_file > /dev/sdb

В Windows, я думаю, кард-ридер появится как драйвер, и мы сделаем что-то подобное, я думаю. Итак, как философия «Все это файл» имеет значение здесь?

«Все это файл» - немного бойкий. «Все появляется где-то в файловой системе » ближе к цели, и даже в этом случае это скорее идеал, чем закон проектирования системы.

Например, доменные сокеты Unix не являются файлами, но они появляются в файловой системе. Вы можете ls -lв доменном сокете отображать его атрибуты, catданные в / из одного, изменять его управление доступом через chmodи т. Д.

Но, хотя обычные сетевые сокеты TCP / IP создаются и управляются теми же системными вызовами сокетов BSD , что и доменные сокеты Unix, сокеты TCP / IP не отображаются в файловой системе, даже если нет особенно веской причины, по которой это следует делать будь настоящим.

Другой пример объектов нефайловых , входящих в файловой систему Linux в /procфайловой системе . Эта функция предоставляет большое количество подробностей о работе ядра в пользовательском пространстве , в основном в виде виртуальных текстовых файлов. Многие /procзаписи доступны только для чтения, но многие из /procних также доступны для записи, поэтому вы можете изменить способ работы системы, используя любую программу, которая может изменить файл. Увы, и здесь у нас опять есть неидеальность: Unix-системы типа BSD обычно работают без/proc , а Unix-ы System V предоставляют гораздо меньше возможностей, /procчем Linux.

Я не могу противопоставить это MS Windows

Во-первых, большая часть мнений, которые вы можете найти в Интернете и в книгах о том, что Unix полностью посвящен файловому вводу-выводу, а Windows «сломана» в этом отношении, устарела. Windows NT исправил многое из этого.

Современные версии Windows имеют унифицированную систему ввода-вывода, как и Unix, поэтому вы можете при желании читать сетевые данные из сокета TCP / IP, ReadFile()а не через специальный API-интерфейс Windows Sockets WSARecv(). Это в точности совпадает с Unix Way , где вы можете читать из сетевого сокета либо с помощью общего read(2)системного вызова Unix, либо с помощью вызова, специфичного для recv(2)сокетов.

Тем не менее, Windows по-прежнему не может перенести эту концепцию на тот же уровень, что и Unix, даже здесь, в 2018 году. Существует много областей архитектуры Windows, к которым нельзя получить доступ через файловую систему или которые нельзя рассматривать как файловые. Некоторые примеры:

1. Драйверы.

   Подсистема драйверов Windows так же богата и мощна, как и Unix, но для написания программ для работы с драйверами вам, как правило, приходится использовать Windows Driver Kit , что означает написание кода на C или .NET.

   В операционных системах типа Unix вы можете многое сделать для драйверов из командной строки. Вы почти наверняка уже сделали это, хотя бы перенаправив нежелательный вывод на /dev/null.³

2. Межпрограммное общение.

   Программы Windows не легко общаются друг с другом.

   Программы командной строки Unix легко общаются через текстовые потоки и каналы. Программы с графическим интерфейсом часто либо создаются поверх программ командной строки, либо экспортируют текстовый командный интерфейс, так что те же простые текстовые механизмы связи работают и с программами с графическим интерфейсом.

3. Реестр.

   Unix не имеет прямого эквивалента реестра Windows. Та же самая информация разбросана по файловой системе, большая ее часть /etc- /procи /sys.

Если вы не видите, что драйверы, каналы и ответ Unix на реестр Windows имеют какое-либо отношение к «все является файлом», продолжайте читать.

Как философия «Все в файле» имеет значение здесь?

Я объясню это, подробно остановившись на моих трех пунктах выше.

Длинный ответ, часть 1: Диски против файлов устройств

Допустим, ваш считыватель CF-карт выглядит как E:под Windows и /dev/sdcпод Linux. Какая практическая разница это имеет?

Это не просто небольшая разница в синтаксисе.

В Linux я могу сказать, dd if=/dev/zero of=/dev/sdcчтобы перезаписать содержимое /dev/sdcс нулями.

Подумайте, что это значит на секунду. Здесь у меня есть обычная программа пользовательского пространства ( dd(1)), которую я просил прочитать данные с виртуального устройства ( /dev/zero) и записать то, что они считывают, в реальное физическое устройство ( /dev/sdc) через унифицированную файловую систему Unix. ddне знает, что читает и пишет на специальные устройства. Он будет работать как с обычными файлами, так и с различными устройствами и файлами, как мы увидим ниже.

В E:Windows нет простого способа обнуления диска, потому что Windows различает файлы и диски, поэтому вы не можете использовать одни и те же команды для управления ими. Самое близкое, что вы можете получить, - это выполнить форматирование диска без опции «Быстрое форматирование», которая обнуляет большую часть содержимого диска, но затем записывает новую файловую систему поверх него. Что если я не хочу новую файловую систему? Что если я действительно хочу, чтобы диск был заполнен только нулями?

Давайте будем щедрыми и скажем, что нам действительно нужна новая файловая система E:. Чтобы сделать это в программе для Windows, мне нужно вызвать специальный API форматирования. Need В Linux вам не нужно писать программу для доступа к функциональности ОС «форматировать диск». Вы просто запустить соответствующую программу пользовательского пространства для типа файловой системы вы хотите создать: mkfs.ext4, mkfs.xfsили что у вас. Эти программы будут записывать файловую систему в любой файл или /devузел, который вы передаете.

Поскольку mkfsпрограммы типов в системах Unixy работают с файлами, не делая искусственных различий между устройствами и обычными файлами, это означает, что я могу создать файловую систему ext4 внутри обычного файла на моем компьютере с Linux:

$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs

Это буквально создает образ диска размером 1 МБ в текущем каталоге с именем myfs. Затем я могу смонтировать его, как если бы это была любая другая внешняя файловая система:

$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint

Теперь у меня есть образ диска ext4 с вызванным файлом, my-passwd-entryкоторый содержит /etc/passwdзапись моего пользователя .

Если я хочу, я могу вставить это изображение в свою CF-карту:

$ sudo dd if=myfs of=/dev/sdc1

Или я могу упаковать этот образ диска, отправить его вам по почте и позволить записать его на носитель по вашему выбору, например на карту памяти 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

Все это возможно в Linux⁵, потому что нет искусственного различия между файлами, файловыми системами и устройствами. Многие вещи в системах Unix либо являются файлами, либо доступны через файловую систему, так что они выглядят как файлы, или каким-то другим образом выглядят достаточно файлово-подобными, чтобы к ним можно было обращаться как таковым.

Концепция файловой системы в Windows - мешанина; это делает различия между каталогами, дисками и сетевыми ресурсами. Существует три разных синтаксиса, все смешанные вместе в Windows: Unix-подобная ..\FOO\BARсистема путей, буквы дисков C:и UNC-пути \\SERVER\PATH\FILE.TXT. Это связано с тем, что это скорее идеи Unix, CP / M , MS-DOS и LAN Manager , а не единый целостный дизайн. Именно поэтому в именах файлов Windows так много недопустимых символов .

Unix имеет унифицированную файловую систему, где все доступно по единой общей схеме. К программе , работающей на коробке Linux, нет функциональной разницы между /etc/passwd, /media/CF_CARD/etc/passwdи /mnt/server/etc/passwd. Локальные файлы, внешние носители и общие сетевые ресурсы обрабатываются одинаково.

Windows может достичь таких же целей, как в примере с моим образом диска выше, но вы должны использовать специальные программы, написанные необычайно талантливыми программистами. Вот почему в Windows так много программ типа «виртуальный DVD» . Отсутствие основной функции ОС создало искусственный рынок для программ, чтобы заполнить этот пробел, а это означает, что у вас есть группа людей, борющихся за создание лучшей программы виртуального типа DVD. Нам не нужны такие программы в системах * ix, потому что мы можем просто смонтировать образ диска ISO с помощью устройства петли .

То же самое относится и к другим инструментам, таким как программы очистки дисков , которые нам также не нужны в системах Unix. Хотите, чтобы содержимое вашей CF-карты безвозвратно шифровалось, а не просто обнулялось? Хорошо, используйте /dev/randomв качестве источника данных вместо /dev/zero:

$ sudo dd if=/dev/random of=/dev/sdc

В Linux мы не изобретаем такие колеса, потому что основные функции ОС не только работают достаточно хорошо, они работают настолько хорошо, что используются повсеместно. Типичная схема загрузки Linux-бокса включает образ виртуального диска, только для одного примера, созданного с использованием техник, которые я показываю выше.

Я чувствую, что было бы справедливо отметить, что, если бы Unix с самого начала интегрировал ввод / вывод TCP / IP в файловую систему, у нас не было бы беспорядкаnetcat vs socatvs Ncatvs , причиной которого была та же слабость дизайна, которая приводила к Распространение инструментов для создания образов и очистки дисков в Windows: отсутствие приемлемых возможностей ОС.nc

Длинный ответ, часть 2: Трубы как виртуальные файлы

Несмотря на свои корни в DOS, Windows никогда не имела богатых традиций командной строки.

Это не означает, что Windows не имеет командной строки или что ей не хватает многих программ командной строки. В наши дни в Windows даже есть очень мощная командная оболочка, которая называется PowerShell .

Тем не менее, есть и другие последствия этого отсутствия традиции командной строки. Вы получаете такие инструменты, DISKPARTкоторые практически неизвестны в мире Windows, потому что большинство людей выполняют разбиение диска и тому подобное с помощью оснастки MMC «Управление компьютером». Затем, когда вам нужно написать сценарий создания разделов, вы обнаружите, что DISKPARTон не был создан для управления другой программой. Да, вы можете записать серию команд в файл сценария и выполнить его через DISKPART /S scriptfile, но это все или ничего. Что вам действительно нужно в такой ситуации, так это нечто большее, чем GNUparted , которое будет принимать такие отдельные команды, как parted /dev/sdb mklabel gpt. Это позволяет вашему сценарию выполнять пошаговую обработку ошибок.

Какое все это имеет отношение к "все это файл"? Легко: каналы делают программный ввод / вывод в командной строке своего рода «файлами». Каналы представляют собой однонаправленные потоки , а не произвольный доступ, как обычный файл на диске, но во многих случаях разница не имеет значения. Важно то, что вы можете прикрепить две независимо разработанные программы и заставить их общаться с помощью простого текста. В этом смысле любые две программы, разработанные с учетом Unix Way, могут общаться.

В тех случаях, когда вам действительно нужен файл, легко превратить вывод программы в файл:

$ some-program --some --args > myfile
$ vi myfile

Но зачем записывать вывод во временный файл, когда философия «все - файл» дает вам лучший способ? Если все, что вы хотите сделать, это прочитать вывод этой команды в viбуфер редактора, viможете сделать это непосредственно для вас. Из vi«нормального» режима скажите:

:r !some-program --some --args

Это вставляет вывод этой программы в активный буфер редактора в текущей позиции курсора. Под этим подразумевается viиспользование каналов для соединения вывода программы с небольшим количеством кода, который использует те же вызовы ОС, которые он использовал бы для чтения из файла. Я не удивлюсь, если два случая :r- то есть с и без !- оба используют один и тот же общий цикл чтения данных во всех распространенных реализациях vi. Я не могу придумать вескую причину, чтобы этого не делать.

Это не недавняя особенность vi, либо; все ясно возвращается к древнему ed(1)текстовому редактору.

Эта мощная идея снова и снова появляется в Unix.

Для второго примера, вспомните мою muttкоманду электронной почты выше. Единственная причина, по которой мне пришлось написать это в виде двух отдельных команд, заключается в том, что я хотел, чтобы временный файл был назван *.gzтак, чтобы вложение электронной почты было правильно названо. Если бы меня не волновало имя файла, я мог бы использовать подстановку процесса, чтобы избежать создания временного файла:

$ echo "Here's the disk image I promised to send you." | 
  mutt -a <(gzip -c myfs) -s "Password file disk image" you@example.com

Это позволяет избежать временного gzip -cпреобразования, превратив вывод в FIFO (который является файловым) или /dev/fdобъект (который является файловым). (Bash выбирает метод на основе возможностей системы, поскольку /dev/fdдоступен не везде.)

Еще один третий способ, которым эта мощная идея появляется в Unix, рассмотрим gdbв системах Linux. Это отладчик, используемый для любого программного обеспечения, написанного на C и C ++. Программисты, приходящие в Unix из других систем, смотрят на это gdbи почти всегда жалуются на это: «Тьфу, это так примитивно!» Затем они ищут отладчик с графическим интерфейсом, находят один из нескольких, которые существуют, и с радостью продолжают свою работу ... часто даже не понимая, что GUI просто работает gdbпод ним, создавая симпатичную оболочку поверх него. В большинстве систем Unix нет конкурирующих низкоуровневых отладчиков, поскольку нет необходимости конкурировать с программами на этом уровне. Все, что нам нужно, - это один хороший инструмент низкого уровня, на котором мы все можем основывать наши инструменты высокого уровня, если этот инструмент низкого уровня легко взаимодействует через каналы.

Это означает, что теперь у нас есть документированный интерфейс отладчика, который позволял бы заменять их gdb, но, к сожалению, основной конкурент gdb не пошел по пути с низким коэффициентом трения .

Тем не менее, по крайней мере возможно, что какая-то gdbзамена в будущем будет прозрачной, просто путем клонирования интерфейса командной строки. Чтобы осуществить то же самое в Windows, создателям заменяемого инструмента пришлось бы определить какой-то формальный плагин или API автоматизации. Это означает, что этого не произойдет, за исключением самых популярных программ, потому что много работы по созданию как обычного пользовательского интерфейса командной строки, так и полного API программирования.

Эта магия происходит благодаря благодати всепроникающего текстового IPC .

Хотя в ядре Windows есть анонимные каналы в стиле Unix, обычные пользовательские программы редко используют их для IPC вне командной оболочки, поскольку в Windows отсутствует традиция сначала создавать все основные сервисы в версии командной строки, а затем строить графический интерфейс на Вершина этого отдельно. Это приводит к невозможности сделать некоторые вещи без графического интерфейса, что является одной из причин, по которой существует так много систем удаленных рабочих столов для Windows по сравнению с Linux: Windows очень трудно использовать без графического интерфейса.

В отличие от этого, обычно удаленно администрировать Unix, BSD, OS X и Linux, удаленно через SSH. И как это работает, спросите вы? SSH соединяет сетевой сокет (который похож на файл) с псевдотерминалом at /dev/pty*(который похож на файл). Теперь ваша удаленная система подключена к локальной через соединение, которое настолько легко соответствует Unix Way, что вы можете при необходимости передавать данные через SSH-соединение .

Вы получаете представление о том, насколько мощна эта концепция сейчас?

Потоковый текстовый поток неотличим от файла с точки зрения программы, за исключением того, что он является однонаправленным. Программа читает из канала так же, как читает из файла: через дескриптор файла . FD абсолютно необходимы для Unix; тот факт, что файлы и каналы используют одну и ту же абстракцию для ввода-вывода в обоих, должен вам кое-что сказать.

Мир Windows, лишенный этой традиции простых текстовых коммуникаций, обходится тяжелыми интерфейсами ООП через COM или .NET . Если вам нужно автоматизировать такую ​​программу, вы также должны написать программу COM или .NET. Это немного сложнее, чем настроить конвейер на Unix-сервере.

Программы Windows, в которых отсутствуют эти сложные программные API, могут обмениваться данными только через обедневшие интерфейсы, такие как буфер обмена или Файл / Сохранить, а затем Файл / Открыть.

Длинный ответ, часть 3: Реестр и файлы конфигурации

Практическое различие между реестром Windows и Unix Way в конфигурации системы также иллюстрирует преимущества философии «все в одном файле».

В системах типа Unix я могу просматривать информацию о конфигурации системы из командной строки, просто просматривая файлы. Я могу изменить поведение системы, изменив те же файлы. По большей части эти файлы конфигурации являются просто текстовыми файлами, что означает, что я могу использовать любой инструмент в Unix для манипулирования ими, который может работать с простыми текстовыми файлами.

Сценарии реестра не так просто в Windows.

Самый простой способ - внести изменения с помощью графического интерфейса редактора реестра на одном компьютере, а затем слепо применить эти изменения к другим компьютерам с regeditпомощью *.regфайлов . Это на самом деле не «сценарий», поскольку он не позволяет вам делать что-либо условно: все или ничего.

Если изменения в вашем реестре требуют какой-либо логики, следующим простым способом является изучение PowerShell , что в основном сводится к изучению системного программирования .NET. Было бы , как если бы Un была только Perl, и вы должны были сделать все Специальное администрирование системы через него. Теперь я фанат Perl, но не все. Unix позволяет вам использовать любой инструмент, который вам нравится, если он может манипулировать текстовыми файлами.

Примечания:

1. План 9 фиксированной конструкция этого неверный шаг, подвергая сеть ввод / вывод с помощью в /netвиртуальной файловой системе .

   Bash имеет функцию,/dev/tcp которая позволяет сетевой ввод / вывод через обычные функции файловой системы. Поскольку это функция Bash, а не функция ядра, она не видна за пределами Bash или в системах, которые вообще не используют Bash . Контрпример, это показывает, почему такая хорошая идея сделать все ресурсы данных видимыми через файловую систему.

2. Под «современной Windows» я подразумеваю Windows NT и всех ее прямых потомков, включая Windows 2000, все версии Windows Server и все ориентированные на десктоп версии Windows начиная с XP. Я использую этот термин, чтобы исключить версии Windows для DOS: Windows 95 и ее прямые потомки, Windows 98 и Windows ME, а также их 16-разрядные предшественники.

   Вы можете увидеть различие по отсутствию единой системы ввода-вывода в этих последних ОС. Вы не можете передать сокет TCP / IP в ReadFile()Windows 95; вы можете только передавать сокеты в API Windows Sockets. См. Основополагающую статью Эндрю Шульмана « Windows 95: что не так» для более глубокого погружения в эту тему.

3. Не заблуждайтесь, /dev/nullэто настоящее устройство ядра в системах типа Unix, а не просто специальное имя файла, как внешне эквивалентно NULв Windows.

   Хотя Windows пытается помешать вам создать NULфайл, эту защиту можно обойти с помощью простой хитрости , обманывая логику разбора имени файла Windows. Если вы попытаетесь получить доступ к этому файлу с помощью cmd.exeили Explorer, Windows откажется открывать его, но вы можете записать в него через Cygwin, так как он открывает файлы, используя методы, аналогичные примеру программы, и вы можете удалить его с помощью аналогичного трюка .

   В отличие от этого, Unix с радостью предоставит вам rm /dev/null, если у вас есть доступ для записи /dev, и позволит вам воссоздать новый файл на его месте, и все это без хитрости, потому что этот узел разработки - это просто другой файл. Пока этот узел разработки отсутствует, нулевое устройство ядра все еще существует; это просто недоступно до тех пор, пока вы не создадите узел dev через mknod.

   Вы даже можете создать дополнительные узлы dev для нулевого устройства в другом месте: не имеет значения, если вы его называете /home/grandma/Recycle Bin, если это узел dev для нулевого устройства, он будет работать точно так же, как и /dev/null.

4. На самом деле в Windows есть два высокоуровневых API «форматирования диска»: SHFormatDrive()и Win32_Volume.Format().

   Их два по очень ... ну ... Windows- причине. В первом из них Windows Explorer отображает свое обычное диалоговое окно «Форматировать диск», что означает, что он работает в любой современной версии Windows, но только когда пользователь вошел в систему в интерактивном режиме. Другой вы можете вызывать в фоновом режиме без ввода данных пользователем, но он не был добавлен в Windows до Windows Server 2003. Это верно, поведение основной ОС было скрыто за графическим интерфейсом до 2003 года, в мире, где Unix поставлялся mkfs с первого дня .

   Моя копия Unix V5 от 1974 года включает исполняемый файл PDP-11 со/etc/mkfs статической связью 4136 байт . (Unix не получал динамическое связывание до конца 1980-х годов , поэтому не похоже, что где-то еще есть большая библиотека, выполняющая всю настоящую работу.) Его исходный код, включенный в образ системы V5 как, является полностью автономным. программа линии C. Там даже нет никаких заявлений!/usr/source/s2/mkfs.c#include

   Это означает, что вы можете не только исследовать то, что mkfsпроисходит на высоком уровне, вы можете экспериментировать с ним, используя тот же набор инструментов, с которым был создан Unix, так же, как вы, Кен Томпсон , четыре десятилетия назад. Попробуйте это с Windows. Самое близкое , к чему вы можете прийти сегодня, - это загрузить исходный код DOS , впервые выпущенный в 2014 году , который, как вы обнаружите, составляет всего лишь кучу исходных кодов сборки . Он будет собираться только с устаревшими инструментами, которых у вас, вероятно, не будет под рукой, и в итоге вы получите свою собственную копию DOS 2.0, ОС, намного менее мощную, чем Unix V5 1974 года , несмотря на то, что она была выпущена почти десятилетие спустя.

   (Зачем говорить о Unix V5? Потому что это самая ранняя полная система Unix, доступная до сих пор. Ранние версии, по- видимому, утеряны во времени . Был проект, который объединил Unix эпохи V1 / V2, но, похоже, отсутствует mkfs, несмотря на существование на странице руководства V1, на которую ссылаются выше, доказывая, что она где-то когда-то существовала. Либо те, кто собирают этот проект, не могут найти существующую копию mkfsдля включения, либо мне не хватает, чтобы найти файлы без find(1), чего также нет в этой системе . :))

   Теперь вы можете подумать: «Разве я не могу просто позвонить format.com? Разве это не то же самое в Windows, что и вызов mkfsв Unix?» Увы, нет, это не то же самое по нескольким причинам:

   • Во-первых, format.comне предназначен для сценариев. Он предлагает вам «нажать ENTER, когда будет готов», что означает, что вам нужно отправить клавишу ввода на его ввод, или он просто зависнет.

   • Затем, если вам нужно что-то большее, чем код состояния успеха / сбоя, вы должны открыть его стандартный вывод для чтения, который в Windows намного сложнее, чем должен быть . (В Unix все в этой связанной статье можно выполнить простым popen(3)вызовом.)

   • Пройдя через все это усложнение, выходные данные format.comдля компьютерных программ труднее анализировать, чем выходные данные mkfs, предназначенные главным образом для потребления человеком.

   • Если проследить , что format.comделает, вы обнаружите , что она делает кучу сложных вызовов DeviceIoControl(), ufat.dllи тому подобное. Это не просто открытие файла устройства и запись новой файловой системы на это устройство. Это тот тип дизайна, который вы получаете от компании, в которой работают 126 000 человек , и им необходимо продолжать их использовать.

5. Говоря о петлевых устройствах, я говорю только о Linux, а не Unix в целом, потому что петлевые устройства не переносимы между системами типа Unix. Есть аналогичные механизмы в OS X, BSD и т. Д., Но синтаксис несколько варьируется .

6. В те времена, когда дисководы были размером со стиральные машины и стоили дороже, чем роскошный автомобиль начальника отдела, большие компьютерные лаборатории разделяли бы большую часть своего общего дискового пространства по сравнению с современными вычислительными средами. Возможность прозрачного внедрения удаленного диска в локальную файловую систему сделала такие распределенные системы намного проще в использовании. Вот где мы /usr/share, например.

   В отличие от Windows, где удаленный диск обычно либо сопоставляется с буквой диска, либо к нему нужно обращаться по пути UNC, а не прозрачно интегрировать в локальную файловую систему. Буквы дисков предлагают вам несколько вариантов символического выражения; это P:относится к «общественности» пространства на BigServer, или в «пакеты» каталог на сервере программного обеспечения зеркала? UNC-пути означают, что вы должны помнить, на каком сервере находятся ваши удаленные файлы, что сложно в большой организации с сотнями или тысячами файловых серверов.

   Windows не получала символические ссылки до выпуска Windows Vista, выпущенной в 2007 году, в которой были представлены символические ссылки NTFS . Символические ссылки Windows немного более мощные, чем символические ссылки Unix - функция Unix с 1977 года - в том, что они могут также указывать на удаленный общий файловый ресурс, а не только на локальный путь. Unix сделал это по-другому, через NFS в 1984 году , которая основывается на ранее существовавшей в Unix функции точки монтирования , которая была у него с самого начала.

   Таким образом, в зависимости от того, как вы на это смотрите, Windows отставала от Unix примерно на 2 или 3 десятилетия.

   Даже в этом случае символические ссылки не являются обычной частью работы пользователя Windows по нескольким причинам.

   Во-первых, вы можете создавать их только с помощью обратной программы командной строки MKLINK. Вы не можете создать их из проводника Windows, в то время как эквиваленты Unix в Windows Explorer , как правило , действительно позволяют создавать символические ссылки.

   Во-вторых, конфигурация Windows по умолчанию не позволяет обычным пользователям создавать символические ссылки, требуя, чтобы вы либо запустили командную оболочку от имени администратора, либо дали пользователю разрешение на их создание по неясному пути в инструменте, который ваш обычный пользователь никогда даже не видел, а тем более знает как использовать. (И в отличие от большинства проблем с привилегиями администратора в Windows, UAC в этом случае не поможет.)

7. Linux-боксы не всегда используют образ виртуального диска в последовательности загрузки. Есть куча разных способов сделать это .

8. man ed

9. Кстати, дескрипторы сетевых сокетов - это FD.

Если вы считаете , Linuxкак английский язык , то file systemsявляются алфавитов , которые в основном блоки фундаментные для английского языка .

Со страницы вики файловой системы,

В вычислениях файловая система (или файловая система) используется для управления тем, как данные хранятся и извлекаются. Без файловой системы информация, помещаемая в область хранения, была бы одним большим массивом данных без возможности определить, где останавливается один фрагмент информации и начинается следующий.

Таким образом, с точки зрения непрофессионала без правильной языковой структуры для английского языка (который составлен из алфавитов), человеческое взаимодействие не будет иметь никакого смысла. Точно так же без файловых систем любые данные, которые мы имеем в базовом устройстве хранения, не будут иметь реального смысла.