mini-distr

рецепты недетского похудания для дистрибутивов или секрет обрезания клитора ;)

крис касперски, ака мыщъх, a.k.a. nezumi, a.k.a. souriz, a.k.a. elraton, no-email

жилплощадь новейших жестких дисков исчисляется тысячами гектар и заполнить такой объем одним лишь программным кодом нереально. музыка, видео — вот основной источник расходов! однако, достаточно многие пользователи до сих пор ютятся на десятке-другом гектар, что особенно актуально для ноутбуков, модернизация которых существенно затруднена, а древние (но все еще работающие) материнские платы винчестеров большого объема в упор не «видят», а поэтому, приходится обходится минимумом программ, выкидывая из них все лишнее. а лишнего в них много. рядовой дистрибутив ужимается в три и более раз! главное знать, что выкидывать, а что лучше оставить про запас!

Разработчики программного обеспечения, похоже, совсем потеряли нюх и пихают в дистрибутивы всякий хлам, даже тот, что заведомо не будет использоваться. Вполне типичная ситуация — динамическая библиотека есть, а загружающий ее код вырезан еще пару версий тому назад, вот она и болтается на диске как неприкаянная. Про разные файлы с текстами лицензионных соглашений и прочий упаковочный «пенопласт» можно даже и не говорить!

Практически все дистрибутивы поддерживают «ручной» режим инсталляции с выбором необходимых компонентов, однако, качество его реализации оставляет желать лучшего и зачастую даже в минимальном варианте поставки мы получаем кучу неиспользуемого хлама, транжирящего дисковое место.

Нашей задачей будет избавление от всего лишнего, включая «мусор», оставленный кривыми деинсталляторами в каталогах Windows и System32. Опытные хакеры, вооруженные отладчиками, дизассемблерами, файловыми мониторами, API-шпионами и прочей амуницией подобного типа, после непродолжительного ресерча могут с полной определенностью определить зачем (не)нужен тот или иной файл и когда он (не)используется. А как быть тем, кто смотрит на ассемблерные листинги как на священные тексты, и ни черта не понимает за какой хвост дергать отладчик, чтобы он сказал «му»?!

Существует множество варварских методов обрезания, проводимых в кустарных условиях подручными инструментами без всякой анестезии. Одно неверное нажатие <DEL> может запросто угробить весь дистрибутив или, что хуже, искалечить его. Сохранив возможность запускаться, изуродованная программа полно рухнет в самый ответственный момент. Впрочем, риск не так уж и велик, особенно если не злоупотреблять. К тому же, переустановить «убитый» дистрибутив — не проблема.

Естественно, эксперименты требуют времени. А время — это деньги. Соответственно, если обрезание требует продолжительно траха, то ну его в баню. Лучше вложить свои силы во что-то полезное, а на вырученные деньги приобрести более емкий жесткий диск или даже весь компьютер целиком. Поэтому, мы будем говорить лишь о тех способах обрезания, которые не требуют слишком больших телодвижений.

ASCII

Рисунок 1 мыщъх. собственной персоной

Начиная с Windows 95 каждый файл «прокомпостирован» тремя временными штампами: 1й — время модификации (или, так называемое MS-DOS время, оставленное главным образом в целях обратной совместимости); 2й — время создания файла на диске, 3й — время последнего открытия файла на запись или чтение.

По умолчанию «Проводник» Windows и большинство оболочек отображают именно MS-DOS время, которое нам совершенно неинтересно, поскольку не несет никакой достоверной информации. Теоретически – это время первого создания файла, сохраняющееся при копировании файла на другой диск, архивации и даже инсталляции. Однако, разработчики программного обеспечения зачастую изменяют MS-DOS время так, что бы у всех файлов оно было одинаково, хотя всем понятно, что истинная дата «рождения» файла отличается от присвоенной ему инсталлятором.

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

А вот время последнего обращения к файлу— самая большая ценность, благодаря которому мы можем легко и быстро отделить мусор от полезного stuff'а. Что происходит при запуске программы? Правильно ‑ она обращается к определенным файлам и штамп времени их последнего открытия неизбежно изменяется, что позволяет нам мгновенно определить какие фалы реально необходимы программы, а без каких она может и обойтись.

Естественно, в процессе запуска программы загружаются только базовые компоненты и вовсе не факт, что их окажется достаточно для нормальной работы. Скажем, печать довольно часто реализуется в виде отдельной библиотеке, загружаемой лишь при нажатии иконки, символизирующей принтер. Загрузка компонентов по потребности — весьма распространенный прием программирования. И прежде, чем приступать к расчистке мусора следует поработать с программой некоторое время, например, неделю или даже месяц, гарантируя, что за это время мы «выбрали» весь необходимый нам функционал, но не взяли ничего лишнего. Например, если случайно нажать <F1> — загрузиться раздел справки (и, возможно, динамические библиотеки, обеспечивающие его функционирование). Штамп времени последнего обращения ко всем этим файлам будет автоматически изменен, хотя они нам ни хвоста не нужны. Так что, в процессе набора статистики, следует вести себя предельно осторожно: не делать резкий движений и не наживать тех кнопок (пунктов меню), без которых можно обойтись.

