Я и 30 тыс. других пользователей моего компьютера

Или 30 лет спустя (после появления ПК): пробуем записать ini-файл... (а он не пишется!..)

К компании Майкрософт часто предъявляют разные, иногда взаимоисключающие претензии, относительно совместимости новых технических решений с предыдущими. С одной стороны, эта совместимость принимает угрожающие масштабы. Так на современном ПК с Windows XP или 32-разрядной Windows 7 до сих пор могут работать многие программы, написанные еще для DOS, не говоря уже о 16-разрядных приложениях для Windows. С другой стороны, некоторые изменения в устройстве ОСов от Майкрософт проглатываются с трудом, хотя они могут быть полезными и необходимыми.

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

Для начала несколько слов о типичной ситуации, иллюстрирующей произошедшие изменения и возникшие проблемы. В какой-то момент некоторые прикладные программы начинают вести себя непредсказуемо. Выясняется, что они перестают сохранять настройки. Как правило, это происходит при переходе с Windows XP на Windows Vista или 7. Если программа находится в директории Program Files, то она не может изменить здесь какой-либо файл, например, файл инициализации или конфигурации, если ее не запускать с «правами Администратора».

Краткая ретроспектива: Режим всесильного «Администратора» существовал уже в Windows XP (возможно и раньше, но с NT/2000 я знаком только понаслышке), однако по умолчанию он, как правило, был включен. Это привело к тому, что подавляющее большинство пользователей, а значит и запускаемых ими программ, работало именно в этом режиме и считало, что это нормальная, «естественная» ситуация. В Windows Vista Майкрософт ввел т.н. UAC (User Account Control, не путать с UAC из игры Doom) и по умолчанию пользователь стал работать с «обычными» правами. В результате этого многие простейшие операции по изменению системы, например, изменение содержания некоторых, «защищенных» директорий или установка драйвера, стали требовать выполнения дополнительных шагов, а иногда оказывались вообще «невозможными». Это вызвало массу нареканий, и было одной из причин, почему Vista «не пошла».

Разделение типов пользователей на разные категории было одним из элементов в процессе формализации системы. Другим элементом стало (относительно) жесткое предписание структуры директорий. Загадочная директория «Мои документы» – это лишь верхушка айсберга. С какого-то момента прикладным программам было предписано «раздваиваться» при установке, причем неизменяемые файлы программ должны были устанавливаться в вышеупомянутую директорию Program Files, а все остальное, в первую очередь настройки, в одну из т.н. «пользовательских» директорий. Программы, запускаемые в обычном режиме, могли менять только файлы, находящиеся в этих директориях. Если в директории Program Files устанавливалась программа, которая по старинке хранила изменяемые файлы в одном месте с исполняемыми, то она начинала вести себя странно. Странности зависели от того, как влияет на поведение программы невозможность изменения файлов настроек. В принципе, это было справедливо уже для Windows XP, работающей в режиме, отличном от «администраторского», что, как сказано выше, не было массовым явленим.

Единственная ясная ситуация, в которой такое «раздвоение» представляется полезным, это когда один компьютер используется несколькими пользователями, и каждый хранит свои настройки и свои данные отдельно. Тогда мы имеем исполняемый файл в одном месте, он общий и одинаковый для всех, а файлы настроек – разные для разных пользователей. Такая ситуация может существовать в офисе, и то не в каждом, но дома? Если муж и жена заводят свои пользовательские эккаунты, то это значит, что (1) семья очень бедная и не может позволить себе иметь два недорогих компьютера, (2) ждать до развода осталось недолго. С точки зрения обычного «домашнего» пользователя понять эту логику невозможно. Однако, в какой-то момент, мне, кажется, это удалось, почему и возникла эта статья.

Помогла, как ни странно, работа с Линуксом. В любом введении в Unix/Linux сразу упоминается о большом значении прав, которыми наделен пользователь (то есть запускаемые им программы/команды) при совершении каких-то операций. И действительно, если в Windows XP вопрос о правах вообще не возникает (то есть настолько не возникает, что даже непонятно о чем речь), в Windows Vista/7 он возникает, чтобы мешать работе, то в Linux он является повседневной реальностью и если не начать мыслить в этой категории, то пользоваться компьютером просто окажется невозможным. Хотя последняя ситуация возникла исторически, со временем преследуемая при этом цель или функциональность, изменилась. Но обо всем по-очереди.

