7 января

О том, когда случился(тся) конец века.

Дамы и господа, не будьте так серьёзны, у меня и в мыслях не было устраивать на эту тему войну. Решили, что в 2001-м, ну и пусть его. Мне не жалко. :-)

Увы, конечно, это решение не стыкуется с принятой системой счисления, но это, собственно, не очень важно. Почему не стыкуется? Потому, что десяток кончается тогда, когда идёт перенос из младшего разряда в старший, а не когда в младшем ноль сменяется единицей. А не потому, что в Си массивы с нуля индексируются. Сам факт наличия ошибки Y2K говорит о том, что именно 2000-ный год принципиально отличается от 1999-го, а не 2001-й от 2000-ного.

Принятие границы века именно на рубеже 2000-ного и 2001-го годов отчасти (отчасти) обусловлено исторически - исходя из того, что перед 1-м годом идёт -1-й год делается вывод, что 1-й век начался в 1-м году. А не 0-й в 0-м. Действительно, все остальные варианты "разметки" (0-й в -1м, -1-й в -1-м, :-) смотрятся ещё более маразматично.

Увы, от того принятая система летосчисления не стала логичной до конца, что, собственно, и заставляет меня ворчать. Я ещё раз обращаю внимание на то, что предки со своим -1-м годом лишили нас возможности построить идеальное с математической и программистской точки зрения летосчисление, а все возможные исходя из пары -1:1 варианты моему сердцу отвратительны.

Пришло тут в голову, что проблема прав на использование и распространение принимает довольно запутанный характер в отношении шрифтов. Я купил шрифт и использовал его при создании сайта. Значит, чтобы реализовать права собственника, я должен сделать его доступным всем, кто смотрит мой сайт. Но, в идеале, сделать это так, чтобы ни для чего ещё этот шрифт не мог быть использован. То есть инсталлировать его на машине клиента нельзя. Но чтобы минимизировать скорость загрузки сайта шрифт, всё же, желательно сохранить на машине клиента. А если с таким шрифтом сделано десять сайтов, то, формально говоря, у него должно лежать десять копий этого шрифта.

Проблему со шрифтом можно назвать надуманной, но давайте заменим слово "шрифт" на "аплет", например, причём существенный для сайта. На "небесплатный плагин". На любой модуль, используемый на клиентской стороне и в то же время не бесплатный.

Фактически, принятая правовая схема препятствует прогрессу компьютерного мира в плане модуляризации софта. Сегодня проблема зачастую решается путём выпуска бесплатного "клиентского" модуля и платного "серверного", или бесплатного "декодера" и платного "кодера". Пример - "смотрелка" для word-овых файлов и сам MS Word. Но... так возможно не всегда. Со шрифтами, к примеру, невозможно.

Разве что исполнять шрифты в виде собственно растеризатров, а не блока параметров для них, как это делается сейчас, а входной поток (которым сейчас является текст) сделать зашифрованным... Тогда шрифт можно будет раздавать бесплатно, а шифровщик для него - за деньги. Ну и всем сайтовладельцам придётся использовать его для построения сайта в шужных шрифтах. Громоздко, не так ли. Маразматично. Кое-как приемлемо для музыки и видео, но не для текста же.

Какая в форуме война про select и нити - просто загляденье. И почти все, словно сговорившись говорят лишь о производительности.

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

Небольшое отступление. Идея объектной ОС вырисовывалась очень давно. Неестественность понятий "программа", "процесс", "файл" - основ традиционных ОС, очевидна любому, кто когда-нибудь обучал полного чайника общению с компьютером. Все эти понятия вторичны. Первичны, например, понятия "документ" и "напечатать". Откуда берутся "программа печати" и "файл с документом"? А никоткуда. Исторически. Так вышло.

С другой стороны, перед программистами давно уже стоит задача тонкого взаимодействия между программами (тоньше, чем "одна программа удалила вторую"), скриптинга, потребность в модульности всё растёт - всё это как-то решается, конечно, но решения частны и однобоки. DLL-и и shared libraries, средства межпрограммной коммуникации и сетевые протоколы, скрипт-языки и интерфейс для них в прикладных программах...