ОК, будем считать, что у нас имеется программа, поработавшая некоторое время, и мы горим желанием выкинуть из нее все ненужное — все то, что за это время ни разу не было использовано. Тащим подопытную мышу на операционной стол, в роли которого в нашем случае выступает популярный файл-менеджер FAR.

Ждем <CTRL-F9> для сортировки файлов по времени доступа и давим <Ctrl-5> (не <F5>, а просто <5>), заставляя FAR отображать само время доступа, которое он по умолчанию (вот подлец!) не отображает.

Вот, например, результат исследования каталога «C:\Program Files\Microsoft Visual Studio\VC98\Bin» (см. рис. 1), в котором компилятор MS Visual Studio хранит свои исполняемые файлы. Как мы видим, его содержимое четко делится на три основных группы. В первую попадают постоянно используемые файлы, образующее ядро компилятора. Последний раз все они открывались в течении одного дня — 19.02.08, а точнее в 23:43. Вторую группу образуют редко используемые файлы, открываемые в период с 15.02.08 по 16.01.08. Прожить без них можно, но… сложно. В третью группу попадают файлы, последний раз открытые несколько месяцев назад, причем в одно и тоже время — 23.10.07/20:20, что, вероятно, произошло во время антивирусной проверки или глобального контекстного поиска. Вполне логично, если мыщъх в течении полугода (а может, даже и больше) спокойно жил без этих файлов, то проживет и дальше, а потому их можно удалить или перенести на внешний носитель, например, на DVD.

Рисунок 2 определение времени последнего открытия файлов

Просматривая содержимое папки Windows, мыщъх обнаружил, что 70% объема приходится на файлы, которые практически не используются, MS Office показал более скоромную цифру, едва преодолев планку в 62% (и это при том, что он изначально был установлен в минимальном комплекте, в частности мыщъх не инсталлировал Excel и прочую не нужную лично ему муть), но все-таки, 62% это намного больше половины! И все это пространство занято реально невостребованными компонентами, которые могут быть беспрепятственно удалены или перемещены на DVD, FLASH или сетевой диск.

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

Кстати, чтобы не блуждать по запутанной иерархии папок, достаточно просто нажать Пуск Найти Файлы и папки Дата Файлы открытые  c … по …, приказ системе искать файлы, которые ни разу не открывались за последние полгода. Мусора вылезет столько, что хвост встанет. Реально встанет, как еще никогда не стоял! Конечно, удалять весь этот хлам случает с большой осторожностью, а то потом можно не досчитаться курсовой, написанное еще в прошлом году или фотографии любимой девушки, брошенной черт знает когда, и хранимой чисто из сентиментальных соображений.

Тем не менее, если обнаруживается большое количество «нужных» файлов, не открываемых годами, следует задуматься: а так ли они нужны? Архивы лучше держать на DVD, а на жестких дисках иметь только ту информацию, которая всегда должна быть под рукой. Грубо говоря, жесткий диск — это кэш-память, а основная память — это DVD (впрочем, учитывая цены на современные винты, экономически выгоднее купить внешний сетевой диск, чем стопку DVD).

Рисунок 3 поиск давно неиспользуемых файлов

Методика определения степени «нужности» файла, основанная на штампе времени, чрезвычайно чувствительна к различным посторонним возмущениям: антивирусам, системам индексации, глобальному контекстному поиску и прочим X-факторам, «лапающих» все файлы без разбора и искажающих дату последнего открытия. А потому, перед сбором статистики их необходимо отключить. Или хотя бы настроить антивирусы так, чтобы они проверяли только открываемые или вновь создаваемые файлы. В противном случае, мы получим огромное количество ложных позитивных ошибок — то есть примем бесполезный мусор за нужные файлы. Тоже самое относится и к операции тотальной архивации диска — штука, бесспорно, очень полезная, но… увы, безнадежно затирающая прежний штамп времени.

Допустим, у нас имеются редко используемые приложения, например Photoshop, занимающие много места, но практически не содержащие «мусора», который было бы можно удалить, тем более что, применительно к Photoshop'у, включающему множество фильтров — никогда не знаешь наперед какой фильтр и когда тебе понадобиться. Удаление редко используемых компонентов практически не высвобождает дискового пространства, но зато приносит огромную головную боль.