Типичная структура директорий в Linux/Unix выглядит примерно так:

	/
	/bin
	/home/andrew
	     /mary
	     /петя ...
	..
	/lib
	/usr
	/var

Если вы думаете, что это все ваши директории, то это принципиальная ошибка. Директория конкретного пользователя – это всего лишь одна-единственная (включая, естественно, поддиректории), находящаяся в директории home: andrew, mary или петя. Все остальное – это «чужое» (как минимум, «общее»), лишь «случайно» оказавшееся на данном конкретном (однопользовательском) компьютере.

Когда Unix появился в начале 1970-х годов, его основное назначение заключалось в управлении системой «тупых» (dumb) терминалов. Где-то на другом конце университетского кампуса или на 15-м этаже 40-этажного офисного здания стоял единственный полноценный компьютер, огромный железный шкаф, с жестким диском, магнитными ленточками и памятью, а к нему были присоединены 100 или 1000 или 10 000 «тупых» терминалов, которые ничего кроме клавы и экрана не имели. Пользователи, сидевшие за этими терминалами, хранили свои данные на диске этого шкафа, и, естественно, не были заинтересованы в том, что каждый мог читать все, что там записано. Если кто-то стирал программу, находившуюся в общей директории /bin, то замечали это сразу все остальные 9999 пользователей, которым она оказывалась необходимой. Поэтому разграничение дискового пространства является в таких условиях жизненно важной необходимостью, без которой подобная система работать не будет. Этим обусловлена жесткая система директорий и ограничение прав на изменение содержания общих директорий. Последним занимался специальный человек (а иногда и не один), отвечающий за эксплуатацию «шкафа».

Если рассматривать эту ситуацию c точки зрения владельца однопользовательского компьютера, то понять стоящую за этим логику невозможно. Владелец однопользовательского компьютера – это властелин своей маленькой вселенной. У него есть все, необходимое для автономной работы, и его действия не приводят, как минимум, непосредственно, к каким-то последствиям для других. Поэтому разграничение доступа здесь объективно не нужно. Раздел про «домашний каталог» в описаниях Linux/Unix и поздних версий Windows вызывал у меня страшную скуку. Какой-такой домашний каталог, когда у меня весь компьютер – «домашний»?..

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

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

В реально многопользовательской системе существует несколько разных лиц (логично?), имеющих разные права доступа к ресурсам. По этой причине, пароли у этих лиц также неодинаковы. В фиктивной многопользовательской системе множества паролей может и не быть. Совершенно очевидно это становится при изучении линуксовой команды sudo. Эта команда позволяет обычному пользователю становиться на какое-то время супер-юзером (= администратором в терминологии Windows), благодаря чему он может проводить какие-то при обычных условиях невозможные операции, например, менять содержание «общих» директорий. Для ее выполнения пользователь должен ввести пароль, но не пароль супер-юзера, а свой собственный. Супер-юзер – это виртуальная личность, причем пароль для него может не существовать вообще. Рекомендация Ubuntu заключается в том, что создавая при установке Linux профиль root (это профиль того самого несуществующего супер-юзера), не нужно придавать ему свой отдельный пароль. В некотором роде эта защита сродни той, которая применяется в реальной жизни в странах со сложной ситуацией в области собственности. Титульным собственником объекта – компании, квартиры и т.д.– является некое неуловимое лицо, которое нельзя отвезти в контору нотариуса и, пытая утюгом, заставить подписать нужные бумаги. А реальный владелец – это всего лишь пользователь, отказываться которому не от чего.

В один прекрасный момент Майкрософт начал переносить юниксовую логику на свои системы. В частности, запуск с правами администратора является аналогом команды sudo. Для этого достаточно запустить программу через соответствующую позицию в контекстном (плавающем) меню. Разделение директорий внешне напоминает прежнюю систему «тупых» терминалов: программы хранятся в особо защищенном от действий обычных пользователей месте. Последние могут запускать эти программы, но не более того. Причем это справедливо как для реального пользователя данного конкретного компьютера, так и для вирусов, которые лишаются возможности для внедрения в файлы программ. Все эти меры должны повысить безопасность использования компьютерной техники. Но если вы предпочитаете (и успешно используете) иные способы защиты, то эти инновации не принесут дополнительных плюсов.

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