Ещё одна наприятная сторона традиционного программирования - ядро ОС. С ним - куча проблем. Во-первых, оно не слишком гибко - поведение ядра редко получается модифицировать или дополнить, а если это и возможно (путём установки драйвера, ядерного модуля, инсталлируемой файловой системы и т.п.), то опять же, решение оказывается частным, трудоёмким и проблемным в применении - уже хотя бы потому, что установка дополнений в ядро доступна лишь администраторам систем и создаёт риск нарушения защиты. А ну, как в ядерном модуле троян? Вот ужо он получит власти над нами, добравшись до святая святых...

Кроме того, присутствие в ядре свего того, что там традиционно понапихано вовсе не обосновано. Например, модуль файловой системы находится в ядре беспричинно - он не нуждается, вообще говоря, ни в каких привелегиях, кроме доступа в ограниченную часть адресного пространства процесса, запрашивающего ввод-вывод. Но этот доступ можно организовать и из-за пределов ядра - вопрос лишь в реализации адекватной схемы взаимодействия между процессами. Пусть файловая система сидит в процессе, а мы будем к ней обращаться через interprocess communications (IPC). Идея стара, как мир. От неё происходят микроядерные ОС. Точнее, пытаются произойти - разве что QNX как-то приблизился к идеалу в данном направлении, но это - специализированная ОС.

Тем не менее, идея давно оформилась. Выкинуть из ядра всё, что можно - пусть будет клиент-серверная модель, и пусть сервера не будут концептуально ничем отличаться от клиентов. Те же процессы. Или объекты. Потому как процессы с точками входа (методами), собственно, уже объекты. Кстати, поскольку они не обязаны иметь собственный поток управления, то они вовсе не обязательно процессы. Но не суть.

Дальше, если присмотреться, то выясняется, что процессы с точками входа заодно решают кучу других проблем. Модульность - DLL-и и shared libs больше не нужны, любую функциональность можно оформить в виде такого же процесса/объекта. Скриптинг? Если всё, что умеет программа оформлено в виде нужных точек входа/методов, то скриптинг делается на раз. Взаимодействие между программами? Да сколько угодно, интерфейс-то есть.

То есть, как бы, оказывается, что такая модель при минимуме средств (объект/программа, метод/точка входа) обеспечивает решение широченного диапазона задач. Что и привлекает, собственно.

Но хочется и следующего шага. Если, к примеру, CDFS реализована в виде процесса/объекта, то почему части, из которых она сделана, не могут быть теми же объектами? Пусть каждая переменная, пусть каждый int и строка получат адресное пространство, точки входа... тогда понятие "программа" растворяется совсем, вся система обретает вид развешанных в пространстве миллионов крошечных объектиков, лишь умозрительно собранных в "ms word" (во-он та тучка) или "CDFS driver" (скопление близ ядра). При этом каждый крошечный компонент в принципе доступен всему миру самостоятельно. Практически же добраться до него можно лишь получив на то от владельца соответствующее право.

Что в такой системе любопытно? То, что у неё, например, принципиально отсутствуют некоторые виды подверженности хакерским атакам. Классическое переполнение стека, например. Если хакер и сумеет переполнить стек объекта "строка символов", в который идёт приём запроса с сети (что, кстати, невероятно само по себе - по другим причинам) всё, что он грохнет и к чему получит доступ - так это к ней же. Ведь адресное пространство у всех своё. Другой плюс - отлаживаемость. Наличие 100%-ной информации о типах и прозрачность всей системы позволяют в любой момент времени прогуляться по чему угодно в системе, легко пересекая границы приложений, сервисов, драйверов - всё устроено одним образом, всё поддаётся анализу. Ну и далее - открытость и прозрачность, мощная модель защиты, единообразие и компактность набора интерфейсов - всё это, в итоге - лёгкость программирования. В общем, счастье для всех даром, и пусть никто не уйдёт обиженный.

Только вот одна беда. Нет, её даже сделать не слишком сложно. Но... с быстродействием там проблемка одна. Одна. Но крупная. А жаль.

Алгебра программирования. Тут в форуме вопрос: Устарел ли (Виртовский) лозунг программирования: "Алгоритмы + Структуры данных = программы".

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

Если же о процедурном, то "алгоритмы + структуры данных = классы", "классы + алгоритмы + структуры данных = геморрой до небес", "классы + классы = программы".

Но третьего уравнения пока почти не существует в природе. Его можно создать врапперами и другими соплями, но результат будет всё равно плохим.