Абсолютная влажность холодного воздуха низкая. А это значит, что когда он нагреется, он станет очень сухим (по показателям относительной влажности).
Влага из горячего воздуха будет конденсироваться в момент его охлаждения (т.е. в зоне смешивания с холодным воздухом с улицы будет выпадать туман). Если ее в этот момент улавливать и осаждать, а затем пускать в серверную относительно сухой и прохладный воздух, то в серверной конденсат образовываться не будет.
Ну, вам виднее, какой из примеров попоказательнее выбрать. Я как-то затрудняюсь ответить.
Поясню суть моих затруднений: дело в том, что у вас в статье, похоже, речь идет в основном о миграции комплекса, написанного на одном языке программирования (FoxPro?). Мне же обычно встречались «комплексы», слепленные из сотен разнообразных утилит, скриптов и прокладок. Языков программирования там использовалось минимум десяток всяких разных, причем для многих утилит за давностью лет не сохранилось никаких исходников (или сохранились, но далеко не самой последней версии, что еще хуже). Немалая часть всей системы — это сложная конструкция из подпорок и костылей, компенсирующая одни глюки за счет внесения других, чуть менее фатальных. Поэтому для меня автоматическая конвертация кода всей системы с сохранением его функционала — это что-то фантастическое.
Хорошо бы увидеть примеры кода (небольшие) — оригинал и результат конвертирования, с пояснениями, где там были самые грабельные места. Еще интересно, как вам удалось сконвертировать фокспрошные формы и отчеты в сишарп. Только учтите, что я фокспро последний раз тыкал палочкой лет десять назад (да и то еще версию под ДОС), поэтому никаких тонкостей языка уже не помню (думаю, как и многие другие хабровчане).
Все очень просто — исходный текст, на старой платформе, транслируется в текст на новой платформе. В некоторых случаях дописывается миграционная библиотека.
А можно какой-нибудь примерчик такой миграции? Чтобы можно было, так сказать, в более практичесом ключе понять, как это должно работать.
Мне вот приходилось переносить небольшие (несколько тысяч строк кода) древние поделия на другую платформу — так там такое встречалось, что до сих пор волосья дыбом по всему организму. Правда, там и платформы были совсем разные (С++ и XML/XPath/Java), так что автоматическая трансляция, как мне кажется, вообще невозможна.
Интересная статья, надо будет сходить в «Галерею» как-нибудь, пощупать живьем…
Одного не понимаю: зачем небритый субъект на КДПВ хочет затолкать кулаком доллары обратно в экран?
Ну, согласитесь, показатель процента точных выцеплений — тоже метрика.
Согласен. Но возражаю против использования MD5/SHA1 и прочих чексумм: они всего лишь дадут понять, что файлы различны, но не помогут найти файлы с «хвостами» из остатков последнего кластера. Проще уж посчитать чексуммы первых пары килобайт, а остальное сравнивать просто «в лоб».
Кстати, если уж беремся за восстановление данных, то интересны как минимум еще две характеристики:
— точность восстановления имен файлов (в т.ч. с русскими буквами и прочей нелатиницей);
— восстанавливаются ли даты создания, модификации и последнего доступа к файлам.
Обе эти характеристики очень важны, например, при расследовании преступлений, и если утилита их не восстанавливает — может случиться конфуз.
Дело в том, что иногда точную длину файла невозможно «выцепить» из остатков файловой системы. В этих случаях в файл попадает все содержимое последнего кластера (даже если собственно «хвост» файла там сосавляет всего пару байт). Для таких файлов, понятное дело, чексуммы не совпадут, хотя в большинстве случаев «мусор» в конце файла не мешает.
Собственно, смущает еще один момент: автор статьи не указал, каким имено способом записываются тестовые флэшки. Я бы, например, записал все файлы на одну флэшку, затем слил с нее полный посекторный образ и «размножил» бы его на остальные флэшки. Просто для того, чтобы иметь гарантию, что флэшки идентичны не только по объему и списку записанных файлов, но и вообще по всему содержимому.
Тест пройден. Результат восстановления — 99% (по-прежнему не люблю абсолютные значения)
Я правильно понял, что результат восстановления вы оценили по виду списка файлов и счетчику восстановленных файлов? Так это, простите, не результат восстановления данных, а результат восстановления списка файлов.
Насколько точно восстановлены файлы? Есть ли битые? Есть ли мусор в конце (для картинок в формате JPEG это некритично, но для других типов файлов может быть проблемой)?
При попытке сохранить восстановленные данные получаем сообщение:
image
Тем не менее по превью видно, что файлы восстановлены:
image
Тест пройден. Результат восстановления — 99%***
Превью — это, конечно, хорошо, но расскажу историю из жизни.
Вертел я как-то в руках фотоаппаратик типа «карманная мыльница» — и уж очень он мне понравился. Особенно понравилось то, как он четко фокусировался на предметах и лицах — на превью прям не картинка была, а загляденье.
А когда я его купил и вставил карточку, неожиданно выяснилось, что за долю секунды перед спуском затвора это убожище теряет фокусировку и наводится куда-то «в молоко». В результате из ста кадров резкими получаются от силы пара десятков, остальное — сразу в топку.
Вспомнился старый анекдот:
— Мастер, как мне назвать свою книгу?
— Там есть что-нибудь про трубы или барабаны?
— Нет…
— Ну так и назови: «Без труб и барабанов».
А если серьезно, то название должно быть броским и желательно без инговых окончаний. Например,
«Программистские откровения»
«Жизнь и необычайные приключения программистов»
«Компьютерные посиделки: о жизни и ИТ»
«Есть ли жизнь в ИТ? Знаменитости делятся опытом»
И т.д и т. п.
Теоретически — все верно.
Практически — с этим подходом возможно столько подводных граблей, что даже как-то неловко. Начиная от тупого «руки трясутся — промахнулся мимо нужного пункта, понял это только тогда, когда гном-десктоп загрузился» и заканчивая просто дурацкими ошибками («файловая система не проверялась 180 дней — подождите полчасика, щас проверю, потом продолжим загрузку»).
Просто опыт показывает, что в таких вот редкоиспользуемых местах баги кроются чаще всего. Они не обязательно там будут сразу после написания: какую-нибудь дурацкую ошибку могут и при рефакторинге занести.
Чтобы такого не случилось, нужно не одноразовое тестирование, а полноценные юнит-тесты на эту конкретную функциональность. И чтобы все юнит-тесты гонялись перед каждым релизом.
при условии неуязвимости протоколов шифрования дисков и алгоритмов вам достаточно гарантировано уничтожить заголовок контейнера и все его бекапы
Двусмысленная фраза. Бэкапы чего — заголовка или самого контейнера? По смыслу — заголовка, а по грамматике — контейнера.
На самом деле, конечно, все не так радужно. Условий тут несколько больше:
— в компьютере нет аппаратных закладок (не обязательно уровня шпионских девайсов: например, беспроводная клавиатура не только общается с компьютером, но и орет все ваши введенные тексты-явки-пароли в прямой эфир в радиусе как минимум десятка метров). Против «красной кнопки» такой перехват не поможет, но только если код реализован корректно (см. ниже).
— в реализации удаления заголовков нет багов. Ситуация усугубляется тем, что код «красной кнопки» вызывается исключительно редко (практически — один раз), поэтому он, фактически, не тестируется. Даже очевидные логические ошибки могут жить в таком коде годами.
Так оно там уже есть или его надо организовывать самостоятельно? :)
Я ж не спорю, что затирка заголовка теоретически надежна. Сомнение вызывает практический аспект: вот прямо сейчас вам ломают дверь, как именно вы будете портить заголовок (написание затиралки, использующей драйвер, заведомо отпадает) и где гарантия, что за 30 секунд все будет испорчено так, как надо?
Заметьте, это уже несколько отличается от первоначального постулата, цитирую: «Нам нужно только уничтожить заголовок зашифрованного раздела».
Опять же, не факт, что заголовок удастся уничтожить быстро. Например, под виндой, ЕМНИП, запись в системные области диска без специальных приседаний заканчивается пшиком (операция удается, но ничего по факту не пишется). Не факт, что веракрипт не восстановит хедер из лучших побуждений. Не факт, что в веракрипте резервная копия хедера расположена там же, где и у трукрипта (обратной совместимости криптоконтейнеров, как я понимаю, нет). И еще десяток «нефактов» можно придумать, каждый из которых, в принципе, не так уж чтобы фатален, но в сумме все сводится все к тому же доверию программе шифрования.
Жесткий диск не так уж просто раздолбать. Там сталь упругая на крышках, так что молот может и в лобешник отскочить (призовая игра!).
Лучше держать под рукой кувалду, а в свободное от неправедных трудов время подрабатывать молотобойцем — для тренировки.
Запись 1 гигабайта данных на диск со скоростью 50 мб/сек займет 20 секунд. Чтобы полностью зачистить диск объемом 1 терабайт, придется подождать 20000 секунд (5 с половиной часов). А чтобы перезаписать все 35 раз, придется брать отпуск и ехать на пару неделек отдыхать… например, на Колыму.
Если же перезаписать только «секретные» файлы, то с немалой вероятностью на диске останутся их более ранние копии (в свободных областях).
В первую очередь это нужно для автоматического тестирования программ, рисующих что-то на терминале с помощью curses, по моему мнению. Как иначе написать тесты для программы, которая ждёт, что пользователь нажмёт клавишу, и выводит результаты в определенное место экрана средствами curses?
В линуксе можно посылать символы в терминал через ioctl. Насчет читать оттуда символы и атрибуты — не интересовался, но теоретически тоже можно. Вот так, к примеру, можно «напечатать» хелловорлд:
Влага из горячего воздуха будет конденсироваться в момент его охлаждения (т.е. в зоне смешивания с холодным воздухом с улицы будет выпадать туман). Если ее в этот момент улавливать и осаждать, а затем пускать в серверную относительно сухой и прохладный воздух, то в серверной конденсат образовываться не будет.
Или еще проще: вставил бы mov al, 1; ret в самое начало check_key_4C23A8.
Это совсем не по-пацански, наверное?
Ну, вам виднее, какой из примеров попоказательнее выбрать. Я как-то затрудняюсь ответить.
Поясню суть моих затруднений: дело в том, что у вас в статье, похоже, речь идет в основном о миграции комплекса, написанного на одном языке программирования (FoxPro?). Мне же обычно встречались «комплексы», слепленные из сотен разнообразных утилит, скриптов и прокладок. Языков программирования там использовалось минимум десяток всяких разных, причем для многих утилит за давностью лет не сохранилось никаких исходников (или сохранились, но далеко не самой последней версии, что еще хуже). Немалая часть всей системы — это сложная конструкция из подпорок и костылей, компенсирующая одни глюки за счет внесения других, чуть менее фатальных. Поэтому для меня автоматическая конвертация кода всей системы с сохранением его функционала — это что-то фантастическое.
Хорошо бы увидеть примеры кода (небольшие) — оригинал и результат конвертирования, с пояснениями, где там были самые грабельные места. Еще интересно, как вам удалось сконвертировать фокспрошные формы и отчеты в сишарп. Только учтите, что я фокспро последний раз тыкал палочкой лет десять назад (да и то еще версию под ДОС), поэтому никаких тонкостей языка уже не помню (думаю, как и многие другие хабровчане).
А можно какой-нибудь примерчик такой миграции? Чтобы можно было, так сказать, в более практичесом ключе понять, как это должно работать.
Мне вот приходилось переносить небольшие (несколько тысяч строк кода) древние поделия на другую платформу — так там такое встречалось, что до сих пор волосья дыбом по всему организму. Правда, там и платформы были совсем разные (С++ и XML/XPath/Java), так что автоматическая трансляция, как мне кажется, вообще невозможна.
Одного не понимаю: зачем небритый субъект на КДПВ хочет затолкать кулаком доллары обратно в экран?
Согласен. Но возражаю против использования MD5/SHA1 и прочих чексумм: они всего лишь дадут понять, что файлы различны, но не помогут найти файлы с «хвостами» из остатков последнего кластера. Проще уж посчитать чексуммы первых пары килобайт, а остальное сравнивать просто «в лоб».
Кстати, если уж беремся за восстановление данных, то интересны как минимум еще две характеристики:
— точность восстановления имен файлов (в т.ч. с русскими буквами и прочей нелатиницей);
— восстанавливаются ли даты создания, модификации и последнего доступа к файлам.
Обе эти характеристики очень важны, например, при расследовании преступлений, и если утилита их не восстанавливает — может случиться конфуз.
Собственно, смущает еще один момент: автор статьи не указал, каким имено способом записываются тестовые флэшки. Я бы, например, записал все файлы на одну флэшку, затем слил с нее полный посекторный образ и «размножил» бы его на остальные флэшки. Просто для того, чтобы иметь гарантию, что флэшки идентичны не только по объему и списку записанных файлов, но и вообще по всему содержимому.
Я правильно понял, что результат восстановления вы оценили по виду списка файлов и счетчику восстановленных файлов? Так это, простите, не результат восстановления данных, а результат восстановления списка файлов.
Насколько точно восстановлены файлы? Есть ли битые? Есть ли мусор в конце (для картинок в формате JPEG это некритично, но для других типов файлов может быть проблемой)?
Превью — это, конечно, хорошо, но расскажу историю из жизни.
Вертел я как-то в руках фотоаппаратик типа «карманная мыльница» — и уж очень он мне понравился. Особенно понравилось то, как он четко фокусировался на предметах и лицах — на превью прям не картинка была, а загляденье.
А когда я его купил и вставил карточку, неожиданно выяснилось, что за долю секунды перед спуском затвора это убожище теряет фокусировку и наводится куда-то «в молоко». В результате из ста кадров резкими получаются от силы пара десятков, остальное — сразу в топку.
Я к чему? К тому, что превьюшкам доверять нельзя.
— Мастер, как мне назвать свою книгу?
— Там есть что-нибудь про трубы или барабаны?
— Нет…
— Ну так и назови: «Без труб и барабанов».
А если серьезно, то название должно быть броским и желательно без инговых окончаний. Например,
«Программистские откровения»
«Жизнь и необычайные приключения программистов»
«Компьютерные посиделки: о жизни и ИТ»
«Есть ли жизнь в ИТ? Знаменитости делятся опытом»
И т.д и т. п.
Практически — с этим подходом возможно столько подводных граблей, что даже как-то неловко. Начиная от тупого «руки трясутся — промахнулся мимо нужного пункта, понял это только тогда, когда гном-десктоп загрузился» и заканчивая просто дурацкими ошибками («файловая система не проверялась 180 дней — подождите полчасика, щас проверю, потом продолжим загрузку»).
Просто опыт показывает, что в таких вот редкоиспользуемых местах баги кроются чаще всего. Они не обязательно там будут сразу после написания: какую-нибудь дурацкую ошибку могут и при рефакторинге занести.
Чтобы такого не случилось, нужно не одноразовое тестирование, а полноценные юнит-тесты на эту конкретную функциональность. И чтобы все юнит-тесты гонялись перед каждым релизом.
Двусмысленная фраза. Бэкапы чего — заголовка или самого контейнера? По смыслу — заголовка, а по грамматике — контейнера.
На самом деле, конечно, все не так радужно. Условий тут несколько больше:
— в компьютере нет аппаратных закладок (не обязательно уровня шпионских девайсов: например, беспроводная клавиатура не только общается с компьютером, но и орет все ваши введенные тексты-явки-пароли в прямой эфир в радиусе как минимум десятка метров). Против «красной кнопки» такой перехват не поможет, но только если код реализован корректно (см. ниже).
— в реализации удаления заголовков нет багов. Ситуация усугубляется тем, что код «красной кнопки» вызывается исключительно редко (практически — один раз), поэтому он, фактически, не тестируется. Даже очевидные логические ошибки могут жить в таком коде годами.
Вы серьезно хотите переводить на русский?
А то пацаны английского-то совсем не знают! (прим. читат.)
Я ж не спорю, что затирка заголовка теоретически надежна. Сомнение вызывает практический аспект: вот прямо сейчас вам ломают дверь, как именно вы будете портить заголовок (написание затиралки, использующей драйвер, заведомо отпадает) и где гарантия, что за 30 секунд все будет испорчено так, как надо?
Опять же, не факт, что заголовок удастся уничтожить быстро. Например, под виндой, ЕМНИП, запись в системные области диска без специальных приседаний заканчивается пшиком (операция удается, но ничего по факту не пишется). Не факт, что веракрипт не восстановит хедер из лучших побуждений. Не факт, что в веракрипте резервная копия хедера расположена там же, где и у трукрипта (обратной совместимости криптоконтейнеров, как я понимаю, нет). И еще десяток «нефактов» можно придумать, каждый из которых, в принципе, не так уж чтобы фатален, но в сумме все сводится все к тому же доверию программе шифрования.
Не знаю, как насчет ВераКрипт, а в ТруКрипте резервная копия заголовка таки есть: superuser.com/questions/304861/where-does-truecrypt-store-the-backup-volume-header
Да, она зашифрована с другим ключиком и солтом (т.е. с исходной копией не совпадет), но она таки есть.
Лучше держать под рукой кувалду, а в свободное от неправедных трудов время подрабатывать молотобойцем — для тренировки.
Запись 1 гигабайта данных на диск со скоростью 50 мб/сек займет 20 секунд. Чтобы полностью зачистить диск объемом 1 терабайт, придется подождать 20000 секунд (5 с половиной часов). А чтобы перезаписать все 35 раз, придется брать отпуск и ехать на пару неделек отдыхать… например, на Колыму.
Если же перезаписать только «секретные» файлы, то с немалой вероятностью на диске останутся их более ранние копии (в свободных областях).
В линуксе можно посылать символы в терминал через ioctl. Насчет читать оттуда символы и атрибуты — не интересовался, но теоретически тоже можно. Вот так, к примеру, можно «напечатать» хелловорлд:
Естественно, если хочется, чтобы введенные символы попали в другое приложение, придется запускать его как дочерний процесс.