`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

"Кирпичики", или Кризис "just for fun"

0 
 

Изначально автор задумывал кратко рассказать только о весьма интересном проекте Brix (произносится как "брикс", откуда и "кирпичики" в названии статьи). Но "интересность" -- далеко не самое важное свойство той или иной программной системы в наше время.
Мы уже неоднократно говорили о разных операционных системах. В наше поле зрения попадали и совсем нетривиальные разработки (такие, как Plan 9 и Oberon), и куда более "приземленные" проекты (AtheOS). Естественно, говорить о том, что все эти системы представляют собой "передний край" computer science, было бы непозволительно. То же самое касается и "еще одной ОС" -- Brix, ведь этот проект (на самом деле сегодня Brix действительно далек от завершения) ничего существенного к давно определенному перечню идей в системном программировании не добавляет. Впрочем, сейчас отсутствием новизны в очередной разработке кого-либо удивить трудно. Возможно, это в чем-то и неплохо -- новизна всегда слишком далека от насущных потребностей сегодняшнего дня. И все же новые операционные системы нужны -- хотя бы для "обкатки" пригодных к реализации на пользовательском или общесистемном уровне полезных идей и технических решений. Кроме того, в сложившейся ситуации тотального доминирования фактически двух платформ -- с одной стороны, ОС Windows, с другой, Unix-подобных систем -- остается в тени крайне неприятный факт наследования новыми реализациями этих ОС зачастую даже не далекого от совершенства, а убогого наследия прошлого, неизменно сопутствующего любым разработкам "с предысторией". "Совсем альтернативные" (в том смысле, что не попадающие в mainstream) системы иногда демонстрируют с неожиданной ясностью слабые или сильные черты тех решений, которые логично ожидать в будущих поколениях потребительских ОС.

Итак, "кирпичики"... Еще один представитель гибридов "язык программирования -- ОС", весьма близкий по ряду идей к Oberon. Правда, в отличие от ставших уже каноническими как в части синтаксиса, так и в части семантики, языков -- разработок школы Н. Вирта, "лингвистическая" основа Brix является чем-то совсем удивительным. Представить себе нечто, объединяющее свойства таких полярных языковых систем, как Forth, Lisp и Ada (именно на них ссылается сам автор проекта Brix), крайне трудно. Впрочем, если забыть об этом упоминании, единственный язык, "понимающий" Brix, -- Crush, никаких выдающихся особенностей не имеет. Зато его "единственность" -- весьма важное свойство. По идее, Brix (как и Lisp/FORTH-системы) должна работать на "собственном" аппаратном обеспечении, для которого Crush является "системой команд". До такого уровня развития системе еще очень далеко, а если вспомнить судьбу иных "гибридных" систем, можно смело говорить о... потенциальной бесперспективности идеи: несмотря на всю привлекательность высокоуровневых процессоров, обрабатывающих за счет аппаратных средств фактически ЯВУ (Язык Высокого Уровня), и Lisp-машины, некогда серийно выпускавшиеся, и рабочие станции Lilith (процессоры которых "понимали" язык Modula 2), остались разве что редкими экспонатами музеев компьютерной старины. Единственное исключение из правила -- немногочисленные аппаратные FORTH-вычислители, держащиеся "на плаву" в весьма специфических нишах для создания сравнительно недорогих и надежных систем управления реального времени. Так что сама идея объединения этого специфического языка (а Crush действительно специфичен) с не менее специфической архитектурой ОС с самого начала вызывает если не скепсис, то настороженность.

В детали реализации языка Crush мы вдаваться не будем -- те, кому это интересно, могут ознакомиться с ним по не слишком детальным, но достаточным спецификациям на сайте проекта Brix (brix-os.sourceforge.net). Стоит только отметить, что упомянутый ранее странный "коктейль" из сугубо императивного языка Ada, стековой системы программирования FORTH и языка функционального программирования Lisp получился более чем странным и по-своему уникальным. Изобилие (здесь больше напрашивается слово "излишество") конструкций языка сразу бросается в глаза -- здесь есть и модули, и функции, и лямбда-функции -- безымянные вложенные в функции подпрограммы, которыми можно оперировать как данными (по сути являются макросами Crush), и собственно макросы (подставляемые препроцессором перед этапом трансляции фрагменты кода), и множество модификаторов для описания типов данных, и встроенные директивы ассемблера целевой машины, заимствованные из Ada и Eiffel конструкции -- атрибуты "проектирования по контракту" (design on contract, заключаются обычно в расширении понятия "интерфейс" способностью проверять выполнение некоторого условия еще до создания реализации), и исключительные ситуации и механизмы их обработки (весьма похожие на свои аналоги из С++). Если добавить к этой картине динамический объектно-ориентированный характер Crush (при котором переменные являются контейнерами для хранения объектов произвольных типов), получаем нечто уже совсем загадочное (и по мнению не только автора статьи -- неудобоваримое): с одной стороны -- созданное для того, чтобы программисту было трудно писать программы с ошибками, с другой стороны -- созданное так, что ему становится трудно писать их вообще (а тем более -- читать; чего стоит только допустимость рекурсии в лямбда-функциях). Вероятнее всего, именно по этой причине ("неудобоваримости" основного языка, а не по каким-либо декларируемым иным) Crush в Brix является именно основным низкоуровневым средством, для которого создаются трансляторы менее совершенных, но куда более пригодных для человека языков (порой сочетания исходного языка "высокого уровня" и кода целевой машины -- в данном случае Crush, образуют просто настоящие образчики программистского юмора -- например транслятор из C в Crush).

"Странности" Crush во многом проясняются при знакомстве с организацией ОС Brix. Во-первых, у этой системы нет... ядра. Такая организация далеко не нова -- существует даже термин, определяющий класс ОС, не имеющих выделенного ядра (exokernel systems), и в этом смысле Brix -- не единственная разработка. Функции ядра в ней выполняет набор программных модулей, образующих одну из многих библиотек. И все-таки, "изюминка" у Brix есть -- она заключается в отказе от динамического редактора связей, работающего во время загрузки программы. Подкрепляется это решение использованием так называемого "линейного адресного пространства" (ЛАП, опять же не новый термин -- существует и класс ОС, реализующих linear address space). Сторонники ЛАП во многом обоснованно считают, что возможности современных процессоров и доступные объемы памяти дают возможность создавать достаточно функциональные вычислители, обладающие реальными характеристиками и работающие без аппаратной поддержки виртуальной памяти. Соображения здесь просты -- грубо говоря, полноценные 64-битовые процессоры, становящиеся обыденностью, позволяют адресовать... более четырех миллиардов банков памяти емкостью 4 GB каждый. Соответственно, если организовать некий механизм прозрачного удаленного доступа к таким банкам памяти, обладающий достаточной (не будем вдаваться в значения...) пропускной способностью, можно организовать гигантский распределенный вычислитель, состоящий из нескольких миллиардов отдельных компьютеров. В такой среде автоматически решается масса сложных на сегодняшний день вопросов и, естественно, появляются новые, не менее сложные.

Возвращаясь к Brix, стоит отметить, что в этой системе из-за отсутствия динамического редактора связей все программное обеспечение, установленное на вычислитель, является... одной большой (очень большой?) библиотекой, все вызовы и ссылки в которой содержат реальные адреса ЛАП. А для приведения "идеологической красоты" к требованиям реальности механизм исполнения в Brix основан на запуске одной из функций такой библиотеки в отдельном потоке с передачей ей всех необходимых данных. Такая организация позволяет выделять исполняющейся задаче в физическом адресном пространстве быстродействующей памяти (RAM) вычислителя минимально необходимую память. Соответственно, саму библиотеку-программу-ОС при этом нужно как-то хранить, не нарушая целостности ЛАП (в противном случае все "игры в истинность" адресов окажутся бессмысленными), -- для решения этой задачи предназначена файловая система Brix, на деле являющаяся примитивным неструктурированным хранилищем объектов (object store), обеспечивающим живучесть (persistence) последних на уровне энергонезависимой памяти (т. е. объекты сохраняются даже после выключения питания компьютера). Единственный нюанс object store Brix -- встроенная реализация механизма контроля версий объектов -- выгодно отличает эту подсистему от существующих аналогов (а они, естественно, есть).

Итак, кратко подводя итоги обзорному знакомству с Brix, можно говорить об этой системе как об ОС, основанной на модели "живучих" объектов в 64-битовом ЛАП. Учитывая, что и "живучие" объекты сегодня настолько не в диковинку, что даже обещаны Microsoft в будущих версиях ОС Windows (та самая пресловутая замена файловой системы на базу данных), и ЛАП -- идея далеко не новая и воплощенная как в ряде экспериментальных ОС, так и в программных системах, функционирующих в традиционных операционных средах, и, наконец, что гибриды функциональных языков программирования и ОС -- весьма популярная в академической среде тематика (например, проекты Fox и Express, foxnet.cs.cmu.edu/HomePage.html и www.ai.mit.edu/projects/express/ соответственно), можно говорить о Brix как о еще одной попытке реализации весьма отработанных идей. К сожалению, в достаточно цельной общей картине перечисленных технологических нюансов одному существенному вопросу уделяется слишком мало внимания. А именно, вопросу безопасности. ЛАП подразумевает наличие сетевых протоколов, обеспечивающих доступ к фрагментам единого адресного пространства (и в этом заключается прелесть идеи), отказ от динамического редактора связей позволяет реализовать "малой кровью" аналог ядра ОС (прием проверенный и использованный, например, в ОС Plan 9), отсутствие требований к аппаратным средствам по поддержке механизмов виртуальной памяти существенно снижает их стоимость и сложность реализации. Все это очень хорошо... при учете одного нюанса -- когда мы ведем речь об идеальной системе, работающей в идеальных условиях. Последние подразумевают, в том числе, идеальные добропорядочность и грамотность пользователей и исключение любого злого умысла, чего, естественно, в реальных системах не бывает. Здесь у Brix наблюдается некоторое, мягко говоря, несоответствие между заявленными высочайшими показателями безопасности и свойствами системы -- так, с одной стороны, язык программирования Crush не позволяет писать "опасные" программы, манипулирующие данными не из "своего" сегмента адресного пространства (Brix во многом заимствует идеи разграничения доступа ОС Unix, перенося их из файловой системы в область адресов), с другой стороны, наличие встроенных в "низкоуровневый" язык конструкций ассемблера целевой машины позволяет... да почти что угодно позволяет, особенно при учете отсутствия требований к аппаратной реализации защиты памяти. Разделение прав доступа к адресам Brix строится по принципу "пользователь -- группа пользователей" и исключает такие понятия, как "все пользователи" и "все группы". Насколько подобная модель реалистична при большом числе соединенных в сеть Brix-компьютеров -- вопрос интересный, впрочем, как и вопрос об администрировании масштабных систем с отсутствием публично доступных сервисов.

В целом, вопросы безопасности как в системах с ЛАП в целом, так в Brix в частности, остаются terra incognita и требуют серьезного и детального изучения.


Just for fun (JFF)

"Всего лишь для развлечения"... Эта фраза уже стала расхожим символом мотивации многих разработчиков из миров freeware и Open Source. Для развлечения создавались новые операционные системы (например, сугубо развлекательная ОС V2OS, v2os.v2.nl), языки программирования (один из ярких представителей -- Befunge), прикладные программы. Правда, в последнее время поток "JFF"-разработок заметно сократился -- и это, в целом, вполне предсказуемо. Во-первых, программирование из чистого искусства окончательно превратилось в профессиональное ремесло (оставляющее место и искусству, естественно), во-вторых, времена безоговорочного почитания IT-профессий безвозвратно прошли. Соответственно, программистов приравняли к прочим специалистам творческо-ремесленных профессий, и разработка "just for fun" стала дорогим удовольствием для очень многих. Похоже, что эта мотивация еще некоторое время будет преобладать у немногочисленных гениальных программистов, но для поддержания жизнеспособности многих альтернативно-некоммерческих проектов назревает необходимость в чем-то новом, ведь и у второй составляющей мотивации, исторически обеспечившей разнообразие и богатство выбора легально бесплатного ПО (условно называемой "академической"), наступили не лучшие времена. Отслеживая историю развития привлекательных академических разработок операционных систем, можно заметить, что большинство (если не все) из них находились "в пике" именно тогда, когда основную категорию участников проектов составляли студенты или аспиранты с четко определенной мотивацией -- защита степени, получение признания в своей среде и т. д. За академическим этапом наступал период пассивного развития малым сообществом, который затем сменялся либо полным забвением, либо поддержкой (уже без развития) фанатичной группой приверженцев. Примеров таких историй слишком много, чтобы их приводить в статье, -- читатель может самостоятельно "побродить" по ссылкам из обзора проектов ОС, чтобы в этом убедиться.

Хотим мы того или нет, но времена JFF проходят -- рынок труда в области IT насыщается, заработная плата снижается, финансирование академической науки также оставляет желать лучшего, и, что главное, потребность в экспериментальных разработках не ощущается. Пользователи хотят хороших, удобных и доступных работоспособных программ (и в этом их обвинить трудно) и не хотят быть "подопытными кроликами" (что тоже никого не удивляет), работодатели не горят желанием давать возможность программистам удовлетворять свое любопытство за счет компании (и здесь нет никакой крамолы), умные руководители начинают бояться дорогостоящих IT-экспериментов, глупые -- разоряются. Все это -- условия объективной реальности, их игнорирование может либо породить пусть интересный, но бесперспективный (из-за концепции "с миру по нитке", как в случае с упомянутой ОС Brix) проект, либо "развлекательно"-бессмысленный ассемблерный код V2OS, к которому очень быстро утрачивают интерес и сами создатели.

Что придет на смену JFF -- вопрос вовсе не праздный. От ответа на него зависит, в том числе, как судьба очень привлекательных молодых альтернативных разработок (к примеру, ОС AtheOS), так и дальнейшее совершенствование уже устоявшихся (состоявшихся) систем (Linux, *BSD). Сегодня, когда стало модным декларировать приверженность идеям "открытого ПО", нужно хотя бы на секунду задуматься о хрупкости и чувствительности самой модели Open Source, о ее зависимости от внешних и далеких от IT условий и, наконец, о главной составляющей этой модели -- разработчиках. Очень грустно, когда блестящие программисты, создавшие настоящие шедевры и сознательно бескорыстно поделившиеся с человечеством плодами своих трудов, утрачивают побуждающие мотивы, но сегодня это стало уже обыденностью. Именно из-за этого прекратилось развитие замечательной графической оболочки (оконного менеджера в терминах X Window) Enlightenment, великолепный руководитель программных проектов Джордан Хаббард покинул свой "пост" в проекте FreeBSD (грустный список продолжать утомительно -- достаточно поинтересоваться мнением разработчиков, "забросивших" свои проекты).

К сожалению автора, вопросом мотивации разработчиков Open Source практически никто не занимается. Истошно-нервозные вопли "рулез" здесь не помогают (обычно они вообще нигде не помогают, и даже наоборот -- мешают), а мода -- дама весьма ветреная и сиюминутная. Попытки декларативно объявлять политику "всемерного содействия" и "поддержания на всех уровнях" на нашем историческом фоне обоснованно кажутся смешными, а на иных исторических фонах таких заявлений делать не принято. Казалось бы, что в области изучения побуждающих мотивов должны за каждый факт буквально драться психологи, экономисты и руководители проектов, ведь эта информация действительно бесценна, но на самом деле... Впрочем, читатель и без мнения автора прекрасно знает, что происходит на самом деле. И, как бы ни хотелось избежать цитирования М. Жванецкого... "или наша жизнь изменится к лучшему, или мое искусство будет жить вечно"... или кроме голословных заявлений о "любви к Open Source" ничего не будет, и мы будем наблюдать конвульсивное развитие JFF-проектов, или... ?

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

0 
 

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT