Последствия снежной лавины

Видно, что под поломанными деревьями и ветками толстый слой снега, под которым течёт потерявшая своё русло горная речка. Меня удивило направление вывала леса на склоне слева. Стволы легли вверх. Такое впечатление, что лавина с разгону заехала на противоположный склон, повалив деревья. Gold Creek, 3.5 miles from trail head.

Компьютерно-операционно-системное.

Для начала порекламирую неплохой блог с занятной и полезной информацией: блог Guastavo Duarte (англ.) А в нём статьи о начальной загрузке, адресной арифметике и уровнях защиты. Если данные вопросы неинтересны или непонятны, дальше можно и не читать. Собственно, не читать можно в любом случае. Как и наборот. А теперь, после введения, очередная небольшая порция ворчания. Которое состоит в том, что вся эта адресная арифметика и кольца защиты сейчас настолько привычны, что мы даже и не представляем, что может быть по другому. А вот раньше, говорю я постанывая, посвистывая и с хрустом распрямляя позвоночник, мы работали в системах "real mode" безо всякой защиты и такие программы писали, такие, этакие..., да такие же как и сейчас, только поменьше. И которые при любой ошибке вызывали перезагрузку, которая, однако надо отметить, была значительно быстрее теперешней! Довольно занятные системы были в домикрософтовсую и до-ibm-pc-шную эру реального режима. Например, были всякие занятные системы основанные на паскале и модуле. Последная была, как нетрудно догадаться, модульная, причём драйвер устройства - такой же модуль, как и программа пользователя, никакой разницы. Никакой разницы не было, kernel mode or user mode. Одно вызывало другое. Это была экзотика, мини-компьютеры. А большие компьютеры делались на той же, что и сейчас архитектуре, с двумя режимами, режимом ядра и режимом пользователя. Главное в такой архитектуре - защитить ядро от программы пользователя, и программы друг от друга. Традиционно есть процесс, как единица защиты. Процессы защищены друг от друга, ядро защищено от процессов, процесс можно убить, все ресурсы утилизировать без вреда для системы. Внутри же процесса - никаких защит, делай всё, что угодно. Это традиционная архитектура операционных систем. Для неё и делаются все эти адресные арифметики, кольца защиты, виртуальная память с таблицами страниц и прочее. И она, эта архитектура позволяет заражать программы вирусами, исполнять код в стеке, переполнять буфера, позволяет почтовым программам модифицировать системные файлы, ну и конечно, позволяет выполнять и все остальные полезные функции, за что мы её и любим. Естественно была попытка сделать и менее традиционную архитектуру. Где нельзя заражать и выполнять. Где почти ничего нельзя, кроме того, что можно. Где защита сидит в каждом указателе, в каждом массиве, в каждой функции. Аппаратно нельзя выйти за границы. Аппаратно нельзя сделать из числа указатель. И функцию нельзя вызвать если нет на неё указателя. Абсолютная защита. Естественно, всё было задумано в Советском Союзе, как нетрудно догадаться по приведённому описанию, и там же успешно где-то реализовывалось в течении многих лет, до тех пор, пока Горбачёв не произнёс своё знаменитое "разрешено всё, что не запрещено", чем подрубил концепцию на корню. Я очень уважаю разработчиков Эльбруса за эту архитектуру. Увы, в полноте своей она несколько утопична, почти как коммунизм. Обе требуют от человека того, что он дать не может. Коммунизм требует нечеловеческой сознательности, а Эльбрус - нечеловеческой предусмотрительности при программировании на нечеловеческих языках. Хотя второе интересно было бы попробовать. Не знаю, что там будет дальше с Эльбрусом. Идеолог, академик Бабаян теперь работает в Интеле, хотя фирма существует. Но бог с ней, с фирмой. Дело в том, что в подобной системе тоже нет уровней ядра и пользователя. Если функции защищены друг от друга, то драйвер - это просто функция, такая же, как и любая другая. И файловая система - обычный модуль, как и любой другой. И никакой трансляции адресов не надо, и уровней защиты не надо и много всего прочего. Фактически, сложность аппаратуры не выше, чем традиционной. Кстати, упомянутая фирма недавно сделала таки свой микропроцессор, и двоичный компилятор для него. Респект, если работает. Это вам не винду перекрашивать. Хотя я опять отвлёкся, не про него хотел рассказать. Одно время казалось, что это всё где-то далеко в фантастических северных странах, в далёком прошлом или далёком будущем, но услышанная фраза "software isolation" заставила поменять точку зрения. Фраза очевидна - заменить аппаратные границы программными. В эпоху виртуальных машин даже нетривиальная архитектура возможна. Но виртуальная машина - только один из нескольких подходов к "software isolation" и далеко не самый эффективный. Второй подход исповедуют разработчики проекта Midori в Microsoft (бывшая Singularity). Они предлагают оставить процессы как границы защиты и проверить программно двоичный код процесса на то, что он не выйдет за границы и ничего не сделает запрещённого. Тогда этот процесс можно запускать без аппаратной защиты. Я скептически отношусь к данному подходу. И доказать очень сложно и выгода невелика - только производительность, что в наше время грядущих 64-процессорных ядер не самая большая проблема. Третий подход основан на идее генерации кода. Допустим программа существует на некоем байт-коде, а система строит реальный двоичный код сама при запуске. Как в .NET или Java. В таком случае если исходный байт-код не позволяет чего-то сделать то и двоичный код этого не сделает. И его можно запускать без аппаратной защиты. Подобные системы могли бы работать почти как Эльбрус без его аппаратных заморочек. Причём большая часть ядра может сама быть написана на подобном языке. Неудобство данного подхода в невозможности запускать программы в двоичном коде, написанные на non-managed языках. Мне кажется, наиболее перспективный подход, особенно для встроенных систем. Сейчас есть несколько проектов, Java OS, например. Привет вам от Модулы. Здесь выгод может быть множество: более простая аппаратная часть, более простая структура операционной системы, защищённость на уровне процедур или классов. К сожалению, языки типы Java или С# не могут достичь идеальной защиты и избавить нас от вирусов и троянов. Их байт код недостаточно ограничен для этого. Но вообще, я думаю, что software isolation - интересное направление. Но вряд ли пройдёт в mainstream. Слишком далеко мы все ушли в другую сторону. Куда мы без привычной винды.

