Не так давно при разработке фильтра файловых систем возникла проблема, которая приводила к подвисанию всей системы. Казалось бы, фильтр выполнял очень простые действия и сам был очень примитивным. Чтобы выяснить причину, пришлось спуститься до отладки и реверс-инжиниринга драйвера NTFS. Анализ выявил очень интересный эффект. Если скомпилировать и выполнить очень простую программу, изображенную на рисунке ниже, то доступ к соответствующему тому подвиснет.
Т.е. в данном примере, если попытаться открыть любой файл относительно файла $mft, доступ ко всему тому «С» повиснет, а так как этот том является системным, подвиснет и вся система. При этом не нужно иметь каких-либо прав. Если же том был не системным, то повиснет только доступ к этому тому, но если выполнить перезагрузку, то система повиснет на ней.
Прежде чем описать суть проблемы, стоит рассмотреть базовые принципы построения файловых систем. Когда некий процесс открывает файл, кроме полученного HANDLE на него, в пространстве ядра также формируются структуры, как самим ядром, так и файловой системой, которые, по сути, представляют файл тома в памяти. Ниже на рисунке изображены эти структуры.
HANDLE файла всегда ссылается на структуру ядра FILE_OBJECT. Эта структура формируется ядром перед посылкой запроса файловой системе. Файловая система, в свою очередь, инициализирует поля этой структуры. Таким образом, структура FILE_OBJECT будет содержать указатели на структуры файловой системы: FCB (File control block, содержит все необходимые данные для управления файлом) и CCB (Context Control Block, содержит данные, уникальные для конкретного открытого экземпляра). Также не исключено, что два разных HANDLE будут ссылаться на один и тот же файл тома, как это отражено слева. Структура FCB содержит список всех структур CCB. Структура CCB содержит указатель на соответствующую FCB. Т.е. для каждого открытого файла тома в памяти будет ровно одна структура FCB. Если файл открыт несколько раз, то также будет сформировано ровно столько CCB структур, сколько раз был открыт соответствующий файл, и все эти структуры будут ссылаться на единственную FCB структуру.
Поскольку доступ к файлу может выполняться одновременно разными или одним и тем же процессом, то эти параллельные операции должны быть сериализованы. При этом допустимо, что некоторые операции будут выполняться одновременно (например, чтение), однако существуют ситуации, когда доступ должен выполняться монопольно (например, запись). Для этого ядро предоставляет механизм сериализации – ERESOURCE. Этот объект может быть захвачен как монопольно, так и разделяемо. Если объект захвачен монопольно, тогда любые попытки захватить его встанут в очередь ожидания. Если объект захвачен разделяемо, тогда попытки также захватить его разделяемо будут удовлетворены немедленно. Если же объект захвачен разделяемо и очередь ожидания не пуста (т.е. была попытка монопольного захвата), тогда любые попытки захватить его встанут в очередь ожидания.
Структуры FCB файловых систем для сериализации доступа содержат эти механизмы и активно пользуются ими во время доступа к файлу. Таким образом обеспечивается целостность файла как в памяти, так и на томе.
Файл $mft файловой системы NTFS является системным. Этот файл описывает расположение всех файлов на томе. NTFS при монтировании открывает его для личного использования. При попытке прочитать содержимое директории или во время открытия файла NTFS выполнит чтение файла $mft. При любой попытке удалить файл или создать файл NTFS выполнит запись в этот файл. Следовательно, перед любой такой операцией механизм ERESOURCE этого файла также будет захвачен, затем будет выполнена сама операция, после чего механизм будет освобожден.
Чтобы понять суть проблемы, необходимо понимать принцип работы функции NtfsCommonCreate файловой системы NTFS. Очень упрощенный псевдокод изображен ниже на рисунке. Приведены только те части функции, которые имеют прямое отношение к проблеме.
Файловая система NTFS хранит дерево уже открытых файлов/директорий. Поэтому целесообразно в целях повышения производительности найти целевой файл в этом дереве вместо многократного чтения тома. Следовательно, функция посредством функции NtfsFindStartingNode попытается найти его. Если же найти файл не удалось, тогда функция попытается найти директорию, в которой он располагается. Эта попытка будет выполняться вплоть до корня файловой системы. Функция NtfsFindStartingNode возвращает указатель на структуру FCB либо самого файла, либо той директории, которая по глубине ближе всех располагается к целевому файлу. Функция также вернет часть необработанного пути относительно найденной директории. Также функция предварительно захватывает ERESOURCE найденной директории или файла разделяемо.
Далее функция NtfsCommonCreate проверяет, есть ли часть необработанного пути, если нет — значит функция NtfsFindStartingNode нашла сам файл, и в таком случае работа функции NtfsCommonCreate завершается. В противном случае функция продолжает поиск файла, но уже на томе.
Как видно из псевдокода, функция содержит цикл, в котором последовательно открываются директории, ведущие к файлу. В начале работы цикла проверяется, является ли файл директорией, и если нет, тогда работа функции завершается с ошибкой. В противном случае извлекается следующее имя в пути и выполняется попытка открыть файл/директорию с таким именем посредством функции NtfsOpenSubdirectory. Функция NtfsOpenSubdirectory также захватывает открытый файл/директорию монопольно. Перед вызовом функции NtfsOpenSubdirectory также освобождается предыдущая открытая директория функцией NtfsOpenSubdirectory. Работа цикла будет продолжаться до директории, в которой будет располагаться предполагаемый файл.
По окончании своей работы в случае неуспешного завершения функция NtfsCommonCreate закроет последнюю найденную директорию посредством функции NtfsTeardownStructures. Также эта функция освободит ERESOURCE директории/файла, если это возможно. Т.е. если эта директория/файл не являются открытыми. Т.к. эта директория/файл были открыты файловой системой только что, вероятнее всего, что их ERESOURCE будет освобожден, а FCB файла будет закрыт.
Когда будет произведена попытка открыть файл относительно файла $mft, функция NtfsFindStartingNode не найдет его, т.к. эта функция выполняет поиск несколько иначе, в отличие от функции NtfsOpenSubdirectory, которая находит этот файл всегда. Следовательно, начнет работу цикл, начиная с корня файловой системы. Далее функция NtfsOpenSubdirectory откроет этот файл и захватит его ERESOURCE монопольно. На следующей итерации цикл обнаружит, что файл не является директорией, и, следовательно, прервет свою работу с ошибкой. А при завершении своей работы функция NtfsCommonCreate посредством функции NtfsTeardownStructures попытается закрыть его. Функция NtfsTeardownStructures, в свою очередь, столкнется с тем, что она не сможет закрыть файл, т.к. он открывается самой файловой системой при монтировании. При этом, вопреки ожиданиям функции NtfsCommonCreate, функция NtfsTeardownStructures не освободит ERESOURCE $mft файла. Таким образом, он останется захваченным навсегда. Поэтому, например, при попытке создания файла или чтения файлов тома, файловая система NTFS попытается захватить ERESOURCE $mft файла и зависнет на этом этапе навсегда.
Данную проблему нельзя назвать уязвимостью, но имея удаленный доступ к машине, возможно нарушить ее работу. Данная ошибка сохраняется вплоть до последних версий Windows, за исключением последних обновлений, начиная как минимум с Windows Vista. Как уже упоминалось, описание работы файловой системы NTFS в этом случае является очень упрощенным и отражает только саму суть проблемы. В действительности реализация намного сложнее приведенного описания.
Т.е. в данном примере, если попытаться открыть любой файл относительно файла $mft, доступ ко всему тому «С» повиснет, а так как этот том является системным, подвиснет и вся система. При этом не нужно иметь каких-либо прав. Если же том был не системным, то повиснет только доступ к этому тому, но если выполнить перезагрузку, то система повиснет на ней.
Немного теории
Прежде чем описать суть проблемы, стоит рассмотреть базовые принципы построения файловых систем. Когда некий процесс открывает файл, кроме полученного HANDLE на него, в пространстве ядра также формируются структуры, как самим ядром, так и файловой системой, которые, по сути, представляют файл тома в памяти. Ниже на рисунке изображены эти структуры.
HANDLE файла всегда ссылается на структуру ядра FILE_OBJECT. Эта структура формируется ядром перед посылкой запроса файловой системе. Файловая система, в свою очередь, инициализирует поля этой структуры. Таким образом, структура FILE_OBJECT будет содержать указатели на структуры файловой системы: FCB (File control block, содержит все необходимые данные для управления файлом) и CCB (Context Control Block, содержит данные, уникальные для конкретного открытого экземпляра). Также не исключено, что два разных HANDLE будут ссылаться на один и тот же файл тома, как это отражено слева. Структура FCB содержит список всех структур CCB. Структура CCB содержит указатель на соответствующую FCB. Т.е. для каждого открытого файла тома в памяти будет ровно одна структура FCB. Если файл открыт несколько раз, то также будет сформировано ровно столько CCB структур, сколько раз был открыт соответствующий файл, и все эти структуры будут ссылаться на единственную FCB структуру.
Поскольку доступ к файлу может выполняться одновременно разными или одним и тем же процессом, то эти параллельные операции должны быть сериализованы. При этом допустимо, что некоторые операции будут выполняться одновременно (например, чтение), однако существуют ситуации, когда доступ должен выполняться монопольно (например, запись). Для этого ядро предоставляет механизм сериализации – ERESOURCE. Этот объект может быть захвачен как монопольно, так и разделяемо. Если объект захвачен монопольно, тогда любые попытки захватить его встанут в очередь ожидания. Если объект захвачен разделяемо, тогда попытки также захватить его разделяемо будут удовлетворены немедленно. Если же объект захвачен разделяемо и очередь ожидания не пуста (т.е. была попытка монопольного захвата), тогда любые попытки захватить его встанут в очередь ожидания.
Структуры FCB файловых систем для сериализации доступа содержат эти механизмы и активно пользуются ими во время доступа к файлу. Таким образом обеспечивается целостность файла как в памяти, так и на томе.
Файл $mft файловой системы NTFS является системным. Этот файл описывает расположение всех файлов на томе. NTFS при монтировании открывает его для личного использования. При попытке прочитать содержимое директории или во время открытия файла NTFS выполнит чтение файла $mft. При любой попытке удалить файл или создать файл NTFS выполнит запись в этот файл. Следовательно, перед любой такой операцией механизм ERESOURCE этого файла также будет захвачен, затем будет выполнена сама операция, после чего механизм будет освобожден.
Функция NtfsCommonCreate
Чтобы понять суть проблемы, необходимо понимать принцип работы функции NtfsCommonCreate файловой системы NTFS. Очень упрощенный псевдокод изображен ниже на рисунке. Приведены только те части функции, которые имеют прямое отношение к проблеме.
Файловая система NTFS хранит дерево уже открытых файлов/директорий. Поэтому целесообразно в целях повышения производительности найти целевой файл в этом дереве вместо многократного чтения тома. Следовательно, функция посредством функции NtfsFindStartingNode попытается найти его. Если же найти файл не удалось, тогда функция попытается найти директорию, в которой он располагается. Эта попытка будет выполняться вплоть до корня файловой системы. Функция NtfsFindStartingNode возвращает указатель на структуру FCB либо самого файла, либо той директории, которая по глубине ближе всех располагается к целевому файлу. Функция также вернет часть необработанного пути относительно найденной директории. Также функция предварительно захватывает ERESOURCE найденной директории или файла разделяемо.
Далее функция NtfsCommonCreate проверяет, есть ли часть необработанного пути, если нет — значит функция NtfsFindStartingNode нашла сам файл, и в таком случае работа функции NtfsCommonCreate завершается. В противном случае функция продолжает поиск файла, но уже на томе.
Как видно из псевдокода, функция содержит цикл, в котором последовательно открываются директории, ведущие к файлу. В начале работы цикла проверяется, является ли файл директорией, и если нет, тогда работа функции завершается с ошибкой. В противном случае извлекается следующее имя в пути и выполняется попытка открыть файл/директорию с таким именем посредством функции NtfsOpenSubdirectory. Функция NtfsOpenSubdirectory также захватывает открытый файл/директорию монопольно. Перед вызовом функции NtfsOpenSubdirectory также освобождается предыдущая открытая директория функцией NtfsOpenSubdirectory. Работа цикла будет продолжаться до директории, в которой будет располагаться предполагаемый файл.
По окончании своей работы в случае неуспешного завершения функция NtfsCommonCreate закроет последнюю найденную директорию посредством функции NtfsTeardownStructures. Также эта функция освободит ERESOURCE директории/файла, если это возможно. Т.е. если эта директория/файл не являются открытыми. Т.к. эта директория/файл были открыты файловой системой только что, вероятнее всего, что их ERESOURCE будет освобожден, а FCB файла будет закрыт.
Суть проблемы
Когда будет произведена попытка открыть файл относительно файла $mft, функция NtfsFindStartingNode не найдет его, т.к. эта функция выполняет поиск несколько иначе, в отличие от функции NtfsOpenSubdirectory, которая находит этот файл всегда. Следовательно, начнет работу цикл, начиная с корня файловой системы. Далее функция NtfsOpenSubdirectory откроет этот файл и захватит его ERESOURCE монопольно. На следующей итерации цикл обнаружит, что файл не является директорией, и, следовательно, прервет свою работу с ошибкой. А при завершении своей работы функция NtfsCommonCreate посредством функции NtfsTeardownStructures попытается закрыть его. Функция NtfsTeardownStructures, в свою очередь, столкнется с тем, что она не сможет закрыть файл, т.к. он открывается самой файловой системой при монтировании. При этом, вопреки ожиданиям функции NtfsCommonCreate, функция NtfsTeardownStructures не освободит ERESOURCE $mft файла. Таким образом, он останется захваченным навсегда. Поэтому, например, при попытке создания файла или чтения файлов тома, файловая система NTFS попытается захватить ERESOURCE $mft файла и зависнет на этом этапе навсегда.
Заключение
Данную проблему нельзя назвать уязвимостью, но имея удаленный доступ к машине, возможно нарушить ее работу. Данная ошибка сохраняется вплоть до последних версий Windows, за исключением последних обновлений, начиная как минимум с Windows Vista. Как уже упоминалось, описание работы файловой системы NTFS в этом случае является очень упрощенным и отражает только саму суть проблемы. В действительности реализация намного сложнее приведенного описания.
Поделиться с друзьями
lovecraft
Пусть простит меня сообщество за холиварную тему, но все-таки…
Вопрос открытых или не открытых исходных кодов ОС — это вещь первостепенная. Сколько литров кофе потратили сотрудники компании во время реверс-инжиниринга, сколько нервных клеток пало в неравной борьбе с плохо протестированным кодом? И все равно пофиксить эту уязвимость типа «отказ в обслуживании» своими силами нельзя — исходников нет, и даже если написать свой фильтр-драйвер и проверять все вызовы NtCreateFile, то для такого драйвера нужна подпись Майкрософт, а она есть не у всех.
Если бы исходники были открыты, достаточно было бы взять отладчик, поставить брейкпоинт, заменить пару строчек, пересобрать модуль и готово.
anatolymik
В теории да. На практике мы имеем дело с тем, что проекты с открытым исходным кодом часто содержат ошибки, которые опытный разработчик никогда не допустит. Например, также имею опыт и с Linux. Для серверов и построения устройств на его базе — незаменимая вещь. Для desktop решений, говоря примитивно, ад. Т.к. сильно не хватает механизмов, которые есть в Windows. Везде есть как плюсы, так и минусы. Не соглашусь с тем, что однозначно можно утверждать, что открытые исходные коды, явный плюс.
andreymal
В проприетарном ПО всё то же самое, только мы этого не видим, потому что код закрытый, ваш кэп :)
А неготовность линукса для десктопа связана не с открытостью, а с бесплатностью (даже какому-нибудь каноникалу не хватает ресурсов, в первую очередь денег на программистов, чтоб исправить всё и сразу) (хотя можно сказать, что бесплатность это следствие открытости, но вроде не всё так просто)
anatolymik
Не видим, но есть ряд косвенных признаков. Также, теперь можно ознакомиться с WRK v1.2. И попытаться сравнить. Дело не только в отсутствии механизмов, но еще в том, что если они присутствуют, какое у них качество.
MacIn
Кроме того, исходники минимум двух версий утекли в сеть. За WRK — плюс.
sumanai
Эти исходники весьма неполные, если что.
MacIn
Одной из версий — да.
sumanai
Да вроде обоих. NT4 ещё со скрипом компилируют, дописав пачку кода, а вот W2000 уже никак, не хватает пары подсистем.
MacIn
А, ну как посмотреть, да. Я имел в виду, что кода достаточно для понимания, как что работает.
lovecraft
Но я ведь и не писал, что Linux лучше Widows и не сравнивал функционал. Я писал, что продукты с открытым кодом имеют преимущества перед закрытыми, когда речь идет о быстром исправлении ошибок малой командой разработчиков.
anatolymik
Я их тоже не сравнивал. Как я говорил, и там и там есть как плюсы, так и минусы. На счет преимущества, как показывает практика, это не добавляет скорости разработки. Опять же, от случаю к случаю. Важно понимать что все мы имеем в той или иной степени, разный опыт. И в первую очередь я рассказываю о своем.
daggert
> Я писал, что продукты с открытым кодом имеют преимущества перед закрытыми, когда речь идет о быстром исправлении ошибок малой командой разработчиков.
Некоторые баги в открытом ПО висят десятилетиями… В винде не лучше, но в свободном ПО очень часто бывает «вам надо — вы и делайте».
grossws
Эта позиция всё же оказывается чуть лучше и понятнее чем "вам надо — ждите, держитесь там и всё такое".
Всё же разработчик open source решения ничего не должен конечному пользователю (хотя и с коммерческими, если почитать лицензию, ситуация примерно такая же, но вы ещё и деньги платите). Но хотя бы есть шанс, что если проблема задевает не только вас, то кто-нибудь когда-нибудь может её решить. Или можно кому-нибудь заплатить за решение этой проблемы, как вариант.
daggert
Я с вами соглашусь. Просто хотел сказать что открытый код != гарантированное исправление ошибок.
mva
Зато открытый код — наличие возможности У ВАС ЛИЧНО при наличии навыков исправить проблему "здесь и сейчас".
Вот возьмём две ситуации:
Slack и Telegram.
В первом меня очень расстраивал баг, заключавшийся в том, что при нажатии Alt+Shift открывалось меню (Alt) и выбирался фиг пойми какой пункт (или, рандомно, никакой, но при быстром машинальном переключении раскладки во время печати, когда успеваешь напечатать полтора слова прежде, чем от глаз к рукам поступит сигнал о том, что на экране что-то не то, какая-то "буква" нет-нет, да и матчила какой-то из биндингов в меню и активировала чёрт-те что.
Т.к. код у их приложения закрытый (не смотря на то, что это всего лишь кастрированный хромиум с парой кастомных js-скриптов), всё, что мне оставалось после репорта — это ждать пару десятков версий, пока наконец соизволили починить...
Во втором меня очень расстраивало что в широкоэкранной (да и в неширокоэкранной тоже, но в этой особенно) разметке балуны (не знаю, как правильно эти прямоугольники по-русски назвать) с текстом имеют слишком маленький лимит ширины и в итоге любой большой текст (особенно вставляемый код) превращается в кашу.
И разработчики вот уже год как игнорируют тонны багов и даже закрыли пуллреквест с патчем, исправляющим это (и он уже протух относительно кода).
Но… Т.к. код открыт — ничто не помешало мне по мотивом протухшего пулл-реквеста сделать свой патч и добиться желаемого эффекта: текст перестал искусственно сжиматься по горизонтали якобы для улучшения читаемости (чьей, интересно? явно не моей!).
Или, опять же, 2Gis против всё того же телеграма.
Оба патчат Qt5 для того чтобы собрать своё приложение (ну, нравится людям, видимо, патчить инструменты).
Но у 2Gis код закрыт и поэтому остаётся только страдать и иметь не работающее под линуксами отличными от Ubuntu приложение (потому что кроме ситуации с патченными Qt5 и крахом из-за отсутствия использованных костылей в системной версии, они ещё и слинковали бинарник одновременно с двумя версиями ICU).
Телеграмовцы тоже любители пропатчить Qt, но… код у них открытый и поэтому это позволило мне (и представителям других дистрибутивов) написать набор патчей для отвязывания его от необходимости как патчить системные Qt, так и билдить свою статическую копию.
В случае с 2Gis же… Я уже года два-три, если не больше, репорчу-репорчу, но т.к. Linux не ЦА-платформа — nobody cares.
Так и живём :)
daggert
> Зато открытый код — наличие возможности У ВАС ЛИЧНО при наличии навыков исправить проблему «здесь и сейчас».
>… при наличии навыков…
Я действительно рад что у вас навыки для исправления багов, к сожалению моих навыков программирования (веб + МК) хватает только для того чтоб написать багрепорты и ждать у моря погоды, что в линуксе что в винде.
DmitryKa
Они, видимо, решили вообще уйти в онлайн и на мобильные платформы (их очередной ответ в вк группе)
Revertis
mva
Виной всему деньги и только лишь они. А вовсе не состояние открытости кода и/или лицензии :)
geher
Исправление ошибок в системе с открытыми исходниками тоже может быть осложнено лицензией, прямо запрещающей модификацию кода не автору, или требованием подписи новособранных бинарников.
Конечно, можно отослать патч правообладателю, чтобы он учел его в следующей версии. Это уже плюс.
Но если автор забил на продукт, то ограниченная лицензия на продукт с открытыми исходниками может существенно осложнить возможность исправления ошибки.
Короче, открытые исходники — это хорошо в плане исправления ошибок (если исходников нет, то даже «надо — сделай сам» сильно осложнено необходимостью реверс-инженеринга и, частенько, необходимостью сертификации получившегося результата), но совсем не панацея.
khim
grumbler66rus
Касательно РФ, закон позволяет вносить изменения в программу, которые исправляют баги или адаптируют её для конкретного применения. Главное не распространять изменённую копию. И закон имеет приоритет над лицензионным соглашением.
khim
Закон мог бы иметь приоритет, но… не имеет. Дело в том, что в соответствующий пункт несколько лет назад была внесена маленькая поправочка. Было:
стало:И эта маленькая добавка в конце оччено существенно изменила-таки смысл закона, согласитесь? Вы лицензионное соглашение на Windows читали? Ну так просветитесь…
sumanai
А лицензионное соглашение является договором в юридическом смысле?
DrPass
Является, естественно. Но там та самая «маленькая добавка в конце» в соответствующей статье в Гражданском кодексе на самом деле очень размытая: «Применение положений, предусмотренных настоящей статьей, не должно противоречить обычному использованию программы для ЭВМ или базы данных и не должно ущемлять необоснованным образом законные интересы автора или иного правообладателя.»
Т.е. не «как сказал правообладатель в лицензионном соглашении», а «сами между собой разберётесь, на крайняк, в суде».
khim
«Внесение в программу для ЭВМ или базу данных изменений» и «исправление явных ошибок» — это пункт 1280 подраздел 1 параграф 1. В нём — никакой размытости: «если иное не предусмотрено договором с правообладателем» и точка.
grumbler66rus
Спасибо за информацию, я не знал об этой поправке.
Ещё бы без уничижительно-поучительного тона, было бы совсем хорошо.
Ivan_83
Так никто (из практиков) не отрицает что в опенсорце тоже хватает говнокода.
Однако если ты сталкиваешься с тем что у тебя чего не то не работает в опенсорце то открыв исходник можно как минимум понять почему, и вероятно, как минимум, найти обходной путь в виде условий при которых оно будет работать.
А как максимум можно и пропатчить, а то и вообще переписать нормально.
В случае же закрытыми исходниками можно только догадываться о том что там булькает в чёрном ящике.
А уж процесс поиска решения и подавно требует больше навыков и времени.
Под вендой я обычно пользовался процесс монитором и долго листал его простыни, настраивал фильтры, и иногда удавалось после долгого выжигания глазами листингов и медитаций находить решение: там файл подсунуть, тут права подкрутить, там реестрик подредактировать и тп.
Гуру же берутся за дебагер, копаются в асмовых листингах.
Но в целом людей которые могут и у которых есть мотивация и возможности (время) — крайне мало.
Людей которые могут нагуглить исходник, пролистать текст и чего то понять всё же больше, и времени на это нужно меньше.
Касательно линукса для десктопов — там много всего есть, проблема часто в том, что туда пытаются идти с идеологией МС, а потом говорят что линукс говно.
Нет там АД, и оно там не надо. Там другой подход.
Есть керберос, есть nfs, есть возможность монтировать свою хомдиру на входе авторизовавшись керберосом — те фактически получить некий аналог АД и роуминговых профилей.
Если нужны какие то политики с настройками и пр — для этого есть отдельные средства, а примитивные случаи просто скриптуются.
Касательно юзабилити и пр, тут зависит от потребностей, ожиданий и кривизны рук.
В целом опять же не надо приходить и сравнивать с вендой, тут всё по другому.
В венде скачать ехе с помойки и запустить — обычное дело, в линухе ацкая дикость и исключение из правил.
В венде ты ищешь дрова по дискам да по сайтам и ставишь, а линухе оно как правило или уже есть или надо искать на загончиках где пилят ядра или дрова, а их совсем не много. Иногда достаточно ручками добавить пару строк и пересобрать.
Alexey2005
У Linux всё очень плохо с поддержкой железа и разных низкоуровневых фишек. Чуть ли не любая железка под Linux не раскроет все 100% своего функционала, а хоть что-нибудь из функций будет отсутствовать или не заработает как положено.
Вот взять хотя бы NTFS, раз уж статья о ней. Как-то обнаружил, что на внешнем USB-диске появились ошибки: имя одного из файлов сменилось на кашу из символов, и удалить этот файл не выходит — пишет, что файл повреждён.
В винде я бы сделал chkdsk и всё, а в Linux вдруг с удивлением обнаружил, что там полностью отсутствует мало-мальски функциональный инструмент для исправления NTFS-ошибок. Всё, что может мне предложить Linux — это утилиты из комплекта NTFS-3G, которые ntfsfix и ntfsck. И обе они исправляют лишь небольшое подмножество ошибок — фактически, только чтобы файловая система после фикса вообще могла смонтироваться. Полез гуглить — везде советуют загрузиться из-под винды и пофиксить.
Ну весело… Получается, что в Linux нет полной поддержки одной из самых распространённых домашних файловых систем? Все эти экзотические Linux'овые ФС ни одно виндовое устройство не видит, да и всякие смарт-телевизоры тоже что-то не очень. У FAT32 ограничение на размер файла. И на чём же к примеру хранить фильмы, чтобы иметь возможность пофиксить ошибки ФС в случае их появления?
andreymal
Если я правильно помню, тут проблема не совсем в линуксе, NTFS абсолютно закрытая ФС без какой-либо официальной документации, и то, что она доступна в линуксе хоть как-то, уже очень большое достижение (если я не прав, буду рад узнать об этом)
exFAT? Правда, я не интересовался, чё там с исправлением ошибок)
KVL01
С exFAT довольно странная вещь. Я, правда, пару раз обжёгшись больше с ней не разбирался, возможно, не умею её готовить. А случилось вот что: отформатировал флешку дома (Win7 x64), принёс на работу – винда (Win7 x64) её не понимает. Ладно, переформатировал на работе, всё стало хорошо, принёс домой – моя винда её не понимает.
Отформатированную дома флешку, кстати, прекрасно понимала домашняя же XP SP2 с апдейтом для поддержки exFAT.
hddmasters
exFAT отвратительная файловая система с точки зрения надежности.
1. в отличие от FAT16,32 таблица заполняется, только для фрагментированных файлов.
2. таблица FAТ в одном экземпляре. Кроме этого в некоторых ОС при форматировании (создании таблицы) не удосуживаются очищать область, которую будет занимать таблица. Основной структурой контроля занятого пространства считают Bitmap. В итоге анализируя разрушения.
В общем при незначительных разрушения директории можем получить существенные потери при попытке воспользоваться средствами исправления ошибок (потери большие нежели в случае FAT32).
ExFAT использовать, только для хранения данных потеря которых не будет критична.
fshp
Ext4, XFS, Btrfs. Не вижу в них экзотики.
Потому что ФС закрытая, обложенная патентами и авторскими правами. Сама Microsoft помогать даже документацией не желает.
andreymal
Чё там с поддержкой их приставками, телевизорами, виндами?
khim
Если винда у вас есть, то и виндовый chkdsk у вас есть, не вижу проблемы.
andreymal
В контексте данной ветки неважно, кто виноват, важно, что линукс и используемые им технологии, как ни крути, не готовы для повседневного использования)
Он умеет проверять и исправлять «Ext4, XFS, Btrfs»?
andreymal
А за что заминусовали-то, да ещё и в карму? Я какую-то неправду сказал?
G-Tiger
Вы что-то не так сказали в сторону Linux-а. Уже не раз замечаю такое явление. Стоит кому-то что-то сказать на эту ОС, как тут же откуда-то прилетают минуса.
khim
Потому что производители «приставок и телевизоров» целенаправленно и сознательно делают невозможным их использование.
Вы уж меня извините, но… это не техническая проблема и технического решения она не имеет!
Нет, но в этом случае вас не будет напрягать тот факт, что поддержка NTFS в Linux, по понятным причинам, ограниченная.
andreymal
Передёргивать не надо, я же указал — в контексте данной ветки.
Ни капельки не споря с этим, вынужден ещё раз заметить, что из-за этого линуксовые технологии непригодны для конечных пользователей, и форматирование флешек для них «Ext4, XFS, Btrfs» по-прежнему неприемлемо, потому что эту флешку никто не сможет прочитать.
Меня ничего не напрягает, я прекрасно понимаю, как и почему сложилась такая ситуация, какая есть, да и все мои девайсы поддерживают Ext4) Но, что бы вы мне ни отвечали, простым пользователям (не мне), которые хотят закинуть фильм на флешку и посмотреть на приставке или перекинуть соседу, на это всё глубоко плевать: им надо чтобы просто работало. А оно не работает. Такие дела.
Jef239
Гм, у меня на флэшке два раздела, один в VFAT, второй в ext3. Не вижу никаких проблем с ext3, все линуксы её читают.
Тот же андроид 6, в чем SD-карту форматирует в режиме расширения основной памяти? Ну 100% там не FAT.
А пока у соседа винды нет — все работает. А вот если у соседа винда — вот тогда катастрофа.
fshp
Как только винда где-то появляется, так всё, приехали. Эту фс не умею, на этой флешке 2 раздела… Винда говно.
Jef239
С двумя разделами на флэшке у меня никаких проблем. На первом — vFAT, читается на любой винде. На втором ext3 — у меня читается. Но у меня для этого дела драйвер поставлен на винду поставлен. Писать он тоже может, это я уже я сам остерегаюсь.
Taciturn
Начиная с Windows 10 1703 несколько разделов на флешках наконец работают.
andreymal
Ну вообще-то именно с этого и началась данная ветка.
Чего вы андроид-то приплели, у андроида всё хорошо, я про него ничего не писал и не собираюсь.
А приставки, телевизоры (которые не на андроиде) и соседские винды? Не надо прикидываться, будто проблемы не существует.
Jef239
Понимаете чем беда…
Когда я 34 года назад начинал работать программистом, пакет дисковод мог ставится только на тот дисковод, где он писался. А на соседний — не стоило, ибо юстировка иная.
Потом это побороли, сделали совместимость между разными устройствами одной машины.
Потом — между разными устройствами однотипных машин.
Теперь мы имеем физическую совместимость между устройствами совсем разных машин. Осталась — логическая совместимость.
В стандартах на USB-флэш и SD-карты прописан FAT. И до сих пор не каждая флэшка будет беспроблемно работать в ext3.
Во флэшке есть внутренний контроллер, который обеспечивает трансляцию логический секторов в физические, равномерное количество записей на сектора и замену сбойных секторов. Это контроллер оптимизирован для FAT и иногда просто зависает для других файловых систем.
Я понимаю ваше желание выйти за рамки стандарта. Потерпите немного. современные SDHC-карты уже готовы к ext3, USB — ну или выбирать модель или ждать лет 5.
А софт… Ну моя windows XP читает ext3. Хотите — научите вашу. И соседа. В конце концов «из коробки» в винде нет ни экселя ни поверпоинта.
daggert
> Хотите — научите вашу. И соседа. В конце концов «из коробки» в винде нет ни экселя ни поверпоинта.
Не с целью флуда, однако:
У вас есть драйвер монтирующий флешку или жд в экст4 фс в «мой компьютер», при этом не висящий постоянно в отдельном сервисе?
Jef239
Нету, висит сервис «Ext2 management module». А чем он мешает?
daggert
У меня ранее его прибивали антивирусы и всякие «оптимизаторы», приходилось добавлять в исключения, а это уже жирный минус был в использовании.
mayorovp
Это жирный минус "оптимизаторам" и "антивирусам".
Am0ralist
То есть то, что какие-то «левые» программы без спроса нарушают работоспособность нормальных программ — это минус не левых программ, а тех, чью функциональность нарушали?
Отличная логика…
anatolymik
Хороший пример. В ядре я такого особенно наелся. Особенно мне нравилось когда разработчик вызывал IoCallDriver, если драйвер который он вызвал, породил исключение, из-за неверной передачи параметров, то решение их было очень простым, обернули в try/except. Вместо того чтобы разобраться в причине. И таких разработок больше чем множество. Кстати спорить с такими разработчиками не возможно. Люди не в состоянии воспринять твою мысль в принципе.
hddmasters
при анализе алгоритмов NAND контроллеров можно сказать, что в основной массе их микропрограммы они не оптимизируются для какой-либо файловой системы. Зависание — это уже признак проблемы устройства.
Простите, а что именно в них готово, что не приготовлено в USB flash? В SD(SDHC) картах логика работы контроллеров аналогична логике работы контроллеров USB_NAND. Можно рассмотреть примеры различных контроллеров и их нюансы трансляции.
Jef239
Ну значит такое качество у вас анализа было… :-) Для оптимизации под FAT хватает того, что контролер считает, что часто перезаписываемая область находится в начале диска, а не в его середине или в конце
Эксперимент очень простой. Берете 5-10 неиспользованных флэшек разных моделей. Разбиваете на 2 раздела. Один — большой под FAT, второй в конце, 1-2 гига, под ext3. При попытке растарить на него почти гигабайтный архив — запись зависает примерно в половине случаев.
Потом берете ещё 5-10 флэшек — и пытаетесь их замучать при помощи одного раздела FAT. И все работает отлично.
Можете сами проверить. Но мы покупаем флэшек в два раз больше, чем нам надо. И не всегда хватает. Последний раз брали sundisk на 8 и 16 гигов — они чуть получше, но тоже виснут.
Можете ещё DD сделать с посекторным копированием. Тут уже процентов 75, что флэшка помрет.
mayorovp
А это не может быть простое завышение объема, как любят делать некоторые?
qw1
До умирания устройства были почти полностью забиты данными и никаких проблем с данными не было.
hddmasters
Jef239
Интересно, что у меня «изношенными» оказывались только что купленые устройства, что SD 1.1, что USB 2.0.
Вы имеете ввиду, что они «изнашиваются» за время транспортировки с завода? :-)
Или все-таки речь о том, что посекторное обновление хорошо поддерживается лишь для ограниченной области таблицы FAT?
hddmasters
Вас не смутило, что любой физический блок может выполнять любую логическую роль? Ничего, что за время жизни USB Flash местоположение FAT таблиц многократно сменится согласно физического адреса, хотя согласно LBA адресации положение будет неизменным?
Претензии по качеству конечного изделия предъявляйте производителю.
глядя на качество NAND памяти (изначально допустимое количество битовых ошибок и сильно возросшие размеры ЕСС) могу сказать, что я имею в виду некачественные изделия, которые выходят из строя куда раньше, чем обещал производитель.
Jef239
Меня не смущает, что небо голубое, а трава зеленая. А вас это разве смущает?
Вот и я про о том же. Этот механизм намного лучше работает для начала диска, чем для других областей.
Можно строить много гипотез, почему так происходит. Например, по одной из них, в начале диска каждый сектор транслируется в отдельный физический блок. Понятно, что такой блок будет использоваться неэффективно, зато увеличивается надежность.
Ну тогда назовите те, которые вы считаете «качественными». Проверим, наблюдается ли этот эффект на них.
hddmasters
этому механизму совершенно безразлично, где работать. Все блоки равноправны.
можно попросить Вас ознакомиться с хотя бы общими принципами работы NAND контроллеров, а то я затрудняюсь комментировать подобные опусы.
Они уже вымирающий вид. Те самые старые USB Flash малой емкости с SLC или хотя бы MLC памятью. Рынку нужны дешевые и емкие изделия, а это TLC, которое с рождения неспособно хранить пользовательские данные без ошибок (живет исключительно за счет емких ЕСС)
Jef239
Ну так докажите это. Экспериментами с современными флэшками или ссылками на даташиты изготовителей. Информации об дизассемблировании одной прошивки десятилетней давности — это не доказательство.
Тогда я вас ещё сильнее затрудню. S25FL256S — 32 блока по 4 килобайта и 5120 блоков по 64. Это вот был один из кандидатов для нашей платы.
hddmasters
посмотрите алгоритмы сбора логических образов из дампов полученных из различных USB flash. На том же форуме софтцентра, который доступен публично. Как бы тысячи разных версий NAND контроллеров с некоторыми нюансами работают, но основная суть блочной работы и свободным расположением блоков в рамках логического банка сохраняется.
а ничего, что эта информация на данный момент имеет коммерческую ценность?
а причем это изделие к NAND памяти? И чем оно должно затруднить?
Jef239
Ну то есть доказательств у вас нет. У вас есть только ВЕРА в то, что производители не использовали маркетинговые преимущества от увеличения надежности записи в начальные блоки логических адресов.
С другой стороны, у меня — результаты экспериментов. Весьма нестрогие, но показательные.
А любые результаты экспериментов — намного лучше ВЕРЫ.
Мне не важно, что и как там организовано в контроллере. Используются ли блоки разного размера или разные критерии выбора блока для записи или ещё что-то. Но я вижу, что подобный механизм во флэшках есть.
Хотите убедиться — сделайте эксперименты сами.
hddmasters
пока есть только ваше нежелание просмотреть уже указанные источники, чтобы понять основы алгоритмов контроллеров. Речь идет не о вере, а о постоянном анализе различных алгоритмов NAND контроллеров по мере появления их в готовых изделиях.
Один американец тоже проводил эксперименты со спиртовым уровнем доказывая, что земля плоская (думаю найдете в новостях). Пока результаты ваших экспериментов примерно также достоверны, как результаты доказательств того, что земля плоская.
т. е. вы хотите сказать, что домыслы куда лучше анализа алгоритмов работы устройств?
есть только в ваших выводах, которые основаны без учета алгоритма работы самого NAND контроллера.
Так делаю, но более детальные и с учетом алгоритмов NAND контроллеров.
Jef239
Ну так давайте ссылку на результаты ваших экспериментов. Какая была методика, что делали. Гляну, могли ли они вообще выявить отличия в алгоритмах.
На самом деле все просто. Есть способ легко, за 5-10 строчек кода, получить маркетинговое преимущество над конкурентами. Вы утверждаете. что эта идея никому кроме меня в голову не пришла? Или все не стали её реализовывать, потому что эти 10 строчек затормозят алгоритм? Или по какой причине? Мифический нейтралитет к файловой системе? Так 99.9% -под FAT.
Вот подумайте над ответом на этот вопрос.
hddmasters
какое преимущество?
исходя из алгоритмов работы NAND контроллеров на сегодня наиболее удобна файловая система FAT из-за минимальных паразитных нагрузок. Второе удобство совместимость с различными ОС.
этот вопрос возникал бы, если бы не фактический анализ структур трансляторов NAND контроллеров, который показывает, что оптимизации идут несколько в другом направлении (снижение паразитных нагрузок при записи малых объемов данных)
Jef239
Преимущество понятно какое. На всех устройствах хранения прежде всего выходят из строя логические блоки, в которые запись идет чаще всего. Когда мы транслируем логический блок в физический — эта закономерность сохраняется. Чем больше записей в один блок — тем больше шансов, что трансляция в конечном итоге приведет нас в сбойный блок.
Самые часто записываемые блоки на FAT — это область таблицы FAT.
С другой стороны, ошибка записи в тело файла — может быть и не обнаружена потребителем. Или выглядеть как артефакты на одном из кадров видео, что потребитель сочтет сбоем видеозаписи, а не флэшки.
Отсюда и желание на тех устройствах, где FAT составляет 99.9% потребления — оптимизировать характеристики под него.
Такая оптимизация может основываться не только на предоставлении преимуществ начальных логическим блокам, но и на преимуществам часто записываемым блокам вообще. При этом планируемое максимальное количество часто записываемых блоков считается исходя из характеристик FAT.
Так что при анализе вы легко можете не понять, что какая-то оптимизация будет хорошо работать на FAT и плохо на ext3. Тут нужен не просто анализ — а моделирование полученного алгоритма.
hddmasters
это никто не оспаривает, но в итоге это не отражается на непосредственно износе каких-то конкретных блоков. Происходит равномерный износ группы блоков и чем меньше статичной информации лежащей на накопителе без изменений, тем эффективнее работает алгоритм выравнивания износа.
производители занимаются оптимизацией алгоритмов мелких записей, чтобы снижать паразитные нагрузки. И алгоритмам все равно FAT будет или NTFS или Ext. Они просто отработают в силу своих возможностей. Естественно самая меньшая паразитная нагрузка будет в случае FAT из-за организации самой файловой системы.
Вы не уразумев основной логики работы NAND контроллеров, сейчас описываете очень далекие от эффективных по отношению к NAND памяти приемы.
Taciturn
А эта волшебная ротация, на основе чего вообще происходит? Как, после первой записи во все блоки, контроллер отличает занятые блоки от свободных? Через USB ведь TRIM не работает.
hddmasters
микрокод USB-NAND контроллера имеет в распоряжении транслятор, где описываются задействованные блоки в рамках каждого логического банка. При каждой (или после нескольких) перезаписи блока, он исключается из трансляции и переводится в резервные, а его роль начинает выполнять вошедший в трансляцию.
сегодня или в понедельник выложу на хабр описание алгоритма работы одного из USB NAND контроллеров (немного скриншотов приготовлю для лучшей усвояемости материала). В ЕСС, глубины транслятора погружаться не буду, чтобы не пугать читателей. Полагаю, тогда многие вопросы отпадут.
Jef239
Гм, пишем на флэшку до полного заполнения, потом удаляем все файлы или форматируем флэшку. Что будет? «Статической информации» — ноль. Будет ли при этом алгоритм выравнивания износа работать эффективно?
Если будет — это означает, что флэшка понимает удаление файлов, то есть заточена под файловую систему. А затачивать её имеет смысл только под FAT. Если не будет — значит вы недопонимаете тонкости или некорректно формулируете определения.
FAT обладает следующими особенностями:
Все это не так для ext2.
Учетом любой из этих особенностей можно сделать оптимизацию под ту или иную файловую систему.
Например, можно считать все логические блоки, в которых никогда не было записи — свободными. И включить в ротацию соответствующие физические блоки. И это будет огромное преимущество именно для FAT.
А можно вообще сделать границу между свободными и несвободными блоками по записанному логическому блоку с наибольшим адресом. И это будет ещё большее преимущество именно для FAT.
Грубо говоря, если файлы занимают 10% диска — на FAT можно легко включить в ротацию 90% диска. А вот на ext2 даже 5% занятого места ограничивают ротацию считанными резервными блоками.
И это помимо тех оптимизаций, о которых я писал ранее.
hddmasters
для подавляющего большинства USB flash это будет означать, что придется переписать лишь группу блоков с метаданными файловой системы. По мере записи новой информации. Но по мере записи в пустые блоки, которые согласно транслятора заняты, ротация будет происходить. Пусть не самый эффективный алгоритм, но достаточно неплохо отработает в случае удаления, форматирования, при записи новых данных.
USB Flash не понимает нюансов файловой системы за исключением некоторых очень древних «проб пера» авторов фирмварей, которые давно показали неэффективность.
справедливо для логического пространства. В физическом все будет выглядеть по другому. Опять же пример в статье, что произойдет при перезаписи блока.
тут вы лишь декларируете, что не понимаете сути алгоритма NAND контроллера. Ротация будет осуществляться в рамках логического банка (количество банков — это уже нюанс работы того или иного NAND контроллера). И неважно речь пойдет о метаданных EXT или FAT. Разница в том, что паразитных нагрузок в случае EXT будет больше, чем в случае FAT, так как для перезаписи крошечных объемов придется переписывать целиком крупные блоки.
пока что описание ваших оптимизаций, лишь плод вашего воображения, а не фактические реализации в микропрограммах.
Jef239
Почему? Потому что ext2 кэшируется и несколько обновлений одного сектора сливаются в одно? Потому что 4 записи для создания короткого файла на FAT вам кажутся сильно меньше 4 записей для той же операции на ext2? Или потому, что флэшка оптимизирована для FAT?
Вот и подумайте, почему 4 для ext2 вам кажутся сильно больше, чем те же 4 для FAT.
geher
> Если мы удалим файл и на его место запишем другой — будет задействовано прежде всего освободившееся место в начале диска.
Интересно, это во всех реализациях FAT так?
Логично было для разработчиков драйверов ФС в зависимости от конкретных требований добавить в этот алгоритм одну из двух или сразу две оптимизации (первую по крайней мере во времена царствования старых жестких дисков). Во-первых, выделять по возможности нефрагментированный участок (последовательно расположенные кластеры) для ускорения последовательного чтения файла.
Во-вторых, выделять место в ранее не использованном пространстве, чтобы повысить вероятность восстановления данных после удаления (необходимые данные о ранее занятых, а после освобожденных кластерах можно хранить «внутри» драйвера ФС).
> Области каталогов и данных файла обычно находятся в разных физических блоках флэш, то есть удалены по логическим адресам.
> Все это не так для ext2.
> а каталог и тело файла — в другой физический блок.
Почему для FAT и ext2 в этом случае будет разница?
Могу ошибаться, но в обоих случаях каталог — это тоже файл (за исключением корневого каталога FAT). И располагаться они будут в обеих ФС с некоторой (достаточно большой) вероятностью в разных физических блоках флэшки…
Jef239
Для этого на этапе создания файла ОС должна хотя бы примерно понимать его размер. А обычная схема создания файла этого не предусматривает. open/write/close, и только на этапе close, по положению файлового указателя определяется размер файла. Да, есть SetFilePointer и SetEndOfFile в WinAPI, в Си (POSIX) можно сделать ftruncate, но… вы используете эти вызовы в своих программах? Вот и другие не используют. Ну разве что в программах копирования или разархивирования файлов.
Так что самый частый случай — в момент создания файла длина неизвестна, а известна она становится лишь при закрытии файла.
Так что ваша оптимизация присутствует в ОС, но работает лишь в тех редких случаях, когда длина известна заранее — то есть в основном при копировании или разархивировании файла.
В FAT я такого не видел. Наоборот, стараются предотвратить разрастание занятой области. Одна из причин — на внешних дорожках старых дисков плотность записи меньше, чем на внутренних (число секторов фиксировано, физическая длина внешних дорожек больше). То есть запись надежнее.
Цитата из вики
Ядро Linux, используя число индексных дескрипторов, содержащих каталоги, пытается равномерно распределить inode каталогов по группам, а inode файлов старается по возможности переместить в группу с родительским каталогом
Грубо говоря, разница будет потому, что ext2 оптимизирует движение головки по винчестеру. А операция — «прочли каталог, потом читаем файл» — это частая операция и нуждается в оптимизации. Размещение inode в группе с каталогом практически гарантирует, что данные файла будут в той же группе (ну пока файл не слишком разросся).
Для 2хмеговый физических блоков флэш и файлов меньше 512 байт — вероятность попасть в один и тот же физический блок достаточно велика.
MacIn
Как она это делает, если геометрия накопителя — неизвестна?
Jef239
Без перфекционизма, но делает. Исходя из того, что сектора с близкими номерами — требуют меньше времени на перемещение головок, чем сектора с очень дальними номерами.
Собственно геометрия (CHS) известна, прописана в MBR, просто сейчас совсем не совпадает с настоящей. Во времена разработки еxt2 — 1993 год — обычно совпадала. Но была неизвестна скорость вращения диска. Так что полная оптимизациия — и тогда не ставилась целью
hddmasters
Jef239
Вы путаете метод записи битов на диск (FM/MFM/RLL) с методом связи диска с компьютером (ST-506/ESDI/SCSI/IDE (он же АТА)).
Ну это как-то несерьезно — путать мягкое с кислым. Через IDE работали и MFM диски размерами 20-40 мегабайт.
Проблемы встали, когда размеры начали выходить за пределы, допустимые для IDE. Вот тогда LBA (ATA-1) запоздал и появились варианты с подменой геометрии.
Но большинство дисков 1993 года — вполне жили в CHS с натуральной геометрией. Насколько мне помнится, тогда самыми популярными были 80мегабайтные диски, а им трансляция ещё не нужна была.
hddmasters
ключевой момент. старые диски, не имели набортного контроллера. Всем сервоприводом управлял контроллер. И вот тогда речь шла о реальной геометрии. Почитайте про ключевые изменения в архитектуре с появлением IDE. IDE контроллер — хост контроллер и обмен данным с накопителем по протоколам описанным в АТА стандарте.
20-40мегабайт это уже ARLL (много разных видов) диски. Методы кодирования данных более совершенные (если уже про методы записи).
Неправда.
Conner CP3046F с виртуальной CHS адресацией (40Мб). При виртуальных CHS C-977,H-5, S-17. В паспорте висит реальная геометрия С-1053 H-2 S-40. Вскрытие покажет 1 пластину и две головки. И так почти все HDD тех времен и тех емкостей в 3,5" исполнении.
Говоря о коннере, можно сказать, что для тех времен весьма интересная микропрограмма с развитой терминальной системой.
Jef239
Насколько я помню, 3.5 — это была экзотика для 1993 года. Большинство винчестеров было 5.25.
см, мой пост выше, 1053 дорожки — это как раз тот случай, когда физическая геометрия не лезла в CHS.
P.S. Вы, похоже, путаете год разработки модели с годом её популярности на рынке.
hddmasters
Похоже, что Вы были уверены, в том, что CHS параметры были настоящими, а производители несколько раньше их сделали виртуальными.
Jef239
Суть в том, что 3.5 — это были дорогие современные винчестеры для ноутбуков, а 5.25 — делались для массового сегмента и по более старым технологиям. Кроме того, 5.25 бывали и высоты 2U. Представляете, сколько блинов там размещалось? А вот 3.5 — это 1/2U или 1/4U. То есть 1-2 блина максимум.
hddmasters
У меня в донорской базе можно найти много старых дисков и я многих их них могу пощупать вживую. Естественно представляю и как их реальную геометрию, так и некоторые особенности микропрограмм.
Началась беседа с Вами после подобного утверждения. Которое некорректно. И на попытку возражения Вам, вы требовали доказательств. И вам были показаны некоторые материалы по реверс-инжинирингу одного из NAND контроллеров и даны комментарии.
Давай предложим Вам сделать тоже самое? Вы расскажете на чем основаны Ваши выводы касательно оптимизаций и почему SD карты уже готовы, а USB flash нет.
Jef239
Зато из дисков очень тяжело извлечь годы их реальной популярности на рынке.
Про оптимизации много раз уже говорил, а выводы основаны на опыте,
Более того, вы уже признали наличие одной оптимизации. А этого достаточно для объяснения результатов моих экспериментов.
hddmasters
то есть вы из-за того, что у вас зависли некоторые USB flash без каких-либо предпосылок сделали выводы, что виной тому оптимизации под FAT? А как же анализ принципов работы устройства, чтобы доказать, что виной тому оптимизации для FAT и что это не просто тыканье пальцем в небо?
Также пролейте свет на то, что ж такого в SD картах, что они по вашему мнению готовы к разным файловым системам, а USB flash нет? Для более интересного вашего объяснения уточню, что алгоритмы работы с NAND памятью идентичные и у тех и у других накопителей в зависимости от производителя.
дата выпуска может подсказать.
MacIn
Были и восьмидесятки с ST-506 по двум шлейфам, с MFM. У меня была такая — на 2 слота 5.25.
MacIn
А номера-то логические? Какова трансляция из CHS в LBA? Вполне могут быть и не близкими.
Вот именно. Там может быть и 16 блинов с виртуальным преобразованием LBA в CHS, которое совсем не отвечает реальному положению дел. И трюк вида «быстрее переключиться на другую головку в следующем секторе, пока блин вращается, interleave вот это все» уже не будет однозначно работать.
khim
Да, могут. Иногда (чтобы скрыть «плохие блоки») какой-нибудь сектор могли и «за можай», на самый край диска. Но в среднем — так не было, иначе какой был бы смысл в дефрагментации?
А она реально очень сильно ускоряла работу с дисков до появления SmartDrv.
MacIn
Что CHS — не всегда реальны? Нет, это факт. Что соседние блоки могут не быть соседними физически? Тоже факт. В среднем — да, должны быть рядом.
Все верно, так же как read ahead.
Но при всем при этом есть определенный алгоритм трансляции логического номера блока в CHS, (на уровне, например, BIOS или DOS, если уж вспоминать старину). И это будет трансляция в виртуальный CHS.
khim
MacIn
Fat оперирует линейными номерами блоков же? Значит, транслирует.
Jef239
Номера логические. Но понятно, что сектора 1700 и 1800 ближе к друг другу, чем сектора 700 и 95000. Так что без перфекционизма — но оптимизируется.
hddmasters
неудачный пример. С учетом зонного распределения с вашими цифрами может быть меньшим маршрут от 700 до 95000, нежели от 1700 до 1800.
Лучше показать пример: очередь на чтение из трех секторов 100, 800 000 000, 100 000 000 будет исполнена, как 100, 100 000 000, 800 000 000. В таком примере достаточно очевидно преимущество в операциях позиционирования. В случае мелких смещений смысл в сортировке есть, так как эффективно отработает упреждающее чтение (look ahead)
Jef239
В среднем более мелкий маршрут — быстрее более крупного. Это именно в среднем и не касается очень малых маршрутов (в пределах цилиндра) и очень больших. Но в среднем — именно так.
hddmasters
пример анализа одного из алгоритмов USB NAND контроллеров с картинками. По факту их проводилось великое множество (уж больно много разных NAND контроллеров). Естественно хватает отличий и ухищрений. Но нет ничего близко похожего на ваши утверждения.
Jef239
Ну если это называть анализом… Проанализирован только нижний слой алгоритма. Верхний вы даже не пытались анализировать. Чуть позже прямо там напишу вопросы, на которые вы не ответили.
hddmasters
А вы не сочиняйте алгоритмов, которых нет. Сначала найдите признаки их существования, где-то кроме как у Вас в фантазиях. Причины того, что USB flash у вас умирали с использованием Ext совсем в другом. Разберите хотя бы структуры хоть одной из фирмварей USB_NAND контроллера, проанализируйте хоть один код, чтобы понять задачи MCU, что в подавляющем случае они не занимаются анализом данных. У них и так хватает нагрузки.
Jef239
Здесь верно лишь то, что для оптимизации под FAT не нужен анализ данных. Вполне хватает анализа адреса записываемого сектора.
hddmasters
Правда? А ничего, что размер таблиц FAT обратно пропорционален размеру кластера?
Возьмем абстрактный раздел 8GiB кластер 4KiB. Количество записей в таблице описывающей пространство будет равным 8 589 934 592/4 096=2 097 152/. Размер одной записи 4 байта. т.е. в сектор помещается 512/4=128 записей. 2 097 152/128=16 384 секторов или 8MiB размер одной копии таблицы FAT32. Две копии соответственно 16MiB.
кластер 8КiB, обе копии таблиц 8MiB
кластер 16KiB, обе копии таблиц 4MiB
А теперь вернемся к NAND контроллеру, ему чтобы оптимизировать каким-то образом запись необходимо знать размер таблиц. Как минимум должен быть алгоритм поиска boot сектора и разбор параметров из него, для создания схемы оптимизации.
Нужны ли лишние заботы микропрограмме дохлого NAND контроллера? Разбор огромного количества разных контроллеров показывает, что нет. Оптимизации разработчиков идут несколько в другом направлении, что сказывается на уменьшении паразитных нагрузок для записи мелких блоков. Подобные оптимизации снижают нагрузку как при записи метаданных файловой системы, так и при записи небольших файлов.
Jef239
А ничего. В начале у нас кроме FAT ещё и корневой каталог. И просто каталоги. В итоге, если мы при ротации для блоков ниже 32 MiB будем выбирать наименее изношенный физический блок, а для остальных — более изношенный физический блок, то изношенные физические блоки у нас осядут в неизменяемых данных.
Ещё полезная оптимизация — физические блоки, в которых вообще никогда не было записи, держать в списке резервных. Особенно если в качестве номера банка взять младьшие биты адреса блока.
Что за тайная оптимизация? Объединение нескольких логических записей в близкие сектора в одну физическую запись?
hddmasters
нет. Введение понятий блок-апдейтов. Блоков, в которых хранятся лишь группы страниц для разных блоков, которые в трансляции частично заместят содержимое оригинального блока. Снижает паразитные нагрузки при записи.
Что-то вы про «номера банка» несуразное написали. Попробуйте переписать.
Счетчики записей для блоков (там где они есть и где известны) как бы не намекают на подобный алгоритм действий. Насчет «изношенные физические блоки осядут в неизменяемых данных» не получится. Например неизменяемые данные записаны на новую USB flash и до конца жизни накопителя никто их не перезаписывает. В итоге имеем неизменяемые данные в совершенно неизношенных блоках.
Jef239
Про номера банков не поняли? А все просто. 0,4, 8, 12 логический блок — нулевой банк, 1, 5, 9, 13 — первый, 2, 6, 10, 14 — второй, 3, 7, 11, 15 — третий. А не так, что первый 2 мегабайта — все в нулевой банк. И это тоже оптимизация под FAT. она дает равномерное заполнение банков для заполненной не до конца флэшки.
Если этой оптимизации нет, то при заполненной на 20% флэшке у нас на FAT будет использоваться только нулевой банк. А на ext2 — заполнение диска более равномерное, так что такая оптимизация важна прежде всего для FAT.
Помнится, в служебной информации были не опознанные вами биты. Не хранится ли там число потребовавшихся ECC-коррекций? И не является ли оно не менее важным, чем счетчик записей?
Любые процессы с флэшкой надо анализировать как вероятностные. Вы приводите частный случай. А для любого алгоритма есть частные случаи, когда все плохо. Для того делается моделирование, чтобы проверить, как алгоритм ведет себя на большом массиве типичных случаев.
Ну давайте попробуем подумать???
Ну скажем есть тысяча файлов по 2 мегабайта в каждом (128 кластеров). Пишутся они обычным образом: открыли, записали данные и закрыли. Это означает, что на каждый файл было 128 записей в FAT, 2 записи в каталог и 1 запись данных. Так что после первых 10 файлов — уже сильно выгодно изношенные блоки выдавать на «вечное хранение» под данные файла.
hddmasters
говоря о физических банках, то показан разброс по микросхемам.
Говоря о логических банках
0x0-0x3C3*0x200000=именно столько логического пространства реализует нулевой банк. 0 блок из 1 банка — это уже 0x3C4 блок в логическом пространстве. Необходимость организации в банки — экономия на размере маркера номера блока (маркер с номером в служебке блока, дублирующая информация из транслятора и существует далеко не во всех служебках). В случае, если в данном SK6211 использовать FAT, то таблицы всегда будут находиться только в границах 0 банка. (И по факту находятся там).
как уже написано он и есть в нулевом логическом банке в случае SK6211, но есть контроллеры, для которых все пространство будет как один логический банк.
понимаете при перемещении данных в другой блок (а смена позиции логического блока происходит при перезаписи даже части информации), а старый блок исключается и очищается (полностью все биты установлены 0xFF) т.е. информации о качества чтения для этого физического блока не остается и смысла ее тащить в другой блок нет. Не исключено, что можно ввести счетчики количества коррекций согласно ЕСС, но тупиковое направление в силу того, что в современной TLC памяти коррекции будут чуть ли не в каждой странице блока (только что выпущенной памяти).
в силу специфики деятельности я знакомлюсь с большим количеством разных контроллеров.Привел пример очень популярного алгоритма, который с незначительными нюансами можно видеть в массе других контроллеров.
и зачем? Если есть еще много блоков, в которые не было записей. А также откуда контроллеру узнать, что данные будут лежать мертвы грузом, а не будут активно перезаписываться?
Jef239
А с этим никто не спорит. Просто эффективней из LBF-адреса сектора под адрес банка выделить младшие биты. В минусах будет одинаковое количество блоков в банке.
Тем не менее, по каким-то критериям блоки отправляются в список bad-блоков. И скорее всего эти критерии количественные, то есть позволяют выделить надежные и слабые блоки.
Её можно хранить в памяти контроллера. Правда встает вопрос о хранении между включениями — скорее всего в контролере нету своей флэш-памяти.
В целом аргумент про полное стирание — сильный.
А тут есть хорошая презумпция. Таблицы FAT — перезаписываться будут, остальные данные — скорее всего нет. То есть можем считать что первые логические 32 мегабайта — перезаписываются часто, остальное — редко. И в 99% случаев — будем правы.
А вот это уже особенность ext2. У меня такое впечатление, что после записи 5-10 процентов на ext2 уже записаны все блоки. Дело в том, что ext2 борется с фрагментацией файлов путем рассредоточения их по диску. Плюс ещё старается разместить файлы поближе к каталогам. А каталогов — порядка тысячи. В итоге после записи каталоговой структуры — уже можно считать что большинство блоков записано. Это не FAT, где при создании каталоговой структуры все каталоги попадут лишь в несколько логических блоков.
hddmasters
нередкая ситуация: работа с файлом на USB flash. Какой-нибудь студент делающий реферат, один файл пересохранит многократно. При том что редакция будет незначительна и размер в кластерах прежний и положение в логическом пространстве прежнее. И таких ситуаций множество, когда надо думать не только о FAT таблицах, в связи с чем направления по оптимизации записи именно FAT таблиц как-то иначе, чем иные данные не получают широкого распространения.
итог: паразитная нагрузка в случае Ext выше
как правило они отправляются технологическим ПО. Исключить блок из трансляции можно по многим критерями. Например по количеству попыток чтения с использованием Read Retry, после успешного прочтения, но с долгими мучениями переписать его в другой блок. Но есть ли смысл закладывания этих алгоритмов в обычные USB flash — большой вопрос.
Например у современных NAND микросхем, есть возможность в каждой плоскости по страницам исключать проблемные столбцы (Bad Column) и формировать список проблемных столбцов, где наиболее вероятно возникновение ошибок. Но производители не тестируют все микросхемы, часто информация об исключенных столбцах записанная в микросхемы ничего не имеет общего с реальными проблемными местами.
Технология производства выглядит как быстро, дешево и лишь бы кое-как работало.
Jef239
Мда… Знаете с времен редактора TED для RSX-11М много воды утекло. Никто не перезаписывает уже лежащий на диске файл. Делает так:
Последние лет 30 — это основная технология, все остальные варианты — приводят к потере файла из-за сбоя во время записи.
УВЫ. Итог —
всего4 записи на FAT взаменцелых4 записей на ext2. Но, как не обзови, 4=4.hddmasters
Jef239
Ну так расскажите тогда, сколько будет по вашему мнению.
Jef239
Хорошая оптимизация, но сложная. Ну не поверю, что объединение двух логических передач данных в одну физическую запись не сделали раньше.
hddmasters
подобное обычно на уровне драйвера ОС. Как например в жестких дисках уже много лет как введено понятие AHCI контроллера, который сортирует очередь команд для оптимизации перемещений БМГ. Буферизацию на запись с оптимизации записей для сменных устройствах обычно не используют. В силу того, что от пользователя можно ждать постоянных подвохов связанных с извлечением накопителя в неподходящий момент. USB NAND контроллер просто обслуживает R/W операции идущие поверх USB PHY и тут уже вопрос как обрабатываются команды. Учитывая, что в некоторых USB flash используются те же контроллеры что и в некоторых бюджетных SSD, то можно предполагать наличие классических оптимизаций. Но в случае простых контроллеров, так оптимизаций обычно нет.
Jef239
Драйвер ОС не знает размера физического блока и ориентируется на размер кластера.
Тот же linux — вообще не рассчитан на извлечение флэшки, у него иногда буферизация записи до минуты идет. С другой стороны, не так важно, выдернем ли мы флэшку во время записи или во время буферизациии длиной в 1 микросекунду. Более 50 миллисекунд — буферизацию делать не стоит. А до 50 мс — это «вытащил ровно во время записи».
Ну я рад, что в каких-то вещах мы начинаем сходится.
hddmasters
самый опасный момент. Выдернуть USB flash в момент, когда будет происходить запись оверлея трансляции и мгновенный трупик. Конечно на не факт, что на сотню выдергиваний удастся поймать момент, но тем не менее анализируя поток мертвых накопителей вижу немало случаев, когда это стало причиной смерти накопителя.
тем не менее две последовательные записи он потенциально может объединить в одну, а дальше пусть NAND контроллер смотрит, пролезет все в один блок или нет.
Am0ralist
Вот по личному опыту больше трупов я видел после стандартного извлечения с помощью «отключить устройство» в винде.
Не можете прокомментировать?
hddmasters
Am0ralist
Проблема в том что изучение показывало, что флешки были не самые изношенные офисной нагрузкой (не самые большие объемы документов на них таскалось, редко напрямую с флешек кто работал, в отличие от меня). Это было еще во времена массовости 1-4 гиговых флешек, проблем с записью и чтением до отключения не наблюдалось, а вот после отключения — аболютные трупы получались. Ну вот вообще абсолютные. То есть из разряда записали, скопировали обратно, отключили, вытащили, втыкают заново — труп. Разные утилиты не помогали.
Особенно часто грешили кингстоны, купленные не в сомнительных местах, а в нормальных магазинах…
В то же время и в хвост, и в гриву используемые мною годами, которые я вечно выдергивал сразу после записи (как индикаторы отмигаются) — обычно либо терялись быстрее, либо утрачивали актуальность объемов, а не дохли.
Jef239
Индикаторы скорее всего показывают передачу данных, а не сам процесс записи. При штатном отключении записывается FSinfo. Отгадка скорее всего в том, что при выдергивании вы ждете пару секунд после окончания индикации, а при штатном завершении — ориентируетесь на клик мышкой, и в итоге попадаете как раз на операцию записи. Выжидайте пару секунд — и все будет нормально.
Спасибо за красивый эффект, сам не знал, пока копаться не начал.
Jef239
Оверлей трансляции — это что за зверь?
Потенциально может, но зачастую путем потери во времени передачи данных. Например, при двух записях в FAT, вам придется передавать то, что находится между изменяемыми кусками.
Потому реально — не объединяет.
Jef239
Видите в чем беда… Вы перфекционист. Вам кажется, что если уж оптимизация — так до полного упора. А это просто не нужно. Есть такое правило «20-80» (20% людей выпивают 80% пива). 20% возможных оптимизаций дают примерно 80% эффекта.
И не надо анализировать бут-сектор и считать размеры FAT. Ну хотя бы потому, что 90% людей флэшку не переформатируют. А из оставшихся — 95% форматирует с дефолтными параметрами. И того, настройкой на дефолтную разметку мы оптимизируем 99.5% случаев использования.
Остальное — никому не нужный перфекционизм.
hddmasters
именно введение оптимизаций для FAT можно назвать перфекционизмом. Такие попытки были. Например OTI 2169, там небольшой логический мини банк для блоков с FAT был. Но эта политика себя не оправдала. (это было во времена USB Flash 256Мб, 512МБ)
Jef239
Ещё раз говорю — сделайте моделирование. И вы увидите, что алгоритмы оптимизированы под FAT.
hddmasters
Jef239
Что значит «не получили массового распространения»? UBIFS, JFFS2 и LogFS более чем используются. Вы попробуйте найти устройство с linux, где не было было бы одной из этих систем!
Но именно с микросхемами NAND flash, а не с USB-флэш, в которой для этого есть собственный контролер.
Я вам уже посчитал — аж 4 на ext2 взамен всего 4х на FAT для коротких файлов (размером меньше кластера). При этом ext2 агрессивно кэшируется, в отличие от FAT на windows. Иногда после записи на флэшку делаешь sync и чуть ли не минуту ждет сброса дискового кэша. Так что реальных операций записи — сильно меньше.
Jef239
И в чем же они? Почему 4 записи на файл на ext2 вам кажутся сильно больше, чем 4 записи на FAT?
hddmasters
Возьмем к примеру USB Flash на старом контроллере и простой NAND
SK6211 (UFD) + NAND K9HBG08U1M -2шт.
Samsung NAND 8bit I/O, страница 2112 байт. 2 банка, 2 плоскости в банке. Микросхема умеет работать сразу с 2 плоскостями. Организация в блоки по 128 страниц. (128*2112=270336 байт).
2 микросхемы = 4 банка, в каждом банке по 2 плоскости. Контроллер реализует эти возможности. В итоге имеем параллельную симметричную запись по каждому из каналов сразу в 4 банка и в каждом сразу в две плоскости. Итого поток сразу по 8 «каналам». 8*128=1024 страницы — это размер блока (1024*2112=2 162 688), единица в трансляции, которой оперирует данный NAND контроллер.
Организация страницы: (особенность SK6211)
2112 байт из них 2048 — данные для LBA диапазона. 64 служебные. по 16 байт на каждый блок 512 байт. В каждые 16 байт входят несколько служебных байт с маркером и флагами (дублирующие информацию из транслятора) и ЕСС (БЧХ)
Трансляция:
Логический банк по 0x400 (1024 блока), реально включено в трансляцию 0x3Cx (количестве в каждом экземпляре будет разное в зависимости от количества заведомо забракованных блоков).
В таблице указываются порядковые номера блоков из которых формируется LBA диапазон.
пример работы NAND контроллера:
Допустим в блоке с логическим номером 3 лежит файл 2кб, мы его отредактировали и сохранили изменения. NAND контроллер прочитает целый блок 2МБ, внесет в буфере изменения в виде наших модифицированных 2кб очистит и перепишет целиком блок 2Мб, только вот при выборе куда записать не факт, что он выберет блок из котрого прочитал. Скорее выберет блок из тех, что не принимают участие в трансляции с меньшим значением счетчика перезаписей, выполнит в него запись содержимого буфера, отразит сие в трансляции. Аналогичные действия произведутся в областях содержащие метаданные файловой системы.
На вопрос с чего я решил, что данный контроллер работает именно так отвечу демонстрацией примера моей древней работы по реверс-инжинирингу http://www.flash-extractor.com/forum_old/viewtopic.php?t=758 (первое же сообщение с описанием сбора логического образа из дампов полученных из микросхем). Там описан только алгоритм сбора образа с пользовательскими данными в рамках ПО существовавшего в 2008 году.
Jef239
Честно говоря, я не знаю, что там было в 2008ом году. Насколько я помню — 1-2 гигабайтные флэшки тех времен довольно спокойно переживали посекторную запись.
А я про современные флэшки на 8 и 16 гигов.
hddmasters
Я специально взял в качестве примера старый накопитель как значительно более простой пример в пояснении принципов работы. И кстати его размер 8Гб. Думаю Вам бы не стало проще понять принцип работы NAND контроллеров, если бы я добавил всякие нюансы с зашумливанием данных с исключением столбцов по плоскостям, несимметричной записью по каналам, нюансы с использованеим «блоков-апдейтов» и т. п.
Jef239
Некоторые из этих нюансов позволяют дать приоритет в надежности для начальных логических блоков.
Если вы чего-то не нашли в конкретной прошивке — это не означает, что такого не бывает никогда. :-) Как подтверждение — S25FL256S
hddmasters
каким боком приведенный пример flash памяти может относиться к USB Flash или различным CF, SD картам?
hddmasters
Скорее это не качество моего анализа, а Ваше незнание принципов работы накопителей на основе NADN flash. Дело в том, что адресное пространство не используется линейно. Есть понятие группировок NAND страниц в блоки из которых в трансляторе формируется логическое пространство (очень грубое упрощение). Так вот любой физический блок может выполнить любую логическую роль.
Ваш эксперимент с создание разделов в разных местах логического пространства ровным счетом ничего не показывает, кроме того, что в случае использования Ext на USB Flash они отваливаются при высокой нагрузке, что не лучшим образом характеризует качество изделий. Упреждая вопрос с кажущейся одинаковой нагрузкой в случае FAT и Ext предложу Вам обратить внимание на устройство файловых систем, чтобы понимать, какие метаданные файловой системы и куда пишутся, кроме непосредственно самих данных файла. Также обращаю внимание на то, что запись ведется преимущественно блоками (группа NAND страниц), т. е. перезапись метаданных Ext — это неслабая паразитная нагрузка, которая намного выше, нежели в случае FAT.
Jef239
Это не отменяет тот факт, что таблица FAT находится в начале логического пространства адресов.
Обычный режим для Windows — это частое (после записи каждого файла)обновление таблицы FAT. Причем для мелких файлов — меняется лишь один сектор в этой таблице. Винда обычно настроена так, чтобы выдергивание флэшке не привело к поломке FAT.
С другой стороны linux кэширует запись в служебные области, Причем время кэширования — достаточно велико.
Так что теоретически, при распаковке кучи мелких файлов, нагрузка на определенные сектора будет выше для FAT
Собственно можете сами попробовать писать секторами по 512 в начало и конец логического диска на USB. И сами увидите, что посекторная запись в конец быстрее вышибает диск.
geher
Пес его знает.
Есть такая штука Raspberry Pi.
Штатная флэшка под нее разбита на два раздела. Сначала маленький FAT с несколькими текстовыми файлами настройки, а потом, кажется, Ext3 (точно не FAT), работает нормально, образ льется по dd нормально. Под большой нагрузкой (постоянная запись с камеры) флэшка умирает примерно за полгода. Но и FAT (тоже постоянная запись с камеры, но не RPi) под большой нагрузкой умирает за примерно то же время.
hddmasters
geher
Файлы от 1 до 5 мб недостаточно мелкие?
Из-за особенностей настройки видео резалось именно такими порциями (низкое качество несколько секунд).
hddmasters
мелкий файл — это файл, который многократно меньше размера блока, которым оперирует NAND контроллер. 1-5Мб цифры одного порядка с размером блока.
hddmasters
начисто отменяет. блок с boot сектором и FAT может и в самом конце быть. За время эксплуатации он постоянно будет перемещаться. Чуть ли не при каждой перезаписи. В первый свободный блок с существенно меньшим числом записей.
для вас меняется один лишь сектор, а NAND контроллер целиком переписывает блок.
от Windows и любой другой ОС тут мало что зависит. Если выдергивание произойдет во время обновления таблицы трансляции, то получите накопитель, который «перестал определяться» или «определяется нулевым размером».
Если не брать в расчет принципы работы конкретного NAND контроллера, то иллюзия подобная вашей имеет место быть. А по факту на Ext нагрузка будет выше.
поверьте, данный детский эксперимент мне точно нет нужды проводить. Я все же предпочитаю более глубокий анализ принципов работы NAND контроллеров.
Alexey2005
А как повлиять на производителей в плане улучшения поддержки сторонних FS? Тут разве предусмотрена какая-то обратная связь? Даже просто выбрать при покупке модель с поддержкой ext3/ext4, если таковые вообще существуют в природе, и то практически невозможно, потому как в характеристиках этого не указывают. Поддержку основных кодеков и видеоконтейнеров укажут, а такую мелочь — нет.
khim
Ну вот эту проблему и нужно решать.
А то у вас получается, что Linux не поддерживает Linux'овые технологии — а виноваты разработчики. Нет. Виноваты те, что взял — и открутил эту поддержку по тем или иным причинам.
Scorry
Читайте тут. Надеюсь, вы понимаете, что «винды» в перечне «приставки, телевизоры» выглядит несколько чужеродно.
andreymal
Нет, не понимаю. Сходить к соседу с внешним USB-диском с фильмами — вполне реалистичная ситуация (не у всех ещё интернеты в сотни мегабит). И форматировать его в «Ext4, XFS, Btrfs» совершенно не годится, потому что у соседа на компе стоит не Android-x86, а Windows 7.
На флешке/переносном USB-винте должна стоять ФС, которая работает одновременно и на приставках, и на телевизорах, и на виндах. Если сосед — хипстер/дизайнер, то и в макосях тоже.
Zapped
>Если сосед — хипстер/дизайнер, то и в макосях тоже.
с макосями дела не имел, но загуглив по-быстрому, получил, например
Mac OS X can read from NTFS drives, but it can’t write to them unless you use one of the below tricks.
то есть, насколько я понимаю, без предварительных танцев в макоси тоже не всё хорошо
Scorry
Вы интересно выстраиваете аргументы. Виндовый чекдиск не умеет править линуксовые системы — минус линуксу. Линукс умеет править нтфс, но базово — снова минус линуксу. Майкрософт силой загоняет производителей железа на совместимость с виндами и с носителями на фат32 — неужели снова Столлман с Торвальдсом злое умыслили?
andreymal
Во-первых, я писал, что поддержка NTFS это плюс линуксу. Во-вторых, ещё раз повторюсь, конечным пользователям плевать, у кого какие там плюсы-минусы, им надо чтобы просто работало. «Ext4, XFS, Btrfs» под «просто работает» не попадает. Вот и всё. Не надо мне минусов надумывать, я ничего такого не говорил.
Scorry
Я укажу вам на дыру в ваших рассуждениях: я — конечный пользователь. И мне сильно, очень сильно не плевать. Поэтому у меня в доме майкрософта, например, исчезающе мало.
andreymal
Что ж, рад за вас) К сожалению для всех нас, типичный конечный пользователь не такой. Он ближе к такому.
khim
Однако если ты сталкиваешься с тем что у тебя чего не то не работает в опенсорце то открыв исходник можно как минимум понять почему, и вероятно, как минимум, найти обходной путь в виде условий при которых оно будет работать.
У Linux всё очень плохо с поддержкой железа и разных низкоуровневых фишек. Чуть ли не любая железка под Linux не раскроет все 100% своего функционала, а хоть что-нибудь из функций будет отсутствовать или не заработает как положено.
…
Все эти экзотические Linux'овые ФС ни одно виндовое устройство не видит, да и всякие смарт-телевизоры тоже что-то не очень.
Ну а дальше — уже откуда-то возникли «обычные пользователи», которым «всё пофиг», и которым, в частности, пофиг, что нормально Smart TV работает только с HDD, отформатированным в ext3.
andreymal
Я отвечал на второй комментарий, который как раз и является мнением конечного пользователя, который просто хочет фильмов на диске. Ни к линуксу, ни к опенсорсу я никаких претензий не имею и прекрасно понимаю весь вложенный в них труд, я лишь констатирую факты касательно юзабельности всего этого по состоянию на май 2017 года. Как и автор второго комментария.
khim
Как было сказано чуть выше:Это, вы уж извините, не «я лишь констатирую факты касательно юзабельности всего этого по состоянию на май 2017 года», а совсем даже другое…
andreymal
Я отвечал лишь про файловые системы. Про оборудование я ничего не говорил и говорить не собираюсь (хотя сказать тоже много чего есть, я недавно 3G-модем не смог завести, например), только про файловые системы.
Прекращайте перевирать мои комментарии, никому никаких минусов я не приписывал. Я лишь объясняю, что нельзя просто так взять и отформатировать флешку в Ext4. Если все ваши соседи юзают убунту, если все ваши приставки без проблем подключают Ext4, если ваш работодатель отказался от использования продукции Microsoft — я буду очень радоваться за вас и завидовать вашему локальному вендекапцу. Но, к сожалению, мир, в котором живу я (и автор второго комментария), не такой, мне приходится взаимодействовать с Windows каждый день (в том числе с использованием флешек), и, если я отформатирую флешку в Ext4, я получу кучу проблем при взаимодействии с другими людьми и их устройствами.
khim
Ваш мир примерно так же несовершенен, как и мой — но какое это всё имеет отношение к качеству опен-сорсного кода, в частности, кода Linux'а?
andreymal
А никакого. Я про него ничего и не говорил. Я говорил лишь про то, что из-за несовершенства мира нельзя отформатировать флешку/юсб-диск в "Ext4, XFS, Btrfs".
Это даже к теме поста не имеет отношения, может лучше уже закрыть тему?)
fshp
Вы опять же путаете производителей софта и производителей железа.
То, что производитель вашего модема написал драйвер лишь к Windows — никак к теме не относится. У меня есть сканер, который работает лишь в WinXP x86. Начиная с висты и выше драйверов нет. Однако сканер прекрасно работает в любых версиях Linux. И будет работать ещё не одно десятилетие.
grossws
Тогда ntfs не очень подходит, т. к. её поддержка на macosx хуже на linux.
andreymal
Поэтому я и предложил exFAT)
khim
exFAT — ещё хуже, чем NTFS. По той же причине.
andreymal
Есть где почитать про проблемы? В моей практике с ней было всё прекрасно, лучше чем с NTFS
grossws
На куче железок он не поддерживался по тем же причинам: патенты. Какая сейчас ситуация в ванильном линуксе — не знаю. Apple вполне может оплачивать лицензию.
khim
Wikipedia не подойдёт?
Там про всё написано: и про проблемы с патентами и лицензиями и про Samsung'овский драйвер с непонятным правовым статусом и про прочее.
Разница в основном в том что, что exFAT разрабатывался под весьма убогое ядро Windows CE (и, соответcтвенно, под «хитрый план» связанный с вытеснением Linux'а со всяких «приставок и Smart TV»), так что хитрых фич в ней меньше.
mva
Всё в порядке. Просто в UI доступном для "ЦА" её намеренно вырезали. Вот так вот, да. Замкнутый круг. Нету — потому что ЦА не поймёт, а ЦА никогда не поймёт потому что нету.
Ivan_83
Насчёт железа ты не прав, в том смысле что далеко не любая.
Если хочешь померится у кого длиннее список, включи в линуксовый список все те чипы на которых он запускается и все те IP (модули в чипах) хреновины которые в них встроены и которые линух умеет.
С видюхами да, не фонтан, пока что.
К тому же, я могу припомнить что на дворе уже 2017 год, а венда говорят только начиная с десятки кое как научилась работать с вланами, а до того юзеры венды дрочили на утилиты вендоров сетевых карт чтобы хоть какие то VLANы поиметь в системе. Хотя для поддержки VLAN таковая в сетевухе не требуется вообще.
Или вон в конце поста история про DVB в венде.
Ну давай, в своей венде примонтируй самую распространённую во фре UFS2, самую крутую для работы с дисками ZFS, самую линуксовую ext2.
Не можешь?
Значит венда говно.
Те нефиг всё под венду ровнять.
Я и сам тебе могу сотни юзкейсов накидать когда винда отсасывает.
Если тебе надо что то скормить телеку — юзай nfs, UPnP/DLNA и не парь мозги себе и людям. А некоторые плееры даже и самбу умеют.
2 andreymal
Ну так венда настолько уныла что ничего кроме своих NTFS и FAT не знает, почему ты это предъявляешь пользователям/пейсателям линуха!?
Иди мс дрочи, пусть вкорячивают, ты же типа заплатил.
Нам (не винда юзерам) то твой NTFS как бы нафик не сдался, у нас своих винрарных фс хватает, которые получше будут и на любой случай жизни.
Да и ко всяким телекам/плеерам у нас свой подход: nfs, самба, UPnP/DLNA — производитель о нас подумал и внедрил поддержку DLNA и на коробку об этом буквами и картинкой написал, это вы там флешки с вирусами разносите. Не лень вам с флешкой бегать?
А не пробовали WMP тыкать, а то он тоже умеет кина по DLNA на ящик показывать. Вот всякие дриектплей, хромекаст и прочие красивые названия это оно и есть. Всамртах самсунга оно с 2011 года есть.
А я вот смог завести все 3г мопеды под фрёй: http://netlab.dhis.org/wiki/ru:hardware:huawei:e3272
под линухом уже всё давно заезжено.
Но если ты юзер, то перед приобретением хрени нужно убедится что кто то уже её прикрутил и закоммитил поддержку, а не тащить в комп всё подряд что под руку подвернётся.
2 Andreyika
Так мой опус был скорее про то, что Си хотя бы изучают кое где, а вот всякие дебагеры и асемблеры знает и понимает гораздо меньше людей, опять же времени на чтение си/др языка нужно меньше.
Что касается более обычных людей, то если они англоговорячие/читающие то в принципе могут нагуглить по тексту ошибки и хотя бы понять общий смысл и может даже что то самостоятельно придумать как исправить/обойти без компиляции.
2 anatolymik
В линупсе есть udevd, systemd оно получает все нотификации от ядра об новых устройствах.
Во фре есть devd он тоже получает нотификации от ядра о новых файлах и делает какие то действия в ответ, ну там драйвер подгрузить или дёрнуть что то.
Это намного более гибкая система чем то что в венде, тут всё просто и понятно.
Если тебе не нравятся чужие 100500 дистров линуха, форкни что нравится и сделай свой болгенос с гувернандками и думом.
«Попробуйте разработать шифрование загрузочного диска (на уже установленной системе, а не во время установки).» и про фильтрацию — не нужно натягивать свои хотелки и косяки планирования на линукс, очевидно это не венда.
Если ты прошляпил и тебе нужно зашифровать диск ПОСЛЕ установки — достаёшь второй диск, копируешь систему на него, делаешь первый диск зашифрованным и копируешь систему обратно.
Это не венда, тут можно копировать систему целиком и она, о чудо, будет работать.
Попробуй свою венду скопировать на другой диск чтобы она потом ещё и работала. Штатными средствами.
Или вот в линухе/бсд можно одной командой проверить ВСЕ установленные из портов/пакетов проги на предмет того что они поменялись (ну там диск сломался или ещё чего), а в венде — хер.
Фрю/линух можно легко починить просто поставив поверх, при этом все конфиги останутся на месте, ибо это штатная процедура обновления по сути, а венду ты хер починишь. Можно попрыгать там с её типа шаттной системой восстановления, но это не всегда помогает и потом можно систему только переставить… а потом переставить весь софт.
А ты слышал когда нибудь про то что директшоу можно фильтры выстраивать в цепочки для обработки видео/аудио, получая эдакий граф?
Так вот во фре тоже самое можно делать с дисковыми устройствами, и есть куча разных «кубиков» с разным функционалом, в итоге можно из дисков собрать массив любой формы и размера, с шифрованием и прочим.
Есть такая же штука для обработки сетевых пакетов, их тоже можно по всякому жевать и слать в разные места на своё усмотрение, хоть прямо эзернет фреймы. Тебе то в венде для каждого такого чиха нужно корябать отдельный драйвер, как то его подписывать и пр, никакой готовой инфраструктуры у тебя там нет. Да и сам драйвер писать в венде то ещё удовольствие: у тебя там одна обязательная обвязка выходит больше чем у меня на фре/линухе весь драйвер с лицензией внутри.
Но если тебе мало, давай продолжим.
Вот смотри, в линухе есть какой то селинух. Я хз что это, мне пофик, но он есть и он для безопасности.
Во фре есть MAC — это такая штука, которая как рак расползлась по всем подсистемам и позволяет проверять целостность структур и то что запрос от юзера внезапно не стал запросом от рута. А ещё она позволяет крайне гибко раздавать разрешения/запрещать.
Например можно накорябать модуть строк на 200 си кода или меньше, который будет запрещать определённым юзерам создавать сокеты, или наоборот разрешать создавать сырые сокеты.
Вместо/в дополнение к сокету там ещё сотни всего что можно разрешать/запрещать, во всех этих точках контролировать целостность.
Ещё у нас есть джейлы — это можно запустить отдельную операционку не виртуалкой а почти как процесс.
В драгонфлае вообще ядра с дровами штатно отлаживаются как обычная прога.
А давай я винде заодно припомню что там МС так и не осилил нормально запилить подсистему для работы с тюнерами DVB, в итоге венда постоянно валится в синий экран, на каждый чих: включил прогу телек посмотреть — синий экран, переключил канал — синий экран, пропал сигнал — синий экран… ну ты понял.
В линухах у меня от DVB ничего не падало.
Во фре оно вообще упасть в принципе не может, потому что дрова выдернуты из линукса и вставлены в обычный юзерспейс процесс, даже если он свалится — пофик.
Ну и как любителю крипты в венде, могу тебе напомнить что:
1. там часть годных алгоримов отключена тупо в реестре
2. если ты включаешь это ручками, то будь готов повторять процедуру несколько раз в год, потому что иногда приезжают обновления которые выключают это обратно.
http://netlab.dhis.org/wiki/ru:software:win:sec:enabletls
3. встроенной крипте в венду доверять нельзя в принципе, потому что никто не делал публичных аудитов. Даже ихнему ГСПЧ, вероятно там подарок АНБ себе любимым аналогичный тому что был в гспч на элиптике который они везде продавливали.
4. шифрование диска там дико подозрительное, в части ключа восстановления, на что и намекали авторы трукрипта в своём прощальном послании.
Вывод же из всего этого простой: не ходи с вендовым уставом и привычками по другим ОС, учи матчасть тех ОС куда пришёл и будет тебе щастье, а иначе только страдания и боль.
Хотя виндузятники без страданий не могут, особенно на десятке с обновлениями %)
sumanai
Винда ровно так же ставится поверх с сохранением настроек и программ, ибо это штатная процедура обновления.
Месье не освоил оснастку «Управление дисками» консоли управления?
Всегда мечтал слать сетевые пакеты с произвольным содержанием.
«селинух»- это костыль к убогой системе прав UNIX, где есть только три права (чтение-запись-выполнение) и три же объекта для их применения (владелец-группа-остальные). В Windows в любимой вами NTFS поддерживается значительно больше прав доступа безо всяких ограничений на число тех, к кому они применяются.
Исправил.
khim
Да и selinux — это не «костыль к системе прав». Это вы его с xattr, перепутали, я думаю.
С исправлением согласен.
Вообще есть много вещей, которые в Linux и Windows сделаны по разному — причём так, что сходу сказать «что лучше» — нельзя. Например в Windows интерфейс системных вызовов (syscalls) — нестабилен, что приводит к тому, что многие вещи, которые в FreeBSD/Linux можно сделать в Windows в принципе не поддерживеются — но зато это позволяет делать межмодульные вызовы быстрее. И? Какой из подходов лучше? Зависит от ваших целей, разумеется.
Собственно отсюда и появляется явление, которое неправильно описано G-Tigerом как стоит кому-то что-то сказать на эту ОС, как тут же откуда-то прилетают минуса.
Минуса появляются не тогда, когда кто-то заявляется «Linux не умеет X, а Windows — умеет», а когда кто-то из этого делает «глубокомысленный» вывод «потому Linux — отстой». Ибо это как раз и есть попытка «ходить с уставом и привычками одной ОС по другим ОС».
sumanai
Всё зависит от настроек. Настройки по умолчанию достаточно безопасны, главное их не ломать.
Верно.
Ivan_83
Режим обновления, а ты поди снеси кусок десятки и попробуй сверху накатить, чтобы восполнить потери, потом расскажешь как встало и ничего не потеряло в настройках.
Месье освоил GEOM и теперь смотрит на оснастку как на говно для мышководов.
Так в венде об уровне эзернета запрещено даже мечтать, только элита со своими дровами может рассчитывать на такое.
Даже сырые сокеты у вас отобрали, ибо они детям не игрушка :)
(да да, они были, и есть, просто их отключили)
Понятия не имею про се линукс, гугель в андройде на него фапает.
Хочешь поспорить — скажи что нибудь приятное про MAC во фре :)
2 sumanai
У вас все дефолты священны, чего с вас взять :)
2 PsyHaSTe
Специалисты по восстановлению данных вообще не рекомендуют chkdsk юзать, ибо он часто запарывает/херит.
Но думаю у них от части мир такой: к ним несут то что уже запорото/похерено, а то что большинство спасается они не видят.
2 Zalechi
Конформизм такой конформистский, да?
2 anatolymik
У меня для тебя печальная новость: МС очень херово дорабатывает венду.
Давай вспомним историю.
98 и всё что до неё — УГ, но оно работало на 16/32мб озу и за это их можно простить.
2000-2001 годы — 2к и ХР. Годно, юзабельно, не падает, но уже нужно 128 а лучше 256мб озу.
В те годы линукс я видел на десктопе, мне кажется он был чуть прожорливее.
И вот прошло 16 лет.
Линукс переписали уже наверное раза два целиком, фря офигенно подросла и обзавелась форками. Подросло и окружение рабочего стола, которое во многом всё ещё не стало сильно прожорливее (кроме кде).
Что за 16 лет стало в венде круче?
х64 приросло? упёрли ASLR из опенбсд? переписали ядро полтора раза и похерили совместимость с дровами три раза?
Вот только не надо мне про прозрачность и рабочие столы — это всё можно было в ХР.
Ах да, IPv6 вроде как впилили.
По сравнению с опенсорцом венда все 16 лет НИХЕРА НЕ РАЗВИВАЛАСЬ!
Они даже гуй до сих пор не смогли оторвать от ядра.
Единственный раз тут было интервью какого то архитектора облаков (азуре?) и он там говорил дельные вещи мягким языком: о том как они выпиливали горы говна чтобы вендовое ядро стало похоже на линуксовое и чтобы сделать минимальный дистр на 200 метров и сколько это стоило усилий. Именно он говорил что венда сливает и они это понимают и кромсают там чтобы срезать все наслоения сгнившего кода и не нужного хлама.
Но здесь этого похоже никто не услышал, ибо все продолжают спорить о вкусах сорта говна 10 под разными соусами разного срока выдержки/пропатченности.
И ты там где то спрашивал про примеры говнокодерства мс — почитай про багу WSAPoll() и что мс теперь назвало это фичей и не будет править дабы не сломать обратную совместимость.
Да, я в курсе IRP, фильтров и прочего. Даже сам один драйвер почти дописал, от безысходности.
Но это ацкий ад. Драйвер в венде имеет слишком дофига обязательного скелета, а со средствами отладки и удобством вообще швах.
При этом я не особо утруждаясь накорябал уже 3-4 ядерных модуля под фрю, и один драйвер специфичной железки под линух, и он тоже весьма не сложный, в том плане что совсем мало кода который нужен только линуксу а не устройству.
Ну и в целом я не отрицаю что у них в ядре и прочих местах есть годные уникальные вещи, проблема только в том, что они не удаляют горы говна, а их явно больше и растут они быстрее.
В линухе/бсд с этим проще.
При этом линух/бсд умудряются не растерять драйвера при апгрейдах, и это огромный плюс.
2 khim
Справедливости ради.
Когда венда 95 появилась это был наверное прорыв, как ни крути.
У ребят бабло потекло ручьями и было не до кодинга и тем более не до SMP, которого тогда поди и в серверах то не было толком.
Параллельно они пилили NT, потому что было понятно что падения 95 это как то не бизнес подход.
Те они вышли на растущий рынок и старались на нём продвинутся и удержатся, это примерно означало много пеара и багфиксы.
Кой чего они прикупили, кой чего пофиксили и выкатили через 3 года вин 98.
И вот где то тогда, ИМХО, замаячили многопроцовые сервера у корпоратов, плюс стало понятно что глюкодром/решето 98 не излечимо в принципе.
Плюс было накладно тянуть сразу две ветки венды.
Более менее у них всё получилось только через 4 года с ХР/2к3. Пожалуй самая годная ОС за всю их историю и за первые лет 10 начала века (на десктопе).
Из видимых/ощутимых улучшений в семёрке/2к8 относительно 2к3 х64 был IPv6 да поддержка SSD, кто бы что там не говорил. Ах да, в семёрке дрова видео как то отвязали и они при падении перестали ронять систему.
А дальше Гейтс стал впадать в маразм, его выперли на пенсию и всё окончательно скатилось.
Тех оплотов разума что остались в компании хватит чтобы ещё протянуть, но не хватит чтобы изменить курс в никуда.
Широкополосный инет кардинально изменил рынки, МС к этому не готова, и что то делают чтобы не потонуть вроде только в азуре. Если бы не эти гады :) я бы давно заблочил нафик у себя все подсети МС как бесполезные и вредные — ибо в них может утекать как минимум телеметрия. Только они могут собрать дистр и идут в этом направлении который мне будет интересно посмотреть.
ИМХО мы сейчас находимся в начальной точке взрывного роста опенсорца, так не характерного для виндо платформы, и этот рост довольно быстро перекроет все те наработки в виде софта которые есть у венды и которые в общем то ради чего её ставят.
Вон даже наша 1С и та уже под линукс подсуетилась.
sumanai
Это весьма сложно, скажу я вам. Получать права на файлы, пытаться удалить заблокированные… Ну нафиг, сложно это.
Вы мой намёк на то, что 99,999% пользователей это не нужно, вы не поняли? Ну вот, написал открытым текстом.
IPv6 у меня отключён за отсутствием у провайдера, ОС стоит на SSD, здоровье которого наконец-то опустилось до 99% с конца 2012 года, спасибо вам, иначе не заметил бы. И всё это на XPx 64.
qw1
И посмотреть, как обновление системы восстановит потерянные файлы )))
sumanai
И что вы этим хотели сказать? Зачем восстанавливать то, что не удалено?
khim
Натурный эксперимент, проведённый несколько лет назад доказал, что всё это, в общем, сказки: система зачхастую отказывалась грузиться и гораздо чаще «полностью вернуть работоспособность испорченных систем не удалось» — и это были не Windows 95…
qw1
sumanai
Я же показал скриншот после выполнения этой команды. Ничего из этого удалено не было, и система штатно перезагрузилась. И всё потому, что прав не хватило.
Выполните эту команду сами и убедитесь. Только про бекап не забывайте- с ОС ничего не случится, а вот сторонние программы могут пострадать.
Ivan_83
Ну да, мышководить это ппц как сложно, проще два вагона угля совковой лопатой отмахать, конечно.
Оч сложно сменить владельца файлов, имея SeTakeOwnerShip привилегию (у админа есть но можно и любой учётке дать), потом сменить права доступа и затем погрохать всё к чертям.
Ну если чо приноси диск, у меня фре (fuse-nfs вообще то) плевать на эти ваши ACL в NTFS, я тебе быстро все *.exe, *.dll удалю, покажешь потом как оно восстановится.
А то у нас то по колхозному всё, как в досе: херак, скопировал с рабочей системы, и готово.
Да и консоль у нас на всяких инсталяторах не скучная=бесполезная, а вполне решающая.
Впрочем есть и вполне бытовой сценарий: диск может посыпаться, и может оказаться что профили юзеров, сам реестр и програмфилес вообще не пострадают, а только куски ОС. И вот sfc /scannow это вообще очень слабое средство для лечения таких случаев.
Да да, в венде одни юзеры, настоящих программеров и админов там нет, я догадывался… )
Собственно пока сам сидел на венде дальше сокетов и примитивного роутинга не разбирался, потом понял что валить надо было раньше, только время потерял.
А у меня IPv6 включён уже года 4 как минимум, и клал я с прибором на провайдеров, сливаю всё через туннель прямо штатовским гэбистам в их хурикатэлектрик.
Так не солидно юзать трофейный огрызок в виде ХРх64, надо было брать хотя бы полноценный 2к3х64 стандарт, там больше всего доступно и суппортился он сильно дольше и качественнее.
sumanai
Я прекрасно знаю как это сделать. Но сделать это случайно практически нереально.
У меня вообще виртуальная машина, и пересылать образ в 60ГБ как-то лень.
На http://stackoverflow.com/ заходить не советую- его поддерживают ненастоящие админы на десятке серверов под Windows )))
Заплатки я оттуда и брал, остальное чушь. Ничего из 2к3 мне не нужно. Зачем мне файловый сервер, менеджер лицензий и прочий шлак на домашнем ПК?
MacIn
Что имеется в виду?
sumanai
Устанавливал обновления 2003 сервера на свою XP х64. Эти ОС основаны на одном ядре, и обновления у них были общие, так что после окончания поддержки обновления от сервера вставали без проблем.
MacIn
А вы все еще используете XP64? Помню, кто-то говорил про преимущества, еще обсуждали сторонние программы для накопителей SDD.
sumanai
Да, прямо сейчас с неё пишу.
Какая разница уже, раньше думал, что обновления браузера сгонят, но сейчас, когда в следующей версии FF с долгой поддержкой выпилят XUL, смысл обновлять браузер отпала. Так что на ближайшие два года становлюсь адептом необновления, пока жизнь не заставит.
MacIn
Почему?
sumanai
А зачем мне очередной клон интерфейса хрома? Мне FF без Classic Theme Restorer не мил. И это не считая десятка других дополнений, завязанных на XUL и которые принципиально не перенести на WebExtension.
FieryVortex
Оно делает образ системы в виде виртуального жёсткого диска VHD, который можно закинуть почти куда угодно (на NTFS-раздел, естессно) и загрузиться прямо с него, добавив соответствующую запись в список загрузки BCD.
Am0ralist
Кроме того явное передергивание в пункте: «штатными средствами».
Из разряда, если подобные средства встроены:
— ага, злобный монополист захватил кучу сопутствующих рынков встроенными приложениям в ОС с монопольным положением на рынке ОС. (см. антимонопольные разборки относительно ИЕ)
Если не было создано приложений на любой чих:
— ага, лохи, не смогли создать такую простую утилиту (список на 2 млн требований)
При этом как-то явно намеряно забывают уточнить, что все эти программы писали, чаще всего, совершенно другие люди, а не те, что разрабатывали ОС, что для платного софта не допустимо (см. закон про навязывание дополнительных платных услуг и пр.).
Хотя да, под винду куча вещей, которые данный тролль не знает явно.
В данном случае «Тролль» — просто констатация факта, так как он и под линукс то хает половину не нравящихся лично ему технологий, которые кто-то вздумал развивать вопреки его единственно верному истинному мнению.
Так что не кормите его, оно того не стоит.
FieryVortex
Угу, коммерческой компании делать больше нефиг, как тратить тысячи лишних человеко-часов разработчиков ради тонны круто написанных утилит на любой вкус/цвет/запах, которые, раз они так круты, скорее всего, моментально спиратят. И так-то их софт по торрентам гуляет вовсю.
Тот же GNU/Linux создавался десятками компаний и кучей энтузиастов. Попутно разный прикладной свободный софт пришёл и на другие платформы, включая столлманно-мерзкую венду.
Да просто было любопытно потыкать палочкой очередного «винда нифига не умеет!!11адынадын», не удосужившегося сделать то, что посильно простому вендоюзеру, — заглянуть в настройки резервного копирования, в папку с бэкапами и немного подумать.
Ivan_83
Отлично.
Ещё бы кто то об этом знал и умел пользоваться.
А что делать когда когда образа нет или он тоже покорёжен?
Я же привёл вполне конкретный кейс: часть бинарников ОС удалена/покорёжена, реестр и профили полностью целые.
В случае сбоя диска или вирусов вполне обычное дело.
Это я ещё не спрашиваю что делать когда програм филес удалено/покорёжено.
Или как найти файл который поменялся из за того что его подменили/заразили.
2 Am0ralist
Включи моск.
Средства обновления, самодиагностики и управления пакетами — часть ОС, даже в унылой венде.
Напомнить про угрёбищный msi инсталлер?
Собственно это часть инфрастуктуры/платформы ОС, оно ни с чем не конкурирует, ровно как и вендовое АПИ это часть которая не конкурирует, и дисковая система NTFS тоже как бы часть и не конкурирует ни с кем.
Даже встроенный чекдиск не конкурирует с другими, нельзя придти в антимонопольную службу и доказать что он тут не нужен, пусть люди смогут купить нортон диск доктор. Потому что это сервисная штатная утилита для починки того что является неотъемлемой частью ОС.
Ровно как и всякие акронисы и прочие бэкаперы не идут с антимонопольными исками чтобы выпилили встроенные средства восстановления. Даже производители антивирусов не очень то рыпаются, хотя им то вполне можно было.
Ты это, не путай доп услуги с тем чтобы ОС могла сама себя нормально диагностировать и лечить.
Так уж и быть я буду настаивать чтобы венда осилила починку всего стороннего софта, хотя там делались попытки, но чувствую msi скрипты правильно писать мало кто осилил потому всё так хреново.
Так про линукс я сказал что мне пофик что там, я им не так чтобы активно пользуюсь.
2 sumanai
Стак — ошибка природы.
Рано или поздно им надоест и они перепишут это на похапе и поставят вместо 10 виндуст машин 3 тазика с фрёй/линухом и начнут наконец спать спокойно.
Всё что не нужно либо совсем удаляется через роли, либо банально отключается.
Я ж говорю, разницы между серверными и десктопными ОС у МС нет, ну кроме кастрации и накидывания мусора в обновления.
В случае сервера тебе бы даже ручками не пришлось искать и ставить обновления, это единственная редакция которая делается хоть немного для людей.
sumanai
Сперва
добейсязапустите альтернативу.Тазиков с виндой хвалило бы ровно в 10 раз меньше, но для обеспечения устойчивости при пиках у них 10 кратное резервирование. И они ни капли не мучаются, потому что у них есть руки и голова.
Да конечно. Но зачем ставить ОС с кучей хлама лишь для того, чтобы его отключать и удалять? Особая форма мазохизма?
PsyHaSTe
Какое-то время назад с другом по телефону чинили сломанный NTFS как раз через ntfsfix с помощью лайв-убунты, потому что винда не грузилась, а чекдиск циклически проверял диск, перезагружался, снова ругался на сломанный нтфс и снова предлагал починить. На 5 раз стало очевидно, что надо что-то делать. Убунту, руфус, полчаса и готово. Винда грузится, все довольны.
Так что я не знаю, что у вас за траблы с нтфсом в линухе. Тем более, как выше уже сказали, поддержка формата без спецификации то еще удовольствие.
mva
1) "вот эти экзотические Linux'овые ФС", на самом деле, используются на куда бОльшем количестве девайсов в мире, чем существует ПК с Windows
2) Почему вы Linux'у в претензию ставите отсутствие нормальной поддержки проприетарной и абсолютно не документированной ФС, все имплементации которой получены только реверс-инжинирингом, при этом не ставите Windows в вину отсутствие нормальной поддержки не только ExtFS, но и других "вкусняшек", код которых полностью открыт (т.е. давно бы уже могли, если бы не принцип EEE)? Вы сами не видите за собой двойных стандартов?
3)
a) это не вина Linux. Это вина вендоров. Иногда в лени и/или жадности и/или глупости (незнании о существовании чего либо кроме Windows), иногда в сговоре с M$ явно запрещающем писать драйвера для других ОС (да-да).
b) на самом деле, это наглая ло^W^W совсем не так. Я сменил уже порядка 3 лаптопов "игрового" класса (сейчас, вот, пишу с MSI GT-72 купленного год назад) и всё железо в них прекрасно поддерживается. Даже смена окраски клавиатуры.
Не соблаговолите ли вы быть немного более конкретным? Иначе сие так же суть подлог и провокация.
От первого до последнего слова подлог и провокация.
Ну и сама суть:
Ну, детский сад же, ну.
UPD.: забыл ещё сказать:
Практически все эти "умные телевизоры" используют Linux и умеют эти все ФС. Просто вендоры — ну… вендоры. Короче. "ЦА не поймёт — значит выкидываем".
Практически все "приставки" (STB и т.п.) — тоже линуксы и то же самое.
Игровые — либо линуксы либо другие юниксы и то же самое
qw1
Andreyika
Если речь про какие-то банальности, обнаруживаемые filemonом и иже с ним или вообще абстрактно — да, исходники иметь лучше, чем не иметь их…
другой вопрос, что скорее всего читающий совсем не программист, либо «программист» (админ/эникей), либо специалист по другому языку и не понимающий указатели на указатели…
читающий совершенно не знает проект
читающий, даже примерно найдя проблему не сможет «быстренько скомпилировать» сие
нет никакой гарантии, что фикс проблемы с «правами к папке» в итоге не будет теперь выдавать всем рута.
и тд.
Zalechi
«Холивар он такой».
Вы ребя нашли очередной стимул к разодрать старую рану. Не могу пройти мимо…
Винда — она такая лапочка…
Линуx — такой брутальный…
Винда — лимузин…
Линуx — внедорожник(джип)…
Мы уже наверно подошли к пониманию, что сравнивать их можно косвенно. Роскошный лимузин и проходимый жип — оба являются представителями автомобилей. И толку сравнивать эти классы? Давайте обсудим закрытость и открытость этих систем. Бессмысленно! первокурснику понятно, что…
Итого:
1) В рейтинге закрытых систем абсолютный лидер и монополист — Винда. Карсочная, гладкая, вылизанная и причёсанная. Эх одна отрисовка шрифтов чего стоит…
В этой категории iOS даже «краем глаза» не приблизится к мастдаю. Единтственное — это перформанс, тут конечно яблоковцы гуру. Однако iOS — основывается на открытом коде линукса, что у же выбивает его из вышеназванной категории, да и много ещё к чему подкопаться можно. Например, многие кодят в среде iOS, пишут музыку и рисуют фильмы картинки. Вот ток вопрос, в ограниченности предоставленных инструментов полюбому открыт.
Кого ещё можно затронуть в этой категории?..
2) В рейтинге открытых систем — есть много игроков, но все они брутальны. В том плане, что это либо для гиков, админов промышлеников и тд/тп, либо это десктопы, которые никак не сравнить с вышеупомянутыми лидерами.
По ходу кроме «яблока Джобса» с червоточинкой, некому в этом мире написать достойную пусть и закрытую операционную систему.
geher
> iOS
Может быть все же OS X?
iOS — это планшеты и смарты, которые пока уделывают виндоконкурента по полной программе.
Впрочем, и в OS X, и в iOS не используется линуксовое ядро. Там, если не путаю, используется своеобразное юниксовое ядро mach64, причем творчески переработанное.
И да, OS X официально сертифицировано как UNIX система, Linux нет.
Zalechi
Да, спасибо за поправку. Конечно я имел в виду OS X, ну и во вторых за замечание по поводу принадлежности к UNIX системам.
Однако хрен редьки не слаще, — If you know what I'm mean… I'm think you do.
saipr
anatolymik
Попробуйте разработать DLP такое же как под Windows — универсальное. Например для фильтрации устройств которые нужно блокировать. В Linux нет центрального PnP.
Попробуйте разработать шифрование загрузочного диска (на уже установленной системе, а не во время установки). В Linux, отсутствует множество механизмов для таких задач, например фильтрация. Приходиться делать через remapping устройств. А после нужно переконфигурировать Linux, на новое блочное устройство. И разные версии Linux конфигурируются по разному. Я уже не говорю что нужно парсить текстовый файл с этой целью.
Я перечислил только то, что мне в голову пришло. На практике примеров значительно больше.
saipr
А это не подойдет: CryptoAPI ядра Linux: применение российской криптографии ?
anatolymik
Нет. Я говорил о загрузочном томе. Сделать можно. Но это ад. Хотя бы потому что нужно поддерживать много тонкостей разных версий.
Во-вторых, это никак не отменяет отсутствие центрального PnP.
Ну вот еще пример, всем известно что когда Linux адаптировался под многопроцессорные системы, чтобы избежать повреждения данных в контексте ядра, был добавлен так называемый big kernel lock. Который захватывался всякий раз когда user mode вызывал сервисы ядра. Т.е. получается потоки будут простаивать. Windows, изначально разрабатывался как многопроцессорная система. Учитывая все требования которые были необходимы на момент разработки.
С точки зрения реализации Windows мне импонирует больше. И не только реализации, а также её модель мне нравиться больше. Проще и гибче.
khim
Угу. Известная вещь. Про него даже статья есть в Wikipedia. Где, кстати, написано, что его извели пять лет назад.
Именно. А если чего было сделано криво изначально (скажем идиотские «устройства»
con,nul,aux— да там много чего), то всё — теперь все будут «жрать этот кактус». Вечно (ну или по крайней мере до тех пор, пока Windows не станет историей).Ну да. Хотите создать процесс — передаёте имя и параметры. Это же так сложно! То ли дело в Windows: вызываете функцию с 10 аргументами (из которых многие — структуры) — и порядок. Что может быть проще?
Ах, ну да, есть проблеммка: среди этой кучи аргументов не нашлось места массиву параметров — командная строка передаётся как единое целое и её нужно разбирать на части. Причём разные команды делают это по разному (hint: в командной строке ведь и кавычки всякие могут быть). Да так, что «упрощённый» _wexec несовместим с «упрощённым» _tmain'ом. Видимо предполагается что «устаревшие» параметры никто использовать не должен, все будут COM пользовать…
anatolymik
Вы сейчас все смешали. Не стоит сравнивать целиком модель, с отдельными моментами. Еще раз подчеркну, что мне реализация и модель Windows нравиться больше. Я свое мнение не навязываю.
Я явно упомянул что когда Linux адаптировался, ввели BKL. Я знаю что его нет сейчас. Я говорю о подходе как таковом в решении конкретной проблемы. Windows же, изначально в себе не содержал ничего подобного. Если это не так приведите пример.
Касательно идиотских устройств они были введены для совместимости с DOS.
Касательно 10 аргументов, это ничего не доказывает. Эти 10 аргументов позволяют породить новый процесс гибко.
Еще раз подчеркну, я говорил о модели и реализации. Я не говорил об отдельных функциях у которых может быть множество параметров. А это множество, само по себе ничего не доказывает.
khim
Да легко. Windows (не путать с ядром NT!) была изначально рассчитана только и исключительно на однопроцессорные системы. И в ней, когда её адаптировали под многопроцессорные системы — также образовались аналоги BKL. И их тоже изводили — годами. Причём, извели-таки не до конца. Вот, например.
На самом деле для поддержки CP/M, с которой была «слизана» DOS 1.0. Вот только DOS уже давно в Windows x64 не поддерживается, про CP/M уже все забыли, а идиотские устройства — по прежнему с нами.
Не «доказывает», но наводит на неприятные мысли.
Дело в том, что эти «чудесные» функции с дюжиной аргументов ведь не на пустом месте возникли. Они возникли потому, что системные вызовы дорогие. А из-за того, что процессы и нити дорогие — появились разные другие извращения.
Собственно это всё — просто демонстрация разницы в подходах: в Windows всё делается «учитывая все требования которые были необходимы на момент разработки», но после этого то, что сотворили — считается чем-то сакральным и дальше его никто уже никогда не меняет (только в последние годы начались небольшие подвижки), в Linux — изначальная реализация может быть кривой и ужасной, но со временем — её превращают в «конфетку».
Хороший пример (раз уж мы тут о локах говорим): Mutex'ы и Futex'ы. Mutex'ы в Windows есть — однако они неудобные и медленные. Собственно изначально они и в Linux были медленными. А потом — были изобретены Futexы. И в Windows они тоже есть. Но вот только дальнейшая судьба у них — различна. В Linux — стандартные Mutex'ы были переписаны так, чтобы использовать Futex'ы (и теперь их не нужно «создавать» и «освобождать», они быстрые и т.д. и т.п.), а в Windows — Futex'ы были добавлены «сбоку». Mutex'ы — по прежнему медленные и неудобные, но если вам очень нужно (и вы можете позволить себе не поддерживать Windows 7) — тогда да, можете использовать Futex'ы. Напрямую. Создавая поверх них все необходимые надстройки. Удачи!
anatolymik
Коллега, разговор бессмысленный.
mayorovp
Это вы сейчас так разработчиков NGPT обозвали?
MacIn
Обычный мьютекс(без имен) — это спин-лок CriticalSection, которой сто лет в обед.
sergey-b
Да, API Windows в этой части особенно кривой. Однако и в Linux не все хорошо. Например, в Linux нет удобного буфера обмена. В Windows пользователь может скопировать таблицу из Excel и вставить ее в Paint. А в Linux каждая программа по-своему с буфером работает, поэтому никогда не знаешь, что получится при попытке вставить данные из буфера. Для серверных задач это вообще значения не имеет, а для десктопа это важно. Поэтому даже многим разработчикам удобнее в Windows.
khim
Насчёт того, что творится «выше» ядра в GNU/Linux на десктопе — я и сам могу рассказать много ужасов.
Недаром именно на desktop'е Linux «сливает» целиком и полностью. Почему это происходит — отдельный вопрос, но во-многом, я думаю — беда в том, что разработка софта для дейсктопа происходит по всем известной CADT модели.
Однако в самом ядре — все очень сильно не так.
sergey-b
В этом и есть сила Windows. Владеющая этой ОС корпорация может себе позволить довести до нужного уровня и ядро, и оболочку (ну почти, за исключением консоли), и производителей железа простимулировать. А разработчики ядра Linux никак не могут повлиять на разработчиков десктопов, им остается надеяться и ждать, когда те сами организуются и наведут у себя порядок.
MacIn
Воу-воу-воу, палехче. Это же только симлинки для досовких устройств, compatibility layer, а не нечто имманентное самой системе. Возьмите и удалите, если так прям надо.
Не понимаю ваших проблем. Так уж сделайте обертку за 5 минут с двумя параметрами, и будет вам счастье.
khim
mayorovp
Где можно увидеть бенчмарки?
khim
Вот, например. Да — статья старая, но она как раз примерно из тех времён, когда архитектура Windows NT разрабатывалась. Разница там в разы, а не на проценты.
Собственно это изначально очевидно: это разница между микроядерной архитектурой и монолитным ядром.
Со временем Windows NT делалась всё менее «микроядерной» и «цена» системного вызова уменьшалась, но, насколько я знаю, разница всё ещё заметна.
mayorovp
А ничего, что у Linux тоже монолитное ядро? Кстати, по вашей ссылке линукса в сравнении нет.
khim
Там есть NetBSD — для оценки «масштабов бедствия» достаточно.
mayorovp
Нет, недостаточно. Потому что нет информации о "масштабах бедствия" в линуксе.
sumanai
NT не является микроядерной, впрочем как и чисто монолитной. У NT, как и у Linux, гибридное ядро. Хотя у NT уклон в модульность чуть больше и прослеживается с рождения.
khim
Израчально NT планировалась «красивой», «правильной», «строго микроядерной». И первая версия — почти такая и есть. А потом… потом посмотрели на производительность, схватились за голову и начали срочно ядро «гибридизировать», чтобы производительность была хотя бы на уровне плинтуса, а не под ним.
sumanai
Строгой микроядерности там никогда не было, достаточно много кода работала в режиме ядра, включая драйверы и большую часть подсистем. В более поздних версиях в ядро внесли лишь графическую подсистему, да, как раз из-за вопросов к производительности.
qw1
Я думаю, мы ещё придём к микроядерности ради параллелизма. Все эти громоздкие IPC/DPC хорошо себя покажут, когда ядер в процессорах будет под 32-64.
Подсистемы ОС будут хорошо висеть на отдельных физических ядрах и обмениваться сообщениями.
sumanai
Никак не связанные задачи.
Никто не мешает прибить отдельные системные потоки к отдельным ядрам ЦП уже сейчас, но это совершенно не нужно, так как планировщик сам раскидает их по ядрам, и вообще одна и та же задача вполне может запускаться на нескольких ядрах, чтобы не быть ограниченной в производительности одного ядра.
qw1
Ну, смотрите. Микроядерность — это когда сервис ядра нельзя вызвать напрямую, а можно послать ему сообщение, а он пришлёт ответ.
На примере огромных web-приложений мы уже видим, что монолитная архитектура (где в центре — классический большой и мощный SQL-сервер) помирает под нагрузкой. Несколько маленьких изолированных микросервисов спасают ситуацию.
mayorovp
Под нагрузккой системы с СУБД в центре помирают исключительно из-за немасшбтабируемой СУБД в центре, а не из-за монолитности.
qw1
Но разделение большой системы на много маленьких — способ повышения масштабируемости.
mayorovp
Или понижения, если делить неправильно.
MacIn
Порождение процесса — тяжелая вещь как ни крути. Занесение всяких доппараметров, навроде хэндла стандартного устройства вывода, проверка на то, что они заполнены или нужны defaultные, ничего не решает.
khim
Что действительно занимает много времени — так это загрузка нового бинарника. Но, опять-таки в Linux это делать при создании нового процесса необязательно.
Да ладно вам? Сколько времени занимает заполнение одной структурки на 4K? Это — всё, что нужно в Linux для создания процесса, если при этом таблицы дескрипторов, маппинги виртуальной памяти и прочее — шарятся с родителем. Но даже «полноценных» процессов можно напорождать сотни и тысячи за секунду.
MacIn
Создание нити(fiber) вобще не обсуждаем, это отдельная легковесная некооперативная штука. А если говорить о создании в пространстве родителя, где все шарится, то это будет эквивалентно созданию потока в NT, а не процесса.
Иначе получается некорректное сравнение (вы, кстати, выше пеняли кому-то на это — мол, Х решает проблемы, которые есть только в Х).
Насколько «полноценных», каков этот критерий?
Ну так и при создании потока в NT этого делать не надо. Создание процесса в NT — это синоним, по сути, для загрузки бинарника. Да, если он уже подгружен, там будет переиспользование при создании 2+ копии и так далее.
qw1
khim
Нет, под Windows ASLR так не работает. По возможности загруженные библиотеки переиспользуются и загружаются на те же адреса.
Это — собственно костыль для отсутствующего
forkа.qw1
Когда страницы с кодом напрямую мапились на области в исполняемом файле, это было очевидно и прозрачно.
Когда же загруженный код отличается от того, что на диске, я не уверен, что он будет шариться. Может, будет, а может и нет. Если будет, кто владелец страницы? Первый загрузивший её процесс? А если он раньше помрёт? Надо искать авторитетные источники.
sumanai
Я уже упоминал тут книгу «Внутреннее устройство Microsoft Windows», там всё это подробно расписано.
Если кратко, то страницы только для чтения, содержащие код и константы, шарятся очевидно легко, просто один регион памяти отображается на адресное пространство нескольких процессов, заведует всем диспетчер памяти. Страницы, доступные для записи помечаются тегом «Copy on write», и соответственно копируются в личное адресное пространство процесса при первой попытке записи. Это относится к отображаемым файлам и загружаемым библиотекам.
qw1
Это очевидно. Вопрос в ASLR, где каждая страница кода после загрузки должна быть релоцирована на другой адрес. По вышецитированному должен случиться copy-on-write, но тогда какой тут шаринг?
khim
Простой. Как я уже сказал: загрузчик в Windows — это часть ядра. И когда он грузит библиотеку — он запоминает куда он её поклал. Если другой процесс запросит ту же библиотеку — ему постараются её отпамировать на тот же адрес. Тут подробности, если интересно.
MacIn
А какая разница? Маппинг будет другой, но страница-то та же самая.
khim
В Windos не используется PLT, потому если загрузить код в другое место, то все функции, которые его используют придётся менять.
Там вокруг этого весьма немало всякого-разного накручено, чтобы эти изменённые страницы не сжирали уж совсем всю память и не занимали уж совсем весь диск.
Зато 3-5% можно на некоторых бенчмарках выиграть.
MacIn
Нельзя ли подробнее? По идее, например, external dependencies в виде dll зачастую как раз через PLT делаются — IAT позволяет это.
MacIn
Ах да, релоки же могут быть.
qw1
khim
qw1
Очень интересно. Я нашёл пост, в котором описывается процесс маппинга.
Оказывается, copy-on-write не происходит. Загрузчик знает, что DLL в памяти «сдвинут» относительно DLL на диске. И, при подкачке страницы, сам корректирует смещения.
https://blogs.msdn.microsoft.com/oldnewthing/20160413-00/?p=93301
upd. хех, я нагуглил ту же страницу :)
khim
Вы правы. Но желание «размножить» процесс, увы, решает проблемы, которые в Windows тоже нужно как-то решать.
Стандарный
fork, грубо говоря.Дело в том, что в Linux как раз создание процесса — несколько более затейливо, чем в Windows. Вы можете шарить с родителем всё, вплоть до адресного пространства, а можете — получить приватное видение файловой системы, приватные сетевые устройства и даже приватные PID'ы (и да — ребёнок в этом случае будет иметь приватный виртуальный PID #1 и будет там, «в новом мире», init'ом).
Не совсем. Бинарник загружается в новый процесс, а в тот же самый его загрузить нельзя. И нельзя сделать новый процесс, который бы был «копией» существующего — а иногда очень хочется (см. выше).
sumanai
В каждой подсистеме Linux, от самых первых до последней в Windows 10, реализуют этот пресловутый форк.
Есть у кого бенчмарки форка, чтобы проверить на виртуалке в Linux и в виртуалке на Windows 10 с подсистемой Linux приложений. Было бы интересно.
qw1
RtlCloneUserProcess, на базе которого есть куча примеров реализацийforkв Win32. Другое дело, что нет документированной функции.Но Microsoft не спешит. В ядре NT4 уже были множественные рабочие столы, которые недокументированно использовались всякими сторонними десктоп-менеджерами. А потом на их базе сделали публичное API.
MacIn
Верно, на уровне Native API.
MacIn
Это терминологический спор, давайте оставим его в стороне.
Форк — юниксовая тема, как я уже сказал, незачем переносить ее в мир NT и потом обсуждать что что-то, мол, не так. С таким же успехом можно взять, скажем, то, что в других ОС называется нитями (а в NT соответственно потоками) и сравнивать при этом с NTшными fiber'ами.
Это другой вопрос. Я о том, что создание процесса в мире NT сопряжено с выделение адресного пространства, загрузкой образа и так далее. Нет четкого эквивалента, поэтому сравнивать «тут процессы лучше, тут хуже» нельзя.
Другой мир — NT — другие решения. Ни хорошо, ни плохо. Fork — способ решения каких-то задач в мире Unix.
grossws
От BKL окончательно избавились в 2.6.39, см https://kernelnewbies.org/BigKernelLock. Отношение к современному Linux'у это имеет, по большей части, историческое. Да и ранее, BKL автоматически снимался при засыпании потока.
А какая версия Windows разрабатывался изначально для SMP? 3.1? NT3.5? 95? NT4? Или всё же только 2000?
anatolymik
BKL был только пример. Я знаю что его нет сейчас.
На счет конкретной версии не скажу. Я могу только сказать что для этого разработчикам не пришлось переписывать половину ядра. Ибо изначально не было глобальных переменных в огромном количестве.
grossws
Раз у вас столько инсайдерской информации, поделитесь сколько процентов из nt4 присутствуют в nt5? Сколько пришлось переписать для поддержки smp? Сколько функций было затронуто?
И потом расскажите какая у вас была методология подсчета того, что в linux переписали «половину ядра»?
Пока вот утверждения выглядят, к несчастью, голословными утверждениями фаната, не более.
anatolymik
Касательно информации, она далеко не инсайдерская. Есть исходники nt 4.0, 2000 и есть WRK v1.2(Windows 2003). Можно посмотреть и сравнить. Чем я занимался много. Многие функции в нынешнем Windows сохранились и по сей день еще с nt 4.0.
На счет «половины ядра», извиняюсь, это риторика. Однако по опыту, костыли вроде BLK, говорят именно об этом.
Дополню, если Microsoft дорабатывает свой продукт, костыли вроде BLK она не делает. Она делает полноценную реализацию. Еще раз, я говорил о подходе в развитие продукта.
Касательно фаната, если Вам так угодно, пусть так. Как я уже многократно это сказал здесь, я Вам ничего не навязываю.
khim
Дык и мы о том же! В случае с Linux — люди делают ошибки и их справляют. В случае с Microsoft — «она делает полноценную реализацию», но если там что-то не так — то… «мыши кололись, плакали, но продолжали жрать кактус». Обход когда-то забитых «костылей» — становится частью техзадания на новые фичи!
anatolymik
Я извиняюсь, а почему если функция существует 20 лет то это обязательно плохо? Может разработчики угадали на 20 лет вперед? Если все необходимые требования выполняются и все необходимые задачи решаются?
khim
Если «все необходимые задачи решаются» — тогда да. А вот если мне обьясняют, что мне сегодня, сейчас, нужно вставлять в мой код кучу свеженьких ксотыликов для того, чтобы «объехать» костыли, которые были забиты в систему в момент её проектирования для железа, которое уже почти 20 лет не поддерживается… то возникает желание кого-нибудь убить.
Просто вы, как я понял, в основном общаетесь с одной системой — и вам она нравится. А я несколько лет назад — писал низкоуровневый код, который должен был работать на трёх системах (Linux, MacOS, Windows). И подавляющее большинство несуразностей и кривостей — происходили из-за того, что нам приходилось поддерживать Windows.
Слава богу, что мы от этой поддержки отказались, так что сейчас я с этим ужасом не сталкиваюсь, так что как устроена жизнь в Windows 10 — не знаю. Но не думаю что там вдруг всё радикально изменилось и «сакральные костыли» куда-то исчезли.
anatolymik
Приведите пример костылей. Приведите пример проблем поддержки windows.
P.S. В настоящий момент я системный программист под linux.
khim
Выпиливание NtSetLdtEntries в Windows x64 было другим «приятным» сюрпризом, которое потребовало от нас не одного человеко-года.
Ну и всякие «мелочи» (скажем нам так и не удалось придумать способ «захватить» себе участок памяти с базой равной нулю… да и вообще — аллоцировать гигабайт памяти на 32-битной Windows это те ещё пляски с бубном).
Это то, что вспомнилось через 5 лет. Но помню что количество костылей, которые содержали замечания «мы делаем X, потому что Windows не позволяет сделать Y» — зашкаливало, MacOS — дала пару или тройку подобных замечаний, а Linux — я не помню такого вовсе…
anatolymik
Просто из спортивного интереса, почему вам было принципиально распределение виртуального пространства с гранулярностью 4к?
На счет NtSetLdtEntries, я так понимаю в Linux, API не меняется, функции не режут, интерфейсы функций тоже не меняются.
Касательно мелочей, если я Вас правильно понял конечно, нулевой адрес в Windows зарезервирован.
khim
Меняются. Но только в тех случаях, когда без этого — совсем никак. Бинарники, рассчитанные на Linux 1.0 и сейчас отлично запускаются.
А вот DOSEMU — уже нет. Но тут, извините, проблема в процессоре: поддержки 16-битных сегментов в Long Mode нету.
anatolymik
64 прекрасно делиться на 4, что не так?
khim
Вот если бы 4 делилось на 64 — то всё было бы чудесно.
А так… если у нас программа хочет аллоцировать 4K в режиме read-write, а следующие — в режиме read-only (обычный guard page), то под Windows — у нас проблемы.
Пришлось наворотить целый «огород», который пытается программы, по мере возможности, обмануть, и убедить их что всё работает как положено, а не как в Windows.
qw1
Вот рабочий пример кода, ставящий разную защиту на соседние страницы.
anatolymik
Вы меня опередили)
qw1
А разве в linux userspace нулевой адрес не зарезервирован, чтобы ловить segfault при разыменовывании
nullptr?khim
Зарезервирован нулевой адрес, но можно захватить себе кусок памяти, начиная с адреса 64K. Нас это устроило.
Хотя да, если бы у бинарников, которые нам нужно было обрабатывать, не было там «дыры» в 64K, то в Linux у нас тоже была бы проблема.
qw1
Учитывая такие странные запросы, можно было бы попробовать не использовать Win32, а стартовать процесс в native api, плюс процесс поддержки — в Win32 для взаимодействия с юзеом. Хотя документации, как делать exe для native, почти не было, кроме статей Руссиновича.
Тут тебе голое адресное пространство — лепи, что хочешь. Хоть убунту, подсистему которой сделали в десятке.
anatolymik
Кстати в функции NtSetLdtEntries на х64 нет смысла из-за аппаратных особенностей процессора. Так что не к Microsoft претензии.
khim
А к кому? Я ж не претендую на NtSetLdtEntries в 64-битных программах. Зачем было из 32-битных из изводить?
Ах, ну да: отряд равняется на отстающего — если в 64-битных программах нет сегментов, то уже и в 32-битных мы их поддерживать не будем.
Отличный подход, чёрт побери.
anatolymik
Чушь говорит даташит на процессор. Для х64 приложений в нем нет смысла. Функционал ломается.
На счет 32х битных не знаю.
В mac и linux для х64 бинаря?
khim
Правильно. А раз в x64 приложениях в нём нет смысла, то давайте теперь и из 32-битных NtSetLdtEntries выкорчуем.
Решение — вполне в духе той самой 64K-гранулярности, когда из-за поддержки DEC Alpha введённой 1993м в прекращённой в 2003м у нас костыли в 2012м.
red75prim
Костыли, которые лично вам не нужны, живут — плохо. Недокументированную функцию, которая лично вам нужна, убрали — плохо.
Мнение ясно. Но, видимо, инженерам Windows приходится иметь дело не только с вами.
khim
«Железо» что-то делать умеет, а Windows нет == плохо.
И мне пофиг — происходит это из-за костылей, «которые лично мне не нужны» или из-за того, что раньше эта фича делалась через недокументированную функцию, а теперь — не делается никак.
Тут вы правы. В основном им приходится иметь дело с людьми, у которых нет выбора. Обратите внимание над одним очень интересный феномен: «красивая», «правильная», «чудесная» Windows NT не смогла завоевать ни одного рынка.
Почти везде — она существует только лишь как альтернатива, которая держится за свой небольшой клочок рынка, который у неё есть за счёт массированного вливания денег: «большие» сервера и встроенные системы, смартфоны и телевизоры (да-да, туда Microsoft тоже Windows хотел «продвинуть») — потихоньку люди уходят от Windows к другим, «плохим и неправильным» системам. В некоторых местах не удалось даже и процента рынка занять (сколько денег вбухали в продвижение Windows на рынок HPC, а в Top500 Windows слабо заметна).
Единственный рынок (ну или два смежных рынка — тут как считать) где она доминирует — это рынки, которые достались ей в наследство от «ужасной», «кошмарной», «неуклюжей» классической Windows: десктоп и сервера малого бизнеса. Нигде, где у людей не было вложены деньги в Windows-софт до появления Windows NT успеха достичь не удалось.
Подумайте над этим.
DrPass
Да как сказать. Windows NT во второй половине 1990-х практически уничтожила рынок Unix-серверов и рабочих станций. По сути, от них остался только самый топовый сегмент. Неудачными можно считать попытки наезда на ARM-архитектуру и все девайсы, которые работают под ней, сейчас это действительно вотчина Linux. Но и то, это по причине каких-то архитектурных проблем системы, а по причине стратегических просчётов руководства Майкрософт. Во времена Windows CE все шансы закрепиться там у них были.
Людям-то в массе своей вообще безразлично, какая там ОС стоит в их телевизоре (по факту, даже рядовые пользователи компьютера не слишком привередливые в этом плане, пользуются тем, что им поставили). Это больше работа с вендорами, да с поставщиками софта.
MacIn
МС сильны в поддержке клиентов и изменениях «как бы не навредить legacy». И слава богу. Если вы используете недокументированную функцию, то вы ССЗБ.
Zalechi
Может я неверно истолковал Вас, но, если я не ошибаюсь, данный ответ я пишу с Windows NT 10(NT 6.4).
Вики по Win NT
Так, операционной системе Windows 7 соответствует версия ядра Windows NT 6.1, а наиболее современная на сегодняшний день версия ОС Windows 8.1 содержит ядро версии Windows NT 6.3. Но следующая версия — Windows 10 — будет лишена этого противоречия и получит ядро Windows NT 10.0. Хотя текущая предварительная версия Windows 10 Technical Preview все еще содержит ядро версии Windows NT 6.4, в следующих сборках нумерация будет изменена.
khim
Но этот рынок не был «завоёван». Он был передан уже готовым. В наследство вот от тех самых людей, которые, как нам тут рассказывают ничего не понимали в написании операционок и наделали кучу проблем в «классической» Windows.
Am0ralist
Да-да, продажи компьютеров начали стагнировать со времен 9х, угу. За это время количество персоналок не только не выросло где-нибудь на порядок, но даже наоборот — сократилось! И это всё было, видимо, на фоне с невероятным противостоянием против более прогрессивной и удобной Linux для декстопов. Я прям так и вижу эпическую картину.
С учетом, что в 2000 году компьютеров примерно 350 млн было, а 1 млрд. мы перевалили еще в 2008 году, то до сих пор монопольное положение на рынке декстопов именно за МСом намекает, что успех был достигнут определенно не за счет 9х винды, а именно за счет удачности NT, в том числе за счет XP. Поэтому ваше стремление переиначить историю не понятно.
В противном случае линукс бы быстро научился повторять 9х и отхапал бы на текущий момент намного больший кусок.
khim
А Windows 9X выпускалась специально как средство запуска «старых программ для Windows 3.1x» и «новых программ для Cairo». А потом — разрабочиков начали просто гнобить если они отказывались поддерживать Windows NT 4 (а потом Windows 2000).
Это вы стремитесь изобрести какую-то альтернативную историю где от Windows 9X люди вдруг резко отказываются и «стройными рядами» переходят на Windows NT. В реальности же — пользователи тянули до последнего и Microsoft даже пришлось выпустить ещё одну «внеочередную версию» (после того как в 1998м Билл Гейтс заявил что после Windows 98 всем придётся
жрать кактусперейти на линейку Windows NT). Вот как пользователи хотели перейти на «суперудачную NT».Am0ralist
Я был как раз тот, кто снес предустановленную пиратскую хп и поставил честную пиратскую 98 после покупки компа. Потому что я ее знал и мне не нравилось переучивать под новый интерфейс.
Через полгода я снес 98, поставил XP в классическом виде и перестал страдать дурью (в том числе вида переустановки винды по очередному глюку).
Ретроградство — оно такое.
Что опять же никак не доказывает ваши слова, потому что по выходу любой следующей версии винды это повторялось снова и снова. Ну, кроме 7-ки, которая не сильно от висты отличалась, а к этому моменту к той уже все привыкли. Зато вот что с выходом висты (очень стабильная ОС, я нарадоваться не мог на работе на те пару ноутов, которые с ней были куплены — ибо проблем на них не было совершенно, в отличие от ноутов с XP), что 8-ки (а 8.1 по мне так вообще лучшая на текущий момент), что 10-ки (хотя тут больше факт навязывания всех возмутил).
Поэтому приводить как довод то, что на новую версию пользователи переходили со скрипом и воем и этим доказать несостоятельность NT, хотя так было всегда — вот это и есть альтернативное толкование истории.
khim
А вот уже Windows NT — извините, но ни одного рынка она так и не завоевала. Там выше рассказы про то, что она убила рынок рабочих станций на UNIX… Вот нифига подобного! Попытка — была. Но ни Windows под Alpha, ни Windows для MIPS — успеха не имела.
Рынок рабочих станций убил Intel, а не Windows.
sumanai
Как и на бете Windows 7, как и на 10, как и сейчас многие сидят на инсайдерских сборках, которые по суди равны unstable убунты, или как там самая новая ветка зовётся.
anatolymik
В завершении нашего бесполезного диалога, проведу грубую аналогию. Когда вы будете портировать ассемблерный код ARM под платформу Intel, не надо жаловаться на то что процессор Intel не интерпритирует инструкций процессора ARM.
Случай что вы описали, меня наводит на следующие мысли. Вы портировали legacy код с другой платформы. При этом, этот код был написан без учета особенностей других ОС. Не потому что разработчики о чем-то не подумали, а потому что мир был тогда другим. Хотя нередко на своей практике я сталкивался с тем, когда разработчики намерено себе ставят палки в колеса. Я лично видел как код написанный для х32, не заводился на х64, только потому что все указатели кастились к DWORD, а не ULONG_PTR. Я также слышал, брань разработчиков, которые писали этот код и которые его в попыхах исправляли. Нужно было писать это
на диктофон, можно было бы сейчас нарезать неплохих мемов. Ругаться на платформу на которой что-то иначе, тоже самое что ругаться на то что солнце светит. Это объективная реальность. Мне не раз приходилось
переделывать свои работы, некоторые я переделывал 8 раз. Ибо, на каждом витке, я получал новую информацию, и новый опыт. Это нормально. Если бы каждый сокрушался на плохую платформу, я бы не добился нормальных результатов своей деятельности. Я извиняюсь, но люди которые занимаются подобной критикой, никогда не доводили ни одного дела до конца нормально. Это в своем роде, косвенный признак.
Еще раз подчеркну, я не утверждаю кто лучше, а кто хуже. И ни коим образом, не хочу в той или иной степени кого-то задеть высказывая свою мысль. Как я уже говорил, ядро Windows, мне импанирует больше.
Т.к. многие задачи решаются намного проще чем в Linux. Например, наличие центрального PnP. Банально, но это позволяет мне отслеживать любое устройство и его принадлежность в дереве устройств. Это например
позволит сделать универсальный DLP. Также центральный PnP, позволяет более эффективно управлять аппаратными ресурсами, пространство памяти, простанство ввода-вывода и т.д. Т.к. за это отвечает центральная подсистема, решения об управлении этими ресурсами будут куда эффективнее чем в случае, когда этих подсистем множество,
работу которых придется согласовывать. А это в своем роде лишний программный слой. Иначе говоря, костыль.
Наличие фильтрации, позволяет вносить новый функционал без доработки существующих драйверов, сторонних разработчиков или разработчиков Microsoft. По мне так, разработчки Windows и делали ставки именно на это, чтобы весь продукт можно было мастабировать на столько просто, на сколько это возможно. При этом не призывая на помощь другие команды. А фильтрация совместно с центральным PnP, позволяет более грамотно управлять тем же самым электропитанием, например. Т.к. все
мы знаем, что некоторые платформы делаются так, что несколько независимых устройств разных шин, могут запитываться одним источником. В случае с Windows, система навесит дополнительных фильтров на соответствующие устройства, и тем самым подсистема питания, центральная, будет знать, кто и от кого питается. При этом ей не нужно понимать на какой шине располагается устройство. И в сооветствии с этим она будет принимать решение, выключать источник, или нет.
Выгружаемая память в ядре, что позволяет выделять память в пространстве ядра большого объема. А говоря о менеджере памяти,
в Linux он сильно проще. Об этом хотябы говорит swap раздел, когда на Windows это файл. Есстественно работать с блочным устройством сильно проще, чем с файлом. Кстати не так давно, интереса ради установил truecrypt под ubuntu, и зашифровал swap. Результат убитый Linux. Сначала все повисло, после hard reset, система отказывалась грузиться. Сразу скажу, я знаю, что теперь Linux поддерживает и файлы. Но Windows это делал как минимум с nt 4.0. Такой более сложный менеджер памяти, позволяет более эффективно распределять имеющуюся физическую память. И безусловно это усложняет API ядра. Т.к. нам теперь надо какой пул мы хотим получить. Это к вопросу о 10 лишних аргументов.
Я могу говорить об этом много. Безусловно, такая реализация Windows имеет и недостатки. Например, из-за того что менеджер памяти Windows
сложнее, то на не сильных машинах, основной ресурс будет съедать именно он. Под несильными я имею в виду машины до 32мб
памяти, или вроде того. Windows плохо портируется на другие платформы, например потому что в ядре нередко ловяться исключения,
в случае с процессором который не умеет кидать исключений, результат окажеться печальным. Более того, все вышеописанные подсистемы
требуют ресурсы, а на платформах где они не нужны, он будут просто выедать их в холостую. И поскольку реализация Linux проще, то и
переносится он куда веселее. Лично я снимаю шляпу перед тем количеством платформ, которые он поддерживает.
Сравнивать можно долго. Везде найдем как плюсы, так и минусы. Модели этих ОС разные. Это объективный факт. И однозначно
говорить кто из них лучше нельзя, т.к. надо понимать какую задачу мы решаем.
Ну так, как-то.
khim
Swap-раздел обычно используется не потому, что swap-файлы Linux «не умеет», а потому что так быстрее и надёжнее.
И тем самым уносит требования к «железу» в небеса (что и погубило, собственно, Windows на смартфонах). В ядре Windows невыгружаемая часть — тоже есть и, как правило, она занимает больше чем в Linux — вся память, которую ядро требует в принципе на том же железе.
И это — типичная ситуация с восторгами по Windows. То есть обычно разговор выглядит так:
— Вот, в Windows есть классная фишка X, а в Linux — нет!
— Круто, но зачем она нужна?
— А вот потому что это позволяет решить проблему Y и Z!
— Но проблем Y и Z в Linux нету — зачем мне там X?
Иногда, тогда, когда какие-то вещи в Windows сделаны разумнее, они перекрёстках в Linux. Но так бывает редко. Гораздо чаще — это «крутое» решение проблем, которых, по большому счёту можно было просто избежать.
С какого перепугу? Процессор — это процессор. Если он чего-то не умеет, то он таки этого не умеет. Тут уж ничего не сделаешь. А вот когда процессор чего-то умеет, то, извините, я хочу чтобы OS этого умела тоже. А не как в Windows, где «тут умеем, тут не умеем, а тут — только для своих».
Возможно какие-то задачи в ядре — решаются проще. К сожалению за счёт того, что задачи, которые нужно решать с помощью ядра — решаются сложнее. Но, как мне кажется, ядро должно существовать для программ, а не программы для ядра.
Интересно, что в этом смысле Windows-мир и Linux-мир являются полными противоположностями: низкоуровневый API в Windows просто ужасен и когда с ним приходится сталкиваться — хочется кого-нибудь убить. Но «сверху» над ним сделаны обёртки, которыми пользоваться, в общем, довольно приятно (за исключением тех случаев когда «уши» от того ужаса, который находится «под капотом» выглядывают). В Linux, наоборот, «внизу» всё весьма изящно и красиво. А вот сверху над этим — гора разных поделок, над дизайном которых, похоже никто особо не думал. Типа тех же init-скриптов, которые отказались запускать вам систему с зашифрованным swap-разделом (интересно почему: так-то для работы Linux'а ни swap-раздел, ни swap-файл не нужны в принципе).
daggert
> И тем самым уносит требования к «железу» в небеса (что и погубило, собственно, Windows на смартфонах).
То-то у меня телефоны на виндах никогда не глючили, в отличии от блакберри и андроида. Причем банальный виндовый двухядерник с 512 оперативки работал лучше чем ведрышко 6 с четверкой ядер и двумя гигами, на тех-же задачах.
> И тем самым уносит требования к «железу» в небеса (что и погубило, собственно, Windows на смартфонах).
Берите еще выше — тонна оболочек, уже сравнимая с виндовыми фремворками, когда одно приложение на Qt, второе на vala, а нужное вообще из сырцов на питоне собираем… Лично я по этому и не стал разрабатывать под линукс, если в винде я могу сделать нативное приложение для актуальной платформы, используя последний фреймворк (последнее приложение было на телефон и стационарник в одном), то на линуксе приложение на gtk при переносе между разными платформами выглядело… не очень. Пришлось писать в вебе, чтоб не изучать плюсом qt, vala и черт еще пойми сколько разных вещей.
Am0ralist
Вы сейчас о чем? О том, что WinPhone с малым количеством оперативки работали плавнее и лучше андроидов в аналогичном ценовом сегменте?
Или еще о версии 6,5 какой-нибудь? Чью популярность сложно игнорировать.
И это я говорю, как непосредственно имевший дешевый и дорогой винфон 8 серии, а так же общавшийся с андроидами дешевых конфигураций (при сравнимой и даже большей цене за них при сравнении с мои дешевым за 3750 р), которые были убоги чуть более, чем полностью.
Или когда удобно, то в аргументах слышится, что андроид — это линукс, а когда нет — это игнорируется, как и жадность андроида до ресурсов, приведшего к появлению телефонов с овердофига количеством ядер и оперативки, которые частенько превышают подобные числа у компьютеров людей?
Но во втором случае можно заметить, что чистый полноценный линукс на телефонах так вообще не полетел от слова совсем (помянем убунтуфоны и прочие мииго). Так что ваш наезд в эту сторону не то что не в тему, а вообще демонстрирует не лучшее понимание этой самой темой.
PS. Пока отвечал — успели уже оставить аналогичный коммент…
khim
Эта версия не исползовала «расчудесное» ядро Windows NT, не поддерживала многозадачность и потому потребовалось, в лучших традициях Microsoft, «переписать всё с нуля». Вот только монополии на рынке не было и пока Microsoft этим занимался — всё было кончено.
Вы тут ставите телегу впереди лошади. «Овердофига количеством ядер и оперативки» на телефоне появились вследствие Закона Мура. А Android — начал с системы, которая ставилась на телефон с 256MiB флеша и 192MiB оперативки и постепенно был переписан, чтобы использовать фичи, доступные в современных SOCах.
Windows NT же со своим подходом «мы всё делаем только по-настоящему, на мелочи не размениваемся» к шапочному разбору в результате банально опоздала. В 2012м году, когда Windows Phone 8 появилась уже всем всё было ясно…
Мииго был убит засланцем из Майкрософт. А Ubuntu — появился гораздо позже Андроида и на вопрос «а что это такое было» ответить так и не смог. Но это мелочи: мы тут вроде ядро обсуждаем? Так вот Linux-ядро — отлично работало и на первых Android'ах с меньше, чем 256MiB оперативки (Windows Phone изначально требовалось 512MiB) и на современных телефонах с гигабайтами оперативки и полудюжиной ядер — тоже чувствует себя отлично. А Android… Android занимал «столько, сколько нужно». Windows Phone же вначале не мог использовать многоядерные системы из-за своего убого Windows CE ядра, а потом, когда телефонные SOC'и доросли до поддержки «правильного» ядра Windows NT… уже было поздно.
Вот чем кончаются попытки всё и всегда делать «правильно» и «не экономить на мелочах».
daggert
> Нука-нука. С этого момента поподробнее. WinPhone со 192MiB оперативки в 2008 или, так и быть, в 2009м году — в студию. Напомимаю что Android начался именно с такого.
В 2008 вполне себе здравствовал Windows Mobile, отлично работающий на 64 мегабайтах оперативки и первый андроид, который пытался повторить iOS, побеждал только ценой.
Теперь перенесемся в 2017 год — мой телефон Lumia 650 с 1 гигабайтом памяти и последней ОС Windows Mobile, который не тормозит и не глючит. Сравните с последней версией Android?
> Мииго был убит засланцем из Майкрософт.
Тут на хабре статья была про Нокию и ее предсмертные конвульсии. Почитайте на досуге, действительно интересно.
khim
Вот только там не было чудесного «правильного» ядра Windows NT, о котором мы тут говорим.
То, что было у Microsoft в 2008м и то, что есть у него в 2017 не «перетекают» из одного в другое — вот в чём беда! На «неправильном» ядре Windows CE и на «правильном» ядре Windows NT работают разные программы, а «гениальная» идея устроить переход через «чистый» C# — сделала всё только хуже!
Am0ralist
ЧТД.
Но вас это не смущает, мы видим.
khim
А почему это должно меня смущать? 4GiB памяти — нормальный обьём для 2017 года.
Тут же вполне себе зеркально отразилась история самой Windows!
В 1992 году IBM выпустила OS/2 2.0, а Microsoft — Windows 3.1. Но OS/2 2.0 требовала 8MiB оперативы (которых мало у кого было), а Windows 3.1 — довольствовалась 2MiB, а на 4MiB — и вообще «летала». Народ облизнулся на OS/2 и закупил Windows 3.1 в диких количествах.
IBM «учла урок». В 1994м году вышла OS2/ Wart 3.0, которая вполне прилично себя вела на 4MiB. А Microsoft выпустил в 1995м году Windows 95, которая для приличной скорости работы требовала 8MiB. Но к этому моменту 8MiB — уже никого не пугали и IBM снова оказалась в тёмном месте ибо Windows 95 отлично работала с программами для Windows 3.1! А те у кого дерег на 8MiB не было остались просто на Windows 3.1…
То же самое и здесь: важно не какая операционка лучше работает с каким-то определённым количеством опереативки. Важно какая операционка лучше работает с тем железом, которое есть на рынке! А вот это — определяется законом Мура…
daggert
> Да легко: мой Google Pixel с 4GiB RAM тоже не тормозит.
Прикрывать плохую реализацию многозадачности повышением характеристик… Надеюсь вы не пишите программы которыми я пользуюсь.
>Вот только там не было чудесного «правильного» ядра Windows NT, о котором мы тут говорим.
Я вам отвечал сугубо на ваш пассаж про прожерливость мобильной операционки, а не о правильности современного WP ядра.
> То, что было у Microsoft в 2008м и то, что есть у него в 2017 не «перетекают» из одного в другое — вот в чём беда!
Не буду спорить, но я не вижу в этом беды. Иногда надо избавляться от легаси.
khim
Причём тут «плохая реализация многозадачности»? Это просто типичные характеристики телефона 2017 года. Вы же не жалуетесь, что Windows 10 на машинках с 64MiB памяти нормально не работает? С когда-то это был огромный, мало кому доступный, объём памяти.
Понимаете — с точки зрения современного инженера какой-нибудь каменный мост, который стоит 1000 лет — это провал. Потому что это значит, что в его строительство было вбухано в 10 (если не 100 раз) больше ресурсов, чем это было реально нужно для решения поставленной задачи.
То же самое и с операционками: если они не работают на имеющемся железе — плохо, вы никому их не продаете, но если они могут работать на 1/10 того, что есть — то это тоже не слишком хорошо: вы могли бы ресурсы, которые были затрачены на «выжимание из программы всех соков» потратить на что-либо другое.
В прошлом веке Microsoft и его пользователи это очень хорошо понимали. Про историю с OS/2 я уже писал, но ведь и Excel (требовавший в 2-3 больше ресврсов, чем Lotus 1-2-3) и WinWord (занявший нишу WordPerfect за те годы, когда его разработчики пытались написать версию для Windows на ассемблере) и многое другое — было сделано по этому шаблону. А вот в XXI века их то ли гордыня обуяла, то ли память отшибло — и они ринулись «махать кулаками после драки». Ну вот скажите на милость: зачем было тратить время и силы на поддержку устройств с 256MiB памяти в то время как в работе уже была следующая, несовместимая версия, ставившая на этих железках крест? Это же в чистом виде повторение ошибок OS/2!
Но ведь это связанные вещи! Когда смартфоны располагали только лишь 128MIB-192MiB памяти это самое «правильное» ядро не позволило выпустить то, что можно было продать. И тот факт, что за счёт оптимизации UI на «подросших» смартфонах через 3-4 года вся конструкция стала требовать меньше памяти, чем платформа конкурентов, тратящая появившиеся ресурсы на всякие вау-эффекты — он же уже никого спасти не мог!
Вы каким браузером пользуетесь?
daggert
> При наличии живых конкурентов это обычно обозначает избавление от соответствующего подразделения. Кто у нас там решил таким изысканным образом умереть? Nokia, Palm, RIM. Ах, да, ещё Microsoft. Или кого-то забыл?
Да, вполне, соглашусь, однако майкрософт обвиняют очень часто в инертности.
> Причём тут «плохая реализация многозадачности»? Это просто типичные характеристики телефона 2017 года. Вы же не жалуетесь, что Windows 10 на машинках с 64MiB памяти нормально не работает? С когда-то это был огромный, мало кому доступный, объём памяти.
Windows 10 работает успешно на 35м чипсете и четырех гигабайтах памяти, на компьютере купленном почти 10 лет назад, по этому не жалуюсь (: Правда в телефонах это иначе, однако мой HTC Radar успешно обновлялся три года (вроде как) и даже сейчас работает как в первый день покупки.
> Это же в чистом виде повторение ошибок OS/2!
Это неудачная попытка захвата рынка говнофонов, который занят телефонами на андроиде где даже нажатие кнопки меню глючит. Примерно как потуги гугла с chrome os, и мозиллы с firefox os.
> Когда смартфоны располагали только лишь 128MIB-192MiB памяти это самое «правильное» ядро не позволило выпустить то, что можно было продать.
Это буллшит маркетолога. Людям не нужна оперативка/проц, им нужна работа программ и в windows CE с этим было отлично.
> И тот факт, что за счёт оптимизации UI на «подросших» смартфонах через 3-4 года вся конструкция стала требовать меньше памяти, чем платформа конкурентов, тратящая появившиеся ресурсы на всякие вау-эффекты — он же уже никого спасти не мог!
Платформа конкурентов изначально требовала больше памяти, была хуже на UI, однако финансовые вливания гугла и удобный момент сделали свое время. Майки слили, с этим спорить просто глупо и я этим заниматься не буду, я адекватно вижу минусы платформы, однако я напомню что в момент выхода 2.3 версии (2010 год) — минималочка для андроидофонов была 512 мегабайт, чтоб уместить не только ОС, но и пару приложений, один в один как на WP 7.5, в тот-же год. Телефоны с меньшей памятью тупили даже на наборе номера.
> Вы каким браузером пользуетесь?
Хром, в основном, но переползаю IE, ради синхронизации полной десктопа с телефоном.
khim
Платформа кокурентов — вышла на рынок в 2008м году, Windows Phone на базе Windows NT — вышла на рынок в 2012м, через 4 года. Потому что на железе 2008-2009 годов она просто была неработоспособной.
Классическая технология, с помощью которой Microsoft убеждал пользователей в прошлом веке игнорировать предложения конкурентов и подождать годик-два-три-четыре не сработала, так как на рынке смартфонов покупателями являлись в основном люди не слышавшие в принципе ни о Майкрософте и не желавшие ждать пока «правильное» решение поспеет. Они взяли то, что им предлагали «здесь и сейчас».
Извините, но не соглашусь. Как человек просидевший на HTC Dream и пользовавший там, в том числе, 2.3. Вот 4.0 — это было резкое повышение требований и да, там о телефонах с 256MiB памяти (не говоря уже о 192MiB, как у HTC Dream) — оставалось только мечтать.
Тогда у вас есть шансы столкнуться с написаннам мною кодом. Хотя, как я уже заметил, попытки сделать кроссплатформенное решение мы оставили и «задел» для соответствующей подсистемы из Хрома сейчас убирают…
Кто-тот тут говорил о том, что 10% в европейских странах и России — это было круто для Windows Phone. Ну так у ChomeOS в США больше на рынке лэптопов. В в школах — она вообще доминирует.
Это не значит, конечно, что у неё безоблачное будущее: как я уже говорил у OS/2 было 40% рынка в Германии в 1995 году, но… не надо её сравнивать с FirefoxOS, которая дальше пары экспериментальных моделей не пошла…
daggert
> Проблемы в том, что в Windows CE не было предусмотрено поддержки многоядерных систем, принцип «на мелочи не размениваемся» потребовал перехода на ядро Windows NT — а его уместить в нужные параметры за счёт «правильной архитектуры» было, увы, нельзя.
Соглашусь с вами
> Платформа кокурентов — вышла на рынок в 2008м году, Windows Phone на базе Windows NT — вышла на рынок в 2012м, через 4 года. Потому что на железе 2008-2009 годов она просто была неработоспособной.
Сравнивать гипотетические вещи — моветон, сравнивайте с реальными конкурентами, делая срез по времени.
> Классическая технология, с помощью которой Microsoft убеждал пользователей в прошлом веке игнорировать предложения конкурентов и подождать годик-два-три-четыре не сработала, так как на рынке смартфонов покупателями являлись в основном люди не слышавшие в принципе ни о Майкрософте и не желавшие ждать пока «правильное» решение поспеет.
Эм, а что майкрософт предлагал во времена заката CE 6.0 и чего просил подождать людей?
> Извините, но не соглашусь. Как человек просидевший на HTC Dream и пользовавший там, в том числе, 2.3. Вот 4.0 — это было резкое повышение требований и да, там о телефонах с 256MiB памяти (не говоря уже о 192MiB, как у HTC Dream) — оставалось только мечтать.
В 2012 году у меня был HTC Radar и сравнивал я его в живую с HTC Evo 3D, имевшим лучшие характеристики и худшее юзабилити, в особенности «вязкую камеру» запомнил. Сравнивайте одновременно вышедшие телефоны.
> Кто-тот тут говорил о том, что 10% в европейских странах и России — это было круто для Windows Phone. Ну так у ChomeOS в США больше на рынке лэптопов. В в школах — она вообще доминирует.
Это результат прямого вливания бабла. Как только «дешевые ноубуки» закончатся — об ОС сразу забудут.
khim
В 1991м он обещал «промежуточную» систему (которой стала Windows95) через два года и великолепную Windows Cairo
c блекджеком и шлюхамис обьекто-ориентированной файловой системой и прочими чудесами (частично реализовано в Windows XP, частично не реализовано вообще) — через четыре.То же самое было и в 2008м-2009м годах. Только вот на этот раз никто ждать обещанного «три-четыре года» облизываясь на красивую картинку и не имея ничего в руках не захотел.
А почему, собственно? Да и потом: какое имеет отношение «HTC Radar» к «правильной» Windows на ядре Windows NT? Что Windows CE имеет весьма низкие требования к железу — я в курсе. Но так как мы ненавидим BKL и «на мелочи не размениваемся», то она оказалась тупиком. А дальнейшее — уже история.
А почему, собственно, они должны закончится? Или вы думаете Google производителям хромбуков доплачивает? Нет — они с прибылью продаются. С небольшой, конечно, ну так сверхдоходов никто и не обещал.
daggert
> То же самое, что и во времена Windows 3.1: красивую картинку. Когда-нибудь. В будущем.
Какую? Вы наверное не помните — ничего не предвещало смерть Windows Mobile 6.0, она была актуальна. До анонса «чего-то нового» было еще пару лет.
> В 1991м он обещал «промежуточную» систему (которой стала Windows95) через два года и великолепную Windows Cairo c блекджеком и шлюхами с обьекто-ориентированной файловой системой и прочими чудесами (частично реализовано в Windows XP, частично не реализовано вообще) — через четыре.
Я не знаю что было в эти годы, был слишком мал, правда судя по википедии — cairo был типичным проектом microsoft research.
> То же самое было и в 2008м-2009м годах. Только вот на этот раз никто ждать обещанного «три-четыре года» облизываясь на красивую картинку и не имея ничего в руках не захотел.
В 2009 я получил семерку, до нее получил висту. Честно говоря не могу вспомнить промежуточных рекламных вещей. Longhorn помню, но он был ранее и о нем я узнал после выхода висты.
> А почему, собственно? Да и потом: какое имеет отношение «HTC Radar» к «правильной» Windows на ядре Windows NT? Что Windows CE имеет весьма низкие требования к железу — я в курсе. Но так как мы ненавидим BKL и «на мелочи не размениваемся», то она оказалась тупиком. А дальнейшее — уже история.
Как минимум это не правильно. Вы сравниваете разные поколения систем, игнорируя факт что системы одного поколения (WP 7.8 vs android 4.0) имеют разные требования, не в пользу андроида. Про ядро — я не могу вам ответить, ведь мне, как пользователю, всегда было плевать, и я опять-же отошлю вас перечитать тот вопрос, на который я вам отвечаю.
> А почему, собственно, они должны закончится? Или вы думаете Google производителям хромбуков доплачивает? Нет — они с прибылью продаются. С небольшой, конечно, ну так сверхдоходов никто и не обещал.
Весь доход от хромобуков убивают дотации для захвата студенческого рынка. Сейчас гугл тупо вливает бабло для захвата рынка, причем сами хромобуки — ок, но вот система — мертворожденная, что показывает ее доля на рынке.
PS: минусы вашим постам не я ставлю.
Am0ralist
Ага, только доля Винфонов с которыми «все было кончено» еще в 2012 году — в 2015 году достигала более 10% в европейских странах и России. Слив произошел в 16 из-за других причин и не имеет никакого отношения к производительности или неудачности ОС.
Классно передернули, к ОС 2012 года притянули параметры систем 8-9 год и потребовали им соответствовать, хотя за это время требования к функционалу выросли значительно. Хотите сказать, что в 12 году андроид такие же требования выдвигал, правда-правда?
Так что, давайте-ка сравнивать аналоги одного временного периода, а то я потребую вообще, чтоб андроид на 32 мегабайтах работал — ведь когда то раньше были устройства, которым этого хватало, но при этом так же потребую поддержку фуллшд экрана. Не все ж вам ворота двигать.
А в тот же период вдруг окажется, что андроиду 512 — ваще никак уже было, как минимум гиг требовать начал, хотя интерфейс все равно оставался задумчивым. А появившиеся позднее смарты с 8-кой на том же гиге — уделывали по цена/качество всех в том же низком ценовом сегменте для пользователя, проигрывая исключительно за счет количества приложений.
И да, Вы лично пользовались теми устройствами? Ибо я — да. Поэтому мне сказки о том, что андроид занимает сколько надо — не надо рассказывать. Особенно смешно было сравнивать с работой смарта более чем в два раза дороже стоившего. Хотя, может быть, на нем игрушки и лучше фпс выдавали, но не прочее точно.
Бедный Мур, как что, так сразу его приплетают (прям как и другую известную личность), пытаясь оправдать прожорливость систем, которые написали программисты. Нафиг никому не нужно было бы в дешевом сегменте таких наворотов, если бы устройства могли бы работать сносно и на меньшем. Не могут.
Миго был убит, так как нафиг никому не нужен был в реальности, кроме пары десяток гиков, как и убунту, и фаерфоксос. Винда была нужна (циферки вверху для примера), но ее слив совпал с изменением руководства компании. То есть если не выпускать новые версии смартфонов, а потом вообще уйти с кучи рынков — то естественно, что доля упадет в ноль, вот только к удачности ОС это никак не будет относиться.
khim
Нет конечно. Но выводить на рынок новую OS для смартфонов нужно было в 2008-2009м годах (новую — в смысле не поддерживающую программы, написанные для «старых» OS, а не в смысле что у неё все компоненты новенькие, свеженаписанные). В 2010м — ну… может быть, уже почти поздно. К концу же 2012 почти половина продающихся телефонов была смартфонами — а значит тот, кто захватывал в этот момент рынок — тот и оставался.
Да легко — только обьясните почему вы хотите видеть ворота именно там.
Нет, не пользовался. А вот с Windows CE — возился. И я — не одинок. В этом-то всё и дело! В момент, когда Windows Phone на базе Windows NT довели до ума «поезд уже ушел»! Она уже в момент выхода почти никого не интересовала — и было понятно, что жить ей осталось недолго.
Её слив совпал с моментом, когда «первичные» (покупающие смартфон впервые) покупатали смартфонов стали «вторичными» (покупающими, как правило, то, что у них уже было). А вот то, что операционка не была готова выйти на рынок до этого момента — как раз и делает её плохой.
Нет, его привлекают чтобы описать железо, которое будет доступно в тот или иной момент времени. А софт… софт занимает все ресурсы, которые ему дадут занять.
Разработчики ядра бьются за то, чтобы его можно было впихнуть во всякие маломощные IoT устройства и в суперкомпьютеры — так что оно работает и на машинках с 32MiB и на системах с тысячами процессоров. Андроид затачивается под то железо, что есть на рынке — и выигрывает.
А Windows Phone на базе Windows NT — проигрывает, потому что «в нужное время, в нежном месте» оно оказывается неготово, вот и всё.
qw1
Там ядро ближе к NT, чем к 9x, потому что формат модулей ядра был PE, актуальном в текущей винде, а не LE, который были в *.vxd-драйверах 9x.
Userspace вообще сказка — убрали не-unicode api, которые никак не выпилить из десктопа, чем кардинально решили проблему с кодировками.
Многозадачность там была нормальная. Окна сворачивались на панель задач, навигатор в фоне работал, писал трек. mp3-плеер играл (кстати, собранный из открытых исходников и допиленный). Что ещё надо…
khim
Поддержку восьмиядерных процессоров?
Как бы вся наша дискуссия вертится вокруг big kernel lock и учёта всех требований, которые были необходимы на момент разработки. И всё, что я хочу показать, так это то, что big kernel lock — был хорошим решением. Ибо позволил решить задачу «малой кровью», а потом, в конечном итоге — его выпилили.
Попытка же «учесть все требования, которые необходимы на момент разработки» приводят к созданию монстра, который может жить только в тепличных условиях, когда все конкуренты уничтожены.
Но похоже что это — натуральное побуждение всех больших компаний. Вот и Google занялся этой же фигнёй…
qw1
mayorovp
"Ядерный" не знает как минимум про текущую директорию, логические диски и устройства dos — это все фичи подсистемы win32. Также он, скорее всего, не редиректит папки Program Files и system32 в 32х-битных приложениях и не выполняет виртуализацию Program Files в режиме совместимости.
qw1
Хороший обзор. Но эти «недостатки» позволяют назвать это АПИ ужасным?
khim
В Linux'е же, наоборот — над простыми и понятными
creatиopenнастроены страшные GObject-конструкции, которые ещё и каждые несколько лет меняются непредсказуемым образом.qw1
.NET совершенно не минималистичный. Под одним File.Create — 100500 перегрузок, начиная от простого открытия файла по имени, до версии со всеми параметрами, доступными в CreateFile.
qw1
MacIn
И таки Win95 тут поможет :D
qw1
Открытая IDT — дыра в ring0 )))
MacIn
Этим и пользовался WinCIH, если я верно помню (проглядывал когда-то его исходники).
dartraiden
Разработчики Ubuntu, кстати, отказываются от swap-раздела:
grossws
Выделять двукратный размер при современных объёмах уже давно не предлагают. Особенно на серверах.
Я довольно давно использую sparse swap-файлы на ssd. При использовании https://github.com/Nefelim4ag/systemd-swap вполне нормально работают наборы swap-файлов, которые создаются по мере необходимости.
MacIn
Еще, насколько я помню, у Linux было преимущество по части realloc in-place.
mayorovp
Насколько я знаю, в Long mode такая штука как LDT попросту отсутствует независимо от того, 64-битный режим активен или режим совместимости. Поэтому 64-битная ОС не может предоставить такое API даже для 32х-битных приложений.
Разбирался в вопросе по Википедии, если что не так — прошу поправить.
anatolymik
В режиме совместимости работает.
mayorovp
Хм, был не прав, оно и в 64-битном режиме работает. Либо в вики фигня написана, либо я как-то не так прочитал.
Вот со второй попытки нашел мануал где все расписано: http://developer.amd.com/wordpress/media/2012/10/24593_APM_v21.pdf
anatolymik
В х64 не работает, т.к. база для сегментов cs, ss, ds, es не загружается. Она всегда 0, для этих сегментов. Для fs и gs загружается, но только первые 32 бита.
khim
anatolymik
Загружаются, при помощи специальных инструкций нулевого кольца. При загрузке индекса в сегментный регистр — нет. Только 32 бита.
khim
На современных процессорах можно вообще из обычной программы всё сделать через WRFSBASE/WRGSBASE если операционка это поддерживает. Вы думаете эти инструкции появились потому что никому базу менять не нужно? Ну да, конечно.
anatolymik
Мы говорили, про загрузку в сегментный регистр индекса, хотите сказать что в этом случае база сегмента не загрузиться из дескриптора? Если вы утверждали это, то давайте отрывок из даташита.
> На современных процессорах можно вообще из обычной программы
Можно, дальше то что?
khim
Потому что Windows (и, позднее, Windows CE) изначально была рассчитана только на однопроцессорные системы — и поддержку каких-либо других добавить никто не пытался ни туда, ни туда.
А OS/2 3.0 — да, она изначально под SMP затачивалась, так что было бы странно если бы она его не поддерживала.
anatolymik
Возьмите исходники и сопоставьте. Вы найдете очень много совпадений.
khim
Но сомневаюсь я что-то что из Windows в Windows NT перекочевало много кода. Катлер изначально стремился ровно к противоположному.
anatolymik
Насколько я понял, мы вели речь об NT. Касательно линейки 95, я могу ошибаться, но помоему этим занималась отдельная команда.
khim
Совершенно верно. И там, где Linux получил «костыль», который со временем выпилили, там Windows — получил новое ядро, написанное с нуля.
Вы уверены что это — лучший подход к разработке?
anatolymik
Насколько я знаю, ветка NT получила свое начало до Windows 9x линейки.
Даже если так, этот подход в разработке себя я так понимаю не оправдал? Ничего не работает, все падает, старый софт не заводиться?
Я предлагаю, закончить этот бессмысленный разговор.
khim
anatolymik
Без комментариев.
qw1
sumanai
Тут явно путают саму ОС Windows, существующую в нескольких слабо связанных друг с другом линейках, и ядро ОС.
Все современные Windows работают на ядре NT, про которое и пишут, что оно изначально поддерживает SMP. Вспоминать сейчас линейку Windows 9x, внутри которых чуть ли не DOC, сейчас так же актуально, как и вспоминать Linux 1.0.
khim
BKL — появился в момент превращения Linux 1.0 (не поддерживающий SMP) в Linux 2.0 (поддерживающий SMP, пусть и с «костылём»).
Аналогичный процесс «в стане Microsoft» — это превращения линейки «классической Windows» в Windows XP. При котором было переписано всё ядро, полностью, с нуля. Потому что подход «делаем всё „по-настоящему“, но костыли, которые мы при этом породим потом никогда не изводим» себя исчерпал.
«Подход Linux» — был осуществлён одним человеком за примерно год работы, после чего, правда, пришлось потратить годы на выпиливание соотвествующего костыля.
«Подход Microsoft» — привёл к тому, что команда из десятков отличных разработчиков работала чуть ли не 10 лет и, после потраченных миллиардов долларов, смогла завершиться успехом только потому, что Microsoft обладала монополией на десктопе.
Аналогичный процесс на рынке PDA/смартфонов привёл к тому, что Microsoft оный рынок потеряла. Полностью. Совсем.
sumanai
Вы сами ответили, что он появился в 2.0, и просуществовал до 2.6, то есть уже не так давно.
DOS и надстройки над ним писались через пень-колоду.
А как же хвалёный опенсорс? Или тогда в разработке Linux никто кроме Торвальдса не участвовал?
Не аналогичный.
NT позволяла запускать на себе большую часть софта линейки Windows 9x, что было одним из требований к разработке этой ОС. Поэтому она и взлетела.
На рынке мобильных же устройств МС пару раз закапывала старые ОС и выкатывала новые, которые не были совместимы ни со старыми программами, ни со старым железом. Результат немного предсказуем.
khim
А кто вам сказал что этим Линус занимался? Этим как раз совсем другой человек занимался. А Линус только советовал и облизывался, так как денег на SMP-машину у него тогда не было. Они тогда как самолёт стоили.
А вот Коксу Caldera такую машинку прикупила — и денег дала, чтобы он годик работал над поддержкой SMP.
Вдумайтесь: то, на что в Microsoft потратили несколько лет команды из не одного десятка человек, кучу специализированного железа и прочего в случае с Linux'ом — сделал один человек, которому купили один комп!
При этом Linux 2.0 с поддержкой SMP — был гораздо, гораздо, ГОРАЗДО более совместимым с Linux 1.0, чем Windows NT с Windows 3.1.
Так ли уж ужасен BKL, который, к тому же, в конце-концов извели, если сравнить все «за» и «против»?
О как. А ничего, эти 32-битные надстройки писались в те же годы, что и, собственно, Windows NT? То есть у нас в одной компании работает «группа товарищей», которыая всё пишет «через пень-колоду» и «аккуратисты, которые всё делают грамотно». Простите, но… не верю.
Извините, но… нет. Взлетела она только тогда, когда поддержка Windows 9X была прекращена. Windows 98 была в ходу ещё долгие годы после выхода Windows XP. Именно потому что ни о каком запуске «большей части софта» и речи не шло.
16-битный и, особенно, DOS-софт работал вообще отвратительно.
А почему она это делала — не напомните? А вот всё потому же: потому что Windows CE не получалось довести до ума и добавить туда все необходимые фичи.
Ещё одна команда, работающая через одно место, в той же компании?
sumanai
Но так и было. Был нанят отдельный специалист во главу, который собрал себе отдельную команду разработчиков и пилил ОС в своё удовольствие, опираясь на опыт своих прошлых разработок, за что потом с МС судились даже.
Просто это совпало с выходом клиентских NT.
Скорее маркетинг, а это просто отговорка.
qw1
MS же просто делало слой совместимости (и довольно неплохо), перехватывая
int 67h, там API у надстроек было более-менее одинаковое. Но иногда DOS-программы не работали в Win9x, если использовалась экзотическая надстройка.khim
В данном случае под «надстройкой над классической Windows» я понимаю Win32 подсистему в Windows 9X. И совершенно непонятно что мешало сделать её достаточно надёжной и поддерживающей SMP. Почему для решения этой задачи было недостаточно введения BKL с последующим избавлением от него, а потребовалось всё выкинуть и написать новое ядро с нуля.
qw1
Тут обычный вопрос с приоритетами и захватом рынка. Опоздай на 2 года, и рынок был бы у OS/2. Поэтому все силы — на совместимость с DOS и на пиление «рюшечек» в интерейсе, а также на офисные пакеты, мультимедию, игровые API. Увы, тут уж не до ядра…
sumanai
Да всё мешало. Код старых версий был гвоздями прибит к одному процессору и задаче, большинство ядерных функций были не реентабельными, то есть если одна программа вызывала эту функцию, то остальные тупо ждали вместе с самой системой.
Семейство Windows 9X на половину было написано на ассемблере, что мешало задаче портируемости на другие платформы.
И т.д. и т.п.
В общем они правильно сделали, что взяли и выкинули старый код в пользу уже имеющегося и надёжного кода NT, который писали для серверных систем и прочих военных.
khim
Откуда сведения? Что там в 16-битной части было много асма — верю. Ну так его можно было выкорчевать и заменить потихонечку. Выкидывать всё и переписывать всё с нуля было совершенно не нужно. А 32 битная часть… сомневаюсь я что там было так уж много асма.
sumanai
Её самой там было не так уж много.
khim
К началу XXI века? Дисковые драйвера, сетевые, DirectX, USB и куча всего ещё — были 32 битными. Я думаю типичная WIndows 98 система содержала больше 32-битного кода, чем 16-битного.
qw1
Не важно, сколько в процентах было 32-битного кода.
Важно, что база GDI, USER и прочие критически важные части были 16-битные и не портируемые.
khim
sumanai
Вы не понимаете одного- NT уже была почти создана, в рамках совершенно другого проекта. Просто они взяли и прикрутили системные вызовы WinAPI к ядру NT, так как оно изначально поддерживало возможность добавления подсистем совместимости, когда поняли, что WinAPI популярно, а старое ядро никуда не годится.
khim
Вы уверены, что это было быстрее, чем постепенный рефакторинг старого ядра?
Угу. Проекта по захвату ранка рабочих станций. Который закончился полным и оглушительным провалом. Но это — уже другая история.
sumanai
Да ладно? Совместимость с новыми версиями скорее уменьшалась, ровно как уменьшалась необходимость в ней.
Партнёрство не удалось, что поделать. Пришлось идти другим путём.
qw1
Разумеется. Когда есть 16-битное ядро, в которое рандомно воткнуты 32-битные куски, тут только «господь, жги».
Примерно так выглядело что-то низкоуровневое
http://www.drdobbs.com/windows/direct-thunking-in-windows-95/184410046
sumanai
С самой первой NT. Это было требование во время её разработки, пруф ищите в книге «Внутреннее устройство Windows» нужной вам редакции, уверен, что это написано в самом первом издании.
grossws
IIRC портируемость и потенциальная поддержка SMP растут из полуоси от IBM.
А вот насколько оно реально (и насколько костыльно) было реализовано в, скажем, NT4 я не имею понятия. Потому и спрашивал.
В общем, ваш ответ, как минимум, предметный, так что ловите +1 в слово-которое-нельзя-называть.
sumanai
Именно костылей там не было, но проблемы, точнее просчёты планирования или просто недоработки, присутствовали, хоть и не такие эпичные, как BLK.
Например в 2003 сервере ввели отдельный на каждое ядро список потоков, находящихся в состоянии отложенной готовности, чтобы не было глобальной спин-блокировки PRCB-блока. В семёрке так же избавлялись от некоторых блокировок или заменяли обычные блокировки на блокировки с заталкиванием указателя, которые быстрее.
khim
Это была вещь, которая должна была изначально поддерживать SMP и кучу процессоров (а потому разрабатывалась для 80860, а не для какого-нибудь распространённого процессора). Первая версия вышла для x86, MIPS и DEC Alpha. Причём именно из-за последнего в Windows 10 невозможно аллоцировать память с гранулярностью 4K.
DrPass
Справедливости ради, прямой путь для решения подобных проблем в случае закрытых исходников — не тот, который вы указали, а «написать в Майкрософт, с указанием примера, воспроизводящего проблему, и пусть они сами с ним разбираются».
anatolymik
Именно так я и поступил. Об этом было отрапартовано в Microsoft, еще год назад. И несколько месяцев назад я вел переписку с ними.
xRay
А какое решение приняло Microsoft? Баг будут исправлять?
anatolymik
Об этом мне не доложили. Мне только дали понять что в соответствии с их терминологией, подобная ошибка не является уязвимостью.
MacIn
Точно не надо никаких привилегий для открытия $mft?
Наверняка, они имеют в виду, что если ты можешь выполнить подобный код, то ты УЖЕ на клиентской машине и можешь уже сделать и что-то более нехорошее. On the other side of airtight hatch, как пишет Рэймонд Чен.
anatolymik
Проверка привилегий выполняется после того как файл будет найден драйвером. А он не будет найден.
monah_tuk
Интересно, а такое является: https://htrd.su/wiki/zhurnal/2017/04/24/ideja_dlja_badusb? В посте озвучено описание проблемы (т.е. не совсем идея) с которой столкнулся на проекте.
anatolymik
Важно понимать вред. На вскидку сложно сказать. Я не догадывался как можно использовать описываемый баг на момент написания. Когда тут многие уже эксперементировали с html.
FractalizeR
И каковы результаты?
anatolymik
Пока никаких)
rezdm
На моей памяти, мы репортили три бага
Первый баг — приняли как баг, потом в kb/hf можно было увидеть, кто зарепортил.
Второй баг — приняли, но что стало не помню.
Третий баг — самый сложный, ибо его воспроизведение занимало 36 часов, и я уже ушёл из той конторы.
Если я правильно понимаю, политика принятия багов таки изменилась с тех пор.
anatolymik
Мне сложно судить, ибо как правило, мне приходилось адаптироваться под особенности ОС, если таковые выявлялись в процессе реверса.
MacIn
del.
MacIn
Каким образом (путем) вы репортили баги? Я пытался дважды зарепортить кое-что, ни разу не смог добиться какого-то ответа.
anatolymik
Один раз это было на форуме OSR. Давно. Человек из Microsoft, ответил что зафиксировал. Недавно была переписка через secure@microsoft.com.
rezdm
Тогда, давным-давно это было ссылкой в msdn-е, оттуда. Дальше — перепиской.
MacIn
Угу. А когда мне потребовалось, меня послали, ну не 3 буквы, но «пишите на форум technet, если никто не даст ответа, и это окажется действительно ошибкой, то мы свяжемся. Если тема „не взлетит“, создайте еще раз (sic)», потом послали меня в твиттер техподдержки клиентов, где пообещали выделить инженера для рассмотрения вопроса, но все так и осталось без ответа.
semmaxim
Реальная популярность Windows и Linux на десктопах несколько опровергает Ваше мнение о том, что именно первостепенно.
gotch
Доступ к исходникам можно получить — https://www.microsoft.com/en-us/sharedsource/
Только это можно не всем и не всегда бесплатно. 10 000 рабочих станций под Windows и Enterprise Agreement, юридическое лицо в особо доверенной стране — и код ваш.
red75prim
Попытаться отправить в апстрим, получить ответ, что это ломает ххх версии ууу девяносто забытого года. И поддерживать свой патч в своей организации до победного конца.
VBKesha
Простите что я написал не так:
Запускаю ничего не виснет ;(
PS. Win XP SP3
anatolymik
В коде ошибка. Не L«C:\\$mft\123», а L«C:\\$mft\\123». Так заработает.
VBKesha
ХМ исправил, либо я не пойму что должно случится, либо ничего не происходит. Выложите свой тестовый пример в откомпилированном виде.
anatolymik
Просто скопируйте этот код, и соберите еще раз. После того как запустите, создайте папку на диске C. Должно зависнуть. Эффект не всегда мгновенный. Как правило, в пределах первой минуты будет результат.
anatolymik
Только что проверил на Windows XP. Действительно не зависает. Извиняюсь за ошибку.
anatolymik
Начиная с Windows Vista, зависает. Только что проверил. Спасибо.
VBKesha
На 10 протестили тоже не повисла.
anatolymik
Какой BUILD?
VBKesha
14.393.11.98
anatolymik
Касательно 10, после обновления перестало виснуть. Видимо исправлено.
VBKesha
Проверил на Win7 достаточно в консоли написать
cat c:\$mft\123anatolymik
Откорректировал материал, Вам спасибо!
VBKesha
Ну тут всё ещё веселей если например использовать такой путь как url картинки, то Chrome нормально отрабатывает, а вот IE валит систему.
anatolymik
Пишите статью, уверен будет интересно.
Goodkat
Firefox тоже валит — я решил сперва протестировать на себе, прежде чем писать тут комментарий :)
Валит не сразу, примерно с минуту всё нормально, потом всё намертво висит.
anatolymik
Пошла импровизация)))
monah_tuk
Пошла эксплуатация :)
CaptainFlint
Проверил у себя, Win7 со всеми обновлениями:
1. Opera 12.18, Firefox 53, Vivaldi 1.9 — валят систему ТОЛЬКО если файл с таким урлом открыт с локального диска. Если его же открыть по HTTP с удалённого веб-сайта, то доступ к локальному файлу не производится, и система не зависает.
2. IE 11 — плевать хотел на безопасность, даже при открытии по HTTP сразу лезет грузить локальную картинку и всё вешает.
Goodkat
Попробуйте вместо картинки сделать редирект на этот адрес или открыть url в iframe.
CaptainFlint
Аналогично. Нормальные браузеры послылают локальные ссылки лесом что в iframe, что в редиректе; IE радостно хавает и то, и другое. (Проверял только по HTTP.) Редирект смотрел только http-equiv. По-хорошему, надо бы потестить и через 301, и через JS, плюс картинку попробовать через тот же JS проинициализировать, но и так уже много времени убил.
sergey-b
Я думал, браузеры уже давно не открывают локальные ресурсы по ссылкам с внешних страниц.
Goodkat
Ну я тоже так думал, но мы тут только что успешно завесили несколько Windows7-машин через урл в теге img :)
sergey-b
Я бы предложил проверить Аутлук. Отправьте сами себе письмо со ссылкой на картинку с хитрым адресом.
CaptainFlint
Ну так браузеры и не открывают. Открывает только IE. ;-)
sergey-b
Точно. Кроме браузеров. Есть же и другие программы, которые по ссылкам умеют лазить, в том числе и производства Микрософт. Что у нас есть? Скайп какой-нибудь, антивирусы. Например, что-нибудь такое в архиве прислать, чтобы Windows Defender поискал хитрый путь. Есть что поисследовать.
CaptainFlint
Это да, простор в любом случае открывается широкий.
Goodkat
Ярлык.lnk можно сделать — я лет уже 17 назад как-то открыл файл ярлыка текстовым редактором доснавигатора и случайным образом потыкал в клавиши, а потом сохранил. После этого Windows Explorer и Windows Commander зависали в папке с этим ярлыком. Жаль, я не сохранил этот файлик себе на память.
sergey-b
Да это же знаменитый con/con bug из Windows 98!
nwatch
Win8.1 со всеми обновлениями dir c:\$mft\123 — зависает сразу-же, при попытке перезагрузки синий экран.
anatolymik
Этот эффект я тоже встречал. Я намеренно написал упрощенно данную статью. Если не делать через тестовый пример — то да, можно добиться синего экрана. Этот случай я уже не реверсил.
sergey-b
Отформатировал флэшку под NTFS. Думал, выну ее из разъема после эксперимента, и все будет в порядке. Как бы не так. После выполения указанной вами команды съемный диск остается, explorer зависает, taskmgr не запускается.
kernelconf
Ничего себе! Ну, всё, конец терминальным серверам, учитывая простоту кода.
anatolymik
Вот об этом я не подумал.
paranoik
Ничего в мире не меняется, сразу вспомнил con bug.
MacIn
Это таки не баг.
funny13
смотря как использовать
Goodkat
c:\con\con 2.0
smilyfox
Если не считать это уязвимостью, при том, что удалённый доступ злоумышленнику по сути не нужен, то я теряюсь, что можно считать.
anatolymik
Если есть локальный, тогда да. Это уязвимость.
Pochemuk
Не понял всего ужаса фразы, но звучит устрашающе:
"… если выполнить перезагрузку, то система повиснет на ней".
Т.е. после таких экспериментов система перестает загружаться от слова «совсем»?
Чем в таком случае лечить? Диагностика ФС из набора MS DaRT помогает? Или какие сторонние средства?
anatolymik
Диагностика ни чем не поможет. Говоря о повисании на перезагрузке, я имел в виду что экран перезагрузки будет висеть вечно. И поможет только hard reset. Далее система загрузиться нормально. Также, этот случай актуален только когда мы выполним обращение к такому файлу не на системном томе.
Pochemuk
У-ф-ф… Напугали… А я думал уже, что кирдык всей ФС, причем неремонтируемый даже при загрузке с диска MS DaRT. И Hard Reset не в помощь…
Но все равно, если есть возможность внедрить это обращение в html любого сайта, то удовольствия мало. Особенно для терминальных серверов. Особенно работающих с локальными файл-серверными БД.
Germanets
Ну если уж веселиться — то можно добавить в автозапуск обращение к этому замечательному файлу, и результат для обычного пользователя будет недалёк от вечного зависания)
Am0ralist
Слушайте, ну я лично чинил комп, который не загружался (с ошибкой доступа к диску С, на котором была установлена винда). Процесс починки включил в себя — запуск SLAX с флешки, заход на диск С, чтоб проверить работает ли он и не накрылся ли диск вообще, перезагрузка и запуск винды в нормальном режиме. Простая перезагрузка не помогала совсем. Если не ошибаюсь — 10-ка была (но может и 8-ка, не помню уже)
Так что, подозреваю, там и без этого косяка хватает приколов с ФС, после которых винда перестанет загружаться напрочь.
cyberonix
создал html файл chrome — путь валит намертво систему, проверил на себе. Пришлось кнопкой перезагрузиться. Собрал исходник, синий экран мгновенно.
Windows 7 Максимальная
Gaikotsu
Надеюсь MS выпустят вскоре фикс к этому, а то ведь сейчас 100% найдутся «особо одаренные», которые будут «развлекаться» этим способом, благо особых познаний в воспроизведении бага не требуется…
ValdikSS
В комментарии можно вставлять картинки-ссылки на file:// :)
Goodkat
Хабра попытается утянуть их к себе на хабрастораж.
ValdikSS
Но можно ей запретить!
Goodkat
Кто ж ей запретит? Она же хабра!
kafeman
Попытается, но не утянет. На Habrastorage грузятся только картинки.
GrafDL
Попробовал в опере. Если открыть html с такой картинкой с src на локальном диске, то система виснет. Если же открыть такую страницу по http, то не виснет.
ValdikSS
Да, будет работать только в IE.
См. деанонимизируем пользователей Windows и получаем учетные данные Microsoft и VPN-аккаунтов. Там как раз картинка, которая не на habrastorage, и перенаправляет на file://, если статью открыть в IE.
CMEPTbI4
mkdir \\pcname\c$\$mft\text если хватит прав тоже вешает удаленный комп.
Goodkat
Эх, помню в детстве вешали удалённо комп отправив тупо FAR-ом файл с нультерминированной строкой на пайп \\%computername%\mailslot\messngr
Carburn
Еще одна вредоносная программа.
alVV
Маленький шаг человека, большой шаг для человечествамаленький баг в драйвере — большое поле возможностей для вандалов всех мастей… хе-хе…В NTFS разделе вроде не только $mft служебный файл есть. К тому-же бывает NTFS-раздел примонтирован не только к букве раздела, а ещё и в каталог другого раздела ($mft в середине пути)
Как я понял: достаточно запросить "запрещённый путь" к разделу смонтированному на запись и при следующей операции записи произойдет зависание драйвера.
Из этого следуют потенциальные угрозы:
5 Все Редакторы к п.2 (MS офис, либре-офис и т.д.) + п.2
6 Антивирусы + п.1, 2,4 (периодические и неожиданные зависания системы :)
7 Служба индексирования + п.1, 2,4 (периодические и неожиданные зависания системы)
8 Терминальные серверы и все выше описанное
9 Кэширующий сервер на Windows + п 6, 7
…
можно и дальше продолжить....
sergey-b
Можно еще добавить обычные почтовые клиенты. Получаешь письмецо, а там…
Не очень понял про кэширующий сервер на Windows. Как вы представляете атаку на него? Или вы имеете в виду случай, когда NTFS-раздел примонтирован к каталогу?
alVV
Я имел в виду прокси-сервер.
Пользователь загружает страничку с неадекватной ссылкой, ссылка ложится в кеш сервера, при очередном проходе антивируса или службы индексирования в попытке найти файл программа прибивает Windows.
Но это пока абстрактные предположения.
alVV
Неправильно понял. Достаточно операции "я только посмотреть", и раздел может быть "только для чтения", прав не нужно никаких.
TrueCrypt. Раздел ntfs только для чтения, как сменный носитель. При попытке чтения некорректного пути закрывается доступ к разделу.=> Попытка отмонтировать раздел убивает драйвер TrueCrypt и закрывается доступ к другим открытым разделам TrueCrypt. => Попытка доступа к любому разделу TrueCrypt вешает систему.
Флешка: попытка доступа к неадекватному каталогу на ней убивает доступ (на время сессии) ко флешке. => Попытка "безопасно отсоединить" флешку убивает систему.
Am0ralist
Кстати, на XP был веселый глюк:
— расшарил флешку на одном компьюетере в локальной сети и подключался с другого.
— подключал флешку дома.
— на флешку черви по сети (местячковые провайдеры с их любимым способом подключением клиентов через локальную сеть) постоянно скидывали свои екзешники обходя антивирусы (ну то есть те вопили об атаке, а потом при проверке находили этих червей и убивали).
— через управление компьютером/общие папки факт того, что флешка расшарена — не отображалось, если не ошибаюсь.
— почему думаю, что дело в этом — на другие диски и в другие папки ни разу черви не пробились, установка фаервола, а после и вовсе установка роутера — проблему решило.
Вот и думаю, это баг был или фича? И не возможно ли это использовать тем, кто умеет как-то во вред?
hddmasters
Наверное не совсем корректно называть недостатки драйвера работающего со структурами NTFS багом самой NTFS.
anatolymik
О каком недостатке идет речь, когда ERESOURCE $mft файла не отпускается в случае fail?
hddmasters
Не находите, что в этом нет вины самих структур NTFS?
Если бы речь шла о недостатках самой файловой системы, то рассматривали бы здесь непосредственно структуры NTFS.
anatolymik
Я извиняюсь, а эти структуры тут причем?
hddmasters
Эта и прочие структуры и есть сама NTFS. В статье же говорят не совсем о файловой системе.
anatolymik
Мне казалось, что по ходу статьи я разъяснил что речь идет о реализации драйвера.
hddmasters
Ну так о чем и речь. Заголовок не совсем соответствует содержимому.
Mogaba
Получилось в WIndows 2008R2 с последними обновлениями. Зависает и при запуске программы из поста, и при выполнении dir, и при открытии html-файла c (проверял на Firefox ESR и на IE).
Кстати, поверхностный поиск в гугле ничего не дал. Интересно, почему так — это же натурально бомба для тех же терминальных серверов. И защититься от этого, я так понимаю, невозможно?
anatolymik
Как только исправят
Bronekalmar
На терминальных серверах можно попробовать запретить пользователям чтение и запись С:/ не включая вложеные файлы и папки. А на остальные оставить как есть.
mayorovp
Не поможет. Ломается-то процесс поиска файла по указанному пути — а он выполняется до проверки прав.
Но даже если бы получилось закрыть доступ к диску C: — как в таком случае предполагается этим сервером пользоваться?
Bronekalmar
Действительно, ошибся.
Доступ запрещается только до корня диска С:/ а, доступ к остальным папкам и файлам в этом случае не меняется
mayorovp
Так проблема-то не в корне C:\, а в файле C:\$mft
Bronekalmar
Не так выразился… Доступ запрещается на чтение и запись файлов на диске С, но на папки не распространяется. Если я верно понимаю.
Надо будет потестить на виртуалке
Bronekalmar
UPD.
Проверил на виртуалке с Win 8.1 со всеми обновлениями — не помогло
alVV
Если не трудно, проверьте внешний запрос к IIS (internet server от микрософт) типа такого: http://%systemdrive%/$mft/testPath/TestPicture.jpg
Если уронит систему, то все…
alVV
http:// ip-адрес/%systemdrive%/$mft/testPath/TestPicture.jpg
Опечатка в предыдущем тексте
Bronekalmar
Установил компоненты IIS, потестил по всякому, пока все нормально, при этом dir c:$mft\123 в консоли так же перестал вешать систему, страно…
Завтра займусь тестированием на разных версиях Windows
mayorovp
А с какого перепугу IIS должен был выходить за пределы корня сайта при запросе с %systemdrive% в URL?
alVV
Попытка чтения тоже не должна рушить систему, причем даже пользователю без прав. Не зря рекомендуется Гостевой доступ закрывать.
Драйвер ntfs-3g (ОС Linux Ubuntu 17.04) я на всякий случай протестировал — нормально.
mayorovp
Не должна — но тут хоть механизм понятен.
А какой должен быть предполагаемый механизм у подобного запроса?
Migalkin
Был у меня сон " а ля Бальзаминов" — все спрашивают, как ты там- ответить не могу.
0serg
Статья добралась до Ars Technica
https://arstechnica.com/information-technology/2017/05/in-a-throwback-to-the-90s-ntfs-bug-lets-anyone-hang-or-crash-windows-7-8-1/
Очень круто, спасибо за публикацию
Pochemuk
Да уже многие пишут:
https://www.theverge.com/2017/5/26/15696704/microsoft-windows-7-windows-8-pc-crash-bug-ntfs
На 4PDA есть перевод:
http://4pda.ru/2017/05/29/342735/
mixtape774
не обязательно прогу создавать, подходит bat файл:
echo "" >> c:\$fmt\0
mixtape774
уже увидел среди тонны комментов…
Sabado
Общий день, сэр / мадам
Я господин Сабадо Б, Лингат. Частный инвестор, полный юридический и аккредитованный денежный кредитор. Я буду использовать этот носитель, чтобы сообщить вам, что я оказываю надежную финансовую помощь, так как я буду рад предложить вам кредит под 3% годовых.
Если необходимо, предоставьте нам следующую информацию:
Имя:
Страна:
Тел:
Необходимая сумма кредита:
Продолжительность кредита:
(Нет социального обеспечения, Гарантированная предоплата 100%)
Я с нетерпением жду, чтобы позволить мне быть полезным вам,
Искренне Ваш
Г-н Сабадо Бернардо Лингат.
Имя кредитора: г-н Сабадо Бернандо
Контактный адрес электронной почты: sabadobernadoloan@outlook.com
anatolymik
Прошу прощения, коллеги. Одобрил по инерции. Не специально.