Если знать тему (подробности соответствующих системных вызовов в POSIX и ограничения ядра Windows), либо хорошо вникнуть, то это будет очевидно как 2+2. Иначе говоря, "пруфы" сводятся к поиску и сопоставлению фрагментов соответствующих RTFM. Но готовых ссылок на подобные пояснения у меня нет.
Если совсем кратко, то в спецификации NT и Win32 API, по принципу "назло бабушке уши отморожу", намерено закладывалось максимум отличий от POSIX. Некоторые отличия таковы, что их невозможно совместить при работе с одним объектом (файлом).
Даже если (вдруг, невзирая на риск регрессов, на сложность и объем доработок) M$ реализует в ядре обе семантики/спецификации, то файл открытый в Win32 уже нельзя будет открыть в xWSL, и наоборот. А вишенкой на торте будет производительность — т.е. файловые операции Linux будут работать с черепашьей скоростью NTFS и т.д.
Местами статья выглядит как ода технологиями Windows, большинство из которых никогда не тянули на пафос "подвиг архитектурной мысли и реальной программной разработки" (посмешило, конечно).
Посему ниже несколько колких уточнений.
Подсистема должна была стать совсем другой, но фактически вышел провал, в каком-то смысле.
Не в каком-то, а в прямом смысле — провал относительно исходных целей.
Причем специалистам это было более-менее понятно сразу (NTFS проще выкинуть чем ускорить, а некоторые вещи невозможно совместить принципиально). WSL1 не может (и не сможет) обеспечить весь функционал Linux из-за фундаментальных ограничений ядра NT. Какие-то вещи (например clone/fork) были реализованы, но многое не возможно (уменьшение mmap-секций, блокировка файлов и т.д.).
сначала взглянем на WSL 1, и первым делом — на её странное название. Почему эта функция называется подсистемой Windows… для Linux?
Потому-что такова конечная цель (WSL3). Тут стоит отметить что поверх ядра Linux точно возможно реализовать NT API (aka Native API), обеспечить работу подсистемы Win32, работу USB и NDIS-драйверов, и даже части других нативных драйверов. Но неизбежно "отвалятся" драйверы дисков, все завязанное на внутренний кошмар NTFS и внутренности win32.sys, с массой неизбежных регрессов из-за нарушения совместимости (в том числе и ожидаемыми Windows-багами). Поэтому интеграция на уровне виртуализации (WSL2) выглядит разумным переходным решением.
Windows NT разработана с нуля для поддержки процессов, запущенных из множества операционных систем, а Win32 был «просто» одной из этих подсистем окружения.
Это было ~30 лет назад в эпоху Windows NT 3.51. Начиная с Windows NT 4.0 подсистема Win32 потекла в ядро, а начиная с Windows 2000 ядро NT стало уродливым мутантом — уже менее гибким, потенциально уязвимым и небезопасным, но еще не быстрым. Буквально к исходной NT-архитектуре (далеко не идеальной, но более-менее строгой) Win32-говно прибили палками.
Стоит отметить, что 20-30 лет назад модульность ядра NT (деление на подсистемы со стабильными API, стабильный API для драйверов, идеи IRP-стека для интеграции драйверов и даже NDIS) выглядели очень здравыми и перспективными. Но на деле всё это постепенно стало профанацией и маркетинговым трепом. Де-факто воплощение идей обернулось кошмаром:
подсистемы не изолированы, а сплетены в клубок, взаимосвязанность зашкаливает, их невозможно развивать, заменять и/или использовать по-отдельности.
актуальная стабильность ядерных API и ABI не гарантирует совместимости между версиями даже на уровне исходного кода драйверов.
комбинаторная сложность не позволяет проверять релизы (корень эпических сбоев после обновлений) из-за огромного зоопарка версий драйверов у пользователей, исходный код которых вне какого-либо централизованного контроля и code review.
Тут напрашивается премия Дарвина, а не эпитеты типа "подвиг архитектурной мысли и реальной программной разработки" ;)
А там разве какие-то специалисты показали что-то конкретное или (опять, как всегда) только слова?
Хотелось-бы хоть раз, хоть одним глазком, увидеть критерии и/или логические выводы по которым делается отсылка к "помощи государства" и к России в частности.
Но китайцы действительно пару раз были молодцы: раздели/одели, удалили гланды и теперь по-желаю показательно пасут црушников ;)
Не хотелось чтобы вы воспринимали мой комментарий негативно.
Напротив, я считаю обязательно необходимым уметь самостоятельно разрабатывать и собирать "велосипеды". Но при этом не менее важно пользоваться крестовой отверткой для шурупов, а не только забивать их самодельными молотками.
Поэтому, искренне советую повторить решение используя связку re2c + lemon и озвучить впечатление в продолжении этой статьи.
если вселенная бесконечна, то сможем ли мы всегда найти соответствие между двумерным срезом её некой функциональной проекции и некой произвольной плоской картинкой?
а если конечна?
а если с выполнением ОТО (время всегда "не моментально" и не локально)?
а если картина в кубитах и картинка не-монохромная (но с плоской геометрией)?
ну хорошо, а если картинка не плоская, то до скольки измерений найдем?
Если уж пишите, то перепроверяйте и будьте точны, включая детали и картинки.
Иначе кроме википедии появиться еще один слой узаконивания ошибок (преимущественно исторических).
Камрады, начинание хорошее, но пожалуйста сорожнее.
Одно дело, когда отучившиеся ничего сломать не могут — это хорошо.
Но плохо когда они собираются что-то защищать и с полной уверенностью дают гарантии недопонимающим админам и руководителям, а после еще и переходят на реально ответственные позиции.
Александр, есть ещё "нюансы". Рекомендую покопаться в аналогичной по тематике правоприменительной практике США (да, нужно постараться) и после этого обратить внимание на исключения позволяемые/налагаемые другими законами (особенно для не-граждан США).
Вам должно зайти ;)
Проходил мимо, дискутировать не буду (ибо RTFM)
Советую устроиться в M$, поможете им быстрее отмучиться ;)
Если многократно натягивать технологии на бизнес, то либо бизнес сожмется, либо технологии лопнут — M$ с Windows демонстрирует оба варианта.
А безумство+отвага с clone/fork в M$ будут помнить еще долго, от того и "планы у бизнеса поменялись" ;)
Как говорится нормальные герои всегда идут в обход ;)
Если знать тему (подробности соответствующих системных вызовов в POSIX и ограничения ядра Windows), либо хорошо вникнуть, то это будет очевидно как 2+2. Иначе говоря, "пруфы" сводятся к поиску и сопоставлению фрагментов соответствующих RTFM. Но готовых ссылок на подобные пояснения у меня нет.
Если совсем кратко, то в спецификации NT и Win32 API, по принципу "назло бабушке уши отморожу", намерено закладывалось максимум отличий от POSIX. Некоторые отличия таковы, что их невозможно совместить при работе с одним объектом (файлом).
Даже если (вдруг, невзирая на риск регрессов, на сложность и объем доработок) M$ реализует в ядре обе семантики/спецификации, то файл открытый в Win32 уже нельзя будет открыть в xWSL, и наоборот. А вишенкой на торте будет производительность — т.е. файловые операции Linux будут работать с черепашьей скоростью NTFS и т.д.
Местами статья выглядит как ода технологиями Windows, большинство из которых никогда не тянули на пафос "подвиг архитектурной мысли и реальной программной разработки" (посмешило, конечно).
Посему ниже несколько колких уточнений.
Не в каком-то, а в прямом смысле — провал относительно исходных целей.
Причем специалистам это было более-менее понятно сразу (NTFS проще выкинуть чем ускорить, а некоторые вещи невозможно совместить принципиально). WSL1 не может (и не сможет) обеспечить весь функционал Linux из-за фундаментальных ограничений ядра NT. Какие-то вещи (например clone/fork) были реализованы, но многое не возможно (уменьшение mmap-секций, блокировка файлов и т.д.).
Потому-что такова конечная цель (WSL3). Тут стоит отметить что поверх ядра Linux точно возможно реализовать NT API (aka Native API), обеспечить работу подсистемы Win32, работу USB и NDIS-драйверов, и даже части других нативных драйверов. Но неизбежно "отвалятся" драйверы дисков, все завязанное на внутренний кошмар NTFS и внутренности win32.sys, с массой неизбежных регрессов из-за нарушения совместимости (в том числе и ожидаемыми Windows-багами). Поэтому интеграция на уровне виртуализации (WSL2) выглядит разумным переходным решением.
Это было ~30 лет назад в эпоху Windows NT 3.51. Начиная с Windows NT 4.0 подсистема Win32 потекла в ядро, а начиная с Windows 2000 ядро NT стало уродливым мутантом — уже менее гибким, потенциально уязвимым и небезопасным, но еще не быстрым. Буквально к исходной NT-архитектуре (далеко не идеальной, но более-менее строгой) Win32-говно прибили палками.
Стоит отметить, что 20-30 лет назад модульность ядра NT (деление на подсистемы со стабильными API, стабильный API для драйверов, идеи IRP-стека для интеграции драйверов и даже NDIS) выглядели очень здравыми и перспективными. Но на деле всё это постепенно стало профанацией и маркетинговым трепом. Де-факто воплощение идей обернулось кошмаром:
Тут напрашивается премия Дарвина, а не эпитеты типа "подвиг архитектурной мысли и реальной программной разработки" ;)
Недоперемордор.
А там разве какие-то специалисты показали что-то конкретное или (опять, как всегда) только слова?
Хотелось-бы хоть раз, хоть одним глазком, увидеть критерии и/или логические выводы по которым делается отсылка к "помощи государства" и к России в частности.
Но китайцы действительно пару раз были молодцы: раздели/одели, удалили гланды и теперь по-желаю показательно пасут црушников ;)
Не хотелось чтобы вы воспринимали мой комментарий негативно.
Напротив, я считаю обязательно необходимым уметь самостоятельно разрабатывать и собирать "велосипеды". Но при этом не менее важно пользоваться крестовой отверткой для шурупов, а не только забивать их самодельными молотками.
Поэтому, искренне советую повторить решение используя связку
re2c+lemonи озвучить впечатление в продолжении этой статьи.Ну-ну…
;)
В ногу со временем, в ногу стрелять вовремя!
Ну конечно, а если чуть усложнить:
С меня "пиво" за каждый верный ответ при встрече.
Если уж пишите, то перепроверяйте и будьте точны, включая детали и картинки.
Иначе кроме википедии появиться еще один слой узаконивания ошибок (преимущественно исторических).
"Пучина эксплуатации" (на КДПВ) — ну, прям Хорошо, ободряю!
Камрады, начинание хорошее, но пожалуйста сорожнее.
Одно дело, когда отучившиеся ничего сломать не могут — это хорошо.
Но плохо когда они собираются что-то защищать и с полной уверенностью дают гарантии недопонимающим админам и руководителям, а после еще и переходят на реально ответственные позиции.
Вот теперь возьмите
re2c+lemon, повторите и покайтесь ;)Ага, особенно присвоение в массивах ;)
Хм, зачем тут кошмар ASN.1?
Точнее WTF?
Кек.
Эти спалились раз 10 и еще почти год назад дали денег на открытие новых )
Александр, есть ещё "нюансы". Рекомендую покопаться в аналогичной по тематике правоприменительной практике США (да, нужно постараться) и после этого обратить внимание на исключения позволяемые/налагаемые другими законами (особенно для не-граждан США).
Вам должно зайти ;)
Проходил мимо, дискутировать не буду (ибо RTFM)
Примерно да, этот "прорыв" от McAfee ради хайпа, ибо сливают.
Достаточно использовать хорошие системы распознавания. Например, Белорусские.