Жирный пингвин робко прячет тело жирное в утёсах...

Почитал на досуге про udev vs. devfs. Для незнакомых с Линуксом поясню, что это управление именами устройств в файловой системе, т.е. некая жизнь на границе ядра и приложений. Короче, пингвиньи блохи. Раньше жил только один вид, devfs, а потом постепенно развился новый - udev и полностью вытеснил старый. Просто совсем вытеснил, вплоть до полного удаления. Интересно то, что непонятно чем новый вид, собственно, лучше. У меня сложилось впечатление, что он не только не лучше, а хуже. Если объяснять на компьютерном языке, то devfs представлял собой небольшой модуль в ядре, который по сигналам драйверов создавал устройства со стандартными именами. Зато udev - это архитектурная астронавтика. Это демон, который общается с ядром, создаёт имена по некоторым описанным в конфиге правилам, общается с приложениями, которые хотят получать события о создании устройств, и т.д. Дизайн-патерн мне показался очень знакомым. Ситуация такова - есть первая система, очень простая и понятная. С некоторыми небольшими проблемами. Есть некий архитектурный астронавт, который очень пропагандирует некоторую супер-архитектуру, способную покрыть старую систему как бык овцу, и в дополнение решить кучу других проблем, хотя никто никогда с этими другими проблемами и не сталкивался. Как правило маленький компонент или функция будет заменён на некий сервис, вероятно сетевой, возможно веб-сервис. Производительность будет ужасна, но не фатальна, она, вероятно и никогда не была узким местом. Новые проблемы, которые возникли после перехода на новую систему, будут объяснены тем, что система ещё не доделана до полной своей функциональности, и тогда она покроет не только старую функцию, но и всю систему вообще. Здесь главное - напористость астронавта. Особенно, если старая архитектура не особенно персонифицирована и не имеет столь же горячего защитника. Как только новая архитектура будет принята, её доделают до некоей приемлемой формы, другого выхода нет, но лишний килограм веса на животе это добавит. Ещё один, к досаде тех, кто ценит стройность архитектуры. Я раньше считал, что подобное - удел коммерческих компаний и закрытого софта больших компаний. Там это просто непрерывно. Но почитав линуксовые форумы, понял, что нет, это универсально. В открытом софте - то же самое. Фактически, исправить ситуацию может только давление, отбраковывающее подобные патерны, а его по ряду причин нет. Грустно. Не хочется пускать в свой компьютер жирного пингвина. И udev не хочется. Хочется простоты и удобства. Каталоги, как в GOBO, простые модули вместо сервисов, ненавижу сервисы. Наверное, надо фряху посмотреть или в гентушники податься, последнее прибежище отчаявшихся в разумности коллективного сознания.