На самом деле такие приложение можно целиком перенести на FLASH или даже другой раздел диска. Естественно, «тупое» копирование главной папки программы это не наш путь. Если после переезда на новое место жительство приложение сохранить способность запуститься — нам очень сильно повезло. Программисты активно используют абсолютные пути, прописывая их и реестре, и в различных конфигурационных файлах и еще хвост знает где.

Следовательно, приложение должно сохранять абсолютный путь к себе в целости и сохранности (т.е. что-то типа C:\Program Files\Microsoft Office) но _физически_ размещаться на FLASH-брелке. Бред?! Вовсе нет. Операционные системы линейки NT выгодно отличаются от семейства 9x тем, что позволяют монтировать логический диск на любой каталог, при условии, что он пустой.

ОК, вставляем FLASH в USB-порт. Допустим, система присваивает ей букву «E:». Переносим все содержимое папки «C:\Program Files\Microsoft Office» в корневой каталог диска «E:», но саму папку «Microsoft Office» не удаляем. Главное — чтобы она была пустой, а у нас были права администратора (не обязательно входить в систему под администратором, вполне можно запустить cmd.exe посредством службы RunAs или, создав ярлык, указать в его свойствах «Запускать от имени…»).

Рисунок 4 запуск программы от имени администратора из-под текущего пользователя

А запускать мы будем утилиту «mountvol.exe», входящую в комплект стандартной поставки всех NT-подобных систем, начиная с W2K. При запуске без ключей она выдаст полный список точек подключения, который выглядит приблизительно так, как показано на рис. 5.

Рисунок 5 просмотр текущих точек монтирования

Длинная строка цифр в фигурных скобках, начинающаяся с префикса «\\?\» представляет собой имя тома (не путать с меткой), а буква ниже его (в данном случае «E:\») – текущую точку подключения или, выражаясь на юниксоидный манер — точку монтирования. ОК, создаем новую точку монтирования, вызывая mountvol.exe следующим образом:

MOUNTVOL.EXE «C:\Program Files\Microsoft Office» /* здесь _нет_ переноса строки! */

\\?\Volume{98fc8064-566a-11d9-82a2-806d6172696f}\

Листинг 1 монтирование FLASH-диска на каталог C:\Program Files\Microsoft Office

После выполнения команды MOUNTVOL.EXE перезагрузка не требуется и если мы откроем каталог \Microsoft Office\ (который только что был пустым!!!) индикатор обращения к флешке оживленно замигает (если, он, конечно, есть) и мы увидим натуральное содержимое. Пробуем запустить Word – запускается!!! Естественно, если выдернуть флешку, то Word'у придет капец, но тут уж ничего не поделаешь.

Главный минус данной технологии заключается в том, что на каталог может монтироваться только весь диск, а точнее его корневой каталог. Причем, каталог, на который осуществляется монтирование _обязательно_ должен быть пустым, то есть мы можем переносить лишь все приложения целиком.

Однако, поскольку флешку можно разбивать на несколько логических дисков (например, воспользовавшись программой FDISK), то ничто не помешает нам хранить на ней все необходимые приложения (конечно, при условии, что им хватает места). Тоже самое относится и к ZIP-дискам. DVD, увы, разбивать уже нельзя, да и переносить на них можно лишь те программы, которые ничего не пишут в своем каталоге, т.к. на DVD обычным путем писать ничего нельзя, хотя… на CD/DVD-RW, размеченном под файловую систему UDF, писать все-таки можно, пускай и очень медленно.

Удалить точку монтирования можно с помощью ключа /D:

MOUNTVOL.EXE «C:\Program Files\Microsoft Office» /D

Листинг 2 удаление точки монтирования

А чтобы каждый раз не набивать эти длинные пути и имена дисков вручную, рекомендуется загнать их в bat-файлы, которые в случае CD/DVD или FLASH могут вызываться из autorun'а, тогда чтобы смонтировать диск на соответствующий ему каталог достаточно просто воткнуть его в USB-порт или положить на лоток привода.

Скопировав MS Office или другое приложение на FLASH, мы высвободили существенное количество дискового пространства, но… если воткнуть FLASH в другой компьютер, то ни хвоста MS Office работать не будет. Почему?! А все потому, что реестр остался на прежнем месте, а без него MS Office работать не хочет. Какая жалость! Ведь это же так удобно таскать все необходимые приложения на флешке, вставляя ее в первый попавшийся компьютер и без всякой установки!!!