Хранение настроек программ отдельно от исполняемого кода приводит к дополнительным издержкам. Ситуация в DOS и ранних версиях Windows отличалась наглядностью. Все файлы прикладной программы хранились в одной директории и ее поддиректориях. Удаление и перенос такой программы не представляли никакого труда. Существовал еще более экстремальный вариант программ, которые хранили настройки в своем собственном exe-файле, дописывая их в конец файла. Надо признать, что это давало какие-то преимущества, так при копировании нельзя было забыть файл настроек. Но уже тогда такие программы приводили к конфликтам с антивирусными программами.

Современные программы для Windows должны хранить настройки в системном реестре и/или специальных поддиректориях пользовательских директорий. Этим объясняется необходимость использования специального инсталлятора, который, в частности, находит нужную директорию, абсолютный адрес которой зависит, кроме всего прочего, от версии Windows. Но тут сказывается то, что формализация ОС от Майкрософт проведена лишь частично. Что и как делает инсталлятор, остается на совести создателей прикладных программ. В еще большей степени это справедливо для деинсталляции программ. В итоге, как в реестре, так и в пользовательских директориях можно практически всегда найти неудаленные следы «жизнедеятельности» стертых программ.

Развитие техники приводит к неожиданным поворотам. В какой-то момент стали пользоваться популярностью т.н. «носимые» версии программ. В английском языке для этого используется термин portable, который в данном контексте получил второе, новое значение. В первом, более традиционном значении в качестве компьютерного термина слово portable означает переносимость кода между разными платформами, то есть возможность скомпилировать один и тот же код без или с минимальными изменениями для разных операционных систем. Во втором значении слово portable («носимый») стало ближе к обыденному. Речь шла о программах, которые записывались на некий внешний носитель, как правило, USB-флэшку или – в наше время все чаще – SD-карточку, и могли использоваться без инсталляции на компьютерах, куда эта флэшка или карточка втыкались. Способность к такой работе декларировалась как новое, особенное свойство. Парадокс, однако, заключается в том, что до какого-то момента все программы были в этом смысле «носимыми».

Остается вопрос о том, что делать с программами, неспособными к «раздвоению»? Такие программы можно хранить в директориях, не подпадающих под жесткий контроль администратора, в простейшем случае в директории на десктопе. Это, однако, источник потенциальных угроз для безопасности компьютера, оценка реальности которых – дело каждого отдельного пользователя. Более правильным является хранение таких программ в директории Program Files. В случае, если изменения настроек вызываются действиями пользователя, то для этого программу нужно просто (пере)запускать с правами администратора (и повторно перезапускать с обычными правами после внесения изменений). Сложнее ситуация с программами, которые сохраняют какие-то настройки сами. Например, программа может в момент закрытия сохранять свои координаты на экране. В большинстве случаев, неспособность к этому приведет лишь к тому, что программа будет открываться в одном и том же месте экрана. Грамотно написанные программы должны уметь запускаться вовсе без данных для инициализации, получаемых из внешних источников (файлов или записей в системном реестре), выставляя необходимые значения по дефолту.

В заключение небольшая рефлексия по поводу модусов использования Windows и Linux, и почему ситуация Майкрософта в некотором смысле сложнее чем у разработчиков Linux/Unix. Описание проблем, возникающих у пользователей Windows при переходе c XP на более поздние версии, могло произвести впечатление, что они мол представляют собой не самую грамотную часть населения. Причина этого, однако, в том, что лица, использующие Windows, могут быть специалистами, но специалистами в совершенно других областях, в которых компьютеры – это лишь инструменты для достижения цели (нужно ехать, а не шашечки). Напротив, Linux часто ставится для решения какой-то специфической IT-шной проблемы, либо – возможно еще чаще – для целенаправленного изучения. К тому же, у меня сложилось впечатление, что период «полураспада» знаний в области Unix/Linux больше. Как минимум, это справедливо в отношении основ архитектуры и пользовательского интерфейса. Прочитанные мной введения в Unix, написанные большей частью еще в 1990-е годы, дали вполне адекватные знания, оказавшиеся пригодными при работе с Linux. По этим и ряду других причин, готовность инвестировать время в систематическое изучение Linux/Unix выше чем в случае Windows (не считая, естественно, разработчиков, пишущих программы для этой ОС).