Провода

Мысль дня

"There is nothing intellectual in a property." (Нет ничего интеллектуального в собственности.)

Навеяно обсуждением параграфа из годового финансового отчёта Майкрософт.

О хлебе насущном.

На местном рынке купил хлеб местной выпечки. Домой принесли, съели весь за один присест без ничего, даже ничем не намазав. Один запах чего стоит! Хлебом пахнет. Оказывается семейный бизнес. У них печь во дворе каменная. И мельница своя. Они сами мелют зерно, из свежей муки хлеб пекут. Ничего не замораживая, по старым рецептам из натуральных компонентов. Дорого. Но вкусно так, что денег не жалко. Жаль рынок работает только раз в неделю. Вот я всё жду, когда потребитель пожелает вкуса в софте. Я бы тоже попробовал семейный бизнес открыть. Софт на ассемблере и Алголе-68, ручная работа, по старинным рецептам. Может попробовать, бросить свой макдональдз, выпечь что-нибудь, вдруг кому понравится!

Корпоративные игры.

Этот текст является комментарием к тексту Эльдара про фермеров и рабочих в программировании.

Фабрики производят массовый товар, выполняя функцию клонирования. Программисты должны, в принципе, писать уникальный код, ибо стоимость прямого клонирования нулевая. Но модель продажи построена на старых традициях материального производства, поэтому нулевая по себестоимости функция клонирования оплачивается реальными деньгами, и эта особенность приводит к тому, что компания однажды завоевавшая рынок, может больше вообще ничего не производить, продавая копии уже сделанного. Рынок информационного продукта в силу ряда причин любит сиквелы и версии того же самого, что работает на ту же тенденцию. Обычно мелкие изменения и исправления багов достаточны для продолжения продаж. Покупатели не требуют прорыва и изменений. "Мы только-только разобрались в предыдущей версии, не надо нам нового API, сделайте просто чтобы старый работал, и всё."

А люди сидят, им надо расти, делать карьеру. Чем же они заняты? Корпоративными играми. Они играют в производство, в карьеру, в перспективные исследования и разработки, в новые методы производства и системы управления персоналом. Сотрудники делают супер-пупер продукт следующего тысячелетия, проводя бессонные ночи над переписыванием всего кода на новый язык или новую платформу, и ничего при этом не выпуская. А когда кто-то вдруг потребует выпустить что-нибудь, чтобы оправдать расходы, можно быстро повырезать весь новый сомнительный креатив и выпустить почти то же самое, что было, слегка перекрасив. Начальник сделает умное лицо и скажет, что мы потратили миллиарды на разработки и исследования и выпустили продукт много лучше, чем все остальные наши продукты. Блогеры и журналисты скажут WOW! Хакеры расскажут о способе вернуть старую раскраску и привычные функции. Все будут довольны.

Но только до тех пор, пока неумолимое движение прогресса не сделает этот супер-успешный продукт никому не нужным или выскочка-конкурент не напишут вдруг что-нибудь на порядок лучше и удобнее. Но даже и тогда, агония будет долгой, движение прогресса неспешно, инерция потребителей велика, супер доход от копирования позволит уничтожить конкурента или, в конце концов, попытаться завоевать новый рынок.

И тут-то и будет поджидать засада. Забыли! Разучились! Забыли как выпускать. Разучились писать исходя из здравого смысла, из проблем потребителя, быстро и эффективно. Начальство продолжает играть в игры, в карьеры, строить супер-пупер стратегии. Внедрять технологии и бизнес-процессы. Управлять персоналом. И потому не получается захватить новый рынок. Остаётся подождать, пока конкурент тоже начнёт деградировать от своих внутренних игр. И там, в будущем, мы ещё посмотрим, кто победит в финальной схватке гигантов. Если сумеем вспомнить их имена.