Объяснение неспециалиста “Всего является файлом” — что отличается от Windows?

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

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

Но даже несмотря на то, что обычные сетевые сокеты TCP / IP создаются и управляются с помощью тех же системных вызовов BSD sockets , что и сокеты домена 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 , где вы можете читать из сетевого сокета с помощью общего системного вызова Unix read (2) или специфичного для сокета recv (2) call.²

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

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 форматирования. В Linux вам не нужно писать программу для доступа к функциям ОС «форматировать диск». Вы просто запускаете соответствующую программу пользовательского пространства для типа файловой системы, которую хотите создать: mkfs.ext4 , mkfs.xfs или что у вас есть. Эти программы будут записывать файловую систему в любой передаваемый вами файл или узел / dev .

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

$ 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 , который содержит моего пользователя / и т. Д. / 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, такие как \\ СЕРВЕР \ ПУТЬ \ FILE.TXT . Это потому, что это наращивание идей из Unix, CP / M , MS-DOS и LAN Manager , а не единой согласованной конструкции. Вот почему так много недопустимых символов в именах файлов Windows .

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

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

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

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

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

Я считаю, что справедливо отметить, что если бы Unix имел интегрированный ввод-вывод TCP / IP в файловую систему с самого начала, у нас не было бы netcat vs socat vs Ncat vs nc mess , Причиной этого была та же слабость в конструкции, которая привела к распространению инструментов создания образов и очистки дисков в Windows: отсутствие приемлемого средства ОС.

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

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

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

Тем не менее, отсутствие традиции командной строки имеет косвенные последствия. Вы получаете такие инструменты, как DISKPART , которые почти неизвестны в мире Windows, потому что большинство людей делают разделы диска и тому подобное с помощью оснастки Computer Management MMC.Затем, когда вам действительно нужно создать сценарий для создания разделов, вы обнаружите, что DISKPART на самом деле не был создан для управления другой программой. Да, вы можете записать серию команд в файл сценария и запустить его через файл сценария DISKPART / S , но это все или ничего. Что вы действительно хотите в такой ситуации, так это что-то вроде GNU parted , которое будет принимать отдельные команды вроде 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 и почти всегда жалуются на него: «Фу, это так примитивно!» Затем они ищут отладчик графического интерфейса, находят один из нескольких существующих и с радостью продолжают свою работу ... часто даже не осознавая, что графический интерфейс просто запускает gdb под ним, обеспечивая красивую оболочку поверх него. В большинстве систем Unix нет конкурирующих низкоуровневых отладчиков, потому что нет необходимости, чтобы программы конкурировали на этом уровне. Все, что нам нужно, - это один хороший низкоуровневый инструмент, на котором мы все можем основывать наши высокоуровневые инструменты, если этот низкоуровневый инструмент легко обменивается данными через каналы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если изменения в вашем реестре требуют какой-либо логики, следующий самый простой вариант - изучить PowerShell , что в основном сводится к изучению системного программирования .NET. Это было бы похоже на то, если бы в Unix был только 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 или проводника, Windows откажется его открыть, но вы можете записать в него через Cygwin, поскольку он открывает файлы с использованием методов, аналогичных приведенной в примере программы, и вы может удалить его с помощью аналогичной уловки .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. Man ed

9. Между прочим, дескрипторы сетевых сокетов также являются FD.