Как говорится, спор рождает предложение и на рынке уже появились подобные решения. В частности, утилита Thinstall (http://www.thinstall.com/) без малого стоит… $5k, при этом глючит не по детски и не обходится без ряда досадных ограничений. Что? Вот тут кто-то говорит: за $5k ее пускай буржуи покупают, а нормальные хакеры все уже поломали, зарелизили и теперь сидят курят, раздумывая чтобы еще такого крутого сломать. Брехня, брехня!!! Настоящим нахерам, тьфу, хакерам, Thinstall на хрен не нужен. Им достаточно одной операционной системы, которые они знают как точку схождения двух прямых своей girlfriend. В смысле ее ног.

Рисунок 6 здесь продают Thinstall

Начиная с самых первых версий NT позволяла создавать перемещаемые пользовательские профили и сейчас это позволяет. Перемещаемые профили обычно используются для хранения настроек пользовательского аккаунта (вместе с пользовательской ветвь реестра) на сервере, что упрощает их учет и архивацию, но… никто же ведь не запрещает вместо пути к серверу указать DVD или флешку!

Однако, можно пойти другим путем, которым давно пользуется мыщъх. Сначала на своей собственной машине мы создаем нового пользователя, входящего в группу «опытные пользователи» (пусть, для определенности, это будет «nezumi»), входит в систему под его именем и выполняем установку программы, которую планируем носить с собой. Если эта программа уже установлена на компьютере, то необходимо либо удалить ее, либо воспользоваться преимуществами виртуальной машины типа VM Ware.

ОК, программа установлена! Переносим ее на FLASH по вышеописанной технологии и туда же копирует содержимое папки C:\Documents and Settings\nezumi\ (не обязательно в свободный раздел и не обязательно «as is» – при недостатке места можно воспользоваться zip'ом, rar'ом или любым другим архиватором по вкусу).

Выдергиваем FLASH и подходим к соседней машине. Требуем права администратора. Если с правами выходит облом — ставим пиво. Увы, требование администраторских прав — главный недостаток данной технологии, но по другому никак не получается. Впрочем, в XP практически все сидят под администраторами так что никаких проблем тут возникнуть не должно. Создаем пользователя «nezumi» и _не_ _заходя_ _в_ _него_ копируем в паку «C:\Documents and Settings\nezumi\» свое собственное содержимое, как бы перенося пользователя с одной машины на другую, а вместе с ним и пользовательскую ветвь реестра со всеми настройками программы, которую мы будем монтировать на пустой каталог, после чего останется только войти в систему как «nezumi» или запустить программу от его имени из-под текущего пользователя.

Хорошо, а как быть, если еще на самом первом шаге программа откажется устанавливаться из-под аккаунта «опытного пользователя», требуя прав администратора?! Это означает, что программа что-то записывает в системную ветвь реестра, которая в пользовательский аккаунт, увы, не попадет и хотя записываемые ей данные можно экспортировать из реестра в reg-файл, запустить его на соседней машине, импортировав внутрь реестра, а после завершения работы удалить данные из реестра обратно, но… это уже выходит за рамки данной статьи и требует определенной квалификации от пользователя.

Другая проблема — большинство приложений часть файлов кидают в каталог Windows или Windows\System32. В большинстве своем это динамические библиотеки. Если на соседней машине их не окажется, то запуск программы провалится и чтобы исправить ситуацию достаточно просто скопировать их в текущий каталог программы, которую мы уже перенесли на FLASH. Как найти какие именно библиотеки закинул инсталлятор? Очень просто – по дате создания, которая будет совпадать со временем инсталляции. Правда, если эти библиотеки уже присутствовали на нашей машине до запуска инсталлятора (были установлены другим приложением) данная методика не сработает и нам потребуется повторить установку приложения на «стерильной» системе, для чего очень хорошо подходит VM Ware.

Висла виртуализирует запись в системный реестр, сохраняя его в текущем пользовательском аккаунте (при условии, конечно, что данный пользователь входит в группу администраторов), а потому под Вислой будет работать перенос практически всех программ, даже тех, что устанавливают драйвера и регистрируют новые ActiveX-компоненты. И все это без привлечения каких бы то ни было дополнительных утилит. Просто инсталлируем приложение на свежеустановленную операционную систему, копируем на FLASH содержимое папки «C:\Program Files\имя-программы» добавляя туда все библиотеки (и драйвера) которые инсталлятор создал в каталоге Windows и всех ее подкаталогах. Архивируем (или не архивируем) «C:\Documents and Settings\nezumi\» и кидаем его на FLESH. Все. На любой другой Висле монтируем «C:\Program Files\имя-программы», создаем пользователя «nezumi» (если он не был создан ранее) и перезаписываем «C:\Documents and Settings\nezumi\», распаковывая туда архив «своего» nezumi (или просто при создании пользователя указываем путь к его профилю, хранящемуся на флешке